1 2019-01-10T00:02:16  *** michaelsdunn1 has quit IRC
  2 2019-01-10T00:02:42  *** Murch has quit IRC
  3 2019-01-10T00:06:56  *** aqquadro has quit IRC
  4 2019-01-10T00:07:26  <phantomcircuit> gmaxwell, wait they cancel a invoice if the transaction reaches them over the network first?
  5 2019-01-10T00:07:48  *** Giszmo has quit IRC
  6 2019-01-10T00:07:49  <gmaxwell> Yes, they did to me and other people at the time were reporting it too.
  7 2019-01-10T00:07:56  <gmaxwell> Maybe they since stopped? if so then I'm out of date.
  8 2019-01-10T00:08:07  <phantomcircuit> that's crazy
  9 2019-01-10T00:08:50  *** Giszmo has joined #bitcoin-core-dev
 10 2019-01-10T00:09:06  <echeveria> phantomcircuit: they want to be able to selectively abort client payments.
 11 2019-01-10T00:09:46  <echeveria> this is doable if they really wanted to within another protocol, but would need to have the client doing partial signatures, and them filling validity with another signature of their own input to the payment.
 12 2019-01-10T00:10:36  <gmaxwell> BIP70 could have been defined that way, varrious people advocated for it.
 13 2019-01-10T00:11:01  <gmaxwell> But doing that correctly is harder for the wallet, since it needs to track UTXO as 'I signed for this, but it hasn't been broadcast yet'.
 14 2019-01-10T00:11:21  <gmaxwell> At the time BIP70 was written, the only 'used' metric bitcoin core really had was "spent by the mempool"
 15 2019-01-10T00:11:34  <luke-jr> maybe someone should get this in the Bustapay stuff
 16 2019-01-10T00:11:52  <phantomcircuit> echeveria, oooh
 17 2019-01-10T00:12:02  <phantomcircuit> they want to be able to blacklist utxo entries
 18 2019-01-10T00:12:03  <phantomcircuit> got it
 19 2019-01-10T00:12:37  <echeveria> gmaxwell: I don't think it's very user friendly to have that as a system though. you end up with ambiguity, I've paid someone with this output, and they may actually spend it sometime in the future, or not.
 20 2019-01-10T00:13:34  <luke-jr> if you're not careful, it locks your change too
 21 2019-01-10T00:13:39  <echeveria> I guess have a timeout in the script that means your partial signature is only valid for x hours or something, but even so. with most wallets tending towards having absolutely no logic in them this seems like a non-starter.
 22 2019-01-10T00:13:59  <luke-jr> echeveria: Bitcoin intentionally doesn't support such timeouts
 23 2019-01-10T00:15:06  <gmaxwell> you 'time it out' by double spending it.
 24 2019-01-10T00:15:22  *** promag has joined #bitcoin-core-dev
 25 2019-01-10T00:15:36  <gmaxwell> What I think the wallet should do is track pending spends, and eventually intentionally double spend them if they 'timeout'
 26 2019-01-10T00:15:45  *** promag has quit IRC
 27 2019-01-10T00:15:53  <gmaxwell> probably by just including them in a future transaction post timeout.
 28 2019-01-10T00:16:13  <gmaxwell> and also show a 'pending balance', so it's clear that a wallet with pending spends isn't 'empty'
 29 2019-01-10T00:16:39  <gmaxwell> But... yea, it's a non-zero amount of work.
 30 2019-01-10T00:16:48  <luke-jr> especially when you consider Lightning, I bet :p
 31 2019-01-10T00:17:04  <gmaxwell> But what bitpay wants people to do is just busted.
 32 2019-01-10T00:17:28  <gmaxwell> like they want to be able to say 'payment rejected, try again with more fee'  but then no effort at all to doublespend the prior payments.
 33 2019-01-10T00:17:39  <gmaxwell> and no indication in the wallet that you've potentially double paid them.
 34 2019-01-10T00:17:57  <luke-jr> those seem like wallet-side decisions
 35 2019-01-10T00:18:06  <gmaxwell> so days, months, or even years later,  you might have a whole bunch of bitpay payments go through twice..
 36 2019-01-10T00:18:33  <gmaxwell> They are but they need to be part of any BIP70 alternative that doesn't immediately broadcast txn.
 37 2019-01-10T00:18:55  <gmaxwell> As in the spec needs to advise sensible behavior, and wallets _must_ implement somethign sensible or they create security vulnerabilities.
 38 2019-01-10T00:19:24  <gmaxwell> at a minimum if a payment is rejected and needs to be reissued, the wallet must doublespend the original one.
 39 2019-01-10T00:20:48  <gmaxwell> (and since there is bidi communication, there is really no reason that a request couldn't be rejected before a signed copy is even sent... but thats another matter)
 40 2019-01-10T00:20:52  <echeveria> and handle when someone refuses to do the double spend with their hardware wallet.
 41 2019-01-10T00:21:26  <gmaxwell> the double spend can at least be avoided all togeather in the common case.
 42 2019-01-10T00:21:40  <gmaxwell> echeveria: right or with a third party anti-doublespend signer.
 43 2019-01-10T00:22:24  *** jarthur has quit IRC
 44 2019-01-10T00:22:32  <echeveria> ends up being a rather unfortunate amount of logic in the wallet.
 45 2019-01-10T00:23:02  *** promag has joined #bitcoin-core-dev
 46 2019-01-10T00:23:05  <gmaxwell> right and a bunch of it is tricky, which is why I think it's important that a spec that makes you do this tricky thing at least warn you about the stuff you need to consider.
 47 2019-01-10T00:23:46  <gmaxwell> otherwise it would be like a ecdsa spec that just said nothing about where you're supposted to get this nonce value. "Nonce? that means used once. I'll just use a counter."
 48 2019-01-10T00:29:44  <ap4lmtree-> any of you take free online classes, such as through coursera ?
 49 2019-01-10T00:30:19  <ap4lmtree-> they have some cs and every other field courses
 50 2019-01-10T00:38:05  *** hebasto has quit IRC
 51 2019-01-10T00:46:09  <gwillen> ap4lmtree-: not sure how on-topic this is here, but fwiw the Coursera Crypto I class by Dan Boneh is very good
 52 2019-01-10T00:46:45  <phantomcircuit> wumpus, btw i dont have fuzzing.tar.xz anywhere so that can definitely be removed
 53 2019-01-10T00:49:13  *** DeanGuss has joined #bitcoin-core-dev
 54 2019-01-10T01:00:18  <phantomcircuit> gmaxwell, the idea that the remote end is going to reject a payment is crazy town
 55 2019-01-10T01:01:16  <gmaxwell> phantomcircuit: I don't think it is? like at least it's not unreasonable for the remote end to ignore your unconfirmed payment unless it has some minimum feerate.
 56 2019-01-10T01:03:53  <phantomcircuit> gmaxwell, it's not unreasonable to ignore you until it confirms
 57 2019-01-10T01:03:55  <phantomcircuit> then what
 58 2019-01-10T01:04:26  <gmaxwell> right, sure, but assuming you wanted it to not be ignored until them, you would have appricated the oppturnity to make a different txn.
 59 2019-01-10T01:07:17  *** justan0theruser has joined #bitcoin-core-dev
 60 2019-01-10T01:07:37  *** spaced0ut has quit IRC
 61 2019-01-10T01:07:47  *** justanotheruser has quit IRC
 62 2019-01-10T01:07:58  <phantomcircuit> gmaxwell, i guess what im saying is that rejecting an unsigned transaction makes sense, but rejecting one that's signed and broadcast?
 63 2019-01-10T01:08:05  <phantomcircuit> once it's confirmed it's confirmed
 64 2019-01-10T01:08:40  *** pinheadmz has quit IRC
 65 2019-01-10T01:08:57  <gmaxwell> well thats why they want you to submit the transaction directly instead of broadcasting.
 66 2019-01-10T01:11:58  <phantomcircuit> but it's signed why should you trust them not to broadcast it themselves
 67 2019-01-10T01:12:54  <gmaxwell> You shouldn't. They might. Which is why you need to handle it correctly.
 68 2019-01-10T01:13:21  <gmaxwell> E.g. if they reject it and your response is to resign e.g. with more fee, you need to make sure you doublespend it... e.g. same as if you'd feebumped in the UI.
 69 2019-01-10T01:13:55  <gmaxwell> which sounds obnoxious, but its not bad considering that feebumping is already an existing and pretty desirable feature.
 70 2019-01-10T01:15:00  <phantomcircuit> gmaxwell, it seems more like you want a list of "payments im trying to make" and have the wallet ensure any new transaction invalidates anything that doesn't pay to that set
 71 2019-01-10T01:15:59  <gmaxwell> Maybe, though you don't really want to invalidate a payment that the recipent is already trying to CPFP unless asked to do so.
 72 2019-01-10T01:16:42  <wumpus> phantomcircuit: no problem, that whole section can be removed, the fuzzing corpus is going to move to a separate repository
 73 2019-01-10T01:19:56  <wumpus> gkrizek: there's not that much configuration; server is chat.freenode.net port is 6697, room is "#bitcoin-commits,#bitcoin-core-dev", nick is "bitcoin-git", branches is "master,0.11,0.12,0.13,0.14,0.15,0.16,0.17"
 74 2019-01-10T01:20:35  <wumpus> gkrizek: password and nickserv password is not filled in, Ssl is checked, Long url is checked, the other checkboxes are not
 75 2019-01-10T01:25:48  *** promag has quit IRC
 76 2019-01-10T01:26:18  <ap4lmtree-> gmaxwell, okay ill check it out
 77 2019-01-10T01:29:00  *** gekisai has quit IRC
 78 2019-01-10T01:29:42  *** gekisai has joined #bitcoin-core-dev
 79 2019-01-10T01:34:02  *** gekisai has quit IRC
 80 2019-01-10T01:35:10  *** gekisai has joined #bitcoin-core-dev
 81 2019-01-10T01:37:35  *** DeanGuss has quit IRC
 82 2019-01-10T01:42:45  *** jarthur has joined #bitcoin-core-dev
 83 2019-01-10T01:46:11  *** gekisai has quit IRC
 84 2019-01-10T01:46:26  *** fanquake has quit IRC
 85 2019-01-10T01:48:21  *** miknotauro has quit IRC
 86 2019-01-10T01:58:25  *** gekisai has joined #bitcoin-core-dev
 87 2019-01-10T02:02:04  *** gkrizek has quit IRC
 88 2019-01-10T02:03:14  *** gekisai has quit IRC
 89 2019-01-10T02:03:37  *** Zenton has quit IRC
 90 2019-01-10T02:03:46  *** Zenton has joined #bitcoin-core-dev
 91 2019-01-10T02:05:40  *** achow101 has quit IRC
 92 2019-01-10T02:08:54  *** gekisai has joined #bitcoin-core-dev
 93 2019-01-10T02:08:55  *** fanquake has joined #bitcoin-core-dev
 94 2019-01-10T02:13:07  *** gekisai has quit IRC
 95 2019-01-10T02:16:16  *** achow101 has joined #bitcoin-core-dev
 96 2019-01-10T02:17:06  *** gkrizek has joined #bitcoin-core-dev
 97 2019-01-10T02:19:16  <gkrizek> wumpus: Ok, thanks! Are we cool with keeping that the same?  Send a message when pushes happen to those branches and when PRs are open/closed/merged/reopened? I can add or remove whatever we want
 98 2019-01-10T02:20:55  *** gkrizek has quit IRC
 99 2019-01-10T02:21:14  *** gkrizek has joined #bitcoin-core-dev
100 2019-01-10T02:23:23  *** gekisai has joined #bitcoin-core-dev
101 2019-01-10T02:38:32  *** fanquake has quit IRC
102 2019-01-10T03:10:20  *** Giszmo has quit IRC
103 2019-01-10T03:28:23  *** Giszmo has joined #bitcoin-core-dev
104 2019-01-10T03:42:36  *** ap4lmtree- is now known as ap4lmtree
105 2019-01-10T03:44:06  *** ddustin has quit IRC
106 2019-01-10T03:45:05  *** rhavar_ has joined #bitcoin-core-dev
107 2019-01-10T03:54:27  *** justan0theruser is now known as justanotheruser
108 2019-01-10T04:38:11  *** midnightmagic has quit IRC
109 2019-01-10T04:39:06  *** grubles__ is now known as grubles
110 2019-01-10T04:41:42  *** gekisai has quit IRC
111 2019-01-10T04:49:47  *** midnightmagic has joined #bitcoin-core-dev
112 2019-01-10T04:50:47  *** DougieBot5000_ has joined #bitcoin-core-dev
113 2019-01-10T04:53:56  *** DougieBot5000 has quit IRC
114 2019-01-10T05:45:22  *** zenogais has quit IRC
115 2019-01-10T06:12:52  *** Victorsueca has quit IRC
116 2019-01-10T06:17:13  *** Victorsueca has joined #bitcoin-core-dev
117 2019-01-10T06:19:52  *** midnightmagic has quit IRC
118 2019-01-10T06:33:57  *** midnightmagic has joined #bitcoin-core-dev
119 2019-01-10T06:47:25  *** pinheadmz has joined #bitcoin-core-dev
120 2019-01-10T07:06:01  *** pinheadmz has quit IRC
121 2019-01-10T07:09:37  *** DougieBot5000_ is now known as DougieBot5000
122 2019-01-10T07:16:01  *** EagleTM has joined #bitcoin-core-dev
123 2019-01-10T07:20:34  *** EagleTM has quit IRC
124 2019-01-10T07:33:28  *** hebasto has joined #bitcoin-core-dev
125 2019-01-10T07:33:57  *** pinheadmz has joined #bitcoin-core-dev
126 2019-01-10T07:34:17  *** miknotauro has joined #bitcoin-core-dev
127 2019-01-10T08:18:15  *** jungly has joined #bitcoin-core-dev
128 2019-01-10T08:48:13  *** jarthur has quit IRC
129 2019-01-10T08:52:21  *** pinheadmz has quit IRC
130 2019-01-10T08:54:22  *** rhavar_ has quit IRC
131 2019-01-10T09:09:08  *** setpill has joined #bitcoin-core-dev
132 2019-01-10T09:12:28  *** Guyver2 has joined #bitcoin-core-dev
133 2019-01-10T09:20:39  *** promag has joined #bitcoin-core-dev
134 2019-01-10T09:28:14  *** aqquadro has joined #bitcoin-core-dev
135 2019-01-10T09:46:31  *** gekisai has joined #bitcoin-core-dev
136 2019-01-10T09:46:33  *** promag has quit IRC
137 2019-01-10T09:51:03  *** gekisai has quit IRC
138 2019-01-10T09:52:19  *** newbie111 has joined #bitcoin-core-dev
139 2019-01-10T09:52:58  <newbie111> hi ALL
140 2019-01-10T09:54:05  *** gekisai has joined #bitcoin-core-dev
141 2019-01-10T09:54:28  *** newbie111 has quit IRC
142 2019-01-10T10:02:35  *** AaronvanW has joined #bitcoin-core-dev
143 2019-01-10T10:06:53  *** Aaronvan_ has joined #bitcoin-core-dev
144 2019-01-10T10:07:12  *** spinza has quit IRC
145 2019-01-10T10:07:14  *** Aaronvan_ has quit IRC
146 2019-01-10T10:08:50  *** AaronvanW has quit IRC
147 2019-01-10T10:12:54  *** elichai2 has joined #bitcoin-core-dev
148 2019-01-10T10:21:58  *** timothy has joined #bitcoin-core-dev
149 2019-01-10T10:27:19  *** AaronvanW has joined #bitcoin-core-dev
150 2019-01-10T10:29:43  *** Aaronvan_ has joined #bitcoin-core-dev
151 2019-01-10T10:33:04  *** AaronvanW has quit IRC
152 2019-01-10T10:34:01  *** rh0nj has quit IRC
153 2019-01-10T10:34:22  *** spinza has joined #bitcoin-core-dev
154 2019-01-10T10:35:08  *** rh0nj has joined #bitcoin-core-dev
155 2019-01-10T10:36:44  <meshcollider> gkrizek: we dont need branches 0.11, 0.12 or 0.13 anymore btw, only 14+
156 2019-01-10T10:55:10  <wumpus> good point, I cleaned up those branches to keep the number of branches from getting out of hand, as there's no active development expected on them anymore
157 2019-01-10T10:59:40  *** promag has joined #bitcoin-core-dev
158 2019-01-10T11:05:37  *** gekisai has quit IRC
159 2019-01-10T11:07:20  *** wolfspraul has quit IRC
160 2019-01-10T11:08:07  *** wolfspraul has joined #bitcoin-core-dev
161 2019-01-10T11:21:15  *** Murch has joined #bitcoin-core-dev
162 2019-01-10T11:39:41  *** dermoth has quit IRC
163 2019-01-10T11:40:13  *** dermoth has joined #bitcoin-core-dev
164 2019-01-10T11:43:37  *** gekisai has joined #bitcoin-core-dev
165 2019-01-10T11:43:53  *** gelmutshmidt has joined #bitcoin-core-dev
166 2019-01-10T11:48:15  *** gekisai has quit IRC
167 2019-01-10T11:56:53  *** anome has joined #bitcoin-core-dev
168 2019-01-10T12:17:11  *** dermoth has quit IRC
169 2019-01-10T12:20:48  *** lnostdal has quit IRC
170 2019-01-10T12:21:17  *** lnostdal has joined #bitcoin-core-dev
171 2019-01-10T12:25:53  *** lnostdal has quit IRC
172 2019-01-10T12:27:09  *** miknotauro has quit IRC
173 2019-01-10T12:33:30  *** mg0314b has joined #bitcoin-core-dev
174 2019-01-10T12:38:49  *** Guyver2 has quit IRC
175 2019-01-10T12:38:58  *** mg0314b has quit IRC
176 2019-01-10T12:46:03  *** promag has quit IRC
177 2019-01-10T13:01:40  *** mistergold has joined #bitcoin-core-dev
178 2019-01-10T13:30:08  *** rh0nj has joined #bitcoin-core-dev
179 2019-01-10T13:40:47  *** anome has quit IRC
180 2019-01-10T13:50:50  *** Aaronvan_ is now known as AaronvanW
181 2019-01-10T13:54:09  *** VK86GER has joined #bitcoin-core-dev
182 2019-01-10T13:59:45  *** Cchadwicka has joined #bitcoin-core-dev
183 2019-01-10T14:05:12  *** arubi has quit IRC
184 2019-01-10T14:05:36  *** dermoth has joined #bitcoin-core-dev
185 2019-01-10T14:06:56  *** VK86GER has quit IRC
186 2019-01-10T14:08:14  *** arubi has joined #bitcoin-core-dev
187 2019-01-10T14:11:10  *** benthecarman has joined #bitcoin-core-dev
188 2019-01-10T14:12:26  <benthecarman> Is there an easy to way get a CTransaction from a CWalletTx
189 2019-01-10T14:15:40  *** Guyver2 has joined #bitcoin-core-dev
190 2019-01-10T14:19:01  *** lnostdal has joined #bitcoin-core-dev
191 2019-01-10T14:24:16  *** Murch has quit IRC
192 2019-01-10T14:34:08  *** spaced0ut has joined #bitcoin-core-dev
193 2019-01-10T14:34:31  <wumpus> benthecarman: the 'tx' field contains a pointer to the underlying CTransaction
194 2019-01-10T14:34:39  *** lnostdal has quit IRC
195 2019-01-10T14:36:48  <benthecarman> Oh okay thnx
196 2019-01-10T14:42:48  *** Murch has joined #bitcoin-core-dev
197 2019-01-10T14:45:00  *** mike_ has joined #bitcoin-core-dev
198 2019-01-10T14:45:24  *** mike_ is now known as Guest51719
199 2019-01-10T14:46:31  *** lnostdal has joined #bitcoin-core-dev
200 2019-01-10T15:11:15  *** lnostdal has quit IRC
201 2019-01-10T15:13:55  *** setpill has quit IRC
202 2019-01-10T15:19:04  *** Tralfaz has joined #bitcoin-core-dev
203 2019-01-10T15:23:30  *** lnostdal has joined #bitcoin-core-dev
204 2019-01-10T15:27:35  *** promag has joined #bitcoin-core-dev
205 2019-01-10T15:30:14  *** michaelsdunn1 has joined #bitcoin-core-dev
206 2019-01-10T15:38:30  *** zenogais has joined #bitcoin-core-dev
207 2019-01-10T15:45:15  *** gekisai has joined #bitcoin-core-dev
208 2019-01-10T15:49:29  *** gekisai has quit IRC
209 2019-01-10T15:53:32  *** aqquadro has quit IRC
210 2019-01-10T15:55:56  *** lnostdal has quit IRC
211 2019-01-10T15:57:50  *** Cchadwicka has quit IRC
212 2019-01-10T16:07:53  *** lnostdal has joined #bitcoin-core-dev
213 2019-01-10T16:13:52  *** promag has quit IRC
214 2019-01-10T16:13:56  *** lnostdal has quit IRC
215 2019-01-10T16:18:49  *** promag has joined #bitcoin-core-dev
216 2019-01-10T16:19:38  *** mistergold has quit IRC
217 2019-01-10T16:22:28  <hebasto> promag: hi, should I close #14798 in favor of #15136?
218 2019-01-10T16:22:30  <gribble> https://github.com/bitcoin/bitcoin/issues/14798 | qt: Fix deselecting peer when switching from peers to console tab by hebasto · Pull Request #14798 · bitcoin/bitcoin · GitHub
219 2019-01-10T16:22:31  <gribble> https://github.com/bitcoin/bitcoin/issues/15136 | qt: "Peers" tab overhaul by hebasto · Pull Request #15136 · bitcoin/bitcoin · GitHub
220 2019-01-10T16:23:01  <promag> you know my preference :D
221 2019-01-10T16:23:37  <hebasto> yeap :)
222 2019-01-10T16:23:55  <promag> hebasto: which behavior you prefer?
223 2019-01-10T16:25:26  <hebasto> promag: I would not work on it if it seems useless for me.
224 2019-01-10T16:26:20  *** lnostdal has joined #bitcoin-core-dev
225 2019-01-10T16:27:19  <promag> hebasto: then I think you should close the other one with some reasoning
226 2019-01-10T16:31:14  <promag> see you in the meeting
227 2019-01-10T16:31:17  *** promag has quit IRC
228 2019-01-10T16:31:30  <hebasto> promag: sure
229 2019-01-10T16:32:15  *** miknotauro has joined #bitcoin-core-dev
230 2019-01-10T16:38:19  <gkrizek> meshcollider:  wumpus: Ok, great. Thank you. I'm going to send messages when Tags are created as well. They are part of the same event type from GitHub and seem important info to message about
231 2019-01-10T16:40:16  <achow101> gkrizek: that's a good idea. currently wumpus has to send that message himself
232 2019-01-10T16:40:45  *** lnostdal has quit IRC
233 2019-01-10T16:40:57  <sipa> gkrizek: thank you for working on this
234 2019-01-10T16:42:24  <wumpus> gkrizek: thanks, seems useful!
235 2019-01-10T16:42:54  <gkrizek> Great, I think it would be too and since they are already part of the event it's almost no extra work.
236 2019-01-10T16:44:15  <gkrizek> sipa: no problem! Happy to help.  This will probably be a pretty minimal implementation at first because Services are officially EOL on the 31st. Just trying to get something to replace it for now, then can make it better later on.
237 2019-01-10T16:48:56  *** spinza has quit IRC
238 2019-01-10T16:54:48  *** spinza has joined #bitcoin-core-dev
239 2019-01-10T17:03:23  *** pinheadmz has joined #bitcoin-core-dev
240 2019-01-10T17:05:41  *** promag has joined #bitcoin-core-dev
241 2019-01-10T17:13:02  *** promag has quit IRC
242 2019-01-10T17:21:21  *** pinheadmz has quit IRC
243 2019-01-10T17:31:02  *** rh0nj has quit IRC
244 2019-01-10T17:32:08  *** rh0nj has joined #bitcoin-core-dev
245 2019-01-10T17:34:08  *** dviola has joined #bitcoin-core-dev
246 2019-01-10T17:43:44  *** promag has joined #bitcoin-core-dev
247 2019-01-10T17:46:45  *** gekisai has joined #bitcoin-core-dev
248 2019-01-10T17:51:39  *** gekisai has quit IRC
249 2019-01-10T17:57:19  *** sfhi has joined #bitcoin-core-dev
250 2019-01-10T18:00:15  *** jungly has quit IRC
251 2019-01-10T18:00:58  *** pinheadmz has joined #bitcoin-core-dev
252 2019-01-10T18:04:37  *** Giszmo has quit IRC
253 2019-01-10T18:10:42  *** miknotauro has quit IRC
254 2019-01-10T18:19:04  *** Giszmo has joined #bitcoin-core-dev
255 2019-01-10T18:19:05  *** pinheadmz has quit IRC
256 2019-01-10T18:25:10  *** mistergold has joined #bitcoin-core-dev
257 2019-01-10T18:27:33  *** Krellan has quit IRC
258 2019-01-10T18:28:04  *** Krellan has joined #bitcoin-core-dev
259 2019-01-10T18:30:34  *** pinheadmz has joined #bitcoin-core-dev
260 2019-01-10T18:32:21  *** Krellan has quit IRC
261 2019-01-10T18:46:26  *** dgenr8 has joined #bitcoin-core-dev
262 2019-01-10T19:00:25  <achow101> meeting?
263 2019-01-10T19:00:29  <instagibbs> meeting.
264 2019-01-10T19:00:32  <wumpus> #startmeeting
265 2019-01-10T19:00:32  <lightningbot> Meeting started Thu Jan 10 19:00:32 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
266 2019-01-10T19:00:32  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
267 2019-01-10T19:00:44  <moneyball> hi
268 2019-01-10T19:00:45  <sdaftuar> hi
269 2019-01-10T19:00:48  <sipa> hi
270 2019-01-10T19:00:56  <achow101> hi
271 2019-01-10T19:00:56  <moneyball> fyi there weren't any proposed topics in IRC the past week
272 2019-01-10T19:01:00  <jonasschnelli> hi
273 2019-01-10T19:01:02  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
274 2019-01-10T19:01:12  <promag> hi
275 2019-01-10T19:01:19  <jamesob> hi
276 2019-01-10T19:01:31  <wumpus> any proposed topics now?
277 2019-01-10T19:01:42  <wumpus> thanks for keeping track moneyball
278 2019-01-10T19:01:59  <achow101> topic: moving hwi under bitcoin-core org
279 2019-01-10T19:02:13  <wumpus> hwi?
280 2019-01-10T19:02:24  <achow101> hardware wallet interface thingy
281 2019-01-10T19:02:25  <instagibbs> https://github.com/achow101/HWI
282 2019-01-10T19:02:26  <jnewbery> hi
283 2019-01-10T19:02:34  <wumpus> ohh ofc
284 2019-01-10T19:02:47  <wumpus> #topic high priority for review
285 2019-01-10T19:02:54  <wumpus> https://github.com/bitcoin/bitcoin/projects/8
286 2019-01-10T19:03:02  <sipa> can i has #14955 ?
287 2019-01-10T19:03:06  <gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
288 2019-01-10T19:03:33  <wumpus> current ones: #11082 #14491 #14711 #14941 #14938
289 2019-01-10T19:03:36  <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
290 2019-01-10T19:03:38  <gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
291 2019-01-10T19:03:41  <wumpus> sipa: sure
292 2019-01-10T19:03:41  <gribble> https://github.com/bitcoin/bitcoin/issues/14711 | Remove uses of chainActive and mapBlockIndex in wallet code by ryanofsky · Pull Request #14711 · bitcoin/bitcoin · GitHub
293 2019-01-10T19:03:43  <gribble> https://github.com/bitcoin/bitcoin/issues/14941 | rpc: Make unloadwallet wait for complete wallet unload by promag · Pull Request #14941 · bitcoin/bitcoin · GitHub
294 2019-01-10T19:03:45  <gribble> https://github.com/bitcoin/bitcoin/issues/14938 | Support creating an empty wallet by Sjors · Pull Request #14938 · bitcoin/bitcoin · GitHub
295 2019-01-10T19:04:06  <sdaftuar> i'd like to request #15141
296 2019-01-10T19:04:08  <gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
297 2019-01-10T19:04:19  <jnewbery> I think everyone's scared of reviewing that!
298 2019-01-10T19:04:35  <sdaftuar> it's already been reviewed a bunch, just never was merged :(
299 2019-01-10T19:05:00  <wumpus> added
300 2019-01-10T19:05:08  <sdaftuar> thanks
301 2019-01-10T19:06:10  <wumpus> #topic moving hwi under bitcoin-core org (achow101)
302 2019-01-10T19:06:33  <phantomcircuit> hi
303 2019-01-10T19:06:46  <wumpus> #link https://github.com/achow101/HWI
304 2019-01-10T19:06:47  <jonasschnelli> Maybe we can discuss #11082 since there was the discussion of JSON vs INI?
305 2019-01-10T19:06:50  <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
306 2019-01-10T19:06:54  <meshcollider> Hi
307 2019-01-10T19:07:43  <achow101> so hwi is currently under my account. but if we are going to use it for hardware wallet support in core, then perhaps it would be better to have it under a proper github org. the obvious one that comes to mind is bitcoin-core
308 2019-01-10T19:08:14  <wumpus> yes, that makes sense
309 2019-01-10T19:08:17  <achow101> instagibbs: might have some thoughts on this?
310 2019-01-10T19:08:25  <instagibbs> nothing against achow101 but also I'm actively using it and would be nice to be put under an established org
311 2019-01-10T19:08:28  <instagibbs> ;)
312 2019-01-10T19:08:38  <instagibbs> ACK in other words
313 2019-01-10T19:09:02  <wumpus> no one seems to be opposed :)
314 2019-01-10T19:09:29  *** pinheadmz has quit IRC
315 2019-01-10T19:09:31  <instagibbs> https://github.com/achow101/HWI/issues/91 for further background
316 2019-01-10T19:09:43  <meshcollider> We should give achow merge permission on it imo
317 2019-01-10T19:09:58  <wumpus> of course
318 2019-01-10T19:10:05  <sipa> achow101: iirc there is a way to 'transfer' a repo to another org, that way github will automatically set up redirects etc
319 2019-01-10T19:10:09  <sipa> as opposed to copying it over
320 2019-01-10T19:10:23  <instagibbs> yep, just an organizational thing, with established review/merge norms/contributor docs
321 2019-01-10T19:10:25  <wumpus> he might still want the local clone for his own PRs
322 2019-01-10T19:10:29  <achow101> sipa: yes, there's a transfer ownership button
323 2019-01-10T19:10:53  <jnewbery> #link https://help.github.com/articles/transferring-a-repository/
324 2019-01-10T19:10:56  <wumpus> but could create a new one as well
325 2019-01-10T19:11:09  <wumpus> (clone it again after transfering)
326 2019-01-10T19:11:11  *** pinheadmz has joined #bitcoin-core-dev
327 2019-01-10T19:11:35  <wumpus> any other topics?
328 2019-01-10T19:11:51  <jimpo> BIP 157 index leveldb vs flatfiles?
329 2019-01-10T19:12:08  <wumpus> ah yes jonasschnelli had one
330 2019-01-10T19:12:13  *** pinheadmz has quit IRC
331 2019-01-10T19:12:27  <jonasschnelli> not an important one
332 2019-01-10T19:12:40  <jonasschnelli> (and my internet connection goes up and down)
333 2019-01-10T19:12:45  <wumpus> ok jimpo first then
334 2019-01-10T19:12:46  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11082#issuecomment-451406061
335 2019-01-10T19:12:50  <jonasschnelli> ack
336 2019-01-10T19:12:58  <wumpus> #topic BIP 157 index leveldb vs flatfiles (jimpo)
337 2019-01-10T19:13:00  <jimpo> So there's some discussion on #14121
338 2019-01-10T19:13:03  <gribble> https://github.com/bitcoin/bitcoin/issues/14121 | Index for BIP 157 block filters by jimpo · Pull Request #14121 · bitcoin/bitcoin · GitHub
339 2019-01-10T19:13:27  <jimpo> basically there's three options 1) store entire filters along with metadata in separate LevelDB
340 2019-01-10T19:13:43  <jimpo> 2) store filter metadata (hash, disk pos) in levelDB and filters in flat files
341 2019-01-10T19:14:03  <jimpo> 3) add filter metadata to CBlockIndex and store filters in flat files, just like undo data
342 2019-01-10T19:14:27  <jimpo> In terms of perf, #3 is probably the fastest and certainly the fastest with enough IO optimizations
343 2019-01-10T19:14:30  <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
344 2019-01-10T19:14:35  <sipa> so the first question is between 1/2 and 3, i think; whether the filters are their own index semantically, or part of the main data structures
345 2019-01-10T19:15:10  <jonasschnelli> What speaks against being part of the main data structure?
346 2019-01-10T19:15:14  <jimpo> I prefer 1/2 since I can imagine alternate filter types
347 2019-01-10T19:15:21  <jonasschnelli> (like option 3)
348 2019-01-10T19:15:22  <sipa> and i guess that depends on how they'll be used; if they're mostly optional things that some people want to enable, a separate index is the obvious way to go
349 2019-01-10T19:15:29  <jamesob> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/14121#issuecomment-451838178
350 2019-01-10T19:15:39  <sipa> but if we envision it may become a consensus rule, having it separate is quite annoying
351 2019-01-10T19:15:55  <jimpo> metadata is like 76 bytes (2 hashes + disk loc)
352 2019-01-10T19:16:19  <jonasschnelli> From what I see is that there are plans to commit the filters at one point so it'll be part of the consensus, right?
353 2019-01-10T19:17:06  <jimpo> it's more convenient to have it in CBlockIndex if part of consensus rules, yes, but I'm not sure how much worse the separate index is there
354 2019-01-10T19:17:18  <sipa> i guess it isn't really
355 2019-01-10T19:17:29  <jimpo> would have to do some synchronization or build the filters twice (but that's really fast)
356 2019-01-10T19:17:47  <jimpo> like you can validate the consensus rule w/o storing the filter
357 2019-01-10T19:17:50  <sipa> it can go from an asynchronously maintained one to a synchronous one perhap at that time, but still remain a separate db/directory
358 2019-01-10T19:17:50  <jimpo> if you don't want to
359 2019-01-10T19:17:55  <sipa> right
360 2019-01-10T19:18:45  <jimpo> which is another strong (IMO) argument in favor of 1/2: not everyone needs to or should be forced to store filters
361 2019-01-10T19:19:00  <jimpo> and no need to bloat CBlockIndex if people might disable it
362 2019-01-10T19:19:15  <sipa> agree; i forgot about the possibility that even in case of it being consensus, there is no requirement to actually store the filters
363 2019-01-10T19:20:22  <sipa> about the difference between 1 and 2... i prefer the flat files approach slightly (the filters aren't that big that using leveldb is insurmountable, but they're still append-only data like blocks/undo)
364 2019-01-10T19:20:43  <sipa> and i saw you also have a PR to abstract out the flat files stuff, which seems useful in any case
365 2019-01-10T19:20:54  <jimpo> I do agree that 2 is somewhat conceptually cleaner
366 2019-01-10T19:21:13  <jimpo> but it does make the code more complex and is slower right now unless we add a caching layer to the flatfile stuff
367 2019-01-10T19:21:53  <jamesob> we don't know how much slower though, right? might be negligible
368 2019-01-10T19:22:01  <gmaxwell> I feel sketchy about adding a requirement to store blobs in leveldb, I think in the long run we won't end up using leveldb -- we now no longer need basically any interesting properties of it, it's just a MAP on disk for us now.
369 2019-01-10T19:22:24  <gmaxwell> I'm confused that its slower or at least why it would be under actual use though.
370 2019-01-10T19:22:30  <jamesob> gmaxwell: we might use snapshotting to alleviate lock contention at some point...
371 2019-01-10T19:22:46  <gmaxwell> jamesob: you wouldn't say that if you'd actually tested snapshotting.
372 2019-01-10T19:22:49  <jimpo> just two separate reads instead of 1 for each filter I think
373 2019-01-10T19:23:07  <sipa> gmaxwell: but do you think that choosing to use leveldb right now will complicate a hypothetical move to using something else?
374 2019-01-10T19:23:12  <jimpo> but there are certainly ways to reduce that overhead which I haven't experimented with
375 2019-01-10T19:23:20  <gmaxwell> jimpo: why two seperate reads?
376 2019-01-10T19:23:28  <jamesob> 1 for leveldb, then 1 for flatfile
377 2019-01-10T19:23:32  *** chenpo has joined #bitcoin-core-dev
378 2019-01-10T19:23:36  <jimpo> first read from the leveldb index to get the disk pos, then read the filter from flatfile
379 2019-01-10T19:23:43  <sipa> well the leveldb part can be in memory, no?
380 2019-01-10T19:23:51  <sipa> like CBlockIndex is now
381 2019-01-10T19:23:54  <gmaxwell> Ah so it's directly reading the leveldb instead of having the index in memory like the block index is.
382 2019-01-10T19:24:19  <jimpo> true, we could keep the whole index in memory
383 2019-01-10T19:24:35  <jimpo> but shouldn't that be pretty much equivalent to setting the cache on the leveldb high enough?
384 2019-01-10T19:24:36  <gmaxwell> I would be saying these pointers should just be in the blockindex. But there was some talk about switching this on and off above.
385 2019-01-10T19:25:08  <gmaxwell> jimpo: not really, there are a bunch of overheads in the leveldb caching and it's not particularly intelligent.
386 2019-01-10T19:25:23  <sipa> also a leveldb _read_ is not a single disk access
387 2019-01-10T19:25:37  <sipa> (as opposed to something that hits a cache)
388 2019-01-10T19:26:03  <jimpo> ok
389 2019-01-10T19:26:06  <gmaxwell> it's quasi log(n) plus a bunch of rather expensive bloom filter checks, which is why I was surprised the flatfile was slower..
390 2019-01-10T19:26:06  <sipa> so with index in memory + flatfile you're guaranteed one disk seek always
391 2019-01-10T19:26:21  <gmaxwell> but if your flatfile is a leveldb access plus the file now I see why it couldn't be faster.
392 2019-01-10T19:26:32  <gmaxwell> since you take the ldb overheads in both cases.
393 2019-01-10T19:26:35  <jimpo> gmaxwell yes it was leveldb + flatfile
394 2019-01-10T19:27:01  *** profmac has quit IRC
395 2019-01-10T19:27:43  <jimpo> OK, so what if we have a leveldb index + flatfiles
396 2019-01-10T19:28:04  <jimpo> then if that's slow we can add logic to pull the whole leveldb index into mem like the CChain structure
397 2019-01-10T19:28:10  <jimpo> but as a separate structure
398 2019-01-10T19:28:54  <sipa> is that easier than doing it immediately? (i'm thinking about dealing with the possibility of leveldb read failure outside of startup etc)
399 2019-01-10T19:29:17  <jimpo> yes, it definitely breaks up the size of the code change
400 2019-01-10T19:29:22  <gmaxwell> sipa: I think right now our leveldb usage can be replaced with something that very simply serializes the things like blockindexes, and an open-hash table for the utxo set. e.g. like the one the ripple people did... and it would likely be a pretty massive speedup.   I suppose you could just convert this to a flatfile /then/, so it's not the end of the world.  We also take on some increased
401 2019-01-10T19:29:22  <gmaxwell> Q/A,dev overhead if we start storing blobs in ldb because thats just a whole other set of access patterns that we need to worry about that might result in misbehaviors (like, what is ldb's peak memory usage look like when storing 40kb blobs in it?)
402 2019-01-10T19:29:51  <jamesob> sipa: if we have leveldb read failures we've got bigger problems than serving block filters, no?
403 2019-01-10T19:29:53  *** Krellan has joined #bitcoin-core-dev
404 2019-01-10T19:30:29  *** elichai2 has quit IRC
405 2019-01-10T19:30:38  <jimpo> is a leveldb read failure significantly more likely than a flatfile read failure?
406 2019-01-10T19:30:39  <sipa> gmaxwell: ok i see
407 2019-01-10T19:30:43  *** Krellan has joined #bitcoin-core-dev
408 2019-01-10T19:30:58  <sipa> jimpo: it needs exception handling etc, which i remember was a pain to deal with in the UTXO code
409 2019-01-10T19:31:18  *** gekisai has joined #bitcoin-core-dev
410 2019-01-10T19:31:43  <wumpus> doesn't all i/o need error handling?
411 2019-01-10T19:32:11  <jimpo> I guess flatfile accesses just return error codes or null vs throwing exceptions? is that what you're saying sipa?
412 2019-01-10T19:32:22  <sipa> sure, but an "if (!read) return false" in the startup code is easier than a wrapper database object that catches exceptions etc
413 2019-01-10T19:32:35  <wumpus> oh sure the way in which errors are reported will differ
414 2019-01-10T19:32:58  <sipa> anyway, i'm fine with leveldb index + flatfiles, and moving the load into RAM to a later chance
415 2019-01-10T19:33:26  <wumpus> one thing at least, for the first iteration it's useful to keep the amount of new code minimal
416 2019-01-10T19:33:28  <sipa> performance at this point doesn't matter that much for this application, but it's nice that in the future it wouldn't be a compatibility break
417 2019-01-10T19:33:45  <gmaxwell> is the only reason to not store it in the blockindex is to just avoid the size of the blockindex objects increasing when the filter isn't used?
418 2019-01-10T19:34:17  <jimpo> potentially if core supports multiple filter types (dunno how likely that is?)
419 2019-01-10T19:34:33  <sipa> jimpo: also to simplify building it in the background, i guess?
420 2019-01-10T19:34:41  <wumpus> so if using leveldb results in much less code than implementing some manual file handling, that might be handier for review, as said it can be optimized later
421 2019-01-10T19:35:30  <gmaxwell> it won't be.
422 2019-01-10T19:36:10  <jimpo> it's a few hundred more lines
423 2019-01-10T19:36:18  <jimpo> *after* the flatfile refactor
424 2019-01-10T19:36:20  <wumpus> as long as you don't end up rolling your own k/v store
425 2019-01-10T19:36:44  <jimpo> but I think the refactor is good to do anyway
426 2019-01-10T19:36:55  <jamesob> agree with that
427 2019-01-10T19:37:18  <sipa> agree, yes
428 2019-01-10T19:37:28  <sipa> gmaxwell: what makes you say so?
429 2019-01-10T19:37:50  <gmaxwell> The whole process of making these things super optional seems to add a lot of complexity. If instead we didn't think of it that way the filters could just be handled right along side, say, undo data.
430 2019-01-10T19:38:21  <jimpo> eh, depends how you think about complexity
431 2019-01-10T19:38:36  <jimpo> I consider adding more stuff to CBlockIndex to be more complex than a separate, asynchronous system
432 2019-01-10T19:38:54  <sipa> gmaxwell: agree, it adds complexity to make it optional and separate, but that's a different question than whether or not everything should be in leveldb or partially in flat files
433 2019-01-10T19:39:05  <jimpo> otherwise it involves messing around with validation code before there's even a consensus change
434 2019-01-10T19:39:05  <gmaxwell> If I drop out support for upgrades and what not, I believe I could add support for including indexes with two dozen lines of code.  Obviously not a fair comparison.
435 2019-01-10T19:39:06  <wumpus> right, with decoupling at least changes can be localized and contained, instead of tying everything together
436 2019-01-10T19:39:25  <gmaxwell> But building a pile of logical abstractions that add layers and layers is not actually a reduction in complexity.
437 2019-01-10T19:39:32  <wumpus> exactly jimpo
438 2019-01-10T19:39:34  <gmaxwell> It's decomplexity theater.
439 2019-01-10T19:39:40  <sipa> please
440 2019-01-10T19:39:55  <wumpus> is that what he's doing?
441 2019-01-10T19:40:13  <jimpo> rich hickey would disagree, I think
442 2019-01-10T19:40:18  *** profmac has joined #bitcoin-core-dev
443 2019-01-10T19:40:57  <gmaxwell> and then we just spend our entire lives on pointless refactors shifting around the deckchairs on this fractal of layers, while seldom actually advancing visible functionality, which is exactly what the project has been doing for the last year.
444 2019-01-10T19:41:10  <wumpus> I don't think this is construcive anymore
445 2019-01-10T19:41:14  <wumpus> any other topics?
446 2019-01-10T19:41:29  <jonasschnelli> rw_config INI vs UniValue
447 2019-01-10T19:41:36  <jamesob> operation of cblockindex is consensus critical; atm serving filter blocks is not => decoupling failure of the optional feature from the critical one is safer
448 2019-01-10T19:41:49  <wumpus> #topic rw_config INI vs UniValue (jonasschnelli)
449 2019-01-10T19:41:53  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11082#issuecomment-451406061
450 2019-01-10T19:42:05  *** mistergold has quit IRC
451 2019-01-10T19:42:13  <jonasschnelli> The current rw_config PR from luke-jr uses .INI file structure (own parser)...
452 2019-01-10T19:42:29  <jonasschnelli> The question is, if a simple JSON file wouldn't be simpler and more stable
453 2019-01-10T19:42:39  <wumpus> jamesob: FWIW I agree, as long as it is not consensus critical, it's better to have it separate from the consensus critical code, this was the same idea with separating out the other indexes
454 2019-01-10T19:43:08  <wumpus> but apparently all of that was pointless —
455 2019-01-10T19:43:14  <jimpo> JSON is somewhat less human-readable IMO
456 2019-01-10T19:43:38  <jonasschnelli> Yes. But should its main focus be human editable / readable?
457 2019-01-10T19:43:46  <jamesob> also more annoying to write (e.g. trailing commas on last key causes errors)
458 2019-01-10T19:45:44  <jonasschnelli> I think using a JSON file is more straight forward since we have the parser/writer logic in place (rather then adding another file format)
459 2019-01-10T19:46:02  *** promag has quit IRC
460 2019-01-10T19:46:14  <jonasschnelli> Also, the rw_configs focus AFAIK is "edit through the application layer" rather then manually with a text editor
461 2019-01-10T19:46:20  <ryanofsky> the question isn't really "do you like ini or json better?" the question is how do you want to replace QSettings? with a new ini parser, or existing ini parser, or with existing univalue parser?
462 2019-01-10T19:46:34  <jamesob> I'm in favor of whatever is less code
463 2019-01-10T19:46:54  <jonasschnelli> UniValue is very likely less code
464 2019-01-10T19:47:17  <jimpo> Yeah, I'm on board with JSON
465 2019-01-10T19:47:33  <jonasschnelli> But maybe we pick up the discussion when luke-jr is back or – if you care – comment on the PR
466 2019-01-10T19:49:12  <jonasschnelli> other topics?
467 2019-01-10T19:49:33  <jamesob> so can we proceed on jimpo's option (2), i.e. indexing in ldb and storing filters in flatfiles?
468 2019-01-10T19:50:33  <wumpus> jamesob | I'm in favor of whatever is less code   <- same
469 2019-01-10T19:50:48  *** gekisai has quit IRC
470 2019-01-10T19:51:16  <wumpus> no other topics?
471 2019-01-10T19:51:44  <jnewbery> reminder: wallet IRC meeting tomorrow
472 2019-01-10T19:52:52  <wumpus> #endmeeting
473 2019-01-10T19:52:52  <lightningbot> Meeting ended Thu Jan 10 19:52:52 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
474 2019-01-10T19:52:52  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-10-19.00.html
475 2019-01-10T19:52:52  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-10-19.00.txt
476 2019-01-10T19:52:52  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-10-19.00.log.html
477 2019-01-10T19:53:36  *** promag has joined #bitcoin-core-dev
478 2019-01-10T19:54:27  *** benthecarman_ has joined #bitcoin-core-dev
479 2019-01-10T19:55:21  <dongcarl> I would like people to take a look at #12255 when they can, I'm not sure if there is precedent for how this is usually done but I think we should contact distro package maintainers if we decide it should be merged
480 2019-01-10T19:55:23  <gribble> https://github.com/bitcoin/bitcoin/issues/12255 | Update bitcoin.service to conform to init.md by dongcarl · Pull Request #12255 · bitcoin/bitcoin · GitHub
481 2019-01-10T19:56:11  <dongcarl> I do not want careless distro maintainers clogging up people's hard drives and bringing down nodes just because the default datadir has changed
482 2019-01-10T19:57:08  *** benthecarman has quit IRC
483 2019-01-10T19:57:34  *** bentheacarman__ has joined #bitcoin-core-dev
484 2019-01-10T19:58:49  *** hebasto has quit IRC
485 2019-01-10T19:59:27  *** benthecarman has joined #bitcoin-core-dev
486 2019-01-10T19:59:54  *** benthecarman_ has quit IRC
487 2019-01-10T20:06:23  <wumpus> to be honest I have no idea who is actually using those files, whether they're used in any distro packaging
488 2019-01-10T20:06:54  <wumpus> I do know it tends to be hard to find reviewers for init scripts and such
489 2019-01-10T20:07:26  <wumpus> I think they're meant as examples in the first place, to copy over and tweak, not for anything to be automtically installing them
490 2019-01-10T20:08:50  <wumpus> but it's a good point...
491 2019-01-10T20:12:23  *** Guest29947 has joined #bitcoin-core-dev
492 2019-01-10T20:12:35  <dongcarl> wumpus: I know that at least Arch Linux uses the systemd file
493 2019-01-10T20:13:29  <gwillen> I would appreciate if people would glance at #14978, it has a couple of utACKs but I don't really know what it needs before someone is comfortable merging it
494 2019-01-10T20:13:31  <gribble> https://github.com/bitcoin/bitcoin/issues/14978 | Factor out PSBT utilities from RPCs for use in GUI code; related refactoring. by gwillen · Pull Request #14978 · bitcoin/bitcoin · GitHub
495 2019-01-10T20:16:36  *** chenpo has quit IRC
496 2019-01-10T20:20:56  *** promag has quit IRC
497 2019-01-10T20:23:35  *** ddustin has joined #bitcoin-core-dev
498 2019-01-10T20:24:28  *** gekisai has joined #bitcoin-core-dev
499 2019-01-10T20:28:26  *** EagleTM has joined #bitcoin-core-dev
500 2019-01-10T20:29:09  *** gekisai has quit IRC
501 2019-01-10T20:29:24  *** gekisai has joined #bitcoin-core-dev
502 2019-01-10T20:32:32  *** pinheadmz has joined #bitcoin-core-dev
503 2019-01-10T20:37:49  *** AaronvanW has quit IRC
504 2019-01-10T20:45:36  *** promag has joined #bitcoin-core-dev
505 2019-01-10T20:48:08  *** AaronvanW has joined #bitcoin-core-dev
506 2019-01-10T20:52:33  *** AaronvanW has quit IRC
507 2019-01-10T20:54:01  *** chenpo has joined #bitcoin-core-dev
508 2019-01-10T20:54:58  *** promag has quit IRC
509 2019-01-10T20:58:46  *** pinheadmz has quit IRC
510 2019-01-10T21:01:37  *** promag has joined #bitcoin-core-dev
511 2019-01-10T21:07:28  *** promag has quit IRC
512 2019-01-10T21:10:16  <phantomcircuit> sipa, what does openssl's rng do to gather entropy? anything that you're not already doing?
513 2019-01-10T21:11:30  <gmaxwell> phantomcircuit: I believe the code in sipa's PR does more or less strictly more than openssl does by default on linux at least.
514 2019-01-10T21:11:49  <gmaxwell> phantomcircuit: it reads dev/urandom and also combines in e.g. the stack pointer and a time.
515 2019-01-10T21:11:58  <phantomcircuit> also why remove the perfmon data from GetStrongRand* functions
516 2019-01-10T21:12:46  <phantomcircuit> oh i see you moved it to the scheduler, makes sense
517 2019-01-10T21:12:52  <gmaxwell> phantomcircuit: the permon is already only once in a while (its slow), in the PR it gets moved to the idle thread.
518 2019-01-10T21:13:01  <gmaxwell> right.
519 2019-01-10T21:19:06  *** Giszmo has quit IRC
520 2019-01-10T21:25:50  *** lnostdal has joined #bitcoin-core-dev
521 2019-01-10T21:36:32  *** Giszmo has joined #bitcoin-core-dev
522 2019-01-10T21:40:07  *** DeanGuss has joined #bitcoin-core-dev
523 2019-01-10T21:46:30  *** pinheadmz has joined #bitcoin-core-dev
524 2019-01-10T21:52:29  *** Guyver2 has quit IRC
525 2019-01-10T21:57:56  *** AaronvanW has joined #bitcoin-core-dev
526 2019-01-10T22:03:56  *** DeanGuss has quit IRC
527 2019-01-10T22:04:20  *** DeanGuss has joined #bitcoin-core-dev
528 2019-01-10T22:05:46  *** michaelsdunn1 has quit IRC
529 2019-01-10T22:07:52  *** Guest51719 has quit IRC
530 2019-01-10T22:08:46  *** Liliaceae has quit IRC
531 2019-01-10T22:10:44  *** Liliaceae has joined #bitcoin-core-dev
532 2019-01-10T22:33:03  *** hidden has joined #bitcoin-core-dev
533 2019-01-10T22:33:08  *** hidden has left #bitcoin-core-dev
534 2019-01-10T22:33:25  *** spinza has quit IRC
535 2019-01-10T22:37:55  *** hidden has joined #bitcoin-core-dev
536 2019-01-10T22:45:39  <hidden> https://github.com/bitcoin/bitcoin/issues/7463#issuecomment-306336149 does anybody know how i could recover keys from keypool that has been damaged in relation to this issue?
537 2019-01-10T22:46:09  <hidden> i have been trying for years now any help will be hugely appreciated
538 2019-01-10T23:04:18  *** sfhi has quit IRC
539 2019-01-10T23:05:11  <gwillen> hidden: is there a writeup somewhat of what happened, what the failure looks like, and what you've tried
540 2019-01-10T23:05:19  <gwillen> the easiest way to get help will start with writing those things down
541 2019-01-10T23:06:21  <gwillen> (also, I'm not sure this channel is the right place to seek help, but in any case it's not the right place to have a long discussion about it)
542 2019-01-10T23:07:19  *** spinza has joined #bitcoin-core-dev
543 2019-01-10T23:11:49  *** timothy has quit IRC
544 2019-01-10T23:11:57  <hidden> gwillen basically i salvagewallet and it said failed and wallet is corrupt. if i try to open the client again it i could try generate a new address to load up the reserved ones in the keypool, i could do so until i the "unknown key in key pool" error. i can dump the wallet (which was renamed ending .bak december 2013) using pywallet. in the dump i see the address and the corresponding "public_key_hex" under list of keypool but not the
545 2019-01-10T23:11:57  <hidden> private key.
546 2019-01-10T23:12:12  *** echonaut has quit IRC
547 2019-01-10T23:13:05  <hidden> I also downloaded berkeley DB, did a db_dump, didn't go anywhere much yet, i hear doing recovery without aggressive might help but still clueless and learning about berkely db.
548 2019-01-10T23:13:34  <hidden> it's not a HD wallet as you might have guessd. the link i posted (https://github.com/bitcoin/bitcoin/issues/7463#issuecomment-306336149) details the exact issue.
549 2019-01-10T23:13:57  *** echonaut has joined #bitcoin-core-dev
550 2019-01-10T23:14:16  <hidden> maybe even a solution was provided there to retrieve keys but i couldn't follow. if anyone has idea on what to do, patiently just idling and searching solutions thanks.
551 2019-01-10T23:15:52  <gwillen> hm, if pywallet --dumwallet show private keys for other public keys, but not the one in question, presumably that is one of the corrupted records :-\
552 2019-01-10T23:16:47  <gwillen> that doesn't necessarily mean there are zero useful bytes to recover, but it does mean some bytes you want have probably been destroyed, and implies that fixing the salvagewallet issue probably wouldn't recover that key
553 2019-01-10T23:17:24  *** Giszmo has quit IRC
554 2019-01-10T23:17:51  <gwillen> but again I don't want to do too much discussion in this channel -- it would be really helpful if you would write down somewhere, e.g. even just a google doc or something, everything you've tried so far and exactly what you see (e.g. what output do you get from pywallet? obviously don't paste any actual private keys.)
555 2019-01-10T23:17:54  <hidden> yes it is one of the the pages are out of order https://pastebin.com/g0gDC990
556 2019-01-10T23:19:04  <hidden> the output of pywallet is 600mb its hard to post it. but i can post headers of db_dump https://pastebin.com/TbUM2STN
557 2019-01-10T23:19:43  <hidden> i'll write a google doc if no one can provide a solution tonight. maybe it's an easy fix
558 2019-01-10T23:20:08  <gwillen> I'll caution that unfortunately it doesn't _sound_ like an easy fix, but I'd love to offer you one if it is -- a google doc would be ideal
559 2019-01-10T23:20:59  <gwillen> make sure you don't include any private keys, even ones you think aren't the right ones, just in case -- censor them from anything you post
560 2019-01-10T23:21:05  <hidden> ok, i'll get the google doc somewhere, hopefully someone see's the scrollback too who can help. will do some recovery with berkeley db tools
561 2019-01-10T23:33:09  *** Giszmo has joined #bitcoin-core-dev
562 2019-01-10T23:35:55  *** miknotauro has joined #bitcoin-core-dev
563 2019-01-10T23:37:11  *** spaced0ut has quit IRC
564 2019-01-10T23:38:36  *** promag has joined #bitcoin-core-dev
565 2019-01-10T23:43:14  *** echonaut has quit IRC
566 2019-01-10T23:43:25  *** echonaut has joined #bitcoin-core-dev
567 2019-01-10T23:54:25  *** ddustin has quit IRC
568 2019-01-10T23:54:45  *** ddustin has joined #bitcoin-core-dev