12016-07-11T00:23:00  *** challisto has quit IRC
  22016-07-11T00:24:12  *** yy has joined #bitcoin-core-dev
  32016-07-11T00:27:03  *** yy has quit IRC
  42016-07-11T00:49:36  *** moli has joined #bitcoin-core-dev
  52016-07-11T00:52:43  *** molz has quit IRC
  62016-07-11T00:56:06  *** molz has joined #bitcoin-core-dev
  72016-07-11T00:57:47  *** belcher has quit IRC
  82016-07-11T00:58:41  *** belcher has joined #bitcoin-core-dev
  92016-07-11T00:58:51  *** moli has quit IRC
 102016-07-11T01:06:11  *** xiangfu has joined #bitcoin-core-dev
 112016-07-11T01:08:04  *** Chris_Stewart_5 has quit IRC
 122016-07-11T01:08:13  <GitHub125> [bitcoin] pstratem closed pull request #7940: [WIP] Fuzzing framework (master...2016-04-20-fuzzing-framework) https://github.com/bitcoin/bitcoin/pull/7940
 132016-07-11T01:08:58  <GitHub119> [bitcoin] pstratem closed pull request #8277: Refactor CBlockHeaderAndShortTxIDs::GetShortID into CTransaction (master...2016-06-26-ctransaction-getshortid) https://github.com/bitcoin/bitcoin/pull/8277
 142016-07-11T01:20:34  *** belcher has quit IRC
 152016-07-11T01:25:46  *** Ylbam has quit IRC
 162016-07-11T01:51:15  *** PRab has joined #bitcoin-core-dev
 172016-07-11T01:56:26  *** rrt has joined #bitcoin-core-dev
 182016-07-11T02:00:30  *** moli has joined #bitcoin-core-dev
 192016-07-11T02:02:34  *** molz has quit IRC
 202016-07-11T02:19:39  *** molz has joined #bitcoin-core-dev
 212016-07-11T02:22:45  *** moli has quit IRC
 222016-07-11T02:40:02  *** moli has joined #bitcoin-core-dev
 232016-07-11T02:41:47  *** molly has joined #bitcoin-core-dev
 242016-07-11T02:42:51  *** molz has quit IRC
 252016-07-11T02:44:06  *** molz has joined #bitcoin-core-dev
 262016-07-11T02:44:33  *** moli has quit IRC
 272016-07-11T02:46:57  *** molly has quit IRC
 282016-07-11T02:56:53  *** moli has joined #bitcoin-core-dev
 292016-07-11T02:59:33  *** molz has quit IRC
 302016-07-11T03:15:36  *** Justinus has quit IRC
 312016-07-11T03:27:20  *** Sosumi has quit IRC
 322016-07-11T03:35:46  *** cryptapus_ has joined #bitcoin-core-dev
 332016-07-11T03:35:46  *** cryptapus_ has joined #bitcoin-core-dev
 342016-07-11T03:42:45  *** JackH has quit IRC
 352016-07-11T04:02:17  *** Alopex has quit IRC
 362016-07-11T04:03:22  *** Alopex has joined #bitcoin-core-dev
 372016-07-11T04:50:11  *** Alopex has quit IRC
 382016-07-11T04:51:16  *** Alopex has joined #bitcoin-core-dev
 392016-07-11T05:06:26  *** Alopex has quit IRC
 402016-07-11T05:07:32  *** Alopex has joined #bitcoin-core-dev
 412016-07-11T05:31:43  *** molz has joined #bitcoin-core-dev
 422016-07-11T05:32:11  *** moli has quit IRC
 432016-07-11T05:33:58  *** cryptapus_ has quit IRC
 442016-07-11T05:56:05  *** paveljanik has quit IRC
 452016-07-11T05:57:15  *** GreenIsMyPepper has quit IRC
 462016-07-11T05:59:35  *** GreenIsMyPepper has joined #bitcoin-core-dev
 472016-07-11T06:07:11  *** Alopex has quit IRC
 482016-07-11T06:08:16  *** Alopex has joined #bitcoin-core-dev
 492016-07-11T06:20:13  *** GreenIsMyPepper has quit IRC
 502016-07-11T06:22:11  *** GreenIsMyPepper has joined #bitcoin-core-dev
 512016-07-11T07:07:48  *** MarcoFalke has left #bitcoin-core-dev
 522016-07-11T07:11:21  *** GreenIsMyPepper has quit IRC
 532016-07-11T07:13:12  *** GreenIsMyPepper has joined #bitcoin-core-dev
 542016-07-11T07:17:25  *** GreenIsMyPepper has quit IRC
 552016-07-11T07:19:42  *** GreenIsMyPepper has joined #bitcoin-core-dev
 562016-07-11T07:31:52  *** Ylbam has joined #bitcoin-core-dev
 572016-07-11T07:32:35  *** GreenIsMyPepper has quit IRC
 582016-07-11T07:34:44  *** GreenIsMyPepper has joined #bitcoin-core-dev
 592016-07-11T08:03:05  *** Guyver2 has joined #bitcoin-core-dev
 602016-07-11T08:03:36  *** jannes has joined #bitcoin-core-dev
 612016-07-11T08:05:43  *** fengling has joined #bitcoin-core-dev
 622016-07-11T08:12:57  *** assder has joined #bitcoin-core-dev
 632016-07-11T08:19:25  *** JackH has joined #bitcoin-core-dev
 642016-07-11T08:29:53  *** gabridome has quit IRC
 652016-07-11T08:37:02  *** arubi has quit IRC
 662016-07-11T08:41:09  *** arubi has joined #bitcoin-core-dev
 672016-07-11T09:03:24  <GitHub82> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67caef673089...26316ffa7dc5
 682016-07-11T09:03:24  <GitHub82> bitcoin/master 1ba3db6 Christian von Roques: bash-completion: Adapt for 0.12 and 0.13...
 692016-07-11T09:03:25  <GitHub82> bitcoin/master 26316ff Wladimir J. van der Laan: Merge #8289: bash-completion: Adapt for 0.12 and 0.13...
 702016-07-11T09:03:34  <GitHub140> [bitcoin] laanwj closed pull request #8289: bash-completion: Adapt for 0.12 and 0.13 (master...completion) https://github.com/bitcoin/bitcoin/pull/8289
 712016-07-11T09:10:50  <assder> When is the first release candidate for 0.13 expected?
 722016-07-11T09:13:49  <gmaxwell> "Soon"
 732016-07-11T09:22:29  *** Guyver2 has quit IRC
 742016-07-11T09:52:01  *** moli has joined #bitcoin-core-dev
 752016-07-11T09:53:40  <GitHub143> [bitcoin] laanwj pushed 3 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/080457c4ee97...5c8438207661
 762016-07-11T09:53:40  <GitHub78> [bitcoin] laanwj closed pull request #8318: [0.12] Backport "Rename OP_NOP3 to OP_CHECKSEQUENCEVERIFY #7540" (0.12...rename_nop3_0.12) https://github.com/bitcoin/bitcoin/pull/8318
 772016-07-11T09:53:41  <GitHub143> bitcoin/0.12 ac5577b BtcDrak: Rename OP_NOP3 to OP_CHECKSEQUENCEVERIFY
 782016-07-11T09:53:41  <GitHub143> bitcoin/0.12 c4e5688 BtcDrak: Rename NOP3 to CHECSEQUENCEVERIFY in rpc tests
 792016-07-11T09:53:42  <GitHub143> bitcoin/0.12 5c84382 Wladimir J. van der Laan: Merge #8318: [0.12] Backport "Rename OP_NOP3 to OP_CHECKSEQUENCEVERIFY #7540"...
 802016-07-11T09:54:18  *** molz has quit IRC
 812016-07-11T09:54:43  *** kadoban has quit IRC
 822016-07-11T10:06:27  *** kekstone has left #bitcoin-core-dev
 832016-07-11T10:09:49  *** YOU-JI has joined #bitcoin-core-dev
 842016-07-11T10:12:24  *** MarcoFalke has joined #bitcoin-core-dev
 852016-07-11T10:14:55  *** MarcoFalke has left #bitcoin-core-dev
 862016-07-11T10:16:45  *** rrt has quit IRC
 872016-07-11T10:20:51  *** mkarrer has joined #bitcoin-core-dev
 882016-07-11T10:29:25  <GitHub157> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/5c8438207661...1233cb42dde9
 892016-07-11T10:29:25  <GitHub157> bitcoin/0.12 fe98533 Jonas Schnelli: [Qt] Disable some menu items during splashscreen/verification state...
 902016-07-11T10:29:25  <GitHub27> [bitcoin] laanwj closed pull request #8302: 0.12.2: [Qt] Disable some menu items during splashscreen/verification state (0.12...Mf1607-012qtDebugSplash) https://github.com/bitcoin/bitcoin/pull/8302
 912016-07-11T10:29:26  <GitHub157> bitcoin/0.12 1233cb4 Wladimir J. van der Laan: Merge #8302: 0.12.2: [Qt] Disable some menu items during splashscreen/verification state...
 922016-07-11T10:43:31  *** laurentmt has joined #bitcoin-core-dev
 932016-07-11T10:44:16  *** laurentmt has quit IRC
 942016-07-11T10:51:35  <GitHub118> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/26316ffa7dc5...304eff3c614a
 952016-07-11T10:51:35  <GitHub118> bitcoin/master 477777f MarcoFalke: [rpcwallet] Don't use floating point
 962016-07-11T10:51:36  <GitHub118> bitcoin/master 304eff3 Wladimir J. van der Laan: Merge #8317: [rpcwallet] Don't use floating point...
 972016-07-11T10:51:45  <GitHub31> [bitcoin] laanwj closed pull request #8317: [rpcwallet] Don't use floating point (master...Mf1607-rpcFloat) https://github.com/bitcoin/bitcoin/pull/8317
 982016-07-11T11:12:49  *** MarcoFalke has joined #bitcoin-core-dev
 992016-07-11T11:25:07  *** jtimon has joined #bitcoin-core-dev
1002016-07-11T11:40:29  *** arubi has quit IRC
1012016-07-11T11:41:52  *** arubi has joined #bitcoin-core-dev
1022016-07-11T11:54:57  *** arubi has quit IRC
1032016-07-11T11:55:28  *** arubi has joined #bitcoin-core-dev
1042016-07-11T11:58:45  <MarcoFalke> Who guessed it
1052016-07-11T11:58:54  <sipa> ?
1062016-07-11T11:58:56  <MarcoFalke> Of course windows test are timing out, ow
1072016-07-11T11:59:41  <MarcoFalke> I am not sure why they don't work in parallel "out of the box"
1082016-07-11T11:59:57  <MarcoFalke> Maybe wine can't handle it?
1092016-07-11T12:00:00  <sipa> reduce their parallelism?
1102016-07-11T12:00:49  *** laurentmt has joined #bitcoin-core-dev
1112016-07-11T12:01:40  <MarcoFalke> There is already an overhead of about 2 for just using wine. Then, disabling parallel is another slowdown by 4.
1122016-07-11T12:01:51  <MarcoFalke> So about 8 times longer rpc test for windows
1132016-07-11T12:01:57  <sipa> fun.
1142016-07-11T12:02:18  *** laurentmt has quit IRC
1152016-07-11T12:06:25  <luke-jr> what? why would WINE have any overhead?
1162016-07-11T12:23:11  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1172016-07-11T12:25:43  *** MarcoFalke has quit IRC
1182016-07-11T13:06:53  *** MarcoFalke has joined #bitcoin-core-dev
1192016-07-11T13:10:06  <wumpus> luke-jr: that's not really clear, I'd expect an overhead at startup/shutdown due to setting up the 'virtual windows environment', but not on networking
1202016-07-11T13:10:59  *** harrymm has quit IRC
1212016-07-11T13:12:03  <GitHub175> [bitcoin] jtimon opened pull request #8328: Consensus: Rename: Move consensus code to the consensus directory (master...0.12.99-consensus-rename) https://github.com/bitcoin/bitcoin/pull/8328
1222016-07-11T13:14:37  <jtimon> ping kanzure ^^
1232016-07-11T13:15:01  <jtimon> quite trivial to review, just touches the makefile and a bunch of includes
1242016-07-11T13:16:01  <kanzure> thanks for the ping
1252016-07-11T13:16:19  <jtimon> no problem, thanks for asking for it
1262016-07-11T13:19:44  *** harrymm has joined #bitcoin-core-dev
1272016-07-11T13:25:41  *** Chris_Stewart_5 has quit IRC
1282016-07-11T13:27:32  *** YOU-JI has quit IRC
1292016-07-11T13:30:57  *** harrymm has quit IRC
1302016-07-11T13:31:26  *** harrymm has joined #bitcoin-core-dev
1312016-07-11T13:33:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1322016-07-11T13:34:55  *** laurentmt has joined #bitcoin-core-dev
1332016-07-11T13:35:28  *** laurentmt has quit IRC
1342016-07-11T13:36:49  *** MarcoFalke has left #bitcoin-core-dev
1352016-07-11T13:41:09  *** assder has quit IRC
1362016-07-11T13:42:24  <jtimon> sipa: what's the advantage of validating this https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3558 in ContextualCheckBlock() instead of ConnectBlock() ?
1372016-07-11T13:42:59  <jtimon> and the same question kind of applies to the other 2 consensus checks in there
1382016-07-11T13:43:43  <jtimon> in other words would it be crazy to move all those checks to just connectblock? why?
1392016-07-11T13:45:11  <jtimon> or in other words, is it necessary or advantageous to call ContextualCheckBlock() in other places other than ConnectBlock() in some way I'm missing?
1402016-07-11T13:45:26  <jtimon> answers from anyone welcomed
1412016-07-11T13:46:58  *** GreenIsMyPepper has quit IRC
1422016-07-11T13:48:11  <sipa> jtimon: contextualcheckblock runs before storing a block on disk, connectblock after
1432016-07-11T13:48:44  *** molz has joined #bitcoin-core-dev
1442016-07-11T13:48:45  <sipa> so everything that can be in contextualcheckblock should be, as it make attacks that cause disk space wasting harder
1452016-07-11T13:48:45  *** GreenIsMyPepper has joined #bitcoin-core-dev
1462016-07-11T13:49:08  <jtimon> I see, so the advantage is to discard offending blocks before storing them on disk for checks that are relatively cheap
1472016-07-11T13:49:29  <jtimon> I didn't knew we stored invalid blocks at all
1482016-07-11T13:49:48  <jtimon> why do we store invalid blocks?
1492016-07-11T13:50:58  *** moli has quit IRC
1502016-07-11T13:51:06  <sipa> because we can't know until we reorg the chainstate
1512016-07-11T13:51:27  <sipa> we may accept a block on a side branch that does not overtake the best chai  yet
1522016-07-11T13:51:32  <sipa> *chain
1532016-07-11T13:51:55  <jtimon> but it's still valid, no?
1542016-07-11T13:52:09  <sipa> we can't know that without reorg
1552016-07-11T13:52:21  <sipa> because we need the utxo set for its parent
1562016-07-11T13:52:28  <jtimon> we can know whether a block is valid in its chain without knowing whether it belongs to the "longest" chain or not, right?
1572016-07-11T13:52:38  <sipa> in theory, yes
1582016-07-11T13:52:43  <sipa> in practice, no
1592016-07-11T13:52:55  <sipa> because we don't have its utxoset we can't validate
1602016-07-11T13:53:19  <jtimon> oh, I see, we never build incompatible utxo histories
1612016-07-11T13:53:38  <sipa> right, we just have a single utxo set for the tip
1622016-07-11T13:54:04  <sipa> and delay full validation until we're forced to switch tips
1632016-07-11T13:54:15  <jtimon> I thought that was part of the CCoinsViewCache purpose...
1642016-07-11T13:55:14  <jtimon> but I guess yeah, it doesn't make sense to fully validate until you're forced to reorg by the accumulated pow, storing that block is cheaper I guess
1652016-07-11T13:55:18  <sipa> no, that's just so we don't have to write everything to disk immediately
1662016-07-11T13:55:42  <sipa> now, pow is the most expensive thing for an attacker
1672016-07-11T13:56:03  <sipa> so everything that comes after pow validation and corruption checks does not matter very much
1682016-07-11T13:56:09  <sipa> why are you asking, btw?
1692016-07-11T13:56:17  <sipa> ah, i know
1702016-07-11T13:56:27  <sipa> iswitnessenabled depends on versionbits
1712016-07-11T13:56:38  <jtimon> mhmm, why do we validate any part of a block that we don't see as belonging to the longest chain at all?
1722016-07-11T13:57:28  <sipa> because we at least need to know whether it is actually the right block
1732016-07-11T13:57:42  <sipa> a peer could change one transaction before relay
1742016-07-11T13:57:43  <jtimon> sipa: it was part of my latest consensus refactor branch to get rid of ContextualCheckBlock()
1752016-07-11T13:58:06  <sipa> and in that case we must punish the peer, but not mark the block as invalid
1762016-07-11T13:58:32  <sipa> so an invariant is that all blocks on disk are known to actually match the blocks whose headers we know
1772016-07-11T13:59:42  <jtimon> if we know it's not making a longer chain, why bother validating BIP113 ?
1782016-07-11T14:00:15  <sipa> validating bip113 is not necessary i think
1792016-07-11T14:00:30  <sipa> but the segwit commitment check is
1802016-07-11T14:01:10  <sipa> before storing on disk
1812016-07-11T14:01:25  *** Chris_Stewart_5 has quit IRC
1822016-07-11T14:02:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1832016-07-11T14:03:42  <jtimon> that's useful, what about the bip34 check in ContextualCheckBlock(), can it be moved out?
1842016-07-11T14:04:02  <sipa> i believe so
1852016-07-11T14:04:12  <jtimon> ok, thanks
1862016-07-11T14:04:31  <jtimon> but not the new segwit one, fine
1872016-07-11T14:06:38  <jtimon> well, I would prefer to pass the consensus validation flags instead of calling IsWitnessEnabled() from there
1882016-07-11T14:08:41  <jtimon> but I should try to write that first before discussing it further
1892016-07-11T14:11:56  *** Sosumi has joined #bitcoin-core-dev
1902016-07-11T14:32:02  *** Chris_Stewart_5 has quit IRC
1912016-07-11T14:32:18  *** achow101 has quit IRC
1922016-07-11T14:36:07  *** laurentmt has joined #bitcoin-core-dev
1932016-07-11T14:37:01  *** laurentmt has quit IRC
1942016-07-11T14:42:11  *** Giszmo has joined #bitcoin-core-dev
1952016-07-11T14:46:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1962016-07-11T15:24:17  <sdaftuar> reviewers, please review some open PRs for 0.13.0: #8295, #8305, #8312
1972016-07-11T15:38:18  *** harrymm has quit IRC
1982016-07-11T15:38:40  *** harrymm has joined #bitcoin-core-dev
1992016-07-11T15:42:08  *** harrymm has quit IRC
2002016-07-11T15:42:34  *** harrymm has joined #bitcoin-core-dev
2012016-07-11T15:43:01  *** bsm117532 has quit IRC
2022016-07-11T15:43:36  *** bsm117532 has joined #bitcoin-core-dev
2032016-07-11T15:44:14  *** bsm117532 has quit IRC
2042016-07-11T15:44:43  *** bsm117532 has joined #bitcoin-core-dev
2052016-07-11T15:45:35  *** harrymm has quit IRC
2062016-07-11T15:45:45  *** Chris_Stewart_5 has quit IRC
2072016-07-11T15:46:23  *** achow101 has joined #bitcoin-core-dev
2082016-07-11T16:04:22  *** a87ry5 has joined #bitcoin-core-dev
2092016-07-11T16:07:22  *** GreenIsMyPepper has quit IRC
2102016-07-11T16:12:19  *** a87ry5 has quit IRC
2112016-07-11T16:13:41  *** spudowiar has joined #bitcoin-core-dev
2122016-07-11T16:16:33  *** harrymm has joined #bitcoin-core-dev
2132016-07-11T16:17:57  *** GreenIsMyPepper has joined #bitcoin-core-dev
2142016-07-11T16:34:25  *** BTCking has joined #bitcoin-core-dev
2152016-07-11T16:34:26  <BTCking> AMAZING! My bitcoin-grower is now ready. Send me some bitcoin (1btc, 2btc, etc.) and get MUCH more back INSTANTLY. This uses Block-chain explanding technology! Proven safe & secure. You cannot lose. PM me to begin!!
2162016-07-11T16:35:34  <sipa> BTCking: fuck off
2172016-07-11T16:35:49  * BTCking slaps sipa around a bit with a large trout
2182016-07-11T16:35:49  <BTCking> AMAZING! My bitcoin-grower is now ready. Send me some bitcoin (1btc, 2btc, etc.) and get MUCH more back INSTANTLY. This uses Block-chain explanding technology! Proven safe & secure. You cannot lose. PM me to begin!!
2192016-07-11T16:36:46  *** sipa has quit IRC
2202016-07-11T16:36:46  *** sipa has joined #bitcoin-core-dev
2212016-07-11T16:36:56  *** ChanServ sets mode: +o sipa
2222016-07-11T16:37:02  *** sipa sets mode: +b *!*wowperson@*.hsd1.wa.comcast.net
2232016-07-11T16:37:02  *** BTCking was kicked by sipa (BTCking)
2242016-07-11T16:37:35  *** LeMiner2 has joined #bitcoin-core-dev
2252016-07-11T16:39:16  *** LeMiner has quit IRC
2262016-07-11T16:39:16  *** LeMiner2 is now known as LeMiner
2272016-07-11T16:47:08  <GitHub65> [bitcoin] jtimon opened pull request #8329: Consensus: MOVEONLY: Move functions for tx verification (master...0.12.99-consensus-moveonly-tx) https://github.com/bitcoin/bitcoin/pull/8329
2282016-07-11T16:49:04  <jtimon> kanzure: ping again, still quite simple to review and re-write
2292016-07-11T17:04:56  *** dgenr8 has quit IRC
2302016-07-11T17:09:00  *** dgenr8 has joined #bitcoin-core-dev
2312016-07-11T17:10:27  *** spudowiar has quit IRC
2322016-07-11T17:13:40  *** Giszmo has quit IRC
2332016-07-11T17:14:51  *** Giszmo has joined #bitcoin-core-dev
2342016-07-11T17:16:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2352016-07-11T17:28:04  *** Chris_Stewart_5 has quit IRC
2362016-07-11T17:30:56  *** droark has joined #bitcoin-core-dev
2372016-07-11T17:35:25  *** BCBot has quit IRC
2382016-07-11T17:35:42  *** BCBot has joined #bitcoin-core-dev
2392016-07-11T17:38:34  *** molz has quit IRC
2402016-07-11T17:39:03  *** moli has joined #bitcoin-core-dev
2412016-07-11T17:46:05  *** BCBot2 has joined #bitcoin-core-dev
2422016-07-11T17:46:22  *** BCBot2 has quit IRC
2432016-07-11T17:48:19  *** BCBot2 has joined #bitcoin-core-dev
2442016-07-11T17:50:02  *** BCBot2 has joined #bitcoin-core-dev
2452016-07-11T17:51:52  *** BCBot2 has quit IRC
2462016-07-11T17:52:31  *** BCBot2 has joined #bitcoin-core-dev
2472016-07-11T17:55:25  *** BCBot2 has joined #bitcoin-core-dev
2482016-07-11T17:57:27  *** BCBot2 has joined #bitcoin-core-dev
2492016-07-11T17:57:57  *** BCBot2 has quit IRC
2502016-07-11T18:00:26  *** BCBot2 has joined #bitcoin-core-dev
2512016-07-11T18:03:52  *** mkarrer has quit IRC
2522016-07-11T18:10:13  *** kadoban has joined #bitcoin-core-dev
2532016-07-11T18:10:31  <sipa> sdaftuar: done
2542016-07-11T18:10:35  *** sipa sets mode: -o sipa
2552016-07-11T18:10:40  <sdaftuar> sipa: thanks!
2562016-07-11T18:13:45  <sipa> github.com down?
2572016-07-11T18:15:01  <eragmus> sipa: http://www.isup.me/github.com
2582016-07-11T18:15:39  <eragmus> http://isitdownorjust.me/github-com/
2592016-07-11T18:16:03  <sipa> thanks
2602016-07-11T18:16:07  <sipa> it also works from my vps...
2612016-07-11T18:16:41  <tadasv> working fine for me
2622016-07-11T18:19:26  *** mkarrer has joined #bitcoin-core-dev
2632016-07-11T18:19:54  *** spudowiar has joined #bitcoin-core-dev
2642016-07-11T18:33:29  <gmaxwell> sdaftuar: maybe it doesn't matter because its a corner case, but #8305 makes it look like it will effectively discard the dangling header-- it pushmessages a getheaders and returns, without AcceptBlockHeader or UpdateBlockAvailability.
2652016-07-11T18:33:51  <sdaftuar> oh, UpdateBlocKAvailability, hmm
2662016-07-11T18:34:23  *** Guyver2 has joined #bitcoin-core-dev
2672016-07-11T18:34:38  <gmaxwell> Is the expectation that it'll come back in via the getheaders, and that the remote end won't do anything smart like not send it because it already did?  (I guess thats reasonable?) though the lack of updateavailablity probably means we'll send a redundant announcement in that direction.
2682016-07-11T18:35:01  <sdaftuar> well there's no way to avoid getting the headers message back to you
2692016-07-11T18:35:16  <sdaftuar> if you set hashstop equal to the hash of that header, it'll still appear in the response
2702016-07-11T18:35:40  <sdaftuar> i don't think the remote end is allowed to not re-send, though i suppose lack of a spec makes this a difficult statement to concretely make
2712016-07-11T18:35:59  <sdaftuar> but we expect the contents of a headers message to be a linear connecting chain
2722016-07-11T18:36:14  <gmaxwell> K. That makes sense, I thought that was the assumption but wanted to be sure (I think it's correct.)
2732016-07-11T18:37:37  <sdaftuar> i guess there could be an advantage to setting hashLastUnknownBlock if a header doesn't connect... that would mean that if a different peer supplied the missing headers, we could download the block from the peer who made the announcement
2742016-07-11T18:37:51  <sdaftuar> but that would only matter if the peer didn't respond to the getheaders being pushed in this patch
2752016-07-11T18:38:05  <gmaxwell> so now let me ask, if I send you a header that doesn't connect because of timestamp stupidity. And I'm your only peer. If there are two blocks in a row during the time when the prior header will be rejected... When will it start connecting again?  I'll get the flag false on me, then it'll never be sent to true, since all further headers I send will also not connect.
2762016-07-11T18:38:07  <sdaftuar> which is a weird corner case
2772016-07-11T18:38:38  <gmaxwell> On the update front, I was mostly think in terms of not sending surpflous compact block messages.
2782016-07-11T18:38:56  <sdaftuar> when you respond to the getheaders, the bit is cleared
2792016-07-11T18:39:29  <midnightmagic> ;;isitdown github.com
2802016-07-11T18:39:30  <gribble> github.com is up
2812016-07-11T18:40:05  <sdaftuar> and the headers will start connecting again
2822016-07-11T18:40:08  <sdaftuar> well,
2832016-07-11T18:40:11  <sdaftuar> unless the time stamp is still broken
2842016-07-11T18:40:30  *** xinxi has joined #bitcoin-core-dev
2852016-07-11T18:40:44  <gmaxwell> hm. I was thinking that it wouldn't be set to true if the getheaders reply also didn't connect due to bad timestamps.
2862016-07-11T18:41:26  <xinxi> Hi guys
2872016-07-11T18:41:42  <xinxi> Anybody here?
2882016-07-11T18:42:11  <sdaftuar> gmaxwell: yeah, i can't solve the problem of a bunch of blocks in a row all being invalid to one peer but not another
2892016-07-11T18:42:22  <sdaftuar> but typically, the first block is too far ahead
2902016-07-11T18:42:36  <sdaftuar> and then by the time the next block comes in, you would be able to accept both
2912016-07-11T18:42:46  <sdaftuar> if you'd be willing to try
2922016-07-11T18:42:50  <sdaftuar> but we have no "try" mechanism currently
2932016-07-11T18:43:39  <sdaftuar> i guess the question is, what should we do if a peer is relaying many blocks in a row that are all actually too far in the future?
2942016-07-11T18:43:52  <sdaftuar> i just fall back to the current behavior of failing/disconnecting
2952016-07-11T18:45:09  <sdaftuar> i did briefly think about whether it would be feasible to somehow accept headers that are too far in the future, but i'm pretty sure that's a major rewrite to our consensus logic
2962016-07-11T18:45:27  <sdaftuar> (accept them, so that you could re-try them later)
2972016-07-11T18:50:15  <sdaftuar> gmaxwell: perhaps we could always send a getheaders if the peer is whitelisted?
2982016-07-11T18:51:52  *** spudowiar has quit IRC
2992016-07-11T18:52:32  <gmaxwell> I don't think that would be an awful thing, but I don't think it addresses the concern-- you shouldn't only fail to fail if you have whitelisted peers.
3002016-07-11T18:53:25  <sdaftuar> i guess i could do the thing you imply -- actually just check to see if the headers connect, and use that to re-set the bit
3012016-07-11T18:55:03  <gmaxwell> maybe I'm misunderstanding, but that situation I'm thinking about is if you're slow on time by a few seconds, rejected a block, then the next comes in, and it still doesn't connect... you're going to stop sending getheaders after that. Then no others will connect from that peer.  The time is a bit freaky, since it's a temporary failure.
3022016-07-11T18:55:33  <sdaftuar> yes, i agree your example is a correct one
3032016-07-11T18:55:53  <sdaftuar> i'm just trying to distinguish that from an example where an attacker sends you a chain that's far into the future
3042016-07-11T18:56:59  <gmaxwell> I think we award a little bit of misbehaving there. Ironically, for sync purposes it might be better to immediately disconnect: at least that will clear the flag! :)
3052016-07-11T18:58:34  <gmaxwell> relying on DOS disconnect to make progress is weird though, but I think thats the answer here: after some number non-connecting blocks I think you'll disconnect the peer.  When you reconnect, the flag will be true and you'll try to sync again.
3062016-07-11T18:59:37  <gmaxwell> sdaftuar: to prevent looping, why not store the most recent ID. And don't getheader again if it's the same?
3072016-07-11T19:00:09  <gmaxwell> e.g. block announce, doesn't connect, store the most recent ID and getheader. Get headers, still doesn't connect and most recent ID is the same. Stop.
3082016-07-11T19:00:39  <sdaftuar> sorry, what is most recent ID?
3092016-07-11T19:01:20  <gmaxwell> when the headers response comes in take the ID (hash) of the latest block in the reply. And do not keep requesting headers when that value hasn't changed for this peer.
3102016-07-11T19:02:05  <gmaxwell> I announce X, X doesn't connect. Remember X, request headers.  Headers come in, they tell you a bunch of junk ending at X. Still doesn't connect. Stop.
3112016-07-11T19:02:38  <sdaftuar> gmaxwell: i guess i just worry about assuming too much about the broken implementations out there
3122016-07-11T19:02:53  *** xinxi has quit IRC
3132016-07-11T19:02:54  <sdaftuar> eg maybe the peer who was sending me 160kb of junk was sending me random junk
3142016-07-11T19:04:06  <gmaxwell> Well thats what misbehaving is for.
3152016-07-11T19:04:07  *** xinxi has joined #bitcoin-core-dev
3162016-07-11T19:04:33  <sdaftuar> but in your example, wouldn't that behavior result in infinite loop?
3172016-07-11T19:05:04  <gmaxwell> The headers reply would end with the block X, which we already had remembered, so we would stop there.
3182016-07-11T19:05:21  <gmaxwell> no loop. then they later announce block y, and we'd getheaders again. and hopefully connect.
3192016-07-11T19:05:32  <gmaxwell> So basically  one headers retry per novel header they send.
3202016-07-11T19:05:45  <sdaftuar> i'm specifically referring to peers that are totally broken and on initial getheaders sync, they send us 2000 headers that don't connect
3212016-07-11T19:06:39  <sdaftuar> i don't want to assume too much about how that peer is doing that
3222016-07-11T19:06:51  <gmaxwell> sure, whatever, testnet node on mainnet or whatnot.
3232016-07-11T19:06:58  <sdaftuar> if getting it wrong means 160kb over and over again...
3242016-07-11T19:07:32  <gmaxwell> just don't assume it's malicious, since there are better ways to waste our bandwidth for malicious peers.
3252016-07-11T19:08:14  <sdaftuar> well you're suggesting we assume it's deterministic i think.  which is hopefully true, but if it's not, then sadness
3262016-07-11T19:08:45  <gmaxwell> yes, indeed, and actually the 2000 limit gets in the way too.
3272016-07-11T19:09:15  <sdaftuar> i mean, i think in practice your suggestion probably works, i was just hoping for something more robust to accidental disaster
3282016-07-11T19:10:24  <gmaxwell> speaking of 2000, I'm not seeing how what you suggest doesn't actually break sync.
3292016-07-11T19:10:36  <sipa> can i get a summary of the problem?
3302016-07-11T19:11:19  <gmaxwell> oh nevermind last comment, I was mistaking the order.
3312016-07-11T19:11:31  <sdaftuar> sipa: i noticed on testnet that i had a node that would fall out of sync, because its one peer would occasionally send a block header (using headers announcements) that was too far in the future
3322016-07-11T19:11:39  <gmaxwell> (I was thinking that we'd request headers, if there was more than 2000 missing, that they sent the later headers first)
3332016-07-11T19:11:45  <sdaftuar> so the peer thought the header was valid, but the local node would reject
3342016-07-11T19:11:56  <sdaftuar> this is a case i had never thought of when working on the headers announcements stuff
3352016-07-11T19:12:21  <sdaftuar> since the announcing peer doesn't realize the recipient rejects the header, they continue to announce blocks on top of the header
3362016-07-11T19:12:35  <sipa> sdaftuar: yes, i get that
3372016-07-11T19:12:43  <sipa> but you have a patch for that
3382016-07-11T19:12:43  <sdaftuar> resulting in headers announcements that don't connect for the recipient, and then eventually disconnect
3392016-07-11T19:13:06  <xinxi> hey guys, I want to make Bitcoin provably correct.
3402016-07-11T19:13:08  <sdaftuar> oh right.  so gmaxwell wonders if we can avoid failure in the case where two blocks come in quickly, where the first block is still invalid when the second one is announced
3412016-07-11T19:13:17  <sdaftuar> my patch doesn't address that
3422016-07-11T19:13:19  <xinxi> I am serious.
3432016-07-11T19:13:31  <sipa> xinxi: you'll need to be a bit more specific
3442016-07-11T19:13:56  <sipa> what part do you want to prove?
3452016-07-11T19:14:02  <gmaxwell> sipa: and sdaftuar is concerned that relaxations will leave it in a state where its constantly requesting headers over and over again.
3462016-07-11T19:14:17  <xinxi> sipa: thank you for your attention. Yeah, basically, I think bugs are still in the C++ implementation. And I want to make sure it's absolutely correct.
3472016-07-11T19:14:27  <xinxi> so there will be no bugs.
3482016-07-11T19:14:44  <sipa> xinxi: that implies you have a specification for correct to compare to
3492016-07-11T19:14:46  <gmaxwell> I think this could be addressed by just adding a small amount of DOS each time.
3502016-07-11T19:15:09  <gmaxwell> Correct with respect to a specification may well be meaningless if the specification is not "correct" in a broader sense.
3512016-07-11T19:15:22  <xinxi> sipa: yeah, I want to work out a formal specification as well.
3522016-07-11T19:15:26  <sipa> xinxi: for the consensus logic, the code implementation is the specification, so it is by definition correct
3532016-07-11T19:15:37  <xinxi> something like mathematical theorems about the code.
3542016-07-11T19:15:55  <sipa> xinxi: however, being able to verify that the behaviour of that code does not change between releases would be incredibly valuable
3552016-07-11T19:16:37  <sipa> unfortunately, due to historical reasons mostly, the consensus code is not well separated from the rest
3562016-07-11T19:16:39  <gmaxwell> sdaftuar: e.g. I think we could just trigger a getheaders on any header message with only a single header in it that doesn't connect, and add a small dos penalty.
3572016-07-11T19:16:43  <xinxi> sipa: I understand what you mean. The code, as a specification, may not be consistent with itself.
3582016-07-11T19:16:52  <gmaxwell> sdaftuar: then every new block that shows up on the network will cause us to retry to connect.
3592016-07-11T19:16:54  <morcos> i know this sounds kind of janky, but it seems to me that a lot of this sync logic is stuff that to a human is kind of obviously stupid.  i wonder if putting in a bit of belt and suspender check on things getting stuck might make sense.
3602016-07-11T19:17:25  <sipa> xinxi: indeed. not consistent with itself, or not consistent with other implementations/versions
3612016-07-11T19:17:28  <gmaxwell> sdaftuar: and eventually it will either connect, or disconnect the peer.
3622016-07-11T19:17:43  <xinxi> sipa: also, you may not want to treat bugs as part of the specification like the heartbleed bug in OpenSSL should not be part of OpenSSL.
3632016-07-11T19:17:56  <sipa> xinxi: we have to
3642016-07-11T19:17:57  <btcdrak> xinxi: there is a slow and arduous process of extracting the consensus code into a separate library which will make things a lot easier in the long run.
3652016-07-11T19:18:11  <morcos> for instance very 60 secs you clear out some state such as fLastHeadersConnected and perhaps nSyncStarted (maybe only if we're not actively receiving headers)
3662016-07-11T19:18:19  <morcos> i'm sure we can imagine other things that kind of get stuck
3672016-07-11T19:18:24  <xinxi> btcdrak: I've heard of that. It's libconsensus, isn't it?
3682016-07-11T19:18:27  <gmaxwell> morcos: you mean like a periodic, pick a random peer and restart our efforts to sync with it? and loudly logging that the sync state machine has failed if that accomplishes anything?
3692016-07-11T19:18:37  <sipa> xinxi: even if we would write down a specification for the behaviour, and every one would agree that that spec is indeed the behaviour we want
3702016-07-11T19:18:54  <sipa> xinxi: what if we then find a bug, and the code does something slightly different?
3712016-07-11T19:18:55  <sdaftuar> gmaxwell: i think that sounds pretty good, though the DoS score should decay back down once headers that do connect are received, right?  otherwise, over a long enough period of time, you eventually disconnect your peer
3722016-07-11T19:19:12  <morcos> gmaxwell: yes something along those lines, i like the idea of loudly announcing it so we try to make stuff work in general, but that next time we miss something, hopefully it kind of autorecovers (like power cycling)
3732016-07-11T19:19:13  <btcdrak> xinxi: the problem is it's quite disruptive to the codebase and causes everyone's pull-requests to need rebasing so it tends to get done slowly and in bursts. yes it's called libconsensus
3742016-07-11T19:19:23  <gmaxwell> sdaftuar: yea, :( the whole dos score thing is kinda lame.
3752016-07-11T19:19:25  <xinxi> btcdrak: but still, that probably reduces bugs in the consensus part, but still it does not guarantee the correctness.
3762016-07-11T19:19:29  <sipa> xinxi: the code would have a bug, arguably. but we can't tell everyone to change their code, so it will need to be the document that had to be changed
3772016-07-11T19:19:59  <gmaxwell> morcos: I agree with that in principle. We don't however, want to end up with a web of redundant mechenisms, potentially interacting.
3782016-07-11T19:20:16  <sipa> xinxi: so we've usually said that a specification for bitcoin would be descriptive but not prescriptive... the laws of the network are those implemented by the code that people choose to run, not by an abstract descriptio
3792016-07-11T19:20:22  <morcos> a bigger web you mean?
3802016-07-11T19:20:27  <gmaxwell> morcos: hah
3812016-07-11T19:20:47  <sdaftuar> unfortunately some of the bugs we've encountered (eg that hasHeaders thing that got reverted) wouldn't be fixed on restart either
3822016-07-11T19:20:58  <sipa> for 0.14 i think we need to refactor the sync code
3832016-07-11T19:21:07  * sdaftuar ducks
3842016-07-11T19:21:10  <sipa> many parallel mechanisms and duplicated code
3852016-07-11T19:21:17  <gmaxwell> sdaftuar: you could instead have a simple counter, set to zero whenever you connect, incremented on every non-connecting header response. And dos score only when it hits a threshold to avoid that effect.
3862016-07-11T19:21:25  <sipa> no blame anywhere, but we've accumulated too much technical debt
3872016-07-11T19:21:40  <sdaftuar> gmaxwell: yep that's what i was thinking too
3882016-07-11T19:21:48  <gmaxwell> sdaftuar: I believe thats the first sync stuck bug I've ever seen that wasn't fixed on a restart.
3892016-07-11T19:22:07  <sdaftuar> i think i've seen 0.9 nodes not be able to recover from restart
3902016-07-11T19:22:09  <xinxi> sipa: we don't have to be like that. I was motivated by the project CompCert and SEL4. SEL4 is a OS kernel that's proved to be 100% consistent with the specification.
3912016-07-11T19:22:27  <sipa> xinxi: that implies you have a specification
3922016-07-11T19:22:37  <sipa> as i've said before, we can't have one
3932016-07-11T19:22:46  <sipa> we can describe the current behaviour
3942016-07-11T19:22:52  <gmaxwell> sdaftuar: well there was also the "stops on too many orphans" stuff between ~0.8 and 0.10.
3952016-07-11T19:22:59  <sipa> and then formally prove that future code matches that behaviour
3962016-07-11T19:23:47  <gmaxwell> (where it would start fetching blocks backwards, run into a 750 block orphan limit then stop, but even that could recover with enough restarts)
3972016-07-11T19:24:25  <xinxi> sipa: I just don't understand the factor that stops us from driving a formal specification from the code.
3982016-07-11T19:24:42  <gmaxwell> sdaftuar: in any case, I think doing get headers triggered on single header responses, and counting the failures, and DOSing on too many failures... would address both our concerns here.
3992016-07-11T19:25:05  <sipa> xinxi: deriving? yes, we could
4002016-07-11T19:25:12  <sdaftuar> gmaxwell: sounds right to me as well.  for 0.13.0?
4012016-07-11T19:25:40  <sipa> xinxi: i guess my point is that the only way to write a formal specification is by extracting it from the actually implemented and deployed code
4022016-07-11T19:25:41  <xinxi> sipa: yeah, that's where we can start from.
4032016-07-11T19:25:58  <sipa> xinxi: and not from behaviour that humans write
4042016-07-11T19:25:59  <btcdrak> xinxi: the difficulty is if the code differs from the written specification the code wins. Even if you class it as a bug, changing it is extremely hard because you have to change the network consensus. There are examples where this has happened and we've just had to live with the bug.
4052016-07-11T19:26:09  <gmaxwell> Yes, I think it wouldn't be more complex than that patch you currently have. (this is also not just a testnet problem-- we're just fortunate that miners have lately not be excessively rolling their timestamps forward...)
4062016-07-11T19:26:40  <btcdrak> xinxi: the other problem is unknown bugs which we might not be aware of, rare edge cases say, are actually part of the consensus rules even if we dont know it.
4072016-07-11T19:26:46  <sdaftuar> ok i'll see if i can whip up an improved patch
4082016-07-11T19:26:56  <gmaxwell> btcdrak: the kind of "formal specification" in the sense of SEL4 can be proven to agree with the code (effectively, the specification is at least as complex as the implementation)
4092016-07-11T19:26:58  <btcdrak> xinxi: so it's hard to document things you dont know
4102016-07-11T19:27:05  <xinxi> @btcdrak those rare edge bugs can be eliminated by formal proofs I think.
4112016-07-11T19:27:26  <btcdrak> xinxi: seems like a very worthwhile pursuit though.
4122016-07-11T19:27:59  <xinxi> so the motivation of this is to avoid catastrophic failures of Bitcoin.
4132016-07-11T19:28:04  <sipa> xinxi: for example, for a long time, bitcoin relied on OpenSSL's signature parsing code
4142016-07-11T19:28:14  <sipa> xinxi: people thought they knew what this code did
4152016-07-11T19:28:23  <sipa> xinxi: and reimplemented the logic in other places
4162016-07-11T19:28:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4172016-07-11T19:28:41  <sipa> but nobody checked that what they thought actually matched what openssl was doing
4182016-07-11T19:28:45  <sipa> turns out, it didn't
4192016-07-11T19:29:14  <sipa> so now bitcoin's "specification" implicitly depended on OpenSSL's implementation
4202016-07-11T19:29:29  <xinxi> sipa: this kind of inconsistencies can be eliminated by formal proofs as well.
4212016-07-11T19:29:34  <sipa> xinxi: absolutely
4222016-07-11T19:29:56  <sipa> xinxi: but only if they would take OpenSSL's code into account and analyse it, and not treat it as a black box
4232016-07-11T19:30:05  <gmaxwell> xinxi: I'm not sure if you have a grasp of the difficulty of what you're thinking about, go look at the size of the SEL4 kernel. I believe it's about 4000 lines of C.  The isabelle specification for it is something like a half million lines, and though it proves many useful things about it, it falls far short of proving so much that agreement with the spec would be equivilent to correct in a hum
4242016-07-11T19:30:11  <gmaxwell> an sense.
4252016-07-11T19:30:16  <sipa> and this cross-layer effect on consensus makes it IMHO nearly impossible
4262016-07-11T19:30:24  <xinxi> gmaxwell: it's about 9000 lines of code.
4272016-07-11T19:30:27  <sipa> but i am not an expert on the state of the art of formal code proofs
4282016-07-11T19:30:54  <gmaxwell> xinxi: k, my figures are from memory thus approximate.
4292016-07-11T19:31:30  <xinxi> gmaxwell: SEL4 has to guarantee high efficiency. So the code has to be written in C which is difficult to prove.
4302016-07-11T19:32:04  <gmaxwell> xinxi: yes, and Bitcoin has to achieve high efficiency, efficiency is a security parameter for us.
4312016-07-11T19:32:07  <xinxi> For Bitcoin, the programming language is not a big issue, and using languages like Coq, which enables a unified way for both coding and proofs could make it a lot easier.
4322016-07-11T19:32:12  <gmaxwell> No. incorrect.
4332016-07-11T19:32:32  <gmaxwell> If nodes are not fast enough the system will stop converging, at some point this results in a total consensus failure.
4342016-07-11T19:32:41  <xinxi> I think OCaml is quite decent in terms of efficiency. Coq can generate OCaml code.
4352016-07-11T19:32:58  <sipa> well we're not going to rewrite the consensus code in another language!
4362016-07-11T19:33:00  <gmaxwell> Coq can generate C code via the compcert formalization (see VST).
4372016-07-11T19:33:14  <xinxi> gmaxwell: here we go.
4382016-07-11T19:33:15  <sipa> (or at least not without proving that the existing code matches the new code)
4392016-07-11T19:33:44  <xinxi> how many lines of code are there for the consensus part?
4402016-07-11T19:34:05  <xinxi> rewriting the consensus part is not infeasible after you separate it out.
4412016-07-11T19:34:07  <sipa> do you include the cryptography library? the c++ standard library? the kernel?
4422016-07-11T19:34:25  <gmaxwell> Far more than SEL4, the crypto part of it alone is that big.
4432016-07-11T19:34:27  <sipa> changes in any of those can affect consensus
4442016-07-11T19:34:44  <sipa> at some point you have to make an abstraction
4452016-07-11T19:34:57  <kanzure> "formal proofs" cannot eliminate edge cases, they can only prove that the edge case exists
4462016-07-11T19:34:59  <xinxi> sipa: we can leave cryptography part there first. C++ is just hopeless for verification. It's too complicated.
4472016-07-11T19:35:11  <sipa> xinxi: then i think there is nothing we can do
4482016-07-11T19:35:13  <kanzure> xinxi: how are you migrating the network precisely?
4492016-07-11T19:35:18  <kanzure> wtf?
4502016-07-11T19:35:28  <gmaxwell> chill chill.
4512016-07-11T19:35:39  <sipa> these are intesting things to discuss
4522016-07-11T19:35:44  <Chris_Stewart_5> xinxi: I think someone wrote a libsecp256k1 for ocaml if you are serious about implementing
4532016-07-11T19:35:52  <Chris_Stewart_5> using ctypes
4542016-07-11T19:36:04  <sipa> Chris_Stewart_5: what if the ocaml implementation doesn't match the C one?
4552016-07-11T19:36:14  <sipa> we won't know without analysing the one that is actually used
4562016-07-11T19:36:27  <sipa> (libsecp256k1, by the way, does have formal proofs for part of its operation)
4572016-07-11T19:36:33  <xinxi> I mean we can separate out libconsensus first, and then use Coq to rewrite it and generate a provably correct version of libconsensus.
4582016-07-11T19:36:48  <kanzure> xinxi: there are a lot of subtle side effects from the actual running network, but everyone in here still thinks it would be valuable to pursue formal verification anyway
4592016-07-11T19:36:52  *** gmaxwell has left #bitcoin-core-dev
4602016-07-11T19:37:13  <sipa> xinxi: how will you prove that the existing libconsensus (which only does script validation, not full block validation) matches that Coq specification?
4612016-07-11T19:37:14  <kanzure> libconsensus imho should be a priority similar to segwit
4622016-07-11T19:37:54  <sipa> kanzure: i agree. but we first need a plan for what 'libconsensus' means. people have been talking about it for ages, and have meant very different (and conflicting) things with it
4632016-07-11T19:38:08  <xinxi> sipa: we don't prove the existing libconsensus. We derive the formal specification based on the existing libconsensus, and then write another libconsensus in Coq.
4642016-07-11T19:38:11  <kanzure> sipa: maybe we can hijack the milan conference for these purposes (scaling bitcoin 3)
4652016-07-11T19:38:14  <GitHub72> [bitcoin] JeremyRubin opened pull request #8330: WIP: Structure Packing Optimizations in CTransaction and CTxMemPoolEntry (master...structurepacking) https://github.com/bitcoin/bitcoin/pull/8330
4662016-07-11T19:38:40  <Chris_Stewart_5> sipa: It just binds to the C library, so unless there is a bug in ctypes you should be ok
4672016-07-11T19:38:42  <sipa> xinxi: does you derivation prove that the specification matches the current libconsensus?
4682016-07-11T19:39:13  <sipa> sorry; does you derivation result in a specification that provably captures the current behaviour?
4692016-07-11T19:39:32  <xinxi> sipa: no. do they have to match exactly?
4702016-07-11T19:39:35  <sipa> Yes.
4712016-07-11T19:39:38  <xinxi> we just take off there.
4722016-07-11T19:39:48  <kanzure> can coq do outputs re: "behavior is definitely undefined here"?
4732016-07-11T19:40:02  <sipa> xinxi: the specification for the network is the actually deployed code
4742016-07-11T19:40:15  <sipa> any divergence from it can result in a network fork
4752016-07-11T19:40:29  <xinxi> sipa: I think there can be slight difference?
4762016-07-11T19:40:36  <sipa> xinxi: such as?
4772016-07-11T19:40:44  <sipa> if you can't describe the current code exactly, we're done
4782016-07-11T19:40:54  <kanzure> once you announce a difference, soeone will probably try to trigger those circumstances anyway :)
4792016-07-11T19:41:15  <sipa> we won't rewrite the consensus layer in another language without certainty that it does not introduce any changes compared to the current code
4802016-07-11T19:42:15  <xinxi> have you guys talked about this before?
4812016-07-11T19:42:20  <sipa> yes
4822016-07-11T19:42:20  <kanzure> endlessly
4832016-07-11T19:42:34  <xinxi> many times?
4842016-07-11T19:42:36  <sipa> xinxi: i don't think you're understanding what i'm saying
4852016-07-11T19:42:48  <sipa> we do not prescribe the rules of the network
4862016-07-11T19:42:50  <kanzure> xinxi: there is high interest in our community in formal verification and libconsensus and coq.
4872016-07-11T19:43:08  <Chris_Stewart_5> ^^^
4882016-07-11T19:43:08  <petertodd> sipa: along with the pragmatic requirement that the new language have a sufficiently large community of programmers to be maintainable - unusual languages don't need that criteria
4892016-07-11T19:43:21  <sipa> petertodd: agree, but i wasn't going to bring that up
4902016-07-11T19:43:49  <sipa> the first point is that our compatibility concerns are way beyond almost any other system
4912016-07-11T19:44:19  <xinxi> @petertodd that may not be a problem. Later the code will be proof driven. And the core team writes the specification, and the committers need to prove the correctness of their code, which makes them impossible to make any mistakes.
4922016-07-11T19:44:22  <kanzure> xinxi: this seems like something you would like to work on?
4932016-07-11T19:44:37  <sipa> xinxi: i'm getting annoyed
4942016-07-11T19:44:46  <sipa> xinxi: the core team does not write the specification
4952016-07-11T19:45:15  <xinxi> @kanzure yes, it is. And two professors in my school, i.e. National University of Singapore, are willing to work in it as well. They are experts on software verification.
4962016-07-11T19:45:23  <petertodd> ...and the specification will change over time as new features are soft-forked in, and specification flaws are fixed
4972016-07-11T19:45:23  <sipa> xinxi: that's very interesting
4982016-07-11T19:45:35  <xinxi> and we may have big funding support.
4992016-07-11T19:45:56  <xinxi> the purpose is simple. we want to make bitcoin reliable.
5002016-07-11T19:46:02  <sipa> xinxi: but i first want to understand why you say "< xinxi> sipa: I think there can be slight difference?"
5012016-07-11T19:46:05  <Chris_Stewart_5> petertodd: Specifications can be changed overtime, and theoretically the proofs should reflect those changes
5022016-07-11T19:46:13  <xinxi> the impact could be huge.
5032016-07-11T19:46:25  <kanzure> xinxi: there are many bitcoin developers who want that as well. i think you could easily find collaborators from this conversation.
5042016-07-11T19:46:48  <petertodd> xinxi: it's not going to be huge - the reliability of the consensus specification/implementation hasn't been a major problem for bitcoin - other problems are far higher-impact (scaling)
5052016-07-11T19:47:06  <petertodd> xinxi: I'd suggest you focus your efforts on smart-contract use-cases, where specification flaws have been a huge problem (ethereum dao)
5062016-07-11T19:47:13  <sipa> hey
5072016-07-11T19:47:26  <kanzure> petertodd: nooo we do need some people thinking about libconsensus things
5082016-07-11T19:47:38  <xinxi> petertodd: I think we are just lucky that Bitcoin has not yet experienced any catastrophic attacks?
5092016-07-11T19:47:42  <Chris_Stewart_5> petertodd: I disagree, the consensus layer is the bedrock of bitcoin, if we screw that up in a major way we are done
5102016-07-11T19:48:04  <kanzure> smart contract stuff is already getting formal verification attention, i woudn't worry about that, it was fairly high profile and papers have been published already
5112016-07-11T19:48:08  <petertodd> kanzure: I'm not saying we don't, it's just that from the point of view of a researcher, they're going to get better return on their time by doing other things
5122016-07-11T19:48:20  <kanzure> disagree
5132016-07-11T19:48:41  <xinxi> petertodd: not all researchers work for papers.
5142016-07-11T19:48:47  <petertodd> xinxi: it's not luck... it's how we make changes - turns out that intense review works
5152016-07-11T19:48:51  <xinxi> impact is much more important.
5162016-07-11T19:48:56  <Chris_Stewart_5> petertodd: Until it doesn't
5172016-07-11T19:49:06  <Chris_Stewart_5> Bitcoin has already had issues with this in the past
5182016-07-11T19:49:18  <xinxi> petertodd: OpenSSL has been used by so many people. Still it has serious bugs.
5192016-07-11T19:49:18  *** jtimon has quit IRC
5202016-07-11T19:49:21  <Chris_Stewart_5> Bip66 (or was it 62) comes to mind
5212016-07-11T19:49:23  <sipa> how many consensus failures in bitcoin can you name? :)
5222016-07-11T19:49:27  <sipa> yes, that's one
5232016-07-11T19:49:43  <sipa> the march 2013 fork was another one
5242016-07-11T19:49:59  <btcdrak> xinxi: you should probably also have a conversation with jtimon (who just pinged out). he's going a lot of the libconsensus stuff.
5252016-07-11T19:50:02  <petertodd> Chris_Stewart_5: there's no reason to think yet that formal proofs actually do any better in practice, because the pool of talent that can work on them is much smaller
5262016-07-11T19:50:15  <sipa> and bitcoin's scripting language before the removal of OP_VER was also a consensus problem
5272016-07-11T19:50:20  <sipa> i don't know of any others tbh
5282016-07-11T19:50:27  <petertodd> xinxi: indeed, which is why OpenSSL got replaced by libsecp256k1
5292016-07-11T19:50:38  <sipa> OP_VER was in 2010
5302016-07-11T19:50:46  <sipa> and all the others were due to supporting libraries
5312016-07-11T19:50:58  <sipa> xinxi: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html <- read that
5322016-07-11T19:51:02  <xinxi> btcdrak: Yeah some one mentioned him to me.
5332016-07-11T19:51:07  <sipa> (shameless plug)
5342016-07-11T19:51:25  <sipa> xinxi: it gives you an idea of how complicated it was to find some of the actually known consensus failures in bitcoin
5352016-07-11T19:51:43  <sipa> the fact that no easier ones have been found may give an indication
5362016-07-11T19:52:29  <Chris_Stewart_5> petertodd: I think there actually has been some considerable interest in the formal verification community in bitcoin. I've talked to a handful of researchers myself and I don't think directing them away from the core protocol is a good idea
5372016-07-11T19:52:31  <xinxi> I mean the provably correct version of libconsensus may not be consistent with the existing one. The most serious result would be a hard fork, rigth?
5382016-07-11T19:52:44  *** TomMc has joined #bitcoin-core-dev
5392016-07-11T19:52:46  <xinxi> But after that, we will take off. And Bitcoin will be much more secure than before.
5402016-07-11T19:52:56  <sipa> xinxi: but we'll need a hard fork to get there?
5412016-07-11T19:53:19  <xinxi> if the provably correct version is done, is it worth to have a hard fork?
5422016-07-11T19:53:31  <sipa> maybe
5432016-07-11T19:53:37  <petertodd> Chris_Stewart_5: I'm not saying there isn't interest, I'm saying that if you want to make a high impact with formal verification deployed in production, Bitcoin isn't interesting because the risks of deploying formal verification in production are higher than the theoretical benefits
5442016-07-11T19:53:56  <sipa> xinxi: but there are requirements beyond just correctness
5452016-07-11T19:54:06  <petertodd> Chris_Stewart_5: whereas with smart-contract systems, the risks of the existing approaches are known to be very high - likely too high to be practical - so the risks of alternate approaches are less in comparison
5462016-07-11T19:54:32  <sipa> xinxi: such as performance, and ease of maintenance
5472016-07-11T19:54:35  <btcdrak> xinxi: there are other things than correctness which can cause consensus failure.
5482016-07-11T19:54:54  <xinxi> petertodd: sorry, peter, I think current smart contract platforms are trying to solve some hypothetical problems. But this is a bit irrelevant.
5492016-07-11T19:55:20  <petertodd> xinxi: speaking of performance, will your formal verification techniques be able to guarantee bounds on execution time/space?
5502016-07-11T19:55:27  <kanzure> is jl2012 in singapore?
5512016-07-11T19:55:33  <btcdrak> hk
5522016-07-11T19:55:37  <kanzure> damn
5532016-07-11T19:55:37  <sipa> jl2012 is in hong kong
5542016-07-11T19:55:43  <sipa> what petertodd said
5552016-07-11T19:56:00  <petertodd> xinxi: *ethereum* is trying to solve a hypothetical problem; systems like R3's Corda are solving very real problems. Yes, they may be problems in centralized systems, but that doesn't make those problems any less real.
5562016-07-11T19:56:42  <sipa> i think proving time and space bounds (ideally on the current code!) is probably more useful in practice than a formal specification (which i expect to be much more complicated than you expect, if it is to have production value)
5572016-07-11T19:56:55  <xinxi> petertodd: I think most smart contracts should run on AWS. That's much more efficient and easy to use.
5582016-07-11T19:57:24  <xinxi> sipa: why do we need to prove time and space bounds?
5592016-07-11T19:57:36  <petertodd> xinxi: smart contracts are about verification, not computation; "should run on AWS" makes no sense
5602016-07-11T19:58:08  <sipa> xinxi: because if an attack exists that can make validation slow on some nodes, you can take advantage of that (a miner could knock out competition, or get a propagation advantage)
5612016-07-11T19:58:14  <petertodd> xinxi: if you exceed the time/space bounds allowed by the actual implementation, the system fails to reach consensus
5622016-07-11T19:58:25  <sipa> xinxi: if an attack exists that can make memory grow unbounded, you can knock out validation
5632016-07-11T19:58:53  <petertodd> xinxi: in fact, it's fair to say that much of the current development effort is ultimately about making the upper-bound time cost of a block lower
5642016-07-11T19:58:57  <sipa> xinxi: for bitcoin's security assumptions to hold, verification of blocks must be negligable in time compared to the block production rate
5652016-07-11T19:59:40  <xinxi> sipa: that sounds like the scalability issues that you guys are trying to solve.
5662016-07-11T20:00:48  <sipa> well, it's much more a problem today than fear of consensus failure
5672016-07-11T20:01:28  <xinxi> petertodd: a simpler way to do smart contracts is to have trustworthy organization to run a platform on AWS and then people can run their smart contracts on the platform. It's scalable, efficient, and can also be verified.
5682016-07-11T20:02:09  <petertodd> xinxi: the whole point of smart contracts in banking is to get away from that model
5692016-07-11T20:02:22  <btcdrak> xinxi: but we are interested in decentralised systems; there's special about yet another centralised system.
5702016-07-11T20:02:42  <sipa> petertodd, xinxi: i think centralized smart contract design is a bit off topic here
5712016-07-11T20:02:43  <petertodd> xinxi: verifying computaitons are done correctly is not easy
5722016-07-11T20:02:47  <xinxi> petertodd: yeah, we can use Bitcoin in that AWS based smart contract platform. It does not have to be decentralized.
5732016-07-11T20:03:50  <petertodd> sipa: point is, I think xinxi would be much better off solving problems in that problem space first, as they're easier to solve with more impact, and that'll give them tools to tackle bitcoin later; misunderstandings about that problem space are indicative of serious misunderstandings with how bitcoin works
5742016-07-11T20:04:10  <petertodd> xinxi: again, do you understand my point about verification vs. computation?
5752016-07-11T20:06:22  <xinxi> petertodd: you are right. A third party's platform cannot be fully trusted and thus full verification is impossible. But most people's smart contracts don't need that kind of strong verification.
5762016-07-11T20:06:46  *** gmaxwell has joined #bitcoin-core-dev
5772016-07-11T20:08:08  <xinxi> To me, Bitcoin is great because it is solving a real problem.
5782016-07-11T20:08:09  *** Giszmo has quit IRC
5792016-07-11T20:08:35  <Chris_Stewart_5> xinxi: Having a formally verified library of smart contracts would be useful. As in any programming language you end up having design patterns, you will see the emergence of patterns in smart contracts imo
5802016-07-11T20:09:03  <xinxi> Chris_Stewart_5: it is truly useful in some extreme cases.
5812016-07-11T20:09:38  <petertodd> xinxi: I suspect you're unclear as to what smart contracts even do... the sane use-cases I'm talking about, are to formalize legal contracts, allowing adherence to them to be verified - that only works because you can take the state you're in - legally speaking - and verify that it matches the smart contracts (aka protocol definitions)
5822016-07-11T20:09:59  <xinxi> And the biggest concern of Bitcoin to me is not the lack of functions but its security. Many people still think it is too young and not reliable enough and could fail completely and thus don't want to adopt it.
5832016-07-11T20:10:10  <petertodd> xinxi: bitcoin is exactly the same, except that on top of that, PoW allows our state to converge to a single consensus history
5842016-07-11T20:10:33  <petertodd> xinxi: the most likely way bitcoin will fail right now is a failure of decentralization, which is very closely tied to scalability
5852016-07-11T20:11:00  <sipa> petertodd: agree, but i still think smart contracts is off topic here.
5862016-07-11T20:11:07  <sipa> of the type you're describing
5872016-07-11T20:11:49  *** Giszmo has joined #bitcoin-core-dev
5882016-07-11T20:11:50  <petertodd> sipa: again, I'm trying to explain to xinxi how this stuff works - not make smart contracts the topic...
5892016-07-11T20:12:02  <sipa> ok, great
5902016-07-11T20:12:53  <sipa> xinxi: i think it's unlikely that people will accept a hard fork to switch to a more formally provable consensus implementation
5912016-07-11T20:13:01  <xinxi> petertodd: to me, smart contracts are just contracts in code.
5922016-07-11T20:13:13  <sipa> i think you're talking about different things
5932016-07-11T20:13:51  <petertodd> xinxi: that's not any different from what I said... legal contracts are verification, not computation - they're about conditions that need to be met for something to be valid - aka a protocol specification
5942016-07-11T20:14:38  <petertodd> xinxi: equally, the definition of the bitcoin protocol is what the bitcoin implementation accepts as valid - the fact the code that does that is somewhat intermixed with code that records state is just a historical mistake
5952016-07-11T20:14:42  <xinxi> yeah, a coded contracts can be run on AWS and still legally binding.
5962016-07-11T20:15:08  <xinxi> you just write the legal part in terms of conditions.
5972016-07-11T20:15:09  <sipa> xinxi: but if it has very clear benefits (like performance/resource bounds), is easy to work with... maybe, but that's not something for us to decide
5982016-07-11T20:15:11  <btcdrak> xinxi: in this space smart contracts are self enforcing contract
5992016-07-11T20:15:36  <sipa> xinxi: i don't think people should ever expect a future hard forking change to succeed
6002016-07-11T20:15:38  <petertodd> xinxi: why do you keep saying AWS here? that's completely missing the point: what you want is to be able to show to someone else (e.g a judge, but hopefully it doesn't go that far) that the smart contract hasn't been upheld
6012016-07-11T20:16:18  <sipa> xinxi: so imho for formal verification to be practical in the short term, it has to be about the currently deployed code
6022016-07-11T20:16:19  <petertodd> btcdrak: self-enforcing because of the underlying proof-of-work layers ensuring consensus, and the fact that people widely choose to accept the outputs of the system - bitcoin being a perfect - albeit inflexible - example
6032016-07-11T20:16:40  *** Giszmo has quit IRC
6042016-07-11T20:16:40  <xinxi> My point is current smart contract platforms are mostly solving hypothetical problems.
6052016-07-11T20:16:46  <petertodd> sipa: yeah, pragmatically speaking, replacing the entire codebase in a hardfork is going to be incredibly controversial at best
6062016-07-11T20:16:51  <sipa> petertodd: indeed
6072016-07-11T20:17:30  <sipa> petertodd, xinxi: again, please take that discussion elsewhere. yes, there is some overlap that is relevant here. but discussion about what problems smart contracts are solving is not
6082016-07-11T20:17:37  *** ChanServ sets mode: +o sipa
6092016-07-11T20:17:54  <petertodd> sipa: ack
6102016-07-11T20:17:55  <xinxi> sipa: yeah. My focus is still formal verification.
6112016-07-11T20:18:00  *** sipa sets mode: -o sipa
6122016-07-11T20:18:01  <sipa> thanks
6132016-07-11T20:18:30  <sipa> xinxi: have you read my BIP66 writeup above?
6142016-07-11T20:18:56  <xinxi> So you are Pieter?
6152016-07-11T20:18:58  <sipa> yes
6162016-07-11T20:19:02  <xinxi> cool
6172016-07-11T20:19:03  <sipa> i think it is useful to illustrate the difficulty of consensus problems
6182016-07-11T20:19:09  <sipa> of finding
6192016-07-11T20:19:39  <kanzure> btcdrak: bitcoincore.org/en/team/ is lacking usernames
6202016-07-11T20:20:44  <btcdrak> kanzure: really could do with a bio page. people's user handles are not always consistent across platforms
6212016-07-11T20:20:59  *** go1111111 has joined #bitcoin-core-dev
6222016-07-11T20:21:13  <xinxi> sipa: please let met read it first.
6232016-07-11T20:21:47  <petertodd> xinxi: we'll, lets continue the discussion in another hour or two after you read it :)
6242016-07-11T20:21:52  <petertodd> bbl!
6252016-07-11T20:21:54  *** spudowiar has joined #bitcoin-core-dev
6262016-07-11T20:23:11  <sipa> xinxi: (i'll only mention this once): bitcoin core's cryptography library (libsecp256k1) does have some modest attempts at formally verifying pieces of the code, and help there would also be very welcome. It's much less ambitious than proving properties about bitcoin's consensus code, but also much easier to accomplish something in my opinion
6272016-07-11T20:23:41  <kanzure> sipa: don't you guys have that libsecp256k1 paper at some point? :D
6282016-07-11T20:23:53  <sipa> kanzure: at some point.
6292016-07-11T20:24:52  <btcdrak> xinxi: see https://github.com/bitcoin-core/secp256k1
6302016-07-11T20:25:13  <xinxi> btcdrak: thanks.
6312016-07-11T20:25:31  <xinxi> sipa: that's understandable. It takes huge amount of money to get started.
6322016-07-11T20:26:30  *** Chris_Stewart_5 has quit IRC
6332016-07-11T20:27:24  <sipa> also, #secp256k1 for that
6342016-07-11T20:29:29  *** Giszmo has joined #bitcoin-core-dev
6352016-07-11T20:29:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6362016-07-11T20:31:59  <Chris_Stewart_5> sipa: I just read the email, however the hard fork last July wasn't related to the implementation of BIP66 , it was just spv mining correct?
6372016-07-11T20:32:13  <sipa> that was not a hard fork
6382016-07-11T20:32:18  <sipa> just miners creating invalid blocks
6392016-07-11T20:32:40  <sipa> and it triggered when bip65 activated
6402016-07-11T20:32:47  <sipa> not bip66, which was a year earlier
6412016-07-11T20:35:32  <Chris_Stewart_5> Seems that OP_CLTV was activated ~7 months ago?
6422016-07-11T20:35:53  <Chris_Stewart_5> I distinctly remember the issue being July 4th of last year
6432016-07-11T20:35:54  <btcdrak> yes, he means BIP66
6442016-07-11T20:35:58  <Chris_Stewart_5> oh ok
6452016-07-11T20:36:06  <sipa> oh, i'm misremembering
6462016-07-11T20:36:19  <btcdrak> CLTV went without a hitch.
6472016-07-11T20:36:25  <sipa> apologies
6482016-07-11T20:36:30  <Chris_Stewart_5> np
6492016-07-11T20:36:55  <btcdrak> I dont know, I think we must give a punishment.
6502016-07-11T20:38:06  <Chris_Stewart_5> Seven more years of reading openssl!
6512016-07-11T20:38:20  <btcdrak> too harsh. maybe no computer! and go to bed early!
6522016-07-11T20:46:19  <sipa> hah
6532016-07-11T20:46:43  <xinxi> sipa: so you wrote most of secp256k1?
6542016-07-11T20:46:55  *** BCBot has quit IRC
6552016-07-11T20:47:12  *** BCBot has joined #bitcoin-core-dev
6562016-07-11T20:48:13  <xinxi> The email seems fantastic.
6572016-07-11T20:48:39  <xinxi> It's truly a tough journey.
6582016-07-11T20:49:25  <sipa> xinxi: i started it; most of the fancier optimizations and verifications/tests were proposed or implemented by others
6592016-07-11T20:50:20  *** Giszmo has quit IRC
6602016-07-11T20:53:22  *** Chris_Stewart_5 has quit IRC
6612016-07-11T20:56:45  *** Giszmo has joined #bitcoin-core-dev
6622016-07-11T20:57:13  <xinxi> sipa: that's interesting. I saw it's written in C intead of C++. I thought you deliberately did that for verification?
6632016-07-11T20:58:25  <sipa> xinxi: it started as C++, actually, but gmaxwell suggested converting it to C to aide with formal verification
6642016-07-11T20:58:36  <sipa> as there are more analysis tools available for C than C++
6652016-07-11T20:58:45  <sipa> this was very early on
6662016-07-11T20:58:56  <xinxi> sipa: fantastic! I am so glad to see it's formally verified!
6672016-07-11T20:59:10  <sipa> i wouldn't say it's formally verified
6682016-07-11T20:59:21  <sipa> just some pieces
6692016-07-11T20:59:29  <xinxi> C++ is just too complicated to verify.
6702016-07-11T20:59:32  <sipa> i can discuss more on #secp256k1
6712016-07-11T20:59:43  <xinxi> Is it a channel?
6722016-07-11T20:59:45  <sipa> yes
6732016-07-11T20:59:54  <xinxi> sipa: let's talk there.
6742016-07-11T21:04:42  *** Giszmo has quit IRC
6752016-07-11T21:06:01  *** Giszmo has joined #bitcoin-core-dev
6762016-07-11T21:08:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6772016-07-11T21:14:17  *** laurentmt has joined #bitcoin-core-dev
6782016-07-11T21:14:38  *** laurentmt has quit IRC
6792016-07-11T21:23:07  *** justanotheruser has quit IRC
6802016-07-11T21:23:51  *** justanotheruser has joined #bitcoin-core-dev
6812016-07-11T21:24:15  *** justanotheruser has quit IRC
6822016-07-11T21:24:40  *** justanotheruser has joined #bitcoin-core-dev
6832016-07-11T21:32:42  *** frankenmint has joined #bitcoin-core-dev
6842016-07-11T21:34:16  *** xinxi has quit IRC
6852016-07-11T21:38:04  *** arubi has quit IRC
6862016-07-11T21:42:20  *** arubi has joined #bitcoin-core-dev
6872016-07-11T21:43:42  *** xinxi has joined #bitcoin-core-dev
6882016-07-11T21:43:59  *** jannes has quit IRC
6892016-07-11T21:44:34  *** moli has quit IRC
6902016-07-11T21:47:58  *** xinxi has quit IRC
6912016-07-11T21:51:07  *** spudowiar has quit IRC
6922016-07-11T21:52:01  *** spudowiar has joined #bitcoin-core-dev
6932016-07-11T22:13:33  *** frankenmint has quit IRC
6942016-07-11T22:14:09  *** Guyver2 has quit IRC
6952016-07-11T22:15:20  *** proslogion has joined #bitcoin-core-dev
6962016-07-11T22:15:23  *** frankenmint has joined #bitcoin-core-dev
6972016-07-11T22:15:35  *** proslogion has left #bitcoin-core-dev
6982016-07-11T22:17:31  *** TomMc has quit IRC
6992016-07-11T22:28:32  *** belcher has joined #bitcoin-core-dev
7002016-07-11T22:30:32  *** TomMc has joined #bitcoin-core-dev
7012016-07-11T22:35:15  <GitHub44> [bitcoin] dooglus opened pull request #8331: Fix three 'comparison between signed and unsigned integer expressions' warnings. (master...fix-compilation-warnings) https://github.com/bitcoin/bitcoin/pull/8331
7022016-07-11T22:50:22  *** moli has joined #bitcoin-core-dev
7032016-07-11T23:06:15  *** Giszmo has quit IRC
7042016-07-11T23:10:00  *** Giszmo has joined #bitcoin-core-dev
7052016-07-11T23:16:55  *** Giszmo has quit IRC
7062016-07-11T23:25:26  *** spudowiar has quit IRC
7072016-07-11T23:40:01  *** mkarrer has quit IRC
7082016-07-11T23:42:50  *** Giszmo has joined #bitcoin-core-dev
7092016-07-11T23:49:18  *** Giszmo has quit IRC