1 2012-09-09 00:49:44 <amiller> lol
  2 2012-09-09 00:49:55 <amiller> i've been stressing out about how to calculate the price per bitcoin
  3 2012-09-09 00:50:04 <amiller> vs price per hash
  4 2012-09-09 00:50:18 <amiller> i should just divide the total amount of bitcoins earned in each block to the expected number of hashes needed to compute it
  5 2012-09-09 00:50:25 <amiller> obviously that is the price of a bitcoin
  6 2012-09-09 00:50:28 <amiller> in work
  7 2012-09-09 01:04:06 <gmaxwell> amiller: oh boy, you should stick to computer science, because it sounds like you're falling down a common economic rathole.
  8 2012-09-09 01:04:58 <gmaxwell> Unless you want to argue that if I took the hope diamond smashed it to a billion pieces, wrapped it in the monoa lisa, and then had the pope piss out the fire that the resulting muck would we worth a hundred million per gram... :P
  9 2012-09-09 01:09:36 <amiller> it's a pretty simple argument about equilibrium
 10 2012-09-09 01:10:01 <amiller> if the expected bitcoins earned per block are much greater than the cost to produce them, then it's worth buying more gpus
 11 2012-09-09 01:10:20 <amiller> equilibrium is when the price of a bitcoin matches the cost of a block
 12 2012-09-09 01:10:54 <gmaxwell> amiller: right but you can't look to the cost of a hash to determine the price. Thats like looking at my smashed diamond muck and calling it valuable.
 13 2012-09-09 01:11:32 <amiller> eh, don't worry, i'm not interested in observing anything or determining anything...
 14 2012-09-09 01:12:48 <amiller> well i take that back, i'm willing to make a prediction and test it on evidence, based on what i just said, i should be able to take two charts from blockchain.info, divide them, and see a flat line
 15 2012-09-09 01:13:07 <amiller> well it won't be a flat line because i know speculation's changed and we've already seen three generations of mining tech
 16 2012-09-09 01:36:50 <jrmithdobbs> errr, is that rumor about rms true?
 17 2012-09-09 01:37:26 <lianj> which?
 18 2012-09-09 01:37:58 <jrmithdobbs> https://twitter.com/kragen/status/244634678747873280
 19 2012-09-09 01:38:02 <jrmithdobbs> that one
 20 2012-09-09 01:38:23 <amiller> http://pastebin.com/TCZy568K this is the abstract for his talk posted on the conference site
 21 2012-09-09 01:39:03 <amiller> i don't think richard stallman has talked about currency before, so it seems like this will be a new performance specifically for bitcoin
 22 2012-09-09 01:40:07 <lianj> feels like ron paul pushing bitcoin
 23 2012-09-09 01:41:55 <jrmithdobbs> has anyone comitted to recording the talks this time?
 24 2012-09-09 01:42:12 <jrmithdobbs> because i'm a little confused what he's going to talk about, this isn't really his area
 25 2012-09-09 01:43:56 <gmaxwell> "Good news: after months of searching we finally found someone sufficiently more pigheaded than the average bitcoiner that they'll probably survive talking at the conference"
 26 2012-09-09 01:45:16 <Luke-Jr> jrmithdobbs: RMS leaves his area of expertise pretty often
 27 2012-09-09 01:46:05 <Luke-Jr> jrmithdobbs: RMS has been listed up top on http://bitcoin2012.com/ for a while now
 28 2012-09-09 01:46:35 <Luke-Jr> 
ACTION wonders when Bitcoin became part of the free software movement; seems it's mostly accidental overlap

 29 2012-09-09 01:46:50 <jrmithdobbs> Luke-Jr: ya that's where my confusion comes from ;p
 30 2012-09-09 01:48:14 <amiller> i think the big difficulty with RMS is that he says "Free as in Freedom, Free as in Beer" meaning you can still sell it, but no one's really figured out how to practice it
 31 2012-09-09 01:48:18 <amiller> bitcoin is agoric free software
 32 2012-09-09 01:52:28 <amiller> i really like his talks, so i'm excited if there will be new material
 33 2012-09-09 01:53:24 <gmaxwell> I predict he doesn't get to the talk because he enounters someone as immovable as him and then some kind of criticality excursion event happens and the world ends.
 34 2012-09-09 01:58:31 <phantomcircuit> jrmithdobbs, they will be recorded iirc by professionals
 35 2012-09-09 01:58:39 <phantomcircuit> professional maybe iono
 36 2012-09-09 01:59:48 <phantomcircuit> also
 37 2012-09-09 01:59:51 <phantomcircuit> lol @ gmaxwell
 38 2012-09-09 01:59:54 <doublec> I'm surprised he's promoting bsd licensed software
 39 2012-09-09 02:00:50 <phantomcircuit> doublec, something tells me.. https://gitorious.org/libbitcoin/libbitcoin/blobs/master/LICENSE
 40 2012-09-09 02:02:16 <doublec> oh right. must learn to seperate bitcoin the project from bitcoin the implementation
 41 2012-09-09 02:02:57 <Luke-Jr> doublec: that's wumpus's fault ;)
 42 2012-09-09 02:08:57 <gmaxwell> doublec: RMS doesn't have any problem with BSD licensed software. He recommended xiph.org use BSD for vorbis (the early betas we're GPL), specifically because it would improve things if non-free stuff used the format too.
 43 2012-09-09 02:09:29 <gmaxwell> I imagine he'd take a similar position on the bitcoin reference implementation, if not a lot of the tools people build above it.
 44 2012-09-09 02:10:06 <gmaxwell> (er well, to be clear, if you were to ask RMS about this you should be clear which BSD license you mean, or you'd end up down an advertising clause rathole)
 45 2012-09-09 02:11:52 <jrmithdobbs> gmaxwell: especially if you think advertising clauses are a-ok, have a feeling that wouldn't end well at all
 46 2012-09-09 02:12:45 <jgarzik> AFAIK, RMS's default position has been "MIT/X11, if GPL is off the table"
 47 2012-09-09 02:13:04 <jgarzik> but that was years ago, maybe he's changed his mind and likes BSD now
 48 2012-09-09 02:13:59 <jrmithdobbs> it is something i've never really seen a written response from him about: wonder how he feels about people that *explicitly* use the 4 clause bsd license to prevent code from getting gpl'ed
 49 2012-09-09 02:14:14 <jrmithdobbs> (doesn't happen very often anyways)
 50 2012-09-09 02:15:15 <jrmithdobbs> jgarzik: i think he "likes" the 2 clause form, iirc
 51 2012-09-09 02:17:22 <gmaxwell> only the four clause would cause an issue with him, but he'll make you be specific to be clear that he doesn't approve of the four clause, even though almost no one does anymore.
 52 2012-09-09 02:18:27 <jgarzik> RMS loves specificity, that is certain ;p
 53 2012-09-09 02:18:58 <jgarzik> 
ACTION has spoken at events with RMS before, and he inevitably, pedantically reminds someone about "GNU/Linux"

 54 2012-09-09 02:19:58 <jrmithdobbs> jgarzik: and everyone in the room groans and wants to punch him in the face ;p
 55 2012-09-09 02:20:05 <Luke-Jr> 
ACTION reminds jgarzik that RMS is right about "GNU/Linux"

 56 2012-09-09 02:20:06 <Luke-Jr> ;)
 57 2012-09-09 02:20:20 <stamit> need to switch kernel
 58 2012-09-09 02:20:52 <jgarzik> 
ACTION ignores the trolls, and continues implementing "fStrictMiner" mode for bitcoind

 59 2012-09-09 02:21:28 <jrmithdobbs> oh, am i the only one that that triggers that reaction? ha
 60 2012-09-09 02:21:47 <sipa> jgarzik: what's that?
 61 2012-09-09 02:21:48 <stamit> no
 62 2012-09-09 02:23:24 <Luke-Jr> 
ACTION wonders if RMS is still banned from LKML

 63 2012-09-09 02:23:58 <jgarzik> sipa: wait for the Exciting Pull Request...   coming soon to a github theatre near you!
 64 2012-09-09 02:24:33 <sipa> 
ACTION assumes: require correct coinbase height if blockversion==2 ?

 65 2012-09-09 02:24:38 <Luke-Jr> sipa: my guess would be "reject the submitblock call if version==2 and block height missing or wrong"
 66 2012-09-09 02:25:09 <Luke-Jr> which any sensible miner is going to disable, since it makes far more sense to just warn and still get the $500
 67 2012-09-09 02:25:43 <sipa> hopefully fixing his software to create correct blocks is easier than disabling that check
 68 2012-09-09 02:25:49 <sipa> but that's wishful thinking :)
 69 2012-09-09 02:25:53 <Luke-Jr> sipa: I'm doing both ;)
 70 2012-09-09 02:26:09 <Luke-Jr> I don't want to lose $500 if there's a bug and I don't have to.
 71 2012-09-09 03:34:23 <jrmithdobbs> i'm pretty sure i can buildworld faster than building boost, christ
 72 2012-09-09 03:35:01 <xisalty> are you building it for bitcoin ?
 73 2012-09-09 03:35:33 <jrmithdobbs> yes, applying a patch that fixes a bug in the unit tests (boost side, not bitcoin side) on openbsd
 74 2012-09-09 03:35:40 <jrmithdobbs> so I can make sure my other changes actually work right
 75 2012-09-09 04:00:59 <jrmithdobbs> very glad i got the unit tests working before giving this to anyone, haha
 76 2012-09-09 04:01:09 <jrmithdobbs> basically all the coin selection tests fail
 77 2012-09-09 04:01:57 <jrmithdobbs> *** 300 failures detected in test suite "Bitcoin Test Suite"
 78 2012-09-09 04:17:30 <jrmithdobbs> it's the tests at wallet_tests.cpp lines 107, 146, and 158
 79 2012-09-09 04:17:32 <jrmithdobbs> test/wallet_tests.cpp(107): error in "coin_selection_tests": check setCoinsRet.size() == 3 failed [4 != 3]
 80 2012-09-09 04:17:35 <jrmithdobbs> test/wallet_tests.cpp(146): error in "coin_selection_tests": check nValueRet == 18 * CENT failed [19000000 != 18000000]
 81 2012-09-09 04:17:38 <jrmithdobbs> test/wallet_tests.cpp(158): error in "coin_selection_tests": check nValueRet == 11 * CENT failed [14000000 != 11000000]
 82 2012-09-09 04:17:41 <jrmithdobbs> weirdness
 83 2012-09-09 04:18:23 <jrmithdobbs> anyone have thoughts on that?
 84 2012-09-09 04:18:38 <jrmithdobbs> only those 3 fail
 85 2012-09-09 04:32:22 <Cash2BTC> #coshack
 86 2012-09-09 05:11:20 <phantomcircuit> seems the max resident memory for bitcoind is 680 MB
 87 2012-09-09 05:11:26 <phantomcircuit> this is a bitcoind with a huge wallet
 88 2012-09-09 06:30:05 <babalu> hai
 89 2012-09-09 06:30:24 <babalu> i have a big problem using php with bitcoind and jsonrpcclient.php
 90 2012-09-09 06:30:43 <babalu> Every functio works ok, execpt the sendfrom function
 91 2012-09-09 06:30:52 <babalu> that return a 500
 92 2012-09-09 06:31:09 <babalu> \t\t$transacion = $bitcoin->sendfrom($username, $address, $amount);
 93 2012-09-09 06:31:15 <babalu> all is properly set
 94 2012-09-09 06:48:05 <babalu> done
 95 2012-09-09 06:48:16 <babalu> i had just to specific (string (float) ecc
 96 2012-09-09 07:23:51 <babalu> init 0
 97 2012-09-09 09:21:45 <olp> What's the approximate release date for the next version of the client?
 98 2012-09-09 11:11:14 <wumpus> olp: when no more bugs are found in the rc
 99 2012-09-09 11:11:28 <Joric> hehe http://fc04.deviantart.net/fs71/i/2012/253/3/c/btc___blockchain_by_lovendahl-d5e7v16.jpg
100 2012-09-09 11:11:46 <wumpus> olp: are you already helping testing? http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/test/
101 2012-09-09 11:12:15 <Joric> satoshidice share approaches 1,7 Gb
102 2012-09-09 11:12:32 <olp> alright, thanks, I'll test it out
103 2012-09-09 11:13:07 <senseless> i cant believe that people even play that game
104 2012-09-09 11:13:11 <senseless> go play poker or something..
105 2012-09-09 11:13:25 <sipa> Joric: just in blk000*.dat files?
106 2012-09-09 11:14:56 <Joric> sipa, yes, blockchain MB: 1666.6
107 2012-09-09 11:15:11 <Joric> 2285529 transactions total
108 2012-09-09 11:16:44 <sipa> i wonder how much remains of that after pruning
109 2012-09-09 11:16:49 <sipa> relatively
110 2012-09-09 11:17:07 <yellowhat> would any core dev be willing to provide escrow for silly bets made on irc and forums? we have a business opportunity here :)
111 2012-09-09 11:18:50 <Joric> yellowhat, better ask otc
112 2012-09-09 11:19:48 <senseless> Anyone have any idea where I might go to find someone who knows python and could code a custom kernel for me?
113 2012-09-09 11:19:56 <senseless> (paing ofc)
114 2012-09-09 11:19:59 <senseless> paying*
115 2012-09-09 11:20:19 <Joric> senseless, custom kernel for what? jgarzik already wrote pynode
116 2012-09-09 11:20:50 <senseless> bfgminer, phoenix, or whatever (bfgminer pref). I need a cuda kernel to get rid of this 100% cpu bug on nvidia.
117 2012-09-09 11:21:55 <senseless> (while mining)
118 2012-09-09 11:49:55 <denisx> bitcoincharts are down?
119 2012-09-09 11:51:46 <Eliel> sipa: I'd think that after pruning, satoshidice's effect will be close to nonexistent.
120 2012-09-09 11:52:46 <Eliel> sipa: if it isn't then we need something to incentivize people to combine large numbers of very small outputs.
121 2012-09-09 11:54:48 <denisx> does deepbit now use sendtomany?
122 2012-09-09 12:03:23 <MC1984> satoshi dice is just the beginning
123 2012-09-09 12:06:19 <Joric> i wonder how many full nodes will remain
124 2012-09-09 13:32:54 <sebicas> I have a question about orphaned blocks
125 2012-09-09 13:32:58 <sebicas> If you go to http://blockchain.info/
126 2012-09-09 13:33:14 <sebicas> You will see 2 block with 198014 height
127 2012-09-09 13:33:20 <sebicas> Both generated 2 minutes ago
128 2012-09-09 13:33:43 <sebicas> And one is indicated as part of the main chain http://blockchain.info/block-index/279008/000000000000055b3666cf9d1960d3b6002a285b8d1a826929698f5fac69555e
129 2012-09-09 13:33:56 <sebicas> And the other orphaned http://blockchain.info/block-index/279010/000000000000022d5ce9ae1dbdb275ee78e7743abd02ec64b31a93c9597500af
130 2012-09-09 13:34:31 <sebicas> How I can know they determine which one is the correct one?
131 2012-09-09 13:36:02 <sebicas> I meant how I can determine which one is part of the Main chain and which is orphaned
132 2012-09-09 13:36:15 <tcatm> They can't. They guess.
133 2012-09-09 13:37:09 <sebicas> Ahh ok..
134 2012-09-09 13:37:22 <sebicas> So how can I know for sure then?
135 2012-09-09 13:37:37 <sebicas> Waiting for the next block I guess??? correct?
136 2012-09-09 13:38:17 <tcatm> Waiting for a few more blocks, yes
137 2012-09-09 13:38:49 <Diablo-D3> Obsi: ITS SUNDAY
138 2012-09-09 13:39:04 <edcba> and there is sun shining !
139 2012-09-09 13:39:14 <sebicas> I work every day :)
140 2012-09-09 13:39:27 <edcba> but the sun doesn't shine every day !
141 2012-09-09 13:39:29 <sebicas> How many block do I need to wait to make sure?
142 2012-09-09 13:39:35 <sebicas> Right
143 2012-09-09 13:40:09 <tcatm> Depends. I'd suggest reading the paper :)
144 2012-09-09 13:40:25 <wumpus> 6 is recommended
145 2012-09-09 13:40:27 <sebicas> Ok...
146 2012-09-09 13:40:36 <sebicas> Thanks
147 2012-09-09 13:53:52 <lianj> how did http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 get into the blockchain?
148 2012-09-09 13:54:06 <lianj> its a p2sh, "5121029b6d2c97b8b7c718c325d7be3ac30f7c9d67651bce0c929f55ee77ce58efcf8451ae OP_HASH160 19a7d869032368fd1f1e26e5e73a4ad0e474960e OP_EQUAL"
149 2012-09-09 13:54:23 <lianj> with a inner script of, "1 029b6d2c97b8b7c718c325d7be3ac30f7c9d67651bce0c929f55ee77ce58efcf84 1 OP_CHECKMULTISIG"
150 2012-09-09 13:55:02 <lianj> thats a multisig without signatures, why did it get redeemed?
151 2012-09-09 13:59:24 <lianj> was it mined by a node that didnt understand p2sh and just ran the p2sh script but not its inner script?
152 2012-09-09 14:09:33 <lianj> guess thats the only answer.
153 2012-09-09 14:10:27 <jgarzik> lianj: that definitely happens..  some miners still exist that do not understand p2sh
154 2012-09-09 14:10:46 <jgarzik> TD: anybody put code towards your distributed bond market idea?  I was tempted last night
155 2012-09-09 14:10:53 <TD> nope
156 2012-09-09 14:11:17 <jgarzik> https://github.com/jgarzik/pagedb does protocol buffers, and it was surprisingly simple
157 2012-09-09 14:11:24 <jgarzik> seems quite easy to build a p2p app these days
158 2012-09-09 14:12:24 <lianj> jgarzik: bummer, how you would handle it in a node that understands p2sh? with a TX_EXCEPTIONS list?
159 2012-09-09 14:16:54 <jgarzik> lianj: well fwiw the inner script must be standard, otherwise it will not be relayed
160 2012-09-09 14:16:56 <riush> ah, it's only been activated since april
161 2012-09-09 14:17:00 <riush> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1367
162 2012-09-09 14:17:17 <jgarzik> lianj: a zero-sig checkmultisig is valid though, if you find a miner to mine it
163 2012-09-09 14:18:24 <jgarzik> TD: how are bond IPOs handled?  I post the chain with 100,000 new-issuer bond messages?
164 2012-09-09 14:18:27 <jgarzik> *post to
165 2012-09-09 14:18:33 <lianj> ah, nBIP16SwitchTime. fancy and ugly. thanks!
166 2012-09-09 14:19:05 <jgarzik> TD: and then a bunch of people all try to spend at the same time?  :)
167 2012-09-09 14:19:06 <TD> you just create a tx with a control output. the value of the other inputs/outputs is arbitrary.
168 2012-09-09 14:19:31 <TD> to then "issue" the bond you find a seller (or the seller finds you), and you work together to craft a tx that pays you the money and passes the control output to them.
169 2012-09-09 14:19:35 <TD> that reminds me
170 2012-09-09 14:19:44 <jgarzik> TD: say I'm create 1000 bonds at 1 BTC apiece, to sell to the general public
171 2012-09-09 14:19:52 <jgarzik> TD: what does that look like, in messages?  one big tx?
172 2012-09-09 14:19:59 <jgarzik> [*creating
173 2012-09-09 14:20:01 <TD> the change to make transactions with zero-value outputs non standard .... i think we can have our cake and eat if it the rule is changed to >1 zero output is non-standard
174 2012-09-09 14:20:11 <lianj> jgarzik: that cant be true, if the script says it want 1 signature, and you dont pass it, it never evals to true
175 2012-09-09 14:20:33 <TD> you could do 1 big TX to start with, yes.
176 2012-09-09 14:20:56 <jgarzik> if (nKeysCount < 0 || nKeysCount > 20)
177 2012-09-09 14:21:06 <jgarzik> lianj: zero is permitted for either AFAICS
178 2012-09-09 14:21:59 <jgarzik> TD: ...and vin.size==1 and zero output is non-standard?
179 2012-09-09 14:22:18 <lianj> jgarzik: wtf oO. but thanks for clearing that up
180 2012-09-09 14:22:30 <TD> i think a tx with any zero-value outputs is non standard now
181 2012-09-09 14:22:36 <jgarzik> TD: correct
182 2012-09-09 14:22:58 <jgarzik> TD: just saying that we do not want to permit vin.size==1, zero output, if those rules are relaxed
183 2012-09-09 14:23:18 <jgarzik> I need to find the conversation on adding extra data to TX's
184 2012-09-09 14:23:24 <TD> right, sure
185 2012-09-09 14:23:30 <TD> well, actually
186 2012-09-09 14:23:37 <TD> i'm not sure ... i think that'd be ok. if you want to create a tx that is only fee
187 2012-09-09 14:23:41 <TD> then such a construct is useful
188 2012-09-09 14:24:06 <jgarzik> gah the stupid forum search is wholly useful
189 2012-09-09 14:24:28 <jgarzik> a while ago, satoshi, gavin, myself and possibly others had a conversation about adding short bits of data to each TX
190 2012-09-09 14:24:38 <jgarzik> enough to transit a hash, at least
191 2012-09-09 14:25:08 <jgarzik> I _think_ the consensus was to permit anybody to add 32 bytes of arbitrary data, without making the TX non-standard
192 2012-09-09 14:25:31 <jgarzik> i.e. limited OP_DROP type behavior
193 2012-09-09 14:26:37 <lianj> jgarzik: hm, doesnt that make multisig totally broken? when you find miners that accept the script even though you didnt pass any sigs?
194 2012-09-09 14:27:54 <jgarzik> lianj: what is broken?   it is non-standard and will probably be dropped by clients, sure.  but it sounds like a valid script that would evaluate to true unconditionally.
195 2012-09-09 14:28:42 <riush> i think jgarzik means a 0-of-0 multisig script can be valid.. but in our case, a 1-of-1 with a missing sig can't, right?
196 2012-09-09 14:29:53 <jgarzik> Here we go... satoshi on added bytes: https://bitcointalk.org/index.php?topic=2162.0;all
197 2012-09-09 14:32:00 <jgarzik> satoshi even has some suggestions that sipa would dislike :)
198 2012-09-09 14:32:15 <jgarzik> like suggesting unspendable, zero-BTC txout's
199 2012-09-09 14:44:57 <jrmithdobbs> sipa: you around?
200 2012-09-09 14:46:19 <jrmithdobbs> trying to figure out what's going on here: http://pastebin.com/ZNtXSgma
201 2012-09-09 14:46:35 <jrmithdobbs> bitcoind seems to work for all p2p/network stuff, but something's funky in the wallet/coin selection code (that I haven't touched)
202 2012-09-09 14:55:08 <jrmithdobbs> actually, here, everything summazired with full output including the git rev it's based off of (after the diff)
203 2012-09-09 14:55:11 <jrmithdobbs> http://pastebin.com/kFjiXui2
204 2012-09-09 14:55:17 <jrmithdobbs> greatly appreciate anyone's thoughts on what would cause that
205 2012-09-09 14:55:57 <jrmithdobbs> ifgnore the [X/XXX] lines that's just tmux buffer stuff
206 2012-09-09 15:47:45 <gmaxwell> jgarzik: unspendable txouts aren't so bad; so long as we can reliably identify them we can exclude them from the txout set.
207 2012-09-09 15:48:06 <jgarzik> gmaxwell: yes, satoshi also mentioned that in the linked thread
208 2012-09-09 15:53:58 <jgarzik> OP_DROP pull req discussion: https://bitcointalk.org/index.php?topic=107503.0
209 2012-09-09 15:56:21 <gmaxwell> jgarzik: Why do you want to shit on bitcoin?  Seriously.   There are perhaps places for it, because no on has constructed the more approiate mechenisms for all the things that _don't_ belong in it, it'll just get lazy used all over the place.
210 2012-09-09 15:57:04 <gmaxwell> If you were to ask that _after_ we had payment protcols, and after we had a overlay p2p messaging network for connected by non-blockchain usage, my view would be only mildly negative.
211 2012-09-09 15:57:56 <gmaxwell> s/connected by/connected but/
212 2012-09-09 15:59:24 <jgarzik> gmaxwell: it's part of the satoshi design, and people are already inventing non-standard ways to do same
213 2012-09-09 16:00:02 <gmaxwell> jgarzik: I have no ideas how to limit it. If you put a tight constraint on the data size people will just generate large volumes of transactions to carry more data, which is not an improvement.
214 2012-09-09 16:01:05 <jgarzik> gmaxwell: it's better than sending to a non-existent txout pubkey
215 2012-09-09 16:02:00 <gmaxwell> It's far worse than a great many other alternatives for most of the usage we've seen.
216 2012-09-09 16:02:55 <jgarzik> gmaxwell: every single modern financial transaction system permits some small bits of vendor-specific data to come along for the ride
217 2012-09-09 16:03:25 <jgarzik> it's archaic to prevent that
218 2012-09-09 16:03:46 <gmaxwell> jgarzik: every single modern financial system has ways of properly rate controlling abusive usage, and none of them require perpetual storage on enormous numbers of nodes for their security model.
219 2012-09-09 16:04:43 <gmaxwell> We can't properly control abusive usage because privacy depends on us not distinguishing users.
220 2012-09-09 16:04:45 <jgarzik> existing anti-spam rules continue to work
221 2012-09-09 16:05:22 <gmaxwell> jgarzik: Not sure why you say they work, the chain has basically doubled in size in the last four months. They don't work.
222 2012-09-09 16:05:41 <jgarzik> you want to attach data, you must attach value or fees
223 2012-09-09 16:05:59 <gmaxwell> (doubled in size while we've not had an increase of users)
224 2012-09-09 16:06:49 <OneEyed> Financial systems need to add those small bits, because they cannot easily generate a new account number for every transaction (or every sender), while bitcoin can do that.
225 2012-09-09 16:07:05 <gmaxwell> jgarzik: if you make the fee reasonable enough to discourage the pointless usage and the perpetual bloat it will kill all the things that want to use it.
226 2012-09-09 16:08:02 <jgarzik> OneEyed: no, you still have internal transaction ids...  bitcoin exchanges have order numbers, withdrawal ids, etc.
227 2012-09-09 16:08:09 <jgarzik> anyway, baby naptime
228 2012-09-09 16:08:11 <gmaxwell> OneEyed: right, I did dozen ACHs in one day out of my trading account and got a phone call that if I did any more they were going to start charging me per. Bitcoin can't do this.
229 2012-09-09 16:08:16 <jgarzik> discuss on forum :)
230 2012-09-09 16:08:48 <OneEyed> Satoshidice would use it to indicate repayment addresses
231 2012-09-09 16:08:56 <denisx> lolz
232 2012-09-09 16:08:57 <denisx> In the meantime, you could assume the price to be either $0.01 or $100 so we can see some interesting rallies and have fun until you can look at boring numbers again :)
233 2012-09-09 16:11:36 <amiller> jgarzik, this is about adding a constant size (32 bytes, just enough for a hash) field to the current "isStandard" transaction type?
234 2012-09-09 16:11:46 <amiller> and no validation of that data is required
235 2012-09-09 16:29:30 <amiller> ah, at most two 32 byte drops
236 2012-09-09 16:31:08 <Diapolo> Can a core dev tell me, if current merges to Git master are for > 0.7 final or still for the final release of 0.7?
237 2012-09-09 16:33:27 <wumpus> still 0.7 afaik
238 2012-09-09 16:34:23 <Diapolo> makes sense, I just thought Gavin wanted 0.7rc2 as final that is why I asked.
239 2012-09-09 16:35:42 <wumpus> it'd be nice if the translation updates of the last few days make it into final
240 2012-09-09 16:39:10 <Diapolo> I can't agree more :).
241 2012-09-09 17:01:12 <amiller> gmaxwell, what's the procedure like for getting miners to mine nonstandard transactions?
242 2012-09-09 17:01:16 <amiller> https://en.bitcoin.it/wiki/Nonstandard_block this is all i could find
243 2012-09-09 17:01:25 <amiller> i thought Luke-Jr was the only one who did that
244 2012-09-09 17:06:50 <gmaxwell> amiller: connect to luke's nodes, send one with a fee of at least 2 crazy-coins.  Though it's best to talk to luke to make sure you don't hit any of his private antispam rules.  There are other miners that mine non-standard txn apparently but since they haven't identified themselves it's hard to just connect to them.
245 2012-09-09 17:07:16 <amiller> wat
246 2012-09-09 17:07:57 <gmaxwell> (2 crazy-coins == 0.00008192 BTC)
247 2012-09-09 17:08:11 <ne0futur> amiller: see also https://en.bitcoin.it/wiki/Free_transaction_relay_policy
248 2012-09-09 17:09:02 <freewil> crazy coin?
249 2012-09-09 17:09:02 <ne0futur> mtgox is alway looking for more pools to relay those, participating pools can negociate better mtgox fees
250 2012-09-09 17:09:19 <amiller> ah crazycoin is just a different unit, 'tonal bc' and it's like hex or something
251 2012-09-09 17:09:27 <gmaxwell> right. :P
252 2012-09-09 17:09:33 <amiller> crazycoin = "a peculiar amount of btc"
253 2012-09-09 17:09:53 <freewil> hm ok
254 2012-09-09 17:09:59 <gmaxwell> (I didn't remember the actual value, but I knew it was two of some lukejr unit)
255 2012-09-09 17:10:09 <amiller> 1 satanicoin = 0.666 btc
256 2012-09-09 17:10:09 <freewil> i see
257 2012-09-09 17:10:20 <freewil> im suprised it's not named after some religious figure ;)
258 2012-09-09 17:10:34 <freewil> lol
259 2012-09-09 17:11:06 <amiller> i hope that isn't really considered a healthy way for introducing new useful transactions
260 2012-09-09 17:11:39 <amiller> maybe if jgarzik's forum post began with "Dear Luke Jr" it would make more sense
261 2012-09-09 17:12:06 <gmaxwell> amiller: I think it is.
262 2012-09-09 17:12:37 <gmaxwell> amiller: it's a way to achieve limited use with some effort before having a widespread scalable deployment. Testnet is better but its hard to get people to use it.
263 2012-09-09 17:14:08 <amiller> fair enough - maybe the main point of your response was that jgarzik picked the wrong venue, a pull request to mainclient, but it should have been either a BIP  or a 'dear luke rj' post?
264 2012-09-09 17:15:11 <gmaxwell> amiller: well, we don't need a BIP for a IsStandard change generally.
265 2012-09-09 17:17:34 <edcba> yeah maybe we should introduce some unit as godcoin
266 2012-09-09 17:17:45 <edcba> so maybe we could have more support in USA :)
267 2012-09-09 17:18:22 <edcba> donate 10 godcoins to church !
268 2012-09-09 17:18:27 <amiller> heh, make it godcoin = zero btc and let them crash their computers with the exchange rate
269 2012-09-09 17:18:47 <edcba> better use fools than having against you
270 2012-09-09 17:24:39 <amiller> so if i wanted to implement one of TD's BOND contracts, i would need to make a client that identifies luke-jr's node by IP address and/or certificate in order to send the transactions
271 2012-09-09 17:26:48 <gmaxwell> amiller: certificate??
272 2012-09-09 17:27:00 <gmaxwell> amiller: you'd just hardcode the IP of one. Or use testnet.
273 2012-09-09 17:27:15 <amiller> how do the other mining leaders feel about mining nonstandard transactions
274 2012-09-09 17:27:44 <amiller> is it considered very bad or something that could be gradually adopted if it seems okay when Luke-Jr does it
275 2012-09-09 17:28:28 <gmaxwell> It's just a question of defaults. Non-standardness was implemented when bitcoin was exploited multiple times using undertested transaction forms.
276 2012-09-09 17:38:53 <amiller> gmaxwell, k so a reasonable trajectory would be 1) implement one of TD's exciting bond contracts on testnet, then 2) try to get users for a "contract app" that uses mainnet and also requires a connection to luke-jr (or any other nonstandard miner) 3) encourage other miners to support it too, based on its usefulness and its safety
277 2012-09-09 17:39:32 <edcba> the extremly good idea to have a scripting system...
278 2012-09-09 17:40:35 <gmaxwell> amiller: thats one path.  Another is do (1)  then show it to client maintainers who make it a standard in the reference software.. and then many other miners will pick it up eventually unless they hate it.
279 2012-09-09 17:40:44 <gmaxwell> amiller: and you could do both, of course.
280 2012-09-09 17:45:01 <amiller> if it's not yet clear that contracts and smart property are useful and safe, then you just need some op drops http://www.mcnett.com/Op-Drops-Anti-Fog-Lens-Cleaning-System-P329C94.aspx
281 2012-09-09 17:46:46 <gmaxwell> amiller: in my mind, the question is "is the current improvement justified over the harm", and there will be harm. This will absolutely disincentivize the creation of more efficient ways of doing instant messaging in connection with bitcoin, for example.
282 2012-09-09 17:47:27 <gmaxwell> and when there is no smart contract software written yet at all, it's hard to say the improvement trumps that harm.
283 2012-09-09 17:48:17 <jgarzik> gmaxwell: I'm starting on distributed bonds right now
284 2012-09-09 17:48:21 <jgarzik> gmaxwell: thus, relevant.
285 2012-09-09 17:48:49 <amiller> gmaxwell, i'd agree with that for anything except a constant size addition and worst-case validation
286 2012-09-09 17:49:11 <amiller> gmaxwell, satoshidice is already abusive in this way with or without an extra (prunable) 32 bytes
287 2012-09-09 17:49:53 <gmaxwell> amiller: yes, so must we suffer from the broken window effect or something? Just because there is one abuseive use doesn't mean that more should be enabled if it can be costlessly avoided.
288 2012-09-09 17:50:03 <gmaxwell> jgarzik: oh. Interesting!
289 2012-09-09 17:51:13 <amiller> gmaxwell, well 'costlessly avoided' depends on how useful these distributed contracts turn out to be
290 2012-09-09 17:51:34 <amiller> really the problem comes down to transaction fees not yet making too much sense, the question is how much extra to charge for an opdrop, right?
291 2012-09-09 17:51:44 <gmaxwell> amiller: they have zero usefulness when they do not exist; and nonstandardness doesn't prevent implementing the software.
292 2012-09-09 17:52:24 <jgarzik> gmaxwell: I was just doing a python version of TD's distributed bonds proposal, initially.  Then iterate:  (1) check against real world, (2) make changes, (3) goto step #1
293 2012-09-09 17:52:46 <jgarzik> protobuf P2P, hashmap, pretty much as described
294 2012-09-09 17:53:05 <amiller> jgarzik is gonna build a dht!
295 2012-09-09 17:53:15 <jgarzik> sadly yes
296 2012-09-09 17:53:19 <gmaxwell> amiller: it's also more complicated. People want to remove the maximum blocksize limit, so you get an instant tragedy of the commons for blocksize.
297 2012-09-09 17:53:20 <jgarzik> would love to avoid it
298 2012-09-09 17:53:30 <amiller> jgarzik, learn to love it
299 2012-09-09 17:53:31 <amiller> mmm
300 2012-09-09 17:53:47 <gmaxwell> jgarzik: So do it??? you don't need the isstandard change first. And once its working it will inform the exact isstandard change needed.
301 2012-09-09 17:54:19 <jgarzik> gmaxwell: I am against changing block size, FWIW.  I think the market will properly intervene, bitcoin will reach a steady state where all blocks are 1MB, and the best bidding gets block placement.  SatoshiDICE and other data apps automatically solve themselves, once 1MB is normal.
302 2012-09-09 17:54:35 <jgarzik> I think I will be overruled, but that is my position.
303 2012-09-09 17:55:59 <jgarzik> re OP_DROP, every transaction should be permitted X bytes of additional data, as a basic fundamental right.
304 2012-09-09 17:56:21 <jgarzik> like the lack of transaction lifetime determinism, lack of $randomdata is a core flaw
305 2012-09-09 17:56:26 <gmaxwell> jgarzik: I wasn't aware of that! Well, thats generally my position too. One reason I'm bloat concerned is that I'm worried that high bloat apps will push us against the 1MB rail prematurely (before there is economic justification for the blockspace market), and this will create popular support for removing the limit; which would ultimately doom bitcoin.
306 2012-09-09 17:57:11 <jgarzik> bitcoin exists _because_ of certain constrained limits.  money creation is one of them.  block space is another.
307 2012-09-09 17:57:28 <jgarzik> that is a fundamental constraint; messing with it massively changes the economics
308 2012-09-09 17:57:29 <gmaxwell> <3
309 2012-09-09 17:58:35 <yellowhat> what i am asking myself? why is this even a problem? im mean, anybody could just slap together a website and publish signed messages that can be looked up by transaction ID if he is looking to attach metadata. can you explain why the blockchain is even needed?
310 2012-09-09 17:58:37 <gmaxwell> In any case, is there a way of achieving the txn binding for the distributed contracts which doesn't increase the storage required for a validating but pruned node that doesn't care about contracts?
311 2012-09-09 17:58:51 <jgarzik> yellowhat: the block chain is not _needed_ to exchange bitcoins, no.
312 2012-09-09 17:59:06 <amiller> gmaxwell, the op drop payload can be pruned, why not?
313 2012-09-09 17:59:19 <jgarzik> yellowhat: it is just a useful place for untrusted parties to publish transactions, and gain confidence in their timestamp.
314 2012-09-09 17:59:44 <jgarzik> amiller: pruned when spent (it's part of the script, after all)
315 2012-09-09 17:59:55 <amiller> pruned before spent too
316 2012-09-09 18:00:30 <gmaxwell> amiller: because then you can no longer prove that your txout database is the right one, I guess.
317 2012-09-09 18:01:04 <amiller> well you can't do that anyway yet, so yes the op_drops would be needed if you're validating with a merkle tree
318 2012-09-09 18:01:16 <gmaxwell> yellowhat: generall you don't need to add metadata, but you may need to add a binding factor. E.g. you want to know _which_ of the external metadata is the official one.
319 2012-09-09 18:02:33 <gmaxwell> yellowhat: e.g. you have some coin which is also a bond. You transfer it to someone, changing the metadata in the process. What happens if you publish two sets of metadata to the metadata store? you need a way to know which is the official one.
320 2012-09-09 18:03:12 <gmaxwell> so I do understand the need: though it only needs a hash, not the metadata itself. That was where my off-the-cuff crazy suggestion that we require SHA256(data) meet some criteria. :P
321 2012-09-09 18:03:25 <gmaxwell> Though I'm not sure I see why it can't be in the scriptsig instead.
322 2012-09-09 18:04:54 <amiller> jgarzik, i think you will find that TD's contracts are easy to DDoS and will need a highly customized DHT :/
323 2012-09-09 18:06:04 <gmaxwell> amiller: at least there is no obvious rational reason to DOS them.
324 2012-09-09 18:06:16 <jgarzik> amiller: problems I see right now:  (a) how to support bursty activities, like an IPO   (b) how to prevent common DHT attacks, without giving up and simply using the file sharing DHT ;p
325 2012-09-09 18:06:24 <jgarzik> highly customized DHT is a given, sadly
326 2012-09-09 18:06:46 <jgarzik> I'm just doing basic bonds, not even-more-complex pay to policy stuff
327 2012-09-09 18:07:01 <amiller> i think they'll still be really useful and you'll be successful with it
328 2012-09-09 18:07:22 <amiller> and i don't see any other way to start feeling out what kinds of blockchain validation script support we'd need to make them tougher
329 2012-09-09 18:08:25 <amiller> there's nothing stopping someone from going "BOND "data-that-may-or-may-not-be-a-hash" OP_DROP OP_DROP
330 2012-09-09 18:10:00 <jgarzik> amiller: agreed
331 2012-09-09 18:16:28 <amiller> jgarzik, i assume you included {0,1,2} opdrops instead of just {0,1} because the example from TD's contracts is like "BOND" "hash" OP_DROP OP_DROP
332 2012-09-09 18:16:44 <amiller> why not just a single op_drop with up to 64 bytes?
333 2012-09-09 18:16:58 <amiller> or even better, up to only 36 to begin with?
334 2012-09-09 18:17:08 <gmaxwell> amiller: gavin suggested that.
335 2012-09-09 18:17:37 <amiller> ah i see, on the github pull req notes
336 2012-09-09 18:18:38 <amiller> lol okay <= 80 bytes.
337 2012-09-09 18:21:12 <amiller> gmaxwell, i don't agree with your point about timestamps being better off in coinbase
338 2012-09-09 18:22:14 <gmaxwell> amiller: why not? it has O(1) scale for an infinite number of users. Thats enormously worse than putting them in transactions.
339 2012-09-09 18:22:54 <amiller> because it requires a separate protocol for propagating information you want included in timestamps to miners
340 2012-09-09 18:22:54 <gmaxwell> er better. :P
341 2012-09-09 18:23:04 <amiller> there's no way to pay a fair price and have miners compete to include it
342 2012-09-09 18:23:04 <gmaxwell> amiller: we should put it in the protocol, of course.
343 2012-09-09 18:23:12 <gmaxwell> the fair price is ~0
344 2012-09-09 18:23:29 <gmaxwell> the value is in keeping the shit out of the blockchain which forever impacts scalablity.
345 2012-09-09 18:24:28 <gmaxwell> amiller: look at how chronobit works.. every p2p miner can aggregate in timestamps along with their shares, even if they never solve a block.
346 2012-09-09 18:25:37 <gmaxwell> amiller: market pricing is good, but it's not as good as a design that makes something effectively costless so that you don't have to worry about market pricing for it.
347 2012-09-09 18:26:08 <gmaxwell> coinbase timestamps also make it so that timestamps are still fairly priced (~0 in cost) even when there is hot competition for blockchain space.
348 2012-09-09 18:27:13 <gmaxwell> also avoids creating false competition for blockchain space which would inflate transaction costs above their efficient no-timestamping-usage price.
349 2012-09-09 18:28:25 <amiller> hrm, i guess that does work just as well
350 2012-09-09 18:28:32 <amiller> so you could also do the bond contracts like that
351 2012-09-09 18:29:07 <amiller> anything of the sort TD wants to do could also be done using that chronobit technique, right?
352 2012-09-09 18:29:26 <gmaxwell> amiller: I don't think you can? you still need a way of figuring out which of multiple competing metadata hunks is the true one.
353 2012-09-09 18:31:52 <amiller> gmaxwell, yeah, that's the problem with non-validated metadata whether it's in OP_DROP or anywhere else
354 2012-09-09 18:32:54 <gmaxwell> amiller: in the case of it in OP_DROP its tied to the coin. The coin can only be spent once, so there is only one valid metadata hunk.
355 2012-09-09 18:33:20 <gmaxwell> the bonds thing doesn't use bitcoin for timestamping, it uses bitcoin to control access.
356 2012-09-09 18:34:00 <amiller> hrm, i see, that's why it's in scriptsig rather than scriptpubkey
357 2012-09-09 18:34:29 <gmaxwell> It's in the scriptpubkey, but thats why I was asking if it really needed to be there.
358 2012-09-09 18:36:29 <jgarzik> bonds thing also uses bitcoin for secure, atomic funds transfer
359 2012-09-09 18:37:35 <kjj_> jgarzik: do you know how chronobit works?
360 2012-09-09 18:39:15 <jgarzik> kjj_: never heard of it
361 2012-09-09 18:40:03 <kjj_> oh, shit, sorry.  it was gmaxwell that was talking about it earlier, not you
362 2012-09-09 18:42:27 <gmaxwell> kjj_: yes, I know how chronobit works.
363 2012-09-09 18:42:55 <kjj_> does it embed any data in the bitcoin chain?
364 2012-09-09 18:43:03 <gmaxwell> jgarzik: and you should really be aware of things like chronobit if you're going to go around advocating adding more crud to the chain. :P
365 2012-09-09 18:43:12 <gmaxwell> kjj_: it doesn't add any _additional_ data in the chain.
366 2012-09-09 18:43:30 <kjj_> well, does it modify anything?  the documentation is kinda sparse
367 2012-09-09 18:44:05 <gmaxwell> kjj_: there is already data added to the chain in the coinbase for mergemining p2pool. So what chronobit does is just adds its hash root to the merged mining root.
368 2012-09-09 18:44:39 <amiller> if distributed bonds rely on the blockchain enforcing a unique successive chunk of metadata, then the only way for that to work is if there's an OP_DROP in the script
369 2012-09-09 18:44:40 <gmaxwell> kjj_: so to validate a chronobit signature you find the relevant bitcoin block, then follow the series of hash tree fragements to the hash you're verifying.
370 2012-09-09 18:44:52 <amiller> but it might as well be in the scriptsig rather than the scriptpubkey so you can prune it quicker
371 2012-09-09 18:44:57 <jrmithdobbs> oh hey, people paying attention now
372 2012-09-09 18:45:01 <gmaxwell> amiller: thats what I was saying.
373 2012-09-09 18:45:17 <jrmithdobbs> so i've got bitcoind 'working' at least as p2p/validating client on openbsd
374 2012-09-09 18:45:24 <jrmithdobbs> but seeing some weirdness with test_bitcoin
375 2012-09-09 18:45:29 <amiller> and gmaxwell, in terms of scalability, it does not matter what you add to the blockchain nearly as much as it matters what you add to your utxo sets
376 2012-09-09 18:45:34 <amiller> scriptpubkeys never touch the utxo set
377 2012-09-09 18:45:41 <amiller> er sorry the other way around, scriptsigs never touch the utxo set
378 2012-09-09 18:45:43 <jrmithdobbs> http://pastebin.com/kFjiXui2 ... the commit and my diffs are in the paste along with the 3 (repeated 100 times) assert failures
379 2012-09-09 18:45:43 <sipa> amiller: scriptsigs you mean
380 2012-09-09 18:45:48 <gmaxwell> amiller: welcome to my argument from like an hour ago.
381 2012-09-09 18:46:00 <kjj_> gmaxwell: does chronobit also run a p2p net then?
382 2012-09-09 18:46:04 <amiller> gmaxwell, thank you, i am glad to join the company
383 2012-09-09 18:46:13 <jrmithdobbs> would greatly appreciate anyone's insight into what's causing thos coin selection test failures
384 2012-09-09 18:46:30 <jrmithdobbs> because that looks like a pretty Bad Thing(tm) to me ... and I didn't modify any related code as far as i can tell
385 2012-09-09 18:46:48 <sipa> jrmithdobbs: strange, i don't see what can cause that
386 2012-09-09 18:46:54 <gmaxwell> kjj_: no. Doesn't really need to. the chronobit node you submit to is responsible for giving you the data you need to tell you where you were connected.
387 2012-09-09 18:47:05 <jrmithdobbs> sipa: ya it's weird but very very deterministic
388 2012-09-09 18:47:07 <gmaxwell> jrmithdobbs: I looked briefly last night and didn't see why
389 2012-09-09 18:47:15 <sipa> denisx seemed to have much less trouble getting getting bitcoin to run on BSD
390 2012-09-09 18:47:28 <sipa> was a different flavor maybe, though
391 2012-09-09 18:47:46 <jrmithdobbs> sipa: he's working on freebsd, i'm pretty sure my changes are enough to get freebsd working already, i can sync that tree over to my san and test that assertion ;p
392 2012-09-09 18:47:46 <kjj_> gmaxwell: but that means most blocks won't contain anything related to a given timestamp
393 2012-09-09 18:47:54 <jrmithdobbs> sipa: this is openbsd ;p
394 2012-09-09 18:48:45 <sipa> ok
395 2012-09-09 18:49:18 <jrmithdobbs> but everything but the wallet code looks good so far
396 2012-09-09 18:49:35 <gmaxwell> kjj_: yes? so. Your p2p network for getting that data is bitcoin.
397 2012-09-09 18:49:49 <jrmithdobbs> successful IBD, memory pool working, all the rpc stuff i've tested at random is working (including getrawmempool)
398 2012-09-09 18:49:56 <gmaxwell> You need to talk to bitcoin in the first place to make sure the difficulty and timestamps are valid. :P
399 2012-09-09 18:50:15 <kjj_> I'm saying that if I'm running chronobit on my mining nodes, I can only meaningfully timestamp things about four times a year
400 2012-09-09 18:51:01 <jrmithdobbs> sipa: tbqh, most of the problems on openbsd have been related to versions of ports/packages for dependencies (boost 1.42 needs a patch for unit tests to work at all, for instance, and bdb being stuck at 4.6 being the biggest two)
401 2012-09-09 18:51:13 <kjj_> because 99.99% of my coinbases do NOT make it into bitcoin, and I don't think p2pool keeps the full chain around long term
402 2012-09-09 18:51:48 <gmaxwell> kjj_: ... no. You misunderstand.
403 2012-09-09 18:52:16 <kjj_> gmaxwell: I certainly hope I'm misunderstanding something.  the question is what?
404 2012-09-09 18:52:24 <jrmithdobbs> sipa: random thought, how much memory is test_bitcoin expected to use? data segment ulimit is currently set to ~2G
405 2012-09-09 18:53:05 <gmaxwell> kjj_: you have a pool of things to stamp. You commit them to your p2pool shares.. Eventually p2pool gets a block. You then collect up the list of things youre stamping and the p2pool shares that connect up to a block... and you return that to the party that requested the timestamp.
406 2012-09-09 18:53:26 <gmaxwell> kjj_: that data plus the bitcoin chain headers is enough for anyone to validate the timestamp.
407 2012-09-09 18:54:35 <gavinandresen> gmaxwell : RE: arbitrary data in the scriptSig instead of scriptPubKey:  P2SH plus a standard OP_DROP transaction type does that, and has some very nice properties, I think.
408 2012-09-09 18:55:24 <jrmithdobbs> hrm, bumped data seg to 2G and mem limit to 4G and still no love
409 2012-09-09 18:55:41 <kjj_> gmaxwell: ahh, ok.  they can see the hash of the timestamped data in your p2pool share, and a chain of p2pool shares that build on that share all the way up to a valid bitcoin block
410 2012-09-09 18:55:42 <gmaxwell> gavinandresen: yes, p2sh is okay too.
411 2012-09-09 18:55:44 <sipa> i still don't like the idea of encouraging using the blockchain to communicate messages
412 2012-09-09 18:55:52 <sipa> though i do see the need for in some cases
413 2012-09-09 18:55:55 <gmaxwell> kjj_: ding ding.
414 2012-09-09 18:56:27 <gmaxwell> sipa: the only case where I've seen a need described is this bond stuff that only exists as a fantasy now.  jgarzik why must you stress me out about non-existing stuff?
415 2012-09-09 18:56:36 <jrmithdobbs> i'll pull out gdb and see if i can figure something out
416 2012-09-09 18:56:45 <sipa> jrmithdobbs: might try valgrind as well?
417 2012-09-09 18:56:46 <gmaxwell> :P
418 2012-09-09 18:57:50 <jgarzik> chronobit is cute but doesn't really solve useful problems
419 2012-09-09 18:58:07 <sipa> well it does one thing, and does it well: timestamping data
420 2012-09-09 18:58:36 <gmaxwell> jgarzik: it solves the "I want to use bitcoin to prove some data existed at some time" problem without increasing the size of the chain at all.
421 2012-09-09 18:58:47 <gmaxwell> and it does it in a very highly scalable way.
422 2012-09-09 18:59:33 <jgarzik> gmaxwell: bond+atomic funds transfer really seems like a bitcoin application
423 2012-09-09 19:00:05 <gmaxwell> Thats one of the things that people will use op_drop for otherwise (and have previously used unspendable pubkeys for)... but doing it the op_drop way stinks because every user using it must add a txn to the chain for everything they want to timestamp.
424 2012-09-09 19:00:43 <sipa> jrmithdobbs: test_bitcoin runs here with 70MiB RES and 225MiB VIRT
425 2012-09-09 19:00:57 <kjj_> gmaxwell: there is no reason why a notary has to use unspendable pubkeys.
426 2012-09-09 19:01:27 <gmaxwell> kjj_: thats simply the laziest way of doing it, so thats what people do.
427 2012-09-09 19:01:31 <kjj_> gmaxwell: the one I wrote a while back used fully spendable private keys
428 2012-09-09 19:02:33 <gmaxwell> kjj_: but then you had to make two transactions per timestamp?
429 2012-09-09 19:02:55 <kjj_> gmaxwell: yeah, 2
430 2012-09-09 19:03:04 <gmaxwell> yea, see, you're still making my case.
431 2012-09-09 19:03:12 <gmaxwell> (well even 1 per is making my case)
432 2012-09-09 19:03:24 <gavinandresen> the way to discourage laziness is fees, in my humble opinion.
433 2012-09-09 19:03:36 <gmaxwell> It's inefficient and creates more pressure on the block chain, increasing the fair price for regular economic transactions.
434 2012-09-09 19:03:55 <sipa> the way to discourage lazyness is by making the right solution the easiest one
435 2012-09-09 19:03:59 <kjj_> yeah, unnecessary.  but the transactions to collect fees for the service tend to swamp another one or two transactions
436 2012-09-09 19:04:00 <gmaxwell> gavinandresen: fees don't work until we're in a state where there is true pressure on the blockchain for space from regular non-lazy transactions.
437 2012-09-09 19:04:03 <gmaxwell> what sipa said.
438 2012-09-09 19:04:41 <gavinandresen> I don't share sipa's faith that we know the "right" solution
439 2012-09-09 19:05:05 <amiller> gmaxwell, you seem to be excluding the only use case that jgarzik actually wants, which is distributed bonds with a single future metadata
440 2012-09-09 19:05:05 <sipa> well, there is no right solution, i'll admit
441 2012-09-09 19:05:11 <amiller> you just explained to me that you can't do it just with coinbases
442 2012-09-09 19:05:14 <sipa> we don't know how the future will choose to use bitcoin
443 2012-09-09 19:05:19 <kjj_> running chronobit and keeping that chain of shares forever has a cost too.  the good part is that the cost is solely on the timestamper
444 2012-09-09 19:05:20 <amiller> you can do it with scriptsigs
445 2012-09-09 19:05:29 <sipa> but we may at least try to help them keeping as many options open
446 2012-09-09 19:05:32 <gmaxwell> amiller: I'm excluding his case because it's currently pure fantasy. If its developed my position will be different.
447 2012-09-09 19:05:50 <kjj_> (or the timestampee)
448 2012-09-09 19:05:53 <sipa> but i really *really* think we need a payment protocol, or at least standardized payment-request and payment-submit format, soon
449 2012-09-09 19:06:07 <jgarzik> I'm hoping to demo bonds at the conference
450 2012-09-09 19:06:09 <gavinandresen> sipa: agreed
451 2012-09-09 19:06:09 <gmaxwell> amiller: once its developed I can look at it and say "hey, you could make this p2sh only, and then we don't need to permit the drops in scriptpubkey, which is a big improvement"
452 2012-09-09 19:06:53 <gavinandresen> sipa: and I think we're at, or very close, to a state where there is pressure on the blockchain for space
453 2012-09-09 19:07:14 <amiller> gmaxwell, i thought we already agreed that it should be scriptsig only
454 2012-09-09 19:07:19 <kjj_> gavinandresen: on the chain, yes.  on a given block, no
455 2012-09-09 19:07:22 <gmaxwell> gavinandresen: I'm resonably confident that adding perpetual blockchain data is not the right solution when it can be done without doing that absent some additional coding.
456 2012-09-09 19:07:40 <gmaxwell> amiller: well I don't know because it doesn't exist! :P
457 2012-09-09 19:07:58 <gavinandresen> gmaxwell: ok.  We could start by making OP_DROP a valid transaction only when wrapped in a p2sh.....
458 2012-09-09 19:08:00 <gmaxwell> kjj_: you don't have to keep a chain of shares forever!
459 2012-09-09 19:08:12 <gavinandresen> (not valid, standard)
460 2012-09-09 19:08:12 <gmaxwell> gavinandresen: does that actually do anything useful for jgarzik?
461 2012-09-09 19:08:28 <sipa> 
ACTION would prefer not to have OP_DROP a standard transaction type until there is an implemented use case for it

462 2012-09-09 19:08:32 <kjj_> gmaxwell: someone does, or the timestamp becomes unverifiable.  either the timestamping service, or the customer
463 2012-09-09 19:08:51 <Luke-Jr> "nonstandard block" wtf? O.o
464 2012-09-09 19:09:03 <gmaxwell> kjj_: ...  You _always_ have to keep around that identity of the timestamped thing. So you write the connecting shares into that. This is what chronobit does.
465 2012-09-09 19:09:11 <amiller> sipa, jgarzik is about to embark on the development of this and has apparently put this out there, as his first step on the way, to see if we disagree with his way of going about it
466 2012-09-09 19:09:11 <gmaxwell> Luke-Jr: yea, I wish I could delete pages on the wiki.
467 2012-09-09 19:09:28 <amiller> i don't think he expects any traction until he has a cool distributed bond to show off and justify it
468 2012-09-09 19:09:28 <gavinandresen> gmaxwell: jgarzik is already implementing a DHT, seems like the p2sh-hash-to-script mapping could be stored there for anybody to find.
469 2012-09-09 19:09:37 <kjj_> gmaxwell: that is the share chain, no matter what you call it or where you hide it.  it must exist
470 2012-09-09 19:10:16 <gavinandresen> (do you get notified that a new item has been added to the DHT?  I know almost nuthin about dhts....)
471 2012-09-09 19:10:31 <amiller> there are publish-subscribe dhts
472 2012-09-09 19:10:43 <gmaxwell> kjj_: It's just a segment of shares between the initial share an the next block, and its held by the timestampee not anyone else.
473 2012-09-09 19:10:47 <jgarzik> gavinandresen: traditional DHT can search.  timeout == not found
474 2012-09-09 19:10:53 <Luke-Jr> amiller: Eligius will accept any nonstandard transaction regardless of what it is, provided the fees are paid. I do intend to lock down some obvious "not a good idea" cases at some point tho
475 2012-09-09 19:10:56 <jgarzik> ugly and imprecise
476 2012-09-09 19:10:59 <gmaxwell> kjj_: so the person who wants to prove the timestamping takes all of that cost.
477 2012-09-09 19:11:23 <amiller> jgarzik, you may want to look into something like this http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1648810
478 2012-09-09 19:12:06 <gavinandresen> ooh! I know, you could brute-force proof-of-work the p2sh address by adding a nonce to the OP_DROP data so it begins 1BOND...
479 2012-09-09 19:12:10 <jgarzik> in general I'm concerned that we close off too many avenues, in the ref client, before people have a chance to experiment
480 2012-09-09 19:12:20 <gmaxwell> kjj_: and there is no timestamping system that avoids that, all you can do is change the amount of data there. But at least that way none of the cost is externalized == externalized costs almost always result in market failure.
481 2012-09-09 19:12:35 <gmaxwell> jgarzik: we have testnet for expirementation which is fully opened up.
482 2012-09-09 19:12:47 <jgarzik> I think have bond information in the TX is quite elegant, as they are both disconnected untrusted AND MUST BE ATOMIC WITH EACH OTHER </allcaps>
483 2012-09-09 19:13:04 <Luke-Jr> jgarzik: no offense, but I think you're the #1 person who does that <.<
484 2012-09-09 19:13:07 <jgarzik> you lose atomicity and reliability by separating the two bits of data
485 2012-09-09 19:13:38 <gmaxwell> jgarzik: you'll note that I have not objected to the bond usecase except in saying that it does not exist yet and so how can we add functionality for it when we're not sure of what it would need?
486 2012-09-09 19:13:45 <amiller> so far no one has tried suggesting that an OP_DROP is _insufficient_ for implementing any of TD's things
487 2012-09-09 19:13:45 <sipa> gavinandresen: i do see jgarzik's use case, but i wish that using OP_DROP wouldn't be accessible as an easy way to put metadata to the chain before a payment protocol is usable... to avoid OP_DROP becoming the standard way to transfer private transaction metadata
488 2012-09-09 19:14:02 <gmaxwell> and what's sipa's saying.
489 2012-09-09 19:14:24 <amiller> if jgarzik gets his drops, is there anything else he'd need or would he be able to hit everything on the contracts wiki?
490 2012-09-09 19:14:33 <Luke-Jr> gmaxwell: I suggested making it merged-mined; but I see jgarzik's reason that it can't be
491 2012-09-09 19:14:44 <gmaxwell> My concern is that you add this and there will be no bond usage... but there will be a ton of blockchain instant messaging and other crap. And we really aren't at position where there is true market pressure on blockchain space. Not at all.
492 2012-09-09 19:14:57 <sipa> ^ that
493 2012-09-09 19:15:27 <Luke-Jr> gmaxwell: what if we require bonds to have a proof-of-work, in a way that makes IM impractical?
494 2012-09-09 19:15:51 <gavinandresen> the alternate view is that people will start doing stuff like encoding information in satoshi-amounts, and adding extra txouts to transmit that extra information.  Which is worse than OP_DROP
495 2012-09-09 19:15:55 <gavinandresen> (and is already happening)
496 2012-09-09 19:15:55 <sipa> bitcoin is reusable proof-of-work; you can just as easily say it requires a fee
497 2012-09-09 19:15:58 <kjj_> ugh.  that seems very meta and messy
498 2012-09-09 19:16:24 <sipa> gavinandresen: i got an answer from ben (blockchain.info) by the way
499 2012-09-09 19:16:31 <jgarzik> gavinandresen: and simply sending to invalid pubkeys, which has already been done
500 2012-09-09 19:16:33 <gavinandresen> sipa: I think I saw that.
501 2012-09-09 19:16:46 <gmaxwell> Luke-Jr: ha, did you see my forum post? I did suggest that, but only half seriously
502 2012-09-09 19:16:50 <sipa> gavinandresen: hmm, i thought it was just to me
503 2012-09-09 19:17:12 <gavinandresen> sipa:  I'm misremembering, I saw his post to the forums
504 2012-09-09 19:17:22 <gmaxwell> gavinandresen: people already do these things, and I think they aren't actually any worse than OP_DROP in scriptpubkey.
505 2012-09-09 19:17:41 <gmaxwell> They're confined in space and result in perpetual storage...
506 2012-09-09 19:18:14 <gmaxwell> if anything their inefficiency is a bonus??? absent market pressure for blockchain space nothing else encourages people to be space efficient.
507 2012-09-09 19:18:32 <sipa> gavinandresen: forwarded
508 2012-09-09 19:19:17 <Luke-Jr> side note: how about using an extra zero-amount "OP_RETURN <data>" scriptPubKey for the bond?
509 2012-09-09 19:19:31 <Luke-Jr> bonus: non-bond clients can discard it entirely
510 2012-09-09 19:19:34 <jgarzik> absent OP_DROP it encourages people to create unspendable outputs
511 2012-09-09 19:19:57 <Luke-Jr> jgarzik: guaranteed-unspendable outputs (eg, starting with OP_RETURN) are a good thing
512 2012-09-09 19:20:03 <Luke-Jr> (assuming 0-value)
513 2012-09-09 19:20:15 <gmaxwell> meh, I don't know that they're a good thing.... less bad than otherwise.
514 2012-09-09 19:20:17 <sipa> gmaxwell: i think creating extra outputs is strictly worse than adding data to existing normal txouts
515 2012-09-09 19:20:29 <jgarzik> yes
516 2012-09-09 19:20:32 <sipa> if they're unspendable, that's even worse
517 2012-09-09 19:20:34 <gavinandresen> Luke-Jr: <data> OP_FALSE  I like better...
518 2012-09-09 19:20:37 <jgarzik> correct
519 2012-09-09 19:20:53 <sipa> if they're undetectably unspendable, that's yet worse
520 2012-09-09 19:21:03 <jgarzik> satoshi's idea of SIGHASH_DO_NOT_INDEX addressed this issue.
521 2012-09-09 19:21:03 <Luke-Jr> gavinandresen: that seems more open to potential exploits IMO; with OP_RETURN, you're guaranteed the rest of the data can't do anything
522 2012-09-09 19:21:08 <kjj_> creating a contract between two different block chains is hard
523 2012-09-09 19:21:24 <gmaxwell> sipa: if they're low/zero value they won't be spent anyways.  And even if they're theoretically detectable this doesn't help a UTXO tree implementation.
524 2012-09-09 19:21:25 <amiller> look do we have any mechanism that creates proportional fees for proportional bytes
525 2012-09-09 19:21:30 <amiller> or are we expecting such a mechanism in the future
526 2012-09-09 19:21:40 <gmaxwell> amiller: we already have that.
527 2012-09-09 19:21:49 <jgarzik> SIGHASH_DO_NOT_HASH simply tells you this is guaranteed unspendable, therefore, do not index.
528 2012-09-09 19:22:03 <gavinandresen> ending the scriptPubKey with OP_FALSE is provably unspendable.
529 2012-09-09 19:22:05 <jgarzik> but I dislike unspendable outputs, as _that_ really encourages this worse behavior
530 2012-09-09 19:22:35 <gmaxwell> jgarzik: have you figured out if your bonds stuff would work by only having the drops in
531 2012-09-09 19:22:41 <gmaxwell> P2SH or scriptsig?
532 2012-09-09 19:22:46 <jgarzik> spendable, pruneable is more likely to be associated with funds and therefore relevant to the blockchain
533 2012-09-09 19:23:02 <jgarzik> rather than just IM data
534 2012-09-09 19:23:17 <sipa> jgarzik: unfortunately changing SIGHASH semantics is very hard now...
535 2012-09-09 19:23:39 <jgarzik> sipa: that's OK, unspendable outputs are dumb anyway ;p
536 2012-09-09 19:23:47 <Luke-Jr> gavinandresen: if you say so, but it's at least more difficult to prove if you consider the potential to have an unclosed OP_IF (I think that was fixed a while back in practice)
537 2012-09-09 19:23:55 <gmaxwell> jgarzik: very tiny outputs will probably never be spent unless we seriously revamp the priority rules to encourage txout set cleaning.
538 2012-09-09 19:24:06 <sipa> jgarzik: eventually it's still a hack to associate non-monetary data with the transaction
539 2012-09-09 19:24:14 <jgarzik> gmaxwell: ...which we should do...
540 2012-09-09 19:24:18 <gavinandresen> gmaxwell: we should revamp the priority rules to encourage txout set cleaning.
541 2012-09-09 19:24:23 <sipa> ACK
542 2012-09-09 19:24:26 <jgarzik> sipa: ...which is why we should make it a non-hack...  ;p
543 2012-09-09 19:24:31 <jgarzik> gavinandresen: ack
544 2012-09-09 19:24:35 <gmaxwell> then we should do that _first_ before doing things like enabling OP_DROP for anything.
545 2012-09-09 19:24:46 <jgarzik> gmaxwell: perfect is the enemy of good
546 2012-09-09 19:24:56 <jgarzik> not waiting for a "perfect bitcoin" before experimenting
547 2012-09-09 19:25:04 <gmaxwell> jgarzik: go expirement with testnet.
548 2012-09-09 19:25:17 <gavinandresen> yeah, testnet away....
549 2012-09-09 19:25:26 <jgarzik> yes, it will start by default on testnet
550 2012-09-09 19:25:56 <amiller> jgarzik, just to be clear, you aren't expecting or even asking for this to be adopted by reference client until you finish the distributed bonds, right? this is just a preview?
551 2012-09-09 19:26:13 <gmaxwell> And seriously, I can't believe your usecase is worth anything if it can't wait to get a reasonable set of precautionary changes first.
552 2012-09-09 19:26:24 <jgarzik> amiller: not for immediate pushing, no
553 2012-09-09 19:26:30 <jgarzik> amiller: but it is important to start this process now
554 2012-09-09 19:26:32 <amiller> i don't see why it's so difficult to talk about an experimental new feature
555 2012-09-09 19:26:37 <amiller> and explain what it is going to require and how it would work
556 2012-09-09 19:26:53 <amiller> without first having to react to a bunch of terror about how it shouldn't be implemented immediately
557 2012-09-09 19:26:56 <gavinandresen> amiller: some of us distill our ideas by writing code
558 2012-09-09 19:26:56 <Luke-Jr> amiller: it already can be implemented on testnet
559 2012-09-09 19:27:04 <jgarzik> amiller: because otherwise, gmaxwell will insist on further delays six months down the road :)
560 2012-09-09 19:27:13 <jgarzik> yep
561 2012-09-09 19:27:15 <gmaxwell> Er. after having seen jgarzik bludgeon people a couple times about pull requests being for mergable stuff, I was under the impression that he expected this to be pulled right away.
562 2012-09-09 19:27:31 <jgarzik> gmaxwell: no, this should not be pulled right away
563 2012-09-09 19:27:41 <amiller> maybe you should have indicated a roadmap or timeline or something jgarzik
564 2012-09-09 19:27:46 <jgarzik> gmaxwell: but by the time discussion is done, it will be ready state
565 2012-09-09 19:28:07 <gavinandresen> 
ACTION slaps jgarzik on the wrist for pull-requesting something not ready to be pulled

566 2012-09-09 19:28:28 <gmaxwell> jgarzik: as far as I could tell you were taking a page from the lukejr negoiations manual with the pull request and forum post on it. :P
567 2012-09-09 19:29:02 <jgarzik> IMNSHO major changes get created as pulls earlier, because discussion is preserved
568 2012-09-09 19:29:13 <jgarzik> ditto forum post, to permit time for discussion
569 2012-09-09 19:29:36 <jgarzik> thus leveldb, ultraprune, ...
570 2012-09-09 19:29:37 <gavinandresen> forum post is entirely appropriate.  Maybe we need a way to mark pull requests as "FOR DISCUSSION"
571 2012-09-09 19:29:46 <Luke-Jr> gmaxwell: pfft, how is anyone supposed to establish that people want a feature if "user ACKs on pullreqs" and "forum threads" are both discouraged?
572 2012-09-09 19:30:18 <gmaxwell> Luke-Jr: Both gavin and jgarzik have yelled at you for doing exactly that... just saying. :P
573 2012-09-09 19:30:39 <Luke-Jr> gmaxwell: yes, I'm just saying it's a catch-22 since they also yell at me for implemetning things "nobody else wants"
574 2012-09-09 19:30:58 <gavinandresen> we just like yelling.
575 2012-09-09 19:31:00 <Luke-Jr> lol
576 2012-09-09 19:31:05 <gavinandresen> I SAID, WE JUST LIKE....
577 2012-09-09 19:31:05 <sipa> YELL
578 2012-09-09 19:31:12 <gmaxwell> The forum posts means that there is a decent chance of forcing people opposed to doing this to waste a ton of time arguing with people who only understand it as a one sided choice (they only get the potential benefits, not the costs).
579 2012-09-09 19:31:26 <gmaxwell> Thats really the only beef I have with them.
580 2012-09-09 19:31:55 <amiller> that's why you're around to make a first response with "hell no"
581 2012-09-09 19:32:08 <gavinandresen> discussion in forum threads tends to wander off-topic.  Discussion on the mailing list tends to die or never get started....
582 2012-09-09 19:32:31 <gavinandresen> Discussion here tends to be productive when the right people are here
583 2012-09-09 19:32:42 <sipa> indeed
584 2012-09-09 19:32:43 <gmaxwell> Agreed.
585 2012-09-09 19:32:57 <sipa> maybe we should reinstate those weekly IRC meetings?
586 2012-09-09 19:33:05 <Luke-Jr> ^
587 2012-09-09 19:33:11 <gavinandresen> I was just wondering that.  Is there a time we can all make regularly?
588 2012-09-09 19:34:26 <gavinandresen> ... best times for me tend to be east-coast daytime working hours, but I know I'm weird
589 2012-09-09 19:34:41 <gmaxwell> I'm still waiting to hear if this could be scriptsig/p2sh only. With that revision my complaint mostly reduces to the general 'we really need a payment protocol before enabling any use that would discourage the creation of a payment protocol'
590 2012-09-09 19:34:48 <gmaxwell> gavinandresen: for some reason I thought you were on the west coast.
591 2012-09-09 19:35:00 <Luke-Jr> I'm usually pretty flexible, but need to do school dropoff/pickup at 1120 and 1820 (1930 Fridays)
592 2012-09-09 19:35:02 <gavinandresen> gmaxwell: nope, massachusetts
593 2012-09-09 19:35:18 <gavinandresen> 19:30 Fridays it is then.
594 2012-09-09 19:35:22 <gavinandresen> (KIDDING!)
595 2012-09-09 19:35:32 <sipa> i think my biorhythm has diverged to almost westcoast USA anyway...
596 2012-09-09 19:35:35 <Luke-Jr> O.o
597 2012-09-09 19:36:02 <Luke-Jr> oh, I get it ;)
598 2012-09-09 19:36:12 <sipa> gavinandresen: ok, next one will be from the conference? :)
599 2012-09-09 19:36:48 <gavinandresen> sipa: sure, I can be on IRC during the conference (I won't be at the conference....)
600 2012-09-09 19:37:20 <sipa> wait, 19:30 eastcoast is like 4:30 am in london...
601 2012-09-09 19:37:34 <gmaxwell> my mondays are a cesspool of meetings, friday afternoons I'm cut out  Otherwise I can generally slot out an hour any time in east cost working hours, or anytime outside of them.
602 2012-09-09 19:37:42 <gavinandresen> I was kidding about 19:30 eastcoast
603 2012-09-09 19:37:42 <Luke-Jr> sipa: my times are UTC
604 2012-09-09 19:38:24 <Luke-Jr> since I'm sure nobody here wants me to say my availability in Tonal time
605 2012-09-09 19:41:46 <Luke-Jr> gavinandresen: btw, I'm hoping to know today or tomorrow what the cause of Eligius's invalid blocks is from; just in case it turns out to be a subtle problem with the getblocktemplate output, it might be a good idea to wait on any final 0.7.0 until then (but it's probably VERY unlikely IMO)
606 2012-09-09 19:42:09 <gavinandresen> afk to feed hungry kids...
607 2012-09-09 19:42:28 <sipa> gmaxwell: by the way, parallel sig checking seems to work, but has a high overhead right now
608 2012-09-09 19:42:45 <sipa> gmaxwell: i get a 2x speedup by fully using 4 cores
609 2012-09-09 19:44:47 <Luke-Jr> :o
610 2012-09-09 19:44:54 <gmaxwell> sipa: hm. One way to implement would be fully async.. assume the sigs are valid.. and then go back and kill the block and force a reorg if you find out otherwise. That should elimate overhead.. but pretty tricky to implement.
611 2012-09-09 19:44:56 <Luke-Jr> sipa: any effect on interactivity/
612 2012-09-09 19:45:07 <sipa> gmaxwell: exactly how it's implemented
613 2012-09-09 19:45:08 <Luke-Jr> gmaxwell: ++
614 2012-09-09 19:45:27 <sipa> the overhead comes from copying the script data to the queue
615 2012-09-09 19:45:31 <gmaxwell> ha! cool! but .. I'm surprised of the high overhead.. I suppose you're single threading through the cache?
616 2012-09-09 19:45:38 <gmaxwell> oh. ha.
617 2012-09-09 19:45:58 <sipa> well, and sync stuff
618 2012-09-09 19:46:34 <sipa> but there are severel inefficiencies in the implementation
619 2012-09-09 19:46:43 <sipa> as i keep the transaction to be checked inside the queue
620 2012-09-09 19:47:05 <sipa> which effectively means a data blowup of #blocksize * avg_number_inputs
621 2012-09-09 19:47:11 <BlueMatt> oh, you implemented parallel sig checking (again)? nice
622 2012-09-09 19:47:35 <BlueMatt> just do it in ConnectInputs
623 2012-09-09 19:47:38 <sipa> adding a queue to keep the block cached and use pointers into that should help a lot
624 2012-09-09 19:47:39 <BlueMatt> its surprisingly easy there
625 2012-09-09 19:47:55 <sipa> BlueMatt: ?
626 2012-09-09 19:48:05 <sipa> obviously, that's where it is done
627 2012-09-09 19:49:03 <BlueMatt> so why are you queueing txes?
628 2012-09-09 19:49:32 <sipa> i have a CScriptCheck that represents a script being validated
629 2012-09-09 19:49:55 <sipa> and contains the txout and txin and whatever is fed to VerifyScript
630 2012-09-09 19:50:03 <sipa> or VerifySignature, can't remember
631 2012-09-09 19:50:05 <BlueMatt> oh, heh nvm I was thinking of the code wrong..
632 2012-09-09 19:50:06 <firelegend> I looked at the example python code of mini private keys, and was able to write my own Java implementation. But is there a min/max limit of mini private key length?
633 2012-09-09 19:50:21 <sipa> firelegend: ask casascius
634 2012-09-09 19:50:34 <BlueMatt> oh, I meant thread ConnectInputs entirely, dont just thread VerifyScript
635 2012-09-09 19:50:59 <Luke-Jr> firelegend: I don't think any regulars here work with "mini private keys"
636 2012-09-09 19:50:59 <sipa> per-transaction?
637 2012-09-09 19:51:05 <BlueMatt> but, its no big difference there
638 2012-09-09 19:51:16 <sipa> BlueMatt: that may help, yes
639 2012-09-09 19:51:32 <BlueMatt> yea, it ends up being per-tx, but thats no big deal
640 2012-09-09 19:51:39 <sipa> but i was planning to add some global block cache, which keeps recently seen blocks in memory, with refcounts
641 2012-09-09 19:52:02 <sipa> and the sig checking could then lock them, and just point into it, instead of needing to copy everything
642 2012-09-09 19:52:23 <BlueMatt> you could just adapt the code already written: https://github.com/TheBlueMatt/bitcoin/commits/parallelsigs...
643 2012-09-09 19:52:27 <firelegend> Luke-Jr: I had nothing else to do, so I decided to write my own implementation in Java but the wiki article does not state if there is any key lenght limit
644 2012-09-09 19:52:49 <sipa> BlueMatt: no offence, but i'm not rebasing ultraprune over another major rewrite
645 2012-09-09 19:53:22 <BlueMatt> no, no I dont want you to
646 2012-09-09 19:53:37 <BlueMatt> Im just saying use the few commits already there and adapt the how-its-put-in-callbacks stuff to use ultraprune
647 2012-09-09 19:54:16 <firelegend> I suppose I will limit it between 22 and 30
648 2012-09-09 19:54:30 <jgarzik> ok, OP_DROP multisig transactions now require a fee
649 2012-09-09 19:54:32 <jgarzik> pushed
650 2012-09-09 19:54:39 <jgarzik> good idea, btw
651 2012-09-09 19:55:52 <jgarzik> TD: actively working on distributed bond markets
652 2012-09-09 19:56:05 <sipa> jgarzik: any idea yet whether having the data in scriptSig or P2SH would work?
653 2012-09-09 19:56:39 <jgarzik> sipa: scriptSig does not look like it will work
654 2012-09-09 19:56:43 <jgarzik> sipa: P2SH maybe
655 2012-09-09 19:56:48 <gmaxwell> ^ I've been resisting nagging; that would substantially change my view.
656 2012-09-09 19:56:57 <gmaxwell> jgarzik: hm. Why wouldn't it work in scriptsig?
657 2012-09-09 19:58:04 <TD> jgarzik: looking forward to seeing what you come up with
658 2012-09-09 19:58:25 <jgarzik> gmaxwell: storing it in the output is used for tracking current owner, among other uses
659 2012-09-09 19:59:10 <jgarzik> TD: just doing an absolutely minimum bond implementation, without pay-to-policy
660 2012-09-09 19:59:37 <gmaxwell> jgarzik: hm. but can't the scriptsig do that too? You'd just present the unpruned transaction paying you.
661 2012-09-09 19:59:48 <TD> sure
662 2012-09-09 20:00:02 <gmaxwell> oh bleh without pay to policy its no better than the crazy colored coin stuff, except with more externalized costs.
663 2012-09-09 20:00:09 <jgarzik> it sure seems more convenient implementation wise
664 2012-09-09 20:00:12 <TD> jgarzik: ppp is for the investment fund stuff
665 2012-09-09 20:00:20 <TD> so it can wait
666 2012-09-09 20:00:24 <TD> one comes after the other
667 2012-09-09 20:00:27 <jgarzik> nod
668 2012-09-09 20:00:29 <jgarzik> one step at a time
669 2012-09-09 20:01:06 <gmaxwell> jgarzik: have you seen the colored coin stuff? It adds no blockchain data at all. You agree that coin X is a bond, then you just trace the ownership through.
670 2012-09-09 20:01:59 <gmaxwell> (with some rules that prevent inflation should the bond coin get mixed)
671 2012-09-09 20:02:01 <jgarzik> gmaxwell: familiar with the concept yes.  haven't seen any implementations.
672 2012-09-09 20:02:11 <TD> the trick being the "agree that coin x" part
673 2012-09-09 20:02:15 <jgarzik> indeed
674 2012-09-09 20:02:18 <gmaxwell> jgarzik: there is one... it's linked in the forum.
675 2012-09-09 20:02:52 <gmaxwell> TD: you still have to have some way of initially issuing a bond in any bond system, and agreeing on what it means. It's not like bitcoin itself can only let you make a transaction if you also hand over keys to a car. :)
676 2012-09-09 20:02:52 <Luke-Jr> fun toy: run bitcoind -loadblock=??? -rpcpassword= <-- loads blocks and quits :D\\
677 2012-09-09 20:03:05 <gmaxwell> Luke-Jr: hah "feature"
678 2012-09-09 20:03:08 <jgarzik> for now, bond+tx atomicity make life simple, reliable and secure WRT coin transfer.  once I've something running on testnet, I'll be more interested in crazy ideas
679 2012-09-09 20:03:50 <gmaxwell> jgarzik: well the point is that coin color proposals achieve that without adding data.
680 2012-09-09 20:03:57 <gmaxwell> Basically the coin itself is the identifier.
681 2012-09-09 20:04:17 <jgarzik> gmaxwell: with external metadata you have additional reliability problems
682 2012-09-09 20:04:26 <jgarzik> definitely much more complex
683 2012-09-09 20:05:15 <gmaxwell> jgarzik: the cost of storing data is _enormously_ increased (by something like 40,000 fold today more in the future) by putting it in the blockchain. You only think you've solved it because you're parasitically externalizing the cost.
684 2012-09-09 20:05:38 <gmaxwell> Plus you've still got an external storage issue in your system.
685 2012-09-09 20:06:21 <gmaxwell> which you'll ignore with a non-robust DHT thing.. so people will probably still need to keep all the important data themselves to avoid the risk of the dht getting flooded and forgetting it.
686 2012-09-09 20:06:38 <jgarzik> gmaxwell: you are welcome to code this :)
687 2012-09-09 20:06:52 <gmaxwell> jgarzik: I don't have to, people already coded coin coloring.
688 2012-09-09 20:06:59 <gmaxwell> Which I think is stupid, but for different reasons. :)
689 2012-09-09 20:07:10 <jgarzik> that's luke-jr-level hair splitting
690 2012-09-09 20:07:27 <jgarzik> it's nothing like full distributed bond system
691 2012-09-09 20:07:27 <Luke-Jr> ????????????
692 2012-09-09 20:07:36 <gmaxwell> https://bitcointalk.org/index.php?topic=106449.0 and https://bitcointalk.org/index.php?topic=106373.0
693 2012-09-09 20:08:03 <TD> i'm entertained by arguments about whether the block chain in future will be very expensive or _very_ expensive
694 2012-09-09 20:08:18 <TD> i see two expensive things and a few hashes here or there isn't going to make or break the endevour
695 2012-09-09 20:08:36 <gmaxwell> TD: or ... not expensive at all?
696 2012-09-09 20:09:05 <gmaxwell> TD: as it is, bitcoin _can't_ be very expensive to run a full node. We'd need a hardfork to make it actually expensive.
697 2012-09-09 20:10:11 <gmaxwell> Where I'm defining expensive to mean something on the order of "I don't _already_ have the resources to run it 100 years henceforth, at home"
698 2012-09-09 20:11:43 <sipa> i'm not so much worried about the size of the blockchain (if it's data that doesn't enter the utxo set anyway), as i'm worried about opening up the blockchain to be used as a messaging platform
699 2012-09-09 20:11:56 <gmaxwell> jgarzik: I'm not sure what you're calling hair splitting,  the code is here: https://github.com/killerstorm/bitcoin/tree/cbtc   It doesn't address issuing bonds, but once you've done something to issue one it will happily use bitcoin to track ownership.
700 2012-09-09 20:15:55 <MC1984> blockchain messenger
701 2012-09-09 20:16:08 <MC1984> wernt we all rather cross with the last dude who tried to do that
702 2012-09-09 20:16:22 <gmaxwell> MC1984: where are you in this whole discussion? how come I've got to play chicken little. Thats your job!
703 2012-09-09 20:16:39 <MC1984> watching 5th element
704 2012-09-09 20:17:08 <gmaxwell> 
ACTION dumps MC1984 out of the JOHNNY CAB

705 2012-09-09 20:17:18 <gmaxwell> (only thing I remember from that movie)
706 2012-09-09 20:17:18 <TD> sipa: the question is where do you draw the line between "useful script" and "abusive messaging"
707 2012-09-09 20:17:26 <MC1984> no thats total recall
708 2012-09-09 20:17:30 <gmaxwell> oh ha!
709 2012-09-09 20:17:40 <TD> i think stuffing a movie or DNS system into the block chain would count as "abuse" as it really has nothing to do with finance or payments
710 2012-09-09 20:17:53 <Luke-Jr> Multipass.
711 2012-09-09 20:18:08 <TD> bond markets and pay-to-policy outputs, even if expensive, aren't abusive to me as they further the goal of having a peer to peer financial system
712 2012-09-09 20:18:11 <MC1984> MULTIPASS
713 2012-09-09 20:18:17 <MC1984> milla jojovich DFC
714 2012-09-09 20:19:10 <gmaxwell> TD: I'd take that definition and extend it a step further??? does the system externalized costs (push expense on to disinterested parties) more than necessary?
715 2012-09-09 20:19:35 <gmaxwell> TD: the colored coin stuff shows that if all you're doing is tracking ownership you can use bitcoin for that without adding any data beyond the ownership changes themselves.
716 2012-09-09 20:20:09 <gmaxwell> adding data just externalizes a cost: lest to reliably store in your DHT or whatever, at the expense of hundreds of thousands of bitcoin full nodes storing it for you.
717 2012-09-09 20:20:24 <MC1984> yes moar DHT
718 2012-09-09 20:20:51 <Luke-Jr> 
ACTION wonders how much time bitcoind's peering policies add to block propagation

719 2012-09-09 20:21:10 <BlueMatt> Luke-Jr: make a bitcoin backbone and find out
720 2012-09-09 20:21:14 <Luke-Jr> maybe bitcoind should measure latency and use the lowest-latency links for blocks
721 2012-09-09 20:21:54 <gmaxwell> Luke-Jr: someplace I made a simple suggestion: keep a list of peers, every time a peer is the first peer to tell you of a block, move it one up in the list.
722 2012-09-09 20:21:57 <gmaxwell> Luke-Jr: relay in that order.
723 2012-09-09 20:22:08 <Luke-Jr> hm
724 2012-09-09 20:23:27 <MC1984> i said this 2 days ago
725 2012-09-09 20:23:49 <edcba> gmaxwell: so pools get the best connectivity ?
726 2012-09-09 20:24:09 <gmaxwell> (alternatively you can have a higher learing rate by moving all the way to the front, and if you do that it's called "move to front" in the field of entropy coding, and for many kinds of non-stationary probablity models gives you a result no worse than a few percent off the best known adaptation)
727 2012-09-09 20:24:48 <edcba> 
ACTION will use the same algorithm to prevent relaying tx with fees to those nodes ! :)

728 2012-09-09 20:24:50 <kjj_> if you prioritize connections, you should intentionally ditch your worst connection from time to time
729 2012-09-09 20:24:52 <gmaxwell> edcba: it's not about connectivity, it's about ordering. Nodes who are fast to give you blocks will probably be fast to propagate other blocks, so you feed them first.
730 2012-09-09 20:25:03 <yellowhat> just set-up a fresh ubuntu laptop. i noticed it in the software center 0.3.24 is offered. feels a bit wrong for me
731 2012-09-09 20:25:20 <gmaxwell> yellowhat: can you please bug ubuntu to remove that software? it's insecure and unsupported.
732 2012-09-09 20:25:22 <Luke-Jr> yellowhat: blame your OS
733 2012-09-09 20:25:38 <Luke-Jr> yellowhat: get Ubuntu to upgrade to 0.4.8 or ditch it
734 2012-09-09 20:25:49 <kjj_> the PPA is current
735 2012-09-09 20:25:51 <Luke-Jr> (or 0.6.3, but ??? that's less likely)
736 2012-09-09 20:26:18 <yellowhat> i'll file a bug.
737 2012-09-09 20:27:28 <gmaxwell> kjj_: sipa has a whole peer rotation idea worked up but not implemented yet; he's done simulations and such, and he and I hashed out a whole bunch of corner cases that should be addresses. (e.g. overdesigned, like addrman, but that hasn't burned us yet :P)
738 2012-09-09 20:28:02 <gmaxwell> kjj_: naively following your advice would be really dangerous.
739 2012-09-09 20:28:30 <kjj_> ditching the worst node would be dangerous?
740 2012-09-09 20:28:53 <gmaxwell> kjj_: Yes.  because, e.g. links that hop between europe and the US are much more likely to be your worst peer... and not just your worst peer, _everyones_ worse peer, because of the speed of light and all.
741 2012-09-09 20:29:20 <gmaxwell> kjj_: so doing that alone would greatly increase the likelyhood that eu and us would partition, or at least be weakly connected and partition easily if a cable were cut.
742 2012-09-09 20:30:59 <sipa> iirc, the idea was to add a new connection from time to time, and kick out one connection when it succeeds; the choice for which would be with a probability proportional to time_already_connected ** (-0.8), so the most recent connection has the highest chance of being disconnected
743 2012-09-09 20:31:19 <sipa> and add to that some score kept per node, modified by relaying blocks quickly
744 2012-09-09 20:32:04 <gmaxwell> The partitioning risk can be addressed by only considering some slots for rotation instead of all of them; so, e.g., that at least some US nodes would be likely to have some EU nodes in the excempted list.
745 2012-09-09 20:32:07 <sipa> that gives you a nice distribution at any time of some recent peers and some old ones
746 2012-09-09 20:32:41 <Luke-Jr> IMO, it'd be nice to have 4 groups of nodes (so 2 in each group) and have a group for: lowest latency, highest latency, lowest bandwidth, highest bandwidth
747 2012-09-09 20:33:14 <sipa> bandwidth is only really relevant during IBD, imho
748 2012-09-09 20:33:28 <yellowhat> for mobile (or any) client a good objective would be to have at least 1 well-connected node so that the average hop count can go down dramatically.
749 2012-09-09 20:34:10 <Luke-Jr> maybe instead of "lowest bandwidth" have "continuously rotating"
750 2012-09-09 20:34:20 <Luke-Jr> sipa: bandwidth is important for block relaying in general IMO
751 2012-09-09 20:34:25 <denisx> i hate the bitcoind progrssbar, it is only useful when initiallly downloading the blockchain and then never again ;(
752 2012-09-09 20:34:39 <Luke-Jr> sipa: after we get rid of all the processing delays, upload time will be the sole remaining factor in propagation
753 2012-09-09 20:34:47 <sipa> denisx: imho we should remove it :)
754 2012-09-09 20:34:52 <Luke-Jr> denisx: I agree, it should just be a block remaining count in text
755 2012-09-09 20:35:07 <denisx> I liked it the way it was before
756 2012-09-09 20:35:07 <gmaxwell> Luke-Jr: for the small amounts of data we transmit measuring latency and bandwidth is effectively the same thing.
757 2012-09-09 20:35:10 <sipa> or the age of the best block
758 2012-09-09 20:35:33 <Luke-Jr> gmaxwell: blocks aren't small always
759 2012-09-09 20:35:43 <Luke-Jr> sipa: or both
760 2012-09-09 20:35:44 <sipa> denisx: before, people thought that quitting the client and restarting would lose progress because of the bar
761 2012-09-09 20:36:27 <Luke-Jr> also, it would be nice to replace the 99.x% measurement with "5 nines" etc once it gets to 99% ;)
762 2012-09-09 20:36:30 <sipa> 
ACTION announces he's 28 now

763 2012-09-09 20:36:40 <Luke-Jr> sipa: happy birthday! are you my brother-in-law? :P
764 2012-09-09 20:36:47 <gmaxwell> sipa: happy birthday.
765 2012-09-09 20:36:54 <gmaxwell> Luke-Jr: thats .. an odd question 0_o
766 2012-09-09 20:36:56 <Luke-Jr> lol
767 2012-09-09 20:36:59 <denisx> sipa: yes, some people maybe...
768 2012-09-09 20:37:07 <Luke-Jr> nah, my brother-in-law would have turned 25 or something today
769 2012-09-09 20:37:43 <sipa> Luke-Jr: without a sister or wife, that is hard
770 2012-09-09 20:37:47 <Luke-Jr> XD
771 2012-09-09 20:38:16 <yellowhat> should i file as a security bug (bug is private and security group will be notified) WRT the old bitcoin version in ubuntu?
772 2012-09-09 20:38:56 <Luke-Jr> yellowhat: nah, it's common knowledge that 0.3.24 is vulnerable to a ton of exploits.
773 2012-09-09 20:39:11 <sipa> Luke-Jr: i doubt the ubuntu packagers are aware of that
774 2012-09-09 20:39:21 <Luke-Jr> sipa: maybe, but it's no reason to keep the bug private
775 2012-09-09 20:39:30 <sipa> ah
776 2012-09-09 20:39:54 <yellowhat> is there a remote-code execution vuln. in 0.3.24? or "just" DOS attacks?
777 2012-09-09 20:40:13 <Luke-Jr> https://en.bitcoin.it/wiki/CVEs
778 2012-09-09 20:40:28 <Luke-Jr> looks like the worse is a Netsplit attack
779 2012-09-09 20:41:00 <gmaxwell> yellowhat: netsplit attacks allow you to rob people, however.
780 2012-09-09 20:41:26 <yellowhat> i hope this looks ok: https://bugs.launchpad.net/ubuntu/+source/bitcoin/+bug/1048412
781 2012-09-09 20:42:01 <sipa> i'd fix the type
782 2012-09-09 20:42:04 <sipa> *typo
783 2012-09-09 20:42:09 <sipa> Damnit.
784 2012-09-09 20:42:27 <yellowhat> which one?
785 2012-09-09 20:42:46 <sipa> upgrde
786 2012-09-09 20:43:05 <MC-Eeepc> happy birthday sipa
787 2012-09-09 20:43:09 <MC-Eeepc> now get back to work
788 2012-09-09 20:43:24 <sipa> haha :)
789 2012-09-09 20:44:16 <edcba> were you 27 yesterday ?
790 2012-09-09 20:45:06 <sipa> 27.997 something
791 2012-09-09 20:45:18 <edcba> happy rounding !
792 2012-09-09 20:45:28 <sipa> thx!
793 2012-09-09 20:46:34 <edcba> why some CVE have no disclosure ?
794 2012-09-09 20:46:55 <yellowhat> happy birthday sipa !
795 2012-09-09 20:47:06 <sipa> yellowhat: btw, i believe the reason for ubuntu not upgrading beyond 0.3.24, is because as of 0.4.0, unit tests fail on some architectures
796 2012-09-09 20:47:23 <sipa> not that 0.3.24 did work on those, it just didn't have unit tests...
797 2012-09-09 20:47:30 <yellowhat> i don't have high hopes of ubuntu fixing this quickly: https://bugs.launchpad.net/ubuntu/+source/bitcoin/+bug/1011675 this one is  3 months old and reported the same as mine.
798 2012-09-09 20:48:06 <gmaxwell> yellowhat: if you'd like, you can start a node up with 0.3.24 and I can rob you. Then you can report you were robbed. :P
799 2012-09-09 20:48:21 <yellowhat> sounds great
800 2012-09-09 20:48:27 <Luke-Jr> lol
801 2012-09-09 20:48:30 <sipa> let's do this on testnet
802 2012-09-09 20:48:51 <sipa> as testnet coins were once exchanged for realnet ones, you can still claim you were robbed
803 2012-09-09 20:48:58 <Luke-Jr> ???
804 2012-09-09 20:49:09 <Luke-Jr> is there a risk to doing it on mainnet? :p
805 2012-09-09 20:49:20 <gmaxwell> well I was just thinking of sending him some neverconfirmable internal doublespend txn, which I think 0.3.24 will still show.
806 2012-09-09 20:49:22 <edcba> 
ACTION claims gmaxwell robbed him 1000 btc

807 2012-09-09 20:49:37 <gmaxwell> For some attacks there is certantly a risk... but there are ones that wouldn't be.
808 2012-09-09 20:49:49 <sipa> gmaxwell: oh, so easy; forgot about that one!
809 2012-09-09 20:49:50 <MC-Eeepc> is 0.3 reallt that bad
810 2012-09-09 20:50:06 <Luke-Jr> MC-Eeepc: yes
811 2012-09-09 20:50:09 <Luke-Jr> 0.6.0 is too
812 2012-09-09 20:50:11 <edcba> 
ACTION wonder which version last installed...

813 2012-09-09 20:50:46 <MC-Eeepc> where can i get the first version satoshi released
814 2012-09-09 20:50:48 <gmaxwell> the forrestv block killing attack isn't transitive.. you could use it to target a new node and fork them at an early block then mine that fork.
815 2012-09-09 20:50:58 <edcba> 06/08/2010
816 2012-09-09 20:51:02 <edcba> alright !
817 2012-09-09 20:51:20 <sipa> edcba: what's that?