1 2012-07-11 00:01:15 Maged has quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
   2 2012-07-11 00:01:22 sytse has quit (Ping timeout: 245 seconds)
   3 2012-07-11 00:12:26 rdponticelli has quit (Ping timeout: 252 seconds)
   4 2012-07-11 00:16:54 <copumpkin> what do people think, was bitcoin script a bad idea?
   5 2012-07-11 00:17:12 <copumpkin> if we're only allowing predetermined scripts, it seems like people don't trust it anyway
   6 2012-07-11 00:17:45 <copumpkin> and the flexibility isn't much use if the clients reject nonstandard scripts. Are there plans to unrestrict it someday?
   7 2012-07-11 00:18:00 <gavinandresen> sure, once "we" completely understand it.
   8 2012-07-11 00:18:33 <gavinandresen> (and somebody much smarter than me has proven some things about it, or a subset of it)
   9 2012-07-11 00:19:13 <gmaxwell> I think script is a fantastic and very important idea. It's not like we can constantly upgrade all bitcoin users everywhere for every transaction style people want.
  10 2012-07-11 00:19:18 elkingrey has joined
  11 2012-07-11 00:19:38 <gmaxwell> But that doesn't trump the _actual_ exploits observed in real life multiple times until a mellon baller was taken to it.
  12 2012-07-11 00:19:41 <gavinandresen> copumpkin: is there a script form that you really want?
  13 2012-07-11 00:19:41 <copumpkin> so people are really just waiting for proofs of no badness
  14 2012-07-11 00:19:43 minimoose_ has joined
  15 2012-07-11 00:19:49 <copumpkin> oh no, I was just asking abstractly
  16 2012-07-11 00:19:56 <copumpkin> whether in retrospect people thought it was good or not
  17 2012-07-11 00:20:03 <copumpkin> it's obviously here to stay, regardless
  18 2012-07-11 00:20:32 <gavinandresen> abstractly, yes, I think we need proof of things like "these set of opcodes are bounded in execution time and memory space"
  19 2012-07-11 00:21:03 <gavinandresen> Clients will still only understand a subset of transaction forms, I think, it'd be impossible to give a good user experience for "here's an arbitrary script, want to sign it?"
  20 2012-07-11 00:21:09 <gmaxwell> And proof that they aren't isomorphic to OP_RUNx86code
  21 2012-07-11 00:21:10 minimoose has quit (Ping timeout: 264 seconds)
  22 2012-07-11 00:21:10 minimoose_ is now known as minimoose
  23 2012-07-11 00:21:13 luke-jr has quit (Read error: Connection reset by peer)
  24 2012-07-11 00:21:15 <copumpkin> gmaxwell: :)
  25 2012-07-11 00:21:31 luke-jr has joined
  26 2012-07-11 00:21:37 <copumpkin> there seem to be a lot of highly redundant opcodes
  27 2012-07-11 00:21:46 <copumpkin> I guess to save space for common operations?
  28 2012-07-11 00:22:16 <gavinandresen> I suppose; I don't think the opcode set is well designed.
  29 2012-07-11 00:22:24 <copumpkin> fair enough
  30 2012-07-11 00:22:56 <gavinandresen> It fails my "zero one infinity" rule in a bunch of places
  31 2012-07-11 00:23:12 <copumpkin> zero one infinity?
  32 2012-07-11 00:23:17 <copumpkin> oh
  33 2012-07-11 00:23:29 <copumpkin> special cases for 0, 1, and then no others?
  34 2012-07-11 00:23:42 <gavinandresen> 0 means leave the feature out, you don't need it.
  35 2012-07-11 00:23:58 <gavinandresen> 1 means in practice there will only be one of the damn thing, so just plan for 1.
  36 2012-07-11 00:24:12 <gavinandresen> If you're designing for 11 things, then you might as well design for infinity.
  37 2012-07-11 00:24:41 <gmaxwell> copumpkin: the implicit directs look a _lot_ like the opcodes for microcode instructions for very high speed network processors with limited microcode space that I've worked with. (which do it for space, because when you have to write packet extraction code in 200 bytes it matters!) But I only assume the motivation was the same in bitcoin.
  38 2012-07-11 00:24:47 <gavinandresen> Doesn't apply to hardware, of course, where you've got physical constraints, but I'm a software guy
  39 2012-07-11 00:25:02 <copumpkin> yeah
  40 2012-07-11 00:25:07 <copumpkin> I see
  41 2012-07-11 00:27:11 one_zero has joined
  42 2012-07-11 00:28:27 t7 has quit (Remote host closed the connection)
  43 2012-07-11 00:28:58 rdponticelli has joined
  44 2012-07-11 00:34:45 da2ce746 is now known as da2ce7
  45 2012-07-11 00:34:54 ahbritto has quit (Quit: Ex-Chat)
  46 2012-07-11 00:39:15 <[Tycho]> So much efforts for P2SH and no results to end-users yet... Even blockchain.info dropped their support for multisigs.
  47 2012-07-11 00:39:23 sytse has joined
  48 2012-07-11 00:40:50 <doublec> how much use is P2SH getting?
  49 2012-07-11 00:45:00 <BlueMatt> [Tycho]: p2sh/multisig is setting up for the future, not actually implementing it ;)
  50 2012-07-11 00:45:18 <[Tycho]> doublec:  none.
  51 2012-07-11 00:58:28 <copumpkin> http://snapplr.com/d0sq
  52 2012-07-11 00:58:32 <copumpkin> why are those marked as special input-wise?
  53 2012-07-11 00:58:59 <copumpkin> that doesn't seem to have anything to do with the stack
  54 2012-07-11 00:59:15 Zarutian has quit (Quit: Zarutian)
  55 2012-07-11 01:09:09 <BlueMatt> heh...we check sigop count in coinbase input...
  56 2012-07-11 01:10:09 <copumpkin> I don't really understand the notation for OP_IF and friends in the input/output parts
  57 2012-07-11 01:10:21 <copumpkin> is parsing it the weird part or is the semantics?
  58 2012-07-11 01:13:44 <BlueMatt> someone wanna check to make sure we won't generate blocks with >MAX_SIGOPS if we have a coinbase that an unlucky miner stuffed a ton of OP_CHECKMULTISIG's into?
  59 2012-07-11 01:13:51 bobke has quit (Quit: No Ping reply in 180 seconds.)
  60 2012-07-11 01:13:58 bobke has joined
  61 2012-07-11 01:15:19 minimoose has quit (Quit: minimoose)
  62 2012-07-11 01:15:55 <BlueMatt> heh, any miner that stuffs 0xac,0xad,0xae or 0xaf in their coinbase could potentially generate invalid blocks, and...go see if you can make the pools die
  63 2012-07-11 01:16:16 <BlueMatt> also...need to think about this for putting height in coinbase
  64 2012-07-11 01:16:52 <luke-jr> BlueMatt: I don't think so.
  65 2012-07-11 01:16:55 <BlueMatt> especially any 0xae or 0xaf's because those count as 20 sigops...
  66 2012-07-11 01:17:03 <luke-jr> BlueMatt: though you could easily trick p2pool into generating invalid blocks ;)
  67 2012-07-11 01:17:19 <luke-jr> (already fixed when gmp_bip gets merged)
  68 2012-07-11 01:17:44 <BlueMatt> luke-jr: well that checks that blocks will be accepted, but will it actually give you blocks if it starts to fail?
  69 2012-07-11 01:18:17 <luke-jr> BlueMatt: checknewblock != gmp_bip
  70 2012-07-11 01:18:40 <luke-jr> BlueMatt: gmp_bip adds sigop info to getmemorypool, so poolservers can avoid breaking the limits
  71 2012-07-11 01:19:15 <BlueMatt> does it include the coinbase tx's inputs in the sigop count?
  72 2012-07-11 01:19:35 <luke-jr> the sigop count is per-transaction, so yes
  73 2012-07-11 01:19:37 <BlueMatt> (and, leave it to the poolserver isnt a valid answer)
  74 2012-07-11 01:19:42 <luke-jr> but usually the poolserver makes its own coinbase
  75 2012-07-11 01:19:47 <luke-jr> (and coinbase has no inputs)
  76 2012-07-11 01:19:47 <BlueMatt> (and, leave it to the poolserver isnt a valid answer)
  77 2012-07-11 01:19:56 <BlueMatt> no, but it has scriptSig, and we count that
  78 2012-07-11 01:21:14 <luke-jr> bitcoind doesn't serve coinbasetxn, so not an issue there
  79 2012-07-11 01:22:28 <gribble> New news from bitcoinrss: TheBlueMatt opened issue 1578 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1578>
  80 2012-07-11 01:23:08 mmoya has quit (Ping timeout: 248 seconds)
  81 2012-07-11 01:26:59 Diablo-D3 has quit (Ping timeout: 244 seconds)
  82 2012-07-11 01:27:27 <doublec> luke-jr: why does bip 22 use the same name as an existing rpc call?
  83 2012-07-11 01:27:38 <doublec> luke-jr: when it seems a lot more complex
  84 2012-07-11 01:28:14 <luke-jr> doublec: it standardizes the existing RPC call in a generally useful way
  85 2012-07-11 01:28:42 <doublec> luke-jr: given getmemorypool already exists and has usage, wouldn't it be better to give bip 22 a different name
  86 2012-07-11 01:28:58 <doublec> luke-jr: since it seems a whole lot more that just getting memory pool information
  87 2012-07-11 01:29:00 <luke-jr> doublec: it's backward compatible, and incldues the same usage
  88 2012-07-11 01:29:29 <luke-jr> doublec: and notably the old getmemorypool has a flawed design as-is now
  89 2012-07-11 01:29:46 <doublec> it's backward comaptible only in that it takes an argument, right?
  90 2012-07-11 01:29:47 <sipa> bip22 is really just an improvement for the existing getmemorypool call
  91 2012-07-11 01:29:49 <doublec> whereas the original doesn't
  92 2012-07-11 01:29:54 <sipa> but that usage is really not getting the memory pool
  93 2012-07-11 01:30:10 <doublec> sipa: right, good opportunity to give it a more relevant name
  94 2012-07-11 01:30:24 <luke-jr> sipa: most uses get the memory pool :p
  95 2012-07-11 01:30:57 <doublec> it's called "getmemorypool" but has a way of sending shares?
  96 2012-07-11 01:31:11 <doublec> and getting server information?
  97 2012-07-11 01:31:15 <luke-jr> doublec: an earlier draft had "submitblock", but people didn't like that :/
  98 2012-07-11 01:31:33 <sipa> it returns information on how to construct a block, based on the memory pool
  99 2012-07-11 01:31:35 <doublec> and backup servers?
 100 2012-07-11 01:31:41 <doublec> getmemorypool seems completely the wrong name
 101 2012-07-11 01:31:51 <sipa> it should be getmininginfo or something
 102 2012-07-11 01:32:06 <doublec> right
 103 2012-07-11 01:32:14 <sipa> that said, compatibility...
 104 2012-07-11 01:32:22 <sipa> we have getrawmemorypool now in git head
 105 2012-07-11 01:32:30 <luke-jr> getrawmemorypool was du,mb
 106 2012-07-11 01:32:36 <luke-jr> since BIP22 supports that
 107 2012-07-11 01:32:58 <sipa> the pull request doesn't, does it?
 108 2012-07-11 01:33:00 <luke-jr> no
 109 2012-07-11 01:33:15 <sipa> in that case i say scrap it from bip22, and have it be a separate call
 110 2012-07-11 01:33:19 <sipa> as its usage is very different
 111 2012-07-11 01:33:57 <doublec> why overload bip 22 with so much
 112 2012-07-11 01:34:03 <sipa> exactly
 113 2012-07-11 01:34:11 walruscode has joined
 114 2012-07-11 01:34:21 <doublec> split it out into different calls and it'll be much easier to get it accepted in bits
 115 2012-07-11 01:34:27 <walruscode> Anyone know how I can easily find the first block of the day, without checking the timestamp of every block, starting with the most recent one?
 116 2012-07-11 01:34:39 <doublec> it's almost like an rpc system inside of bitcoin's rpc
 117 2012-07-11 01:34:55 <luke-jr> bitcoind doesn't need to implement every use case
 118 2012-07-11 01:35:00 nimdAHK has joined
 119 2012-07-11 01:35:52 <doublec> " If the request parameters include a "mode" key, that is used to explicitly select between "template", "proposal", and "submit" calls. Otherwise, it defaults to a submission if there is a "data" key (including the String-type argument mentioned above), and a template request if not. "
 120 2012-07-11 01:35:57 <doublec> why not make those different rpc's for example
 121 2012-07-11 01:36:10 <luke-jr> doublec: because then bitcoind developers complain about too many RPC methods
 122 2012-07-11 01:36:23 <nimdAHK> walruscode: :/ I don't think there's a way currently. Write a script to do it for you :)
 123 2012-07-11 01:37:23 <doublec> what does getrawmemorypool do compared to getmemorypool?
 124 2012-07-11 01:37:29 <luke-jr> I'm tired of all the fence painting
 125 2012-07-11 01:37:30 <sipa> doublec: it gets the memory pool
 126 2012-07-11 01:37:32 <walruscode> nimdAHK: I'm doing just that. Do you think checking the blockchain, in order of descending block height, would be a good way of doing it?
 127 2012-07-11 01:37:48 <luke-jr> getrawmempool just does gmp({"sigoplimit":false, "sizelimit":false}) more or less
 128 2012-07-11 01:37:48 <nimdAHK> yes
 129 2012-07-11 01:38:03 <nimdAHK> make sure you account for the no-blocks-yet-today case
 130 2012-07-11 01:38:09 <doublec> luke-jr: I'm just saying that splitting it up into seperate calls is likely to make it easier to analyse, debug, use and get accepted
 131 2012-07-11 01:38:10 <sipa> doublec: instead of building a block using the block generation code, and then returning information about which transactions were included in it
 132 2012-07-11 01:38:25 <luke-jr> doublec: it's already in use
 133 2012-07-11 01:38:40 <walruscode> nimdAHK: thanks for your input :)
 134 2012-07-11 01:39:01 <doublec> luke-jr: "in use" doens't mean "easy to maintain, debug and understand"
 135 2012-07-11 01:39:06 <nimdAHK> walruscode: I'd be interested in the script when you finish it
 136 2012-07-11 01:39:11 <nimdAHK> what are you using, python?
 137 2012-07-11 01:39:14 <walruscode> yes
 138 2012-07-11 01:39:30 sgstair has quit (Read error: Connection reset by peer)
 139 2012-07-11 01:39:32 <walruscode> i'll pastebin it when i'm done
 140 2012-07-11 01:39:41 <luke-jr> doublec: well, single call or multiple is fence painting, and we already had to change it from multiple methods to overloaded-single-method for bitcoind developers
 141 2012-07-11 01:39:56 sgstair has joined
 142 2012-07-11 01:40:07 <luke-jr> I don't really care which way it is, but I'm not interested in endless back-and-forth over it
 143 2012-07-11 01:40:19 <sipa> my only complaint ever was that the BIP is too complex
 144 2012-07-11 01:40:25 Nesetalis has quit (Read error: Connection reset by peer)
 145 2012-07-11 01:40:31 <sipa> and i'm hesitant to start supporting it in that way
 146 2012-07-11 01:40:40 Nesetalis has joined
 147 2012-07-11 01:41:22 imsaguy2 has quit (Read error: Connection reset by peer)
 148 2012-07-11 01:41:33 <sipa> separate RPCs or not is indeed fence painting
 149 2012-07-11 01:41:34 <freewil> which BIP?
 150 2012-07-11 01:41:39 <sipa> 22
 151 2012-07-11 01:41:47 <luke-jr> sipa: what's too complex about gmp_bip branch (which is all that matters to bitcoind developers)?
 152 2012-07-11 01:42:03 <doublec> users of bip 22 need to understand it
 153 2012-07-11 01:42:16 <doublec> I had to read that sentence I pasted multiple times to understand it
 154 2012-07-11 01:42:29 <sipa> luke-jr: it brings support for BIP22, and i don't like BIP22
 155 2012-07-11 01:42:35 imsaguy2 has joined
 156 2012-07-11 01:42:51 <sipa> (that sounds wrong, i very much like the idea; i don't like the fact that it tries to do everything)
 157 2012-07-11 01:42:51 <copumpkin> anyone have any hints about what's special about the if family of opcodes?
 158 2012-07-11 01:42:56 <luke-jr> sipa: that's political power abuse then ;)
 159 2012-07-11 01:43:28 <doublec> what's the 'gmp' stand for?
 160 2012-07-11 01:43:36 <luke-jr> doublec: getmemorypool
 161 2012-07-11 01:43:37 <doublec> I keep thinking gnu multiprecision but I doubt that
 162 2012-07-11 01:43:42 <doublec> ah, oh course, thanks :)
 163 2012-07-11 01:44:04 <doublec> I was thinking "finally, no more floats"
 164 2012-07-11 01:44:18 <sipa> luke-jr: imho, client developers are the final judges about which proposals they choose their software to accept, no?
 165 2012-07-11 01:44:25 <luke-jr> doublec: there's already no floats. JSON has Numbers only.
 166 2012-07-11 01:44:41 <luke-jr> sipa: sure, but BIP22 isn't focussed on bitcoind
 167 2012-07-11 01:44:46 <luke-jr> sipa: it's focussed on poolservers
 168 2012-07-11 01:44:49 <sipa> sure, and it shouldn't be
 169 2012-07-11 01:45:09 pickett has joined
 170 2012-07-11 01:45:10 <luke-jr> if bitcoind only wants to implement a simple subset, that makes sense since it isn't a poolserver
 171 2012-07-11 01:45:20 <doublec> so make that subset the bip
 172 2012-07-11 01:45:30 <doublec> and implement the rest in the pool server or a proxy
 173 2012-07-11 01:45:34 <luke-jr> doublec: …
 174 2012-07-11 01:45:42 <sipa> that's not really how it could work
 175 2012-07-11 01:45:53 <luke-jr> doublec: the purpose of the BIP is to standardize the protocol; so a client-specific subset wouldn't be a BIP
 176 2012-07-11 01:46:27 <doublec> ok, maybe I'm misunderstanding. I thought bip 22 was a request to have that in bitcoind
 177 2012-07-11 01:46:38 <sipa> bip22 is the entire proposal
 178 2012-07-11 01:46:40 <luke-jr> doublec: no, gmp_bip is a limited subset of BIP22 intended for bitcoind
 179 2012-07-11 01:46:44 <doublec> ah ok
 180 2012-07-11 01:46:52 <luke-jr> doublec: BIP22 is between Eloipool/ecoinpool/PSJ/etc and miners
 181 2012-07-11 01:47:28 <luke-jr> bitcoind<->poolserver just uses a subset, but the full BIP is needed to support poolserver<->miner functionality
 182 2012-07-11 01:47:42 <sipa> i disagree that all of it is nedded
 183 2012-07-11 01:47:52 <sipa> *needed
 184 2012-07-11 01:48:03 <sipa> (though certainly more than what bitcoind would implement, and that is fine)
 185 2012-07-11 01:48:23 <luke-jr> sipa: because you aren't a developer of poolserver or mining software
 186 2012-07-11 01:49:35 <sipa> luke-jr: but without input from such people (apart from you yourself), i'll have to guess
 187 2012-07-11 01:49:57 rdponticelli has quit (Read error: Connection reset by peer)
 188 2012-07-11 01:50:07 sabayonuser2 is now known as dominoacid
 189 2012-07-11 01:50:09 <luke-jr> sipa: I already answered your questions on everything you asked about why it's needed
 190 2012-07-11 01:50:55 <sipa> yes, and my impression from that is that most of it is "this may be useful to someone"
 191 2012-07-11 01:51:13 <luke-jr> https://en.bitcoin.it/w/index.php?title=BIP_0022#Rationale
 192 2012-07-11 01:52:49 rdponticelli has joined
 193 2012-07-11 01:53:09 <sipa> just to be clear: i don't dispute the necessity of target, workid, sigops
 194 2012-07-11 01:54:26 <sipa> all the rest seems to be "in some cases", or provide different ways of doing the same thing
 195 2012-07-11 01:55:53 <luke-jr> pretty sure I removed all redundancy a few months ago
 196 2012-07-11 01:57:40 rdponticelli_ has joined
 197 2012-07-11 01:58:22 rdponticelli has quit (Ping timeout: 264 seconds)
 198 2012-07-11 01:59:06 <sipa> meh, three ways of representing the list of transactions, several options just for the coinbase, noncerange, several overlapping mutations, ...
 199 2012-07-11 01:59:51 <sipa> yes, just the txid list is the easiest if you just want to mine the block itself without varying anything
 200 2012-07-11 02:00:16 <sipa> and yes, in some cases you may want to see the full transactions being included (but there is gettransaction too)
 201 2012-07-11 02:00:40 <sipa> and yes, in some cases noncerange may be useful, but there are better solutions imho
 202 2012-07-11 02:00:57 <sipa> and yes, servers may be picky about what one may do with the coinbase
 203 2012-07-11 02:01:36 * sipa stops ranting and goes to bed
 204 2012-07-11 02:10:50 <copumpkin> that scriptSig field in http://snapplr.com/0cs1 isn't actually a script, right?
 205 2012-07-11 02:11:16 <copumpkin> in TxIn, that is
 206 2012-07-11 02:11:22 <sipa> it is
 207 2012-07-11 02:11:38 <sipa> but in every meaningful case, it only contains pushes
 208 2012-07-11 02:11:41 <copumpkin> oh okay
 209 2012-07-11 02:11:46 <copumpkin> cause I was only ever seeing pushes in it
 210 2012-07-11 02:11:56 <copumpkin> which doesn't seem very useful
 211 2012-07-11 02:12:24 <copumpkin> I'm seeing stuff like [[PushData "\255\255\NUL\GS",PushData "\223\NUL"]]
 212 2012-07-11 02:12:25 <TigrBot> http://en.wikipedia.org/wiki/PushData "\255\255\NUL\GS",PushData "\223\NUL"
 213 2012-07-11 02:12:37 <copumpkin> heh
 214 2012-07-11 02:13:43 <sipa> yes?
 215 2012-07-11 02:13:50 pickett has quit (Remote host closed the connection)
 216 2012-07-11 02:13:52 <copumpkin> does that seem legit?
 217 2012-07-11 02:13:58 <copumpkin> ignoring my fake opcode there
 218 2012-07-11 02:14:25 <sipa> not really
 219 2012-07-11 02:14:28 <luke-jr> copumpkin: also see BIP 18
 220 2012-07-11 02:14:29 <sipa> but it's not illegal
 221 2012-07-11 02:14:32 m00p has quit (Ping timeout: 252 seconds)
 222 2012-07-11 02:14:41 <BlueMatt> if ts coinbase it is
 223 2012-07-11 02:14:41 <copumpkin> sipa: these are the first blocks that I'm parsing
 224 2012-07-11 02:14:49 <BlueMatt> (seems legit)
 225 2012-07-11 02:15:01 <copumpkin> for the very first block, I have
 226 2012-07-11 02:15:02 <copumpkin> [[PushData "\255\255\NUL\GS",PushData "\EOT",PushData "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"]]
 227 2012-07-11 02:15:04 <TigrBot> http://en.wikipedia.org/wiki/PushData "\255\255\NUL\GS",PushData "\EOT",PushData "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
 228 2012-07-11 02:15:12 <BlueMatt> wtf is TigrBot?
 229 2012-07-11 02:15:28 <nimdAHK> a failed automatic arbitrage system
 230 2012-07-11 02:15:35 <nimdAHK> but this is the wrong channel for that
 231 2012-07-11 02:15:35 <sipa> copumpkin: oh, those are coinbases
 232 2012-07-11 02:15:45 <sipa> copumpkin: they just contain arbitrary data being pushed really
 233 2012-07-11 02:16:04 <copumpkin> okay, so the script isn't meant to be run in isolation, I assume?
 234 2012-07-11 02:16:07 <sipa> originally the difficulty bits and the extranonce
 235 2012-07-11 02:16:08 <copumpkin> or there's some implied other operation afterwards
 236 2012-07-11 02:16:18 <sipa> coinbase inputs aren't every executed
 237 2012-07-11 02:16:20 <sipa> *ever
 238 2012-07-11 02:16:22 <copumpkin> okay
 239 2012-07-11 02:16:50 <copumpkin> so, if I understand correctly, the inputs to a given transaction aren't directly available in the transaction structure, right? I need to be stateful and look the inputs up in a previous transaction by reference?
 240 2012-07-11 02:17:01 <sipa> yes
 241 2012-07-11 02:17:04 <copumpkin> :(
 242 2012-07-11 02:17:14 <copumpkin> oh well, makes sense I guess
 243 2012-07-11 02:17:16 moartr4dez has quit (Ping timeout: 276 seconds)
 244 2012-07-11 02:17:17 dvide has quit ()
 245 2012-07-11 02:17:22 <copumpkin> I was hoping to run in near-constant memory :)
 246 2012-07-11 02:17:34 <BlueMatt> prune
 247 2012-07-11 02:17:39 moartr4dez has joined
 248 2012-07-11 02:18:00 <copumpkin> how do I know that no future transaction will refer to a given transaction output?
 249 2012-07-11 02:18:13 <BlueMatt> if its spent, you can
 250 2012-07-11 02:18:14 <sipa> it cannot be spent twice
 251 2012-07-11 02:18:18 <copumpkin> oh, fair enough
 252 2012-07-11 02:18:28 <sipa> i've been working on my "ultraprune" branch that only retains (for not-fully spent tx's): height, whether it was a coinbase or not, and its unspent outputs
 253 2012-07-11 02:18:44 <sipa> with some clever encodings, that takes around 70 MB
 254 2012-07-11 02:19:12 <luke-jr> sipa: any reason not to collapse the first 2 by using height=-1 for non-coinbases txns?
 255 2012-07-11 02:19:58 <sipa> luke-jr: i originally did it that way, but that makes it impossible to keep the current mining algorithm (because you need to know the confirmation count of inputs)
 256 2012-07-11 02:20:12 <luke-jr> ah
 257 2012-07-11 02:20:14 <sipa> technically not needed to verify, but quite cheap, and adds functionality
 258 2012-07-11 02:21:37 pickett has joined
 259 2012-07-11 02:22:47 <sipa> almost everything is stored as base128 varints, so height is only 3 bytes for now (and will be for the coming 40 years)
 260 2012-07-11 02:24:01 TigrBot has joined
 261 2012-07-11 02:24:01 <TigrBot> jgarzik ... that was not very nice!
 262 2012-07-11 02:24:37 maaku has joined
 263 2012-07-11 02:24:53 <copumpkin> MrTiggr :O
 264 2012-07-11 02:27:19 <jgarzik> "so today i was completely wiped out by [SatoshiDice ...] after 75 consecutive losses i was wiped out, because i was placing relatively large bets. i have decided not to play this game any more.  "
 265 2012-07-11 02:27:35 <nimdAHK> lol
 266 2012-07-11 02:27:54 <[Tycho]> Smart decision.
 267 2012-07-11 02:29:38 <luke-jr> what was he expecting? :P
 268 2012-07-11 02:31:18 <walruscode> nimdAHK, I've run into a bit of a problem. You see, I'm writing the script to work with the Litecoin blockchain, but the litecoin daemon has no getblock method, it seems. /facepalm
 269 2012-07-11 02:31:28 <[Tycho]> A miracle.
 270 2012-07-11 02:31:33 <nimdAHK> :/
 271 2012-07-11 02:36:58 <gmaxwell> jgarzik: it still makes me sad!
 272 2012-07-11 02:46:19 <luke-jr> doublec: cjdns needs rebasing
 273 2012-07-11 02:50:17 ahbritto has joined
 274 2012-07-11 02:51:05 <doublec> luke-jr: yeah, I'll do that and address the pull comments soon
 275 2012-07-11 02:51:54 <doublec> for some reason I sometimes see two connections from my node running on cjdns
 276 2012-07-11 02:52:00 <doublec> but both are too one peer
 277 2012-07-11 02:52:06 <doublec> s/too/to
 278 2012-07-11 02:52:19 <doublec> I don't know why it's connecting to it twice
 279 2012-07-11 02:52:39 <doublec> or that peers connecting back to me maybe
 280 2012-07-11 02:53:23 CluckCreek has left ()
 281 2012-07-11 02:53:25 midnightmagic has quit (Quit: leaving)
 282 2012-07-11 02:53:40 guruvan has quit (Ping timeout: 276 seconds)
 283 2012-07-11 02:53:41 guruvan_ is now known as guruvan
 284 2012-07-11 02:54:19 gfinn has quit (Ping timeout: 276 seconds)
 285 2012-07-11 02:54:39 guruvan_ has joined
 286 2012-07-11 02:55:37 moartr4dez has quit (Ping timeout: 276 seconds)
 287 2012-07-11 02:55:45 m00p has joined
 288 2012-07-11 02:55:55 moartr4dez has joined
 289 2012-07-11 02:56:29 midnightmagic has joined
 290 2012-07-11 02:57:23 TheSeven has quit (Disconnected by services)
 291 2012-07-11 02:57:33 [7] has joined
 292 2012-07-11 02:57:43 paraipan has quit (Quit: Saliendo)
 293 2012-07-11 02:59:55 sytse has quit (Read error: Operation timed out)
 294 2012-07-11 03:02:57 gfinn has joined
 295 2012-07-11 03:04:28 osmosis has quit (Remote host closed the connection)
 296 2012-07-11 03:08:57 Z0rZ0rZ0r has quit (Ping timeout: 265 seconds)
 297 2012-07-11 03:10:10 Z0rZ0rZ0r has joined
 298 2012-07-11 03:13:22 Motest003 has quit (Ping timeout: 246 seconds)
 299 2012-07-11 03:13:56 eoss has quit (Remote host closed the connection)
 300 2012-07-11 03:14:04 sytse has joined
 301 2012-07-11 03:14:12 Motest003 has joined
 302 2012-07-11 03:14:37 <nimdAHK> hodamn what a spam
 303 2012-07-11 03:15:00 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
 304 2012-07-11 03:16:38 egecko has joined
 305 2012-07-11 03:16:56 ledao has quit (Quit: Leaving.)
 306 2012-07-11 03:19:54 nimdAHK is now known as nimdAHK|away
 307 2012-07-11 03:20:34 rdponticelli_ has quit (Ping timeout: 264 seconds)
 308 2012-07-11 03:30:09 RainbowDashh has joined
 309 2012-07-11 03:31:51 RainbowDashh is now known as rainbowDashh
 310 2012-07-11 03:37:52 darkee has quit (Ping timeout: 276 seconds)
 311 2012-07-11 03:38:01 <Karmaon> nimdAHK spam?
 312 2012-07-11 03:38:22 <Karmaon> You mean the connect/disconnect messages?
 313 2012-07-11 03:38:32 rainbowDashh has quit (Quit: SLEEP MODE. I NEED A MORE CREATIVE MESSAGE FOR MY DUMB LID CLOSING.)
 314 2012-07-11 03:41:52 darkee has joined
 315 2012-07-11 03:46:19 RainbowDashh has joined
 316 2012-07-11 03:47:20 elkingrey has quit (Quit: Leaving)
 317 2012-07-11 03:47:23 RainbowDashh has quit (Client Quit)
 318 2012-07-11 03:56:56 eoss has joined
 319 2012-07-11 03:56:56 eoss has quit (Changing host)
 320 2012-07-11 03:56:56 eoss has joined
 321 2012-07-11 03:57:17 leotreasure has joined
 322 2012-07-11 04:07:24 RainbowDashh has joined
 323 2012-07-11 04:13:10 RainbowDashh has quit (Quit: SLEEP MODE. I NEED A MORE CREATIVE MESSAGE FOR MY DUMB LID CLOSING.)
 324 2012-07-11 04:31:05 RainbowDashh has joined
 325 2012-07-11 04:45:03 eoss has quit (Remote host closed the connection)
 326 2012-07-11 04:46:05 dominoacid has quit (Read error: Connection reset by peer)
 327 2012-07-11 04:46:19 osmosis has joined
 328 2012-07-11 04:58:46 <amiller> hell yeah, i just worked out an O(N^2 * D * k) solution for bitcoin parameters
 329 2012-07-11 04:59:09 <amiller> i think that's what i thought i could get before, but i finally made it from start to finish with math
 330 2012-07-11 05:00:45 RainbowDashh has quit (Quit: QUIT! Accident or on purpose? :3)
 331 2012-07-11 05:00:47 <amiller> the N means that the advantage of the network is 1/2 (1 + 1/N), so for example 51% is N=50
 332 2012-07-11 05:02:12 <amiller> the D is the message delay, like a communications radius, where a block gets propagated to everyone within D seconds or w/e
 333 2012-07-11 05:04:22 <luke-jr> amiller: try minutes
 334 2012-07-11 05:04:37 <amiller> w/evs
 335 2012-07-11 05:05:14 D34TH has quit (Quit: Leaving)
 336 2012-07-11 05:06:10 <gmaxwell> luke-jr: the units don't matter of course.
 337 2012-07-11 05:06:29 <luke-jr> maybe. I wasn't following what amiller was doing.
 338 2012-07-11 05:06:46 <gmaxwell> making a proof under what conditions bitcoin will converge to the majority consensus.
 339 2012-07-11 05:07:48 <gmaxwell> (in the face of some badguys)
 340 2012-07-11 05:14:56 variousnefarious has quit (Quit: No Ping reply in 180 seconds.)
 341 2012-07-11 05:15:38 variousnefarious has joined
 342 2012-07-11 05:20:08 variousnefarious has quit (Ping timeout: 245 seconds)
 343 2012-07-11 05:28:09 unknown45682 has quit ()
 344 2012-07-11 05:33:33 RazielZ has joined
 345 2012-07-11 05:35:10 RazielZ has quit (Client Quit)
 346 2012-07-11 05:35:26 <midnightmagic> hey I wonder if the magic word still works..
 347 2012-07-11 05:35:50 <midnightmagic> amiller: do you have something we can read up somewhere?
 348 2012-07-11 05:36:01 <midnightmagic> maybe it's time to try using the magic word again..
 349 2012-07-11 05:36:40 <amiller> not yet, gotta run through it a few more times
 350 2012-07-11 05:36:57 <midnightmagic> raouaw
 351 2012-07-11 05:37:02 RazielZ has joined
 352 2012-07-11 05:37:04 <midnightmagic> lol
 353 2012-07-11 05:37:06 <amiller> gonna submit this shit to a conference, if i don't break down in tears in the next few days if it's broken
 354 2012-07-11 05:38:46 <midnightmagic> in case anybody's curious, for about 6 months from Nov '10 onwards, anytime someone would mention ra oul's nickname he'd suddenly join the channel and answer questions. it was like rubbing a magic lamp, it was great.
 355 2012-07-11 05:38:53 <amiller> i'm providing a lower bound for the longest chain miners know about, even accounting for the delay
 356 2012-07-11 05:39:10 <amiller> that lower bound is more than half the upper bound for the total number of blocks anyone could have found
 357 2012-07-11 05:39:26 <amiller> hence, there is a unique longest chain that every miner knows about
 358 2012-07-11 05:40:08 <amiller> i'm modeling this lower bound as a simple random process, it's alternating phases of waiting for a block to arrive, and then just skipping over the message delay
 359 2012-07-11 05:40:22 <amiller> the upper bound for the total number of blocks is just a normal poisson process
 360 2012-07-11 05:44:47 <midnightmagic> very awesome. :)
 361 2012-07-11 05:46:22 maaku has quit (Quit: maaku)
 362 2012-07-11 05:46:55 maaku has joined
 363 2012-07-11 05:47:24 TD has joined
 364 2012-07-11 05:49:04 RainbowDashh has joined
 365 2012-07-11 05:51:50 twobitcoins has quit (Ping timeout: 265 seconds)
 366 2012-07-11 06:02:24 brwyatt is now known as brwyatt|Away
 367 2012-07-11 06:03:08 sytse has quit (Ping timeout: 248 seconds)
 368 2012-07-11 06:05:36 Apexseals has quit (Ping timeout: 260 seconds)
 369 2012-07-11 06:08:59 ovidiusoft has joined
 370 2012-07-11 06:10:09 sytse has joined
 371 2012-07-11 06:12:57 ovidiusoft has quit (Read error: Connection reset by peer)
 372 2012-07-11 06:13:21 ovidiusoft has joined
 373 2012-07-11 06:41:31 CodesInChaos has joined
 374 2012-07-11 06:43:08 osmosis has quit (Quit: Leaving)
 375 2012-07-11 06:45:26 twobitcoins has joined
 376 2012-07-11 06:56:21 osxorgate has joined
 377 2012-07-11 07:03:51 Lolcust has quit (Quit: Nap time)
 378 2012-07-11 07:04:59 maaku has quit (Quit: maaku)
 379 2012-07-11 07:05:24 CodesInChaos has quit (Ping timeout: 246 seconds)
 380 2012-07-11 07:06:57 Lolcust has joined
 381 2012-07-11 07:07:42 Marf has joined
 382 2012-07-11 07:09:07 RainbowDashh is now known as RainbowDashh|awa
 383 2012-07-11 07:09:11 RainbowDashh is now known as awa!~Rabbit678@unaffiliated/rainbowdashh|RainbowDashh|afk
 384 2012-07-11 07:10:55 sirk390 has joined
 385 2012-07-11 07:11:14 RainbowDashh is now known as afk!~Rabbit678@unaffiliated/rainbowdashh|RainbowDashh
 386 2012-07-11 07:15:42 TD has quit (Quit: TD)
 387 2012-07-11 07:17:17 molecular has quit (Ping timeout: 244 seconds)
 388 2012-07-11 07:21:48 galambo__ has quit (Read error: Connection reset by peer)
 389 2012-07-11 07:24:12 darkee has quit (Remote host closed the connection)
 390 2012-07-11 07:24:49 darkee has joined
 391 2012-07-11 07:25:02 Lolcust has quit (Ping timeout: 244 seconds)
 392 2012-07-11 07:27:14 CodesInChaos has joined
 393 2012-07-11 07:29:16 molecular has joined
 394 2012-07-11 07:32:58 unknown45682 has joined
 395 2012-07-11 07:33:37 Lolcust has joined
 396 2012-07-11 07:42:54 sirk390 has quit (Quit: Leaving.)
 397 2012-07-11 07:51:56 maaku has joined
 398 2012-07-11 08:00:28 mmoya has joined
 399 2012-07-11 08:09:42 iso1 has joined
 400 2012-07-11 08:09:53 TD_ has joined
 401 2012-07-11 08:21:56 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
 402 2012-07-11 08:22:47 wasabi1 has quit (Read error: Connection reset by peer)
 403 2012-07-11 08:27:20 leotreasure_ has joined
 404 2012-07-11 08:28:42 ivan\ has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
 405 2012-07-11 08:30:51 leotreasure has quit (Ping timeout: 265 seconds)
 406 2012-07-11 08:30:52 leotreasure_ is now known as leotreasure
 407 2012-07-11 08:46:15 da2ce7 has quit (Read error: Connection reset by peer)
 408 2012-07-11 08:46:22 gavinandresen has quit (Ping timeout: 264 seconds)
 409 2012-07-11 08:49:00 da2ce716 has joined
 410 2012-07-11 08:50:56 gavinandresen has joined
 411 2012-07-11 08:52:32 <gribble> New news from bitcoinrss: luke-jr opened issue 1579 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1579>
 412 2012-07-11 09:00:11 PiZZaMaN2K has quit (Read error: Connection reset by peer)
 413 2012-07-11 09:02:02 Apexseals has joined
 414 2012-07-11 09:04:18 sytse has quit (Ping timeout: 245 seconds)
 415 2012-07-11 09:04:29 ivan\ has joined
 416 2012-07-11 09:05:07 toffoo has quit ()
 417 2012-07-11 09:06:38 leotreasure has quit (Quit: leotreasure)
 418 2012-07-11 09:11:22 sytse has joined
 419 2012-07-11 09:12:32 one_zero has quit (Ping timeout: 244 seconds)
 420 2012-07-11 09:12:57 Cryo has joined
 421 2012-07-11 09:16:25 datagutt has joined
 422 2012-07-11 09:23:21 wasabi has quit (Read error: Connection reset by peer)
 423 2012-07-11 09:30:54 sgornick has quit (Ping timeout: 240 seconds)
 424 2012-07-11 09:31:34 PiZZaMaN2K has joined
 425 2012-07-11 09:38:29 phantomcircuit has quit (Ping timeout: 248 seconds)
 426 2012-07-11 09:44:36 phantomcircuit has joined
 427 2012-07-11 09:45:37 PiZZaMaN2K has quit (Quit: Linkinus - http://linkinus.com)
 428 2012-07-11 09:46:00 one_zero has joined
 429 2012-07-11 09:48:22 moop has joined
 430 2012-07-11 09:51:46 m00p has quit (Ping timeout: 264 seconds)
 431 2012-07-11 09:52:09 Turingi has joined
 432 2012-07-11 09:52:10 Turingi has quit (Changing host)
 433 2012-07-11 09:52:10 Turingi has joined
 434 2012-07-11 09:59:07 ThomasV has joined
 435 2012-07-11 10:08:49 RainbowDashh has quit (Quit: SLEEP MODE. I NEED A MORE CREATIVE MESSAGE FOR MY DUMB LID CLOSING.)
 436 2012-07-11 10:13:23 drizztbsd has joined
 437 2012-07-11 10:14:35 Clipse has quit (Ping timeout: 264 seconds)
 438 2012-07-11 10:20:00 one_zero has quit ()
 439 2012-07-11 10:24:12 Clipse has joined
 440 2012-07-11 10:33:03 one_zero has joined
 441 2012-07-11 10:37:47 MobiusL has quit (Ping timeout: 276 seconds)
 442 2012-07-11 10:48:03 dlb76 has quit (Ping timeout: 245 seconds)
 443 2012-07-11 10:50:02 MobiusL has joined
 444 2012-07-11 11:21:10 one_zero has quit ()
 445 2012-07-11 11:33:47 coingenuity has quit (Ping timeout: 264 seconds)
 446 2012-07-11 11:39:10 p0s has joined
 447 2012-07-11 11:40:27 <yellowhat> did anyone of the devs get a notice from Jacob Appelbaum? http://twitter.com/ioerror/status/78480502641803264
 448 2012-07-11 11:41:00 <yellowhat> Jacob Appelbaum - @ioerror - Bitcoin prediction: Major bugs in the near future will mess with the "market"
 449 2012-07-11 11:41:34 <yellowhat> @ioerror Bitcoin prediction seem to become en vogue. Have any particular bug in mind?
 450 2012-07-11 11:41:36 <yellowhat> @ioerrorandreasdotorg Yes. :-)
 451 2012-07-11 11:41:36 <jeremias> ounds like FUD to me, until further information is given
 452 2012-07-11 11:41:54 <yellowhat> jacob appelbaum is a serious guy i would not rule it out
 453 2012-07-11 11:42:05 <yellowhat> he is a good guy (TM)
 454 2012-07-11 11:42:33 coingenuity has joined
 455 2012-07-11 11:42:44 <jeremias> well, I don't care if he is a good guy or not, just spreading messages like that without any details is annoying
 456 2012-07-11 11:43:49 <yellowhat> maybe he is waiting for gavin to contact him privately?
 457 2012-07-11 11:44:54 <cccp> isnt that tweet 13 months old?
 458 2012-07-11 11:45:20 rdponticelli has joined
 459 2012-07-11 11:45:21 <yellowhat> he is the lead TOR developer, so he shoud know what he is talking about
 460 2012-07-11 11:45:25 <yellowhat> ahh
 461 2012-07-11 11:45:35 <yellowhat> you are right 11 months old ...
 462 2012-07-11 11:45:40 <sipa> iirc gavin contacted him about back then
 463 2012-07-11 11:45:48 <yellowhat> 13 to be correct like your
 464 2012-07-11 11:46:08 <yellowhat> just forget everything i wrote then
 465 2012-07-11 11:48:19 <gribble> New news from bitcoinrss: laanwj opened pull request 1580 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1580>
 466 2012-07-11 11:50:36 ThomasV has quit (Quit: Leaving)
 467 2012-07-11 11:51:00 ThomasV has joined
 468 2012-07-11 11:56:54 agricocb has quit (Quit: Leaving.)
 469 2012-07-11 12:07:58 egecko has joined
 470 2012-07-11 12:18:34 <gribble> New news from bitcoinrss: laanwj opened pull request 1582 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1582> || Diapolo opened pull request 1581 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1581>
 471 2012-07-11 12:19:23 Diablo-D3 has joined
 472 2012-07-11 12:20:30 dvide has joined
 473 2012-07-11 12:28:02 agricocb has joined
 474 2012-07-11 12:37:07 osxorgat_ has joined
 475 2012-07-11 12:39:49 osxorgate has quit (Ping timeout: 248 seconds)
 476 2012-07-11 12:43:36 minimoose has joined
 477 2012-07-11 12:46:14 sytse has quit (Read error: Operation timed out)
 478 2012-07-11 12:53:18 ThomasV has quit (Quit: Leaving)
 479 2012-07-11 12:56:15 sytse has joined
 480 2012-07-11 12:59:12 moop has quit (Quit: Leaving)
 481 2012-07-11 12:59:14 wasabi1 has joined
 482 2012-07-11 13:00:25 Raziel_ has joined
 483 2012-07-11 13:01:32 paraipan has joined
 484 2012-07-11 13:02:42 Z0rZ0rZ0r has quit (Quit: Leaving)
 485 2012-07-11 13:03:46 RazielZ has quit (Ping timeout: 246 seconds)
 486 2012-07-11 13:04:40 wasabi2 has joined
 487 2012-07-11 13:06:32 ThomasV has joined
 488 2012-07-11 13:11:29 <helo> 'mess with the "market"' sounds like a prediction of problems with exchanges
 489 2012-07-11 13:11:52 dvide_ has joined
 490 2012-07-11 13:14:34 m00p has joined
 491 2012-07-11 13:15:47 dvide has quit (Ping timeout: 264 seconds)
 492 2012-07-11 13:40:59 tower has quit (Ping timeout: 264 seconds)
 493 2012-07-11 13:45:40 tower has joined
 494 2012-07-11 13:50:21 copumpkin has quit (Quit: Computer has gone to sleep.)
 495 2012-07-11 13:55:42 yellowhat has quit (Remote host closed the connection)
 496 2012-07-11 13:56:13 rdponticelli_ has joined
 497 2012-07-11 13:56:30 rdponticelli has quit (Ping timeout: 245 seconds)
 498 2012-07-11 14:00:33 <jgarzik> whee, got a blk0002.dat here
 499 2012-07-11 14:00:47 <kinlo> everybody does :)
 500 2012-07-11 14:00:54 <jgarzik> time to start distributing a canonical blk0001.dat via torrent
 501 2012-07-11 14:01:15 <jgarzik> rather than burdening the DNS seed-listed nodes with a heavy block download burden
 502 2012-07-11 14:02:31 rdponticelli_ has quit (Read error: Connection reset by peer)
 503 2012-07-11 14:03:06 <kinlo> aren't the dns seeded nodes just random nodes with high uptime, hence always different ones?
 504 2012-07-11 14:04:19 <jgarzik> kinlo: no
 505 2012-07-11 14:04:37 rdponticelli has joined
 506 2012-07-11 14:04:50 <kinlo> dns seeding doesn't allow different ports either I assume
 507 2012-07-11 14:04:55 <jgarzik> kinlo: that's only 100% true for sipa's seed.  others like bitseed.xf2.org are taken from the wiki list of fallback nodes, and are largely static.
 508 2012-07-11 14:05:08 <kinlo> ic
 509 2012-07-11 14:05:47 <jgarzik> kinlo: but even so, BitcoinJ exclusively connects to DNS seed-returned nodes, and no other.  And Bitcoin's Initial Block Download (IBD) logic winds up defaulting to download from the first well connected remote P2P node.
 510 2012-07-11 14:06:04 <kinlo> ic
 511 2012-07-11 14:06:06 <jgarzik> thus heaping more work on seed-listed nodes, rather than other listening nodes on the P2P network
 512 2012-07-11 14:06:36 <jgarzik> the initial block download, in particular, always downloads the same data, making it a prime torrent candidate IMO
 513 2012-07-11 14:07:01 <kinlo> in any case, we might should enforce bitcoin not being able to start without an existing blockchain, forcing people to download a bootstrap chain
 514 2012-07-11 14:07:47 <jgarzik> ...as long as you validate the download somehow, sure
 515 2012-07-11 14:08:59 <sipa> you mean download via torrent, to be fed to loadblock or similar?
 516 2012-07-11 14:09:03 <kinlo> should it be?
 517 2012-07-11 14:09:05 <gavinandresen> I nominate kinlo to pay for hosting blk0001.dat
 518 2012-07-11 14:09:19 copumpkin has joined
 519 2012-07-11 14:09:37 <kinlo> jgarzik: imagine that someone gives you an invalid blk0001.dat, your client will still verify it, no?
 520 2012-07-11 14:09:52 <kinlo> jgarzik: given that you do not just load it as is, but fully verify it
 521 2012-07-11 14:10:13 <kinlo> gavinandresen: depending on the bandwith, I might be able to arrange something, I work at an isp...
 522 2012-07-11 14:10:19 <jgarzik> kinlo: -loadblock verifies, yes
 523 2012-07-11 14:10:27 <jgarzik> sipa: yes
 524 2012-07-11 14:10:36 <sipa> btw, separating the block info and coin info has another nice advantage: remove the coindb, and all that happens is a reconnect
 525 2012-07-11 14:10:41 <kinlo> jgarzik: the bootstrap should do somethng like loadblock...
 526 2012-07-11 14:10:52 <jgarzik> kinlo: it already does (over the network)
 527 2012-07-11 14:11:05 <sipa> no new block files created, or new indexes to be created
 528 2012-07-11 14:11:17 <jgarzik> the point is to do it over torrent or other instead, while still verifying
 529 2012-07-11 14:11:30 <gavinandresen> last time we talked about this, the conclusion was there was no real advantage to using torrent versus just asking peers to download
 530 2012-07-11 14:11:39 <kinlo> gavinandresen: in the end, the current dnsseeds seem to be doing the hosting of those files already, so I don't see it to be that expensive in bandwith
 531 2012-07-11 14:11:40 <gavinandresen> if we can do a better job of asking peers, then cool
 532 2012-07-11 14:12:23 <gavinandresen> on a meta level, I'm very "meh" -- since in the medium-term-run only solo miners and pools will need the full chain
 533 2012-07-11 14:12:26 <kinlo> gavinandresen: what about the idea of forcing a client to request the user of a blockchain if the current datadir is empty?
 534 2012-07-11 14:12:43 <gavinandresen> kinlo: meh
 535 2012-07-11 14:13:08 <gavinandresen> what problem are y'all trying to solve?
 536 2012-07-11 14:13:50 <kinlo> just answering jgarzik's question about distributing the blockchain
 537 2012-07-11 14:14:03 <BlueMatt> jgarzik: I was under the impression that was 100% for every one /but/ yours
 538 2012-07-11 14:14:30 <jgarzik> bitcoin P2P protocol is a poor substitute for a real file transfer protocol.  Sure, we can import all the useful file transfer heuristics into bitcoin, for better peer selection
 539 2012-07-11 14:14:50 <BlueMatt> do we get a blk0002.dat when -loadblock'ing, or just with a few orphans in blk0001.dat?
 540 2012-07-11 14:14:55 <jgarzik> the bigger the blockchain, the more the protocol use segments into (a) bulk chain downloads and (b) everything else
 541 2012-07-11 14:15:33 <jgarzik> it's a mess for server profiling and long term planning
 542 2012-07-11 14:15:44 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
 543 2012-07-11 14:15:57 T_X has quit (Ping timeout: 248 seconds)
 544 2012-07-11 14:15:57 <gavinandresen> jgarzik: the problem is difficulty in predicting server bandwidth?
 545 2012-07-11 14:15:58 <jgarzik> BlueMatt: natural chain spills over into blk0002.dat now
 546 2012-07-11 14:16:00 <BlueMatt> jgarzik: anyway, I still disagree that just distributing blk0001.dat is the way to go...obvious optimizations to the way bitcoin does ibd could get the same effect without having to
 547 2012-07-11 14:16:20 <sipa> i figure there will be verification nodes and archival servers in the long term
 548 2012-07-11 14:16:23 <jgarzik> BlueMatt: ...thus reinventing bittorrent, but poorly
 549 2012-07-11 14:16:44 <jgarzik> BlueMatt: once you have all its IP ToS optimizations, peer selection optimizations, etc.
 550 2012-07-11 14:17:21 <BlueMatt> who cares? its not the the bottleneck, and using it over bittorrent blk0001.dat would have only a minor bandwidth cost over bittorrent
 551 2012-07-11 14:17:24 <jgarzik> "good peers for blockchain download " will be a shrinking set of total nodes, and selection becomes ever more important
 552 2012-07-11 14:17:38 <BlueMatt> and just the really obvious and simple optimizations would give it the same result
 553 2012-07-11 14:17:48 <BlueMatt> no need for IP ToS stuff, or getting nearly as fancy as bittorrent
 554 2012-07-11 14:18:03 <jgarzik> BlueMatt: it matters if you observe the impact DNS seeds inflict upon public nodes
 555 2012-07-11 14:18:08 <gmaxwell> The blockchain download should be in the background in any case, so it shouldn't be time critical.
 556 2012-07-11 14:18:23 hnz has quit (Ping timeout: 265 seconds)
 557 2012-07-11 14:18:41 <gmaxwell> It can't be done in the background if you're depending on the user torrenting some multigigabyte file before they start.
 558 2012-07-11 14:18:43 <BlueMatt> jgarzik: thats my point, just downloading blocks from all 8 peers during ibd would get rid of most of that impact
 559 2012-07-11 14:18:44 <jgarzik> gmaxwell: not true from user's PoV...  they are waiting to use the problem.
 560 2012-07-11 14:19:37 <jgarzik> gmaxwell: *program
 561 2012-07-11 14:19:37 <gavinandresen> again, I think we need to figure out what problem(s) we want to solve.  User experience won't be helped by switching to a torrent download
 562 2012-07-11 14:19:39 <gmaxwell> jgarzik: You don't have to have the whole chain to use the software. The node could bootstrap as SPV, fetching headers first.
 563 2012-07-11 14:19:44 <BlueMatt> simple, obvious optimizations that we should do anyway that will get the same result without forcing people to go download a blk0001.dat file to get started (which is horrible for users, btw): download blocks from all peers, thread/buffer blocks, done
 564 2012-07-11 14:20:02 <gavinandresen> I'm not sure server usage would, either, unless we ship a full bittorrent client
 565 2012-07-11 14:20:17 <gmaxwell> (sorry I'm just tuning into this discussion, forgive me if I repeated something already said)
 566 2012-07-11 14:20:37 ThomasV has quit (Quit: Leaving)
 567 2012-07-11 14:20:37 <jgarzik> Idelaly users would see a rapid download (hopefully with progress bar), then a rapid import (hopefully with progress bar), then immediate live network access.
 568 2012-07-11 14:20:42 <jgarzik> *Ideally
 569 2012-07-11 14:20:53 <BlueMatt> jgarzik: yep, and bittorrent wont speed any of those bars up
 570 2012-07-11 14:20:56 <gavinandresen> sure, that should be pretty easy, headers first then backfill....
 571 2012-07-11 14:21:09 <jgarzik> BlueMatt: over today's client, yes it will
 572 2012-07-11 14:21:27 <gmaxwell> jgarzik: "rapid download" .. how rapidly will you download 50 GBytes?
 573 2012-07-11 14:21:33 <gavinandresen> if we get bloom filters (hint hint) then do SPV stuff and fetch full blocks in the background....
 574 2012-07-11 14:21:34 <BlueMatt> jgarzik: again, implementing bittorrent would be more effort than just solving the underlying issues
 575 2012-07-11 14:22:05 <gmaxwell> gavinandresen: the bitcoinj stuff make a useful optimization which is that a new wallet knows there will be no transactions for it before the height at which it was created.
 576 2012-07-11 14:22:20 <BlueMatt> jgarzik: I just feel like you are working around an issue that has low-hanging fruit optimizations that would solve the issue itself
 577 2012-07-11 14:22:21 <jgarzik> gmaxwell: bittorrent peer selection hunts for fast peers.  we don't.  the obvious result occurs.  :)
 578 2012-07-11 14:22:26 <gmaxwell> gavinandresen: so it never even bothers downloading the blocks before that heigh... For a fullnode + wallet it means those could come last.
 579 2012-07-11 14:22:34 <gavinandresen> gmaxwell: yup
 580 2012-07-11 14:22:47 hnz has joined
 581 2012-07-11 14:22:58 <BlueMatt> jgarzik: bandwidth is very far from the problem, just one peer with 100k upload would be just fine for block download
 582 2012-07-11 14:23:05 <gavinandresen> jgarzik: but unless you're a very impatient solo miner, you shouldn't need the full blockchain at all
 583 2012-07-11 14:23:55 <jgarzik> gavinandresen: today's bitcoin-qt users need the full blockchain...  and they are impatient enough to continue complaining on the forums.
 584 2012-07-11 14:23:58 <gmaxwell> jgarzik: Yea, you're not following my point. :)  Even if you have _perfect_ transfer, 50 gigs is going to take 1.2 hours over a 100mbit/s link at line rate.
 585 2012-07-11 14:24:03 <jgarzik> BlueMatt: running several public nodes, I disagree
 586 2012-07-11 14:24:16 <sipa> i think it woulfmd not be hard to have a shipped blockchain with ultraprune, which is imported at first startup
 587 2012-07-11 14:24:25 <jgarzik> BlueMatt: if you judge from log lines, they spend the majority of their time shoveling blocks
 588 2012-07-11 14:24:31 <jgarzik> and bandwidth usage
 589 2012-07-11 14:24:37 <BlueMatt> jgarzik: yep, because we dont thread/buffer blocks
 590 2012-07-11 14:24:48 <gavinandresen> jgarzik: right... but I think if we switch to IBD via bittorrent then we'd just swap those complaints with a whole 'nother set of complaints
 591 2012-07-11 14:24:54 <BlueMatt> jgarzik: if you do that, you can spend most of your time in block checking on tmpfs with just 10m down
 592 2012-07-11 14:24:57 <jgarzik> gmaxwell: yes, agreed
 593 2012-07-11 14:25:39 <gmaxwell> jgarzik: which means for user expirence just changing download mechnism isn't sufficient. We need to get that download of historical data into the background. And once it is simple factors of two probably don't matter much.
 594 2012-07-11 14:25:53 <jgarzik> gavinandresen: perhaps, but x<y.  it eliminates slow downloads, bad peer choice, and public node punishment.
 595 2012-07-11 14:26:13 <gavinandresen> Shipping a "bitcoin starter" that is a 3GB download, blockchain snapshot included, seems like the easiest/quickest short-term fix.  I'm ok with that, as long as somebody else pays the bandwidth costs.
 596 2012-07-11 14:26:36 <BlueMatt> gavinandresen: shipping a bitcoin starter that is 100m would be better ;)
 597 2012-07-11 14:26:47 <gavinandresen> BlueMatt: agreed
 598 2012-07-11 14:26:59 <gmaxwell> jgarzik: As mentioned before, I'm seeing no evidence of public node punishment here, and my nodes are returned by sipa's seeder at least. Perhaps you should make your dnsseed list non-static.
 599 2012-07-11 14:27:14 PiZZaMaN2K has joined
 600 2012-07-11 14:27:17 <gavinandresen> BlueMatt: the work would be all installer/packaging, which should be reusable for whatever starting state you want to ship
 601 2012-07-11 14:27:54 <BlueMatt> gavinandresen: yep...
 602 2012-07-11 14:28:20 <jgarzik> gmaxwell: that just makes the problems more difficult to measure
 603 2012-07-11 14:28:24 <jgarzik> e.g. burying head in sand
 604 2012-07-11 14:28:49 <gavinandresen> I agree with gmaxwell: if the problem is some seeds getting hammered because of a static DNS list....
 605 2012-07-11 14:29:20 <gmaxwell> And also because nodes pull only from the first node they connect to.
 606 2012-07-11 14:29:28 <jgarzik> which is a major problem
 607 2012-07-11 14:29:28 <gavinandresen> that one would be easy to fix
 608 2012-07-11 14:29:41 <gavinandresen> (famous last words)
 609 2012-07-11 14:30:14 <jgarzik> gavinandresen: yes, I had thought about that as a possible solution:  separate program which torrents the block chain, indexes, then executes bitcoin-qt.
 610 2012-07-11 14:30:23 <BlueMatt> jgarzik: one other thing, as of 0.7, we give users an easy way to import blk0001.dat, and tcatm already (graciously) hosts chain snaps, so maybe we could link to his site to download snaps if people want the import to go faster
 611 2012-07-11 14:30:51 <gmaxwell> The pulling behavior has other negative consequences.. if you first connect to a broken node you won't start pulling for real until the next block (perhaps an half hour later!)
 612 2012-07-11 14:31:08 gfinn has quit (Ping timeout: 276 seconds)
 613 2012-07-11 14:32:07 <gmaxwell> BlueMatt: yea, the fact that we have import is good. Though... perhaps loadblock needs a rpc call or even a file->open_blockfile. 0_o because asking people to change commandline parameters isn't exactly user friendly.
 614 2012-07-11 14:32:27 <BlueMatt> yea, that would be nice
 615 2012-07-11 14:32:48 gfinn has joined
 616 2012-07-11 14:33:15 <BlueMatt> (also, loadblock that downloads from a url and imports as it downloads would be cool, but thats potentially another lib...
 617 2012-07-11 14:33:16 <gavinandresen> how about:  if there are blk????.dat files in the executable's directory, automagically -loadblock them
 618 2012-07-11 14:33:26 <gavinandresen> (command line switch to disable for us geeks)
 619 2012-07-11 14:33:43 <BlueMatt> gavinandresen: I was looking at that for a checkpoints file, and it gets pretty ugly
 620 2012-07-11 14:34:01 <jgarzik> well
 621 2012-07-11 14:34:14 <jgarzik> do we mean -loadblock or -justreindex ?
 622 2012-07-11 14:34:21 <BlueMatt> (have to have specific code per os to figure out what dir your exe is in to begin with, and Ive never seen any version for bsd/other not very standard oses)
 623 2012-07-11 14:34:31 <jgarzik> -loadblock creates a duplicate blk0001.dat essentially
 624 2012-07-11 14:34:47 <gavinandresen> BlueMatt: I thought boost::filesystem had a call to figure that out, might be misremembering though
 625 2012-07-11 14:35:01 <BlueMatt> I didnt see one, but I may have missed it
 626 2012-07-11 14:35:04 <BlueMatt> I only know qt has one
 627 2012-07-11 14:35:06 <gmaxwell> jgarzik: yes, and if you're so short on space that this is a major problem.. then you're going to be hosed in N months in any case.
 628 2012-07-11 14:35:33 <gmaxwell> With a file->load blocks there could be a checked by default [delete when done].
 629 2012-07-11 14:35:36 <gavinandresen> Users won't know where to put a downloaded blk*.dat, won't know how to create the -datadir, etc
 630 2012-07-11 14:36:01 <BlueMatt> gavinandresen: yea file->load block file url would be nice
 631 2012-07-11 14:36:05 <jgarzik> gmaxwell: just pointing it out a fact, in case it wasn't obvious.  previously, some devs occasionally assumed -loadblock only indexed, if $datadir/blk0001.dat was being imported.
 632 2012-07-11 14:36:12 <jgarzik> which is not true
 633 2012-07-11 14:36:27 <jgarzik> (that came up in previous -loadblock discussions)
 634 2012-07-11 14:36:38 <jgarzik> users must also avoid putting the -import- file in the bitcoin datadir
 635 2012-07-11 14:36:44 <gmaxwell> ah, I assume that now everyone here uses it daily. :)
 636 2012-07-11 14:37:29 <gmaxwell> well the import file should be called not blk0001.dat  but something like bitcoin-bootstrap.dat
 637 2012-07-11 14:37:45 <gmaxwell> so even if they threw it in there it would be harmless.
 638 2012-07-11 14:38:00 <jgarzik> ack
 639 2012-07-11 14:39:20 <gmaxwell> also, I suppose it wouldn't just be a blk0001.dat .. it would be a concatination of blk000*.dat.  (I don't think it being over 2GB would be an enormous problem for anything anymore, esp since we don't seek in it, though that should be tested)
 640 2012-07-11 14:41:23 <BlueMatt> auto-importing any found bitcoin-bootstrap.dats that are in datadir/exe dir/maybe one dir up from exe would be cool, as long as it more efficiently figured out if it didnt need to import a given set of blocks instead of ProcessBlock'ing them anyway
 641 2012-07-11 14:42:15 <gmaxwell> We could perhaps make loadblock a bit smarter about blocks it already has...
 642 2012-07-11 14:42:37 <gmaxwell> but, hm, you don't want to rescan that file every startup.
 643 2012-07-11 14:42:49 <jgarzik> the first thing ProcessBlock() does is check the hash for dups... not much more efficiency to be gained
 644 2012-07-11 14:43:16 <BlueMatt> jgarzik: except not importing 180k blocks and checking if we already have them to begin with ;)
 645 2012-07-11 14:43:26 <jgarzik> nod
 646 2012-07-11 14:43:36 <jgarzik> if height > 180k, ignore bootstrap.dat
 647 2012-07-11 14:43:41 <gavinandresen> ack
 648 2012-07-11 14:44:04 <gavinandresen> we really only care about the brand-new-user use case, right?
 649 2012-07-11 14:44:22 <jgarzik> pretty much
 650 2012-07-11 14:44:39 YYZ has joined
 651 2012-07-11 14:44:39 <BlueMatt> or, really simply, if our blk*.dat >> bitcoin-bootstrap.dat, dont import unless -forceimport
 652 2012-07-11 14:44:58 <gmaxwell> oh ^ thats a sane sounding metric.
 653 2012-07-11 14:45:02 YYZ has left ()
 654 2012-07-11 14:45:11 <BlueMatt> heh, not really, but for new users it would work
 655 2012-07-11 14:45:42 <jgarzik> gmaxwell BlueMatt: didn't one of you do peer selection work?
 656 2012-07-11 14:45:50 <jgarzik> patches lying around anywhere?
 657 2012-07-11 14:45:54 <BlueMatt> not me
 658 2012-07-11 14:46:24 <BlueMatt> rebroad had (has?) a pull entitled block download from multiple peers simultaneously, but it doesnt actually do that :(
 659 2012-07-11 14:46:53 <gmaxwell> I have a bunch of random peer selection hacks.. but nothing currently applicable. I think our selection isn't really problematic now. The download blocks from multiple peers thing is what we need.
 660 2012-07-11 14:47:00 <jgarzik> even something that avoids the first few peer addresses found would be useful
 661 2012-07-11 14:47:06 <jgarzik> to avoid the hammer-public-node problem
 662 2012-07-11 14:47:09 <gmaxwell> Biggest gap in our peer handling is we have no peer rotation at all.
 663 2012-07-11 14:47:12 <jgarzik> nod
 664 2012-07-11 14:48:14 <jgarzik> for starters (a) don't IBD from the first peer we find, and (b) if requests receive no response within 10 seconds, try another connected peer
 665 2012-07-11 14:49:12 <jgarzik> both of those should go a long way towards spreading the IBD load
 666 2012-07-11 14:49:22 <jgarzik> and being responsive, if a remote peer burps
 667 2012-07-11 14:49:33 <jgarzik> IBD pauses of ~30 minutes are still common
 668 2012-07-11 14:49:49 <BlueMatt> jgarzik: we are going to have to download from public nodes no matter what, if dnsseeds return a random subset of what public nodes are out there, it is no different to download from a set of those nodes than just using them to get addresses
 669 2012-07-11 14:49:59 <BlueMatt> jgarzik: your nodes being static is a separate issue...
 670 2012-07-11 14:50:22 <BlueMatt> downloading from multiple peers to avoid burps/spread the load better is still something that should be done
 671 2012-07-11 14:51:07 <gmaxwell> so.. the really obvious thing to do ...
 672 2012-07-11 14:51:13 <gmaxwell> is to list     {"xf2.org", "bitseed.xf2.org"},
 673 2012-07-11 14:51:15 <gmaxwell> _LAST_
 674 2012-07-11 14:51:17 <gmaxwell> not first.
 675 2012-07-11 14:51:33 <gmaxwell> since his list is static, I bet his first output node is very very frequently getting the IBD.
 676 2012-07-11 14:51:49 <gmaxwell> so there is probably almost no load balance at all.
 677 2012-07-11 14:53:18 <gmaxwell> delaying the ibd 10 seconds and picking a random peer would help.
 678 2012-07-11 14:56:24 <sipa> ha
 679 2012-07-11 14:56:48 hnz has quit (Ping timeout: 246 seconds)
 680 2012-07-11 14:57:57 <jgarzik> no objections to the list change
 681 2012-07-11 14:58:28 <jgarzik> but the way addrman works, plus A record randomization at the DNS server level, I don't think one particular node is getting hit hard
 682 2012-07-11 15:00:19 <BlueMatt> fun test: after my addnode pull, -addnode=all the dnsseeds then use getaddednodeinfo to see to which dnsseed you are connected (have to do it quick before the dnsseeds rotate and you lose that info)
 683 2012-07-11 15:03:36 hnz has joined
 684 2012-07-11 15:04:12 <BlueMatt> (in the few tests I did, while mine was still up, it would get mostly mine, and a connection or two to jgarzik's)
 685 2012-07-11 15:05:45 <gmaxwell> I just went ahead and reordered it, it's an obviously safe change, and I did a quick test, and indeed the first node I connected to in two restarts was on of the ones returned by bitseed.xf2.org.
 686 2012-07-11 15:06:12 <gmaxwell> jgarzik: addrman strongly prefers the recent data for the first peers IIRC.
 687 2012-07-11 15:06:32 <sipa> less strongly than the old code
 688 2012-07-11 15:07:44 <jgarzik> DNS seeds are added to addrman with a random age
 689 2012-07-11 15:08:09 <gmaxwell> You mean my two sample test is not conclusive‽ :)
 690 2012-07-11 15:08:25 <gmaxwell> Also matters for proxydns too.
 691 2012-07-11 15:08:45 <sipa> still, the first ever entry to be added to addrman is quite likely to be the first connected to
 692 2012-07-11 15:09:37 <sipa> whatever age it gets assigned
 693 2012-07-11 15:09:45 <jgarzik> it adds to addrman in batches
 694 2012-07-11 15:09:49 <jgarzik> one batch per DNS server
 695 2012-07-11 15:10:09 <jgarzik> DNS servers, dnspark's and other BIND at least, return A's in random order
 696 2012-07-11 15:10:18 <gmaxwell> even the static dns is a RR, so you'll get at least load balancing there.
 697 2012-07-11 15:10:21 <gmaxwell> Right.
 698 2012-07-11 15:10:38 <gmaxwell> but that still gives the dozen or so nodes on your list a disproportionate load.
 699 2012-07-11 15:11:21 <jgarzik> yep
 700 2012-07-11 15:11:49 <jgarzik> waiting, before choosing a peer, would do a lot I think (as mentioned earlier)
 701 2012-07-11 15:11:58 Cryo has quit (Quit: Leaving)
 702 2012-07-11 15:12:01 <jgarzik> *[first | IBD] peer
 703 2012-07-11 15:12:31 <jgarzik> might also shut down some attacks, by giving the user client better diversity?
 704 2012-07-11 15:12:45 <jgarzik> well, s/shut down/make more difficult/
 705 2012-07-11 15:13:12 <BlueMatt> does dnsseed wait for each dnsseed request to return before trying the next one?
 706 2012-07-11 15:13:26 Motest003 has quit (Ping timeout: 248 seconds)
 707 2012-07-11 15:13:26 <sipa> yes
 708 2012-07-11 15:13:26 <gmaxwell> it doesn't actually compare them... I mean you could get fancy like fetch the best block from each and choose among the ones with the highest pow.. which doesn't stop attacks but would avoid broken peers.
 709 2012-07-11 15:13:39 <BlueMatt> (if it is, its waiting for mine to time out, which means you would pretty much only get jgarzik's nodes atm...)
 710 2012-07-11 15:14:06 Motest003 has joined
 711 2012-07-11 15:14:15 <gavinandresen> always fetching the best block from every new peer seems like a good idea in any case
 712 2012-07-11 15:17:28 maaku has quit (Quit: maaku)
 713 2012-07-11 15:20:36 topace has quit (Remote host closed the connection)
 714 2012-07-11 15:23:12 t7 has joined
 715 2012-07-11 15:27:13 <gavinandresen> gmaxwell: I updated https://gist.github.com/2961409  with my latest transaction fee thoughts.  Away for a while, but will be back in an hour or so
 716 2012-07-11 15:29:12 topace has joined
 717 2012-07-11 15:29:50 <BlueMatt> gavinandresen: did you see my fork of that gist that made some other recommendations? https://gist.github.com/3041216
 718 2012-07-11 15:30:46 <gavinandresen> BlueMatt: yep, if I recall correctly you went off on some tangents I didn't want to follow
 719 2012-07-11 15:31:16 <BlueMatt> gavinandresen: eg specify whats spv clients would do, note that a better prio algorithm should be implemented, etc
 720 2012-07-11 15:33:29 topace has quit (Changing host)
 721 2012-07-11 15:33:29 topace has joined
 722 2012-07-11 15:33:36 <gavinandresen> BlueMatt: I decided to focus on what we could/should do right now (and right now I really am going away for a bit)
 723 2012-07-11 15:37:56 <gmaxwell> gavinandresen: as far as the sendmany vs output reduction goes— a size metric that is linear on size of outputs + size of inputs can never be cheaper/higher priority by spliting it up vs combining, and would still usually be cheaper merged.  (this doesn't work if you make the costs non-linear though)
 724 2012-07-11 15:38:59 rdponticelli has quit (Read error: Connection reset by peer)
 725 2012-07-11 15:49:11 D34TH has joined
 726 2012-07-11 15:49:49 sytse has quit (Ping timeout: 248 seconds)
 727 2012-07-11 15:50:24 pusle has joined
 728 2012-07-11 15:55:58 TD has joined
 729 2012-07-11 15:56:25 sytse has joined
 730 2012-07-11 15:57:01 rdponticelli has joined
 731 2012-07-11 15:59:35 TD_ has quit (Ping timeout: 264 seconds)
 732 2012-07-11 16:02:27 maaku has joined
 733 2012-07-11 16:07:10 <jgarzik> gavinandresen: hmmm, does the review of current code accurately capture current policy?
 734 2012-07-11 16:07:47 <jgarzik> gavinandresen: CreateNewBlock() passes progressively larger nBlockSize values to GetMinFee(), thereby creating different policy zones (and price points) with one block
 735 2012-07-11 16:08:10 <jgarzik> as the block gets larger during CreateNewBlock(), block space is ever more expensive
 736 2012-07-11 16:08:27 maaku has quit (Read error: Connection reset by peer)
 737 2012-07-11 16:08:37 <jgarzik> gavinandresen: (reading your gist)
 738 2012-07-11 16:08:53 maaku has joined
 739 2012-07-11 16:09:46 <BlueMatt> gavinandresen: posted a comment that essentially diffs your gist from my fork and explains the motivations
 740 2012-07-11 16:10:11 <jgarzik> maybe it is how I'm reading it, but under "Block creation rules" it is not as simple as "if block size > 27k, only include transactions with X fee"
 741 2012-07-11 16:10:36 <jgarzik> read alone, that statement does not match the code
 742 2012-07-11 16:16:59 rdponticelli has quit (Ping timeout: 264 seconds)
 743 2012-07-11 16:20:08 osxorgat_ has quit (Remote host closed the connection)
 744 2012-07-11 16:20:35 t7 has quit (Ping timeout: 264 seconds)
 745 2012-07-11 16:21:42 PiZZaMaN2K has quit (Remote host closed the connection)
 746 2012-07-11 16:24:05 starsoccer has joined
 747 2012-07-11 16:24:43 <starsoccer> could someone help me with setting up dark exchange?
 748 2012-07-11 16:33:32 rdponticelli has joined
 749 2012-07-11 16:38:07 TD has quit (Quit: TD)
 750 2012-07-11 16:38:17 maaku has quit (Read error: Connection reset by peer)
 751 2012-07-11 16:39:35 maaku has joined
 752 2012-07-11 16:41:42 ForceMajeure has quit (Read error: Connection reset by peer)
 753 2012-07-11 16:42:09 starsoccer has left ()
 754 2012-07-11 16:43:41 p0s has quit (Remote host closed the connection)
 755 2012-07-11 16:48:56 sacredchao has quit (Remote host closed the connection)
 756 2012-07-11 16:52:41 <jgarzik> starsoccer: no, but if you have fibre, I could set up a light exchange
 757 2012-07-11 16:52:46 <gavinandresen> jgarzik: "policy zones" don't start until you hit MAX_BLOCK_SIZE_GEN/2, which is 250K.  I'll fix the gist (I said it was 500K)
 758 2012-07-11 16:53:21 <jgarzik> gavinandresen: they start immediately, by creating a free transaction area
 759 2012-07-11 16:53:49 <jgarzik> gavinandresen: when CreateNewBlock() begins, nBlockSize < 27k for a while
 760 2012-07-11 16:53:57 <gavinandresen> right.....
 761 2012-07-11 16:54:36 sacredchao has joined
 762 2012-07-11 16:54:45 <gavinandresen> I care mostly about whether or not you can pay a fee and get faster confirmation.  And right now, you can't.
 763 2012-07-11 16:54:53 <jgarzik> gavinandresen: thus "if block size > 27k, only include transactions with X fee" is not true, because blocks >27k do include some free tx's
 764 2012-07-11 16:55:16 <gavinandresen> ah, I see.  I mean "as the block is filling up"
 765 2012-07-11 16:55:21 <gavinandresen> I'll fix the gist to make that clear
 766 2012-07-11 16:55:28 <jgarzik> gavinandresen: thanks
 767 2012-07-11 16:58:34 <gavinandresen> fixed, using the wording " if less than 27kb of transactions have been added" ... etc
 768 2012-07-11 16:59:50 <gavinandresen> BlueMatt: RE: why priority fraction and not "fees to forgo" : because I agree with jgarzik, "fees to forgo" will be a hard sell to miners, and it is way too easy for a not-thinking miner to set fees-to-forgo to zero, not realizing that opens the door to massive spam attacks.
 769 2012-07-11 17:00:57 <gmaxwell> I think we instead have something worse right now.
 770 2012-07-11 17:01:04 <gmaxwell> (I mean in the gist)
 771 2012-07-11 17:01:19 <gavinandresen> gmaxwell: ok, what did I screw up now?
 772 2012-07-11 17:02:06 <gmaxwell> :) With what you have described miners have an unbounded lost fees liability unless they set the target to maximum and the free portion to 0.
 773 2012-07-11 17:03:00 <gavinandresen> They always have a theoretical unbounded lost fees liability-- there may be a million 1-bitcoin transactions in the memory pool that won't fit into a 1MB block
 774 2012-07-11 17:03:18 <gmaxwell> Because you could always have A full megabyte of of 1000 BTC fee transactions, or what have you. Not that this is likely, but we've seen how people obsess about fees on the sending side.
 775 2012-07-11 17:03:30 <gavinandresen> If they're worried about losing fees, then they SHOULD set the free portion to zero, and the maximum (not target) size to 1MB
 776 2012-07-11 17:03:50 <gmaxwell> And so they all will. I think that makes the proposal a failure. :(
 777 2012-07-11 17:04:17 <gavinandresen> I disagree that they all will.  If they do, then so be it, that's the market speaking
 778 2012-07-11 17:04:34 <gmaxwell> I don't think anyone cares about losing a tiny amount of fees— especially for a good cause. It's the fact that the amount is unbounded. In theory it could be omg-millions-of-bitcoins lost.
 779 2012-07-11 17:05:04 <BlueMatt> gavinandresen: I think prioriy fraction will be a harder sell than fees to forgo, actually
 780 2012-07-11 17:05:16 <gmaxwell> No, its not the market speaking, it's paranoia speaking and a result of exposing knobs that don't allow people to express their real market preferences.
 781 2012-07-11 17:06:12 <jgarzik> free or "high priority"  transactions currently exist solely due to momentum from the existing Satoshi client hardcoding several behaviors.  Simply fiddling with that status quo will be messy.  If you give miners a "fees to forgo" knob, it will never be non-zero.
 782 2012-07-11 17:06:34 drizztbsd has quit (Remote host closed the connection)
 783 2012-07-11 17:06:43 <jgarzik> And I don't think miners have the best knowledge of the dev's idea (community's idea?) of a "good" or high priority transaction
 784 2012-07-11 17:07:20 <gmaxwell> Also with the median rule default plus a 50% default priority fraction people will probably observe non-trivial fees being lost. So that will encourage them to tweak the knobs. (I agree that default are powerful and people are lazy, but they'll notice missed fees)
 785 2012-07-11 17:08:19 <gavinandresen> Tweaking the knobs is good, and if we move towards a purely "you must pay a fee to get into a block" model that's OK with me
 786 2012-07-11 17:08:35 <jgarzik> the main market sensitive knob, tx-fee-too-low-and-is-considered-free is easy for miners to change
 787 2012-07-11 17:08:42 <gmaxwell> jgarzik: So make it impossible to set it below the minfee unless they go hack it out?  Perhaps thats a dead idea too.. I'm not arguing for it.
 788 2012-07-11 17:08:52 <gavinandresen> I just don't want to give them a knob that they can tweak and open up a huge DoS problem
 789 2012-07-11 17:09:11 <gmaxwell> jgarzik: funny, previously I'd argued that it should be the only cli inaccessible one! because it's quite subtle due to dos issues.
 790 2012-07-11 17:09:28 <jgarzik> anti-spam is a technical question and should remain in the dev realm. if miners want to #if 0 the spam code, fine :)
 791 2012-07-11 17:09:51 <jgarzik> spam price is a market issue
 792 2012-07-11 17:10:15 <jgarzik> if KimDotCom switches to bitcoin, miners will change the antispam fee limit :)
 793 2012-07-11 17:10:18 <gmaxwell> I would happily take a bet that a random selection of miners (or even pool ops) would set that to zero ("I want to support low cost txn!", "I want all fees I can get!") — and the result is that a simple while loop takes out the network. :)
 794 2012-07-11 17:10:28 <BlueMatt> I guess I havent been following close enough: how does setting fees to forgo to 0 open the door to massive spam?
 795 2012-07-11 17:10:41 <gmaxwell> jgarzik: the fee to be treated as zero is mostly a spam control not a market control.
 796 2012-07-11 17:10:44 <gavinandresen> I spam a bunch of 1-satoshi-fee transactions
 797 2012-07-11 17:10:45 <jgarzik> gmaxwell: the knob exists today
 798 2012-07-11 17:10:56 <gmaxwell> The market control is space availablity in blocks.
 799 2012-07-11 17:11:26 <jgarzik> gmaxwell: that logically leads to all blocks being 1MB, perhaps padded with cheap spam if nothing else
 800 2012-07-11 17:11:34 <BlueMatt> gavinandresen: thats why there are priority limits/fee limits in mempool?
 801 2012-07-11 17:11:57 <gavinandresen> BlueMatt: that's why any transaction with less than 0.0001BTC/kilobyte fee is the same as a 0-fee
 802 2012-07-11 17:12:22 * jgarzik hits pause, time to babysit
 803 2012-07-11 17:12:24 <BlueMatt> yes, and what does that setting have to do with 'fees to forgo"
 804 2012-07-11 17:12:38 <gmaxwell> jgarzik: that doesn't create any pressure to increase fees though.  The thing (perhaps the only thing? :( ) I like about gavin's latest gist is the use of the median operation to set the target size.
 805 2012-07-11 17:12:41 <gavinandresen> If you set fees to forgo to zero, then a 1-satoshi transaction won't be forgone.
 806 2012-07-11 17:13:01 <gavinandresen> 1-satoshi-fee tranactions won't be forgone....
 807 2012-07-11 17:13:05 <BlueMatt> but if they are low priority, they wont get into memory pool...
 808 2012-07-11 17:13:15 <gmaxwell> Because then you have a mechenism to coordinate on that behavior. But it fails in the GIST because there is such a motivation to change it.
 809 2012-07-11 17:14:08 <gavinandresen> BlueMatt: good point, you'd have to twiddle two knobs
 810 2012-07-11 17:14:14 <gmaxwell> I think instead we should have something where the median size sets a target but you'll gladly go over it for 'enough' income. I don't know how to parameterize enough so that people don't need to twiddle it all the time. Or so that it doesn't have a "zero setting" that would have bad outcomes.
 811 2012-07-11 17:14:26 <BlueMatt> gavinandresen: no, I believe the mempool limits would be static
 812 2012-07-11 17:15:01 <gavinandresen> gmaxwell: current version of the gist can go over the target size, up to the max size, if there are fee-paying transactions waiting.
 813 2012-07-11 17:15:26 <gmaxwell> gavinandresen: er, perhaps I was reading old text then!
 814 2012-07-11 17:15:39 <gavinandresen> "include as many as will fit until the block is maximum block size bytes big, not including "free" transactions (transactions with fee-per-kb of less than the default spam threshold of 0.0001 BTC/kilobyte)."
 815 2012-07-11 17:17:12 <gmaxwell> Okay, thats better, though it's still kind of lame.. as you'll literally end up producing a block which is 10x larger just to earn a penny or two.
 816 2012-07-11 17:17:22 <gavinandresen> RE: how to have a reasonable default that doesn't require constant twiddling:  I punted on that problem; I would like to do something straightforward right now so we get some miners on the network sorting transaction by fee.
 817 2012-07-11 17:17:26 <gmaxwell> (and you lose that penny or two in expectation because the larger block takes more time to relay)
 818 2012-07-11 17:17:55 <gavinandresen> Next step would then be to modify the client(s) to estimate fees to get a transaction mined quickly, and maybe later implement fancy algorithms to auto-adjust all the params.
 819 2012-07-11 17:18:25 BurtyB2 has joined
 820 2012-07-11 17:19:08 <gmaxwell> hm. I wonder if "adjust spam threshold based on the block size an value given a simple model of how size relates to orphaning risk" would give useful values.
 821 2012-07-11 17:19:45 <gmaxwell> s/an value/and value/
 822 2012-07-11 17:20:23 <gavinandresen> gmaxwell: probably. I think we should keep it simple to start, though, and keep track of metrics (see end of the gist) to make sure the network is behaving like we think it should
 823 2012-07-11 17:21:03 <gmaxwell> I'm actually losing track of what we'd be gaining by making the changes beyond order by fee?
 824 2012-07-11 17:21:19 <gmaxwell> (I mean the simple changes that you're talking about)
 825 2012-07-11 17:21:26 MobiusL has quit (Ping timeout: 276 seconds)
 826 2012-07-11 17:22:20 BurtyBB has quit (Ping timeout: 245 seconds)
 827 2012-07-11 17:22:51 MobiusL has joined
 828 2012-07-11 17:23:16 da2ce716 has quit (Read error: Connection reset by peer)
 829 2012-07-11 17:24:06 <gmaxwell> ISTM that the median stuff is dangerous (both for market effects and anti-spam) unless we are reasonable sure most people won't just set it to max. Simply because a habbit of maxing out that value established now will moot smarter mechenisms which would let miners coordinate their fee pressure later.
 830 2012-07-11 17:24:24 <gavinandresen> gmaxwell: good question.  I suppose the simplest possible thing that might actually work (on the mining side) is just change the transaction selection code to "After 27K, include transactions in fee-per-kb order."
 831 2012-07-11 17:24:46 <gmaxwell> I think I'd be more comfortable about that as a step one change.
 832 2012-07-11 17:25:03 <gmaxwell> fee-per-kb order is something no one has any concern with, I think.
 833 2012-07-11 17:25:26 <helo> what's the easiest path to calculating percent-spent-outputs for each block?
 834 2012-07-11 17:26:16 <gmaxwell> gavinandresen: I do really want to get the ball rolling on tx-out pressure in priority, because it will take time for network penetration.
 835 2012-07-11 17:27:01 <gavinandresen> Can we do it in a way that is pretty compatible with existing code?  What do you think of the proposed modified priority algorithm in the gist
 836 2012-07-11 17:27:20 <gavinandresen> priority = (sum(value*age)/size) * (10 + number of inputs) / (10 + number of outputs)
 837 2012-07-11 17:27:28 ForceMajeure has joined
 838 2012-07-11 17:27:47 <gavinandresen> (10 is arbitrary... thinking more about it, I think 11 would actually be better)
 839 2012-07-11 17:28:35 <gavinandresen> Still linear, just de-emphasizes the effect of inputs/outputs on priority, for normal transactions with 1-in 2-out modifies the priority a tiny bit
 840 2012-07-11 17:28:56 <gmaxwell> I need to run some numbers on actual data.  What I'd suggsted before is replacing size with  2*size_of_txn - size_of_old_txouts_consumed, with a minimum of size/2.  It could be scaled to make it mostly compatible.
 841 2012-07-11 17:30:03 <gmaxwell> (basically "you get half the size you remove from the chain for free")
 842 2012-07-11 17:30:25 <gavinandresen> mmm.   size of old txouts consumed isn't a number that's easy to get if you didn't save your inputs
 843 2012-07-11 17:30:37 <gmaxwell> You have to have the inputs to write the transaction.
 844 2012-07-11 17:30:54 <gmaxwell> (or validate it)
 845 2012-07-11 17:31:21 <gavinandresen> I'm thinking of an implementation that validates then shoves in the memory pool... I suppose it could cache the size of previous txouts
 846 2012-07-11 17:32:34 <gmaxwell> A downside of using the number is that you don't get bonuses for removing bigger or smaller tx outs.. so you can get crazy fun like making a bunch of zero value outputs with empty scripts to use to insert and increase your priority. :)  Though perhaps the incentive is large enough that it won't matter.
 847 2012-07-11 17:32:56 <BlueMatt> can someone explain why "priority fraction" is better than "fees to forgo"? if you add the same 0.0001 btc/kb limit to counting fees to "fees to forgo" it ends up with the same result?
 848 2012-07-11 17:33:09 <gmaxwell> Mostly my motivation is that later we'll add changes to coin selection to intentionally try to sweep up extra inputs when you already have change... and I don't want people to feel that doing so is against their interest. (omg! more fees!)
 849 2012-07-11 17:33:10 Zarutian has joined
 850 2012-07-11 17:33:10 <gavinandresen> huh? zero-value outputs would decrease your priority, right?
 851 2012-07-11 17:33:42 <gavinandresen> more inputs == higher priority
 852 2012-07-11 17:33:42 <gmaxwell> gavinandresen: I make one txn with 1000 zero value outputs... then I use them as inputs in my future txn to boost their priority.
 853 2012-07-11 17:33:59 <gavinandresen> gmaxwell: so you pay fees then or now
 854 2012-07-11 17:34:08 <gmaxwell> basically more inputs is higher priority is fine, but it should be proportional to the 'cost' of those inputs.
 855 2012-07-11 17:34:23 <gmaxwell> Otherwise I can game the system by making a bunch of useless inputs that get more boost.
 856 2012-07-11 17:35:20 <gavinandresen> ok.  That's why I wanted inputs/outputs to have only a mild effect on priority
 857 2012-07-11 17:36:06 <gavinandresen> (and wouldn't it work the other way? If I want to "pre-pay priority" then I could make one txn with 1000 really big txouts and burn them later to increase future txn priorities)
 858 2012-07-11 17:37:01 <BlueMatt> the goal would be that you would pay more in fees to get priority later, when you could just pay less fees later
 859 2012-07-11 17:37:24 <gmaxwell> gavinandresen: sure but you paid a lot to create that. I'm not concerned with prepay. I'm concerned with pay-less-by-gaming. E.g. if we'll give 1 unit for sane normal inputs and 1 unit for cheaply created inputs.. but :::shrugs::: this is a tangent, I bougt your argument that the incentive is small.
 860 2012-07-11 17:38:44 <gavinandresen> gmaxwell: I don't like the step function in "MAX(size*2 - size_consumed, size/2)"  -- seems like it will make it hard to reason about
 861 2012-07-11 17:40:02 <gmaxwell> gavinandresen: yea, the step function sucks.  There needs to be a max to prevent it from going zero. Lest you get infinite priority.  The reason I suggested size/2 is for compatiblity with the existing behavior.
 862 2012-07-11 17:40:06 <amiller> why not make it proportional to size and call that all?
 863 2012-07-11 17:40:19 <gmaxwell> amiller: it is currently but not all size is equal.
 864 2012-07-11 17:40:20 * BlueMatt re-proposes changing sum(value*age) to sum(min(value, A)*age)
 865 2012-07-11 17:40:51 ThomasV has joined
 866 2012-07-11 17:41:07 <gmaxwell> amiller: we're getting closer to producing a pruned node, and size in the txout set is _far_ more costly than network bandwidth.
 867 2012-07-11 17:41:15 <gmaxwell> (under a model with lots of pruning nodes)
 868 2012-07-11 17:41:18 <amiller> yup, it's the key resource
 869 2012-07-11 17:41:20 <gavinandresen> BlueMatt: I don't like the step function in min(value,A)....
 870 2012-07-11 17:41:27 <amiller> a bitcoin is basically a storage locker token in that tree
 871 2012-07-11 17:41:50 <BlueMatt> gavinandresen: why? its no harder for any of the related algorithms (most coin selection)
 872 2012-07-11 17:41:52 <gmaxwell> BlueMatt: sorry, I still don't like it— though I admit you softened me some.
 873 2012-07-11 17:42:08 <BlueMatt> s/most/mostly/
 874 2012-07-11 17:42:14 <gmaxwell> BlueMatt: because non-linearies are always gaming fun.
 875 2012-07-11 17:42:30 <gavinandresen> yep, find the edge and exploit it
 876 2012-07-11 17:42:42 <gmaxwell> BlueMatt: for example, under that scheme I can _enormously_ boost my priority by never writing myself change greater than A in value.
 877 2012-07-11 17:42:47 <BlueMatt> if, say, you set A to 1 BTC, that just means 1 BTC inputs are the same value as 100 BTC inputs...so?
 878 2012-07-11 17:43:24 <BlueMatt> gmaxwell: hence why you strongly anti-prioritize many outputs?
 879 2012-07-11 17:43:38 <amiller> i still think 1 satoshi (or something proportional to the size) should be deducted from each txoutput during every block that it isn't spent, like collecting rent
 880 2012-07-11 17:43:39 <BlueMatt> (which should happen anyway?)
 881 2012-07-11 17:43:44 <gmaxwell> BlueMatt: but thats a one time operation, and would discourage sendmany.
 882 2012-07-11 17:43:49 <amiller> if you store all your bitcoins in one big txout, then that rent deduction is very small
 883 2012-07-11 17:44:00 <gavinandresen> gmaxwell: priority = (sum(value*age)/size) * (CONSTANT + prev_txout_size) / (CONSTANT  + txout_size)
 884 2012-07-11 17:44:00 <amiller> if you spread your change very thin, then it attritions faster
 885 2012-07-11 17:44:18 <gmaxwell> amiller: there are arguments for it, but the cost of reasoning about it multiplied by all the current and future users of the system just isn't worth it.
 886 2012-07-11 17:44:41 <amiller> understandble. well, simple proportional to size should be the next best thing
 887 2012-07-11 17:44:48 <gmaxwell> amiller: it's also a totally non-starter because of course if we changed something like that, why not have a maximum of ∞ bitcoin and 50 btc blocks forever or wahteve.r
 888 2012-07-11 17:45:01 <gmaxwell> amiller: but what size? There are several sizes that matter?
 889 2012-07-11 17:45:16 <amiller> txout size is all?
 890 2012-07-11 17:45:20 <gmaxwell> gavinandresen: I like that too.
 891 2012-07-11 17:45:52 <gmaxwell> amiller: network bandwidth is never irrelevant.  And the historial size (including the inputs) matters too.
 892 2012-07-11 17:46:12 <amiller> isn't that just paying twice, and it would be simpler to only pay in one direction?
 893 2012-07-11 17:46:32 <gmaxwell> amiller: I could write an enormous input to redeem a boring regular output.
 894 2012-07-11 17:46:49 <gmaxwell> push push push push pop pop pop pop
 895 2012-07-11 17:46:56 <amiller> hmmm
 896 2012-07-11 17:47:01 <BlueMatt> gmaxwell: yes, the fact that its a one-time operation is a bit ugly, but I still think the positives of not strongly prioritizing people with 1 mill btc to spend over people with 1 outweighs that...and in terms of discouraging sendmany, it really doest have to, not discouraging sendmany with something like that is easy
 897 2012-07-11 17:47:08 <amiller> interestingly, that input would never need to be stored in the merkle tree
 898 2012-07-11 17:47:14 <amiller> but i agree it's not free
 899 2012-07-11 17:47:39 <gmaxwell> BlueMatt: but when that person with a million btc uses their priority its gone. It's not in their rational interest to burn more priority than they have to.
 900 2012-07-11 17:48:07 <BlueMatt> gmaxwell: because, again, at that point you defeat the purpose of free txn, and then we might as well throw away priority and /just/ use fee/kb
 901 2012-07-11 17:48:58 <gmaxwell> BlueMatt: I haven't really seen any reason yet to worry that bitcoin millionaries are crowding out newbies for free space.
 902 2012-07-11 17:49:01 <helo> do you folks have your bitcoin savings broken up into increments for multiple aged outputs?
 903 2012-07-11 17:49:03 <amiller> how about if txoutputs indicate a worst-case size for an input that redeems it?
 904 2012-07-11 17:49:29 <BlueMatt> gmaxwell: absolutely, but if you have a high priority cost to get into the free txn area, someone with a larger total btc could get into it easier than someone with less, older btc
 905 2012-07-11 17:49:53 <BlueMatt> gmaxwell: the point of the fee restructuring is to make it work 10 years down the road, not work tomorrow
 906 2012-07-11 17:49:54 <gmaxwell> BlueMatt: they can regardless of what you do though! you can't solve that through non-linearity.
 907 2012-07-11 17:50:06 <BlueMatt> gmaxwell: the current stuff (arguably) works and will work fine for the next year+
 908 2012-07-11 17:50:36 <gmaxwell> If I have a million btc and you cap at 1 BTC, then I just make an effort to split up my million whenever I transact.  Plus you've gained a magic number which will be invalidated if the exchange rate changes.
 909 2012-07-11 17:51:04 <BlueMatt> gmaxwell: magic number: the number can change, which makes it harder to game, too
 910 2012-07-11 17:51:18 <amiller> eventually we are going to need worst-case reasoning when we extend the scripting language anyway, so this is an appropriate place to begin that sort of thing
 911 2012-07-11 17:51:29 <gmaxwell> worse it's encouraged people to write software that bloats the txout set. :( and ... I just haven't seen evidence of the problem. Right now free txn are croweded out by 0.0005 fee txn, not high priority ones.
 912 2012-07-11 17:51:43 <amiller> if push push push pop pop pop is a plausible input, then potentially miners will have to chug through all of that many times just to get to realize the transaction is invalid
 913 2012-07-11 17:51:58 <gmaxwell> amiller: you missed my point.
 914 2012-07-11 17:52:33 <gmaxwell> amiller: I was arguing against your argument to ignore the input size. If you don't ignore the input size it's a non-issue. Because computation = size (times come constant), so they pay for that.
 915 2012-07-11 17:53:07 <amiller> sure, but it's the worst case plausible input that's really expensive
 916 2012-07-11 17:53:12 <BlueMatt> gmaxwell: even if it doesnt change, say someone has 100 BTC split into inputs of size A, and want to send A/2 to someone...they could take in 10 A inputs and send back change to themselves at 9.5A, but now they've lost a ton of their priority*age inputs, or they could send themselves back a bunch of A, in which case its no different than just 1 input, 2 outputs, which anyone can create
 917 2012-07-11 17:53:21 <amiller> since the inputs aren't inserted in a tree, the only cost associated with an input is checking it
 918 2012-07-11 17:53:43 <amiller> but a worst case plausible input might have to be checked many times
 919 2012-07-11 17:54:03 <BlueMatt> gmaxwell: and the "I dont see the problem happening today" isnt a valid argument here..."I dont think the problem will ever occur", sure, but we arent trying to set up a fee system for use for the next 6 months, we are trying to set up something that works further out
 920 2012-07-11 17:54:12 <amiller> so it would be good to limit that at the txoutput, and that's something to pay proportionally for as well
 921 2012-07-11 17:54:36 <amiller> so i'm saying a txout should be prepaid with a fee covering its storage in the tree, and also the worst-case validation cost for a txinput that spends it
 922 2012-07-11 17:54:46 <amiller> those are the two costs
 923 2012-07-11 17:54:56 TD has joined
 924 2012-07-11 17:54:59 <gmaxwell> "input is checking it" and network bandwidth. And archival storage.
 925 2012-07-11 17:55:33 <gavinandresen> the fee for an expensive-to-redeem-txout is paid when it is redeemed; I don't see an issue with that.
 926 2012-07-11 17:56:00 <BlueMatt> its better that way, then the merchant can pay the fee, and its them who really want to pay the fee (or they do in the current system, and that works well)
 927 2012-07-11 17:56:04 <amiller> it's not how much it costs when it's actually redeemed, but how much it might cost just to _validate_ whether a transaction succesfully redeems it
 928 2012-07-11 17:56:21 <gmaxwell> amiller: you could imagine that it _is_ paid in the output, just not market. And in fact if the output is really small the amount paid might be negative. :) it's isomorphic.
 929 2012-07-11 17:56:31 <BlueMatt> amiller: yes, and the tx that is redeeming should pay that cost
 930 2012-07-11 17:56:39 <amiller> if the tx is invalid, there's no pay
 931 2012-07-11 17:56:54 <gavinandresen> you pay by getting disconnected from the network
 932 2012-07-11 17:57:06 <gavinandresen> (the DoS code kicks in if you send invalid transactions)
 933 2012-07-11 17:57:09 <amiller> suppose there's a txoutput that i could redeem with a 10 byte message, but it also could be redeemed by a 10000 byte message
 934 2012-07-11 17:57:48 <amiller> validating a signature has a worst-case cost, that's an important part
 935 2012-07-11 17:58:31 <gmaxwell> amiller: yea good luck writing the solver for figuring that out, and for our language the worst case cost is always ∞. (limited only by the size of the txn you can get the network to accept in the future)
 936 2012-07-11 17:58:55 <gmaxwell> (well, except for p2psh, but you can't know the cost there)
 937 2012-07-11 17:59:00 <amiller> gmaxwell, simple, the txoutput indicates a bound for the worst size cost and pays a fee proportional to that
 938 2012-07-11 17:59:11 <amiller> anything larger is simply invalid
 939 2012-07-11 17:59:15 <gmaxwell> amiller: this feels like navel gazing again.
 940 2012-07-11 17:59:30 <amiller> i don't see what you meant by solver
 941 2012-07-11 17:59:31 T_X has joined
 942 2012-07-11 17:59:31 T_X has quit (Changing host)
 943 2012-07-11 17:59:32 T_X has joined
 944 2012-07-11 17:59:41 <gavinandresen> amiller: I still don't get it, there's an incentive to use the 10 byte message to redeem because you'll pay lower fees
 945 2012-07-11 17:59:46 <BlueMatt> gavinandresen: anyway, the idea behind my suggestion is to actually make the free tx area useful in the case of high volume and competition for that area...in the original proposal, anyone who has a large btc-net-worth can get into the free txn area easily, whereas others cannot...this has several issues: those with high btc-worth could just pay a fee, so getting into the free txn area doesn't matter for them (though they would do so, becau
 946 2012-07-11 17:59:46 <BlueMatt> se they can) second, the free txn area is designed to show people getting started with bitcoin a world with low fees to get them introduced and decrease the cost for initial users...if you set the calculation such that you cannot get into the free txn area easier with a higher net-worth it solves those and makes the free txn area serve its purpose
 947 2012-07-11 17:59:49 <gavinandresen> again, when you redeem
 948 2012-07-11 18:00:29 <gmaxwell> BlueMatt: I'm totally symapathitc to the concern you're expressing, but you have not solved it and I'm vaguely sure you can't solve it.
 949 2012-07-11 18:00:36 <gavinandresen> BlueMatt: newbies with a tiny number of coins are really indistinguishable from spammers
 950 2012-07-11 18:00:52 <amiller> gavinandresen, sure the incentive is to redeem with a 10 byte message, but if a 10MB message is plausible, then that could be the amount of effort a miner spends just checking even the invalid transaction
 951 2012-07-11 18:01:18 <gmaxwell> amiller: okay, I see that point.
 952 2012-07-11 18:01:30 <BlueMatt> gmaxwell: I dont see how it was not largely solved, I have yet to see an example of where it gets easier to create high-prio txn with large net-worth with a hard limit?
 953 2012-07-11 18:01:41 <gmaxwell> E.g. the 100 BTC fee a transaction promises you means _nothing_ if the txn is invalid.
 954 2012-07-11 18:01:51 <BlueMatt> gavinandresen: tiny number of coins, Im talking about low coins eg 1BTC or such, not 10 satoshi, which are clearly spammers
 955 2012-07-11 18:02:37 <gmaxwell> BlueMatt: but I gave you one. I adjust my code that when I have change over 1 BTC it keeps adding more 1 BTC change outputs until my txn hits the minimum free priority.
 956 2012-07-11 18:03:03 <BlueMatt> <BlueMatt> gmaxwell: even if it doesnt change, say someone has 100 BTC split into inputs of size A, and want to send A/2 to someone...they could take in 10 A inputs and send back change to themselves at 9.5A, but now they've lost a ton of their priority*age inputs, or they could send themselves back a bunch of A, in which case its no different than just 1 input, 2 outputs, which anyone can create
 957 2012-07-11 18:03:09 <gmaxwell> BlueMatt: then over time I bloat up the txout set with enormous numbers of 1BTC inputs which I can use for maximum priority effect.
 958 2012-07-11 18:03:41 <BlueMatt> even with 100 1btc outputs, you still have to spend a finite resource to get the high prio, and its more expensive per txn for you than it is for someone who only has 1 btc
 959 2012-07-11 18:04:04 <gmaxwell> BlueMatt: yes, though you can avoid that loss by making better use of sendmany. You're taking a small incentive to break change into typical transaction sizes into a large incentive to split to your target value.
 960 2012-07-11 18:04:09 <gavinandresen> amiller: again, I'm not seeing your point. If a miner gets an expensive-to-check transaction free-floating on the network, and it turns out to be invalid, then they disconnect and ban that peer.
 961 2012-07-11 18:04:37 <gavinandresen> amiller: if they get it as part of a block, then whoever generated that block must have done proof-of-work....
 962 2012-07-11 18:04:49 <gmaxwell> amiller: you have a point but gavin's answer is basically conclusive. ... we can't really get txn so costly that being banned is worth it.
 963 2012-07-11 18:04:52 <gavinandresen> ... either case, there's a disincentive to broadcasting invalid transactions
 964 2012-07-11 18:05:08 <gavinandresen> And if the transaction is valid, then fees will be paid
 965 2012-07-11 18:05:54 <BlueMatt> gmaxwell: huh?
 966 2012-07-11 18:05:54 rdponticelli_ has joined
 967 2012-07-11 18:06:47 rdponticelli has quit (Ping timeout: 264 seconds)
 968 2012-07-11 18:07:12 <amiller> if that's the case then you might as well only pay for the txout storage
 969 2012-07-11 18:07:35 <amiller> consider that all the other costs are bounded and there's no incentive for anyone to exceed them
 970 2012-07-11 18:08:27 <BlueMatt> the way I see it, if high btc-worth people can more easily get into free txn area (as it is in the proposal) the free txn area should just be scrapped...maybe Im wrong and you cant solve it in priority, but then when the competition for the free txn area increases (ie when it starts to actually become useful) its use disappears because those who would otherwise have gladly paid a fee will be the only ones in it
 971 2012-07-11 18:08:32 <gmaxwell> amiller: I'm not following you again. :(  I could make a random txin have 100kb data. Something needs to discourage me from doing that.
 972 2012-07-11 18:08:50 MC1984 has joined
 973 2012-07-11 18:08:56 <BlueMatt> and the whole fee structure would be way simpler if we dropped the free txn area altogether, which, afaict, we might as well do
 974 2012-07-11 18:09:42 <gmaxwell> BlueMatt: I wish you'd stop repeating the motivation. I believe it and love it and cuddle it. And I now wish I never suggested that it might not really matter.
 975 2012-07-11 18:10:22 <gmaxwell> also, why do you say 'as it is in the proposal' instead of 'as it is on bitcoin today' ?
 976 2012-07-11 18:10:39 <gavinandresen> uff. I knew modifying how fees would work would be a great big tarbaby
 977 2012-07-11 18:11:00 <BlueMatt> because Im largely ignoring as it is in bitcoin today, we all agree its largely broken, so...meh
 978 2012-07-11 18:11:18 Nesetalis has quit (Quit: <+shponka> how does one scissor with four people <+shponka> hypercube tribadism)
 979 2012-07-11 18:11:22 <gavinandresen> we can't ignore how it is today, whatever we do we need bitcoin to keep working while we do it
 980 2012-07-11 18:11:56 <BlueMatt> gavinandresen: Id rather try to work through the fees issues than do nothing, I may very well be entirely wrong, so we can just focus on other parts of the fee stuff, but we might as well work through everything
 981 2012-07-11 18:12:12 <gmaxwell> What we have isn't broken. Being a naysayer is cool but it doesn't make you wise. (advice I should take more often). The most obvious current dysfunction is the flood of 0.0005 fee dice txn flooding out transactions where people want fast confirms... and the free policy stuff is irrelevant for that.
 982 2012-07-11 18:12:15 <gavinandresen> ... that's why I've retreated from "rework everything" to what I'm thinking now, which is just sort-by-fee-per-kb after 27K of the block has been filled.
 983 2012-07-11 18:12:49 <gavinandresen> gmaxwell: +1  exactly
 984 2012-07-11 18:13:23 <gavinandresen> maybe satoshi dice is the current best use of block space, but we need to move forward with a market so people can vote on that using transaction fees
 985 2012-07-11 18:13:45 PiZZaMaN2K has joined
 986 2012-07-11 18:14:09 <BlueMatt> gmaxwell: ok, s/we all agree its largely broken/we all agree it has some big limitations, and should be upgraded/
 987 2012-07-11 18:14:16 <gmaxwell> BlueMatt: perhaps we can address your newbie concern differently. How about this.... setup something so new users can solve some annoying captchas to get miners to except their transactions from the fee rules like luke does for commercial partners.
 988 2012-07-11 18:14:36 <luke-jr> ^ interesting
 989 2012-07-11 18:14:46 <BlueMatt> gmaxwell: captcha farms?
 990 2012-07-11 18:15:01 osmosis has joined
 991 2012-07-11 18:15:04 <gavinandresen> good idea.  A RPC call to keep a list of artificially-high-priority transactions would be easy
 992 2012-07-11 18:15:08 <gmaxwell> Sure, you rate limit it. I don't think it would expose a spam risk. It's just another way to pay for your txn.
 993 2012-07-11 18:15:22 <BlueMatt> thats fine with me
 994 2012-07-11 18:15:24 <luke-jr> gavinandresen: I actually have that already, I could clean it up if it's wanted
 995 2012-07-11 18:16:00 <gavinandresen> luke-jr: settransactionpriority <txid> <priority>   ?
 996 2012-07-11 18:16:05 <BlueMatt> gavinandresen: I still think the proposed priority changes that take into account pruning are better than nothing, Im just saying I think they could be better
 997 2012-07-11 18:16:21 <amiller> i still think putting in a worst-case bound at the txout is ideal and simple, especially since in the future it can reflect a cycle/instruction count as well as a storage, and otherwise you're relying too much on the dos defense / banning, which i don't know much about but i'll take your word it's effective
 998 2012-07-11 18:16:23 <luke-jr> gavinandresen: right now it's a boolean, but I could certainly make it variable
 999 2012-07-11 18:16:45 <luke-jr> gavinandresen: IMO it makes more sense to specify a difference/boost tho
1000 2012-07-11 18:16:51 <gavinandresen> would be good to prioritize OR de-prioritize certain txns.  I know some people would like to de-prio all 1dice.....
1001 2012-07-11 18:17:05 Nesetalis has joined
1002 2012-07-11 18:17:28 sirk390 has joined
1003 2012-07-11 18:17:34 <gavinandresen> I think   prioritizetransaction <txid> <delta> would be OK, too
1004 2012-07-11 18:18:56 <gavinandresen> amiller: so what happens if somebody lies about the worst case bound?
1005 2012-07-11 18:19:31 <amiller> the worst case bound is normative
1006 2012-07-11 18:19:35 Maccer has quit (Excess Flood)
1007 2012-07-11 18:19:36 <amiller> it's not something you solve for or calculate
1008 2012-07-11 18:19:53 <amiller> if a tx exceeds it, it's necessarily invalid
1009 2012-07-11 18:19:59 <gavinandresen> we've already got hard-coded bounds on script execution
1010 2012-07-11 18:20:51 <BlueMatt> gmaxwell: one issue with the captcha-with-pools-for-free-prio is its another odd thing to make new users go through, and their experience should generally be as simple as possible...but it is optional so its only a minor gripe
1011 2012-07-11 18:21:42 <amiller> gavinandresen, sure but it's a bit inflexible now, the idea is to allow a txout to prepay for a larger bound
1012 2012-07-11 18:22:06 <gavinandresen> I see, you want the bounds to be expanded if enough fees are paid?
1013 2012-07-11 18:22:11 <amiller> right
1014 2012-07-11 18:22:21 <gavinandresen> meh
1015 2012-07-11 18:22:38 <amiller> heh
1016 2012-07-11 18:22:40 <gavinandresen> on the list of priorities, bumping up against the hard-coded script limits is... well, it's not on it
1017 2012-07-11 18:23:19 <amiller> well then for now it could just be a storage bound, it would prevent the 100kb inputs
1018 2012-07-11 18:23:37 Nesetalis has quit (Quit: <+shponka> how does one scissor with four people <+shponka> hypercube tribadism)
1019 2012-07-11 18:24:09 <gmaxwell> BlueMatt: yea, I'm mostly interested in the infrastructure, which would be the RPC for priority boosts. People can invent clever stuff.
1020 2012-07-11 18:24:44 <luke-jr> gavinandresen: is it fair to assume if priority delta > 0, the minimum fee rule should be ignored?
1021 2012-07-11 18:25:07 <gavinandresen> amiller: scripts (inputs) bigger than 10K are invalid
1022 2012-07-11 18:25:23 <BlueMatt> gmaxwell: I think a priority rpc would be nice in any case, though Im not convinced that its not possible to solve with priority, and I do think that would be a much better way to address the issue
1023 2012-07-11 18:25:28 <gmaxwell> (ah, I was hazy on it being 10k or 100k :) )
1024 2012-07-11 18:25:47 <amiller> well 10k is still larger than necessary for a standard transaction, so you should have to pay more for a txout that can be redeemed with a 10k
1025 2012-07-11 18:26:02 <gmaxwell> amiller: Yes, and we already do!
1026 2012-07-11 18:26:10 <gmaxwell> amiller: because you pay based on the size of the transaction.
1027 2012-07-11 18:26:18 <gmaxwell> when you redeem it!
1028 2012-07-11 18:26:18 <amiller> only for a valid transaction
1029 2012-07-11 18:26:22 <amiller> that 10k is the validation cost
1030 2012-07-11 18:26:29 <gmaxwell> amiller: if the transaction is invalid you will be blacklisted!
1031 2012-07-11 18:26:34 <gavinandresen> luke-jr: no, I'd keep it simple and just add the number to the priority and let it go through all the rest of the transaction selection rules
1032 2012-07-11 18:27:01 <gmaxwell> and there is no concevable way that a 10k (or 100k) txn would be so costly to validate that blacklisting wouldn't be a worse cost.
1033 2012-07-11 18:27:01 <gavinandresen> e.g. if map[txid].count() > 0  then priority += map[txid]
1034 2012-07-11 18:27:12 iso1 has left ()
1035 2012-07-11 18:27:14 <amiller> how sound is this blacklisting thing
1036 2012-07-11 18:27:30 <amiller> can't i submit transactions from anywhere?
1037 2012-07-11 18:27:37 <amiller> only a full node is capable of rejecting it
1038 2012-07-11 18:27:44 <amiller> but lots of nodes will circulate it
1039 2012-07-11 18:27:47 <gmaxwell> amiller: non-full nodes do not relay.
1040 2012-07-11 18:28:06 <amiller> they're not allowed to? or they just typically don't?
1041 2012-07-11 18:28:13 <gavinandresen> yes, rule is "if you can't validate it, you shouldn't be relaying it."
1042 2012-07-11 18:28:15 <amiller> i see
1043 2012-07-11 18:28:41 <gavinandresen> ... otherwise you can easily get yourself DoS'ed off the network as an accessory to the crime
1044 2012-07-11 18:28:46 <gmaxwell> amiller: And it's as sound as the IP addresses you can get access to. Which is your cost.. perhaps you can pay a botnet operator for 10k IPs.. but once they're blacklisted.. you're spent.
1045 2012-07-11 18:28:57 <gmaxwell> Acting as an attack force multiplier.
1046 2012-07-11 18:29:29 <amiller> or connect through tor
1047 2012-07-11 18:29:34 <gmaxwell> Morover, if we didn't have that even with your maximum txin size scheme, the attacker would just flood infinite amounts of maximum allowed cost. The cost is bounded but they'd just send more txn.
1048 2012-07-11 18:29:36 <gavinandresen> That reminds me, Something probably Needs to be Done with IpV6 and the DoS code
1049 2012-07-11 18:29:48 t7 has joined
1050 2012-07-11 18:30:05 <BlueMatt> gavinandresen: easiest: just ban by /64
1051 2012-07-11 18:30:15 <BlueMatt> easy and sane
1052 2012-07-11 18:30:17 <gavinandresen> BlueMatt: that's "Something"
1053 2012-07-11 18:30:21 <gmaxwell> eee.
1054 2012-07-11 18:30:29 <gmaxwell> well start by looking at how the group handling works.
1055 2012-07-11 18:30:38 <gmaxwell> E.g. we convert 6to4 to the IPv4 addresses.
1056 2012-07-11 18:30:59 jurov is now known as away!ldxjiixv@84.245.71.31|jurov
1057 2012-07-11 18:31:03 <gmaxwell> BlueMatt: "I can take deepbit off the network by getting a host in their colo"  fantastic!
1058 2012-07-11 18:31:09 <BlueMatt> gmaxwell: ok s|ban by /64|ban by /64 for regular ipvs's|
1059 2012-07-11 18:31:20 <BlueMatt> ipv6s
1060 2012-07-11 18:31:28 Maccer has joined
1061 2012-07-11 18:32:04 <gmaxwell> BlueMatt: try again? I didn't parse.
1062 2012-07-11 18:32:21 <BlueMatt> gmaxwell: just ban by /64 for regular ipv6s, not for anything else
1063 2012-07-11 18:32:46 <BlueMatt> yea, if you are in a colo where they give you only one ipv6, you may get banned, but you still have ipv4 to fall back on, which should be safe
1064 2012-07-11 18:33:24 <gmaxwell> BlueMatt: Thats true but it seems really inelegant to continue to depend on good v4 connectivity. I suppose it's an okay short term thing.
1065 2012-07-11 18:34:02 <gmaxwell> 6to4 and such should still be treated as their v4 for this purpose too. The same normalization function can handle it.
1066 2012-07-11 18:34:04 <BlueMatt> yea, its not really that pretty, sure, but for the forseeable future it will work just fine
1067 2012-07-11 18:38:01 scottharding has joined
1068 2012-07-11 18:38:07 <amiller> gmaxwell, yeah good point, my input bound thing isn't at all an adequate dos-defense
1069 2012-07-11 18:39:23 <amiller> it still might be a way of prepaying for the 10k inputs so that the fees are simple and one-way only
1070 2012-07-11 18:40:01 <TD> or don't ban
1071 2012-07-11 18:40:03 <TD> just reprioritize
1072 2012-07-11 18:41:23 RainbowDashh has joined
1073 2012-07-11 18:41:35 <BlueMatt> recommendations for profiling java?
1074 2012-07-11 18:42:36 <TD> there's a simple tool included called jvisualvm
1075 2012-07-11 18:42:45 <TD> it's not amazing but works well enough if you take the snapshots
1076 2012-07-11 18:43:18 <BlueMatt> yea, thats what Im trying, but I just hit "Compute retained sizes" and it looks like its gonna take a day...
1077 2012-07-11 18:43:26 <BlueMatt> (and is neatly using 1% cpu right now...wtf?)
1078 2012-07-11 18:43:34 <TD> that's odd. i've used it many times before and had no trouble
1079 2012-07-11 18:44:05 <TD> otherwise the android tools are pretty good, but obv you'd have to write a little android wrapper app to use them
1080 2012-07-11 18:44:15 <TD> there are a bunch of commercial profiling tools too
1081 2012-07-11 18:44:25 <TD> are you trying to do cpu or heap profiles?
1082 2012-07-11 18:44:26 <gmaxwell> amiller: so I'm hoping an expecting that ultraprune (+ txtree commitments later) will make the cost of running a full validation cheap enough that continuing to limit relaying to nodes which can validate isn't an issue at all. I think anything less than that makes any public node an attack multipler, so it better be enough. :)
1083 2012-07-11 18:44:32 <BlueMatt> TD: both...
1084 2012-07-11 18:45:24 <TD> ok
1085 2012-07-11 18:45:37 <TD> i've been ok with jvisualvm or jhat for heap walks
1086 2012-07-11 18:45:43 <TD> but if you find a better one that's free, let me know
1087 2012-07-11 18:46:10 <TD> BlueMatt: whereabouts in germany are you again?
1088 2012-07-11 18:46:15 <BlueMatt> it might just be the fact that the heap peaks at ~500M thats killing it...
1089 2012-07-11 18:46:20 <BlueMatt> frankfurt area
1090 2012-07-11 18:46:52 walruscode has quit (Read error: Connection reset by peer)
1091 2012-07-11 18:47:08 <TD> ah ok
1092 2012-07-11 18:47:16 walruscode has joined
1093 2012-07-11 18:47:22 <TD> BlueMatt: if you have an enormous heap then analyzing it will be difficult, yes. jhat may be more appropriate
1094 2012-07-11 18:47:28 <TD> or reducing the amount of stuff on the heap :)
1095 2012-07-11 18:47:51 <BlueMatt> reducing the amount of stuff in heap is difficult if you cant analyze whats in heap ;)
1096 2012-07-11 18:48:34 <amiller> gmaxwell, agreed, though i'm also really hoping that the scripting language gets totally beefed up
1097 2012-07-11 18:50:29 sytse has quit (Ping timeout: 240 seconds)
1098 2012-07-11 18:51:11 <TD> amiller: what would you want in it?
1099 2012-07-11 18:53:41 <amiller> well, there are tons of cool things you could do with it, but the most important one (i don't expect anyone to agree with me) is Ripple
1100 2012-07-11 18:54:20 <amiller> what i would want is to be able to restrict not just what kind of input is needed to spend a tx, but also how the next txoutputs could be used
1101 2012-07-11 18:54:23 * lianj luke-jr sorry for the privmsg, but how can i connect to you pool node(s) directly? are 208.110.68.114, 78.47.187.252 right?
1102 2012-07-11 18:54:25 bayleef has quit (Ping timeout: 240 seconds)
1103 2012-07-11 18:54:34 * lianj faceplam
1104 2012-07-11 18:57:29 <TD> amiller: see here https://bitcointalk.org/index.php?topic=92421.0 for the latter
1105 2012-07-11 18:57:41 sytse has joined
1106 2012-07-11 18:58:09 <TD> amiller: and here https://en.bitcoin.it/wiki/Ripple_currency_exchange for the former
1107 2012-07-11 18:58:52 walruscode has quit (Read error: Connection reset by peer)
1108 2012-07-11 18:58:52 <TD> amiller: yes, being able to [sig]hash the connecting transaction and match it would be neat. and not a difficult extension
1109 2012-07-11 18:59:18 walruscode has joined
1110 2012-07-11 19:00:23 <TD> amiller: for now, there is plenty of mileage in the features we already have
1111 2012-07-11 19:00:27 <amiller> mm thanks didn't know about those pages, but yeah that's exactly right
1112 2012-07-11 19:00:46 <gribble> New news from bitcoinrss: luke-jr opened pull request 1583 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1583>
1113 2012-07-11 19:01:04 <TD> amiller: the community still hasn't done the basics yet. let alone the more complex stuff. and TBH i haven't found any really compelling use cases for checking the form of spending transactions yet. i keep coming up with places i want to use it, then realizing it isn't really necessary
1114 2012-07-11 19:01:06 <jgarzik> gavinandresen: (returns, scrolling back)  Classify TX as either fee or free (fee < X).  Sort TXs by fee-per-kb.  Fill block from this sorted list.  If there is space left over, add up to X kb free TX's.
1115 2012-07-11 19:01:09 <jgarzik> gmaxwell: ^
1116 2012-07-11 19:02:31 PiZZaMaN2K has quit (Quit: Linkinus - http://linkinus.com)
1117 2012-07-11 19:07:08 <gmaxwell> As an aside,  I'd like to start thinking in terms of "Fee paid" transactions and "Priority paid" transactions. They're both paid for, but with different resources.
1118 2012-07-11 19:08:02 <jgarzik> reasonable
1119 2012-07-11 19:09:02 <amiller> TD, i'll know its working when i can sponsor a chess game
1120 2012-07-11 19:09:06 <gmaxwell> jgarzik: instead of X kb, in that— perhaps apply gavin's median thing.  The target is (x?)*median(y blocks). If you're under target, add up to Z KB of priority paid until you're at target up to target.
1121 2012-07-11 19:09:26 <amiller> i post the bounty price, designated two players by their public key, they alternate making moves by making transactions, miners validate each move, and the winner gets the bitcoins
1122 2012-07-11 19:09:50 <TD> that sounds like an inefficient way to implement it :-)
1123 2012-07-11 19:10:02 <jgarzik> gmaxwell: reasonable -- but I don't understand why target != maximum in all cases
1124 2012-07-11 19:10:02 <amiller> yeah, i also don't have any compelling use case, outside ripple i suppose
1125 2012-07-11 19:10:13 <amiller> oh, also if you can do ripple, you can also build WoT into bitcoin, which will be cool
1126 2012-07-11 19:10:21 <jgarzik> as a miner, why not build all the way up to 1MB of fee-paying tx's?
1127 2012-07-11 19:10:27 <gmaxwell> jgarzik: because the target would only matter for non-fee txn.
1128 2012-07-11 19:10:31 <TD> the way i've been going with my designs, is to move almost all logic out of bitcoin and just tie it to the block chain where necessary
1129 2012-07-11 19:10:40 <jgarzik> gmaxwell: ok
1130 2012-07-11 19:10:43 <amiller> TD, you mean with merge mining?
1131 2012-07-11 19:10:47 <TD> if you wanted some kind of crypto-chess system, it's best to create an independent network for that
1132 2012-07-11 19:10:56 <TD> well, not just for that
1133 2012-07-11 19:11:06 <jgarzik> gmaxwell: I could ack that
1134 2012-07-11 19:11:10 <gmaxwell> jgarzik: I'm saying you add up to the maximum of fee-paid, then if you're still under target, you add free ones. This allows miners to coordinate to keep the free pressure.
1135 2012-07-11 19:11:15 <TD> look at the bonds implementation. the block chain contains pointers to data structures held elsewhere, that are dereferenced by software that knows how to speak the bitcoin protocol
1136 2012-07-11 19:11:20 <jgarzik> gmaxwell: yes, agreed
1137 2012-07-11 19:11:20 <TD> but to miners it's just dropped data
1138 2012-07-11 19:12:08 <amiller> TD, i don't think that's satisfactory but let me read this more carefully first, the basic problem is the same as wtih merge mining, if it's just dropped data to the bitcoin miners, you get timestamp sure but you don't get well-orderedness
1139 2012-07-11 19:12:23 <TD> amiller: for example. for your chess example, you could create a p2p network of nodes that take part in the creation of threshold signatures. when you start a game, you select 50 peers that have been online for >7 days, and they generate a 30 of 50 threshold key
1140 2012-07-11 19:12:24 <jgarzik> gmaxwell: I'm just not a fan of the target system.  Seems easier to ignore block history, and just work on the current block with a simple rule:  block size + X kb, as long as that does not overflow 1MB
1141 2012-07-11 19:12:53 <TD> amiller: the nodes all watch the moves and when a winner is found, group-sign the transaction
1142 2012-07-11 19:12:57 <jgarzik> gmaxwell: but if consensus likes the complex target system, that's fine too
1143 2012-07-11 19:13:14 <jgarzik> simple rules are easier for miners
1144 2012-07-11 19:13:24 <TD> amiller: you can get it when you need it, if you use transactions carefully. trying to use miners as a general purpose logic engine isn't going to work though
1145 2012-07-11 19:13:51 <jgarzik> the smaller the patch, the more likely miners with forked codebases pick it up
1146 2012-07-11 19:14:15 <amiller> but now i have to select 50 peers rather than just using the bitcoin miners? why shouldn't bitcoin miners be a general purpose logic engine, if that's what i want to pay them for?
1147 2012-07-11 19:15:17 walruscode has quit (Read error: Connection reset by peer)
1148 2012-07-11 19:15:35 <TD> amiller: because they weren't designed for it, as you have observed - script is not a general purpose programming language
1149 2012-07-11 19:15:42 walruscode has joined
1150 2012-07-11 19:15:55 <TD> amiller: if people are interested in crypto-chess matches, it's not hard for them to run a node for your network
1151 2012-07-11 19:15:55 <gmaxwell> jgarzik: So I do think we should have some mechenism so that there is always pressure to provide fees for faster processing even when the load is low.  By using the median it means that the free txn only slip in when the local load is low.. regardless of what the absolute load is.
1152 2012-07-11 19:16:13 <TD> amiller: given that people interested in that would want/need an integrated game playing UI, it's not a big leap to combine them together
1153 2012-07-11 19:16:15 <gmaxwell> If we had that all along free txns would always have been a bit slow and we'd be better adapted to where we are now.
1154 2012-07-11 19:16:22 <gmaxwell> But I don't have super strong opinions on this.
1155 2012-07-11 19:16:24 <TD> amiller: also, a confirm per move? sounds kinda dull.
1156 2012-07-11 19:16:29 Raziel_ has quit (Quit: Leaving)
1157 2012-07-11 19:16:50 <jgarzik> gmaxwell: would having a run of same-sized blocks, with moderate-to-heavy transaction load, work to starve off free TXs even with block size < 1MB?
1158 2012-07-11 19:16:55 RazielZ has joined
1159 2012-07-11 19:16:56 <gmaxwell> amiller: BECAUSE THE NETWORK IS MORE THAN MINERS.
1160 2012-07-11 19:17:02 <amiller> TD, the chess game is just an example, but enhancing the scripting language so that bitcoin becomes a giant distributed general-purpose-state machine is exactly what i'm after
1161 2012-07-11 19:17:08 pusle has quit ()
1162 2012-07-11 19:17:28 <amiller> gmaxwell, lol, i didn't mean miners, i meant verifiers of all shapes and sizes ;p
1163 2012-07-11 19:17:35 <TD> amiller: i think that is very likely to result in a network that sucks as a logic engine, and also sucks as a financial platform. have you looked at MPC? building an independent yet linked network that does general MPC might be an interesting project
1164 2012-07-11 19:17:42 <jgarzik> I think bitcoin users benefit from free TX's
1165 2012-07-11 19:17:46 <TD> it'd have very different scaling and security properties to bitcoin though
1166 2012-07-11 19:17:47 <gmaxwell> amiller: you're not paying them They validate for the 'payment' of having their currency be inflation proof.
1167 2012-07-11 19:17:48 <jgarzik> and I don't want to squeeze them off just yet
1168 2012-07-11 19:17:54 <jgarzik> not when there's still <1MB blocks
1169 2012-07-11 19:18:00 <gmaxwell> amiller: but checking your chess games do nothing to make the currency inflation proof.
1170 2012-07-11 19:18:12 <jgarzik> a target system sounds like it will slow existing free TX's
1171 2012-07-11 19:18:20 <jgarzik> when the network bursts
1172 2012-07-11 19:18:21 <gmaxwell> jgarzik: absolutely, I don't want to stop free txn.
1173 2012-07-11 19:18:32 Nesetalis has joined
1174 2012-07-11 19:18:48 <gmaxwell> jgarzik: it would, it would make them slip into gaps and during load growth they'd take a long time.. which is the expected long term behavior.
1175 2012-07-11 19:18:52 <jgarzik> a simple "+ Z Kb priority tx's" rule handles bursts with useful behavior
1176 2012-07-11 19:19:13 <jgarzik> as we approach 1MB, the system slowly converts to fee only
1177 2012-07-11 19:19:40 <amiller> if i pay a fair proportional fee to make a transaction with some logic in the script, i don't see why that makes any difference
1178 2012-07-11 19:19:49 <jgarzik> gmaxwell: a target system hastens the point at which free tx's see poor performance, versus a simple +Z rule
1179 2012-07-11 19:19:58 <TD> amiller: there are quite a few differences.
1180 2012-07-11 19:20:07 <gmaxwell> jgarzik: it does, but also makes the transaction smoother instead of almost instant.
1181 2012-07-11 19:20:36 <TD> amiller: firstly, people who run bitcoin aren't necessarily interested in providing a general purpose computation and storage system. they are definitely interested in a p2p financial system though, that is something we can safely assume. it's rude to assume everyone who takes part in bitcoin cares about your chess games
1182 2012-07-11 19:20:48 <jgarzik> gmaxwell: I disagree with "almost instant" characterization
1183 2012-07-11 19:20:53 <gmaxwell> jgarzik: you could do target + Z ... but meh.
1184 2012-07-11 19:20:53 <TD> amiller: secondly, script is - by design - a pure function over the inputs. it does not support loops or anything else that could lead to non termination.
1185 2012-07-11 19:21:01 <TD> amiller: that limits you a _lot_. really, what you want is MPC
1186 2012-07-11 19:21:07 <jgarzik> gmaxwell: yes, I like target+Z a lot better
1187 2012-07-11 19:21:26 <gmaxwell> jgarzik: I think it's a reasonable guess that the transition between 1m-27k to 1m shouldn't take long, perhaps I'm crazy.
1188 2012-07-11 19:21:30 <amiller> TD, my chess game is easily a pure function that provably terminates, i'll show you my coq if you want ;p
1189 2012-07-11 19:21:42 <TD> amiller: this argument that, well, i paid for it so i can do what i want with the network has come up before. it does not impress any of the main developers, largely because there are many people in the network who have to deal with the block chain but who do not mine and therefore, do not get any of your fees
1190 2012-07-11 19:21:59 <TD> eg, people tried to argue for stuffing DNS data into fake transactions, for storing files in the block chain, etc
1191 2012-07-11 19:22:05 <gmaxwell> jgarzik: yea, target+Z is fine to me. I just prefer something that is a bit adaptive to even out the load, and hopefully make the transation points a little more gradual instead of ALL happening at the 1MB boundary.
1192 2012-07-11 19:22:10 <TD> DNS turned out to be more elegantly done with a merged mined separate network
1193 2012-07-11 19:22:14 <amiller> TD, that's because we don't have a proportional fee system yet
1194 2012-07-11 19:22:14 <TD> file storage was just a bad idea to begin with
1195 2012-07-11 19:22:16 <amiller> bitcoin is like a notarized digital postage system, but all we do right now is send each other blank postcards covered with stamps
1196 2012-07-11 19:22:38 <amiller> the stamps will become even more valuable when we can do various neat things with the envelopes
1197 2012-07-11 19:22:43 <gmaxwell> amiller: 'proportional fee system' doesn't address this at all. :(
1198 2012-07-11 19:22:53 <TD> i'm all for building powerful systems on top of the bitcoin protocol
1199 2012-07-11 19:22:57 <TD> keyword: on top of. not built in.
1200 2012-07-11 19:23:01 <jgarzik> gmaxwell: at the point in the future that block sizes start touching 1MB, it will not be an "almost instant" brick wall that sticks at 1MB, but standard organic transaction flow that bursts, ebbs, flows.  Weaning off free TX's would not be almost instant, and everybody would be long prepared.
1201 2012-07-11 19:23:03 <gmaxwell> TD <3
1202 2012-07-11 19:23:17 <amiller> meh, time will tell
1203 2012-07-11 19:23:21 <TD> amiller: and i think when you drill into the details you'll almost always find there are better ways to do things. at least that's what i found
1204 2012-07-11 19:23:36 <TD> amiller: a p2p MPC network would be a very interesting endevour, btw. i'd probably run a node
1205 2012-07-11 19:23:37 <jgarzik> 1MB boundary is probably soft anyway
1206 2012-07-11 19:23:38 <TD> just for the heck of it
1207 2012-07-11 19:23:47 <gmaxwell> The ability to have hashed locked txn and oracle driven multisigs is super powerful.
1208 2012-07-11 19:23:47 <jgarzik> when we consistently hit 1MB, changes happen
1209 2012-07-11 19:23:50 <TD> though i'm not sure how well it'd work
1210 2012-07-11 19:23:57 <jgarzik> thus simple rule will still be effective
1211 2012-07-11 19:23:59 <jgarzik> +Z Kb
1212 2012-07-11 19:24:18 <TD> amiller: btw, did you see about oracles?
1213 2012-07-11 19:24:21 <amiller> TD, MPC is one of the things you can do in the general bitcoin-as-state-machine approach
1214 2012-07-11 19:24:22 <gmaxwell> e.g. someone proposed a really complicated way of doing cross chain payments .. and I was like.. dur. two hashes + key. Done.  And TD pointed out that this was already an old scheme.
1215 2012-07-11 19:24:38 <gmaxwell> jgarzik: I think gavin is actually off implementing just that in any case.
1216 2012-07-11 19:25:03 <TD> amiller: i suspect MPC with transactions would be one of the least efficient implementations imaginable.
1217 2012-07-11 19:25:15 <TD> if it was possible at all. huge extensions to the script language don't count, btw :)
1218 2012-07-11 19:25:34 <amiller> mpc crypto isn't exactly fast yet so yeah
1219 2012-07-11 19:26:08 <TD> amiller: you can probably make simple programs "fast enough" with some tricks, like having nodes associate with each other if they're on the same continent/within <30msec ping times
1220 2012-07-11 19:26:12 <gmaxwell> It's actually really important to build these external things now. Because if we do need to get something into bitcoin to make the interconnect then now is a good time to do it.
1221 2012-07-11 19:26:28 <TD> gmaxwell: yeah. but everyone is already busy :(
1222 2012-07-11 19:26:41 <gmaxwell> Yea. :(
1223 2012-07-11 19:26:54 <TD> lately i've been thinking about maybe doing my own little company, that'd publish design docs and then raise assurance contracts for implementation
1224 2012-07-11 19:27:12 <TD> if the design docs were precise enough, the work modules small enough, it might be able to get to the point where the community is regularly funding work
1225 2012-07-11 19:27:29 <TD> the question is, how big / rich / interested in exotic "apps" is the bitcoin userbase
1226 2012-07-11 19:27:43 ovidiusoft has quit (Ping timeout: 265 seconds)
1227 2012-07-11 19:28:39 <TD> amiller: i once proposed a network of oracles, that'd run arbitrary imperative programs that yield an address, and which would then sign transactions if they matched the yielded template
1228 2012-07-11 19:28:53 <TD> amiller: as a way to link arbitrary external state to the chain
1229 2012-07-11 19:29:14 <TD> amiller: CHECKMULTISIG is kind of expensive, but there are ways to do threshold signatures that result in a single ECDSA signature
1230 2012-07-11 19:29:31 <TD> amiller: so you could potentially have a lot of oracles all read the same list of moves, compute the winner and then sign correctly.
1231 2012-07-11 19:29:36 <gmaxwell> Oracles are the obvious easy thing to start with.
1232 2012-07-11 19:29:38 <jgarzik> TD: how difficult would 'addr' support in BitcoinJ be?  if I were to look into the task?
1233 2012-07-11 19:29:41 <TD> the advantage being you can do loops and other stuff.
1234 2012-07-11 19:29:50 <gmaxwell> The nice thing about them is that they're fully general.
1235 2012-07-11 19:29:56 <jgarzik> TD: lack of 'addr' bugs me :)  seems like a minor security worry, too.
1236 2012-07-11 19:30:08 RazielZ has quit (Ping timeout: 265 seconds)
1237 2012-07-11 19:30:30 <TD> jgarzik: it bugs me too. i am guessing - not so trivial. i'd start by having a crawler app (or adapting sipas code) to calculate fresh seed lists and having them be loaded from an external file.
1238 2012-07-11 19:30:57 <TD> jgarzik: we could then refresh the seed list regularly offline. at least, the android wallet, is auto-updated pretty often. or the list could just be downloaded and signature checked.
1239 2012-07-11 19:31:19 <TD> jgarzik: then the next step is to make that list be updated locally. not sure if it's best to do it all in RAM or use a real database. so far bitcoinj does not depend on a bdb-like lib anywhere
1240 2012-07-11 19:31:33 <TD> jgarzik: probably you can say, max 5000 addresses or whatever, use a file as a ring buffer or something suitably bare-metal
1241 2012-07-11 19:31:47 <jgarzik> yeah
1242 2012-07-11 19:31:47 <TD> jgarzik: problem is how do you keep it fresh when the apps may remain dormant for some time.
1243 2012-07-11 19:32:06 <TD> you don't want a huge delay if you don't run the mobile wallet for a month, and then it spends 2 mins connecting to vanished nodes
1244 2012-07-11 19:32:50 <TD> jgarzik: a good implementation might require new protocol support, so you can ask nodes "tell me addresses you've seen reliably be announced for >2 weeks". except that nodes don't necessarily re-announce themselves. so it's an issue.
1245 2012-07-11 19:33:11 <TD> i guess you'd build it up in layers
1246 2012-07-11 19:33:43 <gmaxwell> You might be over thinking thing. Fast connect is only an issue at startup. Use DNSseed for an initial connection while you try ones from your database.
1247 2012-07-11 19:33:46 talso has quit (Ping timeout: 246 seconds)
1248 2012-07-11 19:34:19 PiZZaMaN2K has joined
1249 2012-07-11 19:35:27 Diapolo has joined
1250 2012-07-11 19:38:46 <TD> gmaxwell: yeah, but i think the most common use case for these mobile wallets is fast start/fast end. that's how i use mine anyway
1251 2012-07-11 19:39:08 <TD> as nodes migrate more to being run by "professionals" it'll be less of an issue. dead addresses won't be a big concern anymore
1252 2012-07-11 19:39:26 <TD> and until then opening up 100 attempted connections in parallel and then dropping the ones that work until you have 5 is ugly, but doable
1253 2012-07-11 19:39:43 <TD> we recently switched bcj to threaded async io, from one-thread-per-peer. so that approach is more feasible now
1254 2012-07-11 19:40:09 <TD> gmaxwell: for most of the proposed schemes, btw, the only changes we need from bitcoin now are (a) reactivating tx replacement (b) whitelisting a few trivial script forms
1255 2012-07-11 19:40:23 <TD> gmaxwell: it'd probably be pretty safe. those two changes open up a lot of possibilities
1256 2012-07-11 19:41:17 copumpkin has quit (Quit: Computer has gone to sleep.)
1257 2012-07-11 19:42:01 <TD> amiller: for your example of a chess game, you don't need miners to order btw. in the unlikely and unsporting event of two plays by the same player on the same turn being created simultaneously, the one to build off can be chosen by his opponent. because turns are naturally ordered anyway it's a simple and fast way to get a real ordering
1258 2012-07-11 19:42:20 <TD> amiller: then the final set of plays can be fed to a generic script that runs inside a bunch of oracles, who then threshold sign. now your coins are unlocked by the game.
1259 2012-07-11 19:42:33 <TD> amiller: some of those oracles can prove what they're doing to you using a TPM, for additional low-trustyness
1260 2012-07-11 19:42:49 <amiller> the oracle thing is useful but it's also an unnecessary additional trust vector if i trust the bitcoin miners but don't want to have to trust anyone else
1261 2012-07-11 19:42:53 <amiller> you're right that the chess example sucks though
1262 2012-07-11 19:43:48 <TD> well, the problem with miners (and bitcoin nodes in general) is that every additional bit of functionality is an attack vector
1263 2012-07-11 19:43:56 <TD> so extending their power is a very hard problem
1264 2012-07-11 19:44:11 <TD> if you get it wrong the entire system could collapse, or people could have their money stolen, or be double-spent into bankruptcy.
1265 2012-07-11 19:44:16 <gmaxwell> amiller: the _miners_ don't trust the oracles. The oracles are _your_ problem.
1266 2012-07-11 19:44:29 <TD> in contrast it's pretty safe to run arbitrary code inside an oracle. it can't do anything beyond sign your tx or not sign it.
1267 2012-07-11 19:44:49 <gmaxwell> You release a transaction locked to the consent of some ensemble of oracles. If the oracles cheat, too bad for you.. but bitcoin doesn't care.
1268 2012-07-11 19:44:50 <TD> the worst case scenario is, the transaction they're mediating goes the wrong way. but it only affects you. and nothing stops you having a big p2p network of oracles
1269 2012-07-11 19:45:07 <gmaxwell> And you should make better decisions about your oracles in the future. :)
1270 2012-07-11 19:45:10 <amiller> gmaxwell, i know that, i didn't mean to imply otherwise
1271 2012-07-11 19:45:26 <amiller> also for things like measuring my grandfather's death, i nkow there's no hope of relying _only_ on bitcoin miners
1272 2012-07-11 19:45:35 <gmaxwell> amiller: good I was about to say that.
1273 2012-07-11 19:45:36 <amiller> but for things that are just about simple state machine transitions, it could be unnecessary to have to choose oracles
1274 2012-07-11 19:46:13 <gmaxwell> amiller: I think thats wrong in practice unless you can make the validation as ~cheap as a regular finical transaction.
1275 2012-07-11 19:46:26 <gmaxwell> Otherwise the usage is paracitic on everyone else who just wants inflation proof money.
1276 2012-07-11 19:46:37 <gmaxwell> parasitic*
1277 2012-07-11 19:47:32 <TD> amiller: i think it's easier to debate specific use cases than the general case. so the chess example isn't that great.
1278 2012-07-11 19:47:34 <amiller> yeah, i'm assuming it's possible to pay a fair proportional fees for whatever costs i burden the network with
1279 2012-07-11 19:47:36 <TD> there are other ways to do it
1280 2012-07-11 19:47:41 <gavinandresen> speaking of "every additional bit of functionality is a potential attack vector" ...  I've been thinking about double spends and transaction replacement and fees
1281 2012-07-11 19:47:50 <TD> can you find an example of a compelling app that would interest the community, that needs a much more powerful script?
1282 2012-07-11 19:48:43 <amiller> TD, i suppose i should try. at least now i can purge my head of the random processes bullshit i've been struggling with for months.
1283 2012-07-11 19:48:51 <amiller> i bet i can find one
1284 2012-07-11 19:49:10 <TD> amiller: the issue is, you burden any user who runs a node, and they can't avoid processing your data. so if there are 25k nodes on todays tiny system, how do you recompense them for the storage and computation? you don't even know their costs
1285 2012-07-11 19:49:27 <TD> amiller: miners can choose to ignore your transactions if they don't want to process them
1286 2012-07-11 19:49:31 <TD> amiller: at least until they get included
1287 2012-07-11 19:49:54 <TD> amiller: the oracle protocol + micropayment channels do allow you to recompense the oracle nodes, giving people a genuine incentive to run them
1288 2012-07-11 19:50:22 <TD> amiller: and because you talk to each one directly, you can pick ones that are both trustworthy and cheap. whereas you can't really connect to every bitcoin node to give them some money for their troubles.
1289 2012-07-11 19:50:32 <TD> so it seems more elegant, from my perspective
1290 2012-07-11 19:50:34 <TD> gavinandresen: how so?
1291 2012-07-11 19:50:40 <gmaxwell> Redeeming an oracle locked transactions will require a transaction regardless... so you can output to a multisig of the same oracles to pay them.
1292 2012-07-11 19:51:07 ivan\ has quit (Ping timeout: 246 seconds)
1293 2012-07-11 19:52:15 <gavinandresen> TD: spamming a continuous stream of nSequence++ transaction variations into the network just because you can seems like the main risk to just re-enabling transaction replacement as Satoshi wrote it.
1294 2012-07-11 19:52:47 <TD> i suppose you could have a cooldown period. but if you see nodes as work queues with prioritization rules, it shouldn't be an issue
1295 2012-07-11 19:52:57 <TD> besides
1296 2012-07-11 19:52:59 <gavinandresen> TD: we disagreed about using alternative replacement rules (I like the "every replacement needs to pay more in fees", where "more" follows the free-transaction rules)
1297 2012-07-11 19:53:00 <TD> replacing a tx is cheap
1298 2012-07-11 19:53:03 <TD> the inputs have to be the same
1299 2012-07-11 19:53:11 <TD> so the signatures are already checked, i think. they should be cached.
1300 2012-07-11 19:53:55 <TD> given that for replacement to occur the zeroth input must be connected to the same output, and there's no point changing the signatures in the input as then it'd simply fail to verify at commit time ..... it's unclear to me you can DoS nodes this way
1301 2012-07-11 19:54:26 <TD> you could just do a trivial memcmp on the signature and if it's not the same as last time, ignore the update. i'd have to think carefully about if there were any issues with that
1302 2012-07-11 19:54:46 Zarutian has quit (Quit: Zarutian)
1303 2012-07-11 19:54:53 <TD> hmm, actually, never mind. ignore me.
1304 2012-07-11 19:54:58 <TD> i'm talking rubbish
1305 2012-07-11 19:55:01 <TD> of course the signatures have to be differen
1306 2012-07-11 19:55:05 <gavinandresen> good, I was about to dig out the code, I thought the sig covered nSequence
1307 2012-07-11 19:55:06 egecko has joined
1308 2012-07-11 19:55:43 <gavinandresen> So there's an unrelated thought that I think might actually be related
1309 2012-07-11 19:56:18 <TD> ok
1310 2012-07-11 19:56:18 <gavinandresen> The unrelated thought is the idea of broadcasting double-spend attempts instead of just dropping them... which also needs spam prevention
1311 2012-07-11 19:56:27 <TD> right. like the paper suggested.
1312 2012-07-11 19:56:27 ivan\ has joined
1313 2012-07-11 19:56:33 <gavinandresen> which paper?
1314 2012-07-11 19:56:34 <TD> btw the authors of that paper came to the last bitcoin switzerland meetup
1315 2012-07-11 19:56:43 <TD> the ETH paper on double spending attacks. the one that suggested double spend alerts.
1316 2012-07-11 19:56:46 <gmaxwell> gavinandresen: yea, I described how to do that on the mailing list enos ago.
1317 2012-07-11 19:56:56 <TD> ok, for anti-spam
1318 2012-07-11 19:57:16 <TD> let's say we multi-thread signature checking/tx verification. that needs to be done to buy more scaling time sooner or later anyway
1319 2012-07-11 19:57:25 <TD> the worker threads pop signatures/txns off a shared queue.
1320 2012-07-11 19:57:27 <gavinandresen> So if an input is spent twice, you relay a new 'doublespendinv' or something message
1321 2012-07-11 19:57:27 <gmaxwell> gavinandresen: the spamming goes away if each spendable input can only get one alert. So your ability to cause alerts is rate limited by your ability to create valid txn spending inputs.
1322 2012-07-11 19:57:44 <gavinandresen> (if spent a gazillion times, you just broadcast one though)
1323 2012-07-11 19:57:48 <gavinandresen> right
1324 2012-07-11 19:57:50 <gmaxwell> And the alert contains the two signatures, so it _proves_ there was a double spend.
1325 2012-07-11 19:57:53 <TD> now whenever a new piece of work comes in, the queue is locked and we figure out where it should go. if it's a replacement of a transaction that's already in the mempool, clear any pending work items related to the previous one and add it to the bottom
1326 2012-07-11 19:57:56 MC-Eeepc has joined
1327 2012-07-11 19:58:17 <TD> if it's from a newly broadcast, validly solved block, add the signatures at the top
1328 2012-07-11 19:58:29 <TD> or have multiple queues, that are drained in priority (that's probably better)
1329 2012-07-11 19:58:48 <TD> so you can spam tons of updates but the worst you can do is max out peoples CPUs. latency on valuable work won't be affected
1330 2012-07-11 19:59:45 <gmaxwell> gavinandresen: also you only relay the alert when you've also heard one of the txn.  So the alert identifies the input, then gives you the two signatures for the input.  If you haven't seen txn for that input you just hold the alert in the queue for a bit. When you do see a txn for that input you forward the alert.
1331 2012-07-11 20:00:06 <gavinandresen> gmaxwell: ACK.  why is there not a pull request for that yet :)
1332 2012-07-11 20:00:43 <TD> gmaxwell: don't you need both whole transactions?
1333 2012-07-11 20:01:00 <gavinandresen> TD:  I'm more worried about somebody trying to saturate network bandwidth... I suppose if you don't relay until after you validate... but if I spam 8 different versions of a transaction to 8 different peers
1334 2012-07-11 20:01:00 <TD> gmaxwell: nodes don't know which tx they saw, and you can't verify a signature with only a partial transaction
1335 2012-07-11 20:01:14 <gmaxwell> TD: you need everything the signatures cover, not the whole txn.
1336 2012-07-11 20:01:16 MC1984 has quit (Ping timeout: 246 seconds)
1337 2012-07-11 20:01:43 <gmaxwell> gavinandresen: because the devil is in the details! :)
1338 2012-07-11 20:02:12 <gavinandresen> doublespend message can just have the two txids, a node that doesn't already have both will request using regular inv message....
1339 2012-07-11 20:02:26 <TD> gavinandresen: if the tx isn't a replacement (two different txns with the same sequence numbers?) then it's a double spend and can be treated as such. if it's not IsNewerThan(), you don't have to verify the signatures
1340 2012-07-11 20:02:37 <gmaxwell> gavinandresen: ah, thats simpler indeed!
1341 2012-07-11 20:02:44 <gmaxwell> anyone who gives you the alert already has the txn.
1342 2012-07-11 20:03:18 drizztbsd has joined
1343 2012-07-11 20:04:44 <gavinandresen> TD: ok, I'll have to think more... I still don't think the incentives are right for miners, though.  If I want to break the rules I just spend an input involved in some complicated contract with a higher fee and economically rational miners will ignore all the previous non-final transactions and take the bird-in-the-hand fee
1344 2012-07-11 20:04:52 <TD> gavinandresen: but i think network bandwidth can be seen the same way as cpu time/disk seeks. it's a limited resource. prioritize stuff that looks abusive below the stuff that doesn't
1345 2012-07-11 20:05:04 <TD> but there's no need for hard cutoffs that could break in weird ways, or changes to fees
1346 2012-07-11 20:05:58 <gavinandresen> I'm all for moving away from hard cutoffs.  But I'm all for movement, too
1347 2012-07-11 20:07:06 <midnightmagic> TD/amiller: re chess game tied to the blockchain, there's a program called chronobit which is a special-case (timestamping) of tying basically arbitrary information to the main block chain via p2pool and merged-mining, so a large chunk of work for that is already done by mr Uukgoblin, here: https://github.com/goblin/chronobit/
1348 2012-07-11 20:08:14 <UukGoblin> chess game?
1349 2012-07-11 20:08:19 <UukGoblin> I was thinking about poker, but chess?
1350 2012-07-11 20:08:22 <UukGoblin> like, for money?
1351 2012-07-11 20:08:49 <midnightmagic> UukGoblin: it's a ways back in scrollback, I didn't see what the end purpose was, but it's amiller, so it's bound to be something interesting.
1352 2012-07-11 20:10:24 <TD> gavinandresen: i think that strategy is self defeating. if miners apply such a patch in a widespread manner, it just means nobody would rely on the feature because it'd not work as intended. that in turn means there'd be no income to be had from doing it.
1353 2012-07-11 20:10:45 <TD> gavinandresen: i mean, miners are not entirely self interested. if they were, we'd see empty blocks be the majority case.
1354 2012-07-11 20:11:55 <gmaxwell> TD: still you must admit something that aligns the greedy and the altruistic motivations is strictly superior to something that doesn't.
1355 2012-07-11 20:12:16 <TD> not if the cost of that alignment is very high.
1356 2012-07-11 20:12:24 <TD> if it can be done "for free" then sure
1357 2012-07-11 20:12:26 <gmaxwell> Thats the question then I guess.
1358 2012-07-11 20:12:28 <TD> yeah
1359 2012-07-11 20:12:55 <gavinandresen> I've just got a nagging feeling that the whole transaction replacement thing is really just an unnecessary special case for "this is a double spend, but it is a GOOD double spend"
1360 2012-07-11 20:13:02 <gmaxwell> If users can get what they need with some kind of highest-fee-wins then we can just make the default behavior greedy and everything always works as expected even with maximally selfish miners.
1361 2012-07-11 20:13:56 <TD> *requiring* constantly escalating fees seems suboptimal. if miners did form a conspiracy to try and undermine the feature, then nothing stops upgraded clients setting ever-escalating fees once it becomes necessary
1362 2012-07-11 20:14:04 <UukGoblin> amiller, midnightmagic - I was thinking a lot about oracles. Like, an oracle that can resolve a dispute about a poker game. Before the game, you send 2-of-3 to yourself, your opponent (heads-up poker), and the oracle. If players disagree about who should pay who, they submit a proof of the game to the oracle
1363 2012-07-11 20:14:16 <TD> i don't see any reason to help miners cause problems for the system. if they go out of their way to do so, that hurdle can be jumped if/when it arrives
1364 2012-07-11 20:14:18 <gmaxwell> TD: there are a lot of things in security where the single most criteria is correct expectations.
1365 2012-07-11 20:14:36 <UukGoblin> cool thing that even in 2-of-3 transactions (larger are limited, I think 10 is about max) can be securely multi-part signed by using VIFF framework
1366 2012-07-11 20:14:45 * helo fears transaction replacement
1367 2012-07-11 20:15:00 <amiller> UukGoblin, mm, speaking of inefficient but still awesome mpc
1368 2012-07-11 20:15:06 <gmaxwell> TD: Requring the fee go up even in small amounts is something people can deal with... expecting the rules to be followed and getting surprised by greedy miners is surprising. You can adapt (by increasing your fees), but only after the fact.
1369 2012-07-11 20:15:07 drizztbsd has quit (Read error: Connection reset by peer)
1370 2012-07-11 20:15:19 <TD> gmaxwell: i mean with this logic, fees should be required on all transactions. so far we got away without it. who knows for how long.
1371 2012-07-11 20:15:42 <gavinandresen> Maybe we just shouldn't allow non-final transactions into the memory pool at all.  Let all the fancy contract stuff happen outside miner's pools, they only pay attention to the end result.
1372 2012-07-11 20:15:46 <TD> gmaxwell: yeah but it only takes a few times for that to happen, for people to realize there is fraud going on and to upgrade their software ("upgrade now! secure yourself from replacement fraud"
1373 2012-07-11 20:15:56 <gmaxwell> TD: I'd agree except increasing the fees neatly reduces the DOS exposure.
1374 2012-07-11 20:16:08 <TD> gavinandresen: i think tx replacement is a highly valuable feature and would like to see it come back.
1375 2012-07-11 20:16:23 <gmaxwell> TD: so the protection against greedy miners is speculative but the antispam is not.
1376 2012-07-11 20:16:43 <gmaxwell> And two benefits is pretty attractive over a speculative cost of having to increase fees being a pratical burden.
1377 2012-07-11 20:16:50 <TD> gmaxwell: well, if we prioritize verification queues by fee, that probem is solved for the general case too. not just for tx replacement.
1378 2012-07-11 20:17:09 <gmaxwell> TD: only if we assume no one has anything else to do with their cpus/power/bandwidth.
1379 2012-07-11 20:17:21 <gavinandresen> ... but I can still cause you to go to 100% cpu, when better rules might mean you're idle most of the time
1380 2012-07-11 20:17:35 <gmaxwell> e.g. yes all dropping could be replaced with priority queues, but that would presume 100% usage of all resources all the time.
1381 2012-07-11 20:17:58 <TD> up to a limit you could specify with command line flags. but i think most nodes will naturally reach 100% cpu sooner or later anyway
1382 2012-07-11 20:17:59 <gmaxwell> That would be laughable for long term storage... and still laughable for bandwidth.. and almost laughable for cpu.
1383 2012-07-11 20:18:17 <TD> assuming success, of course :)
1384 2012-07-11 20:18:46 <gavinandresen> worse, I might be able to cause every node on the bitcoin network to go to 100% cpu usage all the time at a very low cost to myself
1385 2012-07-11 20:18:47 <gmaxwell> TD: dunno about that. we're mot many transistor density cycles before thats going to require a hardfork to increase blocksize to have the 100% cpu problem.
1386 2012-07-11 20:18:51 <TD> gavinandresen: being 100% cpu for a while if the DoS attack fails
1387 2012-07-11 20:19:00 <TD> the point of a DoS attack is to deny service to legitimate users
1388 2012-07-11 20:19:10 <UukGoblin> amiller, midnightmagic - secure oracles that do not-entirely-legal stuff (like deciding who wins a gambling game) might be prone to govt regulations, so would have to be inside tor or sth
1389 2012-07-11 20:19:11 <TD> if the network maxes out but legitimate users are still serviced with low latency, the attack is a failure
1390 2012-07-11 20:19:11 <gavinandresen> or to just "burn the world"
1391 2012-07-11 20:19:11 drizztbsd has joined
1392 2012-07-11 20:19:29 <UukGoblin> and being inside tor is kinda bad if you want reputation and high uptime
1393 2012-07-11 20:19:32 <TD> practical experience suggests attackers performing a useless DoS attack do invariably stop
1394 2012-07-11 20:19:42 <UukGoblin> so trusting on even distributed oracles for stuff is... :-/
1395 2012-07-11 20:19:44 <TD> (unless it's accidental, of course. you can have non-malicious DoS)
1396 2012-07-11 20:20:07 <TD> UukGoblin: refereeing a game isn't illegal in any country i know of. not even in the USA.
1397 2012-07-11 20:20:17 <amiller> the best oracle is a blockchain!
1398 2012-07-11 20:20:21 <TD> UukGoblin: that said, the reputation of an oracle is merely a function of uptime and number of correct responses to a challenge
1399 2012-07-11 20:20:48 <UukGoblin> amiller, the blockchain can't really solve complex multi-party computations like the ones carried out by libTMCG
1400 2012-07-11 20:20:50 <TD> UukGoblin: challenging an oracle is "free" (modulo whatever computation fee they charge, which should be small).
1401 2012-07-11 20:20:55 <gmaxwell> UukGoblin: you blind the oracle in any case.
1402 2012-07-11 20:21:00 variousnefarious has joined
1403 2012-07-11 20:21:00 <gavinandresen> TD: do any of the contract algorithms require that miners hold non-final transactions in their memory pools?  Couldn't the participants just have a separate pool for non-final transactions that they're involved in?
1404 2012-07-11 20:21:11 <UukGoblin> TD, well, the oracle would effectively be acting as a broker in a poker game...
1405 2012-07-11 20:21:40 <amiller> UukGoblin, there's no fundamental reason why it can't, it just might be expensive
1406 2012-07-11 20:21:50 <gmaxwell> UukGoblin: you can describe protocols for the oracle where it plausable doesn't know its validating poker. (and egads, do you really care about this? this is like the most boring use of oracles ever)
1407 2012-07-11 20:21:51 <TD> gavinandresen: yes. the system doesn't work if the transactions aren't remembered. i mean, they can obviously be on disk instead of in memory. the point is to provide a window of time in which miners/the network can be presented with the latest version
1408 2012-07-11 20:21:52 <amiller> if the fees were proportional and fair and tied to costs, then it would be super expensive to do s
1409 2012-07-11 20:22:00 <gmaxwell> (I want my oracles paying for cures for cancer)
1410 2012-07-11 20:22:01 <amiller> you could do it, but you've have had to buy a ton of bitcoins to afford it
1411 2012-07-11 20:22:11 <TD> gavinandresen: it's exactly to stop you broadcasting an earlier version of the transaction and doing a rollback
1412 2012-07-11 20:22:19 <amiller> thus increasing the value for miners (and everyone who likes bitcoin like non-miner validators)
1413 2012-07-11 20:22:27 <TD> gavinandresen: i don't see how to solve that unless miners have a memory pool with replaceable transactions.
1414 2012-07-11 20:22:34 <UukGoblin> amiller, well, then they'd be just like the regular poker rooms
1415 2012-07-11 20:23:17 Diapolo has left ()
1416 2012-07-11 20:23:18 <UukGoblin> amiller, costs of using an oracle should be minimal so that players could effectively play without a rake
1417 2012-07-11 20:23:30 <UukGoblin> amiller, anyways, what's this stuff about chess in blockchain?
1418 2012-07-11 20:23:33 <gavinandresen> TD: if Alice tries to rollback, Bob will see it....  that's going to be an issue no matter what, because if Alice is a miner and manages to produce a block she can rollback, right?
1419 2012-07-11 20:23:34 <amiller> if you can find a handful of oracles you're willing to trust, i suppose you might as well use them
1420 2012-07-11 20:23:42 <amiller> UukGoblin, the chess example sucks for a few reasons so i should probably bail on it :(
1421 2012-07-11 20:23:50 <UukGoblin> ah.
1422 2012-07-11 20:24:15 <UukGoblin> gmaxwell, well, I'd very much like to NOT have to use an oracle ;-)
1423 2012-07-11 20:24:44 <gmaxwell> UukGoblin: oracles are awesome.. and there is a lot of great stuff you _can't_ do without them.. might as well use 'em.
1424 2012-07-11 20:25:08 <amiller> for example if you have oracles you can have them mint your currency for you
1425 2012-07-11 20:25:14 <amiller> theyr'e called mintettes and ben laurie wrote about them
1426 2012-07-11 20:25:21 <TD> gavinandresen: if alice is a miner that has enough hash power to reliably commit rollbacks before the time window closes, then that's just a minor variant of what you already said. if it keeps happening, people will abandon the mechanism and nobody will trade with alice anymore. it's a pyhrric victory
1427 2012-07-11 20:25:32 <TD> gavinandresen: in most use cases i know of, alice is something like a wifi hotspot
1428 2012-07-11 20:25:32 <amiller> distributed consensus algorithms have been around for years and years, but bitcoin's special because it's anonymous and public
1429 2012-07-11 20:25:39 <TD> gavinandresen: it won't be able to produce a block on demand
1430 2012-07-11 20:26:12 <TD> unless there's a large fraction of mining power that doesn't follow the rules and accepts the rollback ... in which case, see above.
1431 2012-07-11 20:26:20 <gavinandresen> TD: you could always bribe big pools to disregard the nSequence rules.  That might happen anyway, because there's no guarantee that all miners see all the transaction variations
1432 2012-07-11 20:26:24 Z0rZ0rZ0r has joined
1433 2012-07-11 20:26:24 <UukGoblin> ah, well, in that case, would be cool generic oracles that could validate lots of various stuff
1434 2012-07-11 20:26:42 <UukGoblin> they would basically create more incentive for mining, if embedded properly with the blockchain
1435 2012-07-11 20:26:47 <UukGoblin> cool stuff.
1436 2012-07-11 20:27:02 <gmaxwell> UukGoblin: right. We can't avoid having them, so might as well make good use of them.. and get them mature.
1437 2012-07-11 20:27:04 <gavinandresen> TD: again, I've got a nagging feeling that the existing transaction replacement code just ain't right.
1438 2012-07-11 20:27:18 <TD> the time window is supposed to be large enough that transaction propagation can take place. and normally, it's unnecessary anyway. in the case where both parties are co-operating, the tx is never replaced
1439 2012-07-11 20:27:27 <amiller> the nice thing about an oracle is you don't have to _fully_ trust them, they get a sort of limited editorial control
1440 2012-07-11 20:27:32 <TD> you only ever need to perform a replacement if your party DOES try to do a rollback
1441 2012-07-11 20:27:33 <gavinandresen> TD: e.g. instead of messing with sequence numbers, it seems to me decreasign lockTime for subsequent transactions would be the right thing to do
1442 2012-07-11 20:27:51 <amiller> they can refuse to operate at all, and they can exert timing preference over some valid options
1443 2012-07-11 20:27:54 <amiller> but they can't do anything 'invalid'
1444 2012-07-11 20:28:05 <amiller> so you factor away quite a bit of your reliance on them and put that reliance in the blockchain
1445 2012-07-11 20:28:07 <TD> so obscure race conditions in that functionality shouldn't ever be a practical problem. the very existence of the mechanism means it shouldn't need to be used.
1446 2012-07-11 20:28:18 <amiller> the reliance that's left is hopefully small enough.
1447 2012-07-11 20:28:23 <amiller> gmaxwell, yeah i agree now.
1448 2012-07-11 20:28:55 <TD> gavinandresen: locktime is gobal. seqnums are per input, for the specific reason of allowing multi-party contracts, like micropayment channels
1449 2012-07-11 20:29:07 <UukGoblin> amiller, well, there should be oracle federations
1450 2012-07-11 20:29:08 <TD> i think micropayment channels could be pretty useful and a competitive advantage for bitcoin in future
1451 2012-07-11 20:29:11 <gmaxwell> amiller: one fun thing to do is you can use oracles to 'bond' other oracles. E.g. to create an oracle you put up some bond... secured by other trusted oracles.. that says no one can prove you cheat. If someone proves you cheat you lose your bond.
1452 2012-07-11 20:29:15 <TD> so i'm very reluctant to try and "improve" on satoshis design here
1453 2012-07-11 20:29:24 <UukGoblin> like, 5-10 oracles in a network, all semi-trusting each other
1454 2012-07-11 20:29:30 <amiller> gmaxwell, if bitcoin had a general purpose state machine, the 'bond' could exist entirely in the blockchain
1455 2012-07-11 20:29:31 <TD> i'm not convinced the miner incentive problem is real
1456 2012-07-11 20:29:34 <UukGoblin> then if one goes down, user submits a query to another
1457 2012-07-11 20:29:38 <TD> the existing design already has it. we see it occasionally with botnets.
1458 2012-07-11 20:29:55 <TD> professional miners do take into account more than immediate 7-day profit. and if BFL succeed all mining will be professional
1459 2012-07-11 20:30:02 <UukGoblin> and proving that one oracle cheats should also be easy, yeah ;-]
1460 2012-07-11 20:30:15 <gmaxwell> amiller: but validating your nontrivial bond doesn't prevent inflation. So it's a burden that the rest of the network would be disinclined to take.
1461 2012-07-11 20:30:31 <gavinandresen> TD: if we can solve the "I'll just spam the network with every-increasing-nSequence transaction variations with a lockTime next week, then double-spend the input to myself before next week, and giggle as everybody's CPU usage goes to 100%" problem then I'd be ok
1462 2012-07-11 20:30:37 <TD> gmaxwell: that's a neat idea
1463 2012-07-11 20:30:51 <gmaxwell> amiller: besides, if you'll accept one oracle, you can accept others.. And then you always keep the bitcoin txn small and trivial to validate.
1464 2012-07-11 20:31:30 <TD> gavinandresen: well, like i said, i don't see pushing cpu usage to 100% to be a problem as long as the network functions ok during the attack. an attack that achieves nothing will go away.
1465 2012-07-11 20:31:33 <amiller> perhaps someday there will be an alternate blockchain that's a generally useful oracle, as well as the bitcoin network where people only care about their goldlike currency
1466 2012-07-11 20:31:40 <UukGoblin> hang on, why do we need a new currency? :-O
1467 2012-07-11 20:31:55 <amiller> then perhaps since the alternate blockchain is more useful, its value will exceed bitcoin's and everyone wil move over
1468 2012-07-11 20:31:56 <TD> gavinandresen: so it wouldn't stay pegged at 100% for ever
1469 2012-07-11 20:32:23 <amiller> someday goldlike currency will be considered a silly and unnecessary anachronism, but i totally don't expect anyone to agree with this
1470 2012-07-11 20:32:26 <TD> amiller: it could be the case, yes. or maybe something that solves the same problems as bitcoin but is implemented on top of general MPC or something
1471 2012-07-11 20:32:39 <amiller> mpc on top of oracle-chain
1472 2012-07-11 20:32:42 <amiller> it's just code
1473 2012-07-11 20:32:53 <TD> if you have MPC it's unclear to me you even need a chain. but i never thought about it much
1474 2012-07-11 20:33:20 <TD> you could just submit balance adjustments as inputs to the shared computation and get balances back out
1475 2012-07-11 20:33:28 <gmaxwell> amiller: there are uses of bitcoin that don't do anything to goof up the currency use.. e.g. uuk's timestamper.
1476 2012-07-11 20:33:41 <amiller> sure
1477 2012-07-11 20:33:43 <gmaxwell> amiller: so bitcoin can provide that 'for free'. Free uses are good. :)
1478 2012-07-11 20:34:09 <amiller> certainly, any preference people have for oraclecoin vs bitcoin can only be about things oraclecoin does that bitcoin cannot
1479 2012-07-11 20:35:03 <UukGoblin> amiller, why do we need a separate currency? Why can't oracles just be paid in bitcoins, i.e. as transaction fees?
1480 2012-07-11 20:35:08 <gmaxwell> but it also means that oraclecoin doesn't have to solve timestamping if bitcoin can provide timestamping reliable enough for its purposes. And not just timestamping, timestamping also means total-order.
1481 2012-07-11 20:36:04 <UukGoblin> gmaxwell, well, one issue is that bitcoin can't exactly provide high-precision timestamping. It's limited at least to 10 minutes.
1482 2012-07-11 20:36:27 <UukGoblin> so you could have a sort of altchain that'd add the precision required and get it MM'ed.
1483 2012-07-11 20:36:47 <gmaxwell> who says time has anything to do with minutes?
1484 2012-07-11 20:36:59 <gmaxwell> You can measure time in bitcoin blocks, and for _that_ its totally precise.
1485 2012-07-11 20:37:07 drizztbsd has quit (Ping timeout: 246 seconds)
1486 2012-07-11 20:37:13 nimdAHK has quit (away!43fc679d@gateway/web/freenode/ip.67.252.103.157|Ping timeout: 245 seconds)
1487 2012-07-11 20:37:19 drizztbsd has joined
1488 2012-07-11 20:37:22 <amiller> i'm going out for dinner in about ten blocks
1489 2012-07-11 20:37:26 <UukGoblin> gmaxwell, for scenarios like a poker game, you kinda need every in-game action timestamped
1490 2012-07-11 20:37:27 <TD> heh
1491 2012-07-11 20:37:58 <gmaxwell> UukGoblin: bitcoin's wall time is far sloppier than 10 minutes in any case..
1492 2012-07-11 20:38:18 <gmaxwell> since miners can freely choose back to the median and up to two hours into the future.
1493 2012-07-11 20:38:22 <UukGoblin> with chronobit, you can only get about several hours accuracy
1494 2012-07-11 20:38:42 <UukGoblin> between ~1 minute and ~4 hours until you find the share + about 6h until p2pool finds a share
1495 2012-07-11 20:38:45 <gmaxwell> but that has nothing to do with bitcoin and everything to do with distributed time being hard.
1496 2012-07-11 20:38:49 <UukGoblin> I mean block.
1497 2012-07-11 20:39:04 <gmaxwell> I did create a really psycho design for doing truly decenteralized time.
1498 2012-07-11 20:39:06 <UukGoblin> and what you said.
1499 2012-07-11 20:39:13 <gmaxwell> but its psycho^2.
1500 2012-07-11 20:39:17 datagutt has quit (Quit: kthxbai)
1501 2012-07-11 20:39:43 <amiller> gmaxwell, i think that's asymptotically insanity-optimal
1502 2012-07-11 20:39:51 <gmaxwell> amiller: https://people.xiph.org/~greg/decentralized-time.txt
1503 2012-07-11 20:39:58 <UukGoblin> well, what I'm looking for, in general, is being able to tie various MPCs to bitcoin :->
1504 2012-07-11 20:40:20 <UukGoblin> that'd allow various distributed games that use bitcoin as in-world currency
1505 2012-07-11 20:41:09 <amiller> the two variations i'm looking at for bitcoin now are 1) you don't know the message delay and 2) you don't know the size of the network
1506 2012-07-11 20:41:13 [Tycho] has quit (Read error: Operation timed out)
1507 2012-07-11 20:41:17 <amiller> i think those end up being similar to the location uncertainty you have here
1508 2012-07-11 20:42:40 <amiller> that's crazy
1509 2012-07-11 20:42:43 <amiller> terrestrial gps
1510 2012-07-11 20:43:04 tsche has quit (Read error: Operation timed out)
1511 2012-07-11 20:43:22 <amiller> reflect your beacons off known astral bodies and triangulate as usual, use a public blockchain consensus to maintain the reference mapping, is that about right?
1512 2012-07-11 20:43:56 <gmaxwell> amiller: so see the idea there is that nodes all observe something common.. and then use a POW chain to build a majority consensus about the correct time to use for the common thing.  I use RF noise from the sun in that explination.
1513 2012-07-11 20:44:22 <gmaxwell> and right, if you use multiple common things with different locations you can then use their relative offsets to build decenteralized location services.
1514 2012-07-11 20:44:42 <TD> UukGoblin: you can do threshold signatures with MPC, iirc, so you could have the parties inputs be (game state, threshold share, payment tx hash) and output be (unified signature) if game state matches - i guess
1515 2012-07-11 20:44:44 <TD> i don't know much about mpc
1516 2012-07-11 20:44:47 <gmaxwell> which is nuts and fails on lots of boring engineering grounds, at least using natural sources as the exciter.... but it's still fun to think about.
1517 2012-07-11 20:45:22 <UukGoblin> TD, yeah, I think it's sort of doable with this VIFF-style MPC RSA sig
1518 2012-07-11 20:46:14 <amiller> has anyone put a bitcoin mining satellite in sapce
1519 2012-07-11 20:46:23 <amiller> that shouldn't be too hard would it
1520 2012-07-11 20:46:29 <gmaxwell> amiller: more realistic is distributed GPS service using FM radio stations as the common signals the nodes observe. But you have to then deal with people maliciously moving the fm transmitters, so you have a problem with the system being underdetermined without at least one unmovable reference point.
1521 2012-07-11 20:46:33 <amiller> just a gpu and a solar panel?
1522 2012-07-11 20:46:54 <UukGoblin> amiller, more like ASIC
1523 2012-07-11 20:47:00 <gmaxwell> amiller: oracle in space is more exciting.
1524 2012-07-11 20:47:29 <gmaxwell> Tamperproof by virtue of its orbit.
1525 2012-07-11 20:47:35 <amiller> orbitcle
1526 2012-07-11 20:47:43 <amiller> that's pretty awesome too lol
1527 2012-07-11 20:47:47 <amiller> hmm
1528 2012-07-11 20:48:09 <amiller> imagine onion routing between satellites
1529 2012-07-11 20:48:14 <UukGoblin> gmaxwell, being in orbit doesn't provide tamperproofability
1530 2012-07-11 20:48:45 <UukGoblin> however, I guess you could try to secure it and get it to self-destruct upon detecting tampering attempts (i.e. proximity)
1531 2012-07-11 20:48:58 <TD> lol. that sounds reliable.
1532 2012-07-11 20:49:02 <TD> a self destructing satellite.
1533 2012-07-11 20:49:03 <gmaxwell> amiller: you could have 77 of them and call it iridium
1534 2012-07-11 20:49:04 <luke-jr> self-destruct might itself be considered tampering <.<
1535 2012-07-11 20:49:24 <TD> i think GPS is basically "tamperproof" by now given how much vital infrastructure would fail if it started reporting garbage
1536 2012-07-11 20:49:32 <gmaxwell> UukGoblin: you could put it in a very high energy orbit .. if it's small enough it wouldn't take much energy to put it there.. but to move the _attacker_ into the orbit would take exponentially more energy.
1537 2012-07-11 20:49:34 <luke-jr> better to have it use fuel reserves to avoid getting close to anything
1538 2012-07-11 20:49:40 <luke-jr> but how do you keep it fueled?
1539 2012-07-11 20:50:09 <TD> gmaxwell: unless you can fool ground receivers into thinking they're hearing from the original satellite
1540 2012-07-11 20:50:16 <TD> the weak point there would be the terrestrial key backups
1541 2012-07-11 20:50:29 <TD> if you have the balls to launch something into space without any backup of the private keys .......
1542 2012-07-11 20:50:31 <TD> more power to you!
1543 2012-07-11 20:50:34 <UukGoblin> luke-jr, ion thrusters?
1544 2012-07-11 20:50:44 <amiller> cheaper just to put up more tiny satellites
1545 2012-07-11 20:50:49 * TD wonders how GPS keys are managed
1546 2012-07-11 20:50:51 <luke-jr> TD: even then, the weak point is the point where you get the pubkey
1547 2012-07-11 20:50:58 <TD> luke-jr: ah ha. that's true :)
1548 2012-07-11 20:51:12 <TD> i guess it could be signed by people on IRC :)
1549 2012-07-11 20:51:17 <UukGoblin> heheh
1550 2012-07-11 20:51:22 <luke-jr> a secure private key is useless, if everyone is fooled into using another pubkey
1551 2012-07-11 20:51:23 <luke-jr> :p
1552 2012-07-11 20:51:29 <gmaxwell> TD: you assume it's keyed and not obfsucated.. keep in mind gps is fairly old.. there are actually a fair number of old military sats that people keep abusing for other uses.
1553 2012-07-11 20:51:54 <gmaxwell> stuff with open linear transponders that you can key up with a ham radio and use to coordinate your drug running! (no kidding!)
1554 2012-07-11 20:52:20 <luke-jr> I always thought "military GPS" was merely regulation - so GPS manufs were forbidden from being more accurate than X metres
1555 2012-07-11 20:53:09 <gmaxwell> luke-jr: nah, each gps bird produces two signals, one is encrypted. The encrypted one is much higher accuracy. There are also artifical limits, but they're mostly just making the GPS shut off at high speeds
1556 2012-07-11 20:53:16 <gmaxwell> (to prevent the use for guided rockets)
1557 2012-07-11 20:53:34 <TD> the encryption was disabled a long time ago, iirc
1558 2012-07-11 20:53:43 <gmaxwell> TD: SA was disabled a long time ago..
1559 2012-07-11 20:53:49 [Tycho] has joined
1560 2012-07-11 20:53:55 <gmaxwell> Which was the intention reduction in the precision of the non-encrypted signal.
1561 2012-07-11 20:54:05 <TD> ah
1562 2012-07-11 20:54:41 <gmaxwell> L2 is still encrypted, thats the only thing that makes it MITM resistant.   Though you don't have to decrypt it to use it if you have a base station to reference with.  This is what real-time kinematic gps does.. and its what most surveyers use.
1563 2012-07-11 20:55:33 <gmaxwell> (basically you can do timing offset measurements off the _carrier_ of the encrypted signal.. then you just ignore the bits.. but to use that you need to know an initial carrier offset to position measurement with sub-cm high accuracy)
1564 2012-07-11 20:56:11 <UukGoblin> ah, heh, timing attack :->
1565 2012-07-11 20:56:24 <luke-jr> not quite :p
1566 2012-07-11 20:56:43 <luke-jr> most of GPS is implemented by contrasting the radio signal strengths :p
1567 2012-07-11 20:56:55 <OneEyed> gmaxwell: don't you have to time offset measurements off the carrier anyway, even if you decrypt the content?
1568 2012-07-11 20:57:00 <luke-jr> so it is probably just a matter of getting the encrypted sat schedule elsewhere
1569 2012-07-11 20:57:50 <gmaxwell> OneEyed: no! GPS sends a pseudorandom digital sequence at 1mbit for the cleartext stream 10mbit for the encrypted one. You can get timing up to the bit duration (times the speed of light) just from the digital signal.
1570 2012-07-11 20:58:11 Icoin has joined
1571 2012-07-11 20:58:27 <gribble> New news from bitcoinrss: Diapolo opened pull request 1584 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1584>
1572 2012-07-11 20:59:01 <gmaxwell> OneEyed: the differences are great enough that even the 1mbit signal lets you range the sats.
1573 2012-07-11 20:59:38 <OneEyed> 3e8/1e9 => 0.3m ? What did I do wrong?
1574 2012-07-11 20:59:55 <UukGoblin> gmaxwell, interesting, that decentralized-time.txt. Regarding location, can you not determine it based on plain observation of the sky in the visible spectrum (i.e. webcams)?
1575 2012-07-11 21:00:44 <UukGoblin> I'm not sure... but shouldn't it be possible to get both time and location from observation of the sky?
1576 2012-07-11 21:01:11 <gmaxwell> OneEyed: thus 3 meter accuracy from consumer gps.
1577 2012-07-11 21:01:13 <OneEyed> Ooops, 1e6 for 1Mbit
1578 2012-07-11 21:01:37 <OneEyed> So wouldn't that be 300m?
1579 2012-07-11 21:01:43 <gmaxwell> er. right.
1580 2012-07-11 21:02:03 <gmaxwell> OneEyed: you get 3m from tracking the CA carrier I guess.
1581 2012-07-11 21:02:08 <OneEyed> 1µs precision doesn't seem to be enough
1582 2012-07-11 21:03:29 <gribble> New news from bitcoinrss: Diapolo opened pull request 1585 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1585>
1583 2012-07-11 21:04:47 <gmaxwell> OneEyed: ah appearently this is solved by the fact that a normal solution uses at least four ranges, when three is enough to uniquely define your location.
1584 2012-07-11 21:05:10 <gmaxwell> (been a long time since I dorked with gps)
1585 2012-07-11 21:05:21 <UukGoblin> 4 is required to get your loc + time afair?
1586 2012-07-11 21:05:28 <phantomcircuit> anybody know how i can get blockchain.info to show the connections between one address and another?
1587 2012-07-11 21:05:40 <OneEyed> gmaxwell: that may help, but I'm not convinced that this is enough
1588 2012-07-11 21:06:18 <OneEyed> (I'm reading the wikipedia page at the same time)
1589 2012-07-11 21:09:39 <OneEyed> CPGPS (based on the carrier phase measurement) + DGPS can give 30 centimeters according to http://en.wikipedia.org/wiki/GPS_augmentation
1590 2012-07-11 21:10:18 <UukGoblin> that's all based on the assumption that USA doesn't just shut it down
1591 2012-07-11 21:10:42 <OneEyed> Then we switch to http://en.wikipedia.org/wiki/Galileo_(satellite_navigation)
1592 2012-07-11 21:10:58 <UukGoblin> that's not even up yet
1593 2012-07-11 21:11:15 <UukGoblin> and in case of a war, europe will shut galileo too
1594 2012-07-11 21:11:19 <MC-Eeepc> what makes gps cut off at high speed
1595 2012-07-11 21:11:26 <UukGoblin> for the same reasons as USA
1596 2012-07-11 21:11:26 <gmaxwell> OneEyed: see also http://en.wikipedia.org/wiki/Real_Time_Kinematic
1597 2012-07-11 21:12:15 <gmaxwell> OneEyed: but normal consumer gpses don't do cpgps.. (well unless they just started to 0_o), just the stupidly expensive surveyer equipment does.
1598 2012-07-11 21:13:21 <OneEyed> gmaxwell: I guess you have to be static given the computation time
1599 2012-07-11 21:13:35 drizztbsd has quit (Quit: Konversation terminated!)
1600 2012-07-11 21:14:36 <gmaxwell> these wikipedia articles are really good. I wish they existed 10 years ago.
1601 2012-07-11 21:15:38 <UukGoblin> we should really timestamp them
1602 2012-07-11 21:16:01 <UukGoblin> so that 10 years later, if someone fiddles with them, we can see the evidence
1603 2012-07-11 21:16:13 luke-jr has quit (Ping timeout: 248 seconds)
1604 2012-07-11 21:17:01 <UukGoblin> ah, also - what do you guys think about OFFsystem? I'm looking for a reliable anonymous p2p storage solution
1605 2012-07-11 21:17:19 <UukGoblin> freenet has the annoying property of people having to do re-inserts manually to ensure data is findable
1606 2012-07-11 21:17:43 <UukGoblin> however with OFF it seems to me that data can be kept for much longer, as blocks get reused over and over again
1607 2012-07-11 21:18:37 <gmaxwell> p2p storage seems pretty intractable to me. Freenode at least preserves CHKs if they remain popular.
1608 2012-07-11 21:18:57 * gmaxwell hasn't seen offsystem.
1609 2012-07-11 21:19:17 <UukGoblin> yeah, popularity ensures it'll be there
1610 2012-07-11 21:19:27 <UukGoblin> but lots of excellent content isn't very popular, and I'd really like to keep it
1611 2012-07-11 21:19:55 <UukGoblin> also makes freenet kinda useless for personal encrypted backups, unless you take lots of bandwidth reinserting them every few days (or however much is needed)
1612 2012-07-11 21:20:42 <gmaxwell> oh god this sounds like that stupidity that the excellent color of my bits article was written about.
1613 2012-07-11 21:21:03 <UukGoblin> have a look, OFFsystem's principle is pretty simple - it splits data X into three blocks A, B and C such that A xor B xor C = X, and then submits these A-C, and later Y gets done as A xor B xor D
1614 2012-07-11 21:21:04 <OneEyed> UukGoblin: I don't understand your rant, if you store in a p2p network, given that storage is not infinite, you have to specify an expiration policy. Why is refreshing a bad one?
1615 2012-07-11 21:21:10 <gmaxwell> reinsert or request is kinda fundimental, otherwise you just have a tragedy of the commons.
1616 2012-07-11 21:21:46 <jgarzik> true p2p storage only needs to be refreshed with additional bitcoins
1617 2012-07-11 21:21:55 <UukGoblin> OneEyed, well, I guess the rant is about not being able to define it precisely (be it in minutes, bitcoin blocks, whatever)
1618 2012-07-11 21:22:47 <gmaxwell> UukGoblin: http://ansuz.sooke.bc.ca/entry/23 is ranting about the misguided motivations which also fuled Offsystem, though it doesn't have anything to do with its usefulness as distributed storage.
1619 2012-07-11 21:23:04 <UukGoblin> hmm the "store this for 1 year for me, here's your 1.20 BTC" idea is doable using that self-replicating bot thingy
1620 2012-07-11 21:23:52 <UukGoblin> gmaxwell, well an issue I have with OFFsystem is that its crypto doesn't sound very... secure
1621 2012-07-11 21:23:59 <UukGoblin> i.e. it doesn't really use crypto at all
1622 2012-07-11 21:24:39 <gmaxwell> UukGoblin: they're trying to do some iditoic shell game to evade copyright. "Oh this is just random data, if you xor it this way you get PI! and that way you get bambi! but since you can do either you can't claim its copyrighted.. nah nah nah nah!"
1623 2012-07-11 21:24:44 darsk1ez has quit (Ping timeout: 245 seconds)
1624 2012-07-11 21:24:48 <UukGoblin> I've played Paranoia ;-)
1625 2012-07-11 21:24:50 <gmaxwell> (and you repeat that mantra from prison every day)
1626 2012-07-11 21:25:09 darkskiez has quit (Ping timeout: 245 seconds)
1627 2012-07-11 21:25:18 <UukGoblin> gmaxwell, yeah, sounds like OFF
1628 2012-07-11 21:25:48 darsk1ez has joined
1629 2012-07-11 21:26:37 <UukGoblin> avoiding copyright is one thing, being able to hide your actions against active adversaries is another
1630 2012-07-11 21:27:15 <gmaxwell> UukGoblin: yea, the block identity for anonymity thing is interesting.
1631 2012-07-11 21:27:23 <gmaxwell> but it means a lot of bloat.
1632 2012-07-11 21:27:36 <UukGoblin> yeah, you have to transmit ~3x amount the data you'd normally do
1633 2012-07-11 21:27:43 DamascusVG has quit (Quit: I Quit - http://www.youtube.com/watch?v=9p97zsQ51Rw)
1634 2012-07-11 21:27:44 <UukGoblin> but that seems like a reasonable trade-off to me
1635 2012-07-11 21:27:45 <gmaxwell> and it sounds like the anonymity could be trivially removed with techniques from compressed sensing.
1636 2012-07-11 21:27:57 darkskiez has joined
1637 2012-07-11 21:28:09 luke-jr has joined
1638 2012-07-11 21:28:11 <UukGoblin> now that's a keyword I haven't heard of before
1639 2012-07-11 21:28:24 <gmaxwell> wow that wikipedia article isn't very useful!
1640 2012-07-11 21:28:58 <UukGoblin> "a technique for finding sparse solutions to underdetermined linear systems."? yeah, doesn't exactly tell me much
1641 2012-07-11 21:29:31 <sipa> wow long discussion
1642 2012-07-11 21:29:39 <sipa> what did i miss?
1643 2012-07-11 21:29:57 <gmaxwell> sipa: the ontopic stuff is hours ago.
1644 2012-07-11 21:30:18 <UukGoblin> sipa, chess, oracles, poker, distributed time, GPS, and now p2p storage
1645 2012-07-11 21:30:30 <sipa> i scrolled through pages and pages of fee discussion
1646 2012-07-11 21:31:03 <UukGoblin> ah, I do wonder what the latest stuff on fees is
1647 2012-07-11 21:31:03 <gmaxwell> UukGoblin: say you measure a subset of pixels at random from an photo.  And you know in advance that the discrete cosine transform of the image is sparse (has few non zero values). For images you know this because its basically true for real images, because they're smooth which is why jpeg works.
1648 2012-07-11 21:31:40 <gmaxwell> UukGoblin: compressed sensing are techniques which tell you how to recover the most likely sparse coefficients under those assumptions, and from there the whole image.
1649 2012-07-11 21:32:25 MC-Eeepc has quit (Ping timeout: 265 seconds)
1650 2012-07-11 21:32:29 <UukGoblin> but... stuff xored with a random block won't have these assumptions, will it?
1651 2012-07-11 21:32:32 <gmaxwell> UukGoblin: for anonymity, you sample which blocks people are requesting... and you know that the files each have a finite number of blocks. So you create an NxM matrix for blocks vs files.. and you know in advance this is sparse but you don't know the values.
1652 2012-07-11 21:33:02 <gmaxwell> but you do know that users fetch whole files, and to fetch a file you need its blocks.
1653 2012-07-11 21:33:27 <gmaxwell> so there is your sampled data. which is linearly related to the blocks that align with samples.
1654 2012-07-11 21:33:34 <UukGoblin> hmm but but
1655 2012-07-11 21:33:48 <UukGoblin> users can request blocks for "harmless" files
1656 2012-07-11 21:34:09 <UukGoblin> so the most you'll see is that a user has either downloaded 2 free files or 1 copyrighted file, for instance
1657 2012-07-11 21:34:26 <UukGoblin> which, agreeably, isn't hiding your actions very well.
1658 2012-07-11 21:34:35 <gmaxwell> UukGoblin: not so, because they can't have 100% overlap or the files would have to be the same.
1659 2012-07-11 21:34:53 <gmaxwell> e.g. two sane free files don't xor into one sane copyrighted file. :)
1660 2012-07-11 21:35:24 <UukGoblin> freefile1 gets represented as A xor B xor C, freefile2 as B xor C xor D, and copyrightedfile as B xor C xor D?
1661 2012-07-11 21:35:53 <UukGoblin> OFFsystem chooses existing blocks and adds random ones
1662 2012-07-11 21:36:01 <UukGoblin> okay, maybe it'd make sense with 3 free files
1663 2012-07-11 21:36:01 <OneEyed> Then freefile2 is equal to copyrightedfile :)
1664 2012-07-11 21:36:16 <UukGoblin> uh...
1665 2012-07-11 21:36:26 rlifchitz has quit (Remote host closed the connection)
1666 2012-07-11 21:36:27 <gmaxwell> UukGoblin: you've got an information theory limit there. there must be at least as many distinct blocks as files.
1667 2012-07-11 21:36:33 <UukGoblin> gah... I screwed this up
1668 2012-07-11 21:37:14 <UukGoblin> ff1 = A xor B xor C, ff2 = D xor E xor F, ff3 = G xor H xor I, cf = C xor F xor I
1669 2012-07-11 21:37:20 TD has quit (Quit: TD)
1670 2012-07-11 21:37:28 <UukGoblin> gmaxwell, yes
1671 2012-07-11 21:37:56 <UukGoblin> but number of files is huge... I mean I don't see a problem with that limit
1672 2012-07-11 21:37:57 <gmaxwell> Also, unless all files are the same, there must be multiple blocks per large file, which would remove anonymity fast.
1673 2012-07-11 21:39:16 <UukGoblin> assuming that ff1..3 are of similar size to cf, then not necessarily
1674 2012-07-11 21:40:03 <UukGoblin> and since the adversary doesn't really know about ALL files stored, they can't prove to you that you downloaded something copyrighted... they can high-probability guess though
1675 2012-07-11 21:40:38 <OneEyed> UukGoblin: the problem, at least here in France, is not when you download
1676 2012-07-11 21:40:41 <OneEyed> It's when you upload
1677 2012-07-11 21:40:45 <gmaxwell> UukGoblin: right, thats fair enough, I can look at what you fetch and say you either wanted X and Y or Z ...
1678 2012-07-11 21:41:03 <OneEyed> If we can show that you're uploading something which can trivially be recombined into copyrighted work, then you're in trouble
1679 2012-07-11 21:41:26 <gmaxwell> UukGoblin: and even if you were equally likely to want all of them... X*Y is much less likely than Z.
1680 2012-07-11 21:42:11 <UukGoblin> OneEyed, hm
1681 2012-07-11 21:42:29 <gmaxwell> OneEyed: that would be better the files were all encrypted and random nodes remixed files blindly so that it would be hard to tell if something was an upload or a remix without observing everything.
1682 2012-07-11 21:42:39 <UukGoblin> OneEyed, even if you can plausibly claim you don't know what you're uploading (i.e. you're relaying)?
1683 2012-07-11 21:43:24 <luke-jr> gmaxwell: pm
1684 2012-07-11 21:44:13 <luke-jr> OneEyed: so, random internet routers in France are liable for copyright infringement if someone sends content through them illegally?
1685 2012-07-11 21:45:48 drizztbsd has joined
1686 2012-07-11 21:47:42 <UukGoblin> I just asked that ;-]
1687 2012-07-11 21:48:24 nimdAHK has joined
1688 2012-07-11 21:48:34 <OneEyed> luke-jr: the law also says that there can be no crime if there has been no intention to commit one
1689 2012-07-11 21:49:02 <UukGoblin> uhm... interesting
1690 2012-07-11 21:49:10 <gmaxwell> except for strict liability...
1691 2012-07-11 21:49:26 <OneEyed> (could discuss that all night long, but I have to go now, bbl)
1692 2012-07-11 21:49:33 <UukGoblin> was running an internet router an intention to commit copyright infringement?
1693 2012-07-11 21:49:44 <UukGoblin> (yeah, me too, actually)
1694 2012-07-11 21:50:21 <gmaxwell> UukGoblin: in US tradition copyright infringement is just a tort.. not a crime.. we've added some criminal charges, but still hardly treat it what way.
1695 2012-07-11 21:51:40 sytse has quit (Ping timeout: 246 seconds)
1696 2012-07-11 21:54:04 agricocb has quit (Quit: Leaving.)
1697 2012-07-11 21:55:30 eoss has joined
1698 2012-07-11 21:55:31 eoss has quit (Changing host)
1699 2012-07-11 21:55:31 eoss has joined
1700 2012-07-11 21:58:55 sytse has joined
1701 2012-07-11 22:00:43 scobrabyte has joined
1702 2012-07-11 22:00:55 ThomasV has quit (Ping timeout: 240 seconds)
1703 2012-07-11 22:10:26 nicky has joined
1704 2012-07-11 22:12:47 agricocb has joined
1705 2012-07-11 22:23:31 drizztbsd has quit (Ping timeout: 246 seconds)
1706 2012-07-11 22:25:03 nicky has quit ()
1707 2012-07-11 22:25:48 scobrabyte has quit (Quit: Leaving)
1708 2012-07-11 22:26:12 drizztbsd has joined
1709 2012-07-11 22:28:12 CodesInChaos has quit (Ping timeout: 244 seconds)
1710 2012-07-11 22:32:31 minimoose has quit (Quit: minimoose)
1711 2012-07-11 22:32:37 e0s_ has joined
1712 2012-07-11 22:32:41 e0s_ has quit (Read error: Connection reset by peer)
1713 2012-07-11 22:34:56 DamascusVG has joined
1714 2012-07-11 22:37:02 slush1 has quit (Ping timeout: 252 seconds)
1715 2012-07-11 22:38:26 sirk390 has quit (Quit: Leaving.)
1716 2012-07-11 22:44:14 jurov is now known as jurov|away
1717 2012-07-11 22:46:40 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1718 2012-07-11 22:53:01 slush has joined
1719 2012-07-11 23:03:12 Turingi has quit (Read error: Connection reset by peer)
1720 2012-07-11 23:05:31 brwyatt is now known as brwyatt|Away
1721 2012-07-11 23:05:41 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1722 2012-07-11 23:06:55 slush has quit (Ping timeout: 240 seconds)
1723 2012-07-11 23:08:34 slush has joined
1724 2012-07-11 23:28:00 <t7> does bitcoind build on arm?
1725 2012-07-11 23:28:04 <t7> i mean target arm
1726 2012-07-11 23:32:00 tsche has joined
1727 2012-07-11 23:35:55 [7] has quit (Ping timeout: 240 seconds)
1728 2012-07-11 23:37:59 nimdAHK has quit (Quit: Page closed)
1729 2012-07-11 23:40:52 <luke-jr> t7: I've built it on ARM, for ARM.
1730 2012-07-11 23:42:07 <t7> did you have to modify anything?
1731 2012-07-11 23:45:03 dvide_ has quit ()
1732 2012-07-11 23:45:48 TheSeven has joined
1733 2012-07-11 23:46:01 <luke-jr> t7: no
1734 2012-07-11 23:47:42 <doublec> t7: I've built and run it on a Nokia N900 which is arm. worked fine.
1735 2012-07-11 23:47:58 <t7> awesome
1736 2012-07-11 23:48:21 * luke-jr maintains Gentoo for N900, so same platform :P
1737 2012-07-11 23:48:21 <doublec> make sure it's a little endian arm device
1738 2012-07-11 23:48:27 <doublec> (are there any big endian ones?)
1739 2012-07-11 23:49:44 <doublec> ah, the linsys NSLU2 is big endian arm
1740 2012-07-11 23:50:40 <gmaxwell> oh spiffy.
1741 2012-07-11 23:51:00 <gmaxwell> no  .. wait .. must .. not .. buy more crap.
1742 2012-07-11 23:51:01 <luke-jr> so anyone want to help test block previewing, maybe we can get something going so I can safely up Eligius txn limit from 32? :P
1743 2012-07-11 23:55:24 one_zero has joined
1744 2012-07-11 23:55:30 Marf has quit (Ping timeout: 252 seconds)