12015-12-28T00:02:33 *** xiangfu has quit IRC
22015-12-28T00:13:56 <Luke-Jr> sipa: indeed, I think the decision whether to translate or not really lies with the target languag
32015-12-28T00:14:11 <Luke-Jr> when it is inappropriate, the translators can just leave it as-is
42015-12-28T01:04:07 *** brg444 has quit IRC
52015-12-28T01:08:44 *** ghtdak has quit IRC
62015-12-28T01:19:10 *** Thireus has quit IRC
72015-12-28T01:23:18 *** ghtdak has joined #bitcoin-core-dev
82015-12-28T01:44:33 *** Ylbam has quit IRC
92015-12-28T01:49:44 *** Thireus has joined #bitcoin-core-dev
102015-12-28T02:03:58 *** Tera2342 has joined #bitcoin-core-dev
112015-12-28T02:04:45 *** xiangfu has joined #bitcoin-core-dev
122015-12-28T03:46:13 *** zookolap` has quit IRC
132015-12-28T03:46:22 *** zookolaptop has quit IRC
142015-12-28T04:03:22 *** belcher has quit IRC
152015-12-28T04:16:25 *** Tera2342 has quit IRC
162015-12-28T04:17:42 *** Tera2342 has joined #bitcoin-core-dev
172015-12-28T04:46:50 *** xiangfu has quit IRC
182015-12-28T04:52:37 *** xiangfu has joined #bitcoin-core-dev
192015-12-28T05:36:50 *** Guest90279 is now known as amiller
202015-12-28T05:37:20 *** amiller is now known as Guest1038
212015-12-28T05:49:23 *** tripleslash_w is now known as [\\\]
222015-12-28T06:03:18 *** xiangfu has quit IRC
232015-12-28T06:03:50 *** xiangfu has joined #bitcoin-core-dev
242015-12-28T06:35:16 *** p15 has joined #bitcoin-core-dev
252015-12-28T06:54:12 *** Thireus has quit IRC
262015-12-28T07:14:17 *** Thireus has joined #bitcoin-core-dev
272015-12-28T07:14:20 *** xiangfu has quit IRC
282015-12-28T07:14:40 *** xiangfu has joined #bitcoin-core-dev
292015-12-28T07:23:30 *** cryptopeddler has quit IRC
302015-12-28T07:25:22 *** cryptopeddler has joined #bitcoin-core-dev
312015-12-28T07:27:34 *** Thireus has quit IRC
322015-12-28T07:32:15 *** Tera2342 has quit IRC
332015-12-28T07:33:10 *** cryptopeddler has quit IRC
342015-12-28T07:34:35 *** cryptopeddler has joined #bitcoin-core-dev
352015-12-28T08:10:35 *** Amnez777 has quit IRC
362015-12-28T08:44:19 *** Amnez777 has joined #bitcoin-core-dev
372015-12-28T08:46:56 *** Amnez777 has quit IRC
382015-12-28T08:46:56 *** Amnez777 has joined #bitcoin-core-dev
392015-12-28T08:58:03 *** MarcoFalke has joined #bitcoin-core-dev
402015-12-28T09:29:52 *** Tera2342 has joined #bitcoin-core-dev
412015-12-28T09:30:38 *** Thireus has joined #bitcoin-core-dev
422015-12-28T09:31:12 *** Ylbam has joined #bitcoin-core-dev
432015-12-28T09:34:06 *** BashCo has joined #bitcoin-core-dev
442015-12-28T09:55:20 *** JackH has joined #bitcoin-core-dev
452015-12-28T10:21:12 *** raedah has quit IRC
462015-12-28T10:38:07 *** wangchun has quit IRC
472015-12-28T10:39:46 *** wangchun has joined #bitcoin-core-dev
482015-12-28T10:40:50 *** JackH has quit IRC
492015-12-28T10:49:50 *** laurentmt has joined #bitcoin-core-dev
502015-12-28T10:50:42 *** laurentmt has quit IRC
512015-12-28T10:51:26 *** JackH has joined #bitcoin-core-dev
522015-12-28T11:00:09 *** JackH has quit IRC
532015-12-28T11:19:19 *** Guyver2 has joined #bitcoin-core-dev
542015-12-28T11:30:02 *** Thireus has quit IRC
552015-12-28T11:34:15 *** JackH has joined #bitcoin-core-dev
562015-12-28T12:13:12 *** afk11 has joined #bitcoin-core-dev
572015-12-28T12:38:55 *** afk11 has quit IRC
582015-12-28T12:39:31 *** afk11 has joined #bitcoin-core-dev
592015-12-28T13:20:01 <Luke-Jr> anyone happen to remember what the whitelist-peer hack is needed to get RPC tests to pass on 0.10/0.11? :/
602015-12-28T13:42:38 *** p15 has quit IRC
612015-12-28T14:16:20 *** Tera2342 has quit IRC
622015-12-28T14:17:20 *** brg444 has joined #bitcoin-core-dev
632015-12-28T14:17:36 *** cryptopeddler has quit IRC
642015-12-28T14:19:14 *** cryptopeddler has joined #bitcoin-core-dev
652015-12-28T14:46:43 *** belcher has joined #bitcoin-core-dev
662015-12-28T14:54:05 *** civos has quit IRC
672015-12-28T15:14:26 *** cryptopeddler has quit IRC
682015-12-28T15:16:14 *** cryptopeddler has joined #bitcoin-core-dev
692015-12-28T16:09:02 *** tripleslash_t has joined #bitcoin-core-dev
702015-12-28T16:11:00 *** [\\\] has quit IRC
712015-12-28T16:23:01 *** BashCo has quit IRC
722015-12-28T16:24:45 *** JackH has quit IRC
732015-12-28T16:35:42 *** zookolaptop has joined #bitcoin-core-dev
742015-12-28T16:44:17 *** afk11 has quit IRC
752015-12-28T16:56:13 *** laurentmt has joined #bitcoin-core-dev
762015-12-28T16:56:26 *** laurentmt has quit IRC
772015-12-28T17:17:03 *** BashCo has joined #bitcoin-core-dev
782015-12-28T17:22:00 *** MarcoFalke has left #bitcoin-core-dev
792015-12-28T17:47:02 *** JackH has joined #bitcoin-core-dev
802015-12-28T17:49:28 *** jayd3e has joined #bitcoin-core-dev
812015-12-28T18:02:48 *** Luke-Jr has quit IRC
822015-12-28T18:03:54 *** Luke-Jr has joined #bitcoin-core-dev
832015-12-28T18:44:34 *** jcorgan is now known as jcorgan|away
842015-12-28T18:49:22 *** belcher has quit IRC
852015-12-28T18:59:59 <jayd3e> I'm receiving this error "scheduler.h:14:35: fatal error: boost/chrono/chrono.hpp: No such file or directory", even though I have installed libboost-dev-all
862015-12-28T19:00:37 <jayd3e> followed the directions for 12.04 exactly
872015-12-28T19:00:46 <phantomcircuit> jayd3e, iirc chrono is missing in older versions of ubuntu
882015-12-28T19:01:12 <jayd3e> so use 14.04?
892015-12-28T19:02:15 <jayd3e> phantomcircuit:
902015-12-28T19:02:42 <phantomcircuit> jayd3e, sorry i dont know which ubuntu versions will work
912015-12-28T19:02:47 <phantomcircuit> i dont think 12.04 will though
922015-12-28T19:02:51 <jayd3e> kk
932015-12-28T19:34:06 *** JackH has quit IRC
942015-12-28T19:42:42 *** gijensen has quit IRC
952015-12-28T19:47:04 *** raedah has joined #bitcoin-core-dev
962015-12-28T19:49:03 *** gijensen has joined #bitcoin-core-dev
972015-12-28T19:50:07 *** JackH has joined #bitcoin-core-dev
982015-12-28T20:07:01 *** jcorgan|away is now known as jcorgan
992015-12-28T20:20:37 *** c-cex-finch has joined #bitcoin-core-dev
1002015-12-28T20:59:39 *** neilf has joined #bitcoin-core-dev
1012015-12-28T21:00:59 *** zookolaptop has quit IRC
1022015-12-28T21:37:11 *** laurentmt has joined #bitcoin-core-dev
1032015-12-28T21:37:46 *** laurentmt has quit IRC
1042015-12-28T21:38:35 *** zookolaptop has joined #bitcoin-core-dev
1052015-12-28T21:52:53 *** Guest1038 has quit IRC
1062015-12-28T21:52:54 *** Guest1038 has joined #bitcoin-core-dev
1072015-12-28T21:52:54 *** Guest1038 is now known as amiller
1082015-12-28T21:59:16 *** raedah has quit IRC
1092015-12-28T21:59:47 <morcos> CodeShark: sorry, dirty way of getting your attention
1102015-12-28T22:00:05 <CodeShark> No worries :)
1112015-12-28T22:00:07 <morcos> Are we still trying to get this rolled out as the next soft fork
1122015-12-28T22:00:51 <morcos> if so we should be concentrating core development effort on all of these things so we can show progress. versionbits, BIP68/CSV, segwit
1132015-12-28T22:01:25 <morcos> but there doesn't seem to have been any movement on the versionbits PR for quite some time
1142015-12-28T22:01:26 <btcdrak> who is doing the final implementation now, CodeShark or rusty?
1152015-12-28T22:01:31 <morcos> oh
1162015-12-28T22:01:35 <morcos> see i didn't know about that
1172015-12-28T22:01:37 <CodeShark> I think the segwit testnet has taken priority right now
1182015-12-28T22:01:41 <morcos> is there a different implementation?
1192015-12-28T22:01:52 <morcos> is that something that is being worked on?
1202015-12-28T22:02:01 <morcos> i asked sipa about that earlier and he didn't reply
1212015-12-28T22:02:09 <morcos> where is that happening?
1222015-12-28T22:02:13 <btcdrak> morcos: even if versionbits was not ready we can still deploy using ISM though...
1232015-12-28T22:02:23 *** Thireus1 has joined #bitcoin-core-dev
1242015-12-28T22:03:11 <petertodd> morcos: and there's still my pseudo-versionbits proposal that we can use too
1252015-12-28T22:03:34 <morcos> sure i agree we don't have to have versionbits before segwit
1262015-12-28T22:03:47 <morcos> i just thought that was what wumpus laid out in his plan
1272015-12-28T22:04:09 <petertodd> also, for the record, I would NACK segwit myself without a validationless mining fix
1282015-12-28T22:04:20 *** zookolaptop has quit IRC
1292015-12-28T22:05:18 *** Thireus1 has quit IRC
1302015-12-28T22:05:27 *** Thireus has joined #bitcoin-core-dev
1312015-12-28T22:05:43 <CodeShark> wanna help implement that, petertodd?
1322015-12-28T22:06:38 <petertodd> CodeShark: yes, but note that I have no funding right now for core dev work, so I can't promise anything
1332015-12-28T22:07:23 <petertodd> CodeShark: that said, I'm fairly certainly I'll be able to get some soon
1342015-12-28T22:07:31 *** Thireus1 has joined #bitcoin-core-dev
1352015-12-28T22:07:50 <CodeShark> the short-term objective is to deploy a functional testnet without all the intended features and to set up a framework for adding more features
1362015-12-28T22:08:58 <petertodd> CodeShark: makes sense to me
1372015-12-28T22:09:00 *** Thireus1 has quit IRC
1382015-12-28T22:09:57 *** Thireus1 has joined #bitcoin-core-dev
1392015-12-28T22:10:21 *** Thireus has quit IRC
1402015-12-28T22:11:03 <CodeShark> deployment to mainnet is still at least another couple months away, I'd say...once we near that we can figure out which activation mechanism we'll use
1412015-12-28T22:11:41 <CodeShark> So versionbits is now on the backburner
1422015-12-28T22:12:55 *** raedah has joined #bitcoin-core-dev
1432015-12-28T22:13:16 *** brg444 has quit IRC
1442015-12-28T22:14:06 <CodeShark> If you have some extra time and want to dig in, petertodd, I'd love to hear your suggestions
1452015-12-28T22:15:31 <petertodd> CodeShark: well, I'll see that I can do
1462015-12-28T22:16:40 *** zookolaptop has joined #bitcoin-core-dev
1472015-12-28T22:18:14 <morcos> /window 24
1482015-12-28T22:18:17 <morcos> oops
1492015-12-28T22:20:52 *** JackH has quit IRC
1502015-12-28T22:27:06 <sipa> petertodd: your suggestion is easy to implement for consensus rules; i just worry about the logic needed to get mining software to support it
1512015-12-28T22:27:27 <sipa> anything that changes the coinbase outputs needs extra logic
1522015-12-28T22:28:26 <btcdrak> CodeShark: what about rusty, he has code done also.
1532015-12-28T22:28:39 <btcdrak> oh wait, wrong conversion :)
1542015-12-28T22:28:46 *** Tera2342 has joined #bitcoin-core-dev
1552015-12-28T22:30:52 <petertodd> sipa: I'm not suggesting changing the coinbase outputs, just committing to something calculated form them
1562015-12-28T22:31:09 <petertodd> sipa: equaly, the idea probably would work even without the coinbase output commitment
1572015-12-28T22:31:44 <petertodd> sipa: important thing is that miners never soft-fork in a commitment to the prior-block possession proof in the prior block
1582015-12-28T22:33:00 <sipa> petertodd: you're suggesting making block X commit to for example H(full block X-1 incl witness, X's coinbase outouts) ?
1592015-12-28T22:33:21 <sipa> s/,/||/
1602015-12-28T22:33:23 <sipa> right?
1612015-12-28T22:36:03 <petertodd> sipa: yes
1622015-12-28T22:36:57 <sipa> which means that any software which computes the coinbase outouts will need updated code to compute the commitment
1632015-12-28T22:37:21 <petertodd> sipa: right, that's fair
1642015-12-28T22:37:37 <sipa> which for example makes the 21 computer incompatible with it
1652015-12-28T22:37:38 <petertodd> sipa: so maybe make it commit to H(full block X-1 + nonce)
1662015-12-28T22:37:45 <sipa> ah!
1672015-12-28T22:37:54 <sipa> what is nonce?
1682015-12-28T22:37:56 <petertodd> sipa: then soft-forking in a later committment to the coinbase outputs is possible, as is anything else
1692015-12-28T22:38:25 <petertodd> sipa: it's probably ok if the nonce can be picked arbitrarily - so long as miners don't actually soft-fork in a commitment to that commitment in the previous block, we're ok
1702015-12-28T22:38:35 <petertodd> sipa: and in fact, if it's the *full* block that's impossible :)
1712015-12-28T22:39:34 <sipa> i'm very interested in including solutions for this, but i think it will need input from people with more experience with mining software/hardware
1722015-12-28T22:39:49 <petertodd> sipa: agreed
1732015-12-28T22:39:51 *** Tera2342 has quit IRC
1742015-12-28T22:40:08 <petertodd> sipa: part of why I want to do this now, is because I think if we *don't* fix this, we will have significant pushback on fixing it later
1752015-12-28T22:40:12 <sipa> petertodd: also, i think you want the full block data at the end of the hash, so you can't compute a midstate for it
1762015-12-28T22:40:30 <petertodd> sipa: IE, we probably will have to allow a validationless mining alternative where you leave off the commitment, in exchange for an empty block
1772015-12-28T22:41:11 <petertodd> sipa: well, if the nonce is picked arbitrarily, that's technically not an issue, but yeah, best to do H(nonce + <data>)
1782015-12-28T22:44:22 <sipa> petertodd: i mean, you probably want to prevent a setup where someone can send a midstate of the full prevblock
1792015-12-28T22:45:34 <sipa> petertodd: i think there may be significant pushback against this already; any device that decides the coinbase but leaves tx selection up to something else will now need to be burdened with full blocks, where it only needed very low bandwidth beforehand
1802015-12-28T22:47:01 <petertodd> sipa: well, the fact that you can do that is probably a flaw in the bitcoin protocol
1812015-12-28T22:47:51 <morcos> sipa: "pushback against this" you mean segwit itself?
1822015-12-28T22:47:54 <petertodd> sipa: I'm just trying to at least get us back to thecurrent situation, where if you do validationless mining you're trusting others
1832015-12-28T22:48:03 <petertodd> sipa: IE, don't make the situation worse
1842015-12-28T22:48:20 <btcdrak> morcos: against validationless mining fix
1852015-12-28T22:48:43 <morcos> but the issue with the coinbase needing more data exists with just segwit
1862015-12-28T22:49:22 <petertodd> morcos: not quite - with just segwit the rest of the coinbase outputs can be picked freely
1872015-12-28T22:50:19 <sipa> morcos: segwit makes the coinbase input depend on tx selection
1882015-12-28T22:50:21 <morcos> petertodd: so what was the reasoning of having it commit to block X's coinbase outputs
1892015-12-28T22:50:51 <sipa> morcos: the fact that segwit allows easy mining without validating signatures
1902015-12-28T22:51:45 <petertodd> morcos: so, the reasoning of committing to H(nonce + prev-block-data) is to force you to have that data to be able to mine; making it H(coinbase-outputs + prev-block-data) would additionally constrain that calculation to be miner-specific
1912015-12-28T22:51:46 <morcos> yes i understand why to commit to previous blocks witness, but the point of it being your coinbase in there is just to prove that the computation had to be done individually for each miner
1922015-12-28T22:52:01 <morcos> right, ok
1932015-12-28T22:52:51 <petertodd> morcos: like I saidabove, it's probably sufficient to just make it H(nonce+prevblockdata), and if coinbase is worth committing too we can do that later with a H(H(nonce+coinbase)+prevblockdata) softfork
1942015-12-28T22:53:08 <morcos> so personally i'm not convinced of why this is so critically important, i think if you don't have enough full nodes validating everything to keep the network honest then we've failed anyway.
1952015-12-28T22:54:01 <morcos> the only thing from your email that i found particularly compelling though was maybe there is some gaming behind witholding your witness data
1962015-12-28T22:54:17 *** c-cex-finch has quit IRC
1972015-12-28T22:54:20 <petertodd> morcos: sure, but this makes it much easier for miners to skip validating - in practice that'll be a major engineering risk at the very least
1982015-12-28T22:54:41 <petertodd> morcos: minres don't like to do anything they don't have too- the existing validationless mining code they run is scary enough
1992015-12-28T22:54:42 <morcos> so anyway, to sipas point about pushback.. there would no additional pushback to the H(nonce + prevblockdata) approach then
2002015-12-28T22:55:01 <petertodd> morcos: I don't think there would be, same kind of data needed to calculate segwit
2012015-12-28T22:55:13 <petertodd> (calcualte it honestly anyway)
2022015-12-28T22:56:01 <sipa> petertodd: not true
2032015-12-28T22:56:01 <morcos> ok, that was my original confusion
2042015-12-28T22:56:10 <petertodd> sipa: why not?
2052015-12-28T22:56:40 <sipa> petertodd: with segwit, the code doing the tx selection needs to be able to make coinbase commitments
2062015-12-28T22:57:09 <sipa> petertodd: with your proposal (the eventual one), the code doing coinbase output selection needs to be able to make coinbase commitments
2072015-12-28T22:57:23 <sipa> this is already not the same hardware in some cases now
2082015-12-28T22:57:40 <petertodd> sipa: sure, but I mean the arbitrary nonce version - committing to the coinbae output is *think* optional
2092015-12-28T22:57:41 <morcos> sipa: yes but we're talking about just the H(nonce + prev) version
2102015-12-28T22:57:56 <sipa> who chooses the nonce?
2112015-12-28T22:58:03 <petertodd> sipa: minerdoes
2122015-12-28T22:58:11 <petertodd> sipa: they'll probably all choose 0x00 :)
2132015-12-28T22:58:27 <sipa> you can construct a validationless mining scheme where everyone just agrees on a constant noncr
2142015-12-28T22:58:32 <morcos> there are other ways you could make it unique'ish to the miner if that was important, that doesn't depend on coinbase outputs anyway
2152015-12-28T22:58:32 <sipa> *nonce
2162015-12-28T22:58:52 *** Thireus1 has quit IRC
2172015-12-28T22:58:59 <petertodd> sipa: no! because you don't know for sure if the nonce the previous miner gave you with their block is actually correct, and they can't commit to it in the block itself
2182015-12-28T22:59:26 <sipa> petertodd: so?
2192015-12-28T22:59:35 <sipa> they can make a deal that they have to
2202015-12-28T22:59:45 <petertodd> sipa: like I say, that gets us back to the status quo, where such arrangements involve trust
2212015-12-28T23:00:13 <petertodd> sipa: I'm certainly not claiming this isa perfect solution, but keeping at least the status quo is important
2222015-12-28T23:00:17 <sipa> does segwit-without-witness-validation not give you just a weaker version of that?
2232015-12-28T23:00:37 <sipa> that also requires trust, but only trust in valid signatures
2242015-12-28T23:00:49 <sipa> rather than trust in fully valid block
2252015-12-28T23:00:59 <petertodd> sipa: which is bloody dangerous given how many SPV nodes there are
2262015-12-28T23:01:39 <petertodd> sipa: note that my *other* proposed solution was that we allow invalid txs to be committed to in blocks, and have miners commit to the subset that were valid n-1 blocks ago, but I figured that was too far out to get any acceptance
2272015-12-28T23:01:46 <sipa> my point is: if they're going to bother not doing full validation, why wouldn't they go all the way
2282015-12-28T23:02:26 <sipa> nowitvalidation gives you a small constant factor bandwidth improvememt
2292015-12-28T23:02:38 <petertodd> sipa: whatdo you mean by "all the way", empty blocks?
2302015-12-28T23:02:46 <sipa> Ah.
2312015-12-28T23:03:02 <sipa> now i see the distinction: it requires giving up fees
2322015-12-28T23:03:06 <petertodd> indeed
2332015-12-28T23:03:47 <petertodd> equally, giving an option to leave out the prev-block posession proof,in exchange for an empty block, is a nice way to make gmaxwell's validationless mining flag actually have some consensus enforced teeth
2342015-12-28T23:04:56 <morcos> yeah i guess i agree it could be a step backwards that if you withold your witness data without one of these fixes, other miners won't have the fee incentive to ignore you, and will be more likely to build on top
2352015-12-28T23:05:13 <petertodd> yup
2362015-12-28T23:05:36 <morcos> thats more compelling to me than the miners won't bother with the witness data
2372015-12-28T23:06:12 <petertodd> well, I'm sure some won't bother... it's a lot of engineering work to do it right
2382015-12-28T23:06:57 <morcos> so couldn't we just do H(cur block wit data + prev block data) or something to make it unique to miner
2392015-12-28T23:07:17 <petertodd> morcos: hmm, actually I think that works
2402015-12-28T23:07:33 <morcos> if someone doesn't give you the witness data, you aren't free to pick your own txs to include in the block
2412015-12-28T23:07:53 <petertodd> morcos: though you'd have to recalculate the commitment every time you change the tx contents of the block, but that's not too expensive - just hashing a few MB of data
2422015-12-28T23:08:07 <petertodd> morcos: makes sense
2432015-12-28T23:08:08 <morcos> you have to do that anyway for your own witness commitment
2442015-12-28T23:08:15 <petertodd> morcos: yup
2452015-12-28T23:09:22 *** tripleslash_a has joined #bitcoin-core-dev
2462015-12-28T23:09:52 <sipa> ... of course, a fraud proof for that requires access to the whole block
2472015-12-28T23:10:13 <petertodd> sipa: that's kinda the point :)
2482015-12-28T23:10:32 <petertodd> sipa: fraud proofs are themselves a dangerous double-edged sword...
2492015-12-28T23:11:15 *** tripleslash_t has quit IRC
2502015-12-28T23:12:30 *** raedah has quit IRC
2512015-12-28T23:14:30 *** Thireus has joined #bitcoin-core-dev
2522015-12-28T23:25:48 <sipa> petertodd: i'm aware that you feel that way
2532015-12-28T23:27:27 <sipa> i'd prefer a mechanism that didn't preclude compact fraud proofs though
2542015-12-28T23:28:15 <petertodd> to use the terminology of banking/fintech, fraud proofs lull you into an ecosystem without strong transaction finality: you never know if there's a fraud proof out there that you're being prevented from learning about via a sybil
2552015-12-28T23:28:57 <petertodd> sipa: note how, if you make the prev-block-data commitment into a tree, allowing for a compact fraud proof, you'd simultaneously make it easy and compact to prove that it was correct!
2562015-12-28T23:30:15 <sipa> petertodd: but what if the alternative to those who would run partial validation node is not more full node, but more centralized api providers?
2572015-12-28T23:30:38 <petertodd> sipa: that said, in that type of scheme, it may be sufficient that the sender of that "proof" can lie about a subset of the tree and get away with it
2582015-12-28T23:31:04 <petertodd> sipa: the alternative isn't that, it's that we scale up bitcoin differently
2592015-12-28T23:31:23 <sipa> petertodd: i think that question may be independent of scale :)
2602015-12-28T23:31:31 *** brg444 has joined #bitcoin-core-dev
2612015-12-28T23:31:51 <sipa> but i understand your concern, and i'm certainly not pushing to get the ecosystem into a fraud proof model now
2622015-12-28T23:31:52 <petertodd> sipa: a 4MB fraud proof isn't all that bad
2632015-12-28T23:32:40 <petertodd> sipa: remember, right now we have ~50GB fraud proofs :)
2642015-12-28T23:32:45 <sipa> aware!
2652015-12-28T23:34:15 <sipa> petertodd: "lull you into an ecosystem without strong transaction finality"... isn't that already the case for bitcoin? you never know that the block you saw may be reorganized away
2662015-12-28T23:34:56 <sipa> the difference is of course that PoW, under certain assumptions about mining strategies and distribution, allows you to compute an upper bound on the chance for that
2672015-12-28T23:35:07 <sipa> and that you can observe long term sybils
2682015-12-28T23:35:22 *** Thireus has quit IRC
2692015-12-28T23:35:32 <sipa> but bitcoin doesn't have the strong transaction finality either as such
2702015-12-28T23:36:09 <petertodd> sipa: bitcoin has very strongly *defined* transaction finality: at a given # of confirmations from a point after which you're sure is in the longest chain, you know exactly what it'dcost to reorganize
2712015-12-28T23:36:19 *** raedah has joined #bitcoin-core-dev
2722015-12-28T23:36:23 <sipa> fair enoigh
2732015-12-28T23:36:24 <petertodd> sipa: fraud proofs aren't like that at all
2742015-12-28T23:36:42 <sipa> nope, for fraud proofs it is just assuming no censorship
2752015-12-28T23:36:43 <petertodd> sipa: especially in an envifronment where we're relying heavily on them
2762015-12-28T23:37:23 <petertodd> not quite, remember a fraud proof can't be made from data that you don't have access too, so the actual mechanism of a fraud proof will always be challenge->response - it's not fraud proofs that matter, but rather *non-fraud* proofs
2772015-12-28T23:37:52 <sipa> ?
2782015-12-28T23:38:40 <sipa> well SNARKs that can encompass the entirety of a block validation would of course solve many things :)
2792015-12-28T23:39:20 <kanzure> once the SNARK scheme is figured out, you can often figure out a way to do the same thing without SNARKs
2802015-12-28T23:42:21 <petertodd> sipa: with SNARKs even treechains is trivial, so... :)
2812015-12-28T23:43:07 <petertodd> sipa: consider the case of a prev-block-possession commitment, proved via merkle tree of H(nonce + <part of prev-block>)
2822015-12-28T23:43:38 <sipa> well, if computing the proof takes a google-size datacenter to produce within 10 minutes, we get a different type of centralization concern
2832015-12-28T23:43:44 <petertodd> sipa: now, if I commit fraud in that tree, meaning one of the leaves isn't valid, I'm obviously not going to give you that leaf - you'd have a handy fraud proof! instead, I'll distribute all but the data required to prove that fraud
2842015-12-28T23:44:17 <petertodd> sipa: now, what'll happen is nodes will notice "hey, how do I know leaf #123 is valid?", and they'll ask they're peers to prove it to them - that's a challenge
2852015-12-28T23:44:34 <sipa> petertodd: a partial node wouldn't accept a block that lacks revealing all its commitments
2862015-12-28T23:44:56 <petertodd> sipa: the peers will response with a *non-fraud/validity proof*, showing that that part of the block is correct
2872015-12-28T23:45:01 <kanzure> wasn't there a proposal about making an explicit commitment(?) to the sum of the values of the outputs
2882015-12-28T23:45:04 <petertodd> sipa: however, at no point is a fraud proof ever going to be generated
2892015-12-28T23:45:23 <petertodd> sipa: right, but in that case, the partial node doesn't even need fraud proofs
2902015-12-28T23:45:28 <sipa> how so?
2912015-12-28T23:46:06 <petertodd> sipa:you just said thhe partial node is validating everything relevant...
2922015-12-28T23:46:14 <sipa> no
2932015-12-28T23:46:17 <petertodd> sipa: IOW, you just said 'full node' and made a typo :)
2942015-12-28T23:46:20 <sipa> i said it is receiving everything relevant
2952015-12-28T23:46:24 <sipa> not validating it
2962015-12-28T23:46:42 <petertodd> sipa: right, in which case it's just a dumb transmitter of information - fraud proofs don't come into it
2972015-12-28T23:47:04 <petertodd> sipa: again, in what scenario would the fraudster ever reveal the data required to prove fraud? I'd argue never
2982015-12-28T23:47:26 <sipa> petertodd: in that scenario, no node will accept its block
2992015-12-28T23:48:06 <petertodd> sipa: ok, but this goes back transitively - a block may be in itself 100% locally valid, but it's invalid because it depends on an invalid block - why would the partial node eversee thatblock?
3002015-12-28T23:48:06 <sipa> because it is failing to reveal commitments
3012015-12-28T23:48:29 <petertodd> but who forces it to revealthe commitments? fraud challenges!
3022015-12-28T23:48:31 <sipa> petertodd: a partial node sees everything; it just doesn't verify everything
3032015-12-28T23:48:43 <petertodd> sipa: that's a contradiction...
3042015-12-28T23:48:52 <petertodd> sipa: what do you think a partial node sees exactly?
3052015-12-28T23:48:59 <sipa> petertodd: all blocks and witnesses
3062015-12-28T23:49:11 <sipa> (in the current model, more things can be added of course)
3072015-12-28T23:49:21 <petertodd> sipa: all blocks from the genesis block?
3082015-12-28T23:49:38 <sipa> down to a block it trusts; that may be the genesis block or not
3092015-12-28T23:49:57 <sipa> same as a full node now verifies down to genesis, or gets a utxo set copied from a trusted place
3102015-12-28T23:50:06 <petertodd> sipa: right, so again, the only time fraud ever comes into it is fraud in a block prior to the one it trusts
3112015-12-28T23:50:24 <sipa> that makes no sense
3122015-12-28T23:50:25 <petertodd> sipa: and again, under what circumstance would the fraudster ever give that partial node the data necessary to prove fraud?
3132015-12-28T23:50:37 <petertodd> sipa: like, come up with a concrete example!
3142015-12-28T23:50:52 <sipa> i said no node accepts without seeing the commitment
3152015-12-28T23:51:03 <sipa> there is no need to prove fraud
3162015-12-28T23:51:07 <sipa> nobody accepts it
3172015-12-28T23:51:53 <petertodd> sipa: ok, so... I think we're in violent agreement :) I'm just saying, there's actually no scenario where fraud proofs themselves make sense - what's actually important is fraud challenges, responded to via local validity proofs
3182015-12-28T23:52:08 <sipa> i disagree
3192015-12-28T23:52:20 <petertodd> ok, so where's the concrete example of a fraud proof?
3202015-12-28T23:52:42 <sipa> for example, you could build a node that maintains only a utxo set for txids whose hash starts with a 0
3212015-12-28T23:52:55 <petertodd> right
3222015-12-28T23:53:14 <sipa> the assumption is that other nodes are either full, or do together validation for all txids whose hash starts with (not 0)
3232015-12-28T23:53:21 <petertodd> right
3242015-12-28T23:53:25 <sipa> and that you're not censored from them
3252015-12-28T23:53:42 <sipa> this partial node would still download full blocks and witnesses
3262015-12-28T23:53:43 <petertodd> sure, so when exactly does the fraud proof get generated?
3272015-12-28T23:54:20 <sipa> and will not accept a block that hash merkle malleability, pow failure, mismatching txids, mismatching witness hashes, ...
3282015-12-28T23:54:41 <petertodd> ok, so lets come up with a concrete example: tx in block n spends an output that doesn't exist
3292015-12-28T23:55:40 <sipa> the witness will be required to contain a reference (for example, height) to the block that created the output, and an index into it the block (transaction number 5 in that block)
3302015-12-28T23:56:06 <petertodd> now, as a miner, why would I give a partial node that data? instead, knowing that'll instantly get turned into a fraud proof, I just don't distribute that part of the block, and instead create block n+1 that spends output in block n from tx A, where tx A simply isn't valid
3312015-12-28T23:56:34 <sipa> nobody will accept n+1 without seeing n
3322015-12-28T23:57:01 <petertodd> ah! but then, why do we need a fraud proof system? you just said no-one will accept n+1 without n, so fraud doesn't come into it
3332015-12-28T23:57:23 <petertodd> again, I'm just not seeing a concrete example where a fraud proof would ever be generated
3342015-12-28T23:57:40 <petertodd> ccccccducvnvnecvrblijvucvhtrgnudfblcnfukdkjt
3352015-12-28T23:57:42 <sipa> the fraud is needed so the partial node can be told its block n spends from an invalid output
3362015-12-28T23:57:45 <petertodd> lol, yubikey
3372015-12-28T23:57:47 <sipa> yeah, i agree with that
3382015-12-28T23:57:51 <petertodd> good thing that's one-time :)
3392015-12-28T23:58:00 <sipa> *fraud proof
3402015-12-28T23:58:04 *** raedah has quit IRC
3412015-12-28T23:58:34 <petertodd> right, and like I say, in an ecosystem with partial nodes, no miner making an invalid block would ever publish the parts of theirblocks that allow fraud to be proven, so the fraud proof itself is irrelevant
3422015-12-28T23:59:03 <sipa> that's like saying full nodes are irrelevant because no miner will produce a block that is invalid
3432015-12-28T23:59:07 <petertodd> it's pointless to do that - better to just setup a bunch of sybil's that prevent to SPV clients that everything is ok
3442015-12-28T23:59:12 <sipa> that's the point obviously
3452015-12-28T23:59:48 <petertodd> if everyone ran full nodes, then yes, that'd be irrelevant, but only on a tautological level :)
3462015-12-28T23:59:58 <sipa> it's the same thing