1 2019-04-03T00:20:31  *** fanquake has quit IRC
  2 2019-04-03T00:37:53  <gwillen> hmmm, can someone tell me why CoinControlDialog uses a static CoinControl object, instead of like, having the caller supply one
  3 2019-04-03T00:37:59  <gwillen> I expect the answer is "because it was easier"
  4 2019-04-03T01:06:37  *** AaronvanW has quit IRC
  5 2019-04-03T01:08:16  *** timothy has quit IRC
  6 2019-04-03T01:09:45  *** echonaut1 has joined #bitcoin-core-dev
  7 2019-04-03T01:12:06  *** achow101_ has joined #bitcoin-core-dev
  8 2019-04-03T01:12:33  *** echonaut has quit IRC
  9 2019-04-03T01:12:34  *** BGL has quit IRC
 10 2019-04-03T01:12:34  *** Evel-Knievel has quit IRC
 11 2019-04-03T01:12:34  *** achow101 has quit IRC
 12 2019-04-03T01:12:35  *** owowo has quit IRC
 13 2019-04-03T01:13:10  *** Evel-Knievel has joined #bitcoin-core-dev
 14 2019-04-03T01:13:24  *** owowo has joined #bitcoin-core-dev
 15 2019-04-03T01:14:16  *** fanquake has joined #bitcoin-core-dev
 16 2019-04-03T01:15:12  *** phantomcircuit has quit IRC
 17 2019-04-03T01:16:03  <fanquake> I assume this was accidental, rather than spam (as it was reverted right after). Just need to keep an eye on the wiki.. https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft/_compare/af6d617%5E...af6d617
 18 2019-04-03T01:17:42  *** phantomcircuit has joined #bitcoin-core-dev
 19 2019-04-03T01:22:04  *** Krellan has quit IRC
 20 2019-04-03T01:49:55  <conman> gmaxwell: did some more testing
 21 2019-04-03T01:50:03  <conman> I picked a random transaction from the mempool
 22 2019-04-03T01:50:10  <conman> if it's a regular transaction I can prioritise it
 23 2019-04-03T01:50:20  <conman> if it's a segwit one I canNOT get it into the template
 24 2019-04-03T01:50:42  <conman> I picked a random txn (not mine) with the txid f8ac1bf739aace5c10fbde87d387e47a2536e897a738a65e1f153fe02ddabf01
 25 2019-04-03T01:50:49  <conman> see if you can prioritise it
 26 2019-04-03T01:51:07  <conman> its fee is 2590s
 27 2019-04-03T01:57:50  *** nanotube has quit IRC
 28 2019-04-03T01:59:50  *** achow101_ is now known as achow101
 29 2019-04-03T02:01:01  *** nanotube has joined #bitcoin-core-dev
 30 2019-04-03T02:02:22  *** achow101 is now known as achow101_
 31 2019-04-03T02:02:31  *** achow101_ is now known as achow101
 32 2019-04-03T02:09:28  *** BGL has joined #bitcoin-core-dev
 33 2019-04-03T02:53:54  <conman> yep I cannot successfully prioritise any segwit transactions into the block template
 34 2019-04-03T03:49:20  *** tynes has joined #bitcoin-core-dev
 35 2019-04-03T04:03:51  *** ossifrage has quit IRC
 36 2019-04-03T04:04:11  *** ossifrage has joined #bitcoin-core-dev
 37 2019-04-03T04:46:14  <gmaxwell> conman: can you take a segwit txn that is already in the template and prioritize it so it goes from near the bottom to near the top?
 38 2019-04-03T04:46:14  *** arubi has quit IRC
 39 2019-04-03T04:46:35  *** arubi has joined #bitcoin-core-dev
 40 2019-04-03T05:08:41  *** hebasto has joined #bitcoin-core-dev
 41 2019-04-03T05:10:48  *** Krellan_ has joined #bitcoin-core-dev
 42 2019-04-03T05:24:25  <conman> ok lemme try
 43 2019-04-03T05:29:54  <conman> of course all the ones low down are NOT segwit txns..
 44 2019-04-03T05:35:37  <conman> man just how few segwit txns are there...
 45 2019-04-03T05:39:12  <gmaxwell> do you have any?
 46 2019-04-03T05:39:13  <gmaxwell> ./bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' | jq '.transactions | .[] | select(.hash != .txid)'
 47 2019-04-03T05:39:38  <gmaxwell> I see 1090 in my template...
 48 2019-04-03T05:39:47  <conman> thanks that's what I needed to help
 49 2019-04-03T05:40:13  <gmaxwell> so about 40% of them.
 50 2019-04-03T05:40:35  <conman> yeah I was just randomly picking them off the bottom and looking at them
 51 2019-04-03T05:40:40  <conman> silly me
 52 2019-04-03T05:40:46  <conman> since I know nought of this
 53 2019-04-03T05:41:52  <conman> ok I prioritised the lowest priority one I could find
 54 2019-04-03T05:41:53  <gmaxwell> FWIW, it worked for me (with 0.18rc) -- I picked the bottom segwit txn, prioritised it, and it's now the second transaction in my template.
 55 2019-04-03T05:42:01  <conman> and now it no longer appears in the block template at all
 56 2019-04-03T05:42:10  <conman> let's try again
 57 2019-04-03T05:42:26  <gmaxwell> OH how high is your priority? is it possible that there is an overflow somwhere?
 58 2019-04-03T05:42:40  <gmaxwell> I did: $ ./bitcoin-cli prioritisetransaction 35611cbad11967731aa122136bf90bd63c5224296c45c10a26885c3bb3fff6f6 0 100000
 59 2019-04-03T05:42:40  <gmaxwell> true
 60 2019-04-03T05:42:46  <conman> 0.1btc
 61 2019-04-03T05:42:55  <conman> so 10000000
 62 2019-04-03T05:43:06  <conman> again, same thing happened this time around
 63 2019-04-03T05:43:10  <conman> I'll try smaller then
 64 2019-04-03T05:43:24  <conman> but note that size priority worked fine on a regular transaction
 65 2019-04-03T05:43:25  <gmaxwell> I tried 10000000 ... now its the first one.
 66 2019-04-03T05:43:32  <conman> then wtf is going on here
 67 2019-04-03T05:44:11  <gmaxwell> bug in 0.17 that is fixed in 0.18? I just don't recall any such changes.
 68 2019-04-03T05:44:46  <conman> every prioritised one disappears instead of moving up
 69 2019-04-03T05:45:19  <conman> hang on, maybe I'm searching for it wrong in the template
 70 2019-04-03T05:47:03  <gmaxwell> I'm just ./bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' | jq '.transactions | .[] | select(.hash != .txid)' |less  and hitting / and pasting in the txid.
 71 2019-04-03T05:47:22  <gmaxwell> and I successfully move something to the top, then undo the priority and it goes back down to near the bottom.
 72 2019-04-03T05:47:29  <conman> I'm not adding rules to getblocktemplate...
 73 2019-04-03T05:47:41  <conman> is that what I'm doing wrong?
 74 2019-04-03T05:48:04  <conman> doesn't explain how it's been generating templates with segwit txns all the time
 75 2019-04-03T05:48:25  <conman> I was just doing getblocktemplate | grep
 76 2019-04-03T05:49:00  <conman> or | less and then / searching
 77 2019-04-03T05:49:01  <gmaxwell> oh man..
 78 2019-04-03T05:49:04  <conman> :(
 79 2019-04-03T05:49:12  * conman hides
 80 2019-04-03T05:49:24  <gmaxwell> So I did ask...
 81 2019-04-03T05:49:28  <gmaxwell> in 0.18 this isn't a problem:
 82 2019-04-03T05:49:44  <gmaxwell> $ ./bitcoin-cli getblocktemplate
 83 2019-04-03T05:49:44  <gmaxwell> error code: -8
 84 2019-04-03T05:49:44  <gmaxwell> error message:
 85 2019-04-03T05:49:44  <gmaxwell> getblocktemplate must be called with the segwit rule set (call with {"rules": ["segwit"]})
 86 2019-04-03T05:49:55  <conman> I see
 87 2019-04-03T05:50:07  <gmaxwell> but for backwards compat reasons gbt won't include any segwit txn unless called with rules (and in 0.18 that functionality is disabled)
 88 2019-04-03T05:50:24  <conman> I'm just going to rock back and forth in the corner
 89 2019-04-03T05:50:49  <gmaxwell> I would have asked harder but I didn't remember when the backwards compat was turned off,  I kinda assumed 0.17 had it too, so I didn't ask more than once. Sorry.
 90 2019-04-03T05:51:03  <conman> don't be sorry, it's all my fault
 91 2019-04-03T05:51:07  <gmaxwell> this was a known footgun thus the new behavior in 0.18.
 92 2019-04-03T05:51:16  <conman> for some reason I thought the rules were on by default
 93 2019-04-03T05:51:36  <gmaxwell> yea, they aren't just because if you had non-segwit capable mining software you'd start silently mining invalid blocks.
 94 2019-04-03T05:51:46  <gmaxwell> And we'd rather it fail cleanly.
 95 2019-04-03T05:53:19  <conman> ok well that's been a big learning experience
 96 2019-04-03T05:53:31  <conman> for all the wrong reasons
 97 2019-04-03T05:53:40  <gmaxwell> thanks for the confirmation that 0.18's behavior change is a useful de-footgunning. :P
 98 2019-04-03T05:55:04  <conman> of course the pool software doesn't do that so no idea why I didn't think of it for the command line :s
 99 2019-04-03T05:55:40  <conman> I really have to get out of this game, it's bad for my health
100 2019-04-03T05:56:48  *** nanotube has quit IRC
101 2019-04-03T05:57:21  <conman> thanks again
102 2019-04-03T05:57:29  <gmaxwell> sorry, this interface was bad-- just an annoying consequence of backwards compatiblity. That much isn't your fault. :)
103 2019-04-03T05:57:37  <gmaxwell> I'm glad it wasn't a weird bug though.
104 2019-04-03T06:01:02  *** nanotube has joined #bitcoin-core-dev
105 2019-04-03T06:12:04  *** spinza has quit IRC
106 2019-04-03T06:24:47  *** rex4539 has quit IRC
107 2019-04-03T06:25:36  *** spinza has joined #bitcoin-core-dev
108 2019-04-03T06:25:55  * conman quietly disappears
109 2019-04-03T06:25:57  *** conman has left #bitcoin-core-dev
110 2019-04-03T06:27:06  <gmaxwell> Next Customer!
111 2019-04-03T06:27:39  * gmaxwell is sad that he has still not learned the zen of tech support.
112 2019-04-03T06:27:45  <gwillen> gmaxwell: can you help me with this terrible pain I have in all the diodes down my left side
113 2019-04-03T06:28:12  <gmaxwell> gwillen: have you had them replaced?
114 2019-04-03T06:30:45  <gmaxwell> When I worked for Juniper I was often amazed at how the really good tech support people managed to solve some feindishly hard problems that no one else could solve by being single mindedly consistent about asking all the dumb questions and carefully validating every claim and piece of information.
115 2019-04-03T06:31:14  <gmaxwell> And yet, no matter how much I tell myself that I _must_ ask the 'dumb' questions to get compariable results, I still manage to fail.
116 2019-04-03T06:36:09  *** windsok has quit IRC
117 2019-04-03T06:45:36  *** DeanGuss has joined #bitcoin-core-dev
118 2019-04-03T06:47:25  *** Soligor has joined #bitcoin-core-dev
119 2019-04-03T06:47:29  *** rex4539 has joined #bitcoin-core-dev
120 2019-04-03T06:48:12  <wumpus> gwillen: yes the global coin control object is kind of ugly, and very much different from how the rest of the GUI code works; basically because the original author wrote it like that, and people kind of wanted the functionality so didn't want to hold up the merge for it, it was expected that someone would improve it down the line
121 2019-04-03T06:49:28  <wumpus> gwillen: I'm somewhat surprised it doesn't give trouble with multiple wallets
122 2019-04-03T06:54:53  *** windsok has joined #bitcoin-core-dev
123 2019-04-03T07:03:06  <gwillen> wumpus: ... actually it appears to be pretty broken with multiple wallets
124 2019-04-03T07:03:16  <gwillen> I never thought to try that
125 2019-04-03T07:04:05  <gwillen> it seems to keep UTXOs selected when switching wallets that don't exist in the second wallet
126 2019-04-03T07:04:11  <gwillen> I'm not sure what happens if I then try to spend them.
127 2019-04-03T07:04:27  <gwillen> perhaps this is the secret backdoor way to spend from multiple wallets at once, heh
128 2019-04-03T07:05:35  <gwillen> anyway I am tempted to fix it but I don't have spare cycles right now, ask me again in a month or two and I'll probably do it
129 2019-04-03T07:07:56  *** Guyver2 has joined #bitcoin-core-dev
130 2019-04-03T07:14:44  *** Dean_Guss has joined #bitcoin-core-dev
131 2019-04-03T07:14:49  *** DeanGuss has quit IRC
132 2019-04-03T07:16:31  *** fanquake has quit IRC
133 2019-04-03T07:27:31  <wumpus> gwillen: please create an issue for it at least
134 2019-04-03T07:29:36  <wumpus> fanquake: thanks for keeping an eye on changes to the release notes-if this keeps up we'll have to restrict edits to people in the bitcoin-core org (I'd prefer not to as this loses some potential documentation-only contributors), but this may well be accidental and they fixed it
135 2019-04-03T07:49:45  *** fanquake has joined #bitcoin-core-dev
136 2019-04-03T07:57:36  <gwillen> wumpus: hmm, this may be either caused or revealed by my changes, investigating before I file it
137 2019-04-03T08:00:06  <jonasschnelli> cfields: 0.18.0rc3 osx detached signatures are here: https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/24
138 2019-04-03T08:00:58  <gmaxwell> I've been watching logs on a couple nodes and it looks like new installs of 0.16.1 are significantly more common than later versions.
139 2019-04-03T08:01:04  <gmaxwell> I wonder if there is some outdated link someplace.
140 2019-04-03T08:01:19  <wumpus> maybe some distro did the cursed thing
141 2019-04-03T08:01:36  <gmaxwell> (or there is some spy/sybil-attacker that looks like these things, but I don't think so as I'm already pretty heavily excluding things that look like that)
142 2019-04-03T08:01:41  <wumpus> (e.g. freeze one version of bitcoin core as "stable")
143 2019-04-03T08:03:07  <gmaxwell> Checking my logs most of them appear to be IPs in china.
144 2019-04-03T08:03:59  <gmaxwell> jl2012: ^ any thoughts for this? is it possible some high visibility chinese language bitcoin resource links to 0.16.1 ?
145 2019-04-03T08:07:35  <gmaxwell> looks like 98% of them are chinese.
146 2019-04-03T08:09:12  <jl2012> I'll take a look
147 2019-04-03T08:10:10  <jl2012> Are they from random ip, or from a few datacenters?
148 2019-04-03T08:10:32  *** setpill has joined #bitcoin-core-dev
149 2019-04-03T08:12:23  <gmaxwell> Many, though a large number are from 1.196.144.0/24
150 2019-04-03T08:13:12  *** setpill has quit IRC
151 2019-04-03T08:18:23  *** setpill has joined #bitcoin-core-dev
152 2019-04-03T08:24:39  <gwillen> wumpus: filed #15725, I can't make this happen every time but it's reliable enough that I'm convinced it's probably not anything I touched
153 2019-04-03T08:24:40  <gribble> https://github.com/bitcoin/bitcoin/issues/15725 | Manual coin control dialog interacts badly with multiple wallets · Issue #15725 · bitcoin/bitcoin · GitHub
154 2019-04-03T08:26:55  <wumpus> gwillen: thank you
155 2019-04-03T08:36:18  *** Zenton has joined #bitcoin-core-dev
156 2019-04-03T08:51:04  *** timothy has joined #bitcoin-core-dev
157 2019-04-03T09:07:01  <fanquake> Added a validating subtree merges how-to to core-review: https://github.com/fanquake/core-review/blob/master/subtree-merge.md
158 2019-04-03T09:09:05  <fanquake> Also, anyone is upgrading to Xcode 10.2, you may have to re-install the macOS_SDK_headers.pkg, otherwise your depends builds may break.
159 2019-04-03T09:25:52  *** kryoha has joined #bitcoin-core-dev
160 2019-04-03T09:38:48  <wumpus> fanquake: this is very useful, thanks for working on that document
161 2019-04-03T09:41:30  <wumpus> I think we also need to document the exact steps to update the various subtrees, there's some overlap with the "Subtrees" section in doc/developer-notes.md btw
162 2019-04-03T09:47:34  *** bitcoin-git has joined #bitcoin-core-dev
163 2019-04-03T09:47:35  <bitcoin-git> [bitcoin] ajtowns opened pull request #15726: bitcoin-cli -yaml support (master...201904-cli-yaml) https://github.com/bitcoin/bitcoin/pull/15726
164 2019-04-03T09:47:48  *** bitcoin-git has left #bitcoin-core-dev
165 2019-04-03T09:57:29  *** kryoha has quit IRC
166 2019-04-03T10:01:21  <wumpus> yaml?!?
167 2019-04-03T10:04:56  *** Nakamoto has joined #bitcoin-core-dev
168 2019-04-03T10:12:13  *** nullptr| has quit IRC
169 2019-04-03T10:13:22  <fanquake> wumpus Yea just documenting useful stuff. All the things I do infrequently enough that I have to go look it/the process up again.
170 2019-04-03T10:18:41  *** nullptr| has joined #bitcoin-core-dev
171 2019-04-03T10:18:50  <aj> wumpus: i can't read numbers without thousands separators man
172 2019-04-03T10:19:03  *** jonatack has joined #bitcoin-core-dev
173 2019-04-03T10:19:33  *** spinza has quit IRC
174 2019-04-03T10:29:04  *** Nakamoto has quit IRC
175 2019-04-03T10:35:15  *** AaronvanW has joined #bitcoin-core-dev
176 2019-04-03T10:37:12  *** spinza has joined #bitcoin-core-dev
177 2019-04-03T11:16:13  *** michaelfolkson has joined #bitcoin-core-dev
178 2019-04-03T11:43:37  *** zivl has quit IRC
179 2019-04-03T11:48:01  *** jonatack has quit IRC
180 2019-04-03T11:56:04  *** zivl has joined #bitcoin-core-dev
181 2019-04-03T11:57:03  *** michaelfolkson has quit IRC
182 2019-04-03T12:00:27  *** emzy has quit IRC
183 2019-04-03T12:03:51  *** emzy has joined #bitcoin-core-dev
184 2019-04-03T12:04:03  *** emzy has quit IRC
185 2019-04-03T12:08:00  *** michaelfolkson has joined #bitcoin-core-dev
186 2019-04-03T12:09:47  *** DeanWeen has joined #bitcoin-core-dev
187 2019-04-03T12:10:23  *** michaelfolkson has quit IRC
188 2019-04-03T12:13:25  *** Dean_Guss has quit IRC
189 2019-04-03T12:17:32  *** michaelfolkson has joined #bitcoin-core-dev
190 2019-04-03T12:27:28  *** emzy has joined #bitcoin-core-dev
191 2019-04-03T12:31:05  *** emzy has quit IRC
192 2019-04-03T12:31:05  *** emzy has joined #bitcoin-core-dev
193 2019-04-03T12:31:13  <luke-jr> FWIW, it looks like Boost::Process 1.45 is broken in that it doesn't recongised died-by-signal as exited (and throws exceptions wildly as a result)
194 2019-04-03T12:31:17  <luke-jr> 1.47 has it fixed I guess
195 2019-04-03T12:36:39  *** DeanWeen has quit IRC
196 2019-04-03T12:37:02  <fanquake> luke-jr Boost.Process in Boost 1.45 ? I thought it was only introduced in 1.64? Or are you talking about something else?
197 2019-04-03T12:51:06  <luke-jr> sorry, I have my versions wrong, sec
198 2019-04-03T12:51:13  <luke-jr> 1.65 vs 1.67
199 2019-04-03T13:01:07  *** spaced0ut has quit IRC
200 2019-04-03T13:12:37  *** DeanWeen has joined #bitcoin-core-dev
201 2019-04-03T13:13:33  *** Karyon has quit IRC
202 2019-04-03T13:14:06  *** spaced0ut has joined #bitcoin-core-dev
203 2019-04-03T13:16:01  *** shtirlic has quit IRC
204 2019-04-03T13:27:07  *** michaelfolkson has quit IRC
205 2019-04-03T13:28:40  *** promag has joined #bitcoin-core-dev
206 2019-04-03T13:33:16  *** shtirlic has joined #bitcoin-core-dev
207 2019-04-03T13:37:18  *** Karyon has joined #bitcoin-core-dev
208 2019-04-03T13:46:48  *** bitcoin-git has joined #bitcoin-core-dev
209 2019-04-03T13:46:48  <bitcoin-git> [bitcoin] jnewbery opened pull request #15728: [wallet] Refactor relay transactions (master...2019_03_refactor_relay_transactions) https://github.com/bitcoin/bitcoin/pull/15728
210 2019-04-03T13:46:50  *** bitcoin-git has left #bitcoin-core-dev
211 2019-04-03T13:47:31  *** Aaronvan_ has joined #bitcoin-core-dev
212 2019-04-03T13:50:32  *** AaronvanW has quit IRC
213 2019-04-03T14:09:04  *** michaelfolkson has joined #bitcoin-core-dev
214 2019-04-03T14:13:44  *** michaelfolkson has quit IRC
215 2019-04-03T14:17:17  *** spinza has quit IRC
216 2019-04-03T14:28:21  *** Aaronvan_ has quit IRC
217 2019-04-03T14:35:19  *** pinheadmz has quit IRC
218 2019-04-03T15:00:26  *** spinza has joined #bitcoin-core-dev
219 2019-04-03T15:02:19  <jl2012> gmaxwell: "Miner block size removed" in the release note of 0.16.1 led to some misunderstanding in China
220 2019-04-03T15:02:44  <jl2012> some thought 0.16.1 was a block size hardfork
221 2019-04-03T15:05:32  <jl2012> but those were results from June 2018. No recent discussions
222 2019-04-03T15:06:07  <jl2012> and some people clarified that in Chinese at that time
223 2019-04-03T15:31:51  *** bitcoin-git has joined #bitcoin-core-dev
224 2019-04-03T15:31:51  <bitcoin-git> [bitcoin] promag opened pull request #15729: rpc: Ignore minconf parameter in getbalance (master...2019-04-drop-getbalance-minconf) https://github.com/bitcoin/bitcoin/pull/15729
225 2019-04-03T15:31:52  *** bitcoin-git has left #bitcoin-core-dev
226 2019-04-03T15:43:32  *** cheetah2 has joined #bitcoin-core-dev
227 2019-04-03T15:45:33  <cheetah2> im getting error code -28 prunning blockstore with bitcoin-cli getinfo does it mean its crashed or is it working?
228 2019-04-03T15:50:13  *** pinheadmz has joined #bitcoin-core-dev
229 2019-04-03T16:03:13  *** cheetah2 has quit IRC
230 2019-04-03T16:05:50  *** setpill has quit IRC
231 2019-04-03T16:09:30  *** AaronvanW has joined #bitcoin-core-dev
232 2019-04-03T16:10:04  *** bitcoin-git has joined #bitcoin-core-dev
233 2019-04-03T16:10:04  <bitcoin-git> [bitcoin] promag opened pull request #15730: rpc: Show scanning details in getwalletinfo (master...2019-04-getwalletinfo-scanning) https://github.com/bitcoin/bitcoin/pull/15730
234 2019-04-03T16:10:14  *** bitcoin-git has left #bitcoin-core-dev
235 2019-04-03T16:12:20  *** Aaronvan_ has joined #bitcoin-core-dev
236 2019-04-03T16:14:45  *** Aaronvan_ is now known as AaronvanW_
237 2019-04-03T16:15:27  *** Tralfaz has quit IRC
238 2019-04-03T16:15:42  *** AaronvanW has quit IRC
239 2019-04-03T16:20:14  *** bitcoin-git has joined #bitcoin-core-dev
240 2019-04-03T16:20:14  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2c364fde423e...ba54342c9dd3
241 2019-04-03T16:20:14  <bitcoin-git> bitcoin/master fa292ad MarcoFalke: doc: rpc-mining: Clarify error messages
242 2019-04-03T16:20:15  <bitcoin-git> bitcoin/master ba54342 MarcoFalke: Merge #15685: doc: rpc-mining: Clarify error messages
243 2019-04-03T16:20:16  *** bitcoin-git has left #bitcoin-core-dev
244 2019-04-03T16:20:45  *** joshmg has joined #bitcoin-core-dev
245 2019-04-03T16:21:04  *** bitcoin-git has joined #bitcoin-core-dev
246 2019-04-03T16:21:04  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15685: doc: rpc-mining: Clarify error messages (master...1903-docMining) https://github.com/bitcoin/bitcoin/pull/15685
247 2019-04-03T16:21:08  *** bitcoin-git has left #bitcoin-core-dev
248 2019-04-03T16:25:48  <MarcoFalke> proposedmeetingtopic: TODOs in 0.18.0 Release Notes Draft
249 2019-04-03T16:31:33  <MarcoFalke> [05:41] <wumpus> I think we also need to document the exact steps to update the various subtrees, there's some overlap with the "Subtrees" section in doc/developer-notes.md btw
250 2019-04-03T16:31:36  <MarcoFalke> fanquake:
251 2019-04-03T16:31:45  <MarcoFalke> Those exist in https://github.com/bitcoin/bitcoin/tree/ba54342c9dd3f2e5cdeed9ac57f1924f0d885cc6/test/lint#git-subtree-checksh
252 2019-04-03T16:31:51  <MarcoFalke> and https://github.com/bitcoin-core/bitcoin-maintainer-tools/tree/ae4ed2a58d67764dbfe2dc1ba00667659e330090#subtree-updates
253 2019-04-03T16:40:48  *** pinheadmz has quit IRC
254 2019-04-03T16:45:31  *** pinheadmz has joined #bitcoin-core-dev
255 2019-04-03T16:51:37  *** AaronvanW_ has quit IRC
256 2019-04-03T16:59:14  *** jarthur has joined #bitcoin-core-dev
257 2019-04-03T16:59:37  *** pinheadmz has quit IRC
258 2019-04-03T17:03:58  <instagibbs> the bitcoin-maintainer one is the more useful one IIRC
259 2019-04-03T17:05:43  *** jarthur has quit IRC
260 2019-04-03T17:06:10  *** jarthur has joined #bitcoin-core-dev
261 2019-04-03T17:17:42  *** jarthur has quit IRC
262 2019-04-03T17:18:09  *** jarthur has joined #bitcoin-core-dev
263 2019-04-03T17:21:37  *** jarthur has quit IRC
264 2019-04-03T17:22:04  *** jarthur has joined #bitcoin-core-dev
265 2019-04-03T17:22:36  <MarcoFalke> They serve different purposes. The "linter" is for checking and the maintainer-tool is for creating/bumping
266 2019-04-03T17:24:12  <cfields> jonasschnelli: not sure if you've discussed already, but it looks like you pushed your rc2 gitian sigs as rc3 accidentally.
267 2019-04-03T17:24:41  <cfields> Though your signature attached and verified correctly. So I assume you just pushed the wrong thing on accident.
268 2019-04-03T17:25:44  <cfields> err
269 2019-04-03T17:29:30  *** shesek has quit IRC
270 2019-04-03T17:36:23  <cfields> jonasschnelli: yes, ok, ^^.
271 2019-04-03T17:36:58  <cfields> I'm not going to worry about waiting for updated sigs, though. We have enough, and it looks like the correct thing was signed in the end.
272 2019-04-03T17:39:52  <cfields> gitian builders: detached sigs are pushed for v0.18.0rc3.
273 2019-04-03T17:42:07  *** Zenton has quit IRC
274 2019-04-03T17:46:19  *** morcos has quit IRC
275 2019-04-03T17:46:36  *** morcos has joined #bitcoin-core-dev
276 2019-04-03T17:53:30  *** pinheadmz has joined #bitcoin-core-dev
277 2019-04-03T17:54:29  *** ExtraCrispy has quit IRC
278 2019-04-03T17:54:59  *** ExtraCrispy has joined #bitcoin-core-dev
279 2019-04-03T17:59:06  *** pinheadmz has quit IRC
280 2019-04-03T18:00:26  *** pinheadmz has joined #bitcoin-core-dev
281 2019-04-03T18:07:17  <jonasschnelli> cfields: oh. let me check
282 2019-04-03T18:07:57  *** pinheadmz has quit IRC
283 2019-04-03T18:16:48  *** pinheadmz has joined #bitcoin-core-dev
284 2019-04-03T18:20:01  <jonasschnelli> cfields: yes. I uploaded the rc2 sigs for osx/win (not for linux though).
285 2019-04-03T18:20:07  <jonasschnelli> Will fix
286 2019-04-03T18:25:30  *** dviola has joined #bitcoin-core-dev
287 2019-04-03T18:39:02  *** hebasto has quit IRC
288 2019-04-03T18:41:30  *** d_t has joined #bitcoin-core-dev
289 2019-04-03T18:45:55  *** kexkey has joined #bitcoin-core-dev
290 2019-04-03T19:02:25  *** shesek has joined #bitcoin-core-dev
291 2019-04-03T19:02:25  *** shesek has joined #bitcoin-core-dev
292 2019-04-03T19:03:43  *** pinheadmz has joined #bitcoin-core-dev
293 2019-04-03T19:06:50  *** jarthur has quit IRC
294 2019-04-03T19:12:31  *** jtimon has joined #bitcoin-core-dev
295 2019-04-03T19:14:37  *** owowo has quit IRC
296 2019-04-03T19:18:30  *** beau has joined #bitcoin-core-dev
297 2019-04-03T19:19:42  *** owowo has joined #bitcoin-core-dev
298 2019-04-03T19:19:58  *** beau has quit IRC
299 2019-04-03T19:30:36  *** jarthur has joined #bitcoin-core-dev
300 2019-04-03T19:35:00  <wumpus> MarcoFalke: good to know, I think I knew about that one once but forgot about it
301 2019-04-03T19:45:57  *** Zenton has joined #bitcoin-core-dev
302 2019-04-03T19:52:10  *** mn9495881 has joined #bitcoin-core-dev
303 2019-04-03T20:04:55  *** EagleTM has joined #bitcoin-core-dev
304 2019-04-03T20:08:54  *** timothy has quit IRC
305 2019-04-03T20:49:07  *** Guyver2 has quit IRC
306 2019-04-03T21:17:25  *** DeanWeen has quit IRC
307 2019-04-03T21:40:56  *** bitcoin-git has joined #bitcoin-core-dev
308 2019-04-03T21:40:56  <bitcoin-git> [bitcoin] jamesob opened pull request #15735: Add scheduler deadlock detection (master...2019-04-serialize-scheduler) https://github.com/bitcoin/bitcoin/pull/15735
309 2019-04-03T21:40:57  *** bitcoin-git has left #bitcoin-core-dev
310 2019-04-03T21:43:52  <gmaxwell> jl2012: there isn't a chinese version of bitcoin.org or something that only shows old links?  I'm just at a loss as to what would be causing people to start new nodes using old code.
311 2019-04-03T21:45:42  *** pinheadmz has quit IRC
312 2019-04-03T21:48:35  *** pinheadmz has joined #bitcoin-core-dev
313 2019-04-03T21:49:58  <phantomcircuit> gmaxwell, are they all on aws or something?
314 2019-04-03T21:50:11  <midnightmagic> gmaxwell: the TMSR people and their propaganda maybe?
315 2019-04-03T21:51:07  *** AaronvanW has joined #bitcoin-core-dev
316 2019-04-03T21:52:53  <gwillen> sipa or someone: are descriptors supposed to accept "h" anywhere they would accept "'"?
317 2019-04-03T21:53:06  <gwillen> gmaxwell: ^
318 2019-04-03T21:54:29  <gwillen> it seems like maybe there is an untested interaction with checksums
319 2019-04-03T21:54:42  <gwillen> I am finding that my descriptors with 'h' are being parsed as invalid
320 2019-04-03T21:55:17  <gwillen> if I getdescriptorinfo on a descriptor that uses 'h', I get back one that uses "'" and has a valid checksum, but if I then replace the ' with h and keep the checksum the same, the resulting descriptor is rejected
321 2019-04-03T21:56:09  <sipa> gwillen: yes, you can use either h or '
322 2019-04-03T21:56:16  <sipa> and the checksum will depend on which one you use
323 2019-04-03T21:56:19  <gwillen> hmmmmmm
324 2019-04-03T21:56:36  <gwillen> but getdescriptorinfo canonicalizes from "h" to "'" _before_ computing the checksum
325 2019-04-03T21:56:40  <gwillen> so I can't get one with h :-)
326 2019-04-03T21:56:49  <sipa> yes
327 2019-04-03T21:56:51  <gwillen> also it seems weird that they are treated differently, I would argue against that but maybe it's too late
328 2019-04-03T21:56:53  *** shtirlic has quit IRC
329 2019-04-03T21:57:14  <sipa> gwillen: the alternative would require a checksum algorithm that's not black box
330 2019-04-03T21:57:35  <gwillen> it would just require that you always canonicalize before checksumming
331 2019-04-03T21:57:44  <gwillen> since it seems like the very first thing you do on parsing is canonicalize anyway
332 2019-04-03T21:58:01  <sipa> canonicalizing requiring understand the descriptors
333 2019-04-03T21:58:19  <sipa> while checksums can hopefully be performed by things that treat descriptors as strings
334 2019-04-03T21:58:38  <sipa> it was probably a mistake to permit both h and ' in the first place, but it's far too late for that
335 2019-04-03T21:58:43  <gwillen> this is somewhat sad for dev use, because the primary use of 'h' is not having to quote the apostrophe
336 2019-04-03T21:58:51  <gwillen> but there is no easy way to get a checksum on a descriptor that uses h
337 2019-04-03T21:58:57  <sipa> ah i see
338 2019-04-03T21:58:57  <gwillen> so in practice you always have to use the apostrophe
339 2019-04-03T21:59:06  <gwillen> which defeats the purpose of h existting
340 2019-04-03T21:59:27  *** joshmg has quit IRC
341 2019-04-03T21:59:52  <sipa> well you don't have to use getdescriptorinfo
342 2019-04-03T22:00:08  <gwillen> is there an RPC that will checksum a descriptor for me without altering it first
343 2019-04-03T22:00:22  <sipa> not an RPC, but there is python code for it
344 2019-04-03T22:00:44  <gwillen> can I argue for getdescriptorinfo not to alter the descriptor provided
345 2019-04-03T22:00:51  <gwillen> (is there any other issue like this aside from h/'?)
346 2019-04-03T22:01:16  <sipa> if you include a private key in the descriptor, the canonical version will drop it
347 2019-04-03T22:01:18  *** shtirlic has joined #bitcoin-core-dev
348 2019-04-03T22:01:41  <sipa> because that's just syntactic sugar for the public version + simultaneously also conveying the private key
349 2019-04-03T22:01:53  <gwillen> except again for the checksum caring about the difference
350 2019-04-03T22:02:02  <sipa> yes
351 2019-04-03T22:03:28  <gwillen> I am heavily tempted to disable descriptor checksums locally while I'm doing development to make this more usable
352 2019-04-03T22:03:31  <gwillen> that is not a good sign :-P
353 2019-04-03T22:04:33  <sipa> it wouldn't be hard to add an RPC that just adds the checksum, but otherwise leaves the descriptor untouched
354 2019-04-03T22:05:12  <sipa> would that help?
355 2019-04-03T22:05:15  <gwillen> that would be helpful, but I also wonder if getdescriptorinfo really needs to canonicalize the descriptor
356 2019-04-03T22:05:18  <gwillen> but either one would do, yeah
357 2019-04-03T22:05:29  <gwillen> although I'm now building with descriptor checksums disabled anyway, since it was a one-line change
358 2019-04-03T22:05:34  <sipa> agree, perhaps it doesn't need to in the first place
359 2019-04-03T22:05:38  <gwillen> *nods*
360 2019-04-03T22:06:27  <gwillen> if the canonical version were 'h' rather than "'", it wouldn't require parsing to checksum the canonical version, since "'" can't appear anywhere else as far as I know
361 2019-04-03T22:06:43  <gwillen> (but this doesn't solve private keys, and also it's surely too late.)
362 2019-04-03T22:09:01  <sipa> a side effect of having the checksum depend on the exact string representation also means that 'canonical' version doesn't mean much
363 2019-04-03T22:09:16  <sipa> we could change the canonical encoding without breaking anything
364 2019-04-03T22:09:35  <gwillen> certainly h is easier to work with than "'"
365 2019-04-03T22:09:47  <gwillen> I don't know if it has any downsides I'm not thinking of
366 2019-04-03T22:10:37  <sipa> the ' notation is more widespread
367 2019-04-03T22:10:58  <gmaxwell> I don't think the rpc turning ' into h would be a problem. It does need to accept ' in inputs, of course.
368 2019-04-03T22:11:17  <gwillen> yeah, it should absolutely still accept both
369 2019-04-03T22:11:20  <gwillen> right now it turns h into '
370 2019-04-03T22:11:40  <sipa> wouldn't be hard to make it not touch it as well
371 2019-04-03T22:12:05  <gwillen> hm, I just did a ranged descriptor import with a range of 10,000
372 2019-04-03T22:12:08  <gwillen> and it seems to have hung
373 2019-04-03T22:12:20  <gwillen> it's been 120 seconds
374 2019-04-03T22:12:32  <achow101> I think having the canonical one be 'h' would be better
375 2019-04-03T22:12:33  <sipa> is it rescanning?
376 2019-04-03T22:12:46  <gwillen> I used {"rescan": false}
377 2019-04-03T22:12:53  <sipa> that's ungood
378 2019-04-03T22:13:03  <gwillen> I will attach a debugger
379 2019-04-03T22:13:07  <achow101> also having getdescriptorinfo give the checksum for descriptors with privkeys too
380 2019-04-03T22:14:40  <achow101> gwillen: I think that is not unexpected
381 2019-04-03T22:14:46  <gwillen> no?
382 2019-04-03T22:15:09  <achow101> IIRC it writes each generated key and key origin data independently without batching (I know, bad idea), so it takes a while due to disk I/O
383 2019-04-03T22:15:20  <gwillen> I mean, awhile is awhile, but it's now been like 5 minutes
384 2019-04-03T22:15:25  <gwillen> that is a long while to perform 10,000 writes
385 2019-04-03T22:15:35  <gwillen> and the gui thread is totally dead now
386 2019-04-03T22:15:45  <gwillen> before the GUI was responding but the console wasn't answering RPCs
387 2019-04-03T22:16:18  <achow101> hmm, that might be hung and not just taking awhile
388 2019-04-03T22:17:25  <gwillen> we are inside CWallet::CanGetAddresses
389 2019-04-03T22:18:11  <achow101> gwillen: oh, deadlock?
390 2019-04-03T22:18:26  <gwillen> oh, maybe, yeah, we're trying to lock a mutex
391 2019-04-03T22:18:29  <achow101> the gui thread probably went into cangetaddresses but can't acquire the lock so it
392 2019-04-03T22:18:43  <sipa> gwillen: is this 0.18/master or something with changes by you?
393 2019-04-03T22:18:44  <achow101> as the lock is held by the rpc thread for import
394 2019-04-03T22:18:53  <gwillen> sipa: changes by me
395 2019-04-03T22:19:20  <gwillen> not to any of this though I would expect?
396 2019-04-03T22:20:19  <gwillen> it looks like we may indeed be deadlocked trying to take cs_wallet at the top of CanGetAddresses
397 2019-04-03T22:20:49  <gmaxwell> What lock would be held before cs_wallet in the call path to CanGetAddresses?  can you get a backtrace?
398 2019-04-03T22:21:01  <gmaxwell> (so we can figure out what the other lock involved in the inversion is?)
399 2019-04-03T22:21:06  <sipa> gwillen: compile with -DDEBUG_LOCKORDER
400 2019-04-03T22:21:10  <sipa> and try to reproduce
401 2019-04-03T22:21:17  <gmaxwell> I wonder if essentially anyone has used the GUI with -DDEBUG_LOCKORDER ?
402 2019-04-03T22:21:21  <gwillen> let me paste the backtrace first for gmaxwell
403 2019-04-03T22:21:25  <gwillen> I will try with debug_lockorder next
404 2019-04-03T22:21:42  <sipa> oh, the stack trace (for all threads) should actually tell you just as much
405 2019-04-03T22:21:55  <gwillen> there are a lot of threads, how do I backtrace threads in bulk in lldb
406 2019-04-03T22:21:59  <gmaxwell> thread apply all bt
407 2019-04-03T22:22:11  <gmaxwell> works in gdb, I assume lldb too
408 2019-04-03T22:22:19  <gwillen> sadly it does not work in lldb
409 2019-04-03T22:22:24  <gwillen> and I cannot gdb because mac
410 2019-04-03T22:22:33  <sipa> sadness
411 2019-04-03T22:22:47  <gmaxwell> thread backtrace all
412 2019-04-03T22:22:48  <gmaxwell> bt all
413 2019-04-03T22:22:54  <gwillen> aha
414 2019-04-03T22:22:56  <gmaxwell> ^ lldb commands.
415 2019-04-03T22:24:13  *** shtirlic has quit IRC
416 2019-04-03T22:24:42  <achow101> gwillen: can you check if your wallet file is being modified?
417 2019-04-03T22:25:08  <gmaxwell> (being modified while not paused in the debugger)
418 2019-04-03T22:25:59  <gmaxwell> GUI hanging in CanGetAddresses doesn't itself imply that there is a deadlock there. e.g. it could just be waiting on a lock that is deadlocked elsewhere, or not even locked but absurdly slow.
419 2019-04-03T22:26:08  <gwillen> hm yes, it is being modified
420 2019-04-03T22:26:21  <gwillen> it is growing.
421 2019-04-03T22:26:24  <achow101> gmaxwell: I'm pretty sure it's hanging in CanGetAddresses because cs_wallet is locked by the inport, which CanGetAddresses needs to acquire
422 2019-04-03T22:26:33  <gwillen> it's quite large.
423 2019-04-03T22:26:40  <achow101> no shit. that's 10000 keys
424 2019-04-03T22:26:50  <gwillen> how big is a key?
425 2019-04-03T22:27:13  <gwillen> this seems like support for "not even locked but absurdly slow"
426 2019-04-03T22:27:20  <gmaxwell> I was about to say that.
427 2019-04-03T22:27:28  <achow101> 33 bytes + keyid a few times + metadata. probably like 80 bytes at least
428 2019-04-03T22:27:33  <gmaxwell> key records are on the order of 100 bytes I think.
429 2019-04-03T22:28:05  <achow101> i'm testing this locally. it looks like it spends a while on key derivation also
430 2019-04-03T22:28:16  <gwillen> does it also duplicate full key origin info for each?
431 2019-04-03T22:28:20  <gwillen> that would make it bigger.
432 2019-04-03T22:28:23  <achow101> yes
433 2019-04-03T22:28:29  <gwillen> we're at 4 megs and growing
434 2019-04-03T22:28:36  <achow101> not unexpected
435 2019-04-03T22:28:36  <gwillen> so it's definitely more than 80 bytes per.
436 2019-04-03T22:28:47  <sipa> key entry + metqdata entry + keypool entry if applicable
437 2019-04-03T22:28:49  <sipa> for each
438 2019-04-03T22:29:11  <gwillen> I considered picking a more realistic number than 10,000, fwiw, I have no actual need for this to work
439 2019-04-03T22:29:17  <sipa> also, uncompresed wallet?
440 2019-04-03T22:29:19  <gwillen> I typed it mostly on a lark because computers are fast
441 2019-04-03T22:29:28  <sipa> in that case private keys are 270 bytes
442 2019-04-03T22:29:28  <gwillen> hm, I don't know, whatever the default is for a new wallet
443 2019-04-03T22:29:31  <gmaxwell> well it should be fast this is a bug.
444 2019-04-03T22:29:40  *** jarthur has quit IRC
445 2019-04-03T22:30:05  <gmaxwell> I mean if you said it took a couple seconds, sure whatever, who cares.
446 2019-04-03T22:30:29  <gwillen> yeah
447 2019-04-03T22:30:47  <achow101> I just tested it. it took 6 minutes for my machine to do an import of a ranged descriptor for 10000 keys
448 2019-04-03T22:30:52  <gwillen> I should clearly go into QA
449 2019-04-03T22:31:01  <gwillen> given my ability to provoke software to do stupid shit ;-)
450 2019-04-03T22:33:00  <gwillen> filed #15739
451 2019-04-03T22:33:01  <gribble> https://github.com/bitcoin/bitcoin/issues/15739 | large ranged descriptor imports are sloooooooooow. · Issue #15739 · bitcoin/bitcoin · GitHub
452 2019-04-03T22:33:34  <gmaxwell> I'm gussing it's doing something stupid like opening and closing the wallet for each key.
453 2019-04-03T22:33:50  <achow101> gmaxwell: it's not using a batch write. using a batch write should speed it up significantly
454 2019-04-03T22:34:06  <sipa> gwillen: it absolutely is doing that
455 2019-04-03T22:34:06  <gwillen> even opening and closing the wallet 10,000 times shouldn't take 6 minutes, should it?
456 2019-04-03T22:34:21  <sipa> are you on an I/O starved VPS? :p
457 2019-04-03T22:34:26  <gmaxwell> gwillen: it writes and fsyncs each time.
458 2019-04-03T22:34:32  <gwillen> I guess if every time it opens it, it scans and validates a bunch of things, fires a bunch of notifications, etc. etc.
459 2019-04-03T22:34:36  <gmaxwell> and on mac there is no file-centric fsync.
460 2019-04-03T22:34:40  <achow101> working on fix
461 2019-04-03T22:34:55  *** joshmg has joined #bitcoin-core-dev
462 2019-04-03T22:35:28  *** joshmg has quit IRC
463 2019-04-03T22:35:52  <sipa> achow101: nice
464 2019-04-03T22:36:32  <sipa> i guess some of the wallet encryption logic can be used to avoid opening/closing the db every time?
465 2019-04-03T22:36:53  <gwillen> will my testnet wallet get rekt if I murder this process in the middle of whatever it's doing
466 2019-04-03T22:37:02  <gmaxwell> We had this same problem with the original wallet creation at one point, IIRC
467 2019-04-03T22:37:35  <gwillen> sipa: what's the deal with wallet compression, is it an option?
468 2019-04-03T22:38:51  *** shtirlic has joined #bitcoin-core-dev
469 2019-04-03T22:39:47  <sipa> gwillen: if you never encrypted the wallet it's unencrypted
470 2019-04-03T22:40:19  <gwillen> erm, you said compression before, but this time you said encryption
471 2019-04-03T22:40:35  <sipa> i meant encrypted :)
472 2019-04-03T22:40:45  <gwillen> oh, heh
473 2019-04-03T22:40:49  <gwillen> does encryption also compress
474 2019-04-03T22:40:49  * sipa falls asleep
475 2019-04-03T22:41:01  <gwillen> or is this not actually relevant to the problem of walletfile being huge
476 2019-04-03T22:41:17  <gwillen> you said something about 270 bytes per key
477 2019-04-03T22:41:39  <gwillen> I would have assumed default compression, especially if we're repeating mostly-redundant key origin info for every key
478 2019-04-03T22:41:46  <gwillen> that should be extremely compressible
479 2019-04-03T22:42:07  <gwillen> my wallet has reached 8.5 megs
480 2019-04-03T22:42:13  *** spinza has quit IRC
481 2019-04-03T22:42:59  <sipa> gwillen: the old unencrypted wallet format stores private keys in a ricldiculous der encoded format of 279 bytes per key
482 2019-04-03T22:43:06  <sipa> where only 32 bytes are needed
483 2019-04-03T22:43:20  <gwillen> ah, well this wallet should be relatively new, like within the last few months
484 2019-04-03T22:43:27  <sipa> not relevant
485 2019-04-03T22:43:45  <sipa> the encoding used for unencrypted keys is still that der one
486 2019-04-03T22:43:48  <gwillen> also this is watchonly so there are no private keys anyway
487 2019-04-03T22:43:53  <sipa> oh!
488 2019-04-03T22:43:59  <sipa> then this is all irrelevant
489 2019-04-03T22:44:15  <gwillen> so presumably all that space is being taken up by key origin info and other metadata
490 2019-04-03T22:44:37  <gwillen> although that's still more than 1kb per key, which seems huge
491 2019-04-03T22:44:54  <gwillen> achow101: how large did your wallet get after you spent 6 minutes importing 10,000 keys
492 2019-04-03T22:45:10  <sipa> gwillen: doesn't surprise me
493 2019-04-03T22:45:39  <achow101> gwillen: 8 MB, but I also did it again and now it's 16 MB
494 2019-04-03T22:45:40  *** Randolf has joined #bitcoin-core-dev
495 2019-04-03T22:45:48  <gwillen> heh
496 2019-04-03T22:45:52  <gwillen> so mine was almost done probably
497 2019-04-03T22:47:19  <gwillen> doing 100 takes 3 seconds on my machine, so 10000 would have taken about 5 minutes to finish
498 2019-04-03T22:55:12  *** spinza has joined #bitcoin-core-dev
499 2019-04-03T23:06:56  <achow101> well batching writes reduced that from 6:56 to 1:24
500 2019-04-03T23:08:41  <gwillen> ha
501 2019-04-03T23:18:17  *** bitcoin-git has joined #bitcoin-core-dev
502 2019-04-03T23:18:17  <bitcoin-git> [bitcoin] achow101 opened pull request #15741: Batch write imported stuff in importmulti (master...batch-write-importmulti) https://github.com/bitcoin/bitcoin/pull/15741
503 2019-04-03T23:18:22  *** bitcoin-git has left #bitcoin-core-dev
504 2019-04-03T23:18:25  <achow101> gwillen: ^^
505 2019-04-03T23:19:07  *** AaronvanW has quit IRC
506 2019-04-03T23:21:18  <gwillen> :+1: will review!
507 2019-04-03T23:27:01  <gwillen> achow101: is this kind of manual batching typical of using WalletBatch? I wonder if it would make sense to have a self-flushing WalletWriteCache or something
508 2019-04-03T23:27:13  <gwillen> to avoid having to have all the fiddly counting of entries
509 2019-04-03T23:28:18  *** EagleTM has quit IRC
510 2019-04-03T23:28:33  <achow101> gwillen: we do something similar for initial key generation
511 2019-04-03T23:28:56  <achow101> i was mostly following upgradekeymetadata (aka copy paste) which does counting
512 2019-04-03T23:30:06  <gwillen> would be good to factor it out nicely ;-)
513 2019-04-03T23:30:32  *** Randolf has quit IRC
514 2019-04-03T23:32:17  *** EagleTM has joined #bitcoin-core-dev
515 2019-04-03T23:34:33  *** dviola has quit IRC
516 2019-04-03T23:39:53  *** d_t has quit IRC
517 2019-04-03T23:46:30  *** bitcoin-git has joined #bitcoin-core-dev
518 2019-04-03T23:46:30  <bitcoin-git> [bitcoin] kallewoof closed pull request #13746: -masterdatadir for datadir bootstrapping (master...masterdatadir) https://github.com/bitcoin/bitcoin/pull/13746
519 2019-04-03T23:46:32  *** bitcoin-git has left #bitcoin-core-dev
520 2019-04-03T23:47:50  *** dqx_ has quit IRC
521 2019-04-03T23:50:21  *** fanquake has quit IRC
522 2019-04-03T23:58:11  *** DeanWeen has joined #bitcoin-core-dev
523 2019-04-03T23:59:37  *** DeanWeen is now known as DeanGuss