12019-04-03T00:20:31  *** fanquake has quit IRC
  22019-04-03T00:37:53  <gwillen> hmmm, can someone tell me why CoinControlDialog uses a static CoinControl object, instead of like, having the caller supply one
  32019-04-03T00:37:59  <gwillen> I expect the answer is "because it was easier"
  42019-04-03T01:06:37  *** AaronvanW has quit IRC
  52019-04-03T01:08:16  *** timothy has quit IRC
  62019-04-03T01:09:45  *** echonaut1 has joined #bitcoin-core-dev
  72019-04-03T01:12:06  *** achow101_ has joined #bitcoin-core-dev
  82019-04-03T01:12:33  *** echonaut has quit IRC
  92019-04-03T01:12:34  *** BGL has quit IRC
 102019-04-03T01:12:34  *** Evel-Knievel has quit IRC
 112019-04-03T01:12:34  *** achow101 has quit IRC
 122019-04-03T01:12:35  *** owowo has quit IRC
 132019-04-03T01:13:10  *** Evel-Knievel has joined #bitcoin-core-dev
 142019-04-03T01:13:24  *** owowo has joined #bitcoin-core-dev
 152019-04-03T01:14:16  *** fanquake has joined #bitcoin-core-dev
 162019-04-03T01:15:12  *** phantomcircuit has quit IRC
 172019-04-03T01:16:03  <fanquake> I assume this was accidental, rather than spam (as it was reverted right after). Just need to keep an eye on the wiki.. https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft/_compare/af6d617%5E...af6d617
 182019-04-03T01:17:42  *** phantomcircuit has joined #bitcoin-core-dev
 192019-04-03T01:22:04  *** Krellan has quit IRC
 202019-04-03T01:49:55  <conman> gmaxwell: did some more testing
 212019-04-03T01:50:03  <conman> I picked a random transaction from the mempool
 222019-04-03T01:50:10  <conman> if it's a regular transaction I can prioritise it
 232019-04-03T01:50:20  <conman> if it's a segwit one I canNOT get it into the template
 242019-04-03T01:50:42  <conman> I picked a random txn (not mine) with the txid f8ac1bf739aace5c10fbde87d387e47a2536e897a738a65e1f153fe02ddabf01
 252019-04-03T01:50:49  <conman> see if you can prioritise it
 262019-04-03T01:51:07  <conman> its fee is 2590s
 272019-04-03T01:57:50  *** nanotube has quit IRC
 282019-04-03T01:59:50  *** achow101_ is now known as achow101
 292019-04-03T02:01:01  *** nanotube has joined #bitcoin-core-dev
 302019-04-03T02:02:22  *** achow101 is now known as achow101_
 312019-04-03T02:02:31  *** achow101_ is now known as achow101
 322019-04-03T02:09:28  *** BGL has joined #bitcoin-core-dev
 332019-04-03T02:53:54  <conman> yep I cannot successfully prioritise any segwit transactions into the block template
 342019-04-03T03:49:20  *** tynes has joined #bitcoin-core-dev
 352019-04-03T04:03:51  *** ossifrage has quit IRC
 362019-04-03T04:04:11  *** ossifrage has joined #bitcoin-core-dev
 372019-04-03T04:46:14  <gmaxwell> conman: can you take a segwit txn that is already in the template and prioritize it so it goes from near the bottom to near the top?
 382019-04-03T04:46:14  *** arubi has quit IRC
 392019-04-03T04:46:35  *** arubi has joined #bitcoin-core-dev
 402019-04-03T05:08:41  *** hebasto has joined #bitcoin-core-dev
 412019-04-03T05:10:48  *** Krellan_ has joined #bitcoin-core-dev
 422019-04-03T05:24:25  <conman> ok lemme try
 432019-04-03T05:29:54  <conman> of course all the ones low down are NOT segwit txns..
 442019-04-03T05:35:37  <conman> man just how few segwit txns are there...
 452019-04-03T05:39:12  <gmaxwell> do you have any?
 462019-04-03T05:39:13  <gmaxwell> ./bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' | jq '.transactions | .[] | select(.hash != .txid)'
 472019-04-03T05:39:38  <gmaxwell> I see 1090 in my template...
 482019-04-03T05:39:47  <conman> thanks that's what I needed to help
 492019-04-03T05:40:13  <gmaxwell> so about 40% of them.
 502019-04-03T05:40:35  <conman> yeah I was just randomly picking them off the bottom and looking at them
 512019-04-03T05:40:40  <conman> silly me
 522019-04-03T05:40:46  <conman> since I know nought of this
 532019-04-03T05:41:52  <conman> ok I prioritised the lowest priority one I could find
 542019-04-03T05:41:53  <gmaxwell> FWIW, it worked for me (with 0.18rc) -- I picked the bottom segwit txn, prioritised it, and it's now the second transaction in my template.
 552019-04-03T05:42:01  <conman> and now it no longer appears in the block template at all
 562019-04-03T05:42:10  <conman> let's try again
 572019-04-03T05:42:26  <gmaxwell> OH how high is your priority? is it possible that there is an overflow somwhere?
 582019-04-03T05:42:40  <gmaxwell> I did: $ ./bitcoin-cli prioritisetransaction 35611cbad11967731aa122136bf90bd63c5224296c45c10a26885c3bb3fff6f6 0 100000
 592019-04-03T05:42:40  <gmaxwell> true
 602019-04-03T05:42:46  <conman> 0.1btc
 612019-04-03T05:42:55  <conman> so 10000000
 622019-04-03T05:43:06  <conman> again, same thing happened this time around
 632019-04-03T05:43:10  <conman> I'll try smaller then
 642019-04-03T05:43:24  <conman> but note that size priority worked fine on a regular transaction
 652019-04-03T05:43:25  <gmaxwell> I tried 10000000 ... now its the first one.
 662019-04-03T05:43:32  <conman> then wtf is going on here
 672019-04-03T05:44:11  <gmaxwell> bug in 0.17 that is fixed in 0.18? I just don't recall any such changes.
 682019-04-03T05:44:46  <conman> every prioritised one disappears instead of moving up
 692019-04-03T05:45:19  <conman> hang on, maybe I'm searching for it wrong in the template
 702019-04-03T05:47:03  <gmaxwell> I'm just ./bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' | jq '.transactions | .[] | select(.hash != .txid)' |less  and hitting / and pasting in the txid.
 712019-04-03T05:47:22  <gmaxwell> and I successfully move something to the top, then undo the priority and it goes back down to near the bottom.
 722019-04-03T05:47:29  <conman> I'm not adding rules to getblocktemplate...
 732019-04-03T05:47:41  <conman> is that what I'm doing wrong?
 742019-04-03T05:48:04  <conman> doesn't explain how it's been generating templates with segwit txns all the time
 752019-04-03T05:48:25  <conman> I was just doing getblocktemplate | grep
 762019-04-03T05:49:00  <conman> or | less and then / searching
 772019-04-03T05:49:01  <gmaxwell> oh man..
 782019-04-03T05:49:04  <conman> :(
 792019-04-03T05:49:12  * conman hides
 802019-04-03T05:49:24  <gmaxwell> So I did ask...
 812019-04-03T05:49:28  <gmaxwell> in 0.18 this isn't a problem:
 822019-04-03T05:49:44  <gmaxwell> $ ./bitcoin-cli getblocktemplate
 832019-04-03T05:49:44  <gmaxwell> error code: -8
 842019-04-03T05:49:44  <gmaxwell> error message:
 852019-04-03T05:49:44  <gmaxwell> getblocktemplate must be called with the segwit rule set (call with {"rules": ["segwit"]})
 862019-04-03T05:49:55  <conman> I see
 872019-04-03T05:50:07  <gmaxwell> but for backwards compat reasons gbt won't include any segwit txn unless called with rules (and in 0.18 that functionality is disabled)
 882019-04-03T05:50:24  <conman> I'm just going to rock back and forth in the corner
 892019-04-03T05:50:49  <gmaxwell> I would have asked harder but I didn't remember when the backwards compat was turned off,  I kinda assumed 0.17 had it too, so I didn't ask more than once. Sorry.
 902019-04-03T05:51:03  <conman> don't be sorry, it's all my fault
 912019-04-03T05:51:07  <gmaxwell> this was a known footgun thus the new behavior in 0.18.
 922019-04-03T05:51:16  <conman> for some reason I thought the rules were on by default
 932019-04-03T05:51:36  <gmaxwell> yea, they aren't just because if you had non-segwit capable mining software you'd start silently mining invalid blocks.
 942019-04-03T05:51:46  <gmaxwell> And we'd rather it fail cleanly.
 952019-04-03T05:53:19  <conman> ok well that's been a big learning experience
 962019-04-03T05:53:31  <conman> for all the wrong reasons
 972019-04-03T05:53:40  <gmaxwell> thanks for the confirmation that 0.18's behavior change is a useful de-footgunning. :P
 982019-04-03T05:55:04  <conman> of course the pool software doesn't do that so no idea why I didn't think of it for the command line :s
 992019-04-03T05:55:40  <conman> I really have to get out of this game, it's bad for my health
1002019-04-03T05:56:48  *** nanotube has quit IRC
1012019-04-03T05:57:21  <conman> thanks again
1022019-04-03T05:57:29  <gmaxwell> sorry, this interface was bad-- just an annoying consequence of backwards compatiblity. That much isn't your fault. :)
1032019-04-03T05:57:37  <gmaxwell> I'm glad it wasn't a weird bug though.
1042019-04-03T06:01:02  *** nanotube has joined #bitcoin-core-dev
1052019-04-03T06:12:04  *** spinza has quit IRC
1062019-04-03T06:24:47  *** rex4539 has quit IRC
1072019-04-03T06:25:36  *** spinza has joined #bitcoin-core-dev
1082019-04-03T06:25:55  * conman quietly disappears
1092019-04-03T06:25:57  *** conman has left #bitcoin-core-dev
1102019-04-03T06:27:06  <gmaxwell> Next Customer!
1112019-04-03T06:27:39  * gmaxwell is sad that he has still not learned the zen of tech support.
1122019-04-03T06:27:45  <gwillen> gmaxwell: can you help me with this terrible pain I have in all the diodes down my left side
1132019-04-03T06:28:12  <gmaxwell> gwillen: have you had them replaced?
1142019-04-03T06:30:45  <gmaxwell> When I worked for Juniper I was often amazed at how the really good tech support people managed to solve some feindishly hard problems that no one else could solve by being single mindedly consistent about asking all the dumb questions and carefully validating every claim and piece of information.
1152019-04-03T06:31:14  <gmaxwell> And yet, no matter how much I tell myself that I _must_ ask the 'dumb' questions to get compariable results, I still manage to fail.
1162019-04-03T06:36:09  *** windsok has quit IRC
1172019-04-03T06:45:36  *** DeanGuss has joined #bitcoin-core-dev
1182019-04-03T06:47:25  *** Soligor has joined #bitcoin-core-dev
1192019-04-03T06:47:29  *** rex4539 has joined #bitcoin-core-dev
1202019-04-03T06:48:12  <wumpus> gwillen: yes the global coin control object is kind of ugly, and very much different from how the rest of the GUI code works; basically because the original author wrote it like that, and people kind of wanted the functionality so didn't want to hold up the merge for it, it was expected that someone would improve it down the line
1212019-04-03T06:49:28  <wumpus> gwillen: I'm somewhat surprised it doesn't give trouble with multiple wallets
1222019-04-03T06:54:53  *** windsok has joined #bitcoin-core-dev
1232019-04-03T07:03:06  <gwillen> wumpus: ... actually it appears to be pretty broken with multiple wallets
1242019-04-03T07:03:16  <gwillen> I never thought to try that
1252019-04-03T07:04:05  <gwillen> it seems to keep UTXOs selected when switching wallets that don't exist in the second wallet
1262019-04-03T07:04:11  <gwillen> I'm not sure what happens if I then try to spend them.
1272019-04-03T07:04:27  <gwillen> perhaps this is the secret backdoor way to spend from multiple wallets at once, heh
1282019-04-03T07:05:35  <gwillen> anyway I am tempted to fix it but I don't have spare cycles right now, ask me again in a month or two and I'll probably do it
1292019-04-03T07:07:56  *** Guyver2 has joined #bitcoin-core-dev
1302019-04-03T07:14:44  *** Dean_Guss has joined #bitcoin-core-dev
1312019-04-03T07:14:49  *** DeanGuss has quit IRC
1322019-04-03T07:16:31  *** fanquake has quit IRC
1332019-04-03T07:27:31  <wumpus> gwillen: please create an issue for it at least
1342019-04-03T07:29:36  <wumpus> fanquake: thanks for keeping an eye on changes to the release notes-if this keeps up we'll have to restrict edits to people in the bitcoin-core org (I'd prefer not to as this loses some potential documentation-only contributors), but this may well be accidental and they fixed it
1352019-04-03T07:49:45  *** fanquake has joined #bitcoin-core-dev
1362019-04-03T07:57:36  <gwillen> wumpus: hmm, this may be either caused or revealed by my changes, investigating before I file it
1372019-04-03T08:00:06  <jonasschnelli> cfields: 0.18.0rc3 osx detached signatures are here: https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/24
1382019-04-03T08:00:58  <gmaxwell> I've been watching logs on a couple nodes and it looks like new installs of 0.16.1 are significantly more common than later versions.
1392019-04-03T08:01:04  <gmaxwell> I wonder if there is some outdated link someplace.
1402019-04-03T08:01:19  <wumpus> maybe some distro did the cursed thing
1412019-04-03T08:01:36  <gmaxwell> (or there is some spy/sybil-attacker that looks like these things, but I don't think so as I'm already pretty heavily excluding things that look like that)
1422019-04-03T08:01:41  <wumpus> (e.g. freeze one version of bitcoin core as "stable")
1432019-04-03T08:03:07  <gmaxwell> Checking my logs most of them appear to be IPs in china.
1442019-04-03T08:03:59  <gmaxwell> jl2012: ^ any thoughts for this? is it possible some high visibility chinese language bitcoin resource links to 0.16.1 ?
1452019-04-03T08:07:35  <gmaxwell> looks like 98% of them are chinese.
1462019-04-03T08:09:12  <jl2012> I'll take a look
1472019-04-03T08:10:10  <jl2012> Are they from random ip, or from a few datacenters?
1482019-04-03T08:10:32  *** setpill has joined #bitcoin-core-dev
1492019-04-03T08:12:23  <gmaxwell> Many, though a large number are from 1.196.144.0/24
1502019-04-03T08:13:12  *** setpill has quit IRC
1512019-04-03T08:18:23  *** setpill has joined #bitcoin-core-dev
1522019-04-03T08:24:39  <gwillen> wumpus: filed #15725, I can't make this happen every time but it's reliable enough that I'm convinced it's probably not anything I touched
1532019-04-03T08:24:40  <gribble> https://github.com/bitcoin/bitcoin/issues/15725 | Manual coin control dialog interacts badly with multiple wallets · Issue #15725 · bitcoin/bitcoin · GitHub
1542019-04-03T08:26:55  <wumpus> gwillen: thank you
1552019-04-03T08:36:18  *** Zenton has joined #bitcoin-core-dev
1562019-04-03T08:51:04  *** timothy has joined #bitcoin-core-dev
1572019-04-03T09:07:01  <fanquake> Added a validating subtree merges how-to to core-review: https://github.com/fanquake/core-review/blob/master/subtree-merge.md
1582019-04-03T09:09:05  <fanquake> Also, anyone is upgrading to Xcode 10.2, you may have to re-install the macOS_SDK_headers.pkg, otherwise your depends builds may break.
1592019-04-03T09:25:52  *** kryoha has joined #bitcoin-core-dev
1602019-04-03T09:38:48  <wumpus> fanquake: this is very useful, thanks for working on that document
1612019-04-03T09:41:30  <wumpus> I think we also need to document the exact steps to update the various subtrees, there's some overlap with the "Subtrees" section in doc/developer-notes.md btw
1622019-04-03T09:47:34  *** bitcoin-git has joined #bitcoin-core-dev
1632019-04-03T09:47:35  <bitcoin-git> [bitcoin] ajtowns opened pull request #15726: bitcoin-cli -yaml support (master...201904-cli-yaml) https://github.com/bitcoin/bitcoin/pull/15726
1642019-04-03T09:47:48  *** bitcoin-git has left #bitcoin-core-dev
1652019-04-03T09:57:29  *** kryoha has quit IRC
1662019-04-03T10:01:21  <wumpus> yaml?!?
1672019-04-03T10:04:56  *** Nakamoto has joined #bitcoin-core-dev
1682019-04-03T10:12:13  *** nullptr| has quit IRC
1692019-04-03T10:13:22  <fanquake> wumpus Yea just documenting useful stuff. All the things I do infrequently enough that I have to go look it/the process up again.
1702019-04-03T10:18:41  *** nullptr| has joined #bitcoin-core-dev
1712019-04-03T10:18:50  <aj> wumpus: i can't read numbers without thousands separators man
1722019-04-03T10:19:03  *** jonatack has joined #bitcoin-core-dev
1732019-04-03T10:19:33  *** spinza has quit IRC
1742019-04-03T10:29:04  *** Nakamoto has quit IRC
1752019-04-03T10:35:15  *** AaronvanW has joined #bitcoin-core-dev
1762019-04-03T10:37:12  *** spinza has joined #bitcoin-core-dev
1772019-04-03T11:16:13  *** michaelfolkson has joined #bitcoin-core-dev
1782019-04-03T11:43:37  *** zivl has quit IRC
1792019-04-03T11:48:01  *** jonatack has quit IRC
1802019-04-03T11:56:04  *** zivl has joined #bitcoin-core-dev
1812019-04-03T11:57:03  *** michaelfolkson has quit IRC
1822019-04-03T12:00:27  *** emzy has quit IRC
1832019-04-03T12:03:51  *** emzy has joined #bitcoin-core-dev
1842019-04-03T12:04:03  *** emzy has quit IRC
1852019-04-03T12:08:00  *** michaelfolkson has joined #bitcoin-core-dev
1862019-04-03T12:09:47  *** DeanWeen has joined #bitcoin-core-dev
1872019-04-03T12:10:23  *** michaelfolkson has quit IRC
1882019-04-03T12:13:25  *** Dean_Guss has quit IRC
1892019-04-03T12:17:32  *** michaelfolkson has joined #bitcoin-core-dev
1902019-04-03T12:27:28  *** emzy has joined #bitcoin-core-dev
1912019-04-03T12:31:05  *** emzy has quit IRC
1922019-04-03T12:31:05  *** emzy has joined #bitcoin-core-dev
1932019-04-03T12:31:13  <luke-jr> FWIW, it looks like Boost::Process 1.45 is broken in that it doesn't recongised died-by-signal as exited (and throws exceptions wildly as a result)
1942019-04-03T12:31:17  <luke-jr> 1.47 has it fixed I guess
1952019-04-03T12:36:39  *** DeanWeen has quit IRC
1962019-04-03T12:37:02  <fanquake> luke-jr Boost.Process in Boost 1.45 ? I thought it was only introduced in 1.64? Or are you talking about something else?
1972019-04-03T12:51:06  <luke-jr> sorry, I have my versions wrong, sec
1982019-04-03T12:51:13  <luke-jr> 1.65 vs 1.67
1992019-04-03T13:01:07  *** spaced0ut has quit IRC
2002019-04-03T13:12:37  *** DeanWeen has joined #bitcoin-core-dev
2012019-04-03T13:13:33  *** Karyon has quit IRC
2022019-04-03T13:14:06  *** spaced0ut has joined #bitcoin-core-dev
2032019-04-03T13:16:01  *** shtirlic has quit IRC
2042019-04-03T13:27:07  *** michaelfolkson has quit IRC
2052019-04-03T13:28:40  *** promag has joined #bitcoin-core-dev
2062019-04-03T13:33:16  *** shtirlic has joined #bitcoin-core-dev
2072019-04-03T13:37:18  *** Karyon has joined #bitcoin-core-dev
2082019-04-03T13:46:48  *** bitcoin-git has joined #bitcoin-core-dev
2092019-04-03T13:46:48  <bitcoin-git> [bitcoin] jnewbery opened pull request #15728: [wallet] Refactor relay transactions (master...2019_03_refactor_relay_transactions) https://github.com/bitcoin/bitcoin/pull/15728
2102019-04-03T13:46:50  *** bitcoin-git has left #bitcoin-core-dev
2112019-04-03T13:47:31  *** Aaronvan_ has joined #bitcoin-core-dev
2122019-04-03T13:50:32  *** AaronvanW has quit IRC
2132019-04-03T14:09:04  *** michaelfolkson has joined #bitcoin-core-dev
2142019-04-03T14:13:44  *** michaelfolkson has quit IRC
2152019-04-03T14:17:17  *** spinza has quit IRC
2162019-04-03T14:28:21  *** Aaronvan_ has quit IRC
2172019-04-03T14:35:19  *** pinheadmz has quit IRC
2182019-04-03T15:00:26  *** spinza has joined #bitcoin-core-dev
2192019-04-03T15:02:19  <jl2012> gmaxwell: "Miner block size removed" in the release note of 0.16.1 led to some misunderstanding in China
2202019-04-03T15:02:44  <jl2012> some thought 0.16.1 was a block size hardfork
2212019-04-03T15:05:32  <jl2012> but those were results from June 2018. No recent discussions
2222019-04-03T15:06:07  <jl2012> and some people clarified that in Chinese at that time
2232019-04-03T15:31:51  *** bitcoin-git has joined #bitcoin-core-dev
2242019-04-03T15:31:51  <bitcoin-git> [bitcoin] promag opened pull request #15729: rpc: Ignore minconf parameter in getbalance (master...2019-04-drop-getbalance-minconf) https://github.com/bitcoin/bitcoin/pull/15729
2252019-04-03T15:31:52  *** bitcoin-git has left #bitcoin-core-dev
2262019-04-03T15:43:32  *** cheetah2 has joined #bitcoin-core-dev
2272019-04-03T15:45:33  <cheetah2> im getting error code -28 prunning blockstore with bitcoin-cli getinfo does it mean its crashed or is it working?
2282019-04-03T15:50:13  *** pinheadmz has joined #bitcoin-core-dev
2292019-04-03T16:03:13  *** cheetah2 has quit IRC
2302019-04-03T16:05:50  *** setpill has quit IRC
2312019-04-03T16:09:30  *** AaronvanW has joined #bitcoin-core-dev
2322019-04-03T16:10:04  *** bitcoin-git has joined #bitcoin-core-dev
2332019-04-03T16:10:04  <bitcoin-git> [bitcoin] promag opened pull request #15730: rpc: Show scanning details in getwalletinfo (master...2019-04-getwalletinfo-scanning) https://github.com/bitcoin/bitcoin/pull/15730
2342019-04-03T16:10:14  *** bitcoin-git has left #bitcoin-core-dev
2352019-04-03T16:12:20  *** Aaronvan_ has joined #bitcoin-core-dev
2362019-04-03T16:14:45  *** Aaronvan_ is now known as AaronvanW_
2372019-04-03T16:15:27  *** Tralfaz has quit IRC
2382019-04-03T16:15:42  *** AaronvanW has quit IRC
2392019-04-03T16:20:14  *** bitcoin-git has joined #bitcoin-core-dev
2402019-04-03T16:20:14  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2c364fde423e...ba54342c9dd3
2412019-04-03T16:20:14  <bitcoin-git> bitcoin/master fa292ad MarcoFalke: doc: rpc-mining: Clarify error messages
2422019-04-03T16:20:15  <bitcoin-git> bitcoin/master ba54342 MarcoFalke: Merge #15685: doc: rpc-mining: Clarify error messages
2432019-04-03T16:20:16  *** bitcoin-git has left #bitcoin-core-dev
2442019-04-03T16:20:45  *** joshmg has joined #bitcoin-core-dev
2452019-04-03T16:21:04  *** bitcoin-git has joined #bitcoin-core-dev
2462019-04-03T16:21:04  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15685: doc: rpc-mining: Clarify error messages (master...1903-docMining) https://github.com/bitcoin/bitcoin/pull/15685
2472019-04-03T16:21:08  *** bitcoin-git has left #bitcoin-core-dev
2482019-04-03T16:25:48  <MarcoFalke> proposedmeetingtopic: TODOs in 0.18.0 Release Notes Draft
2492019-04-03T16:31:33  <MarcoFalke> [05:41] <wumpus> I think we also need to document the exact steps to update the various subtrees, there's some overlap with the "Subtrees" section in doc/developer-notes.md btw
2502019-04-03T16:31:36  <MarcoFalke> fanquake:
2512019-04-03T16:31:45  <MarcoFalke> Those exist in https://github.com/bitcoin/bitcoin/tree/ba54342c9dd3f2e5cdeed9ac57f1924f0d885cc6/test/lint#git-subtree-checksh
2522019-04-03T16:31:51  <MarcoFalke> and https://github.com/bitcoin-core/bitcoin-maintainer-tools/tree/ae4ed2a58d67764dbfe2dc1ba00667659e330090#subtree-updates
2532019-04-03T16:40:48  *** pinheadmz has quit IRC
2542019-04-03T16:45:31  *** pinheadmz has joined #bitcoin-core-dev
2552019-04-03T16:51:37  *** AaronvanW_ has quit IRC
2562019-04-03T16:59:14  *** jarthur has joined #bitcoin-core-dev
2572019-04-03T16:59:37  *** pinheadmz has quit IRC
2582019-04-03T17:03:58  <instagibbs> the bitcoin-maintainer one is the more useful one IIRC
2592019-04-03T17:05:43  *** jarthur has quit IRC
2602019-04-03T17:06:10  *** jarthur has joined #bitcoin-core-dev
2612019-04-03T17:17:42  *** jarthur has quit IRC
2622019-04-03T17:18:09  *** jarthur has joined #bitcoin-core-dev
2632019-04-03T17:21:37  *** jarthur has quit IRC
2642019-04-03T17:22:04  *** jarthur has joined #bitcoin-core-dev
2652019-04-03T17:22:36  <MarcoFalke> They serve different purposes. The "linter" is for checking and the maintainer-tool is for creating/bumping
2662019-04-03T17:24:12  <cfields> jonasschnelli: not sure if you've discussed already, but it looks like you pushed your rc2 gitian sigs as rc3 accidentally.
2672019-04-03T17:24:41  <cfields> Though your signature attached and verified correctly. So I assume you just pushed the wrong thing on accident.
2682019-04-03T17:25:44  <cfields> err
2692019-04-03T17:29:30  *** shesek has quit IRC
2702019-04-03T17:36:23  <cfields> jonasschnelli: yes, ok, ^^.
2712019-04-03T17:36:58  <cfields> I'm not going to worry about waiting for updated sigs, though. We have enough, and it looks like the correct thing was signed in the end.
2722019-04-03T17:39:52  <cfields> gitian builders: detached sigs are pushed for v0.18.0rc3.
2732019-04-03T17:42:07  *** Zenton has quit IRC
2742019-04-03T17:46:19  *** morcos has quit IRC
2752019-04-03T17:46:36  *** morcos has joined #bitcoin-core-dev
2762019-04-03T17:53:30  *** pinheadmz has joined #bitcoin-core-dev
2772019-04-03T17:54:29  *** ExtraCrispy has quit IRC
2782019-04-03T17:54:59  *** ExtraCrispy has joined #bitcoin-core-dev
2792019-04-03T17:59:06  *** pinheadmz has quit IRC
2802019-04-03T18:00:26  *** pinheadmz has joined #bitcoin-core-dev
2812019-04-03T18:07:17  <jonasschnelli> cfields: oh. let me check
2822019-04-03T18:07:57  *** pinheadmz has quit IRC
2832019-04-03T18:16:48  *** pinheadmz has joined #bitcoin-core-dev
2842019-04-03T18:20:01  <jonasschnelli> cfields: yes. I uploaded the rc2 sigs for osx/win (not for linux though).
2852019-04-03T18:20:07  <jonasschnelli> Will fix
2862019-04-03T18:25:30  *** dviola has joined #bitcoin-core-dev
2872019-04-03T18:39:02  *** hebasto has quit IRC
2882019-04-03T18:41:30  *** d_t has joined #bitcoin-core-dev
2892019-04-03T18:45:55  *** kexkey has joined #bitcoin-core-dev
2902019-04-03T19:02:25  *** shesek has joined #bitcoin-core-dev
2912019-04-03T19:02:25  *** shesek has joined #bitcoin-core-dev
2922019-04-03T19:03:43  *** pinheadmz has joined #bitcoin-core-dev
2932019-04-03T19:06:50  *** jarthur has quit IRC
2942019-04-03T19:12:31  *** jtimon has joined #bitcoin-core-dev
2952019-04-03T19:14:37  *** owowo has quit IRC
2962019-04-03T19:18:30  *** beau has joined #bitcoin-core-dev
2972019-04-03T19:19:42  *** owowo has joined #bitcoin-core-dev
2982019-04-03T19:19:58  *** beau has quit IRC
2992019-04-03T19:30:36  *** jarthur has joined #bitcoin-core-dev
3002019-04-03T19:35:00  <wumpus> MarcoFalke: good to know, I think I knew about that one once but forgot about it
3012019-04-03T19:45:57  *** Zenton has joined #bitcoin-core-dev
3022019-04-03T19:52:10  *** mn9495881 has joined #bitcoin-core-dev
3032019-04-03T20:04:55  *** EagleTM has joined #bitcoin-core-dev
3042019-04-03T20:08:54  *** timothy has quit IRC
3052019-04-03T20:49:07  *** Guyver2 has quit IRC
3062019-04-03T21:17:25  *** DeanWeen has quit IRC
3072019-04-03T21:40:56  *** bitcoin-git has joined #bitcoin-core-dev
3082019-04-03T21:40:56  <bitcoin-git> [bitcoin] jamesob opened pull request #15735: Add scheduler deadlock detection (master...2019-04-serialize-scheduler) https://github.com/bitcoin/bitcoin/pull/15735
3092019-04-03T21:40:57  *** bitcoin-git has left #bitcoin-core-dev
3102019-04-03T21:43:52  <gmaxwell> jl2012: there isn't a chinese version of bitcoin.org or something that only shows old links?  I'm just at a loss as to what would be causing people to start new nodes using old code.
3112019-04-03T21:45:42  *** pinheadmz has quit IRC
3122019-04-03T21:48:35  *** pinheadmz has joined #bitcoin-core-dev
3132019-04-03T21:49:58  <phantomcircuit> gmaxwell, are they all on aws or something?
3142019-04-03T21:50:11  <midnightmagic> gmaxwell: the TMSR people and their propaganda maybe?
3152019-04-03T21:51:07  *** AaronvanW has joined #bitcoin-core-dev
3162019-04-03T21:52:53  <gwillen> sipa or someone: are descriptors supposed to accept "h" anywhere they would accept "'"?
3172019-04-03T21:53:06  <gwillen> gmaxwell: ^
3182019-04-03T21:54:29  <gwillen> it seems like maybe there is an untested interaction with checksums
3192019-04-03T21:54:42  <gwillen> I am finding that my descriptors with 'h' are being parsed as invalid
3202019-04-03T21:55:17  <gwillen> if I getdescriptorinfo on a descriptor that uses 'h', I get back one that uses "'" and has a valid checksum, but if I then replace the ' with h and keep the checksum the same, the resulting descriptor is rejected
3212019-04-03T21:56:09  <sipa> gwillen: yes, you can use either h or '
3222019-04-03T21:56:16  <sipa> and the checksum will depend on which one you use
3232019-04-03T21:56:19  <gwillen> hmmmmmm
3242019-04-03T21:56:36  <gwillen> but getdescriptorinfo canonicalizes from "h" to "'" _before_ computing the checksum
3252019-04-03T21:56:40  <gwillen> so I can't get one with h :-)
3262019-04-03T21:56:49  <sipa> yes
3272019-04-03T21:56:51  <gwillen> also it seems weird that they are treated differently, I would argue against that but maybe it's too late
3282019-04-03T21:56:53  *** shtirlic has quit IRC
3292019-04-03T21:57:14  <sipa> gwillen: the alternative would require a checksum algorithm that's not black box
3302019-04-03T21:57:35  <gwillen> it would just require that you always canonicalize before checksumming
3312019-04-03T21:57:44  <gwillen> since it seems like the very first thing you do on parsing is canonicalize anyway
3322019-04-03T21:58:01  <sipa> canonicalizing requiring understand the descriptors
3332019-04-03T21:58:19  <sipa> while checksums can hopefully be performed by things that treat descriptors as strings
3342019-04-03T21:58:38  <sipa> it was probably a mistake to permit both h and ' in the first place, but it's far too late for that
3352019-04-03T21:58:43  <gwillen> this is somewhat sad for dev use, because the primary use of 'h' is not having to quote the apostrophe
3362019-04-03T21:58:51  <gwillen> but there is no easy way to get a checksum on a descriptor that uses h
3372019-04-03T21:58:57  <sipa> ah i see
3382019-04-03T21:58:57  <gwillen> so in practice you always have to use the apostrophe
3392019-04-03T21:59:06  <gwillen> which defeats the purpose of h existting
3402019-04-03T21:59:27  *** joshmg has quit IRC
3412019-04-03T21:59:52  <sipa> well you don't have to use getdescriptorinfo
3422019-04-03T22:00:08  <gwillen> is there an RPC that will checksum a descriptor for me without altering it first
3432019-04-03T22:00:22  <sipa> not an RPC, but there is python code for it
3442019-04-03T22:00:44  <gwillen> can I argue for getdescriptorinfo not to alter the descriptor provided
3452019-04-03T22:00:51  <gwillen> (is there any other issue like this aside from h/'?)
3462019-04-03T22:01:16  <sipa> if you include a private key in the descriptor, the canonical version will drop it
3472019-04-03T22:01:18  *** shtirlic has joined #bitcoin-core-dev
3482019-04-03T22:01:41  <sipa> because that's just syntactic sugar for the public version + simultaneously also conveying the private key
3492019-04-03T22:01:53  <gwillen> except again for the checksum caring about the difference
3502019-04-03T22:02:02  <sipa> yes
3512019-04-03T22:03:28  <gwillen> I am heavily tempted to disable descriptor checksums locally while I'm doing development to make this more usable
3522019-04-03T22:03:31  <gwillen> that is not a good sign :-P
3532019-04-03T22:04:33  <sipa> it wouldn't be hard to add an RPC that just adds the checksum, but otherwise leaves the descriptor untouched
3542019-04-03T22:05:12  <sipa> would that help?
3552019-04-03T22:05:15  <gwillen> that would be helpful, but I also wonder if getdescriptorinfo really needs to canonicalize the descriptor
3562019-04-03T22:05:18  <gwillen> but either one would do, yeah
3572019-04-03T22:05:29  <gwillen> although I'm now building with descriptor checksums disabled anyway, since it was a one-line change
3582019-04-03T22:05:34  <sipa> agree, perhaps it doesn't need to in the first place
3592019-04-03T22:05:38  <gwillen> *nods*
3602019-04-03T22:06:27  <gwillen> if the canonical version were 'h' rather than "'", it wouldn't require parsing to checksum the canonical version, since "'" can't appear anywhere else as far as I know
3612019-04-03T22:06:43  <gwillen> (but this doesn't solve private keys, and also it's surely too late.)
3622019-04-03T22:09:01  <sipa> a side effect of having the checksum depend on the exact string representation also means that 'canonical' version doesn't mean much
3632019-04-03T22:09:16  <sipa> we could change the canonical encoding without breaking anything
3642019-04-03T22:09:35  <gwillen> certainly h is easier to work with than "'"
3652019-04-03T22:09:47  <gwillen> I don't know if it has any downsides I'm not thinking of
3662019-04-03T22:10:37  <sipa> the ' notation is more widespread
3672019-04-03T22:10:58  <gmaxwell> I don't think the rpc turning ' into h would be a problem. It does need to accept ' in inputs, of course.
3682019-04-03T22:11:17  <gwillen> yeah, it should absolutely still accept both
3692019-04-03T22:11:20  <gwillen> right now it turns h into '
3702019-04-03T22:11:40  <sipa> wouldn't be hard to make it not touch it as well
3712019-04-03T22:12:05  <gwillen> hm, I just did a ranged descriptor import with a range of 10,000
3722019-04-03T22:12:08  <gwillen> and it seems to have hung
3732019-04-03T22:12:20  <gwillen> it's been 120 seconds
3742019-04-03T22:12:32  <achow101> I think having the canonical one be 'h' would be better
3752019-04-03T22:12:33  <sipa> is it rescanning?
3762019-04-03T22:12:46  <gwillen> I used {"rescan": false}
3772019-04-03T22:12:53  <sipa> that's ungood
3782019-04-03T22:13:03  <gwillen> I will attach a debugger
3792019-04-03T22:13:07  <achow101> also having getdescriptorinfo give the checksum for descriptors with privkeys too
3802019-04-03T22:14:40  <achow101> gwillen: I think that is not unexpected
3812019-04-03T22:14:46  <gwillen> no?
3822019-04-03T22:15:09  <achow101> IIRC it writes each generated key and key origin data independently without batching (I know, bad idea), so it takes a while due to disk I/O
3832019-04-03T22:15:20  <gwillen> I mean, awhile is awhile, but it's now been like 5 minutes
3842019-04-03T22:15:25  <gwillen> that is a long while to perform 10,000 writes
3852019-04-03T22:15:35  <gwillen> and the gui thread is totally dead now
3862019-04-03T22:15:45  <gwillen> before the GUI was responding but the console wasn't answering RPCs
3872019-04-03T22:16:18  <achow101> hmm, that might be hung and not just taking awhile
3882019-04-03T22:17:25  <gwillen> we are inside CWallet::CanGetAddresses
3892019-04-03T22:18:11  <achow101> gwillen: oh, deadlock?
3902019-04-03T22:18:26  <gwillen> oh, maybe, yeah, we're trying to lock a mutex
3912019-04-03T22:18:29  <achow101> the gui thread probably went into cangetaddresses but can't acquire the lock so it
3922019-04-03T22:18:43  <sipa> gwillen: is this 0.18/master or something with changes by you?
3932019-04-03T22:18:44  <achow101> as the lock is held by the rpc thread for import
3942019-04-03T22:18:53  <gwillen> sipa: changes by me
3952019-04-03T22:19:20  <gwillen> not to any of this though I would expect?
3962019-04-03T22:20:19  <gwillen> it looks like we may indeed be deadlocked trying to take cs_wallet at the top of CanGetAddresses
3972019-04-03T22:20:49  <gmaxwell> What lock would be held before cs_wallet in the call path to CanGetAddresses?  can you get a backtrace?
3982019-04-03T22:21:01  <gmaxwell> (so we can figure out what the other lock involved in the inversion is?)
3992019-04-03T22:21:06  <sipa> gwillen: compile with -DDEBUG_LOCKORDER
4002019-04-03T22:21:10  <sipa> and try to reproduce
4012019-04-03T22:21:17  <gmaxwell> I wonder if essentially anyone has used the GUI with -DDEBUG_LOCKORDER ?
4022019-04-03T22:21:21  <gwillen> let me paste the backtrace first for gmaxwell
4032019-04-03T22:21:25  <gwillen> I will try with debug_lockorder next
4042019-04-03T22:21:42  <sipa> oh, the stack trace (for all threads) should actually tell you just as much
4052019-04-03T22:21:55  <gwillen> there are a lot of threads, how do I backtrace threads in bulk in lldb
4062019-04-03T22:21:59  <gmaxwell> thread apply all bt
4072019-04-03T22:22:11  <gmaxwell> works in gdb, I assume lldb too
4082019-04-03T22:22:19  <gwillen> sadly it does not work in lldb
4092019-04-03T22:22:24  <gwillen> and I cannot gdb because mac
4102019-04-03T22:22:33  <sipa> sadness
4112019-04-03T22:22:47  <gmaxwell> thread backtrace all
4122019-04-03T22:22:48  <gmaxwell> bt all
4132019-04-03T22:22:54  <gwillen> aha
4142019-04-03T22:22:56  <gmaxwell> ^ lldb commands.
4152019-04-03T22:24:13  *** shtirlic has quit IRC
4162019-04-03T22:24:42  <achow101> gwillen: can you check if your wallet file is being modified?
4172019-04-03T22:25:08  <gmaxwell> (being modified while not paused in the debugger)
4182019-04-03T22:25:59  <gmaxwell> GUI hanging in CanGetAddresses doesn't itself imply that there is a deadlock there. e.g. it could just be waiting on a lock that is deadlocked elsewhere, or not even locked but absurdly slow.
4192019-04-03T22:26:08  <gwillen> hm yes, it is being modified
4202019-04-03T22:26:21  <gwillen> it is growing.
4212019-04-03T22:26:24  <achow101> gmaxwell: I'm pretty sure it's hanging in CanGetAddresses because cs_wallet is locked by the inport, which CanGetAddresses needs to acquire
4222019-04-03T22:26:33  <gwillen> it's quite large.
4232019-04-03T22:26:40  <achow101> no shit. that's 10000 keys
4242019-04-03T22:26:50  <gwillen> how big is a key?
4252019-04-03T22:27:13  <gwillen> this seems like support for "not even locked but absurdly slow"
4262019-04-03T22:27:20  <gmaxwell> I was about to say that.
4272019-04-03T22:27:28  <achow101> 33 bytes + keyid a few times + metadata. probably like 80 bytes at least
4282019-04-03T22:27:33  <gmaxwell> key records are on the order of 100 bytes I think.
4292019-04-03T22:28:05  <achow101> i'm testing this locally. it looks like it spends a while on key derivation also
4302019-04-03T22:28:16  <gwillen> does it also duplicate full key origin info for each?
4312019-04-03T22:28:20  <gwillen> that would make it bigger.
4322019-04-03T22:28:23  <achow101> yes
4332019-04-03T22:28:29  <gwillen> we're at 4 megs and growing
4342019-04-03T22:28:36  <achow101> not unexpected
4352019-04-03T22:28:36  <gwillen> so it's definitely more than 80 bytes per.
4362019-04-03T22:28:47  <sipa> key entry + metqdata entry + keypool entry if applicable
4372019-04-03T22:28:49  <sipa> for each
4382019-04-03T22:29:11  <gwillen> I considered picking a more realistic number than 10,000, fwiw, I have no actual need for this to work
4392019-04-03T22:29:17  <sipa> also, uncompresed wallet?
4402019-04-03T22:29:19  <gwillen> I typed it mostly on a lark because computers are fast
4412019-04-03T22:29:28  <sipa> in that case private keys are 270 bytes
4422019-04-03T22:29:28  <gwillen> hm, I don't know, whatever the default is for a new wallet
4432019-04-03T22:29:31  <gmaxwell> well it should be fast this is a bug.
4442019-04-03T22:29:40  *** jarthur has quit IRC
4452019-04-03T22:30:05  <gmaxwell> I mean if you said it took a couple seconds, sure whatever, who cares.
4462019-04-03T22:30:29  <gwillen> yeah
4472019-04-03T22:30:47  <achow101> I just tested it. it took 6 minutes for my machine to do an import of a ranged descriptor for 10000 keys
4482019-04-03T22:30:52  <gwillen> I should clearly go into QA
4492019-04-03T22:31:01  <gwillen> given my ability to provoke software to do stupid shit ;-)
4502019-04-03T22:33:00  <gwillen> filed #15739
4512019-04-03T22:33:01  <gribble> https://github.com/bitcoin/bitcoin/issues/15739 | large ranged descriptor imports are sloooooooooow. · Issue #15739 · bitcoin/bitcoin · GitHub
4522019-04-03T22:33:34  <gmaxwell> I'm gussing it's doing something stupid like opening and closing the wallet for each key.
4532019-04-03T22:33:50  <achow101> gmaxwell: it's not using a batch write. using a batch write should speed it up significantly
4542019-04-03T22:34:06  <sipa> gwillen: it absolutely is doing that
4552019-04-03T22:34:06  <gwillen> even opening and closing the wallet 10,000 times shouldn't take 6 minutes, should it?
4562019-04-03T22:34:21  <sipa> are you on an I/O starved VPS? :p
4572019-04-03T22:34:26  <gmaxwell> gwillen: it writes and fsyncs each time.
4582019-04-03T22:34:32  <gwillen> I guess if every time it opens it, it scans and validates a bunch of things, fires a bunch of notifications, etc. etc.
4592019-04-03T22:34:36  <gmaxwell> and on mac there is no file-centric fsync.
4602019-04-03T22:34:40  <achow101> working on fix
4612019-04-03T22:34:55  *** joshmg has joined #bitcoin-core-dev
4622019-04-03T22:35:28  *** joshmg has quit IRC
4632019-04-03T22:35:52  <sipa> achow101: nice
4642019-04-03T22:36:32  <sipa> i guess some of the wallet encryption logic can be used to avoid opening/closing the db every time?
4652019-04-03T22:36:53  <gwillen> will my testnet wallet get rekt if I murder this process in the middle of whatever it's doing
4662019-04-03T22:37:02  <gmaxwell> We had this same problem with the original wallet creation at one point, IIRC
4672019-04-03T22:37:35  <gwillen> sipa: what's the deal with wallet compression, is it an option?
4682019-04-03T22:38:51  *** shtirlic has joined #bitcoin-core-dev
4692019-04-03T22:39:47  <sipa> gwillen: if you never encrypted the wallet it's unencrypted
4702019-04-03T22:40:19  <gwillen> erm, you said compression before, but this time you said encryption
4712019-04-03T22:40:35  <sipa> i meant encrypted :)
4722019-04-03T22:40:45  <gwillen> oh, heh
4732019-04-03T22:40:49  <gwillen> does encryption also compress
4742019-04-03T22:40:49  * sipa falls asleep
4752019-04-03T22:41:01  <gwillen> or is this not actually relevant to the problem of walletfile being huge
4762019-04-03T22:41:17  <gwillen> you said something about 270 bytes per key
4772019-04-03T22:41:39  <gwillen> I would have assumed default compression, especially if we're repeating mostly-redundant key origin info for every key
4782019-04-03T22:41:46  <gwillen> that should be extremely compressible
4792019-04-03T22:42:07  <gwillen> my wallet has reached 8.5 megs
4802019-04-03T22:42:13  *** spinza has quit IRC
4812019-04-03T22:42:59  <sipa> gwillen: the old unencrypted wallet format stores private keys in a ricldiculous der encoded format of 279 bytes per key
4822019-04-03T22:43:06  <sipa> where only 32 bytes are needed
4832019-04-03T22:43:20  <gwillen> ah, well this wallet should be relatively new, like within the last few months
4842019-04-03T22:43:27  <sipa> not relevant
4852019-04-03T22:43:45  <sipa> the encoding used for unencrypted keys is still that der one
4862019-04-03T22:43:48  <gwillen> also this is watchonly so there are no private keys anyway
4872019-04-03T22:43:53  <sipa> oh!
4882019-04-03T22:43:59  <sipa> then this is all irrelevant
4892019-04-03T22:44:15  <gwillen> so presumably all that space is being taken up by key origin info and other metadata
4902019-04-03T22:44:37  <gwillen> although that's still more than 1kb per key, which seems huge
4912019-04-03T22:44:54  <gwillen> achow101: how large did your wallet get after you spent 6 minutes importing 10,000 keys
4922019-04-03T22:45:10  <sipa> gwillen: doesn't surprise me
4932019-04-03T22:45:39  <achow101> gwillen: 8 MB, but I also did it again and now it's 16 MB
4942019-04-03T22:45:40  *** Randolf has joined #bitcoin-core-dev
4952019-04-03T22:45:48  <gwillen> heh
4962019-04-03T22:45:52  <gwillen> so mine was almost done probably
4972019-04-03T22:47:19  <gwillen> doing 100 takes 3 seconds on my machine, so 10000 would have taken about 5 minutes to finish
4982019-04-03T22:55:12  *** spinza has joined #bitcoin-core-dev
4992019-04-03T23:06:56  <achow101> well batching writes reduced that from 6:56 to 1:24
5002019-04-03T23:08:41  <gwillen> ha
5012019-04-03T23:18:17  *** bitcoin-git has joined #bitcoin-core-dev
5022019-04-03T23:18:17  <bitcoin-git> [bitcoin] achow101 opened pull request #15741: Batch write imported stuff in importmulti (master...batch-write-importmulti) https://github.com/bitcoin/bitcoin/pull/15741
5032019-04-03T23:18:22  *** bitcoin-git has left #bitcoin-core-dev
5042019-04-03T23:18:25  <achow101> gwillen: ^^
5052019-04-03T23:19:07  *** AaronvanW has quit IRC
5062019-04-03T23:21:18  <gwillen> :+1: will review!
5072019-04-03T23:27:01  <gwillen> achow101: is this kind of manual batching typical of using WalletBatch? I wonder if it would make sense to have a self-flushing WalletWriteCache or something
5082019-04-03T23:27:13  <gwillen> to avoid having to have all the fiddly counting of entries
5092019-04-03T23:28:18  *** EagleTM has quit IRC
5102019-04-03T23:28:33  <achow101> gwillen: we do something similar for initial key generation
5112019-04-03T23:28:56  <achow101> i was mostly following upgradekeymetadata (aka copy paste) which does counting
5122019-04-03T23:30:06  <gwillen> would be good to factor it out nicely ;-)
5132019-04-03T23:30:32  *** Randolf has quit IRC
5142019-04-03T23:32:17  *** EagleTM has joined #bitcoin-core-dev
5152019-04-03T23:34:33  *** dviola has quit IRC
5162019-04-03T23:39:53  *** d_t has quit IRC
5172019-04-03T23:46:30  *** bitcoin-git has joined #bitcoin-core-dev
5182019-04-03T23:46:30  <bitcoin-git> [bitcoin] kallewoof closed pull request #13746: -masterdatadir for datadir bootstrapping (master...masterdatadir) https://github.com/bitcoin/bitcoin/pull/13746
5192019-04-03T23:46:32  *** bitcoin-git has left #bitcoin-core-dev
5202019-04-03T23:47:50  *** dqx_ has quit IRC
5212019-04-03T23:50:21  *** fanquake has quit IRC
5222019-04-03T23:58:11  *** DeanWeen has joined #bitcoin-core-dev
5232019-04-03T23:59:37  *** DeanWeen is now known as DeanGuss