1 2019-04-04T00:02:59  <sipa> achow101: aftee batching the writes, it should be almost entirely cpu bound
  2 2019-04-04T00:04:00  *** supay has joined #bitcoin-core-dev
  3 2019-04-04T00:04:05  <sipa> so you're now at 8ms of CPU per generated key?
  4 2019-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?
  5 2019-04-04T00:04:56  <sipa> oh, if we'd cache intermediary results in the key derivation we'd save a bunch
  6 2019-04-04T00:05:01  *** drexl has joined #bitcoin-core-dev
  7 2019-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
  8 2019-04-04T00:08:16  <gmaxwell> supay: what exactly does "isn't working" mean?
  9 2019-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
 10 2019-04-04T00:10:17  <sipa> supay: are you sure the private key you're importing corresponds to the address?
 11 2019-04-04T00:10:37  <gwillen> hey supay, I assume you are 0x23212f from github?
 12 2019-04-04T00:10:45  <sipa> could it be you're importing a root key instead of the derived key?
 13 2019-04-04T00:11:12  <sipa> or gotten the compression flag wrong? (depending on how you obtained the private key)
 14 2019-04-04T00:11:14  <supay> sipa: to which address? i gather importing the private key suffices, as it has the address?
 15 2019-04-04T00:11:21  <supay> gwillen: yes, that is correct! :)
 16 2019-04-04T00:11:33  <sipa> supay: well i don't know where you got the key
 17 2019-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?
 18 2019-04-04T00:11:47  <supay> gwillen: thank you for your reply there. i wasn't aware this channel exists.
 19 2019-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 :-)
 20 2019-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
 21 2019-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
 22 2019-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
 23 2019-04-04T00:13:46  <supay> that is correct, each line has a different key
 24 2019-04-04T00:13:51  <supay> wait, let me share some with 0 balance
 25 2019-04-04T00:13:53  <supay> is that safe?
 26 2019-04-04T00:14:09  <achow101> no, it is not safe
 27 2019-04-04T00:14:16  <gwillen> supay: if you "getaddressinfo" the address after importing the privkey, what does it say about ismine and solvable?
 28 2019-04-04T00:14:27  <gwillen> supay: sharing private keys is, to a first approximation, never ever safe
 29 2019-04-04T00:14:35  <supay> haha, makes sense
 30 2019-04-04T00:14:41  <supay> let me check getaddressinfo, one moment
 31 2019-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
 32 2019-04-04T00:15:09  <supay> gwillen: ismine for that address is current false
 33 2019-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.
 34 2019-04-04T00:15:18  <gwillen> and the fact that this is not obvious results in some serious arguments over usability
 35 2019-04-04T00:15:26  <gwillen> gmaxwell: he said in his github issue that the rescan completed
 36 2019-04-04T00:15:29  <supay> gmaxwell: i've been observing debug.log. i'm sure rescan is complete
 37 2019-04-04T00:16:04  <gmaxwell> supay: good!
 38 2019-04-04T00:16:43  <supay> gmaxwell: wait, is ismine: false a good thing? :o
 39 2019-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]
 40 2019-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 :-)
 41 2019-04-04T00:17:50  <supay> i'm so confused. i shouldn't have asked?
 42 2019-04-04T00:17:55  <gwillen> haha, no, not at all
 43 2019-04-04T00:17:58  <supay> :D
 44 2019-04-04T00:18:03  <gwillen> just that most people would go ahead and share without asking
 45 2019-04-04T00:18:08  <gwillen> which would be bad because it would compromise their wallet
 46 2019-04-04T00:18:08  <achow101> supay: ismine false means that address is not part of your wallet
 47 2019-04-04T00:18:22  <supay> gwillen: ah yes, but you cautioned me in the github reply!
 48 2019-04-04T00:18:25  <gwillen> and there is an ongoing argument over the fact that this happens
 49 2019-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.
 50 2019-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
 51 2019-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?
 52 2019-04-04T00:19:12  <supay> gmaxwell: ah hehe
 53 2019-04-04T00:19:28  <gwillen> supay: if you run dumpprivkey address, it will show you what it thinks the privkey is for the address
 54 2019-04-04T00:19:35  <gwillen> and you can compare it to the one you have in your own dump
 55 2019-04-04T00:19:36  <supay> achow101: right, i really hope it is not the latter
 56 2019-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?
 57 2019-04-04T00:19:57  <gwillen> if it's different, don't panic yet, there are lots of ways that the UX can be confusing
 58 2019-04-04T00:20:07  <gmaxwell> supay: what software wrote this list of addresses / paths/ keys?
 59 2019-04-04T00:20:25  <supay> gmaxwell: can't be very sure! :(
 60 2019-04-04T00:20:33  <achow101> supay: can you try `bitcoin-cli listaddressgroupings` and see if your address is in there?
 61 2019-04-04T00:20:44  <supay> i just searched for these patterns on a backup of my computer
 62 2019-04-04T00:20:49  <supay> achow101: sure, one moment
 63 2019-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
 64 2019-04-04T00:21:29  <gmaxwell> If so, I think that proves that he did not successfully import a matching private key.
 65 2019-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
 66 2019-04-04T00:21:54  *** fanquake has joined #bitcoin-core-dev
 67 2019-04-04T00:21:59  <achow101> supay: that's expected. importaddress imports the address to be watched.
 68 2019-04-04T00:22:07  <supay> gmaxwell: is that the only conclusion? :(
 69 2019-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.
 70 2019-04-04T00:22:11  <supay> achow101: ah, alright
 71 2019-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
 72 2019-04-04T00:22:27  <supay> gwillen: ah no, i ran it on the one where i imported the key
 73 2019-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
 74 2019-04-04T00:22:47  <supay> achow101: i do infact, this was a clean install. there were definitely some new addresses
 75 2019-04-04T00:22:58  <supay> gwillen: oh! that's a relief
 76 2019-04-04T00:23:06  <gwillen> honestly all this stuff is very arcane
 77 2019-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.
 78 2019-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.
 79 2019-04-04T00:24:14  <gmaxwell> either case is easily fixable if they're the issue.
 80 2019-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
 81 2019-04-04T00:24:35  <gmaxwell> supay: has any of the addresses which have balances that you're trying to import spent before?
 82 2019-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
 83 2019-04-04T00:25:44  <supay> gmaxwell: not sure, but pm'd you one such address
 84 2019-04-04T00:25:59  <gmaxwell> achow101: darn, I missed the fact that we'd already asked for the leading character.
 85 2019-04-04T00:26:37  <supay> achow101: yep, starts with a K. another with a K. and there's one with an L
 86 2019-04-04T00:26:38  <achow101> gmaxwell: not so much asked but provided in the issue :) #15736
 87 2019-04-04T00:26:39  <gribble> https://github.com/bitcoin/bitcoin/issues/15736 | Unable to importprivkey · Issue #15736 · bitcoin/bitcoin · GitHub
 88 2019-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?
 89 2019-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.
 90 2019-04-04T00:29:01  <supay> it had something indicating the columns. that's all i remember. unfortunately, got rid of the header!
 91 2019-04-04T00:29:23  <supay> that's how i know the last column was private key and second column was address
 92 2019-04-04T00:29:34  <gmaxwell> in the future when you're trying to recover data, take care to not throw anything out. :P
 93 2019-04-04T00:29:40  <supay> yess :(
 94 2019-04-04T00:30:07  <gmaxwell> do we really have no rpc that will take a private key and return addresses?
 95 2019-04-04T00:30:08  *** jarthur has joined #bitcoin-core-dev
 96 2019-04-04T00:30:43  <achow101> gmaxwell: nope
 97 2019-04-04T00:31:46  <supay> gmaxwell: interestingly, i think electrum does that
 98 2019-04-04T00:31:59  <supay> when you import a private key, it says "so and so addresses were added"
 99 2019-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.
100 2019-04-04T00:33:12  <supay> oh, i see, let me try that
101 2019-04-04T00:33:36  *** IGHOR has quit IRC
102 2019-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)
103 2019-04-04T00:35:28  *** jarthur has quit IRC
104 2019-04-04T00:36:26  <supay> oh, i didn't know you could do that! interesting :D
105 2019-04-04T00:36:50  <supay> gmaxwell: my dumpwallet output is huge. so many keys, addresses etc. no idea where all of these came from
106 2019-04-04T00:37:10  <achow101> supay: bitcoin core's default wallet will generate 2000 keys automatically
107 2019-04-04T00:37:11  *** IGHOR has joined #bitcoin-core-dev
108 2019-04-04T00:37:15  <gmaxwell> supay: by default the wallet starts off with 2000 keys generated in it.
109 2019-04-04T00:37:22  <achow101> that's expected. just open the file in a text editor and ctrl+f your private key
110 2019-04-04T00:37:29  <supay> oh, wow. i see
111 2019-04-04T00:38:43  <supay> alright, the addresses are definitely not what i expected. both have 0 balance
112 2019-04-04T00:39:08  *** gwillen has quit IRC
113 2019-04-04T00:39:28  *** gwillen has joined #bitcoin-core-dev
114 2019-04-04T00:39:56  <gmaxwell> are the addresses with them addresses that are in your list anywhere?
115 2019-04-04T00:40:06  <supay> nope, they aren't! :O
116 2019-04-04T00:40:17  *** gwillen__ has joined #bitcoin-core-dev
117 2019-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?
118 2019-04-04T00:40:49  <achow101> (rescan will pick up both address types, just that exporting addresses from core will use the default type)
119 2019-04-04T00:41:07  <supay> dumpwallet gave me 3 address corresponding with the private key. the addresses on the list begin with 1
120 2019-04-04T00:41:42  <achow101> restart bitcoind with with -addresstype=legacy and try the dumpwallet thing again
121 2019-04-04T00:42:11  <supay> alright, let me give that a go
122 2019-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?
123 2019-04-04T00:42:33  <supay> yes, that is correct!
124 2019-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)
125 2019-04-04T00:43:01  <achow101> gwillen: that's not in a release yet
126 2019-04-04T00:43:10  <gwillen> o :-(
127 2019-04-04T00:43:15  <gwillen> heh, nevermind
128 2019-04-04T00:43:24  <achow101> would require installing 0.18.0rc2
129 2019-04-04T00:45:02  <gmaxwell> huh? you can still set the keypool size to 1.
130 2019-04-04T00:45:26  <achow101> oh right. I assumed gwillen was talking about blank wallets
131 2019-04-04T00:46:43  *** omonk has quit IRC
132 2019-04-04T00:46:46  <supay> achow101: restarted bitcoind with that flag. however, same addresses in dumpwallet
133 2019-04-04T00:46:48  <gwillen> ohhh, I was, but that's clever
134 2019-04-04T00:47:06  <gwillen> you probably need to do the import again now that the flag is set
135 2019-04-04T00:47:14  <supay> ah, alright
136 2019-04-04T00:47:21  <gwillen> the addresses are remembered from before, unless you make a new wallet
137 2019-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"?
138 2019-04-04T00:48:17  <gwillen> since you have hopefully learned your lesson about single points of failure? :-)
139 2019-04-04T00:48:28  *** gwillen__ has quit IRC
140 2019-04-04T00:48:53  <supay> i don't have more copies ;((((
141 2019-04-04T00:49:05  <gwillen> well you should make them now
142 2019-04-04T00:49:17  <supay> hahaha, alright
143 2019-04-04T00:49:18  <gwillen> before you do any more fiddling with the list, like, very carefully copy it to a USB stick
144 2019-04-04T00:49:28  <gwillen> and do not even dream of getting rid of the old hard drive / backup / whatever you got it from
145 2019-04-04T00:49:34  <gwillen> never do any more backups to that drive or touch it in any way
146 2019-04-04T00:49:41  <gwillen> store it safely as an extra precaution
147 2019-04-04T00:49:55  <supay> hehe, that makes sense
148 2019-04-04T00:50:05  <supay> wait, let me retrieve the list as i had it before
149 2019-04-04T00:50:10  <supay> i think that will shed more light to this issue
150 2019-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)
151 2019-04-04T00:50:45  <gwillen> in fact, consider buying another drive to make an identical copy of whatever drive that is
152 2019-04-04T00:51:06  <achow101> supay: in your dumpwallet output, you should see multiple addresses for each private key
153 2019-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
154 2019-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
155 2019-04-04T00:51:30  <gwillen> and you should treat them with equivalent care
156 2019-04-04T00:51:35  <supay> achow101: yes, that is correct. i see 3
157 2019-04-04T00:51:36  <gwillen> okay, great
158 2019-04-04T00:51:42  <gwillen> (hopefully encrypted in the cloud...)
159 2019-04-04T00:51:53  <supay> yep, it is encrypted! :)
160 2019-04-04T00:52:02  <achow101> supay: one of those should begin with a 1, that doesn't match what you have in your list?
161 2019-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
162 2019-04-04T00:53:16  <achow101> do you see that address anywhere else in your list?
163 2019-04-04T00:53:54  <supay> the one in dumpwallet? nope, that isn't present in my list
164 2019-04-04T00:54:39  *** omonk has joined #bitcoin-core-dev
165 2019-04-04T00:54:56  *** supay has quit IRC
166 2019-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
167 2019-04-04T00:56:05  <gwillen> oops, we lost him
168 2019-04-04T00:57:44  *** jtimon has quit IRC
169 2019-04-04T00:58:03  *** spaced0ut has quit IRC
170 2019-04-04T00:58:48  *** zivl has quit IRC
171 2019-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."
172 2019-04-04T01:25:11  <gwillen> it's a sh(wsh(multi(2,A,B,C))) with fingerprints and paths given
173 2019-04-04T01:25:16  <gwillen> and tpubs
174 2019-04-04T01:26:01  <sipa> are the privkeys already imported?
175 2019-04-04T01:26:08  <gwillen> although getdescriptorinfo on it returns "hasprivatekeys": false
176 2019-04-04T01:26:14  <gwillen> shouldn't be
177 2019-04-04T01:26:25  <sipa> in that case it sounds like there's a bug...
178 2019-04-04T01:26:32  <gwillen> *nods*
179 2019-04-04T01:27:31  <sipa> what does gai on one of the resulting addresses say?
180 2019-04-04T01:29:33  <gwillen> I'm actually not sure how to get an address from it
181 2019-04-04T01:29:44  <gwillen> that was going to be the next thing to figure out :-)
182 2019-04-04T01:29:44  <sipa> deriveaddresses
183 2019-04-04T01:29:48  <gwillen> oho
184 2019-04-04T01:30:25  <gwillen> gai says ismine: false
185 2019-04-04T01:31:04  <gwillen> gai also displays the desc in a kind of broken way, uhoh
186 2019-04-04T01:31:10  <gwillen> it's suppose to step all three *'s together, right?
187 2019-04-04T01:31:57  <sipa> yes
188 2019-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
189 2019-04-04T01:32:16  <gwillen> so they display without it, but they're still changing
190 2019-04-04T01:32:30  <gwillen> this is a peak bug-filing day for me I guess :-)
191 2019-04-04T01:32:56  <gwillen> I suppose not a lot of people are executing these codepaths yet
192 2019-04-04T01:33:49  <sipa> yeah
193 2019-04-04T01:36:48  <gwillen> fanquake: how do you tag those so fast :-P
194 2019-04-04T01:36:49  <gwillen> are you a robot
195 2019-04-04T01:50:42  *** benthecarman has joined #bitcoin-core-dev
196 2019-04-04T01:50:46  *** drexl has quit IRC
197 2019-04-04T01:51:28  *** drexl has joined #bitcoin-core-dev
198 2019-04-04T01:52:27  *** benthecarman has quit IRC
199 2019-04-04T01:55:56  *** drexl has quit IRC
200 2019-04-04T02:15:01  *** BGL has quit IRC
201 2019-04-04T02:25:36  *** zivl has joined #bitcoin-core-dev
202 2019-04-04T02:31:21  *** jarthur has joined #bitcoin-core-dev
203 2019-04-04T02:36:44  *** jarthur has quit IRC
204 2019-04-04T02:50:10  <sipa> gwillen: i have met a humanoid-looking individual who claims to be fanquake
205 2019-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
206 2019-04-04T03:00:07  <gmaxwell> luke-jr: -ECOMPREHENSIONFAIL
207 2019-04-04T03:00:25  <gmaxwell> forget the mechenism, what property are you trying to achieve?
208 2019-04-04T03:01:25  <luke-jr> gmaxwell: making it infeasible to trust someone else's UTXO snapshot
209 2019-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
210 2019-04-04T03:02:11  <gmaxwell> well you can just copy your chainstate now...
211 2019-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
212 2019-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
213 2019-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.
214 2019-04-04T03:03:17  <gmaxwell> luke-jr: which legitimate use case?
215 2019-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
216 2019-04-04T03:03:48  <luke-jr> and/or effectively backup their chainstate
217 2019-04-04T03:04:21  <luke-jr> (if it gets corrupted, having a commitment to a UTXO set would help recover quicker)
218 2019-04-04T03:04:44  *** drexl has joined #bitcoin-core-dev
219 2019-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
220 2019-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).
221 2019-04-04T03:07:08  <luke-jr> I don't have a magic solution to make IBD instant.
222 2019-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.
223 2019-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)
224 2019-04-04T03:08:30  <luke-jr> it doesn't need to be complicated
225 2019-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.
226 2019-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.
227 2019-04-04T03:10:52  <luke-jr> it's good if it doesn't work with untrustworthy AWS nodes..
228 2019-04-04T03:11:01  <luke-jr> rsync doesn't work for backups
229 2019-04-04T03:11:38  <gmaxwell> What you're describing effectively doesn't work for backups either.
230 2019-04-04T03:11:56  <luke-jr> why not?
231 2019-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
232 2019-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.
233 2019-04-04T03:15:22  *** Eagle[TM] has joined #bitcoin-core-dev
234 2019-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.
235 2019-04-04T03:15:39  <gmaxwell> (I believe wumpus began working on this before)
236 2019-04-04T03:16:10  <luke-jr> for that, we need a way to freeze the chainstate db files during the backup, right?
237 2019-04-04T03:16:41  <gmaxwell> I believe wumpus worked on a thing previously to backup the chainstate using ldb snapshots.
238 2019-04-04T03:17:24  *** EagleTM has quit IRC
239 2019-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.
240 2019-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)
241 2019-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.
242 2019-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
243 2019-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.
244 2019-04-04T03:37:57  *** drexl has quit IRC
245 2019-04-04T03:46:27  *** BGL has joined #bitcoin-core-dev
246 2019-04-04T04:02:25  *** shesek has quit IRC
247 2019-04-04T04:22:16  *** hebasto has joined #bitcoin-core-dev
248 2019-04-04T04:32:13  *** jarthur has joined #bitcoin-core-dev
249 2019-04-04T04:36:47  *** jarthur has quit IRC
250 2019-04-04T04:54:02  *** ppisati has quit IRC
251 2019-04-04T05:00:40  *** ppisati has joined #bitcoin-core-dev
252 2019-04-04T05:02:54  *** spinza has quit IRC
253 2019-04-04T05:08:50  *** cornfeedhobo has quit IRC
254 2019-04-04T05:14:51  *** instagibbs has quit IRC
255 2019-04-04T05:14:53  *** kljasdfvv has quit IRC
256 2019-04-04T05:15:27  *** kljasdfvv has joined #bitcoin-core-dev
257 2019-04-04T05:17:04  *** spinza has joined #bitcoin-core-dev
258 2019-04-04T05:27:47  *** instagibbs has joined #bitcoin-core-dev
259 2019-04-04T05:28:56  <luke-jr> gmaxwell: AV utxo sync is not acceptably secure
260 2019-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.
261 2019-04-04T05:31:22  *** cornfeedhobo has joined #bitcoin-core-dev
262 2019-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.
263 2019-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.
264 2019-04-04T05:33:36  <gmaxwell> So how does AV make any of that worse?
265 2019-04-04T05:35:28  *** drexl has joined #bitcoin-core-dev
266 2019-04-04T05:42:59  <luke-jr> AV utxo sync is not simple AV..
267 2019-04-04T05:44:09  <gmaxwell> It isn't clear to me what you're saying.
268 2019-04-04T05:44:34  <gmaxwell> What is the attack model that you are concerned with?
269 2019-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
270 2019-04-04T05:47:10  *** benthecarman has joined #bitcoin-core-dev
271 2019-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.
272 2019-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
273 2019-04-04T05:49:40  <gmaxwell> something to trigger bypassing scriptchecks or similar.
274 2019-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.
275 2019-04-04T05:50:30  <gmaxwell> It applys no less to utxoav then it does to av in general.
276 2019-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)
277 2019-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.
278 2019-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.
279 2019-04-04T05:55:25  <gmaxwell> sustainability of the initial sync isn't a concern there.
280 2019-04-04T05:55:35  <gmaxwell> it's already horked.
281 2019-04-04T05:55:40  <luke-jr> not entirely yet
282 2019-04-04T05:55:52  <luke-jr> today, a new user *can* do the IBD
283 2019-04-04T05:56:02  <gmaxwell> even developers of lite clients don't want to run full nodes now, come on.
284 2019-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.
285 2019-04-04T05:56:33  <gmaxwell> s/to/too/
286 2019-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.
287 2019-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)
288 2019-04-04T05:59:14  <gmaxwell> (and I assume vice versa)
289 2019-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.
290 2019-04-04T06:01:31  *** benthecarman has quit IRC
291 2019-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.
292 2019-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
293 2019-04-04T06:02:39  <luke-jr> although I suppose the "an excuse to radically crank load" problem exists with *any* solution in this area
294 2019-04-04T06:02:50  <gmaxwell> luke-jr: not quite. AV review effort is a constant if you've already got a node running.
295 2019-04-04T06:03:07  <luke-jr> gmaxwell: new users shouldn't be forced to trust existing users in this way
296 2019-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.
297 2019-04-04T06:03:41  <gmaxwell> at best we can hope people review updates.
298 2019-04-04T06:04:16  <luke-jr> reviewing code is soemthing new users *can* do, even if not as a single person
299 2019-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.
300 2019-04-04T06:05:10  <luke-jr> that can change if we get 1 TB blocks
301 2019-04-04T06:05:43  <gmaxwell> no, because "1 tb blocks" (or similar jokes) isn't remotely viable for continued operation.
302 2019-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.
303 2019-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.
304 2019-04-04T06:07:42  *** drexl has quit IRC
305 2019-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.
306 2019-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.
307 2019-04-04T06:16:58  *** Skirmant has quit IRC
308 2019-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).
309 2019-04-04T06:18:12  *** Eagle[TM] has quit IRC
310 2019-04-04T06:18:18  <luke-jr> compact blocks doesn't have this problem, though?
311 2019-04-04T06:18:28  <luke-jr> hmm, I guess in a sense it could be argued to
312 2019-04-04T06:19:02  <gmaxwell> sure it could easily be argued to
313 2019-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)
314 2019-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!"
315 2019-04-04T06:24:05  *** Skirmant has joined #bitcoin-core-dev
316 2019-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.
317 2019-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)
318 2019-04-04T06:27:01  <gmaxwell> (or at least arguably make them true)
319 2019-04-04T06:30:51  <luke-jr> could have different priorities until someone else starts working on such features
320 2019-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"
321 2019-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.
322 2019-04-04T06:33:06  *** jarthur has joined #bitcoin-core-dev
323 2019-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!".
324 2019-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.
325 2019-04-04T06:35:11  <gmaxwell> which, indeed, had become very common before compact blocks
326 2019-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)
327 2019-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.
328 2019-04-04T06:37:52  *** jarthur has quit IRC
329 2019-04-04T06:40:17  <gmaxwell> (of course the degree depends on how serious the 'need' is...)
330 2019-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)
331 2019-04-04T06:50:36  *** mn9495885 has quit IRC
332 2019-04-04T06:50:37  *** mn94958863 has quit IRC
333 2019-04-04T06:50:37  *** mn949588 has quit IRC
334 2019-04-04T06:50:53  *** mn9495881 has quit IRC
335 2019-04-04T07:07:10  <gwillen> sipa: can I summon you to #15743
336 2019-04-04T07:07:12  <gribble> https://github.com/bitcoin/bitcoin/issues/15743 | getaddressinfo missing key origin information for multisig · Issue #15743 · bitcoin/bitcoin · GitHub
337 2019-04-04T07:28:47  *** gwillen has quit IRC
338 2019-04-04T07:29:18  *** gwillen has joined #bitcoin-core-dev
339 2019-04-04T07:30:59  *** Emcy has quit IRC
340 2019-04-04T07:40:16  *** rex4539 has quit IRC
341 2019-04-04T07:42:47  *** bitcoin-git has joined #bitcoin-core-dev
342 2019-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
343 2019-04-04T07:42:51  *** bitcoin-git has left #bitcoin-core-dev
344 2019-04-04T07:46:36  *** gribble has quit IRC
345 2019-04-04T07:49:56  *** mol has joined #bitcoin-core-dev
346 2019-04-04T07:49:57  *** ccdle12 has joined #bitcoin-core-dev
347 2019-04-04T07:51:19  *** molz has quit IRC
348 2019-04-04T07:53:01  *** rh0nj has quit IRC
349 2019-04-04T07:54:06  *** Skirmant has quit IRC
350 2019-04-04T07:54:07  *** rh0nj has joined #bitcoin-core-dev
351 2019-04-04T07:54:25  *** Skirmant has joined #bitcoin-core-dev
352 2019-04-04T07:55:48  *** gribble has joined #bitcoin-core-dev
353 2019-04-04T07:59:48  *** elichai2 has joined #bitcoin-core-dev
354 2019-04-04T08:04:53  *** drexl has joined #bitcoin-core-dev
355 2019-04-04T08:23:05  *** fanquake has quit IRC
356 2019-04-04T08:33:57  *** jarthur has joined #bitcoin-core-dev
357 2019-04-04T08:38:12  *** drexl has quit IRC
358 2019-04-04T08:38:38  *** jarthur has quit IRC
359 2019-04-04T08:46:57  *** mn94958864 has joined #bitcoin-core-dev
360 2019-04-04T08:46:58  *** mn9495882 has joined #bitcoin-core-dev
361 2019-04-04T08:46:58  *** mn94958859 has joined #bitcoin-core-dev
362 2019-04-04T08:46:58  *** mn949588 has joined #bitcoin-core-dev
363 2019-04-04T08:49:02  *** timothy has joined #bitcoin-core-dev
364 2019-04-04T08:51:56  *** mn94958864 has quit IRC
365 2019-04-04T08:51:57  *** mn9495882 has quit IRC
366 2019-04-04T08:51:57  *** mn94958859 has quit IRC
367 2019-04-04T08:51:57  *** mn949588 has quit IRC
368 2019-04-04T08:52:44  *** spinza has quit IRC
369 2019-04-04T09:04:30  *** kexkey has quit IRC
370 2019-04-04T09:07:54  *** hebasto has quit IRC
371 2019-04-04T09:09:28  *** spinza has joined #bitcoin-core-dev
372 2019-04-04T09:23:39  *** fanquake has joined #bitcoin-core-dev
373 2019-04-04T09:23:48  *** ccdle12 has quit IRC
374 2019-04-04T09:25:50  *** Emcy has joined #bitcoin-core-dev
375 2019-04-04T09:27:00  *** ccdle12 has joined #bitcoin-core-dev
376 2019-04-04T09:31:03  *** ccdle12 has quit IRC
377 2019-04-04T09:34:03  *** dviola has joined #bitcoin-core-dev
378 2019-04-04T09:43:52  *** ccdle12 has joined #bitcoin-core-dev
379 2019-04-04T09:43:57  *** Emcy has quit IRC
380 2019-04-04T10:03:40  *** spinza has quit IRC
381 2019-04-04T10:13:24  *** pinheadmz has quit IRC
382 2019-04-04T10:16:15  *** spinza has joined #bitcoin-core-dev
383 2019-04-04T10:17:10  *** pinheadmz has joined #bitcoin-core-dev
384 2019-04-04T10:17:20  *** rex4539 has joined #bitcoin-core-dev
385 2019-04-04T10:34:16  *** Emcy has joined #bitcoin-core-dev
386 2019-04-04T10:34:18  *** jonatack has joined #bitcoin-core-dev
387 2019-04-04T10:34:49  *** jarthur has joined #bitcoin-core-dev
388 2019-04-04T10:35:17  *** drexl has joined #bitcoin-core-dev
389 2019-04-04T10:36:01  *** AaronvanW has joined #bitcoin-core-dev
390 2019-04-04T10:39:21  *** ccdle12 has quit IRC
391 2019-04-04T10:39:27  *** jarthur has quit IRC
392 2019-04-04T10:43:30  *** ccdle12 has joined #bitcoin-core-dev
393 2019-04-04T10:48:04  *** mn949588 has joined #bitcoin-core-dev
394 2019-04-04T10:48:06  *** mn9495886 has joined #bitcoin-core-dev
395 2019-04-04T10:48:10  *** mn94958860 has joined #bitcoin-core-dev
396 2019-04-04T10:48:10  *** mn94958865 has joined #bitcoin-core-dev
397 2019-04-04T10:51:00  *** mn94958865 has quit IRC
398 2019-04-04T10:51:00  *** mn9495886 has quit IRC
399 2019-04-04T10:51:01  *** mn94958860 has quit IRC
400 2019-04-04T10:51:15  *** mn94958861 has joined #bitcoin-core-dev
401 2019-04-04T10:51:15  *** mn9495887 has joined #bitcoin-core-dev
402 2019-04-04T10:51:15  *** mn94958866 has joined #bitcoin-core-dev
403 2019-04-04T10:51:15  *** mn9495883 has joined #bitcoin-core-dev
404 2019-04-04T10:51:37  *** mn949588 has quit IRC
405 2019-04-04T10:52:24  *** ccdle12 has quit IRC
406 2019-04-04T10:56:04  *** mn94958861 has quit IRC
407 2019-04-04T10:56:04  *** mn9495887 has quit IRC
408 2019-04-04T10:56:04  *** mn94958866 has quit IRC
409 2019-04-04T10:56:04  *** mn9495883 has quit IRC
410 2019-04-04T10:57:19  *** ccdle12 has joined #bitcoin-core-dev
411 2019-04-04T10:57:39  *** ccdle12 has joined #bitcoin-core-dev
412 2019-04-04T11:03:22  *** ccdle12 has quit IRC
413 2019-04-04T11:08:49  *** drexl has quit IRC
414 2019-04-04T11:24:53  *** ccdle12 has joined #bitcoin-core-dev
415 2019-04-04T11:46:29  *** drexl has joined #bitcoin-core-dev
416 2019-04-04T11:47:22  *** atroxes has quit IRC
417 2019-04-04T11:47:52  *** atroxes has joined #bitcoin-core-dev
418 2019-04-04T11:55:26  *** profmac has quit IRC
419 2019-04-04T12:02:29  *** drexl_ has joined #bitcoin-core-dev
420 2019-04-04T12:03:30  *** drexl has quit IRC
421 2019-04-04T12:03:45  *** drexl has joined #bitcoin-core-dev
422 2019-04-04T12:04:23  *** drexl_ has quit IRC
423 2019-04-04T12:04:54  *** drexl has joined #bitcoin-core-dev
424 2019-04-04T12:08:27  *** profmac has joined #bitcoin-core-dev
425 2019-04-04T12:18:57  *** Skirmant has quit IRC
426 2019-04-04T12:19:50  *** Skirmant has joined #bitcoin-core-dev
427 2019-04-04T12:22:38  *** hebasto has joined #bitcoin-core-dev
428 2019-04-04T12:26:33  *** ccdle12 has quit IRC
429 2019-04-04T12:31:02  *** ccdle12 has joined #bitcoin-core-dev
430 2019-04-04T12:32:16  *** ccdle12 has quit IRC
431 2019-04-04T12:33:57  *** ccdle12 has joined #bitcoin-core-dev
432 2019-04-04T12:35:16  *** ryanofsky has quit IRC
433 2019-04-04T12:35:32  *** ryanofsky has joined #bitcoin-core-dev
434 2019-04-04T12:35:41  *** jarthur has joined #bitcoin-core-dev
435 2019-04-04T12:40:07  *** jarthur has quit IRC
436 2019-04-04T12:46:28  *** ccdle12 has quit IRC
437 2019-04-04T12:52:23  *** mn949588 has joined #bitcoin-core-dev
438 2019-04-04T12:52:24  *** mn94958862 has joined #bitcoin-core-dev
439 2019-04-04T12:52:24  *** mn94958867 has joined #bitcoin-core-dev
440 2019-04-04T12:52:24  *** mn9495884 has joined #bitcoin-core-dev
441 2019-04-04T12:57:31  *** harrymm has joined #bitcoin-core-dev
442 2019-04-04T12:57:43  *** mn94958862 has quit IRC
443 2019-04-04T12:57:43  *** mn94958867 has quit IRC
444 2019-04-04T12:57:43  *** mn9495884 has quit IRC
445 2019-04-04T12:57:43  *** mn949588 has quit IRC
446 2019-04-04T13:52:36  *** mn949588 has joined #bitcoin-core-dev
447 2019-04-04T13:52:37  *** mn94958863 has joined #bitcoin-core-dev
448 2019-04-04T13:52:40  *** mn9495888 has joined #bitcoin-core-dev
449 2019-04-04T13:52:41  *** mn9495885 has joined #bitcoin-core-dev
450 2019-04-04T13:53:32  *** jnewbery has quit IRC
451 2019-04-04T13:54:05  *** dqx_ has joined #bitcoin-core-dev
452 2019-04-04T13:54:17  *** jnewbery has joined #bitcoin-core-dev
453 2019-04-04T13:55:40  *** aqquadro has joined #bitcoin-core-dev
454 2019-04-04T13:55:40  *** aqquadro has quit IRC
455 2019-04-04T13:55:40  *** aqquadro has joined #bitcoin-core-dev
456 2019-04-04T13:56:21  *** spaced0ut has joined #bitcoin-core-dev
457 2019-04-04T13:57:26  *** mn94958863 has quit IRC
458 2019-04-04T13:57:31  *** mn9495885 has quit IRC
459 2019-04-04T13:57:32  *** mn949588 has quit IRC
460 2019-04-04T13:57:34  *** mn9495888 has quit IRC
461 2019-04-04T13:57:59  *** dqx_ has quit IRC
462 2019-04-04T13:58:03  *** tralfaz has joined #bitcoin-core-dev
463 2019-04-04T14:10:50  *** nc has joined #bitcoin-core-dev
464 2019-04-04T14:15:10  *** jnewbery has quit IRC
465 2019-04-04T14:26:15  *** jnewbery has joined #bitcoin-core-dev
466 2019-04-04T14:30:56  *** mn949588 has joined #bitcoin-core-dev
467 2019-04-04T14:30:59  *** mn94958864 has joined #bitcoin-core-dev
468 2019-04-04T14:30:59  *** mn94958868 has joined #bitcoin-core-dev
469 2019-04-04T14:30:59  *** mn9495889 has joined #bitcoin-core-dev
470 2019-04-04T14:33:35  *** dqx_ has joined #bitcoin-core-dev
471 2019-04-04T14:35:52  *** mn949588 has quit IRC
472 2019-04-04T14:35:53  *** mn9495889 has quit IRC
473 2019-04-04T14:36:09  *** mn94958864 has quit IRC
474 2019-04-04T14:36:10  *** mn94958868 has quit IRC
475 2019-04-04T14:36:33  *** jarthur has joined #bitcoin-core-dev
476 2019-04-04T14:37:57  *** dqx_ has quit IRC
477 2019-04-04T14:38:50  *** nc has quit IRC
478 2019-04-04T14:41:20  *** jarthur has quit IRC
479 2019-04-04T14:53:38  *** bitcoin-git has joined #bitcoin-core-dev
480 2019-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
481 2019-04-04T14:53:39  *** bitcoin-git has left #bitcoin-core-dev
482 2019-04-04T14:58:13  *** DeanGuss has quit IRC
483 2019-04-04T15:12:32  *** AaronvanW has quit IRC
484 2019-04-04T15:16:30  *** jonatack has quit IRC
485 2019-04-04T15:31:25  *** dviola has quit IRC
486 2019-04-04T15:35:06  *** Guyver2 has joined #bitcoin-core-dev
487 2019-04-04T15:45:11  *** d_t has joined #bitcoin-core-dev
488 2019-04-04T15:52:38  *** dqx_ has joined #bitcoin-core-dev
489 2019-04-04T15:56:15  *** jarthur has joined #bitcoin-core-dev
490 2019-04-04T15:56:23  *** araspitzu has joined #bitcoin-core-dev
491 2019-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
492 2019-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
493 2019-04-04T16:12:03  *** d_t has quit IRC
494 2019-04-04T16:19:49  *** bushstar has joined #bitcoin-core-dev
495 2019-04-04T16:27:07  *** araspitzu has quit IRC
496 2019-04-04T16:32:01  *** mn9495886 has joined #bitcoin-core-dev
497 2019-04-04T16:32:01  *** mn94958865 has joined #bitcoin-core-dev
498 2019-04-04T16:32:01  *** mn94958869 has joined #bitcoin-core-dev
499 2019-04-04T16:32:01  *** mn949588 has joined #bitcoin-core-dev
500 2019-04-04T16:36:39  *** mn9495886 has quit IRC
501 2019-04-04T16:36:39  *** mn94958865 has quit IRC
502 2019-04-04T16:37:00  *** mn94958869 has quit IRC
503 2019-04-04T16:37:00  *** mn949588 has quit IRC
504 2019-04-04T16:53:11  *** _Sam-- has joined #bitcoin-core-dev
505 2019-04-04T16:57:32  *** mn94958810 has joined #bitcoin-core-dev
506 2019-04-04T16:57:32  *** 92AABU4IQ has joined #bitcoin-core-dev
507 2019-04-04T16:57:33  *** 07EABABR2 has joined #bitcoin-core-dev
508 2019-04-04T16:57:34  *** mn949588 has joined #bitcoin-core-dev
509 2019-04-04T17:01:23  *** obsrver has joined #bitcoin-core-dev
510 2019-04-04T17:06:52  *** aqquadro has quit IRC
511 2019-04-04T17:19:46  *** bitcoin-git has joined #bitcoin-core-dev
512 2019-04-04T17:19:47  <bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/ba54342c9dd3...daef20fb50c0
513 2019-04-04T17:19:48  <bitcoin-git> bitcoin/master fae5f87 MarcoFalke: rpc: Document that minconf is an ignored dummy value
514 2019-04-04T17:19:48  <bitcoin-git> bitcoin/master faa3a24 MarcoFalke: scripted-diff: wallet: Rename pcoin to wtx
515 2019-04-04T17:19:50  <bitcoin-git> bitcoin/master fac1a0f MarcoFalke: wallet: Remove unused GetLegacyBalance
516 2019-04-04T17:19:51  *** bitcoin-git has left #bitcoin-core-dev
517 2019-04-04T17:20:25  *** bitcoin-git has joined #bitcoin-core-dev
518 2019-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
519 2019-04-04T17:20:26  *** bitcoin-git has left #bitcoin-core-dev
520 2019-04-04T17:25:13  *** 07EABABR2 has quit IRC
521 2019-04-04T17:25:13  *** mn94958810 has quit IRC
522 2019-04-04T17:25:13  *** 92AABU4IQ has quit IRC
523 2019-04-04T17:25:13  *** mn949588 has quit IRC
524 2019-04-04T17:27:05  *** dqx__ has joined #bitcoin-core-dev
525 2019-04-04T17:27:44  *** bitcoin-git has joined #bitcoin-core-dev
526 2019-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
527 2019-04-04T17:27:45  *** bitcoin-git has left #bitcoin-core-dev
528 2019-04-04T17:30:02  *** dqx_ has quit IRC
529 2019-04-04T18:07:14  *** Krellan has joined #bitcoin-core-dev
530 2019-04-04T18:07:22  *** Krellan_ has quit IRC
531 2019-04-04T18:11:30  *** davec has quit IRC
532 2019-04-04T18:21:39  *** davec has joined #bitcoin-core-dev
533 2019-04-04T18:23:18  <wumpus> rc3 binaries up https://bitcoincore.org/bin/bitcoin-core-0.18.0/test.rc3/
534 2019-04-04T18:30:48  *** bitcoin-git has joined #bitcoin-core-dev
535 2019-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
536 2019-04-04T18:30:49  *** bitcoin-git has left #bitcoin-core-dev
537 2019-04-04T18:36:40  *** d_t has joined #bitcoin-core-dev
538 2019-04-04T18:39:58  *** sipa has quit IRC
539 2019-04-04T18:41:21  *** sipa has joined #bitcoin-core-dev
540 2019-04-04T18:42:27  *** Krellan has quit IRC
541 2019-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?
542 2019-04-04T18:44:28  <gwillen> sipa: solvable true, watchonly true
543 2019-04-04T18:44:33  <gwillen> the only problem I see is the lack of key origin info
544 2019-04-04T18:44:37  <sipa> ok!
545 2019-04-04T18:44:41  <sipa> that's easy to fix
546 2019-04-04T18:44:52  *** sipa_ has joined #bitcoin-core-dev
547 2019-04-04T18:44:52  <gwillen> and the spurious warning
548 2019-04-04T18:44:55  <sipa> the import logic only looks at origin info for pubkeys that are being imported as well
549 2019-04-04T18:45:03  <gwillen> makes sense
550 2019-04-04T18:45:10  <gwillen> but the wallet is capable of holding origin info for pubkeys it doesn't have?
551 2019-04-04T18:45:13  <sipa> it should import all known origin info, even for pubkeys that aren't being imported
552 2019-04-04T18:45:16  <sipa> hmm
553 2019-04-04T18:45:40  <sipa> i'm mostly confused why deriveaddresses doesn't maintain the origin info
554 2019-04-04T18:45:49  <sipa> there is no wallet involved there
555 2019-04-04T18:47:14  <sipa> yeah i think we can import origin info for other keys
556 2019-04-04T18:48:26  <gwillen> sipa: yeah ProcessImport is just throwing it away if it doesn't have the key
557 2019-04-04T18:48:36  <gwillen> it calls pwallet->AddKeyOrigin for keys it has
558 2019-04-04T18:48:46  <gwillen> and throws away the rest
559 2019-04-04T18:52:27  <gwillen> but AddKeyOrigin wants a pubkey, which we don't have...
560 2019-04-04T18:53:28  <sipa_> it doesn't actually use a pubkey
561 2019-04-04T18:53:35  <sipa> only a pubkeyhash
562 2019-04-04T18:54:17  <sipa_> hi sipa_
563 2019-04-04T18:54:29  <sipa> why am i here twice in the same client?
564 2019-04-04T18:54:33  *** sipa_ has left #bitcoin-core-dev
565 2019-04-04T18:56:00  <MarcoFalke> sipa: Have you tried turning it off an on again?
566 2019-04-04T18:56:29  <sipa> actually, just off
567 2019-04-04T18:56:36  <sipa> feels much better
568 2019-04-04T18:56:52  <sipa> gwillen: oh i see now
569 2019-04-04T18:56:54  <MarcoFalke> \o/ on rc3, hopefully the last
570 2019-04-04T18:57:08  <sipa> you're reporting the gai output, and notice there that the origin info is missing
571 2019-04-04T18:57:21  <sipa> yeah, i think we should try importing just all origin info, even for non-importable pubkeys
572 2019-04-04T18:57:29  <sipa> but it's probably not enough to delay 0.18 for
573 2019-04-04T18:57:47  <sipa> (trying to avoid killing MarcoFalke's mood)
574 2019-04-04T18:58:19  *** jonatack has joined #bitcoin-core-dev
575 2019-04-04T19:00:35  <dongcarl> meeting?
576 2019-04-04T19:00:43  <achow101> meeting
577 2019-04-04T19:00:50  <sipa> meeting
578 2019-04-04T19:01:04  <jonasschnelli> yes
579 2019-04-04T19:01:06  <jonasschnelli> meeting
580 2019-04-04T19:01:17  <wumpus> #startmeeting
581 2019-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.
582 2019-04-04T19:01:17  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
583 2019-04-04T19:01:24  <jnewbery> hi
584 2019-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
585 2019-04-04T19:02:08  <wumpus> proposed topics?
586 2019-04-04T19:02:17  <MarcoFalke> TODOs in the release notes
587 2019-04-04T19:02:32  <MarcoFalke> They seem generally ready, but we'd need to finalize them for -final
588 2019-04-04T19:02:54  <wumpus> ok
589 2019-04-04T19:02:59  <MarcoFalke> They are "TODO sipa", not sure if that means sipa should do something or they were added by sipa
590 2019-04-04T19:03:01  <wumpus> #topic high priority for review
591 2019-04-04T19:03:11  <wumpus> https://github.com/bitcoin/bitcoin/projects/8
592 2019-04-04T19:03:51  <wumpus> #15006 #15557 #14121 #15141 #15512
593 2019-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
594 2019-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
595 2019-04-04T19:04:01  <sipa> MarcoFalke: it means i'll try to write them if nobody beats me :)
596 2019-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
597 2019-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
598 2019-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
599 2019-04-04T19:04:53  <wumpus> dunno if someone has something to add or remove?
600 2019-04-04T19:05:16  <meshcollider> hi
601 2019-04-04T19:05:42  <wumpus> helloo
602 2019-04-04T19:05:51  * sipa waves at wumpus 
603 2019-04-04T19:06:25  <sipa> i don't have anything right now for high priority
604 2019-04-04T19:06:36  <meshcollider> I'm still at ICPC so apologies for lack of activity
605 2019-04-04T19:06:51  <achow101> are any of gwillen's issue's blockers for rc3?
606 2019-04-04T19:06:58  <achow101> s/rc3/final/
607 2019-04-04T19:07:14  <wumpus> I don't think there's any blocking issues for rc3
608 2019-04-04T19:07:19  <wumpus> eh, for 0.18.0
609 2019-04-04T19:07:42  <sipa> i'm making a PR to fix #15743 right now, but i think it's a minor thing
610 2019-04-04T19:07:43  <gribble> https://github.com/bitcoin/bitcoin/issues/15743 | getaddressinfo missing key origin information for multisig · Issue #15743 · bitcoin/bitcoin · GitHub
611 2019-04-04T19:08:29  <wumpus> #topic blockers for 0.18.0
612 2019-04-04T19:09:22  <sipa> gwillen: opinions?
613 2019-04-04T19:10:22  <wumpus> so are any of these regressions for 0.18?
614 2019-04-04T19:10:50  <achow101> I don't think so. they're all new stuff added with descriptors
615 2019-04-04T19:10:52  <gwillen> I don't have opinions about 0.18
616 2019-04-04T19:11:13  <gwillen> none of them are correctness issues
617 2019-04-04T19:11:15  <wumpus> achow101: ok, thanks
618 2019-04-04T19:12:03  <wumpus> doesn't seem that needs to block the release
619 2019-04-04T19:12:20  <wumpus> #topic release notes TODOs 0.18.0
620 2019-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
621 2019-04-04T19:12:44  <sipa> i'd welcome help to fill in my TODOs :)
622 2019-04-04T19:13:28  <MarcoFalke> working on it rn
623 2019-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"
624 2019-04-04T19:13:51  <gwillen> :+1:
625 2019-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
626 2019-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
627 2019-04-04T19:14:27  <gwillen> but when I tried to do so, I got an error
628 2019-04-04T19:14:36  <wumpus> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft
629 2019-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
630 2019-04-04T19:15:21  <wumpus> gwillen: we could add a known issue
631 2019-04-04T19:15:43  <gwillen> that would make sense, although who reads those
632 2019-04-04T19:15:57  <gwillen> but I think it is definitely a known thing that one should avoid triggering
633 2019-04-04T19:16:02  <wumpus> sigh, who ever reads anything right ...
634 2019-04-04T19:16:11  <wumpus> if you start asking that why spend time writing release notes at all !
635 2019-04-04T19:16:19  *** obsrver has quit IRC
636 2019-04-04T19:17:00  <wumpus> anyhow the TODO s are;
637 2019-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)
638 2019-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)
639 2019-04-04T19:17:53  <wumpus> (TODO pieter: mention getdata randomization from #14897 and perhaps orphan tx handling from #14626) under "network"
640 2019-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
641 2019-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
642 2019-04-04T19:18:10  <wumpus> (TODO pieter: mention HWI project?)  under "wallet"
643 2019-04-04T19:18:26  <wumpus> (TODO pieter: mention that the rdseed instruction is used where available) under "security"
644 2019-04-04T19:18:34  <wumpus> I think the latter is very low-level for release notes
645 2019-04-04T19:18:42  <sipa> yeah
646 2019-04-04T19:19:24  <wumpus> we also need to be careful to include things that are useful to users to know
647 2019-04-04T19:19:45  <wumpus> too much and people will indeed just skip over things
648 2019-04-04T19:20:20  <wumpus> (TODO pieter: mention new descriptor RPCs deriveaddresses/getdescriptorinfo, and descriptor support in importmulti) under "Documentation"
649 2019-04-04T19:21:17  <wumpus> anyhow help is welcome here
650 2019-04-04T19:21:56  <sipa> assuming no further problems in rc3, when final?
651 2019-04-04T19:21:59  <wumpus> TODO: remove any leftover TODOs before sending the final release notes :)
652 2019-04-04T19:22:53  <wumpus> more or less one week per rc, so I think next week thursday
653 2019-04-04T19:23:36  <MarcoFalke> agree on that timeline
654 2019-04-04T19:24:02  <sipa> yeha
655 2019-04-04T19:24:07  <sipa> *yeah
656 2019-04-04T19:24:59  <gwillen> wumpus: I added some suggested known-issue text to #15725
657 2019-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
658 2019-04-04T19:25:32  <sipa> when do we switch release notes back from wallet to repo?
659 2019-04-04T19:25:56  <MarcoFalke> next tuesday?
660 2019-04-04T19:26:10  <wumpus> sipa: usually just before labeling final
661 2019-04-04T19:26:21  <sipa> okay
662 2019-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?
663 2019-04-04T19:26:52  <wumpus> MarcoFalke: also fine with me, if we know we're going to do final next
664 2019-04-04T19:27:14  <wumpus> just, if you want to do release note editing, please do it on the wiki
665 2019-04-04T19:28:42  <wumpus> any other topics?
666 2019-04-04T19:30:32  <kanzure> no warren update today
667 2019-04-04T19:30:43  <wumpus> thanks for letting us know kanzure
668 2019-04-04T19:32:16  <wumpus> I guess that's all for today
669 2019-04-04T19:32:24  <wumpus> #endmeeting
670 2019-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)
671 2019-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
672 2019-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
673 2019-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
674 2019-04-04T19:33:23  <wumpus> gwillen: thanks
675 2019-04-04T19:33:48  *** hebasto has quit IRC
676 2019-04-04T19:33:53  <gwillen> wumpus: I can edit it into the notes on the wiki, but where actually is that? :-)
677 2019-04-04T19:34:12  *** zivl has quit IRC
678 2019-04-04T19:34:56  <sipa> https://github.com/bitcoin-core/bitcoin-devwiki/wiki
679 2019-04-04T19:35:06  <wumpus> gwillen: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft#known-issues
680 2019-04-04T19:35:20  <wumpus> I've already added it, feel free to edit it further
681 2019-04-04T19:35:28  <gwillen> thanks
682 2019-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
683 2019-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
684 2019-04-04T19:38:19  <wumpus> yes, it's good like this
685 2019-04-04T19:38:24  <gwillen> :+1:
686 2019-04-04T19:38:25  *** qubenix has quit IRC
687 2019-04-04T19:38:51  *** qubenix has joined #bitcoin-core-dev
688 2019-04-04T19:41:10  <sipa> gwillen, achow101: it seems deriveaddresses has somewhat exponentially-looking performance for increasing number of keys
689 2019-04-04T19:41:14  <sipa> this is weird
690 2019-04-04T19:42:21  <achow101> i would expect it to be linear
691 2019-04-04T19:42:54  <sipa> it should be
692 2019-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?
693 2019-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
694 2019-04-04T19:47:24  <sipa> agree
695 2019-04-04T19:47:28  <sipa> that could be the reason
696 2019-04-04T19:47:39  <sipa> should be more n*log(n)'ish though
697 2019-04-04T19:47:43  <sipa> maybe it is
698 2019-04-04T19:48:26  *** bitcoin-git has joined #bitcoin-core-dev
699 2019-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
700 2019-04-04T19:48:28  *** bitcoin-git has left #bitcoin-core-dev
701 2019-04-04T19:51:02  *** Icreatedbitcoin2 has joined #bitcoin-core-dev
702 2019-04-04T19:56:21  *** Icreatedbitcoin2 has quit IRC
703 2019-04-04T19:56:40  *** sodiafosidf has joined #bitcoin-core-dev
704 2019-04-04T19:57:50  *** bitcoin-git has joined #bitcoin-core-dev
705 2019-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
706 2019-04-04T19:57:57  *** bitcoin-git has left #bitcoin-core-dev
707 2019-04-04T19:58:19  <sipa> gwillen: ^
708 2019-04-04T20:04:13  *** sipa has quit IRC
709 2019-04-04T20:08:45  *** sipa has joined #bitcoin-core-dev
710 2019-04-04T20:08:57  *** bitcoin-git has joined #bitcoin-core-dev
711 2019-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
712 2019-04-04T20:08:59  *** bitcoin-git has left #bitcoin-core-dev
713 2019-04-04T20:09:59  *** sipa_ has joined #bitcoin-core-dev
714 2019-04-04T20:10:32  *** sipa_ has quit IRC
715 2019-04-04T20:15:14  *** bitcoin-git has joined #bitcoin-core-dev
716 2019-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
717 2019-04-04T20:15:16  *** bitcoin-git has left #bitcoin-core-dev
718 2019-04-04T20:15:54  *** kmls has quit IRC
719 2019-04-04T20:19:20  *** spinza has quit IRC
720 2019-04-04T20:28:45  *** elichai2 has quit IRC
721 2019-04-04T20:31:19  *** Krellan has joined #bitcoin-core-dev
722 2019-04-04T20:34:13  *** Krellan has quit IRC
723 2019-04-04T20:47:24  *** d_t has quit IRC
724 2019-04-04T20:48:05  *** bitcoin-git has joined #bitcoin-core-dev
725 2019-04-04T20:48:05  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/daef20fb50c0...c83442e17412
726 2019-04-04T20:48:05  <bitcoin-git> bitcoin/master fa8548c MarcoFalke: net: Remove unused unsanitized user agent string CNode::strSubVer
727 2019-04-04T20:48:06  <bitcoin-git> bitcoin/master c83442e MarcoFalke: Merge #15654: net: Remove unused unsanitized user agent string CNode::strS...
728 2019-04-04T20:48:07  *** bitcoin-git has left #bitcoin-core-dev
729 2019-04-04T20:48:49  *** bitcoin-git has joined #bitcoin-core-dev
730 2019-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
731 2019-04-04T20:49:00  *** bitcoin-git has left #bitcoin-core-dev
732 2019-04-04T20:51:13  *** Guyver2 has quit IRC
733 2019-04-04T20:55:25  <gwillen> thanks sipa! Will take a look.
734 2019-04-04T20:55:27  *** spinza has joined #bitcoin-core-dev
735 2019-04-04T20:55:45  <gwillen> sipa: is derivaddress exponential or merely quadratic?
736 2019-04-04T20:55:53  <gwillen> quadratic would not be super shocking
737 2019-04-04T20:56:59  <sipa> gwillen: linearithmic if the cause is what i think it is
738 2019-04-04T21:45:00  *** bushstar has quit IRC
739 2019-04-04T21:54:53  *** drexl has quit IRC
740 2019-04-04T22:25:00  *** spinza has quit IRC
741 2019-04-04T22:31:03  *** spinza has joined #bitcoin-core-dev
742 2019-04-04T22:46:47  *** AaronvanW has joined #bitcoin-core-dev
743 2019-04-04T22:48:38  *** Aaronvan_ has joined #bitcoin-core-dev
744 2019-04-04T22:51:18  *** AaronvanW has quit IRC
745 2019-04-04T23:02:34  *** qubenix has quit IRC
746 2019-04-04T23:04:46  *** qubenix has joined #bitcoin-core-dev
747 2019-04-04T23:12:45  *** Zenton has quit IRC
748 2019-04-04T23:13:58  *** Aaronvan_ is now known as AaronvanW
749 2019-04-04T23:33:34  *** mn949588 has joined #bitcoin-core-dev
750 2019-04-04T23:40:08  *** bitbee has quit IRC
751 2019-04-04T23:40:53  *** bitbee has joined #bitcoin-core-dev
752 2019-04-04T23:43:40  *** bitbee has quit IRC
753 2019-04-04T23:45:28  *** jarthur has quit IRC
754 2019-04-04T23:58:48  *** bitcoin-git has joined #bitcoin-core-dev
755 2019-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
756 2019-04-04T23:58:59  *** bitcoin-git has left #bitcoin-core-dev