12016-05-12T00:00:28  <GitHub127> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/423ca302a3ee...69b3a6dd9d9a
  22016-05-12T00:00:28  <GitHub127> bitcoin/master 32114dd Wladimir J. van der Laan: bench: Add crypto hash benchmarks...
  32016-05-12T00:00:28  <GitHub127> bitcoin/master 69b3a6d Pieter Wuille: Merge #8039: bench: Add crypto hash benchmarks...
  42016-05-12T00:00:34  <phantomcircuit> wumpus, ^
  52016-05-12T00:00:41  <GitHub131> [bitcoin] sipa closed pull request #8039: bench: Add crypto hash benchmarks (master...2016_05_benchmark_sha256) https://github.com/bitcoin/bitcoin/pull/8039
  62016-05-12T00:02:39  *** alpalp has joined #bitcoin-core-dev
  72016-05-12T00:10:18  *** alpalp has quit IRC
  82016-05-12T00:10:30  *** alpalp has joined #bitcoin-core-dev
  92016-05-12T00:10:30  *** alpalp has joined #bitcoin-core-dev
 102016-05-12T00:19:41  *** kadoban has quit IRC
 112016-05-12T00:40:47  *** zooko has joined #bitcoin-core-dev
 122016-05-12T00:41:10  *** Ylbam has quit IRC
 132016-05-12T00:41:29  <gmaxwell> sipa: the xor-linked-list-ish trick in this is clever: http://www.cs.cmu.edu/~binfan/papers/login_cuckoofilter.pdf
 142016-05-12T00:59:11  *** Chris_Stewart_5 has quit IRC
 152016-05-12T01:00:07  *** kadoban has joined #bitcoin-core-dev
 162016-05-12T01:03:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 172016-05-12T01:09:51  *** donal has quit IRC
 182016-05-12T01:11:27  *** Chris_Stewart_5 has quit IRC
 192016-05-12T01:14:06  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 202016-05-12T01:35:04  *** dermoth_ has quit IRC
 212016-05-12T01:35:46  *** dermoth_ has joined #bitcoin-core-dev
 222016-05-12T01:37:49  *** alpalp has quit IRC
 232016-05-12T01:38:41  *** alpalp has joined #bitcoin-core-dev
 242016-05-12T01:38:53  *** alpalp has joined #bitcoin-core-dev
 252016-05-12T01:41:54  *** TomMc has quit IRC
 262016-05-12T01:54:01  *** Alopex has quit IRC
 272016-05-12T01:55:06  *** Alopex has joined #bitcoin-core-dev
 282016-05-12T02:12:58  *** belcher has quit IRC
 292016-05-12T02:13:55  *** Chris_Stewart_5 has quit IRC
 302016-05-12T02:33:31  *** alpalp has quit IRC
 312016-05-12T02:33:46  *** alpalp has joined #bitcoin-core-dev
 322016-05-12T02:37:09  *** grassass has joined #bitcoin-core-dev
 332016-05-12T02:43:02  *** grassass has quit IRC
 342016-05-12T02:47:05  *** TomMc has joined #bitcoin-core-dev
 352016-05-12T02:53:08  *** grassass has joined #bitcoin-core-dev
 362016-05-12T02:57:24  *** achow101 has quit IRC
 372016-05-12T02:57:37  *** TomMc has quit IRC
 382016-05-12T02:57:51  *** fengling has joined #bitcoin-core-dev
 392016-05-12T03:03:37  *** xiangfu has joined #bitcoin-core-dev
 402016-05-12T03:04:02  *** alpalp has quit IRC
 412016-05-12T03:08:29  *** mrkent has quit IRC
 422016-05-12T03:10:29  *** Giszmo has quit IRC
 432016-05-12T03:11:09  *** TomMc has joined #bitcoin-core-dev
 442016-05-12T03:32:02  *** Alopex has quit IRC
 452016-05-12T03:33:07  *** Alopex has joined #bitcoin-core-dev
 462016-05-12T03:45:40  *** CubicEarth has quit IRC
 472016-05-12T03:45:55  *** CubicEarth has joined #bitcoin-core-dev
 482016-05-12T04:07:02  *** TomMc has quit IRC
 492016-05-12T04:14:02  *** Alopex has quit IRC
 502016-05-12T04:15:07  *** Alopex has joined #bitcoin-core-dev
 512016-05-12T04:24:57  *** Cory has quit IRC
 522016-05-12T04:27:51  *** Cory has joined #bitcoin-core-dev
 532016-05-12T04:32:51  *** Cory has quit IRC
 542016-05-12T04:34:02  *** Alopex has quit IRC
 552016-05-12T04:35:07  *** Alopex has joined #bitcoin-core-dev
 562016-05-12T04:35:24  *** Pasha has joined #bitcoin-core-dev
 572016-05-12T04:42:18  *** Pasha is now known as Cory
 582016-05-12T04:49:06  *** xiangfu has quit IRC
 592016-05-12T04:52:01  *** Alopex has quit IRC
 602016-05-12T04:53:07  *** Alopex has joined #bitcoin-core-dev
 612016-05-12T04:56:04  *** earlest has quit IRC
 622016-05-12T04:57:51  *** gabridome has joined #bitcoin-core-dev
 632016-05-12T04:57:59  *** muuqwaul has joined #bitcoin-core-dev
 642016-05-12T05:08:01  *** Alopex has quit IRC
 652016-05-12T05:09:00  *** gill3s has joined #bitcoin-core-dev
 662016-05-12T05:09:06  *** Alopex has joined #bitcoin-core-dev
 672016-05-12T05:12:50  *** gabridome has left #bitcoin-core-dev
 682016-05-12T05:13:48  *** gabridome has joined #bitcoin-core-dev
 692016-05-12T05:14:40  *** xiangfu has joined #bitcoin-core-dev
 702016-05-12T05:22:18  *** gabridome has quit IRC
 712016-05-12T05:23:19  *** gabridome has joined #bitcoin-core-dev
 722016-05-12T05:28:59  *** gabridome has quit IRC
 732016-05-12T05:30:38  *** gabridome has joined #bitcoin-core-dev
 742016-05-12T05:42:17  *** fengling has quit IRC
 752016-05-12T05:43:25  *** gill3s has quit IRC
 762016-05-12T05:50:09  *** gill3s has joined #bitcoin-core-dev
 772016-05-12T05:52:01  *** gill3s has joined #bitcoin-core-dev
 782016-05-12T05:54:38  *** gabridome has quit IRC
 792016-05-12T05:59:43  *** gabridome has joined #bitcoin-core-dev
 802016-05-12T06:02:10  *** gill3s has quit IRC
 812016-05-12T06:05:28  *** gabridome has quit IRC
 822016-05-12T06:11:07  *** paveljanik has quit IRC
 832016-05-12T06:11:31  *** fengling has joined #bitcoin-core-dev
 842016-05-12T06:28:18  *** Ylbam has joined #bitcoin-core-dev
 852016-05-12T06:42:37  *** PaulCapestany has quit IRC
 862016-05-12T06:42:49  *** Squidicuz has quit IRC
 872016-05-12T06:43:15  *** Squidicuz has joined #bitcoin-core-dev
 882016-05-12T06:43:41  *** PaulCapestany has joined #bitcoin-core-dev
 892016-05-12T06:47:35  *** jtimon has quit IRC
 902016-05-12T06:48:38  <wumpus> jonasschnelli: but for the 1MB buffer the benchmark will get called more times, also flattening out variance
 912016-05-12T06:49:03  <wumpus> I also reasoned like you but forgot to take into account that the benchmarking framework automatically runs for a (approximate) fixed amount  of time
 922016-05-12T06:50:21  <wumpus> <Chris_Stewart_5> Is there a reason we don't have any logging inside of interpreter.cpp (or seemingly anything related to scripts)? <- for various reasons: it is inner-loop code, so logging would slow it down. Also it would be incredbily spammy. And further, any kind of logging complicates libconsensus initiatives by adding external dependencies
 932016-05-12T06:51:29  <wumpus> can anyone please benchmark this on an actual recent Intel processor? https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accel
 942016-05-12T06:51:58  <wumpus> intel's 'fast' sha256 assembly implementations mostly turn out slower instead of faster here
 952016-05-12T06:52:00  <wumpus> but that's on AMD
 962016-05-12T06:52:36  <gmaxwell> doing do
 972016-05-12T06:52:37  <gmaxwell> er so
 982016-05-12T06:59:55  <gmaxwell> wumpus: this is on a haswell based xeon:
 992016-05-12T06:59:57  <gmaxwell> SHA256_avx,319,0.00344849,0.00346613,0.0034525
1002016-05-12T06:59:57  <gmaxwell> SHA256_basic,191,0.00531399,0.00533286,0.00532052
1012016-05-12T06:59:57  <gmaxwell> SHA256_rorx,351,0.00290081,0.00290608,0.002903
1022016-05-12T06:59:57  <gmaxwell> SHA256_rorx_x8ms,351,0.0028524,0.00286806,0.0028543
1032016-05-12T06:59:59  <gmaxwell> SHA256_sse4,319,0.00342679,0.00345755,0.003443
1042016-05-12T07:00:35  *** xiangfu has quit IRC
1052016-05-12T07:00:36  *** go1111111 has quit IRC
1062016-05-12T07:00:51  *** xiangfu has joined #bitcoin-core-dev
1072016-05-12T07:04:57  <gmaxwell> and a somewhat lower clocked broadwell-ep xeon:
1082016-05-12T07:04:58  <gmaxwell> SHA256_avx,255,0.0039705,0.0040791,0.00397483
1092016-05-12T07:04:59  <gmaxwell> SHA256_basic,175,0.00599706,0.00610304,0.00599851
1102016-05-12T07:04:59  <gmaxwell> SHA256_rorx,319,0.00334549,0.00345182,0.00334802
1112016-05-12T07:04:59  <gmaxwell> SHA256_rorx_x8ms,319,0.00328481,0.00339317,0.00328667
1122016-05-12T07:05:01  <gmaxwell> SHA256_sse4,255,0.00395852,0.00404716,0.00396052
1132016-05-12T07:07:24  *** gill3s has joined #bitcoin-core-dev
1142016-05-12T07:11:23  *** AaronvanW has joined #bitcoin-core-dev
1152016-05-12T07:13:14  *** go1111111 has joined #bitcoin-core-dev
1162016-05-12T07:17:42  *** CubicEarth has quit IRC
1172016-05-12T07:18:10  <jonasschnelli> What does "OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)" exactly mean? nFile=-1 looks after a undefined CDiskBlockPos?
1182016-05-12T07:18:17  *** CubicEarth has joined #bitcoin-core-dev
1192016-05-12T07:18:42  <jonasschnelli> I'd like to debug the corruption I've got on my AARCH
1202016-05-12T07:20:36  *** BashCo has quit IRC
1212016-05-12T07:32:30  *** paveljanik has joined #bitcoin-core-dev
1222016-05-12T07:37:47  *** kadoban has quit IRC
1232016-05-12T07:43:00  *** BashCo has joined #bitcoin-core-dev
1242016-05-12T07:46:06  <jonasschnelli> wumpus: my results:
1252016-05-12T07:46:09  <jonasschnelli> SHA1,703,0.00148028,0.00152859,0.0015024
1262016-05-12T07:46:09  <jonasschnelli> SHA256_avx,415,0.00256598,0.00258584,0.0025782
1272016-05-12T07:46:10  <jonasschnelli> SHA256_basic,287,0.00375891,0.00400322,0.00383578
1282016-05-12T07:46:10  <jonasschnelli> SHA256_sse4,415,0.00255489,0.00261028,0.0025789
1292016-05-12T07:46:10  <jonasschnelli> SHA512,415,0.00251514,0.00256588,0.00252959
1302016-05-12T07:46:33  <jonasschnelli> Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz
1312016-05-12T07:47:47  <jonasschnelli> bench results of master...
1322016-05-12T07:47:48  <jonasschnelli> SHA1,703,0.00146294,0.00149019,0.00148072
1332016-05-12T07:47:48  <jonasschnelli> SHA256,255,0.00396442,0.00401562,0.00398446
1342016-05-12T07:47:48  <jonasschnelli> SHA512,415,0.00252354,0.0025878,0.00254187
1352016-05-12T07:48:32  <jonasschnelli> Ah. I guess SHA256_basic is the non-tweaked one..
1362016-05-12T07:49:04  <jonasschnelli> So... looks after a 150% performance increase on my xeon server
1372016-05-12T07:49:23  <jonasschnelli> same on gmaxwell's results
1382016-05-12T07:51:51  <gmaxwell> interesting that the only thing the avx seems to do is hurt performance on AMD. :)
1392016-05-12T07:52:35  <gmaxwell> the rorx is somewhat faster though.
1402016-05-12T07:54:46  <jonasschnelli> What about the Intel SHA extentension? I Guess sse4 is a different thing.
1412016-05-12T07:54:51  <jonasschnelli> https://software.intel.com/en-us/articles/intel-sha-extensions
1422016-05-12T07:56:15  <jonasschnelli> I have a Xeon E3 and it seems that intels sha extension is only built into E5 and E7 families.
1432016-05-12T07:57:24  <gmaxwell> jonasschnelli: they don't exist yet.
1442016-05-12T07:57:58  <gmaxwell> (they were announced for broadwell then quietly dropped, I assume because the silicon failed)
1452016-05-12T07:58:17  <jonasschnelli> Also my "AArch64 Processor rev 4 (aarch64)" has Features	: fp asimd aes pmull sha1 sha2 crc32
1462016-05-12T07:58:29  <jonasschnelli> mbedtls has some implementations for this: https://github.com/ARMmbed/mbedtls/pull/432/files
1472016-05-12T08:02:38  <jonasschnelli> After this: https://github.com/CriticalBlue/mbedtls/wiki it could give a x5 performance boost for SHA256 on ARM with that extension
1482016-05-12T08:02:46  *** molz has quit IRC
1492016-05-12T08:12:54  <GitHub135> [bitcoin] jonasschnelli opened pull request #8046: [Qt][OSX] Fix Cmd-Q / Menu Quit shutdown on OSX (master...2016/05/fix_quit) https://github.com/bitcoin/bitcoin/pull/8046
1502016-05-12T08:13:24  <wumpus> thanks for the benchmark results! and yeah re SHA extensions: I'm trying to target hardware that actually exist in the wild :)
1512016-05-12T08:13:56  <wumpus> the AARCH64 sHA256 extension sounds reasonably interesting though, too bad Odroid C2 doesn't have it
1522016-05-12T08:16:24  <jonasschnelli> Yes. Not really an important thing.
1532016-05-12T08:16:49  <jonasschnelli> But enabling AVX should probably be something we should do.
1542016-05-12T08:16:52  <jonasschnelli> wumpus: Is the implementation directly copied from intel?
1552016-05-12T08:16:58  <wumpus> yes
1562016-05-12T08:18:04  <jonasschnelli> 1.5* performance boost in sha256 for advance vector enabled processors should be something we should try to get in soon.
1572016-05-12T08:18:49  *** gill3s has quit IRC
1582016-05-12T08:18:53  <jonasschnelli> I guess Sandy and Ivy supports it.
1592016-05-12T08:21:33  <wumpus> what you could try is see if it influences sync performance (a matter of adding CSHA256::SetImplementation(CSHA256::Impl::SSE4); in the inititalization)
1602016-05-12T08:22:50  <gmaxwell> s/AVX/SSE4/
1612016-05-12T08:23:18  <jonasschnelli> SSE4 is ~the same performance boost on my Xeon. But right. We should probably go for AVX
1622016-05-12T08:23:25  <sipa> building
1632016-05-12T08:23:54  <gmaxwell> jonasschnelli: AVX is no faster on anything we've tested on and it hurts performance on Wumpus' AMD chip.
1642016-05-12T08:24:10  <jonasschnelli> gmaxwell: arg. Right. Mixed it up.
1652016-05-12T08:24:14  <gmaxwell> :)
1662016-05-12T08:24:24  <wumpus> yes, AVX seems useless
1672016-05-12T08:24:56  <gmaxwell> BlueMatt: can you benchmark this on skylake?
1682016-05-12T08:25:16  <sipa> SHA256_avx,255,0.00398244,0.00399226,0.00398497
1692016-05-12T08:25:16  <sipa> SHA256_basic,175,0.00608169,0.00611341,0.00608469
1702016-05-12T08:25:16  <sipa> SHA256_sse4,255,0.0039705,0.00398195,0.00397209
1712016-05-12T08:25:17  <jonasschnelli> wumpus: so I just pass in a CSHA256::SetImplementation(CSHA256::Impl::SSE4) in init.cpp somewhere?
1722016-05-12T08:25:37  *** gill3s has joined #bitcoin-core-dev
1732016-05-12T08:25:43  <wumpus> jonasschnelli: yes, or alternatively change the default in src/crypto/sha256.cpp
1742016-05-12T08:25:57  <wumpus> sipa: what processor?
1752016-05-12T08:26:14  <sipa> Intel(R) Core(TM) i7-4800MQ, 2.6 GHz
1762016-05-12T08:26:33  <wumpus> thanks
1772016-05-12T08:27:02  <gmaxwell> sipa: thats another haswell.
1782016-05-12T08:27:41  <sipa> ok
1792016-05-12T08:28:38  <midnightmagic> I'm sure there's a reason for it, but is cpu detection and then dual codepaths, or even multiple-compile outputs not an option in the event a cpu family does benefit?
1802016-05-12T08:29:24  <midnightmagic> or has a significant benefit to these features just not been found i guess
1812016-05-12T08:29:29  <jonasschnelli> I could create a bench on a "2.6 GHz Intel Core i7" (guess this is Ivy Bridge) if it would be good to know.
1822016-05-12T08:29:47  <wumpus> midnightmagic: runtime CPU detection is necessary to integrate this, yes
1832016-05-12T08:30:06  *** Guyver2 has joined #bitcoin-core-dev
1842016-05-12T08:30:08  <wumpus> (right now I don't bother as this is just a hack/experiment)
1852016-05-12T08:30:24  *** Cheeseo has quit IRC
1862016-05-12T08:30:53  *** Cheeseo has joined #bitcoin-core-dev
1872016-05-12T08:30:53  *** Cheeseo has joined #bitcoin-core-dev
1882016-05-12T08:30:53  <gmaxwell> midnightmagic: yes, it would be detected. But the test is important, e.g. it looks like we've learned not to use the AVX version even if supported.
1892016-05-12T08:31:00  <wumpus> in any case it's nice that sse4 gives the best speedup; that's the most common
1902016-05-12T08:31:38  * midnightmagic shakes fist at irritating icc dual code pathing which ((iirc) nullified it for commercial dev at prior employer
1912016-05-12T08:33:31  <gmaxwell> well rorx was clearly faster in my benchmarks.
1922016-05-12T08:33:59  <wumpus> but you actually have a cpu that supports it :)
1932016-05-12T08:34:36  <wumpus> oh! you did post your results, I missed that
1942016-05-12T08:34:56  <gmaxwell> I even highlit you. :)
1952016-05-12T08:35:02  <midnightmagic> uh. I have a lemote laptop sitting next to me in a backpack. in the event someone might like me to use it for testing, I'd be cool with helping.
1962016-05-12T08:35:44  <midnightmagic> (after I get it rebuilt)
1972016-05-12T08:38:12  <gmaxwell> wumpus: so does sipa and jonasschnelli.
1982016-05-12T08:38:39  <gmaxwell> They just didn't enable it.
1992016-05-12T08:45:38  <gmaxwell> IIRC rorx was introduced with haswell so it's a couple arch generations old now and pretty widely spread. though I can't say if the modest performance increase is really worth it.
2002016-05-12T08:50:27  <wumpus> ok added all of them to https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accel
2012016-05-12T08:51:04  <wumpus> agreed, at the least we should only select one of the rorx variants, they're so similar in performance
2022016-05-12T08:51:37  <gmaxwell> sipa and jonasschnelli should test the rorx. (esp jonasschnelli since his chip is skylake)
2032016-05-12T08:53:16  *** gill3s has quit IRC
2042016-05-12T08:55:16  *** gill3s has joined #bitcoin-core-dev
2052016-05-12T08:56:40  <jonasschnelli> A simple reindex comparison:
2062016-05-12T08:57:01  <jonasschnelli> Reindex up to block 200'000:
2072016-05-12T08:57:08  <jonasschnelli> SSE4: 389 seconds
2082016-05-12T08:57:15  <jonasschnelli> master: 406 seconds
2092016-05-12T08:58:04  <jonasschnelli> But I guess the SHA256 performance will be mostly "visible" during a synced state
2102016-05-12T08:59:03  <wumpus> at least when larger blocks come into play it may be more indicative, up to 200,000 are mostly easy blocks IIRC
2112016-05-12T08:59:10  <wumpus> but it's a noticable speedup that's good
2122016-05-12T08:59:55  <jonasschnelli> here my bench with rorx:
2132016-05-12T08:59:57  <jonasschnelli> SHA256_avx,351,0.00267656,0.00406031,0.00287071
2142016-05-12T08:59:57  <jonasschnelli> SHA256_basic,191,0.00403945,0.00774813,0.00572075
2152016-05-12T08:59:57  <jonasschnelli> SHA256_rorx,415,0.00223376,0.00340772,0.00260254
2162016-05-12T08:59:57  <jonasschnelli> SHA256_rorx_x8ms,319,0.00224853,0.00372237,0.00329514
2172016-05-12T08:59:57  <jonasschnelli> SHA256_sse4,255,0.00273502,0.00505805,0.00409666
2182016-05-12T09:00:10  *** laurentmt has joined #bitcoin-core-dev
2192016-05-12T09:01:48  *** laurentmt has quit IRC
2202016-05-12T09:03:19  <wumpus> so sse4 139% rorx 173%
2212016-05-12T09:04:25  <jonasschnelli> Looks like...
2222016-05-12T09:05:02  *** gill3s has quit IRC
2232016-05-12T09:06:19  <jonasschnelli> I try now to compare a full reindex with std sha against rorx.
2242016-05-12T09:06:42  <wumpus> is this on the same Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz?
2252016-05-12T09:06:52  <jonasschnelli> Yes.
2262016-05-12T09:07:14  <wumpus> the numbers are fairly different that's why I ask
2272016-05-12T09:07:26  <jonasschnelli> Hmm...
2282016-05-12T09:08:21  <jonasschnelli> sse4 is extremely different.. right.
2292016-05-12T09:08:48  <jonasschnelli> Hmm.. maybe the reindex ran in the background... let me redo it.
2302016-05-12T09:08:59  <wumpus> min and max differences are also huge; possibly the benchmark framework should ignore the first run to 'prime the cache'
2312016-05-12T09:09:40  *** gill3s has joined #bitcoin-core-dev
2322016-05-12T09:09:52  <wumpus> not that precise benchmarks are super-imporant here, it's clear that there is a win to using sse4/rorx
2332016-05-12T09:10:06  <jonasschnelli> SHA1,703,0.00148106,0.00254279,0.00150908
2342016-05-12T09:10:06  <jonasschnelli> SHA256_avx,415,0.00256918,0.00271057,0.00260393
2352016-05-12T09:10:06  <jonasschnelli> SHA256_basic,287,0.00377643,0.00395856,0.00385546
2362016-05-12T09:10:06  <jonasschnelli> SHA256_rorx,479,0.00214249,0.00227334,0.00217936
2372016-05-12T09:10:06  <jonasschnelli> SHA256_rorx_x8ms,479,0.00212789,0.00233448,0.00219144
2382016-05-12T09:10:06  <jonasschnelli> SHA256_sse4,383,0.00263,0.00277644,0.00266623
2392016-05-12T09:10:06  <jonasschnelli> SHA512,415,0.00252406,0.00267003,0.0025598
2402016-05-12T09:10:34  <wumpus> that looks better
2412016-05-12T09:10:46  <jonasschnelli> Yes. The reindex was probably running in the background.
2422016-05-12T09:11:08  <jonasschnelli> The latest bench was on a quite system (like the first ones without rorx i have posted)
2432016-05-12T09:14:03  <wumpus> these are comparable: https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accel#intelr-xeonr-cpu-e3-1275-v5--360ghz
2442016-05-12T09:16:54  *** gill3s has quit IRC
2452016-05-12T09:25:43  *** gill3s has joined #bitcoin-core-dev
2462016-05-12T09:31:04  *** xiangfu has quit IRC
2472016-05-12T09:36:01  *** Ginnarr has joined #bitcoin-core-dev
2482016-05-12T09:36:58  *** xiangfu has joined #bitcoin-core-dev
2492016-05-12T09:45:53  <GitHub120> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/69b3a6dd9d9a...5b736ddaa1c1
2502016-05-12T09:45:54  <GitHub120> bitcoin/master fad60b3 MarcoFalke: [qa] Fix bip9-softforks blockstore issue
2512016-05-12T09:45:55  <GitHub120> bitcoin/master 5b736dd Wladimir J. van der Laan: Merge #8041: [qa] Fix bip9-softforks blockstore issue...
2522016-05-12T09:46:05  <GitHub52> [bitcoin] laanwj closed pull request #8041: [qa] Fix bip9-softforks blockstore issue (master...Mf1604-qaBip9Blockstore) https://github.com/bitcoin/bitcoin/pull/8041
2532016-05-12T09:46:30  <GitHub57> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5b736ddaa1c1...2efe38b8323c
2542016-05-12T09:46:31  <GitHub57> bitcoin/master 3262316 Chirag Davé: fReopenDebugLog and fRequestShutdown should be type sig_atomic_t...
2552016-05-12T09:46:33  <GitHub57> bitcoin/master 2efe38b Wladimir J. van der Laan: Merge #8004: signal handling: fReopenDebugLog and fRequestShutdown should be type sig_atomic_t...
2562016-05-12T09:46:41  <GitHub29> [bitcoin] laanwj closed pull request #8004: signal handling: fReopenDebugLog and fRequestShutdown should be type sig_atomic_t (master...fix_signal_handler) https://github.com/bitcoin/bitcoin/pull/8004
2572016-05-12T09:50:12  *** MarcoFalke_ has joined #bitcoin-core-dev
2582016-05-12T09:52:23  *** slackircbridge has quit IRC
2592016-05-12T09:53:37  *** slackircbridge has joined #bitcoin-core-dev
2602016-05-12T09:56:41  <GitHub124> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2efe38b8323c...7c8558da362f
2612016-05-12T09:56:41  <GitHub124> bitcoin/master 8b0e497 Tyler Hardin: Qt: Add option to hide the system tray icon...
2622016-05-12T09:56:42  <GitHub124> bitcoin/master 7c8558d Wladimir J. van der Laan: Merge #8006: Qt: Add option to disable the system tray icon...
2632016-05-12T09:56:51  <GitHub140> [bitcoin] laanwj closed pull request #8006: Qt: Add option to disable the system tray icon (master...disable-tray) https://github.com/bitcoin/bitcoin/pull/8006
2642016-05-12T10:01:19  *** gill3s has quit IRC
2652016-05-12T10:08:06  *** gill3s has joined #bitcoin-core-dev
2662016-05-12T10:13:15  <jonasschnelli> wumpus:do you have a tray icon menu on you Ubuntu?
2672016-05-12T10:14:02  <wumpus> yes, but it's messed up (ends up in the lower left of my screen), a known (upstream) issue with qt5 and ubuntu 14.04, so I'm thankful for the option to disable it
2682016-05-12T10:16:40  <wumpus> oh you mean if I can reproduce #8040 on ubuntu? I'll try
2692016-05-12T10:18:27  <wumpus> no, I can't: the tray icon only appears after the main window shows
2702016-05-12T10:19:04  <wumpus> it's not there during the splash screen
2712016-05-12T10:19:28  <wumpus> this would be an issue if we had a "launcher icon menu"
2722016-05-12T10:19:45  <wumpus> as the icon in the launcher appears as soon as the application loads
2732016-05-12T10:20:05  <jonasschnelli> wumpus: check https://github.com/bitcoin/bitcoin/issues/8043
2742016-05-12T10:20:10  <wumpus> then again that requires linking against ubuntu-specific libraries, so little chance
2752016-05-12T10:20:15  <jonasschnelli> I have this issue in 14.04 and 16.04
2762016-05-12T10:20:35  <MarcoFalke_> fedora core works fine
2772016-05-12T10:20:49  <wumpus> hmm, no I never had that problem
2782016-05-12T10:20:53  <MarcoFalke_> self-compiled, shows the tray icon after start
2792016-05-12T10:21:45  <wumpus> I've had this issue: https://github.com/bitcoin/bitcoin/issues/4826 and this issue: https://github.com/bitcoin/bitcoin/issues/5260
2802016-05-12T10:21:56  <wumpus> lots of fun with qt and the tray icon
2812016-05-12T10:22:18  <wumpus> the former doesn't seem to happen anymore though, so I think it was fixed upstream
2822016-05-12T10:22:51  <wumpus> the latter only happens with self-compiled bitcoin-qt against the system qt5, whichi s ancient
2832016-05-12T10:23:12  <wumpus> (5.2.1)
2842016-05-12T10:23:32  <wumpus> in any case not worrying. The missing menu is strange
2852016-05-12T10:24:01  <wumpus> adding the hide tray icon option is a good start, maybe at some point in the future it should be the default, too much trouble with it
2862016-05-12T10:30:58  *** gill3s has quit IRC
2872016-05-12T10:31:48  <jonasschnelli> Yes. That's what I was thinking. Though, the menu itself can be helpful. But the global menu space problem and the issues we always see with the tray menu make me think so.
2882016-05-12T10:32:29  *** fengling has quit IRC
2892016-05-12T10:32:51  *** PaulCapestany has quit IRC
2902016-05-12T10:32:56  *** fengling has joined #bitcoin-core-dev
2912016-05-12T10:34:08  <wumpus> the right way to do this on ubuntu would be the 'launcher menu' route. But due to the practical concern with distributing GUI binaries on linux that'd only work, at most, for the ppa as that is custom-built for ubuntu
2922016-05-12T10:34:10  *** PaulCapestany has joined #bitcoin-core-dev
2932016-05-12T10:38:48  <wumpus> in any case I'll try on ubuntu 16.04 too and see if I can reproduce 8043
2942016-05-12T10:42:36  *** fengling has quit IRC
2952016-05-12T10:43:59  *** fengling has joined #bitcoin-core-dev
2962016-05-12T10:53:07  <jonasschnelli> wumpus: thanks.
2972016-05-12T11:01:12  *** achow101 has joined #bitcoin-core-dev
2982016-05-12T11:14:26  <GitHub176> [bitcoin] MarcoFalke opened pull request #8047: [qa] test_framework: Set wait-timeout for bitcoind procs (master...Mf1605-qaUtilTimeout) https://github.com/bitcoin/bitcoin/pull/8047
2992016-05-12T11:16:06  <GitHub130> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c8558da362f...169d379c9835
3002016-05-12T11:16:06  <GitHub130> bitcoin/master 34ebceb Jonas Schnelli: [Qt][OSX] Fix Cmd-Q / Menu Quit shutdown on OSX
3012016-05-12T11:16:07  <GitHub130> bitcoin/master 169d379 Jonas Schnelli: Merge #8046: [Qt][OSX] Fix Cmd-Q / Menu Quit shutdown on OSX...
3022016-05-12T11:16:15  <GitHub15> [bitcoin] jonasschnelli closed pull request #8046: [Qt][OSX] Fix Cmd-Q / Menu Quit shutdown on OSX (master...2016/05/fix_quit) https://github.com/bitcoin/bitcoin/pull/8046
3032016-05-12T11:17:55  *** MarcoFalke_ has quit IRC
3042016-05-12T11:26:11  *** cryptapus has joined #bitcoin-core-dev
3052016-05-12T11:26:11  *** cryptapus has joined #bitcoin-core-dev
3062016-05-12T11:32:00  *** Ginnarr has quit IRC
3072016-05-12T11:49:57  *** fengling has quit IRC
3082016-05-12T11:50:29  *** gill3s has joined #bitcoin-core-dev
3092016-05-12T11:51:22  *** molz has joined #bitcoin-core-dev
3102016-05-12T11:52:42  <GitHub194> [bitcoin] laanwj opened pull request #8048: doc: Remove outdated qt4 install information from README.md (master...2016_05_doc_noqt4) https://github.com/bitcoin/bitcoin/pull/8048
3112016-05-12T11:58:17  *** murch has joined #bitcoin-core-dev
3122016-05-12T12:11:05  *** gill3s has quit IRC
3132016-05-12T12:11:38  *** gill3s has joined #bitcoin-core-dev
3142016-05-12T12:16:27  *** molz has quit IRC
3152016-05-12T12:16:45  *** molz has joined #bitcoin-core-dev
3162016-05-12T12:23:37  *** murch1 has joined #bitcoin-core-dev
3172016-05-12T12:24:10  *** jtimon has joined #bitcoin-core-dev
3182016-05-12T12:25:08  *** murch has quit IRC
3192016-05-12T12:27:33  <GitHub159> [bitcoin] laanwj opened pull request #8049: Expose information on whether transaction relayed is enabled in `getnetwork` (master...2016_05_rpc_relaytxes) https://github.com/bitcoin/bitcoin/pull/8049
3202016-05-12T12:28:07  <GitHub116> [bitcoin] laanwj closed pull request #7841: Expose information on whether transaction relayed is enabled in getnetwork (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7841
3212016-05-12T12:32:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3222016-05-12T12:43:47  *** xiangfu has quit IRC
3232016-05-12T12:45:26  *** xiangfu has joined #bitcoin-core-dev
3242016-05-12T13:07:41  *** gill3s has quit IRC
3252016-05-12T13:08:18  *** gill3s has joined #bitcoin-core-dev
3262016-05-12T13:10:13  *** CubicEarth has quit IRC
3272016-05-12T13:10:28  *** CubicEarth has joined #bitcoin-core-dev
3282016-05-12T13:11:43  *** CubicEarth has quit IRC
3292016-05-12T13:12:17  *** CubicEarth has joined #bitcoin-core-dev
3302016-05-12T13:20:22  *** CubicEarth has quit IRC
3312016-05-12T13:20:35  *** CubicEarth has joined #bitcoin-core-dev
3322016-05-12T13:37:53  *** Chris_Stewart_5 has quit IRC
3332016-05-12T13:39:55  *** fengling has joined #bitcoin-core-dev
3342016-05-12T13:40:30  *** TomMc has joined #bitcoin-core-dev
3352016-05-12T13:41:47  *** zooko has quit IRC
3362016-05-12T13:44:36  *** fengling has quit IRC
3372016-05-12T13:47:39  *** CubicEarth has quit IRC
3382016-05-12T13:48:15  *** CubicEarth has joined #bitcoin-core-dev
3392016-05-12T13:50:05  <BlueMatt> gmaxwell: still need it benchmarked?
3402016-05-12T13:50:32  <gmaxwell> BlueMatt: we got skylake numbers from jonasschnelli
3412016-05-12T13:51:51  <BlueMatt> kk
3422016-05-12T13:54:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3432016-05-12T13:59:11  *** BonyM has quit IRC
3442016-05-12T13:59:58  *** gill3s has quit IRC
3452016-05-12T14:01:50  *** BonyM has joined #bitcoin-core-dev
3462016-05-12T14:02:00  *** MarcoFalke has joined #bitcoin-core-dev
3472016-05-12T14:14:07  *** Giszmo has joined #bitcoin-core-dev
3482016-05-12T14:28:53  <jonasschnelli> wumpus: benchmark results of full reindex up to height 400'000
3492016-05-12T14:29:08  <jonasschnelli> master, std sha: 8'431 seconds
3502016-05-12T14:29:13  <jonasschnelli> rorx: 7'836
3512016-05-12T14:30:41  *** xiangfu has quit IRC
3522016-05-12T14:35:36  *** xiangfu has joined #bitcoin-core-dev
3532016-05-12T14:37:34  <instagibbs> jonasschnelli, what is this line doing? https://github.com/bitcoin/bitcoin/pull/8035/files#diff-fcc78df4b7178e5b09f83f38196fef8bR59
3542016-05-12T14:37:39  <instagibbs> I suppose I don't get the serialization code well enough
3552016-05-12T14:38:22  *** G1lius has joined #bitcoin-core-dev
3562016-05-12T14:46:20  *** paveljanik has joined #bitcoin-core-dev
3572016-05-12T14:48:37  *** laurentmt has joined #bitcoin-core-dev
3582016-05-12T14:48:43  *** laurentmt has quit IRC
3592016-05-12T14:52:38  *** Guyver2 has quit IRC
3602016-05-12T14:59:21  *** CubicEarth has quit IRC
3612016-05-12T14:59:33  *** CubicEarth has joined #bitcoin-core-dev
3622016-05-12T15:09:16  *** MarcoFalke has quit IRC
3632016-05-12T15:10:29  *** earlest has joined #bitcoin-core-dev
3642016-05-12T15:13:34  *** muuqwaul has quit IRC
3652016-05-12T15:15:16  <jonasschnelli> instagibbs: i think this line is not required. I guess I copied this from another class. Will have a look soon.
3662016-05-12T15:15:21  *** zooko has joined #bitcoin-core-dev
3672016-05-12T15:15:35  <instagibbs> ok, that's my only ? left. Thanks
3682016-05-12T15:15:54  <luke-jr> it's doing something there
3692016-05-12T15:16:07  <luke-jr> nVersion is the method param, not the class var
3702016-05-12T15:16:17  <luke-jr> I think READWRITE uses it?
3712016-05-12T15:16:37  <luke-jr> definitely needs better docs
3722016-05-12T15:16:44  <instagibbs> ... what
3732016-05-12T15:16:54  <luke-jr> +    inline void SerializationOp(Stream& s, Operation ser_action, int nType, int nVersion)
3742016-05-12T15:16:55  <instagibbs> oh
3752016-05-12T15:16:56  <instagibbs> right
3762016-05-12T15:17:41  <luke-jr> I suggest renaming one of the nVersions
3772016-05-12T15:17:48  <luke-jr> as-is, this is obfuscated code
3782016-05-12T15:18:04  <instagibbs> agreed
3792016-05-12T15:18:06  <jonasschnelli> Yes. Will rename it.
3802016-05-12T15:18:35  <jonasschnelli> I think I took it 1:1 from CKeyMetadata
3812016-05-12T15:21:18  *** zooko` has joined #bitcoin-core-dev
3822016-05-12T15:22:04  *** zooko has quit IRC
3832016-05-12T15:28:38  *** zooko`` has joined #bitcoin-core-dev
3842016-05-12T15:30:07  *** zooko` has quit IRC
3852016-05-12T15:30:33  *** BashCo has quit IRC
3862016-05-12T15:31:12  *** BashCo has joined #bitcoin-core-dev
3872016-05-12T15:35:19  *** BashCo has quit IRC
3882016-05-12T15:43:55  *** fengling has joined #bitcoin-core-dev
3892016-05-12T15:44:48  *** laurentmt has joined #bitcoin-core-dev
3902016-05-12T15:47:56  *** fengling has quit IRC
3912016-05-12T16:04:01  *** bysherper has joined #bitcoin-core-dev
3922016-05-12T16:06:42  *** CubicEarth has quit IRC
3932016-05-12T16:07:04  *** earlest has quit IRC
3942016-05-12T16:10:15  *** zooko`` has quit IRC
3952016-05-12T16:13:53  *** laurentmt has quit IRC
3962016-05-12T16:23:48  *** xiangfu has quit IRC
3972016-05-12T16:28:05  *** earlest has joined #bitcoin-core-dev
3982016-05-12T16:31:04  *** bysherper has quit IRC
3992016-05-12T16:35:03  *** Don_John has joined #bitcoin-core-dev
4002016-05-12T16:44:42  *** fengling has joined #bitcoin-core-dev
4012016-05-12T16:49:36  *** fengling has quit IRC
4022016-05-12T16:58:13  *** zooko has joined #bitcoin-core-dev
4032016-05-12T16:58:25  *** kadoban has joined #bitcoin-core-dev
4042016-05-12T16:59:10  *** PRab_ has joined #bitcoin-core-dev
4052016-05-12T17:01:52  *** G1lius has quit IRC
4062016-05-12T17:02:41  *** cryptapus_ has joined #bitcoin-core-dev
4072016-05-12T17:03:04  *** PRab has quit IRC
4082016-05-12T17:03:12  *** PRab_ is now known as PRab
4092016-05-12T17:04:44  *** PRab has quit IRC
4102016-05-12T17:05:09  *** PRab has joined #bitcoin-core-dev
4112016-05-12T17:05:30  *** cryptapus_ has quit IRC
4122016-05-12T17:05:41  *** cryptapus_ has joined #bitcoin-core-dev
4132016-05-12T17:05:42  *** cryptapus_ has joined #bitcoin-core-dev
4142016-05-12T17:05:46  *** cryptapus has quit IRC
4152016-05-12T17:06:52  *** PRab_ has joined #bitcoin-core-dev
4162016-05-12T17:09:45  *** PRab has quit IRC
4172016-05-12T17:09:54  *** PRab_ is now known as PRab
4182016-05-12T17:11:42  *** PRab_ has joined #bitcoin-core-dev
4192016-05-12T17:15:00  *** PRab_ is now known as PRab
4202016-05-12T17:22:27  *** PRab has quit IRC
4212016-05-12T17:27:37  *** TomMc has quit IRC
4222016-05-12T17:28:54  *** BashCo has joined #bitcoin-core-dev
4232016-05-12T17:41:07  *** TomMc has joined #bitcoin-core-dev
4242016-05-12T17:42:08  *** cryptapus_ is now known as cryptapus
4252016-05-12T17:55:27  *** jcorgan has joined #bitcoin-core-dev
4262016-05-12T17:59:22  *** Guyver2 has joined #bitcoin-core-dev
4272016-05-12T18:14:24  *** Chris_Stewart_5 has quit IRC
4282016-05-12T18:17:27  <wumpus> jonasschnelli: nice, that's quite an improvement
4292016-05-12T18:18:11  <jonasschnelli> wumpus: Yes. I guess most reindex work in ECDSA and not SHA. So yes. It's an impressive improvement.
4302016-05-12T18:18:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4312016-05-12T18:18:24  <jonasschnelli> I guess during a synced state the improvements are even more visible.
4322016-05-12T18:18:40  <jcorgan> are there still thursday weekly dev meetings here?
4332016-05-12T18:18:46  <wumpus> yes
4342016-05-12T18:18:47  <helo> yes
4352016-05-12T18:19:10  <gmaxwell> not for another 45 minutes.
4362016-05-12T18:19:17  <jcorgan> ah, off by an hour
4372016-05-12T18:21:37  *** zooko has quit IRC
4382016-05-12T18:38:41  *** kadoban has quit IRC
4392016-05-12T18:40:01  *** droark has joined #bitcoin-core-dev
4402016-05-12T18:41:43  <droark> Hi. Question about PR #7972. It adds a new file (qa/rpc-tests/create_cache.py) that creates a cache used, I assume, to assist with parallelizing the qa/rpc-tests code. I don't quite understand this. Can somebody help me out? TIA.
4412016-05-12T18:43:45  *** bysherper has joined #bitcoin-core-dev
4422016-05-12T18:44:00  <jonasschnelli> droark: You might need to ask MarcoFalke. But IIRC, you need to create the cache before you run the script in parallel because you run into the risk of different cache versions...
4432016-05-12T18:44:23  <sdaftuar> jonasschnelli: droark: right, i assume it's to avoid having two jobs try to do it at the same time
4442016-05-12T18:45:45  <droark> Sounds reasonable. What exactly is being cached, though? The results? The runtime environment for each instance? Something else?
4452016-05-12T18:45:49  *** murch1 is now known as murch
4462016-05-12T18:46:01  <sdaftuar> droark: it's a cached blockchain
4472016-05-12T18:46:34  *** earlest has quit IRC
4482016-05-12T18:46:37  <sdaftuar> take a look at initialize_chain in qa/rpc_tests/test_framework/util.py
4492016-05-12T18:47:35  <droark> Ahhh. Thanks! I'll ping Marco and double check the code but it sounds right.
4502016-05-12T18:47:52  *** fengling has joined #bitcoin-core-dev
4512016-05-12T18:48:20  <lclc> Is anyone of the devs who are coming to Zurich arriving the day before (Thursday) ?
4522016-05-12T18:48:40  <sipa> i'll be there on thursday evening
4532016-05-12T18:49:48  <jcorgan> i get there thu evening as well
4542016-05-12T18:49:49  <lclc> That doesn't surprise me :D   I'm asking because I'd like to organize a meetup the evening before so the community also has something from the event :)
4552016-05-12T18:50:03  <jcorgan> well, 6pm at the airport
4562016-05-12T18:51:14  <lclc> Would be cool if someone would give a talk - topic is up to you.   Our meetups are 30-110 people, free to attend, and recorded (www.bitcoinlectures.tv - YT Channel)
4572016-05-12T18:51:41  *** laurentmt has joined #bitcoin-core-dev
4582016-05-12T18:52:37  *** fengling has quit IRC
4592016-05-12T19:00:16  <wumpus> I'm also arriving in zurich thursday evening
4602016-05-12T19:00:20  <sdaftuar> meeting time?
4612016-05-12T19:00:40  <wumpus> #meetingstart
4622016-05-12T19:00:42  <petertodd> yup
4632016-05-12T19:00:44  <wumpus> #startmeeting
4642016-05-12T19:00:44  <lightningbot> Meeting started Thu May 12 19:00:44 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4652016-05-12T19:00:44  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4662016-05-12T19:01:12  <BlueMatt> topics?
4672016-05-12T19:01:37  <wumpus> from last week:
4682016-05-12T19:01:48  <wumpus> add a file bip-0009/assignments.md in the bips repository:  btcdrak made a pull for that
4692016-05-12T19:02:05  <wumpus> discuss testnet activation date on bitcoin-dev mailing list
4702016-05-12T19:02:15  <wumpus> ead bluematt's compact block bip
4712016-05-12T19:02:19  <wumpus> +r
4722016-05-12T19:02:33  *** jannes has quit IRC
4732016-05-12T19:02:59  <wumpus> #link https://github.com/bitcoin/bips/pull/386
4742016-05-12T19:03:30  <wumpus> any other topic proposals?
4752016-05-12T19:03:31  <luke-jr> on that note, it'd be nice if people didn't ACK/NACK bips they are not a listed author of ;)
4762016-05-12T19:04:14  <sipa> was segwit testnet discussed on the ml?
4772016-05-12T19:04:19  <kanzure> luke-jr: please elaborate.
4782016-05-12T19:04:25  <BlueMatt> re: compact block, got good feedback from a few, made some slight tweaks but need to finish tweaks in the coming days, so no need to discuss here, I think?
4792016-05-12T19:05:06  <luke-jr> kanzure: when it comes to a BIP draft, the only ACK/NACK that matters is the Author(s); others posting ACK/NACK just makes me spend time looking at the Author header to confirm I need to ignore it
4802016-05-12T19:05:12  <wumpus> well in the case of #386 I felt I had the right to give my opinion because I was one of the people to come up with the idea last meeting, even though I'm not listed as author
4812016-05-12T19:05:28  <sipa> i guess the question is where BIPs are to be discussed
4822016-05-12T19:05:38  <luke-jr> sipa: bitcoin-dev ML
4832016-05-12T19:05:40  <sipa> and the idea is that that would be the mailinglist
4842016-05-12T19:05:43  <sipa> but...
4852016-05-12T19:05:56  <kanzure> luke-jr: wouldn't NACKs from non-authors still be useful? why should the authors be the only trusted source of updates ? i don't understand.
4862016-05-12T19:06:17  <instagibbs> oh, the compact blocks got a bip#
4872016-05-12T19:06:29  <paveljanik> I don't understand either. If the author dies in accident, we can no longer change the BIP? or what?
4882016-05-12T19:06:30  <morcos> luke-jr: i'd suggest that you just come up with a way to distinguish.   for instance ACK/NACK shoudl be interpreted by the author and the author shoudl say Approved or Ready or something for your knowledge on when to merge
4892016-05-12T19:06:31  <wumpus> I agree that ack/nack isn't very useful, in comparison to more detailed comments
4902016-05-12T19:06:31  <kanzure> luke-jr: i'm willing to believe you're right but you need better reasons yo.
4912016-05-12T19:06:36  *** laurentmt has quit IRC
4922016-05-12T19:06:40  <petertodd> kanzure: if I were author of a BIP an ACK would give me confidence; a NACK could be useful criticism
4932016-05-12T19:06:42  <sipa> paveljanik: an active BIP can't be modified anyway
4942016-05-12T19:06:43  <kanzure> wumpus: right, sure.
4952016-05-12T19:06:48  <luke-jr> kanzure: the BIP is a document by the Author(s). ideally, they should have exclusive merge access for changes, but GitHub doesn't support that
4962016-05-12T19:06:54  <paveljanik> text clarification, etc...
4972016-05-12T19:06:59  <kanzure> okay this is just trivial though, luke-jr isn't going to stop me from ACKing on BIPs i didn't author :)
4982016-05-12T19:07:04  <morcos> sipa: in some cases it should be, if for instance the BIP wording is incorrect ala 34
4992016-05-12T19:07:18  <luke-jr> paveljanik: BIP 1 technically allows me to reassign BIP Author in some cases IIRC
5002016-05-12T19:07:18  <sipa> morcos: yeah - makes sense
5012016-05-12T19:07:39  <jonasschnelli> We should also define a rule how we deal with links to implementations that have implemented the BIP.
5022016-05-12T19:07:48  <sipa> jonasschnelli: yes
5032016-05-12T19:07:53  <jonasschnelli> IMO we should not add any implementation links.
5042016-05-12T19:07:58  <jonasschnelli> (expect of sample impl.)
5052016-05-12T19:08:00  <wumpus> many bips have a list of implementations; what's wrong with that?
5062016-05-12T19:08:08  <jonasschnelli> Its just noisy
5072016-05-12T19:08:12  <sipa> wumpus: in BIP32 there are continuously pull requests to add links
5082016-05-12T19:08:16  <gmaxwell> it gets flooded with spammy updates.
5092016-05-12T19:08:17  <wumpus> I think it can be useful to have e.g. implementations in many languages
5102016-05-12T19:08:18  <jonasschnelli> And we don't control the implementations I guess
5112016-05-12T19:08:20  <sipa> wumpus: which imho function as nothing more than advertizement
5122016-05-12T19:08:26  <kanzure> and then we have to moderate the additions
5132016-05-12T19:08:27  <jonasschnelli> sipa: Yes!
5142016-05-12T19:08:30  <gmaxwell> And if we're not looking at it, we're eventually going to get a malware example BIP32 impl. :)
5152016-05-12T19:08:32  <wumpus> ok...
5162016-05-12T19:08:34  <luke-jr> BIP 2 comments would be a nice place to list implementations, but that was controverisal
5172016-05-12T19:09:07  <jonasschnelli> I could imaging more and more advertising like PR to come up in future.
5182016-05-12T19:09:12  <wumpus> I think the requirement should at least be to point to the code
5192016-05-12T19:09:15  <wumpus> not just the product
5202016-05-12T19:09:15  <paveljanik> so what is the topic now? ;-)
5212016-05-12T19:09:22  <wumpus> to prevent advertizement
5222016-05-12T19:09:32  <kanzure> i think the topic was "feedback about compact block relay BIP things"
5232016-05-12T19:09:50  <jonasschnelli> Which still intersects (a little bit)
5242016-05-12T19:10:13  <jcorgan> it is useful, however, when reading a BIP, to at least get pointed to reference code, but it need not be every implementation that anyone wants to list thereafter
5252016-05-12T19:10:20  <wumpus> I think the topic is how to handle BIP implementations, which is as good a topic as anything
5262016-05-12T19:10:48  <wumpus> but then you get the fight about what is reference code and what is not
5272016-05-12T19:10:58  <jonasschnelli> Links are always difficult. You need to check them... then what if a link diverges from the BIP specification?
5282016-05-12T19:11:07  <jonasschnelli> Do we check it?
5292016-05-12T19:11:08  <wumpus> in some cases it's clear if the BIP author wrote code themselves
5302016-05-12T19:11:13  <kanzure> yeah another threat vector is someone selling their github account in the future
5312016-05-12T19:11:17  <kanzure> and then a BIP links to someone's github
5322016-05-12T19:11:21  <jonasschnelli> Yes. These are the link we should keep there...
5332016-05-12T19:11:33  <jcorgan> or the BIP author themselves pick one or more...
5342016-05-12T19:11:38  <gmaxwell> If it's upfront then we can trust the bip author and review process to have had some chance to verify it.
5352016-05-12T19:11:42  <wumpus> yes, I'd say it's up to the BIP author
5362016-05-12T19:11:46  <wumpus> like other changes to the BIP
5372016-05-12T19:11:46  <kanzure> other problem is keeping track of upstream updates like security fixes, oops. anyway, this is a lot of work.
5382016-05-12T19:11:57  <kanzure> we should include hashes of the reference source code, in the BIP text
5392016-05-12T19:11:58  <luke-jr> maybe BIP PRs should be PGP signed
5402016-05-12T19:12:03  <wumpus> this is not something that should be globally decided
5412016-05-12T19:12:16  <gmaxwell> I could see the criteria being different for different BIPs.
5422016-05-12T19:12:19  <jonasschnelli> wumpus: Yes. This makes sense.
5432016-05-12T19:12:20  <kanzure> by hashing the source code we can at least have a way for readers to verify that the source code is still the part we meant to hyperlink to :)
5442016-05-12T19:12:22  <wumpus> gmaxwell: exactly
5452016-05-12T19:12:33  <wumpus> I mean the author of bip32 could say 'enough is enough'
5462016-05-12T19:12:43  <jcorgan> er, link to a URL and commit hash?
5472016-05-12T19:12:44  <wumpus> some other BIPs have far fewer implementations and the author may be happy to see one
5482016-05-12T19:12:48  <gmaxwell> (unfortunately, it's BIP32 that gets 95% of this-- key generation is an especially awkward place for random found on the internet code)
5492016-05-12T19:12:52  <petertodd> my BIP65 links to two separate demo repos that just give some sample code, which is probably something we can generally consider as acceptable (ignoring the issue of more complex implementations that aren't pure demos)
5502016-05-12T19:13:09  <jonasschnelli> I like jcorgan idea to link to sourcecode-only with a commit hash
5512016-05-12T19:13:16  <jonasschnelli> But kinda static.
5522016-05-12T19:13:30  <wumpus> Itend to agree with that. Link to the actual code, not the product
5532016-05-12T19:14:11  <wumpus> not 'blawallet implements bip32', no, *the code linked here shows how we implemented BIP32 in language Z*
5542016-05-12T19:14:29  <sipa> wumpus: agree
5552016-05-12T19:14:29  <luke-jr> +1
5562016-05-12T19:14:33  <petertodd> wumpus: +1
5572016-05-12T19:14:39  <paveljanik> yes
5582016-05-12T19:14:43  <jonasschnelli> ack
5592016-05-12T19:14:49  <wumpus> ok
5602016-05-12T19:14:54  <kanzure> we should review existing bips for source code links that do not include a commit hash. branch names are not OK.
5612016-05-12T19:15:01  <kanzure> i mean, branch names without a commit hash are not OK.
5622016-05-12T19:15:01  <wumpus> other topics?
5632016-05-12T19:15:38  <paveljanik> Revies Jonas' HD - #8035
5642016-05-12T19:15:56  <jonasschnelli> I have a tiny topic proposal that is very into the impl. teretorry..
5652016-05-12T19:16:02  <jonasschnelli> RPC long poll notifications
5662016-05-12T19:16:07  <kanzure> have we received an overview from sipa yet about areas of segwit that he feels should be most thoroughly reviewed
5672016-05-12T19:16:12  <sipa> kanzure: no, sorry
5682016-05-12T19:16:22  <kanzure> can we get 10 volunteers to heckle sipa about this?
5692016-05-12T19:16:23  <sipa> thanks for the reminder
5702016-05-12T19:16:34  <wumpus> #action Revies Jonas' HD - #8035
5712016-05-12T19:16:52  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8035 ... very simple and easy to review
5722016-05-12T19:17:12  <paveljanik> jonasschnelli, can you add some after-merge TODO list there?
5732016-05-12T19:17:18  <jonasschnelli> I'm happy to add some RPC tests...
5742016-05-12T19:17:36  <jonasschnelli> There is no required after-merge PR... thats the nice thing.
5752016-05-12T19:17:49  <jonasschnelli> But most important we should enable flexible bip32 keypath
5762016-05-12T19:17:50  <paveljanik> import, dump... at least...
5772016-05-12T19:17:52  <instagibbs> jonasschnelli, a bit hard to rpc test without import/dump? (perhaps offline discussion)
5782016-05-12T19:18:18  <jonasschnelli> There are concerns with importing single keys into the bip32 wallet...
5792016-05-12T19:18:32  <jonasschnelli> They would not be covered by "a old backup"
5802016-05-12T19:18:44  <wumpus> but that's kind of obvious :)
5812016-05-12T19:18:51  <btcdrak> maybe need a sweep feature.
5822016-05-12T19:19:06  <wumpus> yes, a sweep feature would be nice
5832016-05-12T19:19:09  <jonasschnelli> There are plenty of possible features...
5842016-05-12T19:19:24  <jonasschnelli> But because of the lack of reviewers,.. we need babysteps
5852016-05-12T19:19:28  <sipa> let's not discuss all possible features
5862016-05-12T19:19:29  <luke-jr> sweep would be nice, but non-trivial (currently no way to iterate over the UTXO set I think)
5872016-05-12T19:19:38  <sipa> just what is necessary to work and test
5882016-05-12T19:19:38  <jonasschnelli> agree with sipa.
5892016-05-12T19:19:46  <jonasschnelli> Just review and ack it! :P
5902016-05-12T19:19:48  <luke-jr> so what about RPC longpoll?
5912016-05-12T19:19:49  <wumpus> I agree
5922016-05-12T19:19:58  <sipa> if import/export is necessary for testing, then maybe some functionality for that is warranted
5932016-05-12T19:20:00  <wumpus> scope creep agian
5942016-05-12T19:20:23  <instagibbs> well, it only came up due to testing
5952016-05-12T19:21:10  <wumpus> luke-jr: https://github.com/bitcoin/bitcoin/pull/7949
5962016-05-12T19:21:19  <jonasschnelli> RPC long poll would would allow remote GUI and remote wallet with a very easy setup. IMO it could allow third party developers to write simple remote GUIS, web-frontends, etc.
5972016-05-12T19:22:07  <jonasschnelli> I would even say RPC long poll has more potential then ZMQ for core.
5982016-05-12T19:22:10  <wumpus> I'm kind of divided on the notification thing to be honest - I'd prefer to stick to only one notification mechanism in bitcoin core (apart from the silly -Xnotify), and somehow zmq got a precedent there
5992016-05-12T19:22:41  <luke-jr> calling pollnotifications myself seems like it would disrupt an application relying on it?
6002016-05-12T19:22:45  <jonasschnelli> I also don't like multiple notification channels.
6012016-05-12T19:22:49  <luke-jr> ie, we need channels
6022016-05-12T19:22:56  <jonasschnelli> But how would you connect a remote GUI over the internet...
6032016-05-12T19:23:03  <luke-jr> wumpus: zmq is crazy though :<
6042016-05-12T19:23:16  <luke-jr> also note we already have longpolling
6052016-05-12T19:23:17  <wumpus> yes it should definitely have multiple channels, the current code supports only one client
6062016-05-12T19:23:27  <jonasschnelli> wumpus: no
6072016-05-12T19:23:28  <wumpus> luke-jr: where were you to NACK zmq when it was added?
6082016-05-12T19:23:33  <jcorgan> i'm happy to look at improving zmq
6092016-05-12T19:23:34  <luke-jr> jonasschnelli: no RPC over internet ever :<
6102016-05-12T19:23:35  <jonasschnelli> I have added support for <n> clients
6112016-05-12T19:23:50  <luke-jr> wumpus: just because zmq is crazy doesn't mean optional ZMQ support should be excluded ..
6122016-05-12T19:23:50  <jonasschnelli> RPC over internet over a reverse proxy is a wide use pratice.
6132016-05-12T19:23:55  <wumpus> (I don't think zmq is necessarily crazy)
6142016-05-12T19:24:04  <jtimon> sorry, what are the complaints with zmq? it is optional anyway
6152016-05-12T19:24:18  <wumpus> jtimon: I'm not sure either, it seems to be fashionable to complain about it
6162016-05-12T19:24:21  <luke-jr> jtimon: it's not optional if it is an excuse to exclude other systems
6172016-05-12T19:24:32  <luke-jr> zmq breaks protocol compatibility for minor bumps
6182016-05-12T19:24:34  <jonasschnelli> Working towards decoupling of the GUI and the wallet requires well defined channels/APIs
6192016-05-12T19:24:39  <luke-jr> ie, 4.1 won't work with 4.0 right
6202016-05-12T19:25:00  <jonasschnelli> ZMQ would require a tunnel (VPN, stunnel, etc.).
6212016-05-12T19:25:06  <luke-jr> also see all the Elements functionary problems due to ZMQ
6222016-05-12T19:25:14  <jcorgan> ZMQ 4.x is implementing CurveCP
6232016-05-12T19:25:18  <jtimon> I think it's a wonderful tool I would like to use more (although maybe the fact that its creator rewrote it completely in nanomsg may indeed indicate that some parts of zmq have become too complex)
6242016-05-12T19:25:20  <wumpus> zmq is basically only useful for local system, but so is RPC, it's not meant to be used over the internet
6252016-05-12T19:25:45  <jcorgan> see comment about curvecp
6262016-05-12T19:25:54  <wumpus> if you write tunneling for RPC - why not tunnel the notifications too?
6272016-05-12T19:26:00  <jonasschnelli> I just think Core users would love to have a GUI/wallet-frontend that can run on a different machine.
6282016-05-12T19:26:11  <jcorgan> http://curvezmq.org/
6292016-05-12T19:26:16  <jtimon> wumpus: exactly, it's for your intranet or at most inside a vpn (although I haven't tried that myself)
6302016-05-12T19:26:19  <luke-jr> jonasschnelli: yes, for years now that has been desirable
6312016-05-12T19:26:25  <wumpus> jonasschnelli: I agree, but does that need RPC notifications?
6322016-05-12T19:26:28  <jonasschnelli> wumpus: RPC does work extremly well in reverse-proxy mode.
6332016-05-12T19:26:30  <wumpus> jonasschnelli: what would you use it for?
6342016-05-12T19:26:46  <luke-jr> wumpus: right now it requires polling
6352016-05-12T19:26:51  <wumpus> e.g. to get notification of transactions/blocks the P2P protocol works fine
6362016-05-12T19:26:53  <jonasschnelli> Look at rtorrent or any other RPC daemon software.
6372016-05-12T19:27:32  <jonasschnelli> Polling is extremely inefficient. Long polling would allow clients to get "realtime" events while not require any other dependencies...
6382016-05-12T19:27:37  <jonasschnelli> And the code changes are tiny...
6392016-05-12T19:27:37  <wumpus> yes, agreed jonasschnelli
6402016-05-12T19:27:47  <wumpus> yes the code changes are tiny
6412016-05-12T19:28:09  <jonasschnelli> You could setup a save and secure remote bitcoind with a single apache/nginx config.
6422016-05-12T19:28:18  <wumpus> but I'm a bit afraid the same will happen as with REST, people will want to pile up things on top, and now for every notification people will want zmq and rpc longpull support
6432016-05-12T19:28:19  <jonasschnelli> Now do the same with ZMQ notifications... :)
6442016-05-12T19:28:47  <wumpus> just like people want every possible data item both through RPC and REST
6452016-05-12T19:29:00  <sipa> well ZMQ/P2P are suboptimal to write a remote GUI, as you can't filter for just wallet transactions
6462016-05-12T19:29:03  <wumpus> I believe thatthere is value to  keeping core limited to one interface
6472016-05-12T19:29:07  <luke-jr> wumpus: I don't see why this is a problem
6482016-05-12T19:29:10  <jonasschnelli> Yes. If i had a blank paper. I would drop ZMQ and REST in favor or RPC longpoll and the normal RPC.
6492016-05-12T19:29:32  <jcorgan> longpoll does indeed solve some of my original motivation for adding ZMQ
6502016-05-12T19:29:32  <sipa> jonasschnelli: i think you're biased because you're only thinking about one use case
6512016-05-12T19:29:37  <wumpus> well my iniitial idea for notifications was also something like longpoll, or a streaming socket
6522016-05-12T19:29:41  <wumpus> then a proxy from that to zmq
6532016-05-12T19:29:44  <wumpus> but zmq was first
6542016-05-12T19:30:05  <luke-jr> zmq is optional
6552016-05-12T19:30:15  <luke-jr> someone shouldn't need to install zmq for notifications
6562016-05-12T19:30:17  <jtimon> zmq's req/rep could replace both rpc and rest
6572016-05-12T19:30:19  <jonasschnelli> There is one big advantage of RPC long polling...
6582016-05-12T19:30:26  <jonasschnelli> you can have private notifications...
6592016-05-12T19:30:31  <jonasschnelli> secured behind auth
6602016-05-12T19:30:34  <wumpus> do we want private notifications?
6612016-05-12T19:30:35  <jonasschnelli> Like a new relevant wallet tx comes in
6622016-05-12T19:30:43  <sipa> wumpus: for a remote wallet gui you do
6632016-05-12T19:30:52  <jonasschnelli> It would be on the same level then the RPC security...
6642016-05-12T19:30:56  <jonasschnelli> just instead of poll you can have push
6652016-05-12T19:31:06  <wumpus> connect a remote wallet GUI through RPC?
6662016-05-12T19:31:10  <wumpus> wasn't RPC meant to be for local usage?
6672016-05-12T19:31:15  <jonasschnelli> I would not add this over ZMQ because of the unknown risks
6682016-05-12T19:31:20  <luke-jr> jonasschnelli: btw FYI https://en.bitcoin.it/wiki/Wallet_protocol
6692016-05-12T19:31:32  <jonasschnelli> wumpus: that is an argument.
6702016-05-12T19:31:33  <wumpus> I think the idea was to attach a *wallet*, not a wallet GUI
6712016-05-12T19:31:47  <wumpus> the wallet needs to be split from the core
6722016-05-12T19:31:58  <luke-jr> a wallet can be attached over p2p fine
6732016-05-12T19:32:01  <jonasschnelli> Another solution would be to provide a tiny daemon that would interact between core <-> remote GUI/wallet.
6742016-05-12T19:32:15  <wumpus> I'd prefer for core to handle semi-public data, then have a more restricted wallet
6752016-05-12T19:32:17  <jonasschnelli> But that tiny daemon would speak RPC with the outside/internet.
6762016-05-12T19:32:20  <luke-jr> ideally we should have node <-> wallet <-> GUI
6772016-05-12T19:32:47  <wumpus> luke-jr: yes
6782016-05-12T19:32:51  <jonasschnelli> luke-jr: But how would you see the communication channel between wallet <> GUI?
6792016-05-12T19:32:57  <jcorgan> another motivation for adding ZMQ was to allow bitcoind to be a trusted "border gateway", that spoke P2P and consensus, and then stuff behind it would be very simple ZMQ-based software that didn't need to know all about those things
6802016-05-12T19:33:02  <wumpus> but wallet<->GUI could be a competely different protocol than node<->wallet
6812016-05-12T19:33:02  <jonasschnelli> Needs to be bidirect.
6822016-05-12T19:33:07  <luke-jr> jonasschnelli: see wiki link; or something like what you're doing
6832016-05-12T19:33:15  <jonasschnelli> node <> wallet is probably p2p?
6842016-05-12T19:33:19  <sipa> yes
6852016-05-12T19:33:21  <luke-jr> yes
6862016-05-12T19:33:45  <morcos> node <-> wallet being p2p leaves a lot of missing pieces
6872016-05-12T19:33:46  <wumpus> maybe authentiated P2P
6882016-05-12T19:33:47  <morcos> fee estimation
6892016-05-12T19:33:47  <jonasschnelli> But what direction do we want to go for <wallet> <-> <gui>?
6902016-05-12T19:33:48  <wumpus> as you proposed
6912016-05-12T19:33:55  <wumpus> with some private extensions
6922016-05-12T19:33:59  <sipa> jonasschnelli: up to the wallet
6932016-05-12T19:34:06  <morcos> mempool actions (eviction, how close to top of mempool, whether it was accepted)
6942016-05-12T19:34:12  <jonasschnelli> morcos: fee estimations can be done with authentication/private extensions.
6952016-05-12T19:34:14  <BlueMatt> ehh, lets not layer everything onto p2p extensions
6962016-05-12T19:34:23  <luke-jr> jonasschnelli: XMPP! /s
6972016-05-12T19:34:26  *** d4de has joined #bitcoin-core-dev
6982016-05-12T19:34:38  <jtimon> why people want to remove zmq? I still don't undesrtand
6992016-05-12T19:34:41  <jonasschnelli> sipa: That's why I propose RPC long poll (as a "wallet" feature). :)
7002016-05-12T19:34:55  <sipa> jonasschnelli: i'm not sure our wallet should provide that
7012016-05-12T19:35:01  <sipa> jonasschnelli: at least not at this stage
7022016-05-12T19:35:02  <wumpus> BlueMatt: well if we have a autenticated+encryped P2P protocol, adding private extensions is attractive
7032016-05-12T19:35:27  <wumpus> jtimon: I don't want to remove zmq. But I do think we should have one notification mechanism.
7042016-05-12T19:35:39  <kanzure> notifications over zeromq would be nice
7052016-05-12T19:35:42  <jtimon> wumpus: why not it be zmq?
7062016-05-12T19:35:43  <luke-jr> jtimon: I just want to keep ZMQ as an optional feature, not necessary for this stuff
7072016-05-12T19:35:55  <wumpus> jtimon: I don't want to amintain an endless pile-up of different external notification mechanisms
7082016-05-12T19:36:08  <jonasschnelli> Yes. We don't want that.
7092016-05-12T19:36:10  <jtimon> wumpus: ok, why not use ONLY zmq?
7102016-05-12T19:36:10  <BlueMatt> wumpus: its quite attractive to shove everything into one monolithic protocol, indeed, but I do think there is a lot of value in splitting things out (though I wouldnt be upset if they were logically different code that just happened to have the same on-wire protocol or so)
7112016-05-12T19:36:11  <jcorgan> jtimon: i agree that zmq req/rep and pub/sub could provide the entirety of needed interfaces to bitcoind, but that's an argument lost years ago :)
7122016-05-12T19:36:23  <luke-jr> jtimon: then it's no longer optional
7132016-05-12T19:36:24  <kanzure> unfortunately the simplest private notification stuff that the rest of the community would understand would be.... web hooks. :(
7142016-05-12T19:36:39  <luke-jr> jcorgan: except ZMQ has no protocol compatibility
7152016-05-12T19:36:44  <wumpus> websocket would work
7162016-05-12T19:36:49  <morcos> wumpus: i think we can move towards deprecating some things that we view as redundant.  what we should do now though is decide what would work for a node <-> wallet communication protocol.  b/c that is something we defintiely want.
7172016-05-12T19:36:56  <jtimon> luke-jr: ok, either we have 1, we remove zmq or we make it non-optional
7182016-05-12T19:36:59  <luke-jr> wumpus: websocket doesn't define a protocol
7192016-05-12T19:37:03  <wumpus> but just as well as longpoll
7202016-05-12T19:37:08  <jonasschnelli> websockets have bad security
7212016-05-12T19:37:24  <sipa> wumpus: i think it may be reasonable to say that zmq is for node notifications (which are unauthenticated) and longpoll for wallet notifications
7222016-05-12T19:37:26  <luke-jr> jtimon: if we can only have 1, then IMO zmq can go
7232016-05-12T19:37:30  <wumpus> morcos: what would you propose to deprecate?
7242016-05-12T19:37:33  <jtimon> luke-jr: what do you mean by "protocol compatibility"?
7252016-05-12T19:37:40  <luke-jr> jtimon: but I don't think we should limit to 1
7262016-05-12T19:37:50  <wumpus> sipa: but what jonasschnelli wants is not wallet notifications
7272016-05-12T19:37:51  <luke-jr> jtimon: ZMQ 4.0 can't talk to ZMQ 4.1
7282016-05-12T19:37:53  <jtimon> luke-jr: and IMO, if we only want to have one, zmq should stay
7292016-05-12T19:37:55  <sipa> wumpus: yes it is
7302016-05-12T19:38:01  <wumpus> sipa: he wants the same stuff as is now offered over zmq
7312016-05-12T19:38:08  <jonasschnelli> wumpus sipa: What i want is going toward wallet notifications
7322016-05-12T19:38:11  <morcos> wumpus: well my argument is to first define the right way to do node <-> wallet and then do that (even if it means adding something) and then we can revisit and see what we have that is extraneous
7332016-05-12T19:38:17  <jonasschnelli> But also notifications that could enable a remote GUI
7342016-05-12T19:38:21  <sipa> i don't think so; nothing of what is offered over ZMQ is what you need for a remote wallet GUI
7352016-05-12T19:38:21  <jonasschnelli> (mempool / peers, etc9
7362016-05-12T19:38:38  <jonasschnelli> A Core node GUI on a smartphone....
7372016-05-12T19:38:47  <jonasschnelli> Which can't work over ZMQ
7382016-05-12T19:39:05  <sipa> i think we shouldn't discuss that in the current stage
7392016-05-12T19:39:07  <jcorgan> of course it *could*
7402016-05-12T19:39:15  <jcorgan> but not as it is written today
7412016-05-12T19:39:25  <wumpus> jonasschnelli: how would you protect the RPC connection to the smartphone?
7422016-05-12T19:39:26  <sipa> i don't want my bitcoin core full node software to be accessible by smartphones on the internet, i think
7432016-05-12T19:39:29  <kanzure> jcorgan: how much difference?
7442016-05-12T19:39:34  <wumpus> jonasschnelli: the same tunneling tool could route the notifications from zmq
7452016-05-12T19:39:39  <jcorgan> zmq is a transport
7462016-05-12T19:39:40  <jonasschnelli> wumpus: reverse proxy, SSL auth, mod_security
7472016-05-12T19:39:44  <sipa> except the p2p protocol, which is must provide by necessarily
7482016-05-12T19:39:49  <morcos> jonasschnelli: don't you think we shoudl concentrate on node <-> wallet now?  b/c then different people could build different wallet <-> gui protocols if we wanted.  our core responsiblity is the node
7492016-05-12T19:39:57  <jcorgan> you have to define a protocol/serialization/encapsulation to run over it
7502016-05-12T19:39:59  <luke-jr> jcorgan: except then you need to make sure your ZMQ lib versions match, which is just annoying
7512016-05-12T19:40:15  <jcorgan> you can say that about dozens of other libs
7522016-05-12T19:40:17  <jonasschnelli> morcos: I'm working on node <-> wallet. That's why I'm working on auth/enc. :)
7532016-05-12T19:40:23  <jtimon> jonasschnelli: how can something "not work over ZMQ"? can't you proxy the messages through some other protocol outside of bitcoind once you get the zmq messages?
7542016-05-12T19:40:35  <luke-jr> jcorgan: most protocols are compatible across lib versions
7552016-05-12T19:40:37  <sipa> jtimon: because authentication
7562016-05-12T19:40:37  <jonasschnelli> I don't want to talk SPV over unencrypted channels...
7572016-05-12T19:40:49  <kanzure> unencrypted...?
7582016-05-12T19:40:51  <jcorgan> anyway, if anyone wants to pursue making changes to the current zmq implementation, we can talk in zurich about it
7592016-05-12T19:40:52  <wumpus> wellt he same protocol that offers RPC over the internet needs authentication too
7602016-05-12T19:40:54  <jonasschnelli> jtimon: Sure can you. But can a normal user do that?
7612016-05-12T19:40:57  <wumpus> you have exactly the same problem there
7622016-05-12T19:41:25  <jonasschnelli> I just compared the requirements to setup a remote rtorrent GUI with a possible remote Core node GUI.
7632016-05-12T19:41:46  <wumpus> in any case, I'm not strongly against longpoll RPC notifications
7642016-05-12T19:41:52  <jtimon> jonasschnelli: well, what was your "normal user" using isntead of zmq?
7652016-05-12T19:41:54  <jonasschnelli> And i feal that rpc long polls would result in a easy setup...
7662016-05-12T19:42:14  <sipa> morcos, wumpus, jonasschnelli: i agree node <-> wallet is what we should be talking about first, and the apparent need to add private extensions is a sign of a deeper problem: an SPV wallet without trusted full node will be lacking in features
7672016-05-12T19:42:22  <kanzure> easiest setup for non-core-developers is going to be web hooks :(
7682016-05-12T19:42:36  <kanzure> not rpc
7692016-05-12T19:42:50  <d4de> 0MQ supports GSSAPI and Curve auth, unencrypted?!
7702016-05-12T19:42:54  <wumpus> and indeed, RPC longpoll can be supported without linking against external dependencies
7712016-05-12T19:42:56  <morcos> sipa: good point, but maybe thats a separate problem to solve?
7722016-05-12T19:42:57  <wumpus> which is an advantage
7732016-05-12T19:42:59  <jonasschnelli> </rpc-long-poll-advertizing> I'm happy to keep the PR alive... I'll also try to work on a intermediate script that could -> ZMQ and does -> RPC
7742016-05-12T19:43:17  <sipa> morcos: well if that problem is solved (unsure how...), maybe we don't need private extensions :)
7752016-05-12T19:43:37  <sipa> jonasschnelli: you can't... ZMQ doesn't offer wallet-filtered events
7762016-05-12T19:43:38  <morcos> yes, but it'll always be superior to some degree to have access to a trusted node
7772016-05-12T19:43:44  <instagibbs> sipa, do you mean things like access to mempool, etc?
7782016-05-12T19:43:49  <wumpus> at the least we should make a clear division about *what* should be offered over RPC longpoll and what over zmq and what over (theoretic) P2P extensions
7792016-05-12T19:43:51  <sipa> instagibbs: yes, and fee estimation
7802016-05-12T19:43:51  <morcos> so we shouldn't limit ourselves to things that you can't do without that
7812016-05-12T19:43:52  <jonasschnelli> sipa: you still can talk RPC...
7822016-05-12T19:43:57  <wumpus> so not everything ends up on all three
7832016-05-12T19:44:07  <jonasschnelli> sipa: just the notifications need to be ZMQ to avoid polling..
7842016-05-12T19:44:09  <instagibbs> even if you have access to full node over p2p, that doesn't get you that (maybe that's what you meant)
7852016-05-12T19:44:28  <jonasschnelli> sipa: thats why I think adding long poll would not change the security aspect.
7862016-05-12T19:44:42  <sipa> jonasschnelli: but you don't want to send a ZMQ event for every transaction over the wire... that would consume as much bandwidth as just the p2p protocol
7872016-05-12T19:44:55  <wumpus> adding longpoll to RPC won't change any security aspect
7882016-05-12T19:45:02  <luke-jr> more, since ZMQ is ASCII :P
7892016-05-12T19:45:07  <sipa> luke-jr: wut?
7902016-05-12T19:45:09  <kanzure> rpc thread count exhaustion might change a security aspect
7912016-05-12T19:45:17  <wumpus> (except if it encourages opening up your RPC port to the internet)
7922016-05-12T19:45:20  <jonasschnelli> sipa: Right. Long poll could then be extended to relevant wallet txes.
7932016-05-12T19:45:25  *** d4de has quit IRC
7942016-05-12T19:45:25  <wumpus> kanzure: you need user/pass for that, so only the owner can attack it
7952016-05-12T19:45:37  <wumpus> kanzure: I would be against unauthenticated longpolls, that's for sure
7962016-05-12T19:45:47  <luke-jr> sipa: at least the main protocol design (it transmits binary data as-is, IIRC)
7972016-05-12T19:45:52  <wumpus> kanzure: and if you can authenticate you can do *much* worse things than hold up threads
7982016-05-12T19:45:59  <jtimon> sipa: of course you can filter stuff with zmq, you can do anything with zmq, is "network complete"
7992016-05-12T19:46:17  <jtimon> you may need more processes
8002016-05-12T19:46:23  <sipa> jtimon: that's like saying that x86 asm is better than http, because it can do everything
8012016-05-12T19:46:35  <jonasschnelli> Another + for RPC long poll: no dependencies...
8022016-05-12T19:46:36  <sipa> jtimon: of course you can filter, but the filter would be too late
8032016-05-12T19:46:41  <wumpus> so anyhow: I'd say continue your work jonasschnelli
8042016-05-12T19:46:46  <jtimon> sipa: I really don't undesrtand what you claim can't be done with zmq
8052016-05-12T19:46:46  <kanzure> my zeromq person just left the channel in a huff ("these people are retarded") hah...
8062016-05-12T19:46:53  <jonasschnelli> wumpus: Okay.. I keep the PR warm.
8072016-05-12T19:47:03  <luke-jr> again, we ALREADY have longpolling, so I don't see why make a big deal of it
8082016-05-12T19:47:19  <jtimon> sipa: you want to filter by a set of addresses or something?
8092016-05-12T19:47:19  <jonasschnelli> luke-jr: Yes. It's not a big deal...
8102016-05-12T19:47:32  <sipa> jtimon: we don't want ZMQ to be authenticated, so it can't provide wallet-specific information, which means the ZMQ client will need to do the filtering
8112016-05-12T19:47:40  <wumpus> people seem to have trouble to get zmq to work in practice, maybe if you can provide some easy examples for RPC longpolling then it will be the more popular way to do notifications soon
8122016-05-12T19:47:42  <jonasschnelli> sipa: Agree
8132016-05-12T19:47:49  <sipa> jtimon: which is duplicating logic, because that's something the wallet should do, not the gui
8142016-05-12T19:47:58  <jonasschnelli> wumpus: Okay. I'll add some examples... good point!
8152016-05-12T19:48:02  <wumpus> (I had so much trouble convincing joinmarket to use zmq notifications instead of wacky -notifyX scripts that I just gave u)
8162016-05-12T19:48:11  <luke-jr> LP is really simple. just make a normal request and wait ☺
8172016-05-12T19:48:15  <jonasschnelli> wumpus: hah .. yes. Another +1 for RPC long poll. :)
8182016-05-12T19:48:27  <wumpus> maybe it's the extra dependency, maybe it's unfamiliarity, I don't know.
8192016-05-12T19:48:31  <jonasschnelli> People will call exes on every transaction...
8202016-05-12T19:48:37  <jtimon> sipa: oh, you don't want authenticated connections going through zmq processes...I don't undesrtand why, but ok, that seems to be the piece I was missing
8212016-05-12T19:48:39  <sipa> jtimon: so yes, of course, you can do anything, if you reimplement the wallet in the client, but that was exactly what we were trying to avoid :)
8222016-05-12T19:48:47  <gmaxwell> luke-jr: lots of things time out.
8232016-05-12T19:48:58  <jonasschnelli> gmaxwell: time out doesnt matter
8242016-05-12T19:48:58  <gmaxwell> this discussion seems ratholed.
8252016-05-12T19:49:07  <jonasschnelli> Because you have a queue/state on the server
8262016-05-12T19:49:14  *** fengling has joined #bitcoin-core-dev
8272016-05-12T19:49:15  <wumpus> timeout doesn't matter with longpoll, you can just re-request
8282016-05-12T19:49:19  <jtimon> sipa: no, I would just use some kind of authentication
8292016-05-12T19:49:21  <kanzure> we need more user metric survey data about whehter rpc is really easy for folks. i think all the web app developers only know web hooks and HTTP.
8302016-05-12T19:49:51  <wumpus> kanzure: moving away from JSON-RPC as the main RPC API is out of the question at this stage
8312016-05-12T19:50:02  <wumpus> just too much software and libraries that assume it
8322016-05-12T19:50:07  <sipa> are there other topics?
8332016-05-12T19:50:20  <kanzure> er i did not mean to unintentionally advocate for moving away from json-rpc
8342016-05-12T19:50:52  <wumpus> doesn't seem to be
8352016-05-12T19:51:11  <wumpus> #endmeeting
8362016-05-12T19:51:11  <lightningbot> Meeting ended Thu May 12 19:51:11 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
8372016-05-12T19:51:11  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-12-19.00.html
8382016-05-12T19:51:11  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-12-19.00.txt
8392016-05-12T19:51:11  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-12-19.00.log.html
8402016-05-12T19:51:54  <jcorgan> do we have any grand plans or even wishlists for zurich?
8412016-05-12T19:52:06  <jtimon> kanzure: I did suggest replacing json-rpc with zmq json req/rep, but I knew very few people would consider it seriously
8422016-05-12T19:52:18  <sipa> i'd like to talk about p2p encryption, segwit, signature aggregation, ...
8432016-05-12T19:52:32  <jonasschnelli> Agree with sipa. We could also form groups to directly work on stuff.
8442016-05-12T19:52:57  <sipa> but the overall goal should just be to facillitate improvements that are in the pipeline by meeting in face... whatever those improvements are
8452016-05-12T19:52:59  <kanzure> i would like to do braindumps to get things written down
8462016-05-12T19:53:18  <jonasschnelli> +1 for writing down things...
8472016-05-12T19:53:22  <kanzure> i am good at this
8482016-05-12T19:53:27  <jcorgan> suggest doing as much brainstorming/dumping in advance to not use precious F2F time
8492016-05-12T19:53:55  <kanzure> would like to draw up list of too-often-unspoken proposals to write down more details about
8502016-05-12T19:53:56  *** fengling has quit IRC
8512016-05-12T19:54:09  <sipa> that'd be great
8522016-05-12T19:54:14  <jonasschnelli> I think we should't feel too much pressure. The fact that we are meeting face to face alone is a value.
8532016-05-12T19:54:22  <jcorgan> of course
8542016-05-12T19:54:23  <sipa> agree
8552016-05-12T19:54:37  <jonasschnelli> Even if there is no outcome. It would be a success.
8562016-05-12T19:55:00  <kanzure> some feedback from d4de- he recommends that future bitcoin core meetings shoud have someone that more actively guides discussion, e.g. make things more explicit rather than implicit
8572016-05-12T19:55:07  <wumpus> jtimon: right - there's no deep reason why zmq req/rep wouldn't work for the main RPC API, but it's .... unfamiliar for people, see my comment above about trying to get people to even use zmq for basic notifications
8582016-05-12T19:55:14  <jcorgan> the face time is extremely valuable, just want to make the most of it
8592016-05-12T19:55:17  <kanzure> jonasschnelli: gosh that sounds like one of those unreasonable metrics :) (kidding)
8602016-05-12T19:55:34  <jonasschnelli> kanzure: It's called positiv thinking. :)
8612016-05-12T19:55:35  <wumpus> kanzure: are you volunteering?
8622016-05-12T19:56:01  <jcorgan> so if there are things that can be done ahead of time that don't necessarily need the f2f time, it would make sense to get it out of the way beforehand
8632016-05-12T19:56:05  <kanzure> wumpus: for writing things down? yes. for brainstorming? sure... for meetings, i'll defer to our friendly neighborhod pointy-hair.
8642016-05-12T19:56:06  <jonasschnelli> kanzure: I think wumpus is doing a fantastic job and you easly overmoderate on IRC.
8652016-05-12T19:56:09  <gmaxwell> wumpus: execpt the no stable on the wire format, and no reliable delivery...
8662016-05-12T19:56:43  <jonasschnelli> jcorgan: Agree. You could start a discussion on the bitcoin-core-dev ML?
8672016-05-12T19:56:45  *** belcher has joined #bitcoin-core-dev
8682016-05-12T19:56:48  <kanzure> jonasschnelli: i don't have enough context on many of these topics to correctly guide meetings. so it's not something you should be concerned about. heh.
8692016-05-12T19:56:50  *** mrkent has joined #bitcoin-core-dev
8702016-05-12T19:56:52  <wumpus> gmaxwell: I think you can have reliable delivry over zmq, just not in the way we use it
8712016-05-12T19:56:53  <jtimon> wumpus: yeah, it seems people forgot about socket-like things
8722016-05-12T19:57:10  <wumpus> jtimon: well it's a complete new API to learn
8732016-05-12T19:57:40  <wumpus> jtimon: even if you already know normal socket programming, zmq is like a whole new alien landscape
8742016-05-12T19:57:55  <jonasschnelli> jtimon: RPC long poll require no "real" dependencies, you just aim a http request and wait until you get response.
8752016-05-12T19:58:02  <jcorgan> wumpus: jtimon: people don't seem to grok message based vs. function call based
8762016-05-12T19:58:14  <kanzure> jonasschnelli: that can cause an unintentional DoS against yourself
8772016-05-12T19:58:24  <jonasschnelli> kanzure: explain?
8782016-05-12T19:58:31  <kanzure> rpc thread exhaustion, as mentioned above
8792016-05-12T19:58:31  <jtimon> wumpus: I hadn't used sockets in ages and it was very easy to me (but as said I just use xreq/xrep, push/pull and pub/sub, no dealers or other stuff)
8802016-05-12T19:58:32  <jcorgan> jonasschnelli: i'll make a suggestion on the ML then
8812016-05-12T19:58:41  <jonasschnelli> jcorgan:+1
8822016-05-12T19:59:02  <jonasschnelli> kanzure: no.. you only run the poll http request on a single thread...
8832016-05-12T19:59:15  <jonasschnelli> Only one request in parallel.
8842016-05-12T19:59:18  <kanzure> jonasschnelli: rpcthreads
8852016-05-12T19:59:28  <jonasschnelli> But thats the serverside.
8862016-05-12T19:59:35  <kanzure> yes.. that's still DoSing yourself.
8872016-05-12T19:59:47  <kanzure> you're not enforcing one request in parallel
8882016-05-12T19:59:56  <jtimon> wumpus: but apparently nanomsg simplifies things further removing the context and things like that
8892016-05-12T20:00:01  <wumpus> in principle you don't even need a rpc thread open for a long-poller, if you'd use the event based http, but that's a topic for the far future
8902016-05-12T20:00:10  <jonasschnelli> kanzure: sure. But that would not be different to the "normal" rpc calls?
8912016-05-12T20:00:11  <kanzure> jtimon: in addition to nanomsg, look at nq
8922016-05-12T20:00:24  *** Chris_Stewart_5 has quit IRC
8932016-05-12T20:00:27  <kanzure> jonasschnelli: well, not many of them are meant to be open for a while
8942016-05-12T20:00:43  <jtimon> kanzure: nq? do you have a link?
8952016-05-12T20:00:44  <jonasschnelli> Sure. But you control them. Its secured behind auth.
8962016-05-12T20:01:01  <jonasschnelli> kanzure: No strangers will connect to your RPC.
8972016-05-12T20:01:08  <kanzure> jtimon: actually no :) i think this means i owe you BTC... hah.
8982016-05-12T20:01:10  <wumpus> and if you need multiple long-pollers you can just increase the number of rpc threads anyhow, it's not like we need to support 1000 people in a chat
8992016-05-12T20:01:19  <wumpus> no need to overdesign/overcomplicate
9002016-05-12T20:01:20  <jonasschnelli> Indeed. :)
9012016-05-12T20:01:46  <jtimon> jonasschnelli: you can have an http server with auth that connects "locally" (intranet) to stuff via zmq
9022016-05-12T20:01:49  <kanzure> manual thread management, got it..
9032016-05-12T20:02:01  <luke-jr> we're moving the dev meetings to the p2p network and using longpolling with bitcoin-cli to read the chat? :P
9042016-05-12T20:02:12  <jtimon> jonasschnelli: but yeah, I guess that's one extra step you would be saving
9052016-05-12T20:02:13  <jonasschnelli> jtimon: Yes. Sure. But why the roundtrip when you can have RPC long poll?
9062016-05-12T20:02:15  <kanzure> we don't mention in our docs "don't connect to your bitcoin node from a thousand workers that listen for notifications"
9072016-05-12T20:02:37  <jonasschnelli> jtimon: you don't need the ZMQ dependencies if you want to serve a push not. over http
9082016-05-12T20:02:37  <wumpus> kanzure: some things are common sense, but feel free to add it explicitly
9092016-05-12T20:03:04  <wumpus> kanzure: and for that, zmq is indeed more suited as it has one-to-many broadcast
9102016-05-12T20:03:44  <jtimon> jonasschnelli: of course, strictly speaking "you don't need anything" to do anything, it's the "you can't do X using zmq" that nerves me
9112016-05-12T20:04:30  <jonasschnelli> I think ZMQ is useful....
9122016-05-12T20:04:35  <gmaxwell> jtimon: being excessively pedantic is not productive.
9132016-05-12T20:04:39  <jonasschnelli> Its just pain in the ass to get a notification to a remote end.
9142016-05-12T20:05:39  <jtimon> gmaxwell: sure, I was just misunderstanding some of the "you can't do this with zmq" claims, they were really just "you also need X" or similar things
9152016-05-12T20:05:52  <jtimon> mistery solved
9162016-05-12T20:06:43  * jonasschnelli needs rest and waves goodby...
9172016-05-12T20:08:31  <jtimon> and I'm sorry for being so biased in favor of zmq whenever it's an option for anything, I guess it may equilibrate some other biases against it.
9182016-05-12T20:10:09  *** cryptapus has quit IRC
9192016-05-12T20:14:09  *** BashCo_ has joined #bitcoin-core-dev
9202016-05-12T20:15:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
9212016-05-12T20:16:50  *** BashCo has quit IRC
9222016-05-12T20:17:51  <jcorgan> one suggestion--we seem to be going back and forth between different use cases and different means to accomplish them
9232016-05-12T20:19:38  <jcorgan> i'd rather clarify what all the use cases are first, then see what technology best suits them, then see how that maps to what exists and what doesn't in the client
9242016-05-12T20:21:42  <jcorgan> *best suits each of them
9252016-05-12T20:25:44  <jtimon> jcorgan: that sounds very reasonable
9262016-05-12T20:26:15  <jtimon> analysis first, arch/design decisions later
9272016-05-12T20:34:37  *** droark has quit IRC
9282016-05-12T20:46:15  *** kadoban has joined #bitcoin-core-dev
9292016-05-12T20:47:23  *** kadoban has joined #bitcoin-core-dev
9302016-05-12T20:52:00  *** cryptapus_afk is now known as cryptapus
9312016-05-12T20:52:03  *** cryptapus is now known as cryptapus_afk
9322016-05-12T20:52:06  *** cryptapus_afk is now known as cryptapus
9332016-05-12T21:01:59  *** jcorgan has quit IRC
9342016-05-12T21:12:05  *** kadoban has quit IRC
9352016-05-12T21:12:32  *** kadoban has joined #bitcoin-core-dev
9362016-05-12T21:17:33  *** kadoban has quit IRC
9372016-05-12T21:19:02  *** kadoban has joined #bitcoin-core-dev
9382016-05-12T21:36:46  *** d4de has joined #bitcoin-core-dev
9392016-05-12T21:43:49  *** d4de has quit IRC
9402016-05-12T21:44:09  *** d4de has joined #bitcoin-core-dev
9412016-05-12T21:45:40  *** zooko has joined #bitcoin-core-dev
9422016-05-12T21:52:06  *** fengling has joined #bitcoin-core-dev
9432016-05-12T21:56:57  *** fengling has quit IRC
9442016-05-12T22:00:26  *** AaronvanW has quit IRC
9452016-05-12T22:03:25  *** mrkent has quit IRC
9462016-05-12T22:03:32  *** cryptapus is now known as cryptapus_afk
9472016-05-12T22:04:22  *** mrkent has joined #bitcoin-core-dev
9482016-05-12T22:12:09  *** gabridome has joined #bitcoin-core-dev
9492016-05-12T22:20:15  *** mrkent has quit IRC
9502016-05-12T22:23:42  *** CubicEarth has joined #bitcoin-core-dev
9512016-05-12T22:27:40  *** mrkent has joined #bitcoin-core-dev
9522016-05-12T22:34:53  *** CubicEarth has quit IRC
9532016-05-12T22:37:49  *** gabridome has quit IRC
9542016-05-12T22:39:07  *** BashCo has joined #bitcoin-core-dev
9552016-05-12T22:40:25  *** BashCo_ has quit IRC
9562016-05-12T22:54:35  <BlueMatt> ugh, master is segfaulting trying to call rpc
9572016-05-12T22:54:53  <sipa> BlueMatt: elaborate?
9582016-05-12T22:54:59  <BlueMatt> gdb'ing
9592016-05-12T22:55:07  <sipa> thanks
9602016-05-12T22:55:08  <BlueMatt> but all i did was start and then try to call rpc :(
9612016-05-12T22:57:00  <BlueMatt> oh, false alarm...custom change blew up
9622016-05-12T22:57:04  <BlueMatt> sorry for the noise :/
9632016-05-12T22:57:19  <BlueMatt> fucking 1-line change segfaults :(
9642016-05-12T22:57:41  <sipa> we need a programming language with built-in reed-selomon code
9652016-05-12T22:57:56  <sipa> so that the compiler can correct 1-line errors :p
9662016-05-12T22:58:05  <BlueMatt> heh
9672016-05-12T22:58:22  <gmaxwell> sipa: and updating the code means you need to read all of it?
9682016-05-12T22:58:41  <sipa> gmaxwell: you mean you don't already do that?
9692016-05-12T22:59:16  *** murch has quit IRC
9702016-05-12T23:05:03  *** d4de has quit IRC
9712016-05-12T23:07:34  *** PRab has joined #bitcoin-core-dev
9722016-05-12T23:13:02  *** amiller has quit IRC
9732016-05-12T23:17:43  *** Guest13955 has joined #bitcoin-core-dev
9742016-05-12T23:22:37  *** Guyver2 has quit IRC
9752016-05-12T23:23:12  *** aj has quit IRC
9762016-05-12T23:24:49  *** wangchun has quit IRC
9772016-05-12T23:24:55  *** wangchun has joined #bitcoin-core-dev
9782016-05-12T23:30:36  *** aj has joined #bitcoin-core-dev
9792016-05-12T23:45:18  *** zooko has quit IRC
9802016-05-12T23:50:37  *** TomMc has quit IRC
9812016-05-12T23:55:11  *** fengling has joined #bitcoin-core-dev
9822016-05-12T23:55:44  *** belcher has quit IRC
9832016-05-12T23:59:57  *** fengling has quit IRC