12019-01-10T00:02:16  *** michaelsdunn1 has quit IRC
  22019-01-10T00:02:42  *** Murch has quit IRC
  32019-01-10T00:06:56  *** aqquadro has quit IRC
  42019-01-10T00:07:26  <phantomcircuit> gmaxwell, wait they cancel a invoice if the transaction reaches them over the network first?
  52019-01-10T00:07:48  *** Giszmo has quit IRC
  62019-01-10T00:07:49  <gmaxwell> Yes, they did to me and other people at the time were reporting it too.
  72019-01-10T00:07:56  <gmaxwell> Maybe they since stopped? if so then I'm out of date.
  82019-01-10T00:08:07  <phantomcircuit> that's crazy
  92019-01-10T00:08:50  *** Giszmo has joined #bitcoin-core-dev
 102019-01-10T00:09:06  <echeveria> phantomcircuit: they want to be able to selectively abort client payments.
 112019-01-10T00:09:46  <echeveria> this is doable if they really wanted to within another protocol, but would need to have the client doing partial signatures, and them filling validity with another signature of their own input to the payment.
 122019-01-10T00:10:36  <gmaxwell> BIP70 could have been defined that way, varrious people advocated for it.
 132019-01-10T00:11:01  <gmaxwell> But doing that correctly is harder for the wallet, since it needs to track UTXO as 'I signed for this, but it hasn't been broadcast yet'.
 142019-01-10T00:11:21  <gmaxwell> At the time BIP70 was written, the only 'used' metric bitcoin core really had was "spent by the mempool"
 152019-01-10T00:11:34  <luke-jr> maybe someone should get this in the Bustapay stuff
 162019-01-10T00:11:52  <phantomcircuit> echeveria, oooh
 172019-01-10T00:12:02  <phantomcircuit> they want to be able to blacklist utxo entries
 182019-01-10T00:12:03  <phantomcircuit> got it
 192019-01-10T00:12:37  <echeveria> gmaxwell: I don't think it's very user friendly to have that as a system though. you end up with ambiguity, I've paid someone with this output, and they may actually spend it sometime in the future, or not.
 202019-01-10T00:13:34  <luke-jr> if you're not careful, it locks your change too
 212019-01-10T00:13:39  <echeveria> I guess have a timeout in the script that means your partial signature is only valid for x hours or something, but even so. with most wallets tending towards having absolutely no logic in them this seems like a non-starter.
 222019-01-10T00:13:59  <luke-jr> echeveria: Bitcoin intentionally doesn't support such timeouts
 232019-01-10T00:15:06  <gmaxwell> you 'time it out' by double spending it.
 242019-01-10T00:15:22  *** promag has joined #bitcoin-core-dev
 252019-01-10T00:15:36  <gmaxwell> What I think the wallet should do is track pending spends, and eventually intentionally double spend them if they 'timeout'
 262019-01-10T00:15:45  *** promag has quit IRC
 272019-01-10T00:15:53  <gmaxwell> probably by just including them in a future transaction post timeout.
 282019-01-10T00:16:13  <gmaxwell> and also show a 'pending balance', so it's clear that a wallet with pending spends isn't 'empty'
 292019-01-10T00:16:39  <gmaxwell> But... yea, it's a non-zero amount of work.
 302019-01-10T00:16:48  <luke-jr> especially when you consider Lightning, I bet :p
 312019-01-10T00:17:04  <gmaxwell> But what bitpay wants people to do is just busted.
 322019-01-10T00:17:28  <gmaxwell> like they want to be able to say 'payment rejected, try again with more fee'  but then no effort at all to doublespend the prior payments.
 332019-01-10T00:17:39  <gmaxwell> and no indication in the wallet that you've potentially double paid them.
 342019-01-10T00:17:57  <luke-jr> those seem like wallet-side decisions
 352019-01-10T00:18:06  <gmaxwell> so days, months, or even years later,  you might have a whole bunch of bitpay payments go through twice..
 362019-01-10T00:18:33  <gmaxwell> They are but they need to be part of any BIP70 alternative that doesn't immediately broadcast txn.
 372019-01-10T00:18:55  <gmaxwell> As in the spec needs to advise sensible behavior, and wallets _must_ implement somethign sensible or they create security vulnerabilities.
 382019-01-10T00:19:24  <gmaxwell> at a minimum if a payment is rejected and needs to be reissued, the wallet must doublespend the original one.
 392019-01-10T00:20:48  <gmaxwell> (and since there is bidi communication, there is really no reason that a request couldn't be rejected before a signed copy is even sent... but thats another matter)
 402019-01-10T00:20:52  <echeveria> and handle when someone refuses to do the double spend with their hardware wallet.
 412019-01-10T00:21:26  <gmaxwell> the double spend can at least be avoided all togeather in the common case.
 422019-01-10T00:21:40  <gmaxwell> echeveria: right or with a third party anti-doublespend signer.
 432019-01-10T00:22:24  *** jarthur has quit IRC
 442019-01-10T00:22:32  <echeveria> ends up being a rather unfortunate amount of logic in the wallet.
 452019-01-10T00:23:02  *** promag has joined #bitcoin-core-dev
 462019-01-10T00:23:05  <gmaxwell> right and a bunch of it is tricky, which is why I think it's important that a spec that makes you do this tricky thing at least warn you about the stuff you need to consider.
 472019-01-10T00:23:46  <gmaxwell> otherwise it would be like a ecdsa spec that just said nothing about where you're supposted to get this nonce value. "Nonce? that means used once. I'll just use a counter."
 482019-01-10T00:29:44  <ap4lmtree-> any of you take free online classes, such as through coursera ?
 492019-01-10T00:30:19  <ap4lmtree-> they have some cs and every other field courses
 502019-01-10T00:38:05  *** hebasto has quit IRC
 512019-01-10T00:46:09  <gwillen> ap4lmtree-: not sure how on-topic this is here, but fwiw the Coursera Crypto I class by Dan Boneh is very good
 522019-01-10T00:46:45  <phantomcircuit> wumpus, btw i dont have fuzzing.tar.xz anywhere so that can definitely be removed
 532019-01-10T00:49:13  *** DeanGuss has joined #bitcoin-core-dev
 542019-01-10T01:00:18  <phantomcircuit> gmaxwell, the idea that the remote end is going to reject a payment is crazy town
 552019-01-10T01:01:16  <gmaxwell> phantomcircuit: I don't think it is? like at least it's not unreasonable for the remote end to ignore your unconfirmed payment unless it has some minimum feerate.
 562019-01-10T01:03:53  <phantomcircuit> gmaxwell, it's not unreasonable to ignore you until it confirms
 572019-01-10T01:03:55  <phantomcircuit> then what
 582019-01-10T01:04:26  <gmaxwell> right, sure, but assuming you wanted it to not be ignored until them, you would have appricated the oppturnity to make a different txn.
 592019-01-10T01:07:17  *** justan0theruser has joined #bitcoin-core-dev
 602019-01-10T01:07:37  *** spaced0ut has quit IRC
 612019-01-10T01:07:47  *** justanotheruser has quit IRC
 622019-01-10T01:07:58  <phantomcircuit> gmaxwell, i guess what im saying is that rejecting an unsigned transaction makes sense, but rejecting one that's signed and broadcast?
 632019-01-10T01:08:05  <phantomcircuit> once it's confirmed it's confirmed
 642019-01-10T01:08:40  *** pinheadmz has quit IRC
 652019-01-10T01:08:57  <gmaxwell> well thats why they want you to submit the transaction directly instead of broadcasting.
 662019-01-10T01:11:58  <phantomcircuit> but it's signed why should you trust them not to broadcast it themselves
 672019-01-10T01:12:54  <gmaxwell> You shouldn't. They might. Which is why you need to handle it correctly.
 682019-01-10T01:13:21  <gmaxwell> E.g. if they reject it and your response is to resign e.g. with more fee, you need to make sure you doublespend it... e.g. same as if you'd feebumped in the UI.
 692019-01-10T01:13:55  <gmaxwell> which sounds obnoxious, but its not bad considering that feebumping is already an existing and pretty desirable feature.
 702019-01-10T01:15:00  <phantomcircuit> gmaxwell, it seems more like you want a list of "payments im trying to make" and have the wallet ensure any new transaction invalidates anything that doesn't pay to that set
 712019-01-10T01:15:59  <gmaxwell> Maybe, though you don't really want to invalidate a payment that the recipent is already trying to CPFP unless asked to do so.
 722019-01-10T01:16:42  <wumpus> phantomcircuit: no problem, that whole section can be removed, the fuzzing corpus is going to move to a separate repository
 732019-01-10T01:19:56  <wumpus> gkrizek: there's not that much configuration; server is chat.freenode.net port is 6697, room is "#bitcoin-commits,#bitcoin-core-dev", nick is "bitcoin-git", branches is "master,0.11,0.12,0.13,0.14,0.15,0.16,0.17"
 742019-01-10T01:20:35  <wumpus> gkrizek: password and nickserv password is not filled in, Ssl is checked, Long url is checked, the other checkboxes are not
 752019-01-10T01:25:48  *** promag has quit IRC
 762019-01-10T01:26:18  <ap4lmtree-> gmaxwell, okay ill check it out
 772019-01-10T01:29:00  *** gekisai has quit IRC
 782019-01-10T01:29:42  *** gekisai has joined #bitcoin-core-dev
 792019-01-10T01:34:02  *** gekisai has quit IRC
 802019-01-10T01:35:10  *** gekisai has joined #bitcoin-core-dev
 812019-01-10T01:37:35  *** DeanGuss has quit IRC
 822019-01-10T01:42:45  *** jarthur has joined #bitcoin-core-dev
 832019-01-10T01:46:11  *** gekisai has quit IRC
 842019-01-10T01:46:26  *** fanquake has quit IRC
 852019-01-10T01:48:21  *** miknotauro has quit IRC
 862019-01-10T01:58:25  *** gekisai has joined #bitcoin-core-dev
 872019-01-10T02:02:04  *** gkrizek has quit IRC
 882019-01-10T02:03:14  *** gekisai has quit IRC
 892019-01-10T02:03:37  *** Zenton has quit IRC
 902019-01-10T02:03:46  *** Zenton has joined #bitcoin-core-dev
 912019-01-10T02:05:40  *** achow101 has quit IRC
 922019-01-10T02:08:54  *** gekisai has joined #bitcoin-core-dev
 932019-01-10T02:08:55  *** fanquake has joined #bitcoin-core-dev
 942019-01-10T02:13:07  *** gekisai has quit IRC
 952019-01-10T02:16:16  *** achow101 has joined #bitcoin-core-dev
 962019-01-10T02:17:06  *** gkrizek has joined #bitcoin-core-dev
 972019-01-10T02:19:16  <gkrizek> wumpus: Ok, thanks! Are we cool with keeping that the same?  Send a message when pushes happen to those branches and when PRs are open/closed/merged/reopened? I can add or remove whatever we want
 982019-01-10T02:20:55  *** gkrizek has quit IRC
 992019-01-10T02:21:14  *** gkrizek has joined #bitcoin-core-dev
1002019-01-10T02:23:23  *** gekisai has joined #bitcoin-core-dev
1012019-01-10T02:38:32  *** fanquake has quit IRC
1022019-01-10T03:10:20  *** Giszmo has quit IRC
1032019-01-10T03:28:23  *** Giszmo has joined #bitcoin-core-dev
1042019-01-10T03:42:36  *** ap4lmtree- is now known as ap4lmtree
1052019-01-10T03:44:06  *** ddustin has quit IRC
1062019-01-10T03:45:05  *** rhavar_ has joined #bitcoin-core-dev
1072019-01-10T03:54:27  *** justan0theruser is now known as justanotheruser
1082019-01-10T04:38:11  *** midnightmagic has quit IRC
1092019-01-10T04:39:06  *** grubles__ is now known as grubles
1102019-01-10T04:41:42  *** gekisai has quit IRC
1112019-01-10T04:49:47  *** midnightmagic has joined #bitcoin-core-dev
1122019-01-10T04:50:47  *** DougieBot5000_ has joined #bitcoin-core-dev
1132019-01-10T04:53:56  *** DougieBot5000 has quit IRC
1142019-01-10T05:45:22  *** zenogais has quit IRC
1152019-01-10T06:12:52  *** Victorsueca has quit IRC
1162019-01-10T06:17:13  *** Victorsueca has joined #bitcoin-core-dev
1172019-01-10T06:19:52  *** midnightmagic has quit IRC
1182019-01-10T06:33:57  *** midnightmagic has joined #bitcoin-core-dev
1192019-01-10T06:47:25  *** pinheadmz has joined #bitcoin-core-dev
1202019-01-10T07:06:01  *** pinheadmz has quit IRC
1212019-01-10T07:09:37  *** DougieBot5000_ is now known as DougieBot5000
1222019-01-10T07:16:01  *** EagleTM has joined #bitcoin-core-dev
1232019-01-10T07:20:34  *** EagleTM has quit IRC
1242019-01-10T07:33:28  *** hebasto has joined #bitcoin-core-dev
1252019-01-10T07:33:57  *** pinheadmz has joined #bitcoin-core-dev
1262019-01-10T07:34:17  *** miknotauro has joined #bitcoin-core-dev
1272019-01-10T08:18:15  *** jungly has joined #bitcoin-core-dev
1282019-01-10T08:48:13  *** jarthur has quit IRC
1292019-01-10T08:52:21  *** pinheadmz has quit IRC
1302019-01-10T08:54:22  *** rhavar_ has quit IRC
1312019-01-10T09:09:08  *** setpill has joined #bitcoin-core-dev
1322019-01-10T09:12:28  *** Guyver2 has joined #bitcoin-core-dev
1332019-01-10T09:20:39  *** promag has joined #bitcoin-core-dev
1342019-01-10T09:28:14  *** aqquadro has joined #bitcoin-core-dev
1352019-01-10T09:46:31  *** gekisai has joined #bitcoin-core-dev
1362019-01-10T09:46:33  *** promag has quit IRC
1372019-01-10T09:51:03  *** gekisai has quit IRC
1382019-01-10T09:52:19  *** newbie111 has joined #bitcoin-core-dev
1392019-01-10T09:52:58  <newbie111> hi ALL
1402019-01-10T09:54:05  *** gekisai has joined #bitcoin-core-dev
1412019-01-10T09:54:28  *** newbie111 has quit IRC
1422019-01-10T10:02:35  *** AaronvanW has joined #bitcoin-core-dev
1432019-01-10T10:06:53  *** Aaronvan_ has joined #bitcoin-core-dev
1442019-01-10T10:07:12  *** spinza has quit IRC
1452019-01-10T10:07:14  *** Aaronvan_ has quit IRC
1462019-01-10T10:08:50  *** AaronvanW has quit IRC
1472019-01-10T10:12:54  *** elichai2 has joined #bitcoin-core-dev
1482019-01-10T10:21:58  *** timothy has joined #bitcoin-core-dev
1492019-01-10T10:27:19  *** AaronvanW has joined #bitcoin-core-dev
1502019-01-10T10:29:43  *** Aaronvan_ has joined #bitcoin-core-dev
1512019-01-10T10:33:04  *** AaronvanW has quit IRC
1522019-01-10T10:34:01  *** rh0nj has quit IRC
1532019-01-10T10:34:22  *** spinza has joined #bitcoin-core-dev
1542019-01-10T10:35:08  *** rh0nj has joined #bitcoin-core-dev
1552019-01-10T10:36:44  <meshcollider> gkrizek: we dont need branches 0.11, 0.12 or 0.13 anymore btw, only 14+
1562019-01-10T10:55:10  <wumpus> good point, I cleaned up those branches to keep the number of branches from getting out of hand, as there's no active development expected on them anymore
1572019-01-10T10:59:40  *** promag has joined #bitcoin-core-dev
1582019-01-10T11:05:37  *** gekisai has quit IRC
1592019-01-10T11:07:20  *** wolfspraul has quit IRC
1602019-01-10T11:08:07  *** wolfspraul has joined #bitcoin-core-dev
1612019-01-10T11:21:15  *** Murch has joined #bitcoin-core-dev
1622019-01-10T11:39:41  *** dermoth has quit IRC
1632019-01-10T11:40:13  *** dermoth has joined #bitcoin-core-dev
1642019-01-10T11:43:37  *** gekisai has joined #bitcoin-core-dev
1652019-01-10T11:43:53  *** gelmutshmidt has joined #bitcoin-core-dev
1662019-01-10T11:48:15  *** gekisai has quit IRC
1672019-01-10T11:56:53  *** anome has joined #bitcoin-core-dev
1682019-01-10T12:17:11  *** dermoth has quit IRC
1692019-01-10T12:20:48  *** lnostdal has quit IRC
1702019-01-10T12:21:17  *** lnostdal has joined #bitcoin-core-dev
1712019-01-10T12:25:53  *** lnostdal has quit IRC
1722019-01-10T12:27:09  *** miknotauro has quit IRC
1732019-01-10T12:33:30  *** mg0314b has joined #bitcoin-core-dev
1742019-01-10T12:38:49  *** Guyver2 has quit IRC
1752019-01-10T12:38:58  *** mg0314b has quit IRC
1762019-01-10T12:46:03  *** promag has quit IRC
1772019-01-10T13:01:40  *** mistergold has joined #bitcoin-core-dev
1782019-01-10T13:30:08  *** rh0nj has joined #bitcoin-core-dev
1792019-01-10T13:40:47  *** anome has quit IRC
1802019-01-10T13:50:50  *** Aaronvan_ is now known as AaronvanW
1812019-01-10T13:54:09  *** VK86GER has joined #bitcoin-core-dev
1822019-01-10T13:59:45  *** Cchadwicka has joined #bitcoin-core-dev
1832019-01-10T14:05:12  *** arubi has quit IRC
1842019-01-10T14:05:36  *** dermoth has joined #bitcoin-core-dev
1852019-01-10T14:06:56  *** VK86GER has quit IRC
1862019-01-10T14:08:14  *** arubi has joined #bitcoin-core-dev
1872019-01-10T14:11:10  *** benthecarman has joined #bitcoin-core-dev
1882019-01-10T14:12:26  <benthecarman> Is there an easy to way get a CTransaction from a CWalletTx
1892019-01-10T14:15:40  *** Guyver2 has joined #bitcoin-core-dev
1902019-01-10T14:19:01  *** lnostdal has joined #bitcoin-core-dev
1912019-01-10T14:24:16  *** Murch has quit IRC
1922019-01-10T14:34:08  *** spaced0ut has joined #bitcoin-core-dev
1932019-01-10T14:34:31  <wumpus> benthecarman: the 'tx' field contains a pointer to the underlying CTransaction
1942019-01-10T14:34:39  *** lnostdal has quit IRC
1952019-01-10T14:36:48  <benthecarman> Oh okay thnx
1962019-01-10T14:42:48  *** Murch has joined #bitcoin-core-dev
1972019-01-10T14:45:00  *** mike_ has joined #bitcoin-core-dev
1982019-01-10T14:45:24  *** mike_ is now known as Guest51719
1992019-01-10T14:46:31  *** lnostdal has joined #bitcoin-core-dev
2002019-01-10T15:11:15  *** lnostdal has quit IRC
2012019-01-10T15:13:55  *** setpill has quit IRC
2022019-01-10T15:19:04  *** Tralfaz has joined #bitcoin-core-dev
2032019-01-10T15:23:30  *** lnostdal has joined #bitcoin-core-dev
2042019-01-10T15:27:35  *** promag has joined #bitcoin-core-dev
2052019-01-10T15:30:14  *** michaelsdunn1 has joined #bitcoin-core-dev
2062019-01-10T15:38:30  *** zenogais has joined #bitcoin-core-dev
2072019-01-10T15:45:15  *** gekisai has joined #bitcoin-core-dev
2082019-01-10T15:49:29  *** gekisai has quit IRC
2092019-01-10T15:53:32  *** aqquadro has quit IRC
2102019-01-10T15:55:56  *** lnostdal has quit IRC
2112019-01-10T15:57:50  *** Cchadwicka has quit IRC
2122019-01-10T16:07:53  *** lnostdal has joined #bitcoin-core-dev
2132019-01-10T16:13:52  *** promag has quit IRC
2142019-01-10T16:13:56  *** lnostdal has quit IRC
2152019-01-10T16:18:49  *** promag has joined #bitcoin-core-dev
2162019-01-10T16:19:38  *** mistergold has quit IRC
2172019-01-10T16:22:28  <hebasto> promag: hi, should I close #14798 in favor of #15136?
2182019-01-10T16:22:30  <gribble> https://github.com/bitcoin/bitcoin/issues/14798 | qt: Fix deselecting peer when switching from peers to console tab by hebasto · Pull Request #14798 · bitcoin/bitcoin · GitHub
2192019-01-10T16:22:31  <gribble> https://github.com/bitcoin/bitcoin/issues/15136 | qt: "Peers" tab overhaul by hebasto · Pull Request #15136 · bitcoin/bitcoin · GitHub
2202019-01-10T16:23:01  <promag> you know my preference :D
2212019-01-10T16:23:37  <hebasto> yeap :)
2222019-01-10T16:23:55  <promag> hebasto: which behavior you prefer?
2232019-01-10T16:25:26  <hebasto> promag: I would not work on it if it seems useless for me.
2242019-01-10T16:26:20  *** lnostdal has joined #bitcoin-core-dev
2252019-01-10T16:27:19  <promag> hebasto: then I think you should close the other one with some reasoning
2262019-01-10T16:31:14  <promag> see you in the meeting
2272019-01-10T16:31:17  *** promag has quit IRC
2282019-01-10T16:31:30  <hebasto> promag: sure
2292019-01-10T16:32:15  *** miknotauro has joined #bitcoin-core-dev
2302019-01-10T16:38:19  <gkrizek> meshcollider:  wumpus: Ok, great. Thank you. I'm going to send messages when Tags are created as well. They are part of the same event type from GitHub and seem important info to message about
2312019-01-10T16:40:16  <achow101> gkrizek: that's a good idea. currently wumpus has to send that message himself
2322019-01-10T16:40:45  *** lnostdal has quit IRC
2332019-01-10T16:40:57  <sipa> gkrizek: thank you for working on this
2342019-01-10T16:42:24  <wumpus> gkrizek: thanks, seems useful!
2352019-01-10T16:42:54  <gkrizek> Great, I think it would be too and since they are already part of the event it's almost no extra work.
2362019-01-10T16:44:15  <gkrizek> sipa: no problem! Happy to help.  This will probably be a pretty minimal implementation at first because Services are officially EOL on the 31st. Just trying to get something to replace it for now, then can make it better later on.
2372019-01-10T16:48:56  *** spinza has quit IRC
2382019-01-10T16:54:48  *** spinza has joined #bitcoin-core-dev
2392019-01-10T17:03:23  *** pinheadmz has joined #bitcoin-core-dev
2402019-01-10T17:05:41  *** promag has joined #bitcoin-core-dev
2412019-01-10T17:13:02  *** promag has quit IRC
2422019-01-10T17:21:21  *** pinheadmz has quit IRC
2432019-01-10T17:31:02  *** rh0nj has quit IRC
2442019-01-10T17:32:08  *** rh0nj has joined #bitcoin-core-dev
2452019-01-10T17:34:08  *** dviola has joined #bitcoin-core-dev
2462019-01-10T17:43:44  *** promag has joined #bitcoin-core-dev
2472019-01-10T17:46:45  *** gekisai has joined #bitcoin-core-dev
2482019-01-10T17:51:39  *** gekisai has quit IRC
2492019-01-10T17:57:19  *** sfhi has joined #bitcoin-core-dev
2502019-01-10T18:00:15  *** jungly has quit IRC
2512019-01-10T18:00:58  *** pinheadmz has joined #bitcoin-core-dev
2522019-01-10T18:04:37  *** Giszmo has quit IRC
2532019-01-10T18:10:42  *** miknotauro has quit IRC
2542019-01-10T18:19:04  *** Giszmo has joined #bitcoin-core-dev
2552019-01-10T18:19:05  *** pinheadmz has quit IRC
2562019-01-10T18:25:10  *** mistergold has joined #bitcoin-core-dev
2572019-01-10T18:27:33  *** Krellan has quit IRC
2582019-01-10T18:28:04  *** Krellan has joined #bitcoin-core-dev
2592019-01-10T18:30:34  *** pinheadmz has joined #bitcoin-core-dev
2602019-01-10T18:32:21  *** Krellan has quit IRC
2612019-01-10T18:46:26  *** dgenr8 has joined #bitcoin-core-dev
2622019-01-10T19:00:25  <achow101> meeting?
2632019-01-10T19:00:29  <instagibbs> meeting.
2642019-01-10T19:00:32  <wumpus> #startmeeting
2652019-01-10T19:00:32  <lightningbot> Meeting started Thu Jan 10 19:00:32 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2662019-01-10T19:00:32  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2672019-01-10T19:00:44  <moneyball> hi
2682019-01-10T19:00:45  <sdaftuar> hi
2692019-01-10T19:00:48  <sipa> hi
2702019-01-10T19:00:56  <achow101> hi
2712019-01-10T19:00:56  <moneyball> fyi there weren't any proposed topics in IRC the past week
2722019-01-10T19:01:00  <jonasschnelli> hi
2732019-01-10T19:01:02  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
2742019-01-10T19:01:12  <promag> hi
2752019-01-10T19:01:19  <jamesob> hi
2762019-01-10T19:01:31  <wumpus> any proposed topics now?
2772019-01-10T19:01:42  <wumpus> thanks for keeping track moneyball
2782019-01-10T19:01:59  <achow101> topic: moving hwi under bitcoin-core org
2792019-01-10T19:02:13  <wumpus> hwi?
2802019-01-10T19:02:24  <achow101> hardware wallet interface thingy
2812019-01-10T19:02:25  <instagibbs> https://github.com/achow101/HWI
2822019-01-10T19:02:26  <jnewbery> hi
2832019-01-10T19:02:34  <wumpus> ohh ofc
2842019-01-10T19:02:47  <wumpus> #topic high priority for review
2852019-01-10T19:02:54  <wumpus> https://github.com/bitcoin/bitcoin/projects/8
2862019-01-10T19:03:02  <sipa> can i has #14955 ?
2872019-01-10T19:03:06  <gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
2882019-01-10T19:03:33  <wumpus> current ones: #11082 #14491 #14711 #14941 #14938
2892019-01-10T19:03:36  <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
2902019-01-10T19:03:38  <gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
2912019-01-10T19:03:41  <wumpus> sipa: sure
2922019-01-10T19:03:41  <gribble> https://github.com/bitcoin/bitcoin/issues/14711 | Remove uses of chainActive and mapBlockIndex in wallet code by ryanofsky · Pull Request #14711 · bitcoin/bitcoin · GitHub
2932019-01-10T19:03:43  <gribble> https://github.com/bitcoin/bitcoin/issues/14941 | rpc: Make unloadwallet wait for complete wallet unload by promag · Pull Request #14941 · bitcoin/bitcoin · GitHub
2942019-01-10T19:03:45  <gribble> https://github.com/bitcoin/bitcoin/issues/14938 | Support creating an empty wallet by Sjors · Pull Request #14938 · bitcoin/bitcoin · GitHub
2952019-01-10T19:04:06  <sdaftuar> i'd like to request #15141
2962019-01-10T19:04:08  <gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
2972019-01-10T19:04:19  <jnewbery> I think everyone's scared of reviewing that!
2982019-01-10T19:04:35  <sdaftuar> it's already been reviewed a bunch, just never was merged :(
2992019-01-10T19:05:00  <wumpus> added
3002019-01-10T19:05:08  <sdaftuar> thanks
3012019-01-10T19:06:10  <wumpus> #topic moving hwi under bitcoin-core org (achow101)
3022019-01-10T19:06:33  <phantomcircuit> hi
3032019-01-10T19:06:46  <wumpus> #link https://github.com/achow101/HWI
3042019-01-10T19:06:47  <jonasschnelli> Maybe we can discuss #11082 since there was the discussion of JSON vs INI?
3052019-01-10T19:06:50  <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
3062019-01-10T19:06:54  <meshcollider> Hi
3072019-01-10T19:07:43  <achow101> so hwi is currently under my account. but if we are going to use it for hardware wallet support in core, then perhaps it would be better to have it under a proper github org. the obvious one that comes to mind is bitcoin-core
3082019-01-10T19:08:14  <wumpus> yes, that makes sense
3092019-01-10T19:08:17  <achow101> instagibbs: might have some thoughts on this?
3102019-01-10T19:08:25  <instagibbs> nothing against achow101 but also I'm actively using it and would be nice to be put under an established org
3112019-01-10T19:08:28  <instagibbs> ;)
3122019-01-10T19:08:38  <instagibbs> ACK in other words
3132019-01-10T19:09:02  <wumpus> no one seems to be opposed :)
3142019-01-10T19:09:29  *** pinheadmz has quit IRC
3152019-01-10T19:09:31  <instagibbs> https://github.com/achow101/HWI/issues/91 for further background
3162019-01-10T19:09:43  <meshcollider> We should give achow merge permission on it imo
3172019-01-10T19:09:58  <wumpus> of course
3182019-01-10T19:10:05  <sipa> achow101: iirc there is a way to 'transfer' a repo to another org, that way github will automatically set up redirects etc
3192019-01-10T19:10:09  <sipa> as opposed to copying it over
3202019-01-10T19:10:23  <instagibbs> yep, just an organizational thing, with established review/merge norms/contributor docs
3212019-01-10T19:10:25  <wumpus> he might still want the local clone for his own PRs
3222019-01-10T19:10:29  <achow101> sipa: yes, there's a transfer ownership button
3232019-01-10T19:10:53  <jnewbery> #link https://help.github.com/articles/transferring-a-repository/
3242019-01-10T19:10:56  <wumpus> but could create a new one as well
3252019-01-10T19:11:09  <wumpus> (clone it again after transfering)
3262019-01-10T19:11:11  *** pinheadmz has joined #bitcoin-core-dev
3272019-01-10T19:11:35  <wumpus> any other topics?
3282019-01-10T19:11:51  <jimpo> BIP 157 index leveldb vs flatfiles?
3292019-01-10T19:12:08  <wumpus> ah yes jonasschnelli had one
3302019-01-10T19:12:13  *** pinheadmz has quit IRC
3312019-01-10T19:12:27  <jonasschnelli> not an important one
3322019-01-10T19:12:40  <jonasschnelli> (and my internet connection goes up and down)
3332019-01-10T19:12:45  <wumpus> ok jimpo first then
3342019-01-10T19:12:46  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11082#issuecomment-451406061
3352019-01-10T19:12:50  <jonasschnelli> ack
3362019-01-10T19:12:58  <wumpus> #topic BIP 157 index leveldb vs flatfiles (jimpo)
3372019-01-10T19:13:00  <jimpo> So there's some discussion on #14121
3382019-01-10T19:13:03  <gribble> https://github.com/bitcoin/bitcoin/issues/14121 | Index for BIP 157 block filters by jimpo · Pull Request #14121 · bitcoin/bitcoin · GitHub
3392019-01-10T19:13:27  <jimpo> basically there's three options 1) store entire filters along with metadata in separate LevelDB
3402019-01-10T19:13:43  <jimpo> 2) store filter metadata (hash, disk pos) in levelDB and filters in flat files
3412019-01-10T19:14:03  <jimpo> 3) add filter metadata to CBlockIndex and store filters in flat files, just like undo data
3422019-01-10T19:14:27  <jimpo> In terms of perf, #3 is probably the fastest and certainly the fastest with enough IO optimizations
3432019-01-10T19:14:30  <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
3442019-01-10T19:14:35  <sipa> so the first question is between 1/2 and 3, i think; whether the filters are their own index semantically, or part of the main data structures
3452019-01-10T19:15:10  <jonasschnelli> What speaks against being part of the main data structure?
3462019-01-10T19:15:14  <jimpo> I prefer 1/2 since I can imagine alternate filter types
3472019-01-10T19:15:21  <jonasschnelli> (like option 3)
3482019-01-10T19:15:22  <sipa> and i guess that depends on how they'll be used; if they're mostly optional things that some people want to enable, a separate index is the obvious way to go
3492019-01-10T19:15:29  <jamesob> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/14121#issuecomment-451838178
3502019-01-10T19:15:39  <sipa> but if we envision it may become a consensus rule, having it separate is quite annoying
3512019-01-10T19:15:55  <jimpo> metadata is like 76 bytes (2 hashes + disk loc)
3522019-01-10T19:16:19  <jonasschnelli> From what I see is that there are plans to commit the filters at one point so it'll be part of the consensus, right?
3532019-01-10T19:17:06  <jimpo> it's more convenient to have it in CBlockIndex if part of consensus rules, yes, but I'm not sure how much worse the separate index is there
3542019-01-10T19:17:18  <sipa> i guess it isn't really
3552019-01-10T19:17:29  <jimpo> would have to do some synchronization or build the filters twice (but that's really fast)
3562019-01-10T19:17:47  <jimpo> like you can validate the consensus rule w/o storing the filter
3572019-01-10T19:17:50  <sipa> it can go from an asynchronously maintained one to a synchronous one perhap at that time, but still remain a separate db/directory
3582019-01-10T19:17:50  <jimpo> if you don't want to
3592019-01-10T19:17:55  <sipa> right
3602019-01-10T19:18:45  <jimpo> which is another strong (IMO) argument in favor of 1/2: not everyone needs to or should be forced to store filters
3612019-01-10T19:19:00  <jimpo> and no need to bloat CBlockIndex if people might disable it
3622019-01-10T19:19:15  <sipa> agree; i forgot about the possibility that even in case of it being consensus, there is no requirement to actually store the filters
3632019-01-10T19:20:22  <sipa> about the difference between 1 and 2... i prefer the flat files approach slightly (the filters aren't that big that using leveldb is insurmountable, but they're still append-only data like blocks/undo)
3642019-01-10T19:20:43  <sipa> and i saw you also have a PR to abstract out the flat files stuff, which seems useful in any case
3652019-01-10T19:20:54  <jimpo> I do agree that 2 is somewhat conceptually cleaner
3662019-01-10T19:21:13  <jimpo> but it does make the code more complex and is slower right now unless we add a caching layer to the flatfile stuff
3672019-01-10T19:21:53  <jamesob> we don't know how much slower though, right? might be negligible
3682019-01-10T19:22:01  <gmaxwell> I feel sketchy about adding a requirement to store blobs in leveldb, I think in the long run we won't end up using leveldb -- we now no longer need basically any interesting properties of it, it's just a MAP on disk for us now.
3692019-01-10T19:22:24  <gmaxwell> I'm confused that its slower or at least why it would be under actual use though.
3702019-01-10T19:22:30  <jamesob> gmaxwell: we might use snapshotting to alleviate lock contention at some point...
3712019-01-10T19:22:46  <gmaxwell> jamesob: you wouldn't say that if you'd actually tested snapshotting.
3722019-01-10T19:22:49  <jimpo> just two separate reads instead of 1 for each filter I think
3732019-01-10T19:23:07  <sipa> gmaxwell: but do you think that choosing to use leveldb right now will complicate a hypothetical move to using something else?
3742019-01-10T19:23:12  <jimpo> but there are certainly ways to reduce that overhead which I haven't experimented with
3752019-01-10T19:23:20  <gmaxwell> jimpo: why two seperate reads?
3762019-01-10T19:23:28  <jamesob> 1 for leveldb, then 1 for flatfile
3772019-01-10T19:23:32  *** chenpo has joined #bitcoin-core-dev
3782019-01-10T19:23:36  <jimpo> first read from the leveldb index to get the disk pos, then read the filter from flatfile
3792019-01-10T19:23:43  <sipa> well the leveldb part can be in memory, no?
3802019-01-10T19:23:51  <sipa> like CBlockIndex is now
3812019-01-10T19:23:54  <gmaxwell> Ah so it's directly reading the leveldb instead of having the index in memory like the block index is.
3822019-01-10T19:24:19  <jimpo> true, we could keep the whole index in memory
3832019-01-10T19:24:35  <jimpo> but shouldn't that be pretty much equivalent to setting the cache on the leveldb high enough?
3842019-01-10T19:24:36  <gmaxwell> I would be saying these pointers should just be in the blockindex. But there was some talk about switching this on and off above.
3852019-01-10T19:25:08  <gmaxwell> jimpo: not really, there are a bunch of overheads in the leveldb caching and it's not particularly intelligent.
3862019-01-10T19:25:23  <sipa> also a leveldb _read_ is not a single disk access
3872019-01-10T19:25:37  <sipa> (as opposed to something that hits a cache)
3882019-01-10T19:26:03  <jimpo> ok
3892019-01-10T19:26:06  <gmaxwell> it's quasi log(n) plus a bunch of rather expensive bloom filter checks, which is why I was surprised the flatfile was slower..
3902019-01-10T19:26:06  <sipa> so with index in memory + flatfile you're guaranteed one disk seek always
3912019-01-10T19:26:21  <gmaxwell> but if your flatfile is a leveldb access plus the file now I see why it couldn't be faster.
3922019-01-10T19:26:32  <gmaxwell> since you take the ldb overheads in both cases.
3932019-01-10T19:26:35  <jimpo> gmaxwell yes it was leveldb + flatfile
3942019-01-10T19:27:01  *** profmac has quit IRC
3952019-01-10T19:27:43  <jimpo> OK, so what if we have a leveldb index + flatfiles
3962019-01-10T19:28:04  <jimpo> then if that's slow we can add logic to pull the whole leveldb index into mem like the CChain structure
3972019-01-10T19:28:10  <jimpo> but as a separate structure
3982019-01-10T19:28:54  <sipa> is that easier than doing it immediately? (i'm thinking about dealing with the possibility of leveldb read failure outside of startup etc)
3992019-01-10T19:29:17  <jimpo> yes, it definitely breaks up the size of the code change
4002019-01-10T19:29:22  <gmaxwell> sipa: I think right now our leveldb usage can be replaced with something that very simply serializes the things like blockindexes, and an open-hash table for the utxo set. e.g. like the one the ripple people did... and it would likely be a pretty massive speedup.   I suppose you could just convert this to a flatfile /then/, so it's not the end of the world.  We also take on some increased
4012019-01-10T19:29:22  <gmaxwell> Q/A,dev overhead if we start storing blobs in ldb because thats just a whole other set of access patterns that we need to worry about that might result in misbehaviors (like, what is ldb's peak memory usage look like when storing 40kb blobs in it?)
4022019-01-10T19:29:51  <jamesob> sipa: if we have leveldb read failures we've got bigger problems than serving block filters, no?
4032019-01-10T19:29:53  *** Krellan has joined #bitcoin-core-dev
4042019-01-10T19:30:29  *** elichai2 has quit IRC
4052019-01-10T19:30:38  <jimpo> is a leveldb read failure significantly more likely than a flatfile read failure?
4062019-01-10T19:30:39  <sipa> gmaxwell: ok i see
4072019-01-10T19:30:43  *** Krellan has joined #bitcoin-core-dev
4082019-01-10T19:30:58  <sipa> jimpo: it needs exception handling etc, which i remember was a pain to deal with in the UTXO code
4092019-01-10T19:31:18  *** gekisai has joined #bitcoin-core-dev
4102019-01-10T19:31:43  <wumpus> doesn't all i/o need error handling?
4112019-01-10T19:32:11  <jimpo> I guess flatfile accesses just return error codes or null vs throwing exceptions? is that what you're saying sipa?
4122019-01-10T19:32:22  <sipa> sure, but an "if (!read) return false" in the startup code is easier than a wrapper database object that catches exceptions etc
4132019-01-10T19:32:35  <wumpus> oh sure the way in which errors are reported will differ
4142019-01-10T19:32:58  <sipa> anyway, i'm fine with leveldb index + flatfiles, and moving the load into RAM to a later chance
4152019-01-10T19:33:26  <wumpus> one thing at least, for the first iteration it's useful to keep the amount of new code minimal
4162019-01-10T19:33:28  <sipa> performance at this point doesn't matter that much for this application, but it's nice that in the future it wouldn't be a compatibility break
4172019-01-10T19:33:45  <gmaxwell> is the only reason to not store it in the blockindex is to just avoid the size of the blockindex objects increasing when the filter isn't used?
4182019-01-10T19:34:17  <jimpo> potentially if core supports multiple filter types (dunno how likely that is?)
4192019-01-10T19:34:33  <sipa> jimpo: also to simplify building it in the background, i guess?
4202019-01-10T19:34:41  <wumpus> so if using leveldb results in much less code than implementing some manual file handling, that might be handier for review, as said it can be optimized later
4212019-01-10T19:35:30  <gmaxwell> it won't be.
4222019-01-10T19:36:10  <jimpo> it's a few hundred more lines
4232019-01-10T19:36:18  <jimpo> *after* the flatfile refactor
4242019-01-10T19:36:20  <wumpus> as long as you don't end up rolling your own k/v store
4252019-01-10T19:36:44  <jimpo> but I think the refactor is good to do anyway
4262019-01-10T19:36:55  <jamesob> agree with that
4272019-01-10T19:37:18  <sipa> agree, yes
4282019-01-10T19:37:28  <sipa> gmaxwell: what makes you say so?
4292019-01-10T19:37:50  <gmaxwell> The whole process of making these things super optional seems to add a lot of complexity. If instead we didn't think of it that way the filters could just be handled right along side, say, undo data.
4302019-01-10T19:38:21  <jimpo> eh, depends how you think about complexity
4312019-01-10T19:38:36  <jimpo> I consider adding more stuff to CBlockIndex to be more complex than a separate, asynchronous system
4322019-01-10T19:38:54  <sipa> gmaxwell: agree, it adds complexity to make it optional and separate, but that's a different question than whether or not everything should be in leveldb or partially in flat files
4332019-01-10T19:39:05  <jimpo> otherwise it involves messing around with validation code before there's even a consensus change
4342019-01-10T19:39:05  <gmaxwell> If I drop out support for upgrades and what not, I believe I could add support for including indexes with two dozen lines of code.  Obviously not a fair comparison.
4352019-01-10T19:39:06  <wumpus> right, with decoupling at least changes can be localized and contained, instead of tying everything together
4362019-01-10T19:39:25  <gmaxwell> But building a pile of logical abstractions that add layers and layers is not actually a reduction in complexity.
4372019-01-10T19:39:32  <wumpus> exactly jimpo
4382019-01-10T19:39:34  <gmaxwell> It's decomplexity theater.
4392019-01-10T19:39:40  <sipa> please
4402019-01-10T19:39:55  <wumpus> is that what he's doing?
4412019-01-10T19:40:13  <jimpo> rich hickey would disagree, I think
4422019-01-10T19:40:18  *** profmac has joined #bitcoin-core-dev
4432019-01-10T19:40:57  <gmaxwell> and then we just spend our entire lives on pointless refactors shifting around the deckchairs on this fractal of layers, while seldom actually advancing visible functionality, which is exactly what the project has been doing for the last year.
4442019-01-10T19:41:10  <wumpus> I don't think this is construcive anymore
4452019-01-10T19:41:14  <wumpus> any other topics?
4462019-01-10T19:41:29  <jonasschnelli> rw_config INI vs UniValue
4472019-01-10T19:41:36  <jamesob> operation of cblockindex is consensus critical; atm serving filter blocks is not => decoupling failure of the optional feature from the critical one is safer
4482019-01-10T19:41:49  <wumpus> #topic rw_config INI vs UniValue (jonasschnelli)
4492019-01-10T19:41:53  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11082#issuecomment-451406061
4502019-01-10T19:42:05  *** mistergold has quit IRC
4512019-01-10T19:42:13  <jonasschnelli> The current rw_config PR from luke-jr uses .INI file structure (own parser)...
4522019-01-10T19:42:29  <jonasschnelli> The question is, if a simple JSON file wouldn't be simpler and more stable
4532019-01-10T19:42:39  <wumpus> jamesob: FWIW I agree, as long as it is not consensus critical, it's better to have it separate from the consensus critical code, this was the same idea with separating out the other indexes
4542019-01-10T19:43:08  <wumpus> but apparently all of that was pointless —
4552019-01-10T19:43:14  <jimpo> JSON is somewhat less human-readable IMO
4562019-01-10T19:43:38  <jonasschnelli> Yes. But should its main focus be human editable / readable?
4572019-01-10T19:43:46  <jamesob> also more annoying to write (e.g. trailing commas on last key causes errors)
4582019-01-10T19:45:44  <jonasschnelli> I think using a JSON file is more straight forward since we have the parser/writer logic in place (rather then adding another file format)
4592019-01-10T19:46:02  *** promag has quit IRC
4602019-01-10T19:46:14  <jonasschnelli> Also, the rw_configs focus AFAIK is "edit through the application layer" rather then manually with a text editor
4612019-01-10T19:46:20  <ryanofsky> the question isn't really "do you like ini or json better?" the question is how do you want to replace QSettings? with a new ini parser, or existing ini parser, or with existing univalue parser?
4622019-01-10T19:46:34  <jamesob> I'm in favor of whatever is less code
4632019-01-10T19:46:54  <jonasschnelli> UniValue is very likely less code
4642019-01-10T19:47:17  <jimpo> Yeah, I'm on board with JSON
4652019-01-10T19:47:33  <jonasschnelli> But maybe we pick up the discussion when luke-jr is back or – if you care – comment on the PR
4662019-01-10T19:49:12  <jonasschnelli> other topics?
4672019-01-10T19:49:33  <jamesob> so can we proceed on jimpo's option (2), i.e. indexing in ldb and storing filters in flatfiles?
4682019-01-10T19:50:33  <wumpus> jamesob | I'm in favor of whatever is less code   <- same
4692019-01-10T19:50:48  *** gekisai has quit IRC
4702019-01-10T19:51:16  <wumpus> no other topics?
4712019-01-10T19:51:44  <jnewbery> reminder: wallet IRC meeting tomorrow
4722019-01-10T19:52:52  <wumpus> #endmeeting
4732019-01-10T19:52:52  <lightningbot> Meeting ended Thu Jan 10 19:52:52 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4742019-01-10T19:52:52  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-10-19.00.html
4752019-01-10T19:52:52  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-10-19.00.txt
4762019-01-10T19:52:52  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-10-19.00.log.html
4772019-01-10T19:53:36  *** promag has joined #bitcoin-core-dev
4782019-01-10T19:54:27  *** benthecarman_ has joined #bitcoin-core-dev
4792019-01-10T19:55:21  <dongcarl> I would like people to take a look at #12255 when they can, I'm not sure if there is precedent for how this is usually done but I think we should contact distro package maintainers if we decide it should be merged
4802019-01-10T19:55:23  <gribble> https://github.com/bitcoin/bitcoin/issues/12255 | Update bitcoin.service to conform to init.md by dongcarl · Pull Request #12255 · bitcoin/bitcoin · GitHub
4812019-01-10T19:56:11  <dongcarl> I do not want careless distro maintainers clogging up people's hard drives and bringing down nodes just because the default datadir has changed
4822019-01-10T19:57:08  *** benthecarman has quit IRC
4832019-01-10T19:57:34  *** bentheacarman__ has joined #bitcoin-core-dev
4842019-01-10T19:58:49  *** hebasto has quit IRC
4852019-01-10T19:59:27  *** benthecarman has joined #bitcoin-core-dev
4862019-01-10T19:59:54  *** benthecarman_ has quit IRC
4872019-01-10T20:06:23  <wumpus> to be honest I have no idea who is actually using those files, whether they're used in any distro packaging
4882019-01-10T20:06:54  <wumpus> I do know it tends to be hard to find reviewers for init scripts and such
4892019-01-10T20:07:26  <wumpus> I think they're meant as examples in the first place, to copy over and tweak, not for anything to be automtically installing them
4902019-01-10T20:08:50  <wumpus> but it's a good point...
4912019-01-10T20:12:23  *** Guest29947 has joined #bitcoin-core-dev
4922019-01-10T20:12:35  <dongcarl> wumpus: I know that at least Arch Linux uses the systemd file
4932019-01-10T20:13:29  <gwillen> I would appreciate if people would glance at #14978, it has a couple of utACKs but I don't really know what it needs before someone is comfortable merging it
4942019-01-10T20:13:31  <gribble> https://github.com/bitcoin/bitcoin/issues/14978 | Factor out PSBT utilities from RPCs for use in GUI code; related refactoring. by gwillen · Pull Request #14978 · bitcoin/bitcoin · GitHub
4952019-01-10T20:16:36  *** chenpo has quit IRC
4962019-01-10T20:20:56  *** promag has quit IRC
4972019-01-10T20:23:35  *** ddustin has joined #bitcoin-core-dev
4982019-01-10T20:24:28  *** gekisai has joined #bitcoin-core-dev
4992019-01-10T20:28:26  *** EagleTM has joined #bitcoin-core-dev
5002019-01-10T20:29:09  *** gekisai has quit IRC
5012019-01-10T20:29:24  *** gekisai has joined #bitcoin-core-dev
5022019-01-10T20:32:32  *** pinheadmz has joined #bitcoin-core-dev
5032019-01-10T20:37:49  *** AaronvanW has quit IRC
5042019-01-10T20:45:36  *** promag has joined #bitcoin-core-dev
5052019-01-10T20:48:08  *** AaronvanW has joined #bitcoin-core-dev
5062019-01-10T20:52:33  *** AaronvanW has quit IRC
5072019-01-10T20:54:01  *** chenpo has joined #bitcoin-core-dev
5082019-01-10T20:54:58  *** promag has quit IRC
5092019-01-10T20:58:46  *** pinheadmz has quit IRC
5102019-01-10T21:01:37  *** promag has joined #bitcoin-core-dev
5112019-01-10T21:07:28  *** promag has quit IRC
5122019-01-10T21:10:16  <phantomcircuit> sipa, what does openssl's rng do to gather entropy? anything that you're not already doing?
5132019-01-10T21:11:30  <gmaxwell> phantomcircuit: I believe the code in sipa's PR does more or less strictly more than openssl does by default on linux at least.
5142019-01-10T21:11:49  <gmaxwell> phantomcircuit: it reads dev/urandom and also combines in e.g. the stack pointer and a time.
5152019-01-10T21:11:58  <phantomcircuit> also why remove the perfmon data from GetStrongRand* functions
5162019-01-10T21:12:46  <phantomcircuit> oh i see you moved it to the scheduler, makes sense
5172019-01-10T21:12:52  <gmaxwell> phantomcircuit: the permon is already only once in a while (its slow), in the PR it gets moved to the idle thread.
5182019-01-10T21:13:01  <gmaxwell> right.
5192019-01-10T21:19:06  *** Giszmo has quit IRC
5202019-01-10T21:25:50  *** lnostdal has joined #bitcoin-core-dev
5212019-01-10T21:36:32  *** Giszmo has joined #bitcoin-core-dev
5222019-01-10T21:40:07  *** DeanGuss has joined #bitcoin-core-dev
5232019-01-10T21:46:30  *** pinheadmz has joined #bitcoin-core-dev
5242019-01-10T21:52:29  *** Guyver2 has quit IRC
5252019-01-10T21:57:56  *** AaronvanW has joined #bitcoin-core-dev
5262019-01-10T22:03:56  *** DeanGuss has quit IRC
5272019-01-10T22:04:20  *** DeanGuss has joined #bitcoin-core-dev
5282019-01-10T22:05:46  *** michaelsdunn1 has quit IRC
5292019-01-10T22:07:52  *** Guest51719 has quit IRC
5302019-01-10T22:08:46  *** Liliaceae has quit IRC
5312019-01-10T22:10:44  *** Liliaceae has joined #bitcoin-core-dev
5322019-01-10T22:33:03  *** hidden has joined #bitcoin-core-dev
5332019-01-10T22:33:08  *** hidden has left #bitcoin-core-dev
5342019-01-10T22:33:25  *** spinza has quit IRC
5352019-01-10T22:37:55  *** hidden has joined #bitcoin-core-dev
5362019-01-10T22:45:39  <hidden> https://github.com/bitcoin/bitcoin/issues/7463#issuecomment-306336149 does anybody know how i could recover keys from keypool that has been damaged in relation to this issue?
5372019-01-10T22:46:09  <hidden> i have been trying for years now any help will be hugely appreciated
5382019-01-10T23:04:18  *** sfhi has quit IRC
5392019-01-10T23:05:11  <gwillen> hidden: is there a writeup somewhat of what happened, what the failure looks like, and what you've tried
5402019-01-10T23:05:19  <gwillen> the easiest way to get help will start with writing those things down
5412019-01-10T23:06:21  <gwillen> (also, I'm not sure this channel is the right place to seek help, but in any case it's not the right place to have a long discussion about it)
5422019-01-10T23:07:19  *** spinza has joined #bitcoin-core-dev
5432019-01-10T23:11:49  *** timothy has quit IRC
5442019-01-10T23:11:57  <hidden> gwillen basically i salvagewallet and it said failed and wallet is corrupt. if i try to open the client again it i could try generate a new address to load up the reserved ones in the keypool, i could do so until i the "unknown key in key pool" error. i can dump the wallet (which was renamed ending .bak december 2013) using pywallet. in the dump i see the address and the corresponding "public_key_hex" under list of keypool but not the
5452019-01-10T23:11:57  <hidden> private key.
5462019-01-10T23:12:12  *** echonaut has quit IRC
5472019-01-10T23:13:05  <hidden> I also downloaded berkeley DB, did a db_dump, didn't go anywhere much yet, i hear doing recovery without aggressive might help but still clueless and learning about berkely db.
5482019-01-10T23:13:34  <hidden> it's not a HD wallet as you might have guessd. the link i posted (https://github.com/bitcoin/bitcoin/issues/7463#issuecomment-306336149) details the exact issue.
5492019-01-10T23:13:57  *** echonaut has joined #bitcoin-core-dev
5502019-01-10T23:14:16  <hidden> maybe even a solution was provided there to retrieve keys but i couldn't follow. if anyone has idea on what to do, patiently just idling and searching solutions thanks.
5512019-01-10T23:15:52  <gwillen> hm, if pywallet --dumwallet show private keys for other public keys, but not the one in question, presumably that is one of the corrupted records :-\
5522019-01-10T23:16:47  <gwillen> that doesn't necessarily mean there are zero useful bytes to recover, but it does mean some bytes you want have probably been destroyed, and implies that fixing the salvagewallet issue probably wouldn't recover that key
5532019-01-10T23:17:24  *** Giszmo has quit IRC
5542019-01-10T23:17:51  <gwillen> but again I don't want to do too much discussion in this channel -- it would be really helpful if you would write down somewhere, e.g. even just a google doc or something, everything you've tried so far and exactly what you see (e.g. what output do you get from pywallet? obviously don't paste any actual private keys.)
5552019-01-10T23:17:54  <hidden> yes it is one of the the pages are out of order https://pastebin.com/g0gDC990
5562019-01-10T23:19:04  <hidden> the output of pywallet is 600mb its hard to post it. but i can post headers of db_dump https://pastebin.com/TbUM2STN
5572019-01-10T23:19:43  <hidden> i'll write a google doc if no one can provide a solution tonight. maybe it's an easy fix
5582019-01-10T23:20:08  <gwillen> I'll caution that unfortunately it doesn't _sound_ like an easy fix, but I'd love to offer you one if it is -- a google doc would be ideal
5592019-01-10T23:20:59  <gwillen> make sure you don't include any private keys, even ones you think aren't the right ones, just in case -- censor them from anything you post
5602019-01-10T23:21:05  <hidden> ok, i'll get the google doc somewhere, hopefully someone see's the scrollback too who can help. will do some recovery with berkeley db tools
5612019-01-10T23:33:09  *** Giszmo has joined #bitcoin-core-dev
5622019-01-10T23:35:55  *** miknotauro has joined #bitcoin-core-dev
5632019-01-10T23:37:11  *** spaced0ut has quit IRC
5642019-01-10T23:38:36  *** promag has joined #bitcoin-core-dev
5652019-01-10T23:43:14  *** echonaut has quit IRC
5662019-01-10T23:43:25  *** echonaut has joined #bitcoin-core-dev
5672019-01-10T23:54:25  *** ddustin has quit IRC
5682019-01-10T23:54:45  *** ddustin has joined #bitcoin-core-dev