12018-04-19T00:00:02  *** weez17 has quit IRC
  22018-04-19T00:00:47  *** weez17 has joined #bitcoin-core-dev
  32018-04-19T00:01:05  *** grafcaps has joined #bitcoin-core-dev
  42018-04-19T00:05:46  *** promag has quit IRC
  52018-04-19T00:06:08  *** promag has joined #bitcoin-core-dev
  62018-04-19T00:09:01  *** Krellan has quit IRC
  72018-04-19T00:10:07  *** Krellan has joined #bitcoin-core-dev
  82018-04-19T00:12:05  *** jtimon has quit IRC
  92018-04-19T00:24:31  *** jojeyh has quit IRC
 102018-04-19T00:26:30  *** jchysk has joined #bitcoin-core-dev
 112018-04-19T00:36:44  <promag> kallewoof: there is no need to prevent a loop iterating an empty array
 122018-04-19T00:38:02  <kallewoof> promag: Yeah, I was confused. Fixed. :)
 132018-04-19T00:38:15  <promag> cool
 142018-04-19T00:38:47  <promag> I have to test -noincludeconf
 152018-04-19T00:38:53  <promag> didn't thought about that´
 162018-04-19T00:39:19  <kallewoof> Yeah, I didn't think about it either. I think a command line -noincludeconf will actually disable config includeconf. Which.. is good, I think?
 172018-04-19T00:41:50  <kallewoof> No, it seems like -noincludeconf is ignored from command line right now.
 182018-04-19T00:42:13  <promag> really?
 192018-04-19T00:42:38  <kallewoof> It's ignored in bitcoin.conf too. `noincludeconf=1 \n includeconf=relative.conf` will still include relative.conf.
 202018-04-19T00:43:19  <kallewoof> Ah, wait. `includeconf=relative.conf \n noincludeconf=1` will not include relative.conf.
 212018-04-19T00:44:14  *** ProfMac has quit IRC
 222018-04-19T00:44:18  <kallewoof> Not sure this is a useful feature at all, to be honest. (-noincludeconf I mean)
 232018-04-19T00:52:34  <aj> kallewoof: foo=bar nofoo=1 foo=baz --> nofoo clears out bar, but then foo=baz gets put in
 242018-04-19T00:53:39  <aj> kallewoof: -nofoo on the commandline would clear out everything for other options
 252018-04-19T00:54:04  *** drexl has quit IRC
 262018-04-19T00:54:32  <kallewoof> aj: probably because I am loading both kinds manually, but -noincludeconf from cli does not cancel `includeconf=relative.conf` from bitcoin.conf
 272018-04-19T00:54:45  <kallewoof> both kinds = `includeconf` and `[chain].includeconf`
 282018-04-19T00:56:13  <aj> kallewoof: yeah, other options have that taken care of them by the ArgsManager::Get*Arg* functions, you'd have to do it yourself
 292018-04-19T00:57:17  <kallewoof> aj: Gotcha. I think I'll require that `noincludeconf` is not set before doing it, so people can -noincludeconf from command line. Feels buggy otherwise.
 302018-04-19T01:00:24  <kallewoof> promag: I pushed a fix for -noincludeconf
 312018-04-19T01:00:53  <promag> kk
 322018-04-19T01:06:58  *** harrymm has quit IRC
 332018-04-19T01:11:43  *** luke-jr has quit IRC
 342018-04-19T01:14:49  *** Randolf has quit IRC
 352018-04-19T01:19:23  *** harrymm has joined #bitcoin-core-dev
 362018-04-19T01:20:04  *** Emcy has quit IRC
 372018-04-19T01:22:27  *** luke-jr has joined #bitcoin-core-dev
 382018-04-19T01:25:11  *** dgenr8 has quit IRC
 392018-04-19T01:25:23  *** dgenr8 has joined #bitcoin-core-dev
 402018-04-19T01:28:23  *** d_t has joined #bitcoin-core-dev
 412018-04-19T01:32:33  *** Murch has quit IRC
 422018-04-19T01:32:38  *** zigen has joined #bitcoin-core-dev
 432018-04-19T01:35:05  *** Randolf has joined #bitcoin-core-dev
 442018-04-19T01:38:24  *** Randolf has quit IRC
 452018-04-19T01:44:57  *** Emcy has joined #bitcoin-core-dev
 462018-04-19T01:47:02  *** fanquake has joined #bitcoin-core-dev
 472018-04-19T01:47:34  *** promag has quit IRC
 482018-04-19T01:51:35  *** AaronvanW has quit IRC
 492018-04-19T01:51:44  <fanquake> eklitzke Good to know you were just travelling. Thought you might have bailed on Core dev after all the slow review turnaround.
 502018-04-19T02:15:16  *** fanquake has quit IRC
 512018-04-19T02:19:48  *** akaka has joined #bitcoin-core-dev
 522018-04-19T02:21:36  *** grafcaps has quit IRC
 532018-04-19T02:38:14  *** tylevine has joined #bitcoin-core-dev
 542018-04-19T02:45:58  *** Samdney has quit IRC
 552018-04-19T02:46:01  *** tylevine has quit IRC
 562018-04-19T02:46:10  *** tylevine has joined #bitcoin-core-dev
 572018-04-19T02:55:25  *** grafcaps has joined #bitcoin-core-dev
 582018-04-19T03:01:03  *** Randolf has joined #bitcoin-core-dev
 592018-04-19T03:02:11  <bitcoin-git> [bitcoin] tjps opened pull request #13025: Dead code removal (master...tjps_dead_code) https://github.com/bitcoin/bitcoin/pull/13025
 602018-04-19T03:04:11  *** tylevine has quit IRC
 612018-04-19T03:06:52  *** tylevine has joined #bitcoin-core-dev
 622018-04-19T03:10:29  *** Giszmo has quit IRC
 632018-04-19T03:17:54  *** fanquake has joined #bitcoin-core-dev
 642018-04-19T03:18:03  *** jojeyh has joined #bitcoin-core-dev
 652018-04-19T03:19:49  *** Emcy has quit IRC
 662018-04-19T03:21:22  *** fanquake has quit IRC
 672018-04-19T03:26:27  *** Randolf has quit IRC
 682018-04-19T03:29:46  *** zigen has quit IRC
 692018-04-19T03:30:21  *** zigen has joined #bitcoin-core-dev
 702018-04-19T03:32:25  *** Randolf has joined #bitcoin-core-dev
 712018-04-19T03:34:57  *** zigen has quit IRC
 722018-04-19T03:37:32  *** Emcy has joined #bitcoin-core-dev
 732018-04-19T03:56:53  *** tryphe has quit IRC
 742018-04-19T03:57:32  *** tryphe has joined #bitcoin-core-dev
 752018-04-19T04:05:53  *** Randolf has quit IRC
 762018-04-19T04:11:34  *** cryptojanitor has quit IRC
 772018-04-19T04:16:03  *** geezas has joined #bitcoin-core-dev
 782018-04-19T04:29:34  *** zigen has joined #bitcoin-core-dev
 792018-04-19T04:30:50  *** akaka has quit IRC
 802018-04-19T04:37:07  *** contrapumpkin has quit IRC
 812018-04-19T04:40:37  *** akaka has joined #bitcoin-core-dev
 822018-04-19T04:42:30  *** akaka has quit IRC
 832018-04-19T04:42:30  *** Krellan has quit IRC
 842018-04-19T04:43:05  *** Krellan has joined #bitcoin-core-dev
 852018-04-19T04:49:05  *** grafcaps has quit IRC
 862018-04-19T05:19:03  *** Murch has joined #bitcoin-core-dev
 872018-04-19T05:29:05  *** lnostdal has joined #bitcoin-core-dev
 882018-04-19T05:33:45  *** lnostdal has quit IRC
 892018-04-19T05:34:01  *** lnostdal has joined #bitcoin-core-dev
 902018-04-19T05:35:33  *** akaka has joined #bitcoin-core-dev
 912018-04-19T05:39:28  *** akaka has left #bitcoin-core-dev
 922018-04-19T05:42:40  *** arbitrary_guy has quit IRC
 932018-04-19T05:59:36  *** zigen has quit IRC
 942018-04-19T06:00:10  *** zigen has joined #bitcoin-core-dev
 952018-04-19T06:00:22  <kallewoof> aj: I looked at the seen-txns file you sent me. In combination with block data I should be able to extract what I need I think. For starters I'll make the tool that can read current data, then I will nudge you for data, probably. :)
 962018-04-19T06:00:36  *** zigen has joined #bitcoin-core-dev
 972018-04-19T06:06:46  *** zigen has joined #bitcoin-core-dev
 982018-04-19T06:50:07  *** arbitrary_guy has joined #bitcoin-core-dev
 992018-04-19T06:54:41  *** Randolf has joined #bitcoin-core-dev
1002018-04-19T07:01:46  *** arbitrary_guy has quit IRC
1012018-04-19T07:01:47  *** Krellan has quit IRC
1022018-04-19T07:02:14  *** fanquake has joined #bitcoin-core-dev
1032018-04-19T07:02:34  *** Krellan has joined #bitcoin-core-dev
1042018-04-19T07:15:15  *** tylevine has quit IRC
1052018-04-19T07:15:46  *** tylevine has joined #bitcoin-core-dev
1062018-04-19T07:18:58  *** bedo has joined #bitcoin-core-dev
1072018-04-19T07:21:12  <wumpus> kallewoof: TX_CONF (0x03) has 8 bytes reserved for block height - it's good to plan ahead when designing formats, but 80000 years is maybe a bit much :)
1082018-04-19T07:22:44  <wumpus> kallewoof: also please add some header magic, and a format version
1092018-04-19T07:23:52  *** bedo is now known as bedotech
1102018-04-19T07:23:58  <wumpus> kallewoof: especially as the packet types have no framing information of themselves, this means the format is not forward compatible, so readers need to be able to reject newer files
1112018-04-19T07:24:13  <wumpus> (e.g. no way to skip unknown records or fields)
1122018-04-19T07:24:57  <wumpus> (which is a valid decision with regard to storage, but maybe needs to be documented)
1132018-04-19T07:26:24  *** zarez has joined #bitcoin-core-dev
1142018-04-19T07:27:47  *** fanquake has quit IRC
1152018-04-19T07:30:09  *** tylevine has quit IRC
1162018-04-19T07:30:41  *** tylevine has joined #bitcoin-core-dev
1172018-04-19T07:30:47  *** Murch has quit IRC
1182018-04-19T07:31:22  <bedotech> Hi all, currently bitcoin-core what kind of wallet derivation implement? (for example BIP44 and so on...)
1192018-04-19T07:32:01  <wumpus> bip32 hierarchical deterministic wallet
1202018-04-19T07:32:53  <wumpus> not bip44, you can find the implemented bips in doc/bips.md
1212018-04-19T07:33:13  <bedotech> wumpus: thanks a lot
1222018-04-19T07:34:32  *** fanquake has joined #bitcoin-core-dev
1232018-04-19T07:39:14  <fanquake> wumpus looks like #12855 is ready to go now that sipa's nit has been fixed
1242018-04-19T07:39:16  <gribble> https://github.com/bitcoin/bitcoin/issues/12855 | net: Minor accumulated cleanups by tjps · Pull Request #12855 · bitcoin/bitcoin · GitHub
1252018-04-19T07:45:09  *** grafcaps has joined #bitcoin-core-dev
1262018-04-19T07:49:21  *** grafcaps has quit IRC
1272018-04-19T07:51:28  *** crt4 has joined #bitcoin-core-dev
1282018-04-19T07:59:53  *** zigen has quit IRC
1292018-04-19T08:00:25  *** zigen has joined #bitcoin-core-dev
1302018-04-19T08:00:27  <bedotech> i want to build a online service that generate address from extended public key, is better to use backward compatibility P2SH-P2WPKH or i can use direct P2WPKH?
1312018-04-19T08:01:16  <fanquake> bedotech ask in #bitcoin
1322018-04-19T08:01:33  <bedotech> fanquake: thanks!
1332018-04-19T08:01:51  <fanquake> or #bitcoin-dev
1342018-04-19T08:04:21  *** zigen has quit IRC
1352018-04-19T08:04:58  *** zarez has quit IRC
1362018-04-19T08:05:19  *** zarez has joined #bitcoin-core-dev
1372018-04-19T08:08:29  *** jtimon has joined #bitcoin-core-dev
1382018-04-19T08:23:47  *** zigen has joined #bitcoin-core-dev
1392018-04-19T08:23:55  *** timothy has joined #bitcoin-core-dev
1402018-04-19T08:29:24  *** drizztbsd has joined #bitcoin-core-dev
1412018-04-19T08:29:53  *** timothy has quit IRC
1422018-04-19T08:33:48  *** drizztbsd has quit IRC
1432018-04-19T08:39:14  *** fanquake has quit IRC
1442018-04-19T08:42:24  *** timothy has joined #bitcoin-core-dev
1452018-04-19T08:43:24  *** anstaendig has quit IRC
1462018-04-19T08:55:23  *** promag has joined #bitcoin-core-dev
1472018-04-19T09:01:52  *** promag has quit IRC
1482018-04-19T09:02:20  *** drexl has joined #bitcoin-core-dev
1492018-04-19T09:02:42  *** promag has joined #bitcoin-core-dev
1502018-04-19T09:09:37  *** anstaendig has joined #bitcoin-core-dev
1512018-04-19T09:14:44  *** Krellan has quit IRC
1522018-04-19T09:15:31  *** geezas has quit IRC
1532018-04-19T09:16:06  *** intcat has quit IRC
1542018-04-19T09:16:22  *** laurentmt has joined #bitcoin-core-dev
1552018-04-19T09:17:00  <bitcoin-git> [bitcoin] promag opened pull request #13026: Fix include comment in src/interfaces/wallet.h (master...2018-04-fixincludecomment) https://github.com/bitcoin/bitcoin/pull/13026
1562018-04-19T09:17:58  *** intcat has joined #bitcoin-core-dev
1572018-04-19T09:22:51  *** meshcollider has joined #bitcoin-core-dev
1582018-04-19T09:24:34  *** laurentmt has quit IRC
1592018-04-19T09:28:41  *** zautomata2 has joined #bitcoin-core-dev
1602018-04-19T09:31:31  *** crt4 has quit IRC
1612018-04-19T09:33:18  *** grafcaps has joined #bitcoin-core-dev
1622018-04-19T09:37:27  *** grafcaps has quit IRC
1632018-04-19T09:40:49  *** drexl has quit IRC
1642018-04-19T09:41:13  *** zautomata2 has quit IRC
1652018-04-19T09:41:51  *** zautomata has joined #bitcoin-core-dev
1662018-04-19T09:44:57  *** goatpig has joined #bitcoin-core-dev
1672018-04-19T09:47:06  *** wxss has joined #bitcoin-core-dev
1682018-04-19T10:07:58  *** anstaendig has quit IRC
1692018-04-19T10:11:50  *** anstaendig has joined #bitcoin-core-dev
1702018-04-19T10:23:09  *** Samdney has joined #bitcoin-core-dev
1712018-04-19T10:24:37  *** CubicEarths has quit IRC
1722018-04-19T10:27:22  *** anstaendig has quit IRC
1732018-04-19T10:28:53  *** zigen has quit IRC
1742018-04-19T10:35:30  *** pergaminho has quit IRC
1752018-04-19T10:58:53  *** anstaendig has joined #bitcoin-core-dev
1762018-04-19T11:04:09  *** pergaminho has joined #bitcoin-core-dev
1772018-04-19T11:23:04  *** AaronvanW has joined #bitcoin-core-dev
1782018-04-19T11:24:09  *** CubicEarths has joined #bitcoin-core-dev
1792018-04-19T11:25:02  *** Aaronvan_ has joined #bitcoin-core-dev
1802018-04-19T11:26:52  *** jchysk has quit IRC
1812018-04-19T11:28:38  *** AaronvanW has quit IRC
1822018-04-19T11:29:59  <jtimon> fixed nits on https://github.com/bitcoin/bitcoin/pull/10757 , in case anyone was waiting for that to review
1832018-04-19T11:37:09  *** mistergold has joined #bitcoin-core-dev
1842018-04-19T11:39:09  *** jchysk has joined #bitcoin-core-dev
1852018-04-19T11:45:51  *** CubicEarths has quit IRC
1862018-04-19T11:52:24  *** jtimon has quit IRC
1872018-04-19T11:53:49  *** promag has quit IRC
1882018-04-19T11:55:12  *** Samdney has quit IRC
1892018-04-19T12:00:50  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/615f7c288414...39cf27faf324
1902018-04-19T12:00:51  <bitcoin-git> bitcoin/master b382004 Thomas Snider: benchmark: Removed bench/perf.cpp
1912018-04-19T12:00:51  <bitcoin-git> bitcoin/master 1bf3f33 Thomas Snider: node: Removed unused wallet-related methods from the Node interface.
1922018-04-19T12:00:52  <bitcoin-git> bitcoin/master 39cf27f MarcoFalke: Merge #13025: Dead code removal...
1932018-04-19T12:01:46  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13025: Dead code removal (master...tjps_dead_code) https://github.com/bitcoin/bitcoin/pull/13025
1942018-04-19T12:18:14  *** pergaminho has quit IRC
1952018-04-19T12:19:57  <wumpus> MarcoFalke: I don't get it, why are you removing perf.cpp/h?
1962018-04-19T12:20:07  <wumpus> MarcoFalke: is counting cpu cycles no longer relevant?
1972018-04-19T12:21:36  <wumpus> I really don't get this, without any discussion
1982018-04-19T12:24:36  <sipa> wumpus: it seems the code is actually unused
1992018-04-19T12:24:42  *** shtirlic_ has quit IRC
2002018-04-19T12:25:24  <sipa> only perf_init and perf_fini are invoked
2012018-04-19T12:25:48  <sipa> or is your point that we expect to use them again for another purpose soon?
2022018-04-19T12:25:59  *** shtirlic_ has joined #bitcoin-core-dev
2032018-04-19T12:26:22  <sipa> (i don't have an opinion either way, just want to make sure it's clear what is happening)
2042018-04-19T12:30:36  <MarcoFalke> wumpus: The discussion was in the pull that removed the usage, IIRC
2052018-04-19T12:31:01  *** SopaXorzTaker has joined #bitcoin-core-dev
2062018-04-19T12:31:02  <wumpus> it used to be that the benchmarks reported number of cycles too
2072018-04-19T12:31:16  <wumpus> apparently that was changed, and now my code to measure cycles was removed too
2082018-04-19T12:31:21  <wumpus> no one ever asked me about any of this
2092018-04-19T12:31:35  *** meshcollider has quit IRC
2102018-04-19T12:32:48  <wumpus> "I have removed the cycles statistics because I personally don't think it is necessary, and it simplifies the code. I could add it back though if others think its a helpful statistic"
2112018-04-19T12:33:03  <wumpus> wtf asked him :/
2122018-04-19T12:33:42  <wumpus> apparently I even reviewed that and missed that
2132018-04-19T12:35:20  <wumpus> but you can't say there really was any discussion
2142018-04-19T12:35:27  <MarcoFalke> fine
2152018-04-19T12:35:31  <MarcoFalke> Is there any evidence that this actually is a statistic that is not redundant?
2162018-04-19T12:36:02  <wumpus> redundant compared to what?
2172018-04-19T12:36:33  <MarcoFalke> std::chrono
2182018-04-19T12:36:42  <wumpus> well std::chrono counts time, not cycles
2192018-04-19T12:36:42  <MarcoFalke> (the clock we use right now)
2202018-04-19T12:37:19  <wumpus> e.g. not when the cpu is actually idle
2212018-04-19T12:38:16  <MarcoFalke> I asssume the only difference would be in the deser block test?
2222018-04-19T12:39:46  <wumpus> I don't know. It's entirely valid to have a discussion about whether it is redundent or not, but I think how this went is absurd
2232018-04-19T12:40:20  <MarcoFalke> It was unused for months now, and no one noticed. I don't think removing the code as it was unused is absurd.
2242018-04-19T12:40:26  <MarcoFalke> I am not saying we can't add it back in
2252018-04-19T12:40:59  <wumpus> right I haven't been using the benchmarks the last months
2262018-04-19T12:41:42  <MarcoFalke> When added back, it should be an optional swich (clock/cycles), so the format doesn't change again
2272018-04-19T12:42:19  <sipa> FWIW, if we continue work on platform specific SHA256 implementations, itay be necessary to do a mini benchmark at startup to determine what is fastest... generally cpu cycles are the most accurate way of doing that
2282018-04-19T12:42:49  <wumpus> well I"m not going to bother that's for sure
2292018-04-19T12:43:05  <wumpus> if I need this again I'll just patch it in locally
2302018-04-19T12:43:12  <MarcoFalke> sipa: That means the fuction should be moved to util.cpp?
2312018-04-19T12:43:18  <sipa> wumpus: i think you're overreacting
2322018-04-19T12:43:25  *** shtirlic_ has quit IRC
2332018-04-19T12:43:32  <sipa> people who reviewed this missed this, and acted in good faith
2342018-04-19T12:44:00  <sipa> we can trivially bring the code back
2352018-04-19T12:44:08  *** shtirlic_ has joined #bitcoin-core-dev
2362018-04-19T12:44:29  <wumpus> yes it was also my own dumb fault for not noticing it, on the other hand that PR changed so much in the format it was easy to miss
2372018-04-19T12:46:29  <sipa> if counting cpu cycles actually more reliable then counting time in benchmarks? i generally lock my cpu to a single frequency to do benchmarks, as noise complicates things otherwise, but i never botheres trying to look at cpu cycles
2382018-04-19T12:47:54  <MarcoFalke> sipa: That was my though. Only difference would be when cpu waits on io?
2392018-04-19T12:48:22  <sipa> MarcoFalke: waiting on IO does not directly reduce clock rate
2402018-04-19T12:48:33  *** anstaendig has quit IRC
2412018-04-19T12:49:05  <sipa> it could cause a switch to a different process though (but then cpu time is not counted anymore, while cycles are!)
2422018-04-19T12:49:43  <MarcoFalke> oh, cycles are still counted?
2432018-04-19T12:50:08  <MarcoFalke> In which case it would be identical to clock
2442018-04-19T12:50:13  <sipa> yes, the cycle counter is per cpu thread
2452018-04-19T12:50:41  <sipa> which clock are we using?
2462018-04-19T12:50:48  <sipa> cpu time or wall time?
2472018-04-19T12:50:52  <MarcoFalke> Yeah, I think BlueMatt told me something that the clock might be using cycles internally
2482018-04-19T12:51:23  <MarcoFalke> std::chrono::steady_clock mostly
2492018-04-19T12:51:59  <MarcoFalke> fallback to std::chrono::high_resolution_clock
2502018-04-19T12:52:19  <MarcoFalke> other way round, sorry
2512018-04-19T12:53:17  <sipa> yup, sorry  those also keep ticking if a process if not executing
2522018-04-19T12:54:19  <sipa> though it's unclear what those clocks really dl
2532018-04-19T12:54:32  <wumpus> it's one big stack of abstractions
2542018-04-19T12:54:33  <sipa> they may use system calls
2552018-04-19T12:55:18  <sipa> which are completely inappropriate if you want to measure very short running pieces of code (sub microsecond)
2562018-04-19T12:55:29  <wumpus> at least cpu cycles is a clear, transparant metric, the only problem is that it's not available on all architectures, and on e.g. ARM it needs system calls to measure :-/
2572018-04-19T12:56:09  <MarcoFalke> sipa: I think that is why we loop a bit before taking the clock
2582018-04-19T12:56:48  <MarcoFalke> in fact the iterations are hardcoded
2592018-04-19T12:57:06  <sipa> that may be historical
2602018-04-19T12:57:48  <sipa> the benchmarks used to be entirely self-measuring (aiming to run for 1s)
2612018-04-19T12:58:00  *** zautomata has quit IRC
2622018-04-19T12:58:00  *** zautomata has joined #bitcoin-core-dev
2632018-04-19T12:58:26  *** shesek has quit IRC
2642018-04-19T12:58:34  * sipa sleeps some more
2652018-04-19T12:58:40  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/39cf27faf324...c19986940869
2662018-04-19T12:58:40  <bitcoin-git> bitcoin/master 2c084a6 Thomas Snider: net: Minor accumulated cleanups
2672018-04-19T12:58:41  <bitcoin-git> bitcoin/master c199869 Wladimir J. van der Laan: Merge #12855: net: Minor accumulated cleanups...
2682018-04-19T12:59:25  <bitcoin-git> [bitcoin] laanwj closed pull request #12855: net: Minor accumulated cleanups (master...tjps_misc_cleans) https://github.com/bitcoin/bitcoin/pull/12855
2692018-04-19T13:00:01  *** Prady has joined #bitcoin-core-dev
2702018-04-19T13:01:38  *** Prady has quit IRC
2712018-04-19T13:02:43  <wumpus> but yes I was overreacting, sorry MarcoFalke
2722018-04-19T13:04:41  <MarcoFalke> wumpus: no worries :)
2732018-04-19T13:09:35  *** grafcaps has joined #bitcoin-core-dev
2742018-04-19T13:11:41  *** cryptojanitor has joined #bitcoin-core-dev
2752018-04-19T13:12:21  *** Guyver2 has joined #bitcoin-core-dev
2762018-04-19T13:13:35  *** grafcaps has quit IRC
2772018-04-19T13:15:22  *** anstaendig has joined #bitcoin-core-dev
2782018-04-19T13:16:04  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
2792018-04-19T13:16:04  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
2802018-04-19T13:27:43  *** promag has joined #bitcoin-core-dev
2812018-04-19T13:27:48  *** jtimon has joined #bitcoin-core-dev
2822018-04-19T13:35:31  *** Dizzle has joined #bitcoin-core-dev
2832018-04-19T13:35:49  <promag> I would really appreciate some reviews in #13017, ty
2842018-04-19T13:35:51  <gribble> https://github.com/bitcoin/bitcoin/issues/13017 | Add wallets management functions by promag · Pull Request #13017 · bitcoin/bitcoin · GitHub
2852018-04-19T13:36:14  <promag> simple stuff
2862018-04-19T13:37:10  *** crt4 has joined #bitcoin-core-dev
2872018-04-19T13:39:01  *** timothy has quit IRC
2882018-04-19T13:40:28  *** timothy has joined #bitcoin-core-dev
2892018-04-19T13:48:21  *** mistergold has quit IRC
2902018-04-19T13:51:21  *** CubicEarths has joined #bitcoin-core-dev
2912018-04-19T13:52:31  <bitcoin-git> [bitcoin] promag opened pull request #13028: Make vpwallets usage thread safe (master...2018-04-cs_wallets) https://github.com/bitcoin/bitcoin/pull/13028
2922018-04-19T13:54:04  *** CubicEarths has quit IRC
2932018-04-19T14:13:43  *** drizztbsd has joined #bitcoin-core-dev
2942018-04-19T14:13:53  *** timothy has quit IRC
2952018-04-19T14:14:11  *** laurentmt has joined #bitcoin-core-dev
2962018-04-19T14:14:41  *** akolen has joined #bitcoin-core-dev
2972018-04-19T14:16:50  *** akolen has quit IRC
2982018-04-19T14:21:03  *** tryphe_ has joined #bitcoin-core-dev
2992018-04-19T14:24:06  *** tryphe has quit IRC
3002018-04-19T14:26:42  <BlueMatt> sipa: the reason the iteration count was hardcoded is cause the time measured changed a shitload depending on iteration counts
3012018-04-19T14:27:05  <BlueMatt> so hardcoding was easier to get more stable results than running it 20 times until you had a bunch of results for the iteration count you wanted
3022018-04-19T14:27:45  <bitcoin-git> [bitcoin] Sjors opened pull request #13029: Interpret absense of prune= as prune=1 if there are pruned blocks (master...2018/04/implicit_prune) https://github.com/bitcoin/bitcoin/pull/13029
3032018-04-19T14:43:28  *** contrapumpkin has joined #bitcoin-core-dev
3042018-04-19T14:48:15  *** promag has quit IRC
3052018-04-19T14:51:01  *** grafcaps has joined #bitcoin-core-dev
3062018-04-19T15:00:57  *** grafcaps has quit IRC
3072018-04-19T15:02:13  *** Krellan has joined #bitcoin-core-dev
3082018-04-19T15:03:29  *** zarez has quit IRC
3092018-04-19T15:03:30  *** timothy has joined #bitcoin-core-dev
3102018-04-19T15:04:33  *** drizztbsd has quit IRC
3112018-04-19T15:06:58  *** zarez has joined #bitcoin-core-dev
3122018-04-19T15:08:59  *** drizztbsd has joined #bitcoin-core-dev
3132018-04-19T15:09:26  *** timothy has quit IRC
3142018-04-19T15:14:47  *** grafcaps has joined #bitcoin-core-dev
3152018-04-19T15:16:19  *** promag has joined #bitcoin-core-dev
3162018-04-19T15:18:29  *** Giszmo has joined #bitcoin-core-dev
3172018-04-19T15:21:30  <bitcoin-git> [bitcoin] jnewbery opened pull request #13030: [bugfix] [wallet] Fix zapwallettxes/multiwallet interaction. (master...fix_zapwallet_multiwallet_interaction) https://github.com/bitcoin/bitcoin/pull/13030
3182018-04-19T15:22:07  *** lnostdal_ has joined #bitcoin-core-dev
3192018-04-19T15:24:17  *** lnostdal has quit IRC
3202018-04-19T15:26:32  *** jtimon has quit IRC
3212018-04-19T15:28:49  *** shesek has joined #bitcoin-core-dev
3222018-04-19T15:28:49  *** shesek has joined #bitcoin-core-dev
3232018-04-19T15:30:20  *** drizztbsd is now known as timothy
3242018-04-19T15:30:23  *** arbitrary_guy has joined #bitcoin-core-dev
3252018-04-19T15:32:39  *** laurentmt has quit IRC
3262018-04-19T15:43:27  *** Randolf has quit IRC
3272018-04-19T15:48:59  *** rafalcpp has joined #bitcoin-core-dev
3282018-04-19T15:51:14  *** cryptojanitor has quit IRC
3292018-04-19T16:02:25  *** isis is now known as isis_
3302018-04-19T16:02:30  *** isis_ is now known as isis
3312018-04-19T16:02:35  *** jamesob has quit IRC
3322018-04-19T16:02:43  *** jtimon has joined #bitcoin-core-dev
3332018-04-19T16:02:53  *** jamesob has joined #bitcoin-core-dev
3342018-04-19T16:04:41  *** Murch has joined #bitcoin-core-dev
3352018-04-19T16:04:46  *** isis is now known as isis_
3362018-04-19T16:14:02  *** zarez1 has joined #bitcoin-core-dev
3372018-04-19T16:14:10  *** Randolf has joined #bitcoin-core-dev
3382018-04-19T16:14:54  *** zarez has quit IRC
3392018-04-19T16:14:54  *** zarez1 is now known as zarez
3402018-04-19T16:15:35  *** promag has quit IRC
3412018-04-19T16:16:58  *** lnostdal_ is now known as lnostdal
3422018-04-19T16:18:56  *** Dizzle has quit IRC
3432018-04-19T16:31:27  *** promag has joined #bitcoin-core-dev
3442018-04-19T16:34:43  *** guest1456342 has joined #bitcoin-core-dev
3452018-04-19T16:39:36  *** promag has quit IRC
3462018-04-19T16:45:05  *** arbitrary_guy has quit IRC
3472018-04-19T16:46:49  *** ProfMac has joined #bitcoin-core-dev
3482018-04-19T17:02:15  *** AaronvanW has joined #bitcoin-core-dev
3492018-04-19T17:04:57  *** owowo has quit IRC
3502018-04-19T17:05:38  *** owowo has joined #bitcoin-core-dev
3512018-04-19T17:05:59  *** Aaronvan_ has quit IRC
3522018-04-19T17:14:08  *** zarez has quit IRC
3532018-04-19T17:14:09  *** tryphe_ has quit IRC
3542018-04-19T17:14:35  *** tryphe_ has joined #bitcoin-core-dev
3552018-04-19T17:27:31  *** crt4 has quit IRC
3562018-04-19T17:28:46  <jnewbery> wumpus: I think #13024 can go on the high priority for review. It's blocking walletload, which a few people said they wanted for V0.17 in the last weekly meeting.
3572018-04-19T17:28:47  <gribble> https://github.com/bitcoin/bitcoin/issues/13024 | test: Add rpcauth pair that generated by rpcauth by ken2812221 · Pull Request #13024 · bitcoin/bitcoin · GitHub
3582018-04-19T17:28:53  <jnewbery> sorry, not 13024
3592018-04-19T17:29:02  <jnewbery> sorry, not #13017
3602018-04-19T17:29:03  *** Krellan has quit IRC
3612018-04-19T17:29:05  <gribble> https://github.com/bitcoin/bitcoin/issues/13017 | Add wallets management functions by promag · Pull Request #13017 · bitcoin/bitcoin · GitHub
3622018-04-19T17:29:18  <jnewbery> That one ^^ 13017
3632018-04-19T17:32:59  *** Krellan_ has joined #bitcoin-core-dev
3642018-04-19T17:34:48  *** timothy has quit IRC
3652018-04-19T17:37:53  *** Krellan_ has quit IRC
3662018-04-19T17:44:35  *** Aaronvan_ has joined #bitcoin-core-dev
3672018-04-19T17:44:57  *** iwkse_ is now known as iwkse
3682018-04-19T17:47:46  *** AaronvanW has quit IRC
3692018-04-19T17:49:10  *** promag has joined #bitcoin-core-dev
3702018-04-19T18:02:01  *** promag has quit IRC
3712018-04-19T18:09:05  *** instagibbs has quit IRC
3722018-04-19T18:10:20  *** instagibbs has joined #bitcoin-core-dev
3732018-04-19T18:10:24  <BlueMatt> I'll probably miss the meeting, but, hey, I got through 3/4 of the high-priority PRs, even acked 2, and left blocking comments on the 3rd....how did *you* do this week?
3742018-04-19T18:11:01  <BlueMatt> someone should repeat that when meeting time comes ^ :p
3752018-04-19T18:13:35  <kanzure> will do
3762018-04-19T18:13:45  *** goatpig has quit IRC
3772018-04-19T18:15:57  *** promag has joined #bitcoin-core-dev
3782018-04-19T18:16:24  *** Dizzle has joined #bitcoin-core-dev
3792018-04-19T18:17:27  *** lnostdal has quit IRC
3802018-04-19T18:28:07  *** AaronvanW has joined #bitcoin-core-dev
3812018-04-19T18:31:10  *** Aaronvan_ has quit IRC
3822018-04-19T18:34:03  *** Krellan has joined #bitcoin-core-dev
3832018-04-19T18:34:49  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c19986940869...9b3a67eb0861
3842018-04-19T18:34:49  <bitcoin-git> bitcoin/master defffb3 João Barbosa: trivial: Improve include comment in src/interfaces/wallet.h
3852018-04-19T18:34:50  <bitcoin-git> bitcoin/master 9b3a67e MarcoFalke: Merge #13026: Fix include comment in src/interfaces/wallet.h...
3862018-04-19T18:35:39  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13026: Fix include comment in src/interfaces/wallet.h (master...2018-04-fixincludecomment) https://github.com/bitcoin/bitcoin/pull/13026
3872018-04-19T18:35:53  *** Giszmo has quit IRC
3882018-04-19T18:38:31  *** lnostdal has joined #bitcoin-core-dev
3892018-04-19T18:38:57  *** Krellan has quit IRC
3902018-04-19T18:40:23  <bitcoin-git> [bitcoin] MarcoFalke pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/9b3a67eb0861...0a8b7b4b33c9
3912018-04-19T18:40:24  <bitcoin-git> bitcoin/master ce65018 Suhas Daftuar: Use P2SH consensus rules for all blocks...
3922018-04-19T18:40:24  <bitcoin-git> bitcoin/master 95749a5 Suhas Daftuar: Separate NULLDUMMY enforcement from SEGWIT enforcement...
3932018-04-19T18:40:25  <bitcoin-git> bitcoin/master 5c31b20 Suhas Daftuar: [qa] Remove some pre-activation segwit tests...
3942018-04-19T18:40:46  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11739: Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis (master...2017-09-p2sh-segwit-from-genesis) https://github.com/bitcoin/bitcoin/pull/11739
3952018-04-19T18:46:28  <wumpus> jnewbery: 13017 already has lots of (ut)ACKs, I'm not sure it makes sense to add it to high priority for review anymore
3962018-04-19T18:51:11  <promag> yap, just merge it instead :)
3972018-04-19T18:51:29  <luke-jr> (not going to be on time for the meeting, but will try to join as soon as I can)
3982018-04-19T18:55:29  *** clarkmoody has joined #bitcoin-core-dev
3992018-04-19T18:56:54  *** meshcollider has joined #bitcoin-core-dev
4002018-04-19T18:57:42  *** moneyball has joined #bitcoin-core-dev
4012018-04-19T18:58:59  *** mistergold has joined #bitcoin-core-dev
4022018-04-19T19:00:09  <wumpus> #startmeeting
4032018-04-19T19:00:09  <lightningbot> Meeting started Thu Apr 19 19:00:09 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4042018-04-19T19:00:09  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4052018-04-19T19:00:15  <sipa> ohai
4062018-04-19T19:00:22  <jonasschnelli> hi
4072018-04-19T19:00:25  <promag> hi
4082018-04-19T19:00:30  <achow101> hi
4092018-04-19T19:00:35  <jnewbery> hi
4102018-04-19T19:00:37  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
4112018-04-19T19:00:39  <kanzure> hi.
4122018-04-19T19:00:41  <instagibbs> hi
4132018-04-19T19:00:42  <aj> 'lo
4142018-04-19T19:00:50  <cfields> hi
4152018-04-19T19:01:24  <jonasschnelli> ;;seen gmaxwell
4162018-04-19T19:01:24  <gribble> gmaxwell was last seen in #bitcoin-core-dev 5 weeks, 0 days, 1 hour, and 59 seconds ago: <gmaxwell> it's not like you pay lower fees due to it.
4172018-04-19T19:01:35  <meshcollider> hi
4182018-04-19T19:01:37  <wumpus> any proposed topics?
4192018-04-19T19:01:50  <jonasschnelli> I'd like to touch the light client mode design
4202018-04-19T19:02:02  <wumpus> ok
4212018-04-19T19:02:04  <promag> check high priority review first?
4222018-04-19T19:02:08  <kanzure> 11:10 < BlueMatt> I'll probably miss the meeting, but, hey, I got through 3/4 of the high-priority PRs, even acked 2, and left blocking comments on the 3rd....how did *you* do this week?
4232018-04-19T19:02:09  <jonasschnelli> ack
4242018-04-19T19:02:22  <wumpus> promag: yes, that's always the first topic
4252018-04-19T19:02:22  <jonasschnelli> we can't view jimpos txindex PR
4262018-04-19T19:02:31  <jonasschnelli> github issue... can we reopen the PR in a new #?
4272018-04-19T19:02:33  <sipa> I'd like #13002 on the high-priority list
4282018-04-19T19:02:34  <gribble> https://github.com/bitcoin/bitcoin/issues/13002 | Do not treat bare multisig outputs as IsMine unless watched by sipa · Pull Request #13002 · bitcoin/bitcoin · GitHub
4292018-04-19T19:02:46  <wumpus> #topic high priority for review
4302018-04-19T19:02:50  <wumpus> https://github.com/bitcoin/bitcoin/projects/8
4312018-04-19T19:03:00  <Murch> hi
4322018-04-19T19:03:00  <sipa> Also, I can't open #11857
4332018-04-19T19:03:05  <gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
4342018-04-19T19:03:19  <jonasschnelli> added 13002
4352018-04-19T19:03:22  <sipa> Do we at some point just close the PR and open a new one, to flush all historical discussion?
4362018-04-19T19:03:26  *** laurentmt has joined #bitcoin-core-dev
4372018-04-19T19:03:31  <jonasschnelli> sipa: yes
4382018-04-19T19:03:35  <sipa> (assuming that's the reason for the sad unicorn)
4392018-04-19T19:03:41  <jonasschnelli> jimpo should do it though...
4402018-04-19T19:03:46  <sipa> yes
4412018-04-19T19:03:48  <kanzure> has someone reported the unicorn to support@github.com
4422018-04-19T19:03:49  <jonasschnelli> I could not get hold of him in. the last days
4432018-04-19T19:03:54  <achow101> maybe telling github would help...
4442018-04-19T19:03:57  <jonasschnelli> kanzure: please do
4452018-04-19T19:04:12  <sipa> probably better if a repo owner does so
4462018-04-19T19:04:18  <sipa> i'll send a mail
4472018-04-19T19:04:20  <jonasschnelli> I doubt it would help in a resonable timeframe
4482018-04-19T19:04:21  <meshcollider> I don't get the unicorn, I can see it fine
4492018-04-19T19:04:28  <jonasschnelli> it's wired
4502018-04-19T19:04:33  <promag> me to, but in incognito
4512018-04-19T19:04:37  <instagibbs> kanzure, i did
4522018-04-19T19:04:39  <wumpus> I see the unicorn
4532018-04-19T19:04:40  <jonasschnelli> I can't. But i can in mobile view
4542018-04-19T19:04:51  <instagibbs> incognito works reliably for me
4552018-04-19T19:04:52  <jnewbery> instagibbs reported it
4562018-04-19T19:04:54  <kanzure> instagibbs: thanks. i'll refrain.
4572018-04-19T19:05:10  <sipa> instagibbs: when?
4582018-04-19T19:05:14  <instagibbs> couple days ago
4592018-04-19T19:05:18  <sipa> any response?
4602018-04-19T19:05:21  <instagibbs> no
4612018-04-19T19:05:29  <achow101> I've reported it just now
4622018-04-19T19:05:40  <achow101> also works in private browsing (firefox)
4632018-04-19T19:06:21  <jonasschnelli> logged out state works
4642018-04-19T19:06:34  <jonasschnelli> however, jimpo should just open a new PR
4652018-04-19T19:07:38  <jamesob> I can view it in lynx just fine
4662018-04-19T19:07:40  <sipa> suggested tiny topic: cyclic dependency
4672018-04-19T19:07:47  <jonasschnelli> hah jamesob
4682018-04-19T19:07:50  <jamesob> ;)
4692018-04-19T19:08:28  <wumpus> #topic cyclic dependency
4702018-04-19T19:08:55  *** jcohen has joined #bitcoin-core-dev
4712018-04-19T19:09:00  *** laurentmt has quit IRC
4722018-04-19T19:09:06  <sipa> i was wondering if we should have a policy against the type of cyclic dependency where the .cpp files include eachother's .h files (but not .h files include eachother)
4732018-04-19T19:09:36  <wumpus> do we have that problem?
4742018-04-19T19:09:36  <sipa> that's not a cyclic dependency for the compiler, but it does mean those two modules can't really be used independently and is generally a sign of bad separation
4752018-04-19T19:09:38  <kanzure> do we have many of that
4762018-04-19T19:09:38  <cfields> sipa: example?
4772018-04-19T19:09:45  <sipa> there are a few open PRs that introduce them
4782018-04-19T19:10:15  <wumpus> I do agree cyclic dependency should be avoided in general
4792018-04-19T19:10:20  <sipa> so i wanted to bring it up here to see if that should be a PR merging blocker
4802018-04-19T19:10:29  <sipa> or just a "try to fix it up afterwards if introduced"
4812018-04-19T19:10:46  <sipa> i'm fine with either
4822018-04-19T19:11:07  <cfields> indeed sounds like likely bad design that should at least be justified in the PR
4832018-04-19T19:11:10  *** votefrac has joined #bitcoin-core-dev
4842018-04-19T19:11:19  <sdaftuar> cfields: +1
4852018-04-19T19:11:21  <jonasschnelli> Yes. And maybe mention it in the developer guidelines?
4862018-04-19T19:11:23  <wumpus> right, might make sense to discuss this in the PR
4872018-04-19T19:11:23  <meshcollider> Sounds like it'd be a painful thing to fix up afterwards in some cases
4882018-04-19T19:11:25  <aj> seems good to fix it before merge, but not sure it should be added as a lint check or similar
4892018-04-19T19:11:27  <sdaftuar> i can imagine that in some contexts we'd merge anyway
4902018-04-19T19:11:54  <sdaftuar> but might be blocking in others
4912018-04-19T19:12:02  <meshcollider> ^
4922018-04-19T19:12:10  <sipa> #12954 introduces one for example
4932018-04-19T19:12:11  <gribble> https://github.com/bitcoin/bitcoin/issues/12954 | util: Refactor logging code into a global object by jimpo · Pull Request #12954 · bitcoin/bitcoin · GitHub
4942018-04-19T19:12:36  <wumpus> for a refactor it should definitely be avoided
4952018-04-19T19:12:44  <wumpus> refactoring is supposed to make the code better
4962018-04-19T19:12:50  <wumpus> not introduce further bad design
4972018-04-19T19:12:58  <sdaftuar> that might be an example of an improvement that just doens't go far enough though?
4982018-04-19T19:13:05  <sipa> well one way of looking at it is that the current util.cpp there has two subcomponents that already have a cyclic dependency
4992018-04-19T19:13:16  <sipa> within the same .cpp file
5002018-04-19T19:13:27  <sipa> and forcing people to fix it before they can separate it is maybe counterproductive
5012018-04-19T19:13:35  <sipa> or not ;)
5022018-04-19T19:13:36  <wumpus> maybe...
5032018-04-19T19:13:43  *** laurentmt has joined #bitcoin-core-dev
5042018-04-19T19:13:46  *** laurentmt has quit IRC
5052018-04-19T19:14:16  <sipa> enough on the topic i guess
5062018-04-19T19:14:27  <jcohen> one "quick" solution to avoiding that circular dep would be to jam it all into a single file - which i think would be even less desireable
5072018-04-19T19:14:39  <wumpus> it is already in a single file
5082018-04-19T19:14:42  <jcohen> the alternative would be to split util up even further, which would lengthen the diff
5092018-04-19T19:15:06  <sipa> this is just an example, it's relatively easy to fix in this case
5102018-04-19T19:15:07  <cfields> sipa: right. Since the point of this one is to break up a big blob anyway, requiring it to solve the circular issue in one go would be pretty burdensome. But if it's moving in the right direction, imo maintaining the status quo is ok.
5112018-04-19T19:15:23  <cfields> we could go back to main.cpp :p
5122018-04-19T19:15:32  <sipa> cat *.cpp | gcc -
5132018-04-19T19:15:33  <wumpus> cfields: true...
5142018-04-19T19:15:40  <achow101> "just put everything into one big file and call it main.cpp"
5152018-04-19T19:15:52  <wumpus> I don't think I feel strong enough about this one to put it in the guidelines
5162018-04-19T19:15:55  *** dx25 has quit IRC
5172018-04-19T19:15:59  <jtimon> well, perhaps breaking util as needed first makes sense
5182018-04-19T19:16:10  <wumpus> though commenting on it where relevant is a good idea
5192018-04-19T19:16:14  <sipa> sgtm
5202018-04-19T19:16:45  <wumpus> if there's an obvious solution to avoid it that's better, but we cannot enumerate every single software design compromise
5212018-04-19T19:17:19  <wumpus> #topic light client mode design (jonasschnelli)
5222018-04-19T19:17:39  <aj> #13021 does the "break util as needed first" by the looks - logging.cpp includes util.h, util.h includes logging.h
5232018-04-19T19:17:40  <gribble> https://github.com/bitcoin/bitcoin/issues/13021 | MOVEONLY: Move logging code from util.{h,cpp} to new files. by jimpo · Pull Request #13021 · bitcoin/bitcoin · GitHub
5242018-04-19T19:17:41  *** dx25 has joined #bitcoin-core-dev
5252018-04-19T19:17:42  <jonasschnelli> I'd like to get some feedback about the light client mode... particular the "requestblock" design
5262018-04-19T19:17:50  <jonasschnelli> #10794
5272018-04-19T19:17:53  <gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
5282018-04-19T19:17:59  <jonasschnelli> if that is something we should follow or drop
5292018-04-19T19:18:07  *** promag has quit IRC
5302018-04-19T19:18:26  <jonasschnelli> I know the use-cases with 10794 are limited, but a stepping stone towards hybrid and BIP158 light validation
5312018-04-19T19:18:28  *** promag has joined #bitcoin-core-dev
5322018-04-19T19:19:01  <sipa> jonasschnelli: will review
5332018-04-19T19:19:19  <jonasschnelli> maybe first check for a concept ACK/NACK
5342018-04-19T19:19:28  <jtimon> aj: yeah, and it seems moveonly, so perhaps just rebasing 12954 on top of 13021 solves the issue in this case? sipa
5352018-04-19T19:19:30  *** LukeJr has joined #bitcoin-core-dev
5362018-04-19T19:20:23  <sipa> jonasschnelli: yes, makes sense - it's a bit too much to look at right now in the meeting though, i think
5372018-04-19T19:20:30  <jonasschnelli> sure...
5382018-04-19T19:20:58  <jonasschnelli> I'm only interested to know if the concept make sense for you guys
5392018-04-19T19:21:14  <jonasschnelli> (of having a light client mode)
5402018-04-19T19:21:20  <wumpus> they have been open for a long time, probably should et around to at least concept-acking them
5412018-04-19T19:21:26  <sipa> yes
5422018-04-19T19:21:45  <jonasschnelli> Great. Thanks
5432018-04-19T19:21:47  <sipa> jonasschnelli: oh, the idea of having a client mode - that makes absolutely sense to me
5442018-04-19T19:21:53  <sipa> but it heavily depends on how and what :)
5452018-04-19T19:22:04  <meshcollider> Having a light client mode is definitely a concept ACK for me
5462018-04-19T19:22:11  <LukeJr> jonasschnelli: only as a temporary stage
5472018-04-19T19:22:19  <sipa> LukeJr: how so?
5482018-04-19T19:22:21  <jonasschnelli> right... I wasn't sure if the PR is the right place to discuss that or if we want to do it in a meeting
5492018-04-19T19:22:43  <LukeJr> sipa: it should always be building up to a full node in the bg
5502018-04-19T19:23:13  <sipa> LukeJr: i disagree - it's a perfectly valid usecase to have one full node you run yourself, and then have multiple client nodes connect exclusively to it
5512018-04-19T19:23:16  <LukeJr> (even if that bg process is paused for a time)
5522018-04-19T19:23:36  <LukeJr> sipa: hmm
5532018-04-19T19:23:43  <cfields> jonasschnelli: I realize this is really unhelpful feedback, but I find the current download logic nearly impossible to follow as-is. I remember giving up on review of this last time for that reason. Imo it's due for a bit of a cleanup/encapsulation before piling more on :(
5542018-04-19T19:24:13  <sipa> LukeJr: but lightweight upgrading to full in the background is also an very good usecase, imho
5552018-04-19T19:24:15  <cfields> (feel free to ignore that, maybe it's just my issue reading the code)
5562018-04-19T19:24:43  <sdaftuar> cfields: you are not the only person who finds the download logic confusing :)
5572018-04-19T19:25:02  <sipa> i believe those who (helped) write it agree :)
5582018-04-19T19:25:12  <jonasschnelli> heh. Yes. The open PR is not the first try to make this with a possible very small impact on the code...
5592018-04-19T19:25:26  <sipa> jonasschnelli: thanks for stickin with it, though
5602018-04-19T19:25:56  <cfields> yes, I was hesitant to mention that because I didn't want to de-motivate at all.
5612018-04-19T19:26:00  <LukeJr> sipa: as soon as the wallet is split, your use case just works
5622018-04-19T19:26:31  <sipa> LukeJr: this is how i imagine the wallet being split :)
5632018-04-19T19:27:14  <jamesob> *cough* #10973 *cough*
5642018-04-19T19:27:17  <gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
5652018-04-19T19:27:19  <jonasschnelli> It's still unclear though how fee estimations and mempool checks would be done "in that way"
5662018-04-19T19:27:46  <sipa> jamesob: that's modularizing the code better, which is independently useful
5672018-04-19T19:29:08  <sipa> i don't think the goal should be separating the wallet from the node into different processes, and then inventing a protocol between the two... instead of just making the wallet run as a light client
5682018-04-19T19:29:41  <jamesob> the two sound very similar to me
5692018-04-19T19:29:50  <LukeJr> I don't agree. There's no reason the wallet and node should be in the same process.
5702018-04-19T19:30:50  <jonasschnelli> sipa: I agree. For me its just unclear how to transport fee estimations and mempool checks between light client and the fullnode.
5712018-04-19T19:31:00  <wumpus> LukeJr: that's not what sipa is saying, in his case the node and wallet would also be in different processes, but without custom protocol
5722018-04-19T19:31:17  <sipa> jamesob: the advantage of using P2P as communication between node and wallet (which is what you get if you see wallets as just lightweight nodes) is that it actually modularizing things: you can run _any_ wallet software or _any_ node software
5732018-04-19T19:31:30  <jamesob> wumpus sipa: but then using what protocol? a more fleshed out rpc interface?
5742018-04-19T19:31:37  <sipa> jamesob: P2P
5752018-04-19T19:31:37  <instagibbs> p2p messages
5762018-04-19T19:31:50  <instagibbs> with whitelisted fee estimation type messages, i assume
5772018-04-19T19:31:55  <wumpus> right
5782018-04-19T19:32:05  <jonasschnelli> instagibbs: but not before we have BIP150/151
5792018-04-19T19:32:19  <wumpus> I think for localhost it's fine without?
5802018-04-19T19:32:21  <jonasschnelli> I don't want MITMled fees
5812018-04-19T19:32:24  <jonasschnelli> yes. sure
5822018-04-19T19:32:32  <sipa> oh, short topic: update on private authentication protocols
5832018-04-19T19:32:41  <wumpus> but yes, in general that's correct
5842018-04-19T19:32:56  <jnewbery> I don't think doing process separation with IPC precludes later doing a p2p-based wallet
5852018-04-19T19:32:58  <jamesob> sipa: thanks for the explanation; will noodle on that
5862018-04-19T19:33:16  <jnewbery> p2p-based wallet seems like a very large project
5872018-04-19T19:33:17  <sipa> jnewbery: i agree, but i think it's a bit overkill
5882018-04-19T19:33:25  <sipa> jnewbery: however, i don't think that's a choice that needs to be made
5892018-04-19T19:33:43  <jonasschnelli> jnewbery: we are not too far away from a p2p based wallet IMO
5902018-04-19T19:33:46  <sipa> encapsulating the communication between node and wallet is an objective improvement to the code
5912018-04-19T19:34:06  <sipa> even if it does not lead to also a process separation along that interface
5922018-04-19T19:34:08  *** Aaronvan_ has joined #bitcoin-core-dev
5932018-04-19T19:34:38  <jnewbery> jonasschnelli: really? Maybe I overestimate the difficulty, but it seems like we'd need a lot of new logic in the wallet to understand p2p
5942018-04-19T19:34:48  <sipa> jnewbery: you misunderstand!
5952018-04-19T19:34:56  <sipa> jnewbery: it would reuse all the existing full node code
5962018-04-19T19:35:00  <sipa> and p2p implementation
5972018-04-19T19:35:06  <sipa> just don't do validation
5982018-04-19T19:35:07  <instagibbs> turn off full validation, ofc
5992018-04-19T19:35:08  <ryanofsky> just catching up, but yeah, i think two approaches are not exclusive, and work done to support ipc will be useful anyway for making wallet more independent and better able to do async p2p stuff
6002018-04-19T19:35:10  <jonasschnelli> jnewbery: it needs BIP158 light client mode (or fullblock), fee and mempool checks. Done
6012018-04-19T19:35:24  *** SopaXorzTaker has quit IRC
6022018-04-19T19:35:29  <sipa> ryanofsky: yes, fully agree
6032018-04-19T19:35:51  <jonasschnelli> You just start two instances of Core. One as a full node, one with disabled validation pointing to the full node
6042018-04-19T19:36:59  <LukeJr> does it simplify or complicate the internal code? (ignoring the present level of complexity in itself)
6052018-04-19T19:36:59  <jonasschnelli> --> <sipa>	oh, short topic: update on private authentication protocols
6062018-04-19T19:37:00  <jnewbery> ok, I understand. How much work is it to make core work in --disablevalidation mode?
6072018-04-19T19:37:12  <sipa> jnewbery: that's the current topic :)
6082018-04-19T19:37:29  <jonasschnelli> jnewbery: 10794
6092018-04-19T19:37:32  <jonasschnelli> (does it)
6102018-04-19T19:37:33  <jnewbery> ok, I'll shut up and read the PR
6112018-04-19T19:37:37  *** AaronvanW has quit IRC
6122018-04-19T19:38:03  <jonasschnelli> although 10794 leads out the wallet
6132018-04-19T19:38:11  <jonasschnelli> (to make it reviewable)
6142018-04-19T19:38:21  <jonasschnelli> *lefts out
6152018-04-19T19:38:39  <wumpus> #topic update on private authentication protocols (sipa)
6162018-04-19T19:38:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6172018-04-19T19:39:25  <sipa> so, as some know gmaxwell and i have been thinking about authentication protocols that have better privacy than bip150
6182018-04-19T19:40:06  <jonasschnelli> privacy in the sense of fingerprinting?
6192018-04-19T19:40:09  <sipa> yes
6202018-04-19T19:40:23  <sipa> the goal is to have a design where one node has 1 or more private keys, and the other node has 1 or more public keys
6212018-04-19T19:40:40  <sipa> and the second node learns whether one of the other node's private keys matches one of your public keys
6222018-04-19T19:40:43  <sipa> but _nothing_ else
6232018-04-19T19:40:57  <sipa> the node with the private keys does not even learn if authentication was succesful
6242018-04-19T19:41:09  <sipa> or doesn't learn which keys it was being queried for
6252018-04-19T19:41:26  <jonasschnelli> the use case is then wide deploey authentication sheme rather then the more client-server-ish approach?
6262018-04-19T19:41:42  <sipa> it's still client-server
6272018-04-19T19:42:01  <sipa> the cool thing about this is that you can always run the authentication protocol
6282018-04-19T19:42:03  <LukeJr> sounds hard to give an "authentication failiure" error?
6292018-04-19T19:42:34  <sipa> LukeJr: the idea is that most of our connections are unauthentication anyway (and should be)... so whatever privileges you give to authenticated nodes, you just don't give if auth fails
6302018-04-19T19:42:45  <sipa> this has a very cool property
6312018-04-19T19:42:53  <sipa> you can _always_ run this authentication protocol
6322018-04-19T19:43:00  <sipa> even if you don't care who the other party is
6332018-04-19T19:43:05  <jonasschnelli> sipa: but, if you have node A and node B's pubkeys and you want connect to A, how can you be sure you'r not connecting to B?
6342018-04-19T19:43:11  <LukeJr> sipa: but if the authenticating node doesn't know if it failed, then it doesn't know if it has an authentication connection it expects
6352018-04-19T19:43:37  <sipa> LukeJr: it can run the same protocol in the other direction to find out
6362018-04-19T19:43:43  <LukeJr> hmm
6372018-04-19T19:43:54  <sipa> jonasschnelli: you just query for who you want the other party to be
6382018-04-19T19:43:59  <phantomcircuit> or just ask for something that requires authentication
6392018-04-19T19:44:02  *** d9b4bef9 has quit IRC
6402018-04-19T19:44:41  <sipa> the cool thing is that if you always run the authentication protocol, but if you're not interested in authentication do it with just a randomly generated pubkey, a MitM can't find out what you're doing
6412018-04-19T19:44:49  <sipa> they have to assume you're trying to authenticate
6422018-04-19T19:45:02  <sipa> anyway, turns out... this is difficult
6432018-04-19T19:45:05  <cfields> sipa: i'm not sure if this has evolved from when we discussed last... does your peer learn how many pubkeys you'd accept?
6442018-04-19T19:45:08  *** d9b4bef9 has joined #bitcoin-core-dev
6452018-04-19T19:45:20  <sipa> cfields: yes, but you can stuff your request with a number of random ones
6462018-04-19T19:45:28  <cfields> right, ok
6472018-04-19T19:45:29  <sipa> just pad to 256 keys or whatever, always
6482018-04-19T19:45:52  <instagibbs> so, did you fix it? :)
6492018-04-19T19:45:55  <jonasschnelli> sounds interesting.. are there written specs already?
6502018-04-19T19:46:00  <sipa> we have a protocol that works with 1 privkey and 1 pubkey - which means you need to run in many times sometimes which doesn't lead to great fingerprinting properties
6512018-04-19T19:46:10  <sipa> and i'm talking to some people to extend it :)
6522018-04-19T19:46:46  <jonasschnelli> Great. Thanks!
6532018-04-19T19:46:50  <sipa> jonasschnelli: https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
6542018-04-19T19:46:58  <sipa> note that that protocol linked to is broken
6552018-04-19T19:47:16  <sipa> but it does explain the rationale pretty well, i think
6562018-04-19T19:47:37  <sipa> end topic
6572018-04-19T19:47:51  <jonasschnelli> I guess this protocol would require more cryptoanalysis then the exiting BIP150
6582018-04-19T19:48:09  <sipa> jonasschnelli: that's ok, i'm talking to dan boneh about it
6592018-04-19T19:48:28  <jonasschnelli> Good!
6602018-04-19T19:48:51  <meshcollider> Dan is the solution to all crypto problems
6612018-04-19T19:48:57  <jonasschnelli> heh
6622018-04-19T19:49:18  <wumpus> it'd be good as a future successor to BIP150 - though I guess this research shouldn't discourage anyone from implementing BIP150 and having something working on more short term
6632018-04-19T19:49:26  <sipa> right
6642018-04-19T19:49:42  <wumpus> (maybe that's obvious, but just to be clear)
6652018-04-19T19:49:44  <jonasschnelli> Implementing BIP151/150 is still hold back due to the network refactor, right?
6662018-04-19T19:50:03  <jonasschnelli> If not, I can continue on BIP150
6672018-04-19T19:50:09  <jonasschnelli> sry. 1541
6682018-04-19T19:50:10  <jonasschnelli> sry. 151
6692018-04-19T19:50:11  <cfields> sipa: I'm still a bit confused as to the use-case. Is the intent to be able to explicitly find a known peer, or more generally to build up a list of tofu-ish nodes that aren't known to misbehave, and look for them first when creating outbound connections?
6702018-04-19T19:50:27  <jnewbery> cfields: what's the state of network refactor? Any PRs awaiting review?
6712018-04-19T19:50:28  <sipa> cfields: you can't do TOFU, you don't learn who you're connecting to
6722018-04-19T19:50:50  <sipa> cfields: the whole point is avoiding having discoverable identities for things that should be identityless
6732018-04-19T19:51:06  <sipa> but sometimes you have a node you trust already (due to external reasons, for example you run it yourself)
6742018-04-19T19:51:21  <sipa> in which case you'd configure an addnode with a known pubkey or so
6752018-04-19T19:51:36  <cfields> sipa: got it, thanks.
6762018-04-19T19:51:51  <cfields> jnewbery: #11457 still, looks like it needs rebase again
6772018-04-19T19:51:54  <sipa> yes, BIP150 can continue independently
6782018-04-19T19:51:54  <gribble> https://github.com/bitcoin/bitcoin/issues/11457 | Introduce BanMan by theuni · Pull Request #11457 · bitcoin/bitcoin · GitHub
6792018-04-19T19:51:56  <cfields> doing now, thanks for the reminder
6802018-04-19T19:51:58  <sipa> eh, BIP151
6812018-04-19T19:52:01  <Murch> cfields: In the case that you for example want to connect with a thin client to your own node, the only valid key you query for is your home node's. If you want to defend against Sybil, you may query a list of known friends and accept any of them. If you just want to scare off a MITM, you query for random keys.
6822018-04-19T19:52:02  *** niska has quit IRC
6832018-04-19T19:52:28  <sipa> this is just a replacement for the authentication part; it needs an existing encrypted connection to run over anyway
6842018-04-19T19:52:49  * jonasschnelli will continue with 151
6852018-04-19T19:53:14  <LukeJr> how does one authenticate the encryption key?
6862018-04-19T19:53:20  <sipa> you don't
6872018-04-19T19:53:39  <jonasschnelli> bip151 does not protect from MITM
6882018-04-19T19:53:40  <sipa> encryption is done with ephemeral keys, and is completely unauthenticated
6892018-04-19T19:53:46  <sipa> it does not protect against MitM
6902018-04-19T19:53:51  <jonasschnelli> Only from passible observing and undetectable interception
6912018-04-19T19:53:55  <jonasschnelli> *passive
6922018-04-19T19:54:11  <sipa> but then you run an authentication protocol which can determine if the party you are talking to (possibly the MitM) is who you think it is
6932018-04-19T19:54:36  <sipa> anyway, enough on the topic
6942018-04-19T19:54:44  <sipa> just wanted to give an update that there are some cool ideas
6952018-04-19T19:54:50  <wumpus> yes, thanks!
6962018-04-19T19:54:54  * sipa lunch
6972018-04-19T19:55:00  <jonasschnelli> thanks sipa for working on this!
6982018-04-19T19:55:22  <wumpus> unless someone has a very quick last-minutet topic I think that was the last topic for today
6992018-04-19T19:56:02  <wumpus> clear :)
7002018-04-19T19:56:03  <wumpus> #endmeeting
7012018-04-19T19:56:03  <lightningbot> Meeting ended Thu Apr 19 19:56:03 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7022018-04-19T19:56:03  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.html
7032018-04-19T19:56:03  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.txt
7042018-04-19T19:56:03  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.log.html
7052018-04-19T19:56:10  *** LukeJr has quit IRC
7062018-04-19T19:57:23  <promag> jtimon: sorry, forgot about #10757
7072018-04-19T19:57:24  *** niska has joined #bitcoin-core-dev
7082018-04-19T19:57:27  <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
7092018-04-19T19:57:44  *** promag has quit IRC
7102018-04-19T20:04:37  <phantomcircuit> sipa, separating encryption and authentication like that has the potential for an obvious mistake
7112018-04-19T20:05:05  <phantomcircuit> mitm encryption and then fail to authenticate the shared secret used for encryption
7122018-04-19T20:08:34  *** isis_ is now known as isis
7132018-04-19T20:08:37  *** Murch has quit IRC
7142018-04-19T20:09:01  *** Krellan has joined #bitcoin-core-dev
7152018-04-19T20:13:49  *** wxss has quit IRC
7162018-04-19T20:13:58  *** promag has joined #bitcoin-core-dev
7172018-04-19T20:15:01  *** promag has quit IRC
7182018-04-19T20:16:20  *** moneyball has quit IRC
7192018-04-19T20:21:37  <achow101> question about wallet hd upgrade path (#12560): is it preferable to warn that a new backup is needed for -upgradewallet or just use a new option entirely?
7202018-04-19T20:21:40  <gribble> https://github.com/bitcoin/bitcoin/issues/12560 | [wallet] Upgrade path for non-HD wallets to HD by achow101 · Pull Request #12560 · bitcoin/bitcoin · GitHub
7212018-04-19T20:24:42  *** Murch has joined #bitcoin-core-dev
7222018-04-19T20:25:19  *** clarkmoody has quit IRC
7232018-04-19T20:29:30  *** Murch has quit IRC
7242018-04-19T20:30:06  *** Murch has joined #bitcoin-core-dev
7252018-04-19T20:33:34  <sipa> phantomcircuit: then you just have an unauthenticated connection that's still safe from passive attackers
7262018-04-19T20:34:26  *** clarkmoody has joined #bitcoin-core-dev
7272018-04-19T20:38:35  *** votefrac has quit IRC
7282018-04-19T20:40:06  *** tryphe_ has quit IRC
7292018-04-19T20:41:03  *** tryphe has joined #bitcoin-core-dev
7302018-04-19T20:42:25  *** AndroUser has joined #bitcoin-core-dev
7312018-04-19T20:47:28  *** votefrac has joined #bitcoin-core-dev
7322018-04-19T20:49:23  *** isis is now known as isis_
7332018-04-19T20:50:49  *** Randolf has quit IRC
7342018-04-19T20:53:58  *** Murch has quit IRC
7352018-04-19T20:55:29  *** Guyver2 has quit IRC
7362018-04-19T20:58:30  *** Murch has joined #bitcoin-core-dev
7372018-04-19T21:00:53  *** cryptojanitor has joined #bitcoin-core-dev
7382018-04-19T21:20:09  *** votefrac has quit IRC
7392018-04-19T21:22:58  *** TheCharlatan has joined #bitcoin-core-dev
7402018-04-19T21:23:29  *** Chris_Stewart_5 has quit IRC
7412018-04-19T21:29:14  *** Dizzle has quit IRC
7422018-04-19T21:30:12  <phantomcircuit> sipa, yeah but you get what im saying im sure
7432018-04-19T21:35:12  <jimpo> Sorry, I missed meeting. So I should open a new PR for #11857? It also loads for me, but I can do that if people want...
7442018-04-19T21:35:16  <gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
7452018-04-19T21:35:33  *** dongcarl has quit IRC
7462018-04-19T21:38:07  *** Randolf has joined #bitcoin-core-dev
7472018-04-19T21:38:17  <jimpo> Also, I'd really like to get #13021 in before I have to rebase it again
7482018-04-19T21:38:19  <gribble> https://github.com/bitcoin/bitcoin/issues/13021 | MOVEONLY: Move logging code from util.{h,cpp} to new files. by jimpo · Pull Request #13021 · bitcoin/bitcoin · GitHub
7492018-04-19T21:38:38  *** clarkmoody has quit IRC
7502018-04-19T21:39:24  *** Giszmo has joined #bitcoin-core-dev
7512018-04-19T21:39:26  *** AndroUser has quit IRC
7522018-04-19T21:48:03  *** Randolf has quit IRC
7532018-04-19T21:49:06  *** LeMiner has quit IRC
7542018-04-19T21:50:19  *** arbitrary_guy has joined #bitcoin-core-dev
7552018-04-19T21:51:20  *** jcohen has quit IRC
7562018-04-19T21:56:37  *** meshcollider has quit IRC
7572018-04-19T21:57:12  *** isis_ is now known as isis
7582018-04-19T22:01:44  *** spinza has quit IRC
7592018-04-19T22:20:12  *** echonaut has quit IRC
7602018-04-19T22:20:18  *** echonaut2 has joined #bitcoin-core-dev
7612018-04-19T22:25:47  *** bedotech has quit IRC
7622018-04-19T22:28:11  *** spinza has joined #bitcoin-core-dev
7632018-04-19T22:31:25  *** promag has joined #bitcoin-core-dev
7642018-04-19T22:39:51  *** ProfMac has quit IRC
7652018-04-19T22:46:59  <bitcoin-git> [bitcoin] sipsorcery opened pull request #13031: Fix for utiltime to compile with msvc. (master...msvc_gmtime) https://github.com/bitcoin/bitcoin/pull/13031
7662018-04-19T22:52:30  *** ProfMac has joined #bitcoin-core-dev
7672018-04-19T22:59:49  *** bzb has joined #bitcoin-core-dev
7682018-04-19T23:10:32  *** arbitrary_guy has quit IRC
7692018-04-19T23:11:31  *** arbitrary_guy has joined #bitcoin-core-dev
7702018-04-19T23:17:33  *** isis is now known as isis_
7712018-04-19T23:28:29  *** Cogito_Ergo_Sum has quit IRC
7722018-04-19T23:34:29  *** Randolf has joined #bitcoin-core-dev
7732018-04-19T23:40:03  <achow101> BlueMatt: what's your idea for detecting old keypool keys?
7742018-04-19T23:41:02  *** d9b4bef9 has quit IRC
7752018-04-19T23:42:08  *** d9b4bef9 has joined #bitcoin-core-dev
7762018-04-19T23:43:01  *** d9b4bef9 has quit IRC
7772018-04-19T23:44:07  *** d9b4bef9 has joined #bitcoin-core-dev
7782018-04-19T23:55:18  <bitcoin-git> [bitcoin] kristapsk opened pull request #13032: Output values for "min relay fee not met" error (master...min-relay-fee-not-met-debug) https://github.com/bitcoin/bitcoin/pull/13032