12019-04-04T00:02:59  <sipa> achow101: aftee batching the writes, it should be almost entirely cpu bound
  22019-04-04T00:04:00  *** supay has joined #bitcoin-core-dev
  32019-04-04T00:04:05  <sipa> so you're now at 8ms of CPU per generated key?
  42019-04-04T00:04:32  <supay> i lost access to my bitcoin and scrubbed my system for any data i could find. found some bip32/44 paths. trying to import private keys into bitcoin core using importprivkey, but that isn't working. there aren't any errors either. any help?
  52019-04-04T00:04:56  <sipa> oh, if we'd cache intermediary results in the key derivation we'd save a bunch
  62019-04-04T00:05:01  *** drexl has joined #bitcoin-core-dev
  72019-04-04T00:07:05  <achow101> sipa: I'm pretty sure it's still spending most of the time on writing to the wallet as the wallet file starts growing in size almost immediately and that should only happen only after all keys are derivec
  82019-04-04T00:08:16  <gmaxwell> supay: what exactly does "isn't working" mean?
  92019-04-04T00:09:05  <supay> gmaxwell: i've done: bitcoin-cli importprivkey the_key "" true  -- and i wait about 25 mins or so for the rescan, and when i run bitcoin-cli getwalletinfo, the balances are still 0
 102019-04-04T00:10:17  <sipa> supay: are you sure the private key you're importing corresponds to the address?
 112019-04-04T00:10:37  <gwillen> hey supay, I assume you are 0x23212f from github?
 122019-04-04T00:10:45  <sipa> could it be you're importing a root key instead of the derived key?
 132019-04-04T00:11:12  <sipa> or gotten the compression flag wrong? (depending on how you obtained the private key)
 142019-04-04T00:11:14  <supay> sipa: to which address? i gather importing the private key suffices, as it has the address?
 152019-04-04T00:11:21  <supay> gwillen: yes, that is correct! :)
 162019-04-04T00:11:33  <sipa> supay: well i don't know where you got the key
 172019-04-04T00:11:40  <gwillen> supay: you said the path is m/44'/0'/0'/0/427 -- are you trying to import the master privkey, or the privkey derived from that path?
 182019-04-04T00:11:47  <supay> gwillen: thank you for your reply there. i wasn't aware this channel exists.
 192019-04-04T00:12:25  <gwillen> np, I didn't want to encourage you to come here since it's not really a tech support channel, but the people here are trustworthy :-)
 202019-04-04T00:12:49  <supay> gwillen: i have a bunch of lines like this one (multiple paths). i see them as 4 comma separated values. the 2nd column is address, the 4th is private key. i'm not sure if it's the master or otherwise
 212019-04-04T00:12:49  <gwillen> if you are trying to import the master privkey, that is your problem -- bitcoin core does not know about bip 44, and won't try to derive the child keys automatically
 222019-04-04T00:13:08  <gwillen> ahh, if each line has a different key, then I expect it is the child key, which I would expect to have the funds
 232019-04-04T00:13:46  <supay> that is correct, each line has a different key
 242019-04-04T00:13:51  <supay> wait, let me share some with 0 balance
 252019-04-04T00:13:53  <supay> is that safe?
 262019-04-04T00:14:09  <achow101> no, it is not safe
 272019-04-04T00:14:16  <gwillen> supay: if you "getaddressinfo" the address after importing the privkey, what does it say about ismine and solvable?
 282019-04-04T00:14:27  <gwillen> supay: sharing private keys is, to a first approximation, never ever safe
 292019-04-04T00:14:35  <supay> haha, makes sense
 302019-04-04T00:14:41  <supay> let me check getaddressinfo, one moment
 312019-04-04T00:15:04  <gwillen> and in fact, sharing private keys which are derived from a path related to other private keys that have funds is _specifically_ unsafe
 322019-04-04T00:15:09  <supay> gwillen: ismine for that address is current false
 332019-04-04T00:15:12  <gmaxwell> supay: rescan can take hours depending on your system, but the call blocks while it's in progress so you'll now when its done.
 342019-04-04T00:15:18  <gwillen> and the fact that this is not obvious results in some serious arguments over usability
 352019-04-04T00:15:26  <gwillen> gmaxwell: he said in his github issue that the rescan completed
 362019-04-04T00:15:29  <supay> gmaxwell: i've been observing debug.log. i'm sure rescan is complete
 372019-04-04T00:16:04  <gmaxwell> supay: good!
 382019-04-04T00:16:43  <supay> gmaxwell: wait, is ismine: false a good thing? :o
 392019-04-04T00:16:45  <gmaxwell> aside the above exchange with supay asking if it was safe to share zero balance keys with us in here, ... ahem,  non-hardened derrivation, ... how many users would even ask if it was safe? [/obrant]
 402019-04-04T00:17:02  <gwillen> gmaxwell: yes, indeed, the very fact that he asked the question is strong evidence of your rightness in this argument :-)
 412019-04-04T00:17:50  <supay> i'm so confused. i shouldn't have asked?
 422019-04-04T00:17:55  <gwillen> haha, no, not at all
 432019-04-04T00:17:58  <supay> :D
 442019-04-04T00:18:03  <gwillen> just that most people would go ahead and share without asking
 452019-04-04T00:18:08  <gwillen> which would be bad because it would compromise their wallet
 462019-04-04T00:18:08  <achow101> supay: ismine false means that address is not part of your wallet
 472019-04-04T00:18:22  <supay> gwillen: ah yes, but you cautioned me in the github reply!
 482019-04-04T00:18:25  <gwillen> and there is an ongoing argument over the fact that this happens
 492019-04-04T00:18:38  <gmaxwell> supay:  it's good you asked, ignore my comment there-- I'm just pointing out that its relevant to a unrelated longer term debate.
 502019-04-04T00:18:39  <achow101> supay: so either importprivkey is not working (we have tests, but it's possible) or the address you have is not an address corresponding to that private key
 512019-04-04T00:18:51  <supay> achow101: that is correct. all the material i have read indicates directly using importprivkey. do i need to first add the address to the wallet?
 522019-04-04T00:19:12  <supay> gmaxwell: ah hehe
 532019-04-04T00:19:28  <gwillen> supay: if you run dumpprivkey address, it will show you what it thinks the privkey is for the address
 542019-04-04T00:19:35  <gwillen> and you can compare it to the one you have in your own dump
 552019-04-04T00:19:36  <supay> achow101: right, i really hope it is not the latter
 562019-04-04T00:19:53  <gmaxwell> I'm guessing that the privkey he is importing doesn't match the address he expects. Maybe due to a compressed flag?
 572019-04-04T00:19:57  <gwillen> if it's different, don't panic yet, there are lots of ways that the UX can be confusing
 582019-04-04T00:20:07  <gmaxwell> supay: what software wrote this list of addresses / paths/ keys?
 592019-04-04T00:20:25  <supay> gmaxwell: can't be very sure! :(
 602019-04-04T00:20:33  <achow101> supay: can you try `bitcoin-cli listaddressgroupings` and see if your address is in there?
 612019-04-04T00:20:44  <supay> i just searched for these patterns on a backup of my computer
 622019-04-04T00:20:49  <supay> achow101: sure, one moment
 632019-04-04T00:21:11  <gmaxwell> I believe supay said above he was getting ismine false on an address he believed he imported a private key for
 642019-04-04T00:21:29  <gmaxwell> If so, I think that proves that he did not successfully import a matching private key.
 652019-04-04T00:21:41  <supay> achow101: hm, interesting. another one that i tried some time ago is on listaddressgroupings. this one, i ran importaddress but didn't import the private key yet
 662019-04-04T00:21:54  *** fanquake has joined #bitcoin-core-dev
 672019-04-04T00:21:59  <achow101> supay: that's expected. importaddress imports the address to be watched.
 682019-04-04T00:22:07  <supay> gmaxwell: is that the only conclusion? :(
 692019-04-04T00:22:08  <gwillen> supay: ahhhh sorry, did you run 'getaddressinfo' on one where you just imported the address? I meant to suggest you do it on one where you imported the key.
 702019-04-04T00:22:11  <supay> achow101: ah, alright
 712019-04-04T00:22:26  <achow101> do you see any unfamiliar addresses there? if so, try dumpprivkey on those addresses and see if you can find the one that matches the private key you imported
 722019-04-04T00:22:27  <supay> gwillen: ah no, i ran it on the one where i imported the key
 732019-04-04T00:22:38  <gwillen> supay: don't panic yet, there are many many ways that the user interface can go wrong, and most of them do not involve you losing coins once we figure out what's goin gon
 742019-04-04T00:22:47  <supay> achow101: i do infact, this was a clean install. there were definitely some new addresses
 752019-04-04T00:22:58  <supay> gwillen: oh! that's a relief
 762019-04-04T00:23:06  <gwillen> honestly all this stuff is very arcane
 772019-04-04T00:23:23  <gmaxwell> My leading hypothesis is that the dump he has shows the wrong addresses with the keys. E.g. because it mishandles the compressed flag.
 782019-04-04T00:23:47  <gmaxwell> Or because of some off by one, like each line is the address for the private key on the prior/next line.
 792019-04-04T00:24:14  <gmaxwell> either case is easily fixable if they're the issue.
 802019-04-04T00:24:33  <achow101> gmaxwell: i'm trying to figure out if he's got an off by one or something like that. once he can find the address that was imported for the private key, he can check if that's in his list
 812019-04-04T00:24:35  <gmaxwell> supay: has any of the addresses which have balances that you're trying to import spent before?
 822019-04-04T00:25:10  <achow101> gmaxwell: i would be surprised if it was a compressed flag problem. the key is compressed (he says it begins with K) and it's BIP 32 derived, which basically requires compressed keys
 832019-04-04T00:25:44  <supay> gmaxwell: not sure, but pm'd you one such address
 842019-04-04T00:25:59  <gmaxwell> achow101: darn, I missed the fact that we'd already asked for the leading character.
 852019-04-04T00:26:37  <supay> achow101: yep, starts with a K. another with a K. and there's one with an L
 862019-04-04T00:26:38  <achow101> gmaxwell: not so much asked but provided in the issue :) #15736
 872019-04-04T00:26:39  <gribble> https://github.com/bitcoin/bitcoin/issues/15736 | Unable to importprivkey · Issue #15736 · bitcoin/bitcoin · GitHub
 882019-04-04T00:28:01  <gmaxwell> supay: does the file you're taking these from have any kind of header that I could use to determine the originating software?
 892019-04-04T00:28:55  <gmaxwell> achow101: still possible some broken app was using bip32 with uncompressed keys. But I agree thats a lot less likely.
 902019-04-04T00:29:01  <supay> it had something indicating the columns. that's all i remember. unfortunately, got rid of the header!
 912019-04-04T00:29:23  <supay> that's how i know the last column was private key and second column was address
 922019-04-04T00:29:34  <gmaxwell> in the future when you're trying to recover data, take care to not throw anything out. :P
 932019-04-04T00:29:40  <supay> yess :(
 942019-04-04T00:30:07  <gmaxwell> do we really have no rpc that will take a private key and return addresses?
 952019-04-04T00:30:08  *** jarthur has joined #bitcoin-core-dev
 962019-04-04T00:30:43  <achow101> gmaxwell: nope
 972019-04-04T00:31:46  <supay> gmaxwell: interestingly, i think electrum does that
 982019-04-04T00:31:59  <supay> when you import a private key, it says "so and so addresses were added"
 992019-04-04T00:32:32  <gmaxwell> probably the easiest thing to do would be to import a single additional key from the middle of the list with rescan false, and then look in dumpwallet output to see what new address got added.
1002019-04-04T00:33:12  <supay> oh, i see, let me try that
1012019-04-04T00:33:36  *** IGHOR has quit IRC
1022019-04-04T00:33:56  <gwillen> (in general I recommend always using rescan false, and then call rescanblockchain when you're ready to rescan -- you can give it a height to start scanning so it doesn't need to start in 2009)
1032019-04-04T00:35:28  *** jarthur has quit IRC
1042019-04-04T00:36:26  <supay> oh, i didn't know you could do that! interesting :D
1052019-04-04T00:36:50  <supay> gmaxwell: my dumpwallet output is huge. so many keys, addresses etc. no idea where all of these came from
1062019-04-04T00:37:10  <achow101> supay: bitcoin core's default wallet will generate 2000 keys automatically
1072019-04-04T00:37:11  *** IGHOR has joined #bitcoin-core-dev
1082019-04-04T00:37:15  <gmaxwell> supay: by default the wallet starts off with 2000 keys generated in it.
1092019-04-04T00:37:22  <achow101> that's expected. just open the file in a text editor and ctrl+f your private key
1102019-04-04T00:37:29  <supay> oh, wow. i see
1112019-04-04T00:38:43  <supay> alright, the addresses are definitely not what i expected. both have 0 balance
1122019-04-04T00:39:08  *** gwillen has quit IRC
1132019-04-04T00:39:28  *** gwillen has joined #bitcoin-core-dev
1142019-04-04T00:39:56  <gmaxwell> are the addresses with them addresses that are in your list anywhere?
1152019-04-04T00:40:06  <supay> nope, they aren't! :O
1162019-04-04T00:40:17  *** gwillen__ has joined #bitcoin-core-dev
1172019-04-04T00:40:21  <achow101> supay: one thing that I think we forgot to mention was the address type. dumpwallet probably gives you addresses beginning with 3, yes? what do the addresses in your list begin with?
1182019-04-04T00:40:49  <achow101> (rescan will pick up both address types, just that exporting addresses from core will use the default type)
1192019-04-04T00:41:07  <supay> dumpwallet gave me 3 address corresponding with the private key. the addresses on the list begin with 1
1202019-04-04T00:41:42  <achow101> restart bitcoind with with -addresstype=legacy and try the dumpwallet thing again
1212019-04-04T00:42:11  <supay> alright, let me give that a go
1222019-04-04T00:42:22  <gwillen> btw supay, are you only using bitcoin core for rescuing this old wallet? I.e. you have no other funds in it?
1232019-04-04T00:42:33  <supay> yes, that is correct!
1242019-04-04T00:42:35  <gwillen> (if so, it's possible to set it up without the 2000 keys already in it, just to reduce confusion)
1252019-04-04T00:43:01  <achow101> gwillen: that's not in a release yet
1262019-04-04T00:43:10  <gwillen> o :-(
1272019-04-04T00:43:15  <gwillen> heh, nevermind
1282019-04-04T00:43:24  <achow101> would require installing 0.18.0rc2
1292019-04-04T00:45:02  <gmaxwell> huh? you can still set the keypool size to 1.
1302019-04-04T00:45:26  <achow101> oh right. I assumed gwillen was talking about blank wallets
1312019-04-04T00:46:43  *** omonk has quit IRC
1322019-04-04T00:46:46  <supay> achow101: restarted bitcoind with that flag. however, same addresses in dumpwallet
1332019-04-04T00:46:48  <gwillen> ohhh, I was, but that's clever
1342019-04-04T00:47:06  <gwillen> you probably need to do the import again now that the flag is set
1352019-04-04T00:47:14  <supay> ah, alright
1362019-04-04T00:47:21  <gwillen> the addresses are remembered from before, unless you make a new wallet
1372019-04-04T00:48:08  <gwillen> BTW, let me take this opportunity to ask: you have multiple safe copies of this list of private keys, right? Stored in at least a few places, at least one of which is not "electronically on the computer you're using right now"?
1382019-04-04T00:48:17  <gwillen> since you have hopefully learned your lesson about single points of failure? :-)
1392019-04-04T00:48:28  *** gwillen__ has quit IRC
1402019-04-04T00:48:53  <supay> i don't have more copies ;((((
1412019-04-04T00:49:05  <gwillen> well you should make them now
1422019-04-04T00:49:17  <supay> hahaha, alright
1432019-04-04T00:49:18  <gwillen> before you do any more fiddling with the list, like, very carefully copy it to a USB stick
1442019-04-04T00:49:28  <gwillen> and do not even dream of getting rid of the old hard drive / backup / whatever you got it from
1452019-04-04T00:49:34  <gwillen> never do any more backups to that drive or touch it in any way
1462019-04-04T00:49:41  <gwillen> store it safely as an extra precaution
1472019-04-04T00:49:55  <supay> hehe, that makes sense
1482019-04-04T00:50:05  <supay> wait, let me retrieve the list as i had it before
1492019-04-04T00:50:10  <supay> i think that will shed more light to this issue
1502019-04-04T00:50:16  <gwillen> (for example, if there is somehow something wrong with your dump, or it is incomplete, you might have to go back to it and try to dig out more informattion)
1512019-04-04T00:50:45  <gwillen> in fact, consider buying another drive to make an identical copy of whatever drive that is
1522019-04-04T00:51:06  <achow101> supay: in your dumpwallet output, you should see multiple addresses for each private key
1532019-04-04T00:51:25  <gwillen> like, do the math on how much your bitcoins are worth, and consider that the bits we are helping you recover right now are effectively a pile of hundred-dollar bills of the equivalent value
1542019-04-04T00:51:28  <supay> gwillen: i have a few copies of the backup, on cloud. but i'll make other physical copies as well
1552019-04-04T00:51:30  <gwillen> and you should treat them with equivalent care
1562019-04-04T00:51:35  <supay> achow101: yes, that is correct. i see 3
1572019-04-04T00:51:36  <gwillen> okay, great
1582019-04-04T00:51:42  <gwillen> (hopefully encrypted in the cloud...)
1592019-04-04T00:51:53  <supay> yep, it is encrypted! :)
1602019-04-04T00:52:02  <achow101> supay: one of those should begin with a 1, that doesn't match what you have in your list?
1612019-04-04T00:53:02  <supay> achow101: right. there's one that begins with 1. it doesn't match :( which is why i want to get a clean dump of the files and try again. i think i messed up somewhere along the way
1622019-04-04T00:53:16  <achow101> do you see that address anywhere else in your list?
1632019-04-04T00:53:54  <supay> the one in dumpwallet? nope, that isn't present in my list
1642019-04-04T00:54:39  *** omonk has joined #bitcoin-core-dev
1652019-04-04T00:54:56  *** supay has quit IRC
1662019-04-04T00:55:25  <achow101> I doubt that you've done anything wrong that's made this output an incorrect address. I think it's far more likely that the private keys you have simply don't match
1672019-04-04T00:56:05  <gwillen> oops, we lost him
1682019-04-04T00:57:44  *** jtimon has quit IRC
1692019-04-04T00:58:03  *** spaced0ut has quit IRC
1702019-04-04T00:58:48  *** zivl has quit IRC
1712019-04-04T01:24:44  <gwillen> hmm, I just imported a descriptor with no private keys, and got ""All private keys are provided, outputs will be considered spendable. If this is intentional, do not specify the watchonly flag."
1722019-04-04T01:25:11  <gwillen> it's a sh(wsh(multi(2,A,B,C))) with fingerprints and paths given
1732019-04-04T01:25:16  <gwillen> and tpubs
1742019-04-04T01:26:01  <sipa> are the privkeys already imported?
1752019-04-04T01:26:08  <gwillen> although getdescriptorinfo on it returns "hasprivatekeys": false
1762019-04-04T01:26:14  <gwillen> shouldn't be
1772019-04-04T01:26:25  <sipa> in that case it sounds like there's a bug...
1782019-04-04T01:26:32  <gwillen> *nods*
1792019-04-04T01:27:31  <sipa> what does gai on one of the resulting addresses say?
1802019-04-04T01:29:33  <gwillen> I'm actually not sure how to get an address from it
1812019-04-04T01:29:44  <gwillen> that was going to be the next thing to figure out :-)
1822019-04-04T01:29:44  <sipa> deriveaddresses
1832019-04-04T01:29:48  <gwillen> oho
1842019-04-04T01:30:25  <gwillen> gai says ismine: false
1852019-04-04T01:31:04  <gwillen> gai also displays the desc in a kind of broken way, uhoh
1862019-04-04T01:31:10  <gwillen> it's suppose to step all three *'s together, right?
1872019-04-04T01:31:57  <sipa> yes
1882019-04-04T01:32:08  <gwillen> ahh, it looks like maybe it is, but it's forgotten the origin info for all but the first one
1892019-04-04T01:32:16  <gwillen> so they display without it, but they're still changing
1902019-04-04T01:32:30  <gwillen> this is a peak bug-filing day for me I guess :-)
1912019-04-04T01:32:56  <gwillen> I suppose not a lot of people are executing these codepaths yet
1922019-04-04T01:33:49  <sipa> yeah
1932019-04-04T01:36:48  <gwillen> fanquake: how do you tag those so fast :-P
1942019-04-04T01:36:49  <gwillen> are you a robot
1952019-04-04T01:50:42  *** benthecarman has joined #bitcoin-core-dev
1962019-04-04T01:50:46  *** drexl has quit IRC
1972019-04-04T01:51:28  *** drexl has joined #bitcoin-core-dev
1982019-04-04T01:52:27  *** benthecarman has quit IRC
1992019-04-04T01:55:56  *** drexl has quit IRC
2002019-04-04T02:15:01  *** BGL has quit IRC
2012019-04-04T02:25:36  *** zivl has joined #bitcoin-core-dev
2022019-04-04T02:31:21  *** jarthur has joined #bitcoin-core-dev
2032019-04-04T02:36:44  *** jarthur has quit IRC
2042019-04-04T02:50:10  <sipa> gwillen: i have met a humanoid-looking individual who claims to be fanquake
2052019-04-04T02:54:50  * luke-jr wonders if the security danger to assumeutxo could be mitigated by only producing hashes encrypted to a key that controls UTXOs over a certain value
2062019-04-04T03:00:07  <gmaxwell> luke-jr: -ECOMPREHENSIONFAIL
2072019-04-04T03:00:25  <gmaxwell> forget the mechenism, what property are you trying to achieve?
2082019-04-04T03:01:25  <luke-jr> gmaxwell: making it infeasible to trust someone else's UTXO snapshot
2092019-04-04T03:01:36  <luke-jr> ie, you can generate your own on PC A, and move it to PC B, but that's it
2102019-04-04T03:02:11  <gmaxwell> well you can just copy your chainstate now...
2112019-04-04T03:02:55  <luke-jr> gmaxwell: context is a ML thread suggesting assumeutxo can only be modified in code, which not only creates a trust-the-devs problem, it also makes it useless for this legitimate use case
2122019-04-04T03:03:05  <gmaxwell> Personally I'm fine with "a trivially validated (root) hash is embedded in the software you run, and subject to the same review process that governs any other update to it" but I know that some people (morcos, and I think sipa) felt that was placing too much responsiblity on the developers/reviewer.  I still feel that they could be convinced otherwise, since I still haven't seen a counter to my
2132019-04-04T03:03:05  <gmaxwell> primary assertion that essentially every change to the software has the same/worse security risk, but most are much harder to review.
2142019-04-04T03:03:17  <gmaxwell> luke-jr: which legitimate use case?
2152019-04-04T03:03:39  <luke-jr> gmaxwell: an easy way for users to bootstrap new nodes of their own, from an older node they already synced
2162019-04-04T03:03:48  <luke-jr> and/or effectively backup their chainstate
2172019-04-04T03:04:21  <luke-jr> (if it gets corrupted, having a commitment to a UTXO set would help recover quicker)
2182019-04-04T03:04:44  *** drexl has joined #bitcoin-core-dev
2192019-04-04T03:05:51  <gmaxwell> luke-jr: I thnk that usecase is essentially irrelevant:  consider,  we must support users syncing up without that because that will always be the vast majority of the syncups,  without too much pain.   If we do, then the 'use yourself' is not much of an improvement-- you just go from acceptable to somewhat better.    Relatedly,  we must be able to catch up several months of activity in a short
2202019-04-04T03:05:51  <gmaxwell> amount of time, otherwise nodes that have been offline for a couple months will not be recoverable except through a trusty process... (e.g. the case with ethereum now).
2212019-04-04T03:07:08  <luke-jr> I don't have a magic solution to make IBD instant.
2222019-04-04T03:07:48  <gmaxwell> Also, I think the problem with the kind of thinking you're offering there is that the overlap in users that want instant magic now,  can't just rsync an existing node,  and will actually go along with some complicated utxo encryption scheme is essentially zero.
2232019-04-04T03:08:13  <gmaxwell> luke-jr: no, but instant I think isn't really important  (and for anyone who wants faster, rsyncing a node is probably never going to be beat)
2242019-04-04T03:08:30  <luke-jr> it doesn't need to be complicated
2252019-04-04T03:09:24  <gmaxwell> luke-jr: so you have some always on AWS node .... oh now you have to take one of your valuable private keys, manually handle it, put it on it...  essentially no one will ever do that.
2262019-04-04T03:10:13  <gmaxwell> just rsync. rsync works fine. We can make rsync work better by havin an rpc to flush and quiesce the chainstate.
2272019-04-04T03:10:52  <luke-jr> it's good if it doesn't work with untrustworthy AWS nodes..
2282019-04-04T03:11:01  <luke-jr> rsync doesn't work for backups
2292019-04-04T03:11:38  <gmaxwell> What you're describing effectively doesn't work for backups either.
2302019-04-04T03:11:56  <luke-jr> why not?
2312019-04-04T03:12:40  <luke-jr> actually, it might not even need encryption for that case: just update the wallet file with a UTXO snapshot regularly, and restore from that if it's there
2322019-04-04T03:14:42  <gmaxwell> Right. But all that is just begging for some 'helpful person' to fork the software and make the one line patch to remove the agreement check.  Relaying on that, instead of making sure there is little to no need for it, just makes it more likely that in practice all users end up looking like ethereum does now, pure blind trust.
2332019-04-04T03:15:22  *** Eagle[TM] has joined #bitcoin-core-dev
2342019-04-04T03:15:28  <gmaxwell> like if you worry about corruption (A good worry), then just a chainstate recovery without any external loading would be fine.
2352019-04-04T03:15:39  <gmaxwell> (I believe wumpus began working on this before)
2362019-04-04T03:16:10  <luke-jr> for that, we need a way to freeze the chainstate db files during the backup, right?
2372019-04-04T03:16:41  <gmaxwell> I believe wumpus worked on a thing previously to backup the chainstate using ldb snapshots.
2382019-04-04T03:17:24  *** EagleTM has quit IRC
2392019-04-04T03:17:32  <gmaxwell> luke-jr: if we implement a AV utxo sync we'll get chainstate backups as a side effect most likely, since we'll need to store periodic old utxo states for people to sync from.
2402019-04-04T03:18:01  <gmaxwell> (and so presumably the same mechenism could optionally be run more frequently for local-only recovery at the expense of more disk space)
2412019-04-04T03:18:31  <gmaxwell> Though I think if people really need better than what is offered to all users then we have a problem.
2422019-04-04T03:22:34  <gmaxwell> I think that last point basically summarizes my view: We need to offer acceptable performance in an acceptably secure way, if we do not people will do insecure things.  If we do-- then we don't have a strong reason to implement conditionally secure local only behavior, it wouldn't be worth the effort-- because the generally available mechenism is good enough.  We also don't have some massive
2432019-04-04T03:22:34  <gmaxwell> surplus of development resources (review, QA, design, development...), and we've also seen from the past the insecure half solutions (like BIP37) starve more secure secure approaches of resources.
2442019-04-04T03:37:57  *** drexl has quit IRC
2452019-04-04T03:46:27  *** BGL has joined #bitcoin-core-dev
2462019-04-04T04:02:25  *** shesek has quit IRC
2472019-04-04T04:22:16  *** hebasto has joined #bitcoin-core-dev
2482019-04-04T04:32:13  *** jarthur has joined #bitcoin-core-dev
2492019-04-04T04:36:47  *** jarthur has quit IRC
2502019-04-04T04:54:02  *** ppisati has quit IRC
2512019-04-04T05:00:40  *** ppisati has joined #bitcoin-core-dev
2522019-04-04T05:02:54  *** spinza has quit IRC
2532019-04-04T05:08:50  *** cornfeedhobo has quit IRC
2542019-04-04T05:14:51  *** instagibbs has quit IRC
2552019-04-04T05:14:53  *** kljasdfvv has quit IRC
2562019-04-04T05:15:27  *** kljasdfvv has joined #bitcoin-core-dev
2572019-04-04T05:17:04  *** spinza has joined #bitcoin-core-dev
2582019-04-04T05:27:47  *** instagibbs has joined #bitcoin-core-dev
2592019-04-04T05:28:56  <luke-jr> gmaxwell: AV utxo sync is not acceptably secure
2602019-04-04T05:30:31  <gmaxwell> luke-jr: then no software is secure enough because it is strictly more secure then the rest of the software.
2612019-04-04T05:31:22  *** cornfeedhobo has joined #bitcoin-core-dev
2622019-04-04T05:31:30  <gmaxwell> no compromise that can make AV fail couldn't also make the software fail, it is only protected against by review.. and yet review in general is radically harder for software in general than it is for AV.
2632019-04-04T05:33:24  <gmaxwell> there are a million and one subtle changes that would silently turn off validation in production, many of them would be hard for review to detect.
2642019-04-04T05:33:36  <gmaxwell> So how does AV make any of that worse?
2652019-04-04T05:35:28  *** drexl has joined #bitcoin-core-dev
2662019-04-04T05:42:59  <luke-jr> AV utxo sync is not simple AV..
2672019-04-04T05:44:09  <gmaxwell> It isn't clear to me what you're saying.
2682019-04-04T05:44:34  <gmaxwell> What is the attack model that you are concerned with?
2692019-04-04T05:44:37  <luke-jr> as to your argument, it can't be strictly more secure, since it relies on the software being secure as a prerequisite to verify it
2702019-04-04T05:47:10  *** benthecarman has joined #bitcoin-core-dev
2712019-04-04T05:47:47  <gmaxwell> luke-jr: It's more secure than the other vectors, not including them.  Consider a nearly unbreakable lock but which can be defeated by drilling ... in a cardboard door.  We need not debate too much about the limitation of the lock, since anyone that can drill can even more easily just drill right through the rest of the door.
2722019-04-04T05:49:40  <gmaxwell> if someone can sneak through a false AV hash through review and get people to run it, assuming that the software has been updated to compute AV hashes on all nodes (which is the point of pieter's rolling utxo set hash work) so that catching a false one is as trivial as just looking at the output on a node that didn't depend on the update,  ... then that person could just as well sneak through
2732019-04-04T05:49:40  <gmaxwell> something to trigger bypassing scriptchecks or similar.
2742019-04-04T05:50:14  <gmaxwell> because it would be a lot easier to sneak a backdoor like that in, then put in a false hash that everyone could trivially check.  This is the AV security argument.
2752019-04-04T05:50:30  <gmaxwell> It applys no less to utxoav then it does to av in general.
2762019-04-04T05:51:56  <luke-jr> this does assume people *can* verify it; but it is creating a situation where it's likely people won't be able to anymore (because block sizes will get increased since it "doesn't matter" anymore)
2772019-04-04T05:54:14  <gmaxwell> People validate new version with the existing versions that they have.  If you have a valid version, then you can check that a new release is invalid.  So even if no one is starting from scratch you still can't get a compromise though unless you 'break the chain' of review, e.g. by having everyone who reviews leave and get replaced with new people that didn't benefit from the review of others.
2782019-04-04T05:55:04  <gmaxwell> and I don't think it changes the situation on block sizes much, already block sizes are well beyond what results in a sustainable initial sync, and have been for years.
2792019-04-04T05:55:25  <gmaxwell> sustainability of the initial sync isn't a concern there.
2802019-04-04T05:55:35  <gmaxwell> it's already horked.
2812019-04-04T05:55:40  <luke-jr> not entirely yet
2822019-04-04T05:55:52  <luke-jr> today, a new user *can* do the IBD
2832019-04-04T05:56:02  <gmaxwell> even developers of lite clients don't want to run full nodes now, come on.
2842019-04-04T05:56:28  <gmaxwell> luke-jr: yes, well people _can_ do an archive sync of ethereum to, which is several TB of data and months of processing on a very high end system.
2852019-04-04T05:56:33  <gmaxwell> s/to/too/
2862019-04-04T05:57:49  <gmaxwell> luke-jr: it isn't like most users can review updates except in the same kind of sense that they could buy a really high end computer system.
2872019-04-04T05:58:56  <gmaxwell> (in fact, _I_ can't reliably review updates, I am absolutely confident that you could slip a 'stops actually validating' backdoor past me-- but its much less likely that you could get one past everyone who looks)
2882019-04-04T05:59:14  <gmaxwell> (and I assume vice versa)
2892019-04-04T06:00:51  <gmaxwell> luke-jr: Thanks though for explaining more though. I at least agree "utxoav would be an excuse to radically crank load" is something to consider.
2902019-04-04T06:01:31  *** benthecarman has quit IRC
2912019-04-04T06:01:58  <gmaxwell> luke-jr: but I would suggest that the absense of this is already resulting in an outcome where very few users (even businesses) don't run full nodes, and now many that do so via highly insecure opaque snapshot installs.... and that is a lot worse.
2922019-04-04T06:02:12  <luke-jr> gmaxwell: the ability to review code is a boolean; the ability to review a UTXO AV grows with IBD time
2932019-04-04T06:02:39  <luke-jr> although I suppose the "an excuse to radically crank load" problem exists with *any* solution in this area
2942019-04-04T06:02:50  <gmaxwell> luke-jr: not quite. AV review effort is a constant if you've already got a node running.
2952019-04-04T06:03:07  <luke-jr> gmaxwell: new users shouldn't be forced to trust existing users in this way
2962019-04-04T06:03:33  <gmaxwell> but thats also what happens with software review, reviewing the whole of the software is well beyond the capabilities of any single person.
2972019-04-04T06:03:41  <gmaxwell> at best we can hope people review updates.
2982019-04-04T06:04:16  <luke-jr> reviewing code is soemthing new users *can* do, even if not as a single person
2992019-04-04T06:04:47  <gmaxwell> luke-jr: and 'forced' is too strong, you can sync history, even if its costly to the point of being obnoxious: it already is and the result is people not running full nodes, in vast numbers.
3002019-04-04T06:05:10  <luke-jr> that can change if we get 1 TB blocks
3012019-04-04T06:05:43  <gmaxwell> no, because "1 tb blocks" (or similar jokes) isn't remotely viable for continued operation.
3022019-04-04T06:05:54  <gmaxwell> luke-jr: even if capacity were cranked up 'new users' as a group could do a sync from nothing without AV... even if it was so expensive as to make it unrealistic for just a single user to do alone.
3032019-04-04T06:06:30  <gmaxwell> and any load level that was viable for single users to keep _running_ would remain viable for a group of users to history validate for a long time.
3042019-04-04T06:07:42  *** drexl has quit IRC
3052019-04-04T06:12:20  <gmaxwell> as an aside, I really don't think that handicapping the software is a viable way to avoid load increases that compromise security.
3062019-04-04T06:12:44  <gmaxwell> All that approach would do in the long run is demand someone forks the software, fixes the shortcoming, and then pushes you out of the way-- killing your influence.
3072019-04-04T06:16:58  *** Skirmant has quit IRC
3082019-04-04T06:17:21  <gmaxwell> it would be like if you had applied this same logic to compact blocks and  managed to block their introduction... BU would have eventually gotten 'xthin' working right, and then essentially all miners would use it, and many nodes (due to the bandwidth savings).
3092019-04-04T06:18:12  *** Eagle[TM] has quit IRC
3102019-04-04T06:18:18  <luke-jr> compact blocks doesn't have this problem, though?
3112019-04-04T06:18:28  <luke-jr> hmm, I guess in a sense it could be argued to
3122019-04-04T06:19:02  <gmaxwell> sure it could easily be argued to
3132019-04-04T06:19:27  <gmaxwell> (and in fact many people argued that blocksize was no longer an issue because of compact blocks, but most of those people were confused about what compact blocks did)
3142019-04-04T06:20:08  <gmaxwell> there have been a bunch of threads saying essentially "compact blocks made blocks 99% smaller so blocks can now be 100x larger!"
3152019-04-04T06:24:05  *** Skirmant has joined #bitcoin-core-dev
3162019-04-04T06:26:17  <gmaxwell> but my point is that to the extent people thinking that is a risk, you can't solve it by just not making the improvement. Someone else will make it, failing to make it would only just diminish your relevance for future changes.
3172019-04-04T06:26:52  <gmaxwell> (and not only that, it would make true some of the absurd allegations of unethical behavior, e.g. intentionally degrading the system)
3182019-04-04T06:27:01  <gmaxwell> (or at least arguably make them true)
3192019-04-04T06:30:51  <luke-jr> could have different priorities until someone else starts working on such features
3202019-04-04T06:31:11  <luke-jr> not that I'm saying it's necessarily a solution, just a possible alternative to "don't do it and lose users"
3212019-04-04T06:32:46  <gmaxwell> Right, but even with that it still points out that 'don't implement a performance improvement' isn't really a way to effectively avoid security loss in the long run.
3222019-04-04T06:33:06  *** jarthur has joined #bitcoin-core-dev
3232019-04-04T06:33:41  <gmaxwell> and 'people will switch software' is only one risk factor.  For something like initial sync, what happens is that many people don't run fullnodes at all: and we've seen that happen and those folks are overwhelming more likly to think "wtf is capacity limited at all!".
3242019-04-04T06:34:51  <gmaxwell> the analog for compact blocks is e.g. miners doing 'headers only mining' then not caring about propagation/validation speed.
3252019-04-04T06:35:11  <gmaxwell> which, indeed, had become very common before compact blocks
3262019-04-04T06:35:58  <gmaxwell> (and which was a material driver for the development and deployment of compact blocks,  ... not alternative software though that would have also been one had your approach been taken there)
3272019-04-04T06:36:44  <gmaxwell> In any case, point is that ignoring a need isn't very effective-- it'll be routed around in some way, and the routing around may have much worse outcomes.
3282019-04-04T06:37:52  *** jarthur has quit IRC
3292019-04-04T06:40:17  <gmaxwell> (of course the degree depends on how serious the 'need' is...)
3302019-04-04T06:41:00  <gmaxwell> (and how easy the bypasses are, unfortuantely "trust someone else" is almost always a very easy bypass that a very large number of economically important users are happy to make)
3312019-04-04T06:50:36  *** mn9495885 has quit IRC
3322019-04-04T06:50:37  *** mn94958863 has quit IRC
3332019-04-04T06:50:37  *** mn949588 has quit IRC
3342019-04-04T06:50:53  *** mn9495881 has quit IRC
3352019-04-04T07:07:10  <gwillen> sipa: can I summon you to #15743
3362019-04-04T07:07:12  <gribble> https://github.com/bitcoin/bitcoin/issues/15743 | getaddressinfo missing key origin information for multisig · Issue #15743 · bitcoin/bitcoin · GitHub
3372019-04-04T07:28:47  *** gwillen has quit IRC
3382019-04-04T07:29:18  *** gwillen has joined #bitcoin-core-dev
3392019-04-04T07:30:59  *** Emcy has quit IRC
3402019-04-04T07:40:16  *** rex4539 has quit IRC
3412019-04-04T07:42:47  *** bitcoin-git has joined #bitcoin-core-dev
3422019-04-04T07:42:48  <bitcoin-git> [bitcoin] Empact opened pull request #15744: Extract ParseDescriptorRange (master...parse-descriptor-range) https://github.com/bitcoin/bitcoin/pull/15744
3432019-04-04T07:42:51  *** bitcoin-git has left #bitcoin-core-dev
3442019-04-04T07:46:36  *** gribble has quit IRC
3452019-04-04T07:49:56  *** mol has joined #bitcoin-core-dev
3462019-04-04T07:49:57  *** ccdle12 has joined #bitcoin-core-dev
3472019-04-04T07:51:19  *** molz has quit IRC
3482019-04-04T07:53:01  *** rh0nj has quit IRC
3492019-04-04T07:54:06  *** Skirmant has quit IRC
3502019-04-04T07:54:07  *** rh0nj has joined #bitcoin-core-dev
3512019-04-04T07:54:25  *** Skirmant has joined #bitcoin-core-dev
3522019-04-04T07:55:48  *** gribble has joined #bitcoin-core-dev
3532019-04-04T07:59:48  *** elichai2 has joined #bitcoin-core-dev
3542019-04-04T08:04:53  *** drexl has joined #bitcoin-core-dev
3552019-04-04T08:23:05  *** fanquake has quit IRC
3562019-04-04T08:33:57  *** jarthur has joined #bitcoin-core-dev
3572019-04-04T08:38:12  *** drexl has quit IRC
3582019-04-04T08:38:38  *** jarthur has quit IRC
3592019-04-04T08:46:57  *** mn94958864 has joined #bitcoin-core-dev
3602019-04-04T08:46:58  *** mn9495882 has joined #bitcoin-core-dev
3612019-04-04T08:46:58  *** mn94958859 has joined #bitcoin-core-dev
3622019-04-04T08:46:58  *** mn949588 has joined #bitcoin-core-dev
3632019-04-04T08:49:02  *** timothy has joined #bitcoin-core-dev
3642019-04-04T08:51:56  *** mn94958864 has quit IRC
3652019-04-04T08:51:57  *** mn9495882 has quit IRC
3662019-04-04T08:51:57  *** mn94958859 has quit IRC
3672019-04-04T08:51:57  *** mn949588 has quit IRC
3682019-04-04T08:52:44  *** spinza has quit IRC
3692019-04-04T09:04:30  *** kexkey has quit IRC
3702019-04-04T09:07:54  *** hebasto has quit IRC
3712019-04-04T09:09:28  *** spinza has joined #bitcoin-core-dev
3722019-04-04T09:23:39  *** fanquake has joined #bitcoin-core-dev
3732019-04-04T09:23:48  *** ccdle12 has quit IRC
3742019-04-04T09:25:50  *** Emcy has joined #bitcoin-core-dev
3752019-04-04T09:27:00  *** ccdle12 has joined #bitcoin-core-dev
3762019-04-04T09:31:03  *** ccdle12 has quit IRC
3772019-04-04T09:34:03  *** dviola has joined #bitcoin-core-dev
3782019-04-04T09:43:52  *** ccdle12 has joined #bitcoin-core-dev
3792019-04-04T09:43:57  *** Emcy has quit IRC
3802019-04-04T10:03:40  *** spinza has quit IRC
3812019-04-04T10:13:24  *** pinheadmz has quit IRC
3822019-04-04T10:16:15  *** spinza has joined #bitcoin-core-dev
3832019-04-04T10:17:10  *** pinheadmz has joined #bitcoin-core-dev
3842019-04-04T10:17:20  *** rex4539 has joined #bitcoin-core-dev
3852019-04-04T10:34:16  *** Emcy has joined #bitcoin-core-dev
3862019-04-04T10:34:18  *** jonatack has joined #bitcoin-core-dev
3872019-04-04T10:34:49  *** jarthur has joined #bitcoin-core-dev
3882019-04-04T10:35:17  *** drexl has joined #bitcoin-core-dev
3892019-04-04T10:36:01  *** AaronvanW has joined #bitcoin-core-dev
3902019-04-04T10:39:21  *** ccdle12 has quit IRC
3912019-04-04T10:39:27  *** jarthur has quit IRC
3922019-04-04T10:43:30  *** ccdle12 has joined #bitcoin-core-dev
3932019-04-04T10:48:04  *** mn949588 has joined #bitcoin-core-dev
3942019-04-04T10:48:06  *** mn9495886 has joined #bitcoin-core-dev
3952019-04-04T10:48:10  *** mn94958860 has joined #bitcoin-core-dev
3962019-04-04T10:48:10  *** mn94958865 has joined #bitcoin-core-dev
3972019-04-04T10:51:00  *** mn94958865 has quit IRC
3982019-04-04T10:51:00  *** mn9495886 has quit IRC
3992019-04-04T10:51:01  *** mn94958860 has quit IRC
4002019-04-04T10:51:15  *** mn94958861 has joined #bitcoin-core-dev
4012019-04-04T10:51:15  *** mn9495887 has joined #bitcoin-core-dev
4022019-04-04T10:51:15  *** mn94958866 has joined #bitcoin-core-dev
4032019-04-04T10:51:15  *** mn9495883 has joined #bitcoin-core-dev
4042019-04-04T10:51:37  *** mn949588 has quit IRC
4052019-04-04T10:52:24  *** ccdle12 has quit IRC
4062019-04-04T10:56:04  *** mn94958861 has quit IRC
4072019-04-04T10:56:04  *** mn9495887 has quit IRC
4082019-04-04T10:56:04  *** mn94958866 has quit IRC
4092019-04-04T10:56:04  *** mn9495883 has quit IRC
4102019-04-04T10:57:19  *** ccdle12 has joined #bitcoin-core-dev
4112019-04-04T10:57:39  *** ccdle12 has joined #bitcoin-core-dev
4122019-04-04T11:03:22  *** ccdle12 has quit IRC
4132019-04-04T11:08:49  *** drexl has quit IRC
4142019-04-04T11:24:53  *** ccdle12 has joined #bitcoin-core-dev
4152019-04-04T11:46:29  *** drexl has joined #bitcoin-core-dev
4162019-04-04T11:47:22  *** atroxes has quit IRC
4172019-04-04T11:47:52  *** atroxes has joined #bitcoin-core-dev
4182019-04-04T11:55:26  *** profmac has quit IRC
4192019-04-04T12:02:29  *** drexl_ has joined #bitcoin-core-dev
4202019-04-04T12:03:30  *** drexl has quit IRC
4212019-04-04T12:03:45  *** drexl has joined #bitcoin-core-dev
4222019-04-04T12:04:23  *** drexl_ has quit IRC
4232019-04-04T12:04:54  *** drexl has joined #bitcoin-core-dev
4242019-04-04T12:08:27  *** profmac has joined #bitcoin-core-dev
4252019-04-04T12:18:57  *** Skirmant has quit IRC
4262019-04-04T12:19:50  *** Skirmant has joined #bitcoin-core-dev
4272019-04-04T12:22:38  *** hebasto has joined #bitcoin-core-dev
4282019-04-04T12:26:33  *** ccdle12 has quit IRC
4292019-04-04T12:31:02  *** ccdle12 has joined #bitcoin-core-dev
4302019-04-04T12:32:16  *** ccdle12 has quit IRC
4312019-04-04T12:33:57  *** ccdle12 has joined #bitcoin-core-dev
4322019-04-04T12:35:16  *** ryanofsky has quit IRC
4332019-04-04T12:35:32  *** ryanofsky has joined #bitcoin-core-dev
4342019-04-04T12:35:41  *** jarthur has joined #bitcoin-core-dev
4352019-04-04T12:40:07  *** jarthur has quit IRC
4362019-04-04T12:46:28  *** ccdle12 has quit IRC
4372019-04-04T12:52:23  *** mn949588 has joined #bitcoin-core-dev
4382019-04-04T12:52:24  *** mn94958862 has joined #bitcoin-core-dev
4392019-04-04T12:52:24  *** mn94958867 has joined #bitcoin-core-dev
4402019-04-04T12:52:24  *** mn9495884 has joined #bitcoin-core-dev
4412019-04-04T12:57:31  *** harrymm has joined #bitcoin-core-dev
4422019-04-04T12:57:43  *** mn94958862 has quit IRC
4432019-04-04T12:57:43  *** mn94958867 has quit IRC
4442019-04-04T12:57:43  *** mn9495884 has quit IRC
4452019-04-04T12:57:43  *** mn949588 has quit IRC
4462019-04-04T13:52:36  *** mn949588 has joined #bitcoin-core-dev
4472019-04-04T13:52:37  *** mn94958863 has joined #bitcoin-core-dev
4482019-04-04T13:52:40  *** mn9495888 has joined #bitcoin-core-dev
4492019-04-04T13:52:41  *** mn9495885 has joined #bitcoin-core-dev
4502019-04-04T13:53:32  *** jnewbery has quit IRC
4512019-04-04T13:54:05  *** dqx_ has joined #bitcoin-core-dev
4522019-04-04T13:54:17  *** jnewbery has joined #bitcoin-core-dev
4532019-04-04T13:55:40  *** aqquadro has joined #bitcoin-core-dev
4542019-04-04T13:55:40  *** aqquadro has quit IRC
4552019-04-04T13:55:40  *** aqquadro has joined #bitcoin-core-dev
4562019-04-04T13:56:21  *** spaced0ut has joined #bitcoin-core-dev
4572019-04-04T13:57:26  *** mn94958863 has quit IRC
4582019-04-04T13:57:31  *** mn9495885 has quit IRC
4592019-04-04T13:57:32  *** mn949588 has quit IRC
4602019-04-04T13:57:34  *** mn9495888 has quit IRC
4612019-04-04T13:57:59  *** dqx_ has quit IRC
4622019-04-04T13:58:03  *** tralfaz has joined #bitcoin-core-dev
4632019-04-04T14:10:50  *** nc has joined #bitcoin-core-dev
4642019-04-04T14:15:10  *** jnewbery has quit IRC
4652019-04-04T14:26:15  *** jnewbery has joined #bitcoin-core-dev
4662019-04-04T14:30:56  *** mn949588 has joined #bitcoin-core-dev
4672019-04-04T14:30:59  *** mn94958864 has joined #bitcoin-core-dev
4682019-04-04T14:30:59  *** mn94958868 has joined #bitcoin-core-dev
4692019-04-04T14:30:59  *** mn9495889 has joined #bitcoin-core-dev
4702019-04-04T14:33:35  *** dqx_ has joined #bitcoin-core-dev
4712019-04-04T14:35:52  *** mn949588 has quit IRC
4722019-04-04T14:35:53  *** mn9495889 has quit IRC
4732019-04-04T14:36:09  *** mn94958864 has quit IRC
4742019-04-04T14:36:10  *** mn94958868 has quit IRC
4752019-04-04T14:36:33  *** jarthur has joined #bitcoin-core-dev
4762019-04-04T14:37:57  *** dqx_ has quit IRC
4772019-04-04T14:38:50  *** nc has quit IRC
4782019-04-04T14:41:20  *** jarthur has quit IRC
4792019-04-04T14:53:38  *** bitcoin-git has joined #bitcoin-core-dev
4802019-04-04T14:53:39  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15746: rpc: RPCHelpMan: Always name dictionary keys (master...1904-rpcUtilFix) https://github.com/bitcoin/bitcoin/pull/15746
4812019-04-04T14:53:39  *** bitcoin-git has left #bitcoin-core-dev
4822019-04-04T14:58:13  *** DeanGuss has quit IRC
4832019-04-04T15:12:32  *** AaronvanW has quit IRC
4842019-04-04T15:16:30  *** jonatack has quit IRC
4852019-04-04T15:31:25  *** dviola has quit IRC
4862019-04-04T15:35:06  *** Guyver2 has joined #bitcoin-core-dev
4872019-04-04T15:45:11  *** d_t has joined #bitcoin-core-dev
4882019-04-04T15:52:38  *** dqx_ has joined #bitcoin-core-dev
4892019-04-04T15:56:15  *** jarthur has joined #bitcoin-core-dev
4902019-04-04T15:56:23  *** araspitzu has joined #bitcoin-core-dev
4912019-04-04T15:57:56  <araspitzu> Hi, does anybody have more info on the error "Transaction too large for fee policy"? Seems to happen at https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L2986
4922019-04-04T15:58:11  <araspitzu> It's my understanding that the fees attached to this tx wouldn't be enough to cover the "minRelayFee" and thus the transaction isn't even worth to be made
4932019-04-04T16:12:03  *** d_t has quit IRC
4942019-04-04T16:19:49  *** bushstar has joined #bitcoin-core-dev
4952019-04-04T16:27:07  *** araspitzu has quit IRC
4962019-04-04T16:32:01  *** mn9495886 has joined #bitcoin-core-dev
4972019-04-04T16:32:01  *** mn94958865 has joined #bitcoin-core-dev
4982019-04-04T16:32:01  *** mn94958869 has joined #bitcoin-core-dev
4992019-04-04T16:32:01  *** mn949588 has joined #bitcoin-core-dev
5002019-04-04T16:36:39  *** mn9495886 has quit IRC
5012019-04-04T16:36:39  *** mn94958865 has quit IRC
5022019-04-04T16:37:00  *** mn94958869 has quit IRC
5032019-04-04T16:37:00  *** mn949588 has quit IRC
5042019-04-04T16:53:11  *** _Sam-- has joined #bitcoin-core-dev
5052019-04-04T16:57:32  *** mn94958810 has joined #bitcoin-core-dev
5062019-04-04T16:57:32  *** 92AABU4IQ has joined #bitcoin-core-dev
5072019-04-04T16:57:33  *** 07EABABR2 has joined #bitcoin-core-dev
5082019-04-04T16:57:34  *** mn949588 has joined #bitcoin-core-dev
5092019-04-04T17:01:23  *** obsrver has joined #bitcoin-core-dev
5102019-04-04T17:06:52  *** aqquadro has quit IRC
5112019-04-04T17:19:46  *** bitcoin-git has joined #bitcoin-core-dev
5122019-04-04T17:19:47  <bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/ba54342c9dd3...daef20fb50c0
5132019-04-04T17:19:48  <bitcoin-git> bitcoin/master fae5f87 MarcoFalke: rpc: Document that minconf is an ignored dummy value
5142019-04-04T17:19:48  <bitcoin-git> bitcoin/master faa3a24 MarcoFalke: scripted-diff: wallet: Rename pcoin to wtx
5152019-04-04T17:19:50  <bitcoin-git> bitcoin/master fac1a0f MarcoFalke: wallet: Remove unused GetLegacyBalance
5162019-04-04T17:19:51  *** bitcoin-git has left #bitcoin-core-dev
5172019-04-04T17:20:25  *** bitcoin-git has joined #bitcoin-core-dev
5182019-04-04T17:20:26  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15596: rpc: Ignore sendmany::minconf as dummy value (master...1903-rpcWalletDummySendmany_2) https://github.com/bitcoin/bitcoin/pull/15596
5192019-04-04T17:20:26  *** bitcoin-git has left #bitcoin-core-dev
5202019-04-04T17:25:13  *** 07EABABR2 has quit IRC
5212019-04-04T17:25:13  *** mn94958810 has quit IRC
5222019-04-04T17:25:13  *** 92AABU4IQ has quit IRC
5232019-04-04T17:25:13  *** mn949588 has quit IRC
5242019-04-04T17:27:05  *** dqx__ has joined #bitcoin-core-dev
5252019-04-04T17:27:44  *** bitcoin-git has joined #bitcoin-core-dev
5262019-04-04T17:27:44  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15747: wallet: Remove plethora of Get*Balance (master...1903-walletBal) https://github.com/bitcoin/bitcoin/pull/15747
5272019-04-04T17:27:45  *** bitcoin-git has left #bitcoin-core-dev
5282019-04-04T17:30:02  *** dqx_ has quit IRC
5292019-04-04T18:07:14  *** Krellan has joined #bitcoin-core-dev
5302019-04-04T18:07:22  *** Krellan_ has quit IRC
5312019-04-04T18:11:30  *** davec has quit IRC
5322019-04-04T18:21:39  *** davec has joined #bitcoin-core-dev
5332019-04-04T18:23:18  <wumpus> rc3 binaries up https://bitcoincore.org/bin/bitcoin-core-0.18.0/test.rc3/
5342019-04-04T18:30:48  *** bitcoin-git has joined #bitcoin-core-dev
5352019-04-04T18:30:48  <bitcoin-git> [bitcoin] jamesob closed pull request #15735: Add scheduler deadlock detection (master...2019-04-serialize-scheduler) https://github.com/bitcoin/bitcoin/pull/15735
5362019-04-04T18:30:49  *** bitcoin-git has left #bitcoin-core-dev
5372019-04-04T18:36:40  *** d_t has joined #bitcoin-core-dev
5382019-04-04T18:39:58  *** sipa has quit IRC
5392019-04-04T18:41:21  *** sipa has joined #bitcoin-core-dev
5402019-04-04T18:42:27  *** Krellan has quit IRC
5412019-04-04T18:43:31  <sipa> gwillen: back to your problem yesterday... you say gai on the derived addresses says ismine:false (which is expected for a watchonly address), but what does it say about watchonly and solvable?
5422019-04-04T18:44:28  <gwillen> sipa: solvable true, watchonly true
5432019-04-04T18:44:33  <gwillen> the only problem I see is the lack of key origin info
5442019-04-04T18:44:37  <sipa> ok!
5452019-04-04T18:44:41  <sipa> that's easy to fix
5462019-04-04T18:44:52  *** sipa_ has joined #bitcoin-core-dev
5472019-04-04T18:44:52  <gwillen> and the spurious warning
5482019-04-04T18:44:55  <sipa> the import logic only looks at origin info for pubkeys that are being imported as well
5492019-04-04T18:45:03  <gwillen> makes sense
5502019-04-04T18:45:10  <gwillen> but the wallet is capable of holding origin info for pubkeys it doesn't have?
5512019-04-04T18:45:13  <sipa> it should import all known origin info, even for pubkeys that aren't being imported
5522019-04-04T18:45:16  <sipa> hmm
5532019-04-04T18:45:40  <sipa> i'm mostly confused why deriveaddresses doesn't maintain the origin info
5542019-04-04T18:45:49  <sipa> there is no wallet involved there
5552019-04-04T18:47:14  <sipa> yeah i think we can import origin info for other keys
5562019-04-04T18:48:26  <gwillen> sipa: yeah ProcessImport is just throwing it away if it doesn't have the key
5572019-04-04T18:48:36  <gwillen> it calls pwallet->AddKeyOrigin for keys it has
5582019-04-04T18:48:46  <gwillen> and throws away the rest
5592019-04-04T18:52:27  <gwillen> but AddKeyOrigin wants a pubkey, which we don't have...
5602019-04-04T18:53:28  <sipa_> it doesn't actually use a pubkey
5612019-04-04T18:53:35  <sipa> only a pubkeyhash
5622019-04-04T18:54:17  <sipa_> hi sipa_
5632019-04-04T18:54:29  <sipa> why am i here twice in the same client?
5642019-04-04T18:54:33  *** sipa_ has left #bitcoin-core-dev
5652019-04-04T18:56:00  <MarcoFalke> sipa: Have you tried turning it off an on again?
5662019-04-04T18:56:29  <sipa> actually, just off
5672019-04-04T18:56:36  <sipa> feels much better
5682019-04-04T18:56:52  <sipa> gwillen: oh i see now
5692019-04-04T18:56:54  <MarcoFalke> \o/ on rc3, hopefully the last
5702019-04-04T18:57:08  <sipa> you're reporting the gai output, and notice there that the origin info is missing
5712019-04-04T18:57:21  <sipa> yeah, i think we should try importing just all origin info, even for non-importable pubkeys
5722019-04-04T18:57:29  <sipa> but it's probably not enough to delay 0.18 for
5732019-04-04T18:57:47  <sipa> (trying to avoid killing MarcoFalke's mood)
5742019-04-04T18:58:19  *** jonatack has joined #bitcoin-core-dev
5752019-04-04T19:00:35  <dongcarl> meeting?
5762019-04-04T19:00:43  <achow101> meeting
5772019-04-04T19:00:50  <sipa> meeting
5782019-04-04T19:01:04  <jonasschnelli> yes
5792019-04-04T19:01:06  <jonasschnelli> meeting
5802019-04-04T19:01:17  <wumpus> #startmeeting
5812019-04-04T19:01:17  <lightningbot> Meeting started Thu Apr  4 19:01:17 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
5822019-04-04T19:01:17  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5832019-04-04T19:01:24  <jnewbery> hi
5842019-04-04T19:02: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
5852019-04-04T19:02:08  <wumpus> proposed topics?
5862019-04-04T19:02:17  <MarcoFalke> TODOs in the release notes
5872019-04-04T19:02:32  <MarcoFalke> They seem generally ready, but we'd need to finalize them for -final
5882019-04-04T19:02:54  <wumpus> ok
5892019-04-04T19:02:59  <MarcoFalke> They are "TODO sipa", not sure if that means sipa should do something or they were added by sipa
5902019-04-04T19:03:01  <wumpus> #topic high priority for review
5912019-04-04T19:03:11  <wumpus> https://github.com/bitcoin/bitcoin/projects/8
5922019-04-04T19:03:51  <wumpus> #15006 #15557 #14121 #15141 #15512
5932019-04-04T19:03:56  <gribble> https://github.com/bitcoin/bitcoin/issues/15006 | Add option to create an encrypted wallet by achow101 · Pull Request #15006 · bitcoin/bitcoin · GitHub
5942019-04-04T19:03:58  <gribble> https://github.com/bitcoin/bitcoin/issues/15557 | Enhance `bumpfee` to include inputs when targeting a feerate by instagibbs · Pull Request #15557 · bitcoin/bitcoin · GitHub
5952019-04-04T19:04:01  <sipa> MarcoFalke: it means i'll try to write them if nobody beats me :)
5962019-04-04T19:04:10  <gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
5972019-04-04T19:04:11  <gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub
5982019-04-04T19:04:11  <gribble> https://github.com/bitcoin/bitcoin/issues/14121 | Index for BIP 157 block filters by jimpo · Pull Request #14121 · bitcoin/bitcoin · GitHub
5992019-04-04T19:04:53  <wumpus> dunno if someone has something to add or remove?
6002019-04-04T19:05:16  <meshcollider> hi
6012019-04-04T19:05:42  <wumpus> helloo
6022019-04-04T19:05:51  * sipa waves at wumpus 
6032019-04-04T19:06:25  <sipa> i don't have anything right now for high priority
6042019-04-04T19:06:36  <meshcollider> I'm still at ICPC so apologies for lack of activity
6052019-04-04T19:06:51  <achow101> are any of gwillen's issue's blockers for rc3?
6062019-04-04T19:06:58  <achow101> s/rc3/final/
6072019-04-04T19:07:14  <wumpus> I don't think there's any blocking issues for rc3
6082019-04-04T19:07:19  <wumpus> eh, for 0.18.0
6092019-04-04T19:07:42  <sipa> i'm making a PR to fix #15743 right now, but i think it's a minor thing
6102019-04-04T19:07:43  <gribble> https://github.com/bitcoin/bitcoin/issues/15743 | getaddressinfo missing key origin information for multisig · Issue #15743 · bitcoin/bitcoin · GitHub
6112019-04-04T19:08:29  <wumpus> #topic blockers for 0.18.0
6122019-04-04T19:09:22  <sipa> gwillen: opinions?
6132019-04-04T19:10:22  <wumpus> so are any of these regressions for 0.18?
6142019-04-04T19:10:50  <achow101> I don't think so. they're all new stuff added with descriptors
6152019-04-04T19:10:52  <gwillen> I don't have opinions about 0.18
6162019-04-04T19:11:13  <gwillen> none of them are correctness issues
6172019-04-04T19:11:15  <wumpus> achow101: ok, thanks
6182019-04-04T19:12:03  <wumpus> doesn't seem that needs to block the release
6192019-04-04T19:12:20  <wumpus> #topic release notes TODOs 0.18.0
6202019-04-04T19:12:33  <gwillen> well, "manual coin control broken with multiple wallets" is not merely superficial, but I don't think you can successfully do anything broken with it, as far as I can tell
6212019-04-04T19:12:44  <sipa> i'd welcome help to fill in my TODOs :)
6222019-04-04T19:13:28  <MarcoFalke> working on it rn
6232019-04-04T19:13:29  <wumpus> gwillen: right-I just think the criterion at this point is "worked in 0.17 and broken in 0.18"
6242019-04-04T19:13:51  <gwillen> :+1:
6252019-04-04T19:14:11  <wumpus> unless it's really dangerous ofc, but in that case we could also opt for disabling the feature that introduces it
6262019-04-04T19:14:19  <gwillen> it is not totally out of the question that a clever user could accidentally send coins from the wrong wallet with it
6272019-04-04T19:14:27  <gwillen> but when I tried to do so, I got an error
6282019-04-04T19:14:36  <wumpus> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft
6292019-04-04T19:15:04  <gwillen> and it only triggers if you are performing coin control on multiple wallets at once, which would be a weird thing to be doing
6302019-04-04T19:15:21  <wumpus> gwillen: we could add a known issue
6312019-04-04T19:15:43  <gwillen> that would make sense, although who reads those
6322019-04-04T19:15:57  <gwillen> but I think it is definitely a known thing that one should avoid triggering
6332019-04-04T19:16:02  <wumpus> sigh, who ever reads anything right ...
6342019-04-04T19:16:11  <wumpus> if you start asking that why spend time writing release notes at all !
6352019-04-04T19:16:19  *** obsrver has quit IRC
6362019-04-04T19:17:00  <wumpus> anyhow the TODO s are;
6372019-04-04T19:17:13  <wumpus> (TODO pieter: it feels like this section can be merged with the earlier RPC changes section) (under low-level changes)
6382019-04-04T19:17:31  <wumpus> Descriptors with key origin information imported through importmulti will have their key origin information stored in the wallet for use with creating PSBTs. (TODO pieter: this should probably be merged with the text on importmulti gaining descriptor support)
6392019-04-04T19:17:53  <wumpus> (TODO pieter: mention getdata randomization from #14897 and perhaps orphan tx handling from #14626) under "network"
6402019-04-04T19:17:58  <gribble> https://github.com/bitcoin/bitcoin/issues/14897 | randomize GETDATA(tx) request order and introduce bias toward outbound by naumenkogs · Pull Request #14897 · bitcoin/bitcoin · GitHub
6412019-04-04T19:18:01  <gribble> https://github.com/bitcoin/bitcoin/issues/14626 | Select orphan transaction uniformly for eviction by sipa · Pull Request #14626 · bitcoin/bitcoin · GitHub
6422019-04-04T19:18:10  <wumpus> (TODO pieter: mention HWI project?)  under "wallet"
6432019-04-04T19:18:26  <wumpus> (TODO pieter: mention that the rdseed instruction is used where available) under "security"
6442019-04-04T19:18:34  <wumpus> I think the latter is very low-level for release notes
6452019-04-04T19:18:42  <sipa> yeah
6462019-04-04T19:19:24  <wumpus> we also need to be careful to include things that are useful to users to know
6472019-04-04T19:19:45  <wumpus> too much and people will indeed just skip over things
6482019-04-04T19:20:20  <wumpus> (TODO pieter: mention new descriptor RPCs deriveaddresses/getdescriptorinfo, and descriptor support in importmulti) under "Documentation"
6492019-04-04T19:21:17  <wumpus> anyhow help is welcome here
6502019-04-04T19:21:56  <sipa> assuming no further problems in rc3, when final?
6512019-04-04T19:21:59  <wumpus> TODO: remove any leftover TODOs before sending the final release notes :)
6522019-04-04T19:22:53  <wumpus> more or less one week per rc, so I think next week thursday
6532019-04-04T19:23:36  <MarcoFalke> agree on that timeline
6542019-04-04T19:24:02  <sipa> yeha
6552019-04-04T19:24:07  <sipa> *yeah
6562019-04-04T19:24:59  <gwillen> wumpus: I added some suggested known-issue text to #15725
6572019-04-04T19:25:01  <gribble> https://github.com/bitcoin/bitcoin/issues/15725 | Manual coin control dialog interacts badly with multiple wallets · Issue #15725 · bitcoin/bitcoin · GitHub
6582019-04-04T19:25:32  <sipa> when do we switch release notes back from wallet to repo?
6592019-04-04T19:25:56  <MarcoFalke> next tuesday?
6602019-04-04T19:26:10  <wumpus> sipa: usually just before labeling final
6612019-04-04T19:26:21  <sipa> okay
6622019-04-04T19:26:43  <MarcoFalke> Shouldn't there be one day so that everyone can look over what is going to be tagged as final?
6632019-04-04T19:26:52  <wumpus> MarcoFalke: also fine with me, if we know we're going to do final next
6642019-04-04T19:27:14  <wumpus> just, if you want to do release note editing, please do it on the wiki
6652019-04-04T19:28:42  <wumpus> any other topics?
6662019-04-04T19:30:32  <kanzure> no warren update today
6672019-04-04T19:30:43  <wumpus> thanks for letting us know kanzure
6682019-04-04T19:32:16  <wumpus> I guess that's all for today
6692019-04-04T19:32:24  <wumpus> #endmeeting
6702019-04-04T19:32:24  <lightningbot> Meeting ended Thu Apr  4 19:32:24 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6712019-04-04T19:32:24  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-04-19.01.html
6722019-04-04T19:32:24  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-04-19.01.txt
6732019-04-04T19:32:24  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-04-19.01.log.html
6742019-04-04T19:33:23  <wumpus> gwillen: thanks
6752019-04-04T19:33:48  *** hebasto has quit IRC
6762019-04-04T19:33:53  <gwillen> wumpus: I can edit it into the notes on the wiki, but where actually is that? :-)
6772019-04-04T19:34:12  *** zivl has quit IRC
6782019-04-04T19:34:56  <sipa> https://github.com/bitcoin-core/bitcoin-devwiki/wiki
6792019-04-04T19:35:06  <wumpus> gwillen: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft#known-issues
6802019-04-04T19:35:20  <wumpus> I've already added it, feel free to edit it further
6812019-04-04T19:35:28  <gwillen> thanks
6822019-04-04T19:37:03  <gwillen> I tried to think of a narrower recommendation, but I think probably very few people are using these features together anyway
6832019-04-04T19:37:17  <gwillen> and I'm afraid of wrongly implying that some usage pattern is safe, given that I don't really know the implications of the issue
6842019-04-04T19:38:19  <wumpus> yes, it's good like this
6852019-04-04T19:38:24  <gwillen> :+1:
6862019-04-04T19:38:25  *** qubenix has quit IRC
6872019-04-04T19:38:51  *** qubenix has joined #bitcoin-core-dev
6882019-04-04T19:41:10  <sipa> gwillen, achow101: it seems deriveaddresses has somewhat exponentially-looking performance for increasing number of keys
6892019-04-04T19:41:14  <sipa> this is weird
6902019-04-04T19:42:21  <achow101> i would expect it to be linear
6912019-04-04T19:42:54  <sipa> it should be
6922019-04-04T19:45:26  <achow101> maybe it's because you use the same provider as the input and output of Expand? More and more stuff gets put into it, so it becomes large and slower to search?
6932019-04-04T19:45:52  <achow101> I don't think there is a need to use the same provider since it isn't using any of the resulting solving data
6942019-04-04T19:47:24  <sipa> agree
6952019-04-04T19:47:28  <sipa> that could be the reason
6962019-04-04T19:47:39  <sipa> should be more n*log(n)'ish though
6972019-04-04T19:47:43  <sipa> maybe it is
6982019-04-04T19:48:26  *** bitcoin-git has joined #bitcoin-core-dev
6992019-04-04T19:48:27  <bitcoin-git> [bitcoin] jnewbery opened pull request #15748: [rpc] remove dead mining code (master...2019_04_simplify_generate) https://github.com/bitcoin/bitcoin/pull/15748
7002019-04-04T19:48:28  *** bitcoin-git has left #bitcoin-core-dev
7012019-04-04T19:51:02  *** Icreatedbitcoin2 has joined #bitcoin-core-dev
7022019-04-04T19:56:21  *** Icreatedbitcoin2 has quit IRC
7032019-04-04T19:56:40  *** sodiafosidf has joined #bitcoin-core-dev
7042019-04-04T19:57:50  *** bitcoin-git has joined #bitcoin-core-dev
7052019-04-04T19:57:50  <bitcoin-git> [bitcoin] sipa opened pull request #15749: Fix: importmulti only imports origin info for PKH outputs (master...201904_importallorigins) https://github.com/bitcoin/bitcoin/pull/15749
7062019-04-04T19:57:57  *** bitcoin-git has left #bitcoin-core-dev
7072019-04-04T19:58:19  <sipa> gwillen: ^
7082019-04-04T20:04:13  *** sipa has quit IRC
7092019-04-04T20:08:45  *** sipa has joined #bitcoin-core-dev
7102019-04-04T20:08:57  *** bitcoin-git has joined #bitcoin-core-dev
7112019-04-04T20:08:58  <bitcoin-git> [bitcoin] jnewbery opened pull request #15750: [rpc] Remove the addresses field from the getaddressinfo return object (master...2019_04_remove_address_from_getaddressinfo) https://github.com/bitcoin/bitcoin/pull/15750
7122019-04-04T20:08:59  *** bitcoin-git has left #bitcoin-core-dev
7132019-04-04T20:09:59  *** sipa_ has joined #bitcoin-core-dev
7142019-04-04T20:10:32  *** sipa_ has quit IRC
7152019-04-04T20:15:14  *** bitcoin-git has joined #bitcoin-core-dev
7162019-04-04T20:15:14  <bitcoin-git> [bitcoin] sipa opened pull request #15751: Speed up deriveaddresses for large ranges (master...201904_fasterderiveaddresses) https://github.com/bitcoin/bitcoin/pull/15751
7172019-04-04T20:15:16  *** bitcoin-git has left #bitcoin-core-dev
7182019-04-04T20:15:54  *** kmls has quit IRC
7192019-04-04T20:19:20  *** spinza has quit IRC
7202019-04-04T20:28:45  *** elichai2 has quit IRC
7212019-04-04T20:31:19  *** Krellan has joined #bitcoin-core-dev
7222019-04-04T20:34:13  *** Krellan has quit IRC
7232019-04-04T20:47:24  *** d_t has quit IRC
7242019-04-04T20:48:05  *** bitcoin-git has joined #bitcoin-core-dev
7252019-04-04T20:48:05  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/daef20fb50c0...c83442e17412
7262019-04-04T20:48:05  <bitcoin-git> bitcoin/master fa8548c MarcoFalke: net: Remove unused unsanitized user agent string CNode::strSubVer
7272019-04-04T20:48:06  <bitcoin-git> bitcoin/master c83442e MarcoFalke: Merge #15654: net: Remove unused unsanitized user agent string CNode::strS...
7282019-04-04T20:48:07  *** bitcoin-git has left #bitcoin-core-dev
7292019-04-04T20:48:49  *** bitcoin-git has joined #bitcoin-core-dev
7302019-04-04T20:48:49  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15654: net: Remove unused unsanitized user agent string CNode::strSubVer (master...1903-netUABytes) https://github.com/bitcoin/bitcoin/pull/15654
7312019-04-04T20:49:00  *** bitcoin-git has left #bitcoin-core-dev
7322019-04-04T20:51:13  *** Guyver2 has quit IRC
7332019-04-04T20:55:25  <gwillen> thanks sipa! Will take a look.
7342019-04-04T20:55:27  *** spinza has joined #bitcoin-core-dev
7352019-04-04T20:55:45  <gwillen> sipa: is derivaddress exponential or merely quadratic?
7362019-04-04T20:55:53  <gwillen> quadratic would not be super shocking
7372019-04-04T20:56:59  <sipa> gwillen: linearithmic if the cause is what i think it is
7382019-04-04T21:45:00  *** bushstar has quit IRC
7392019-04-04T21:54:53  *** drexl has quit IRC
7402019-04-04T22:25:00  *** spinza has quit IRC
7412019-04-04T22:31:03  *** spinza has joined #bitcoin-core-dev
7422019-04-04T22:46:47  *** AaronvanW has joined #bitcoin-core-dev
7432019-04-04T22:48:38  *** Aaronvan_ has joined #bitcoin-core-dev
7442019-04-04T22:51:18  *** AaronvanW has quit IRC
7452019-04-04T23:02:34  *** qubenix has quit IRC
7462019-04-04T23:04:46  *** qubenix has joined #bitcoin-core-dev
7472019-04-04T23:12:45  *** Zenton has quit IRC
7482019-04-04T23:13:58  *** Aaronvan_ is now known as AaronvanW
7492019-04-04T23:33:34  *** mn949588 has joined #bitcoin-core-dev
7502019-04-04T23:40:08  *** bitbee has quit IRC
7512019-04-04T23:40:53  *** bitbee has joined #bitcoin-core-dev
7522019-04-04T23:43:40  *** bitbee has quit IRC
7532019-04-04T23:45:28  *** jarthur has quit IRC
7542019-04-04T23:58:48  *** bitcoin-git has joined #bitcoin-core-dev
7552019-04-04T23:58:49  <bitcoin-git> [bitcoin] madeken opened pull request #15752: Remove redundant shuffle in KnapsackSolver (master...master) https://github.com/bitcoin/bitcoin/pull/15752
7562019-04-04T23:58:59  *** bitcoin-git has left #bitcoin-core-dev