1 2017-09-28T00:00:20  *** justanotheruser has joined #bitcoin-core-dev
  2 2017-09-28T00:06:07  *** georges_ has joined #bitcoin-core-dev
  3 2017-09-28T00:07:51  *** georges_ has quit IRC
  4 2017-09-28T00:20:34  *** merehap__ has joined #bitcoin-core-dev
  5 2017-09-28T00:20:35  *** merehap_ has quit IRC
  6 2017-09-28T00:26:24  *** goatpig has joined #bitcoin-core-dev
  7 2017-09-28T00:28:12  *** Ylbam has quit IRC
  8 2017-09-28T00:31:18  *** Miezel has quit IRC
  9 2017-09-28T00:39:06  *** chjj has joined #bitcoin-core-dev
 10 2017-09-28T00:43:13  *** promag has joined #bitcoin-core-dev
 11 2017-09-28T00:43:20  *** justanotheruser has quit IRC
 12 2017-09-28T00:43:37  *** justanotheruser has joined #bitcoin-core-dev
 13 2017-09-28T00:47:29  *** promag has quit IRC
 14 2017-09-28T00:49:39  *** ekerstein has quit IRC
 15 2017-09-28T00:51:01  *** dabura667 has joined #bitcoin-core-dev
 16 2017-09-28T00:51:02  *** ekerstein has joined #bitcoin-core-dev
 17 2017-09-28T00:52:10  *** ekerstein has left #bitcoin-core-dev
 18 2017-09-28T01:21:57  *** Murch has quit IRC
 19 2017-09-28T01:37:28  *** kebman has quit IRC
 20 2017-09-28T01:41:03  *** tknp has quit IRC
 21 2017-09-28T02:07:56  *** justan0theruser has joined #bitcoin-core-dev
 22 2017-09-28T02:08:26  *** justan0theruser has joined #bitcoin-core-dev
 23 2017-09-28T02:09:48  *** justanotheruser has quit IRC
 24 2017-09-28T02:16:03  *** ensign has quit IRC
 25 2017-09-28T02:16:40  <jimpo> Why is this check for input index out of bounds below the BIP 143 sighash handling? https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1223
 26 2017-09-28T02:18:16  *** ensign has joined #bitcoin-core-dev
 27 2017-09-28T02:26:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 28 2017-09-28T02:31:39  *** PaulCape_ has quit IRC
 29 2017-09-28T02:32:35  <sipa> the bip143 code has the same check here: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1194
 30 2017-09-28T02:33:21  <sipa> oh, no; you're just talking about the sanity check
 31 2017-09-28T02:33:31  <sipa> that should be an assert really, and it can go above, indeed
 32 2017-09-28T02:36:43  *** PaulCapestany has joined #bitcoin-core-dev
 33 2017-09-28T02:43:17  *** meshcollider has quit IRC
 34 2017-09-28T02:47:18  <jimpo> sipa: So it's safe if I change that to an assert at the top?
 35 2017-09-28T02:51:31  *** meshcollider has joined #bitcoin-core-dev
 36 2017-09-28T02:54:54  <sipa> jimpo: imo, yes
 37 2017-09-28T02:55:13  <bitcoin-git> [bitcoin] jimpo opened pull request #11411: script: Change SignatureHash input index check to an assert. (master...sighash-bounds-check) https://github.com/bitcoin/bitcoin/pull/11411
 38 2017-09-28T02:55:23  <jimpo> I'm running the test suite on it now. Let's see...
 39 2017-09-28T03:10:24  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ef8340d25f7c...d90a00eabed0
 40 2017-09-28T03:10:24  <bitcoin-git> bitcoin/master 22f816e Wladimir J. van der Laan: net: Improve and document SOCKS code...
 41 2017-09-28T03:10:25  <bitcoin-git> bitcoin/master d90a00e Jonas Schnelli: Merge #11397: net: Improve and document SOCKS code...
 42 2017-09-28T03:11:04  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #11397: net: Improve and document SOCKS code (master...2017_09_socks_refactor) https://github.com/bitcoin/bitcoin/pull/11397
 43 2017-09-28T03:15:56  *** ghost43 has quit IRC
 44 2017-09-28T03:18:21  *** Chris_Stewart_5 has quit IRC
 45 2017-09-28T03:22:50  *** ghost43 has joined #bitcoin-core-dev
 46 2017-09-28T03:27:35  *** justanotheruser has joined #bitcoin-core-dev
 47 2017-09-28T03:29:37  *** justan0theruser has quit IRC
 48 2017-09-28T03:32:19  *** gijensen has quit IRC
 49 2017-09-28T03:32:50  *** wolfspraul has quit IRC
 50 2017-09-28T03:33:28  *** ghost43 has quit IRC
 51 2017-09-28T03:33:52  *** comboy has quit IRC
 52 2017-09-28T03:34:29  *** justanotheruser has quit IRC
 53 2017-09-28T03:34:47  *** ghost43 has joined #bitcoin-core-dev
 54 2017-09-28T03:34:49  *** justanotheruser has joined #bitcoin-core-dev
 55 2017-09-28T03:38:02  *** gijensen has joined #bitcoin-core-dev
 56 2017-09-28T03:39:14  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #11412: Simplify GetWarnings() (master...2017/09/getwarnings) https://github.com/bitcoin/bitcoin/pull/11412
 57 2017-09-28T03:39:33  *** wolfspraul has joined #bitcoin-core-dev
 58 2017-09-28T03:39:39  *** comboy has joined #bitcoin-core-dev
 59 2017-09-28T03:53:42  *** ndrst has quit IRC
 60 2017-09-28T04:01:06  *** Guest26486 has joined #bitcoin-core-dev
 61 2017-09-28T04:03:56  *** intcat has quit IRC
 62 2017-09-28T04:08:00  *** intcat has joined #bitcoin-core-dev
 63 2017-09-28T04:11:54  <jonasschnelli> Beg for reviews on #7061 (from 2015!)
 64 2017-09-28T04:11:57  <gribble> https://github.com/bitcoin/bitcoin/issues/7061 | [Wallet] Add RPC call "rescanblockchain " by jonasschnelli · Pull Request #7061 · bitcoin/bitcoin · GitHub
 65 2017-09-28T04:21:52  <warren> I liked sipa's comment "I would still prefer an approach that imports with birthdate instead of explicit rescanning."
 66 2017-09-28T04:22:34  <warren> opportunity to optionally encode a birthdate in the address, but there was concern of bikeshedding or something
 67 2017-09-28T04:27:25  *** ghost43 has quit IRC
 68 2017-09-28T04:27:51  *** ghost43 has joined #bitcoin-core-dev
 69 2017-09-28T04:38:59  *** wittysense has quit IRC
 70 2017-09-28T04:45:07  *** promag has joined #bitcoin-core-dev
 71 2017-09-28T04:47:08  *** twistedline has quit IRC
 72 2017-09-28T04:49:21  *** promag has quit IRC
 73 2017-09-28T05:12:50  *** ghost43 has quit IRC
 74 2017-09-28T05:13:04  *** Guest26486 is now known as ndrst
 75 2017-09-28T05:13:08  *** ndrst has joined #bitcoin-core-dev
 76 2017-09-28T05:13:32  *** ghost43 has joined #bitcoin-core-dev
 77 2017-09-28T05:17:42  *** Geoffy has joined #bitcoin-core-dev
 78 2017-09-28T05:27:32  *** Ylbam has joined #bitcoin-core-dev
 79 2017-09-28T05:41:35  *** twistedline has joined #bitcoin-core-dev
 80 2017-09-28T05:48:33  *** twistedline has quit IRC
 81 2017-09-28T05:49:50  *** M has joined #bitcoin-core-dev
 82 2017-09-28T05:50:14  *** M is now known as Guest54972
 83 2017-09-28T05:51:29  *** Guest54972 has quit IRC
 84 2017-09-28T05:53:22  *** lifeofguenter has quit IRC
 85 2017-09-28T05:56:24  *** twistedline has joined #bitcoin-core-dev
 86 2017-09-28T05:57:49  *** lifeofguenter has joined #bitcoin-core-dev
 87 2017-09-28T06:01:17  *** chjj has quit IRC
 88 2017-09-28T06:07:52  *** ghost43 has quit IRC
 89 2017-09-28T06:08:29  *** ghost43 has joined #bitcoin-core-dev
 90 2017-09-28T06:34:11  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/d90a00eabed0...c9a4aa8a0e7e
 91 2017-09-28T06:34:12  <bitcoin-git> bitcoin/master 3826253 Wladimir J. van der Laan: rpc: Handle `getinfo` locally in bitcoin-cli w/ `-getinfo`...
 92 2017-09-28T06:34:12  <bitcoin-git> bitcoin/master 5e69a43 John Newbery: Add test for bitcoin-cli -getinfo...
 93 2017-09-28T06:34:13  <bitcoin-git> bitcoin/master c9a4aa8 Wladimir J. van der Laan: Merge #10871: Handle getinfo in bitcoin-cli w/ -getinfo (revival of #8843)...
 94 2017-09-28T06:34:38  <bitcoin-git> [bitcoin] laanwj closed pull request #10871: Handle getinfo in bitcoin-cli w/ -getinfo (revival of #8843) (master...cli-getinfo) https://github.com/bitcoin/bitcoin/pull/10871
 95 2017-09-28T06:35:40  *** wittysense has joined #bitcoin-core-dev
 96 2017-09-28T06:38:50  *** ghost43 has quit IRC
 97 2017-09-28T06:39:04  *** ghost43 has joined #bitcoin-core-dev
 98 2017-09-28T06:40:35  *** wittysense has quit IRC
 99 2017-09-28T06:43:17  *** meshcollider has quit IRC
100 2017-09-28T06:44:36  <bitcoin-git> [bitcoin] kallewoof opened pull request #11413: [wallet] [rpc] sendtoaddress: Add explicit feerate option to sendtoaddress (master...explicit-fee) https://github.com/bitcoin/bitcoin/pull/11413
101 2017-09-28T06:44:59  *** chjj has joined #bitcoin-core-dev
102 2017-09-28T06:51:36  *** BashCo has quit IRC
103 2017-09-28T07:05:35  *** promag has joined #bitcoin-core-dev
104 2017-09-28T07:07:07  *** promag has quit IRC
105 2017-09-28T07:13:13  *** BashCo has joined #bitcoin-core-dev
106 2017-09-28T08:08:05  *** laurentmt has joined #bitcoin-core-dev
107 2017-09-28T08:13:51  *** laurentmt has quit IRC
108 2017-09-28T08:15:09  *** promag has joined #bitcoin-core-dev
109 2017-09-28T08:36:07  *** promag has quit IRC
110 2017-09-28T08:36:24  *** wittysense has joined #bitcoin-core-dev
111 2017-09-28T08:36:53  *** promag has joined #bitcoin-core-dev
112 2017-09-28T08:38:38  *** ThomasV has joined #bitcoin-core-dev
113 2017-09-28T08:41:11  <ThomasV> can someone clarify the syntax of importmulti?
114 2017-09-28T08:41:17  <ThomasV> "Array of strings giving pubkeys that must occur in the output or redeemscript"
115 2017-09-28T08:41:55  <ThomasV> does that mean that for each execution path of redeemScript, you have to import a different array of pubkeys?
116 2017-09-28T08:42:41  *** wittysense has quit IRC
117 2017-09-28T08:46:08  *** timothy has joined #bitcoin-core-dev
118 2017-09-28T08:49:11  <sipa> ThomasV: signing with anything other than pure multisig is not supported, so there can't be multiple execution paths
119 2017-09-28T08:49:49  <sipa> so no, it's just the list of all public keys that appear
120 2017-09-28T08:49:54  <ThomasV> sipa: will the syntax need to be changed for other scripts?
121 2017-09-28T08:50:05  <sipa> i think it's also only necessary for single-pubkey cases
122 2017-09-28T08:50:14  <sipa> if you give the redeemscript, you're good
123 2017-09-28T08:50:25  <sipa> if you want solvability or signability
124 2017-09-28T08:53:44  <sipa> ThomasV: the idea is you give a) what script/address you're interested in b) what you want for it (watching, solving, signing) c) all the information necessary for that (redeemscripts, public keys, private keys, ...)
125 2017-09-28T08:56:18  *** Ylbam has quit IRC
126 2017-09-28T08:56:38  <ThomasV> sipa: so if you pass pubkeys you do not need to pass redeemscript?
127 2017-09-28T08:57:29  <sipa> rather the other way around
128 2017-09-28T08:57:49  <sipa> passing pubkeys (i think) is only useful for single-key cases (pay to pubkey etc)
129 2017-09-28T08:58:23  <ThomasV> but why is it an array, then?
130 2017-09-28T08:58:56  <ThomasV> and the doc says  "Array of strings giving pubkeys that must occur in the output or redeemscript"
131 2017-09-28T08:59:13  <ThomasV> that suggests an execution path
132 2017-09-28T08:59:22  <sipa> yes - you're free to pass in multiple keys if they all appear
133 2017-09-28T08:59:29  <sipa> that doesn't mean that you need to
134 2017-09-28T08:59:36  <ThomasV> hmm
135 2017-09-28T08:59:43  <sipa> presumably it's for being future proofness
136 2017-09-28T09:00:07  <ThomasV> ok, so future plan is to extend that to arbitrary scripts?
137 2017-09-28T09:00:36  <sipa> we'll only ever be able to sign the scripts we can sign
138 2017-09-28T09:00:53  <sipa> importmulti is just a way for passing in all the information the signing logic may possibly need
139 2017-09-28T09:02:15  <gmaxwell> I don't believe its computationally tractable to be able to sign actually arbritary scripts.
140 2017-09-28T09:02:19  <ThomasV> sipa: the signing logic needs to know the position of the signature in the witness. this position may differ depending on the execution path
141 2017-09-28T09:02:43  <sipa> ThomasV: if it knows the redeemscript, it knows all possible execution paths
142 2017-09-28T09:02:44  <ThomasV> so I would expect that info to be passed to importmulti
143 2017-09-28T09:02:51  <gmaxwell> Though there are presumably large classes that could be signed automatically, or partially using the fill in the blanks technique.
144 2017-09-28T09:03:13  <sipa> (but currently no scripts with conditionals are supported in the signer)
145 2017-09-28T09:03:46  *** promag has quit IRC
146 2017-09-28T09:04:44  <ThomasV> sipa: it depends what you mean by "it knows". does the signing logic execute the redeem script in order to figure that out?
147 2017-09-28T09:05:00  <ThomasV> (or parse it)
148 2017-09-28T09:05:17  <sipa> it uses template matching
149 2017-09-28T09:05:41  <sipa> again, the current logic can't deal with anything other than P2PK, P2PKH, P2SH, and simple multisig
150 2017-09-28T09:05:49  <ThomasV> ok, so the only template it currently has is pure multisig
151 2017-09-28T09:06:06  <sipa> however, i believe that the interface for importmulti doesn't need changing
152 2017-09-28T09:06:15  <sipa> if the signing logic gets extended
153 2017-09-28T09:06:43  *** promag has joined #bitcoin-core-dev
154 2017-09-28T09:07:12  <sipa> say we'd add support for signing an A-and-B OR C-and-D like script, if you've given it the redeemscript (which includes the 4 pubkeys), it can theoretically sign for something like that
155 2017-09-28T09:08:28  *** intcat has quit IRC
156 2017-09-28T09:10:35  *** intcat has joined #bitcoin-core-dev
157 2017-09-28T09:14:46  <ThomasV> gmaxwell: signing arbitrary scripts is not tractable if you expect the signing logic to understand the script. however, I think that burden could be moved to the user who owns the privkey
158 2017-09-28T09:15:16  *** bitbee has quit IRC
159 2017-09-28T09:15:54  *** bitbee has joined #bitcoin-core-dev
160 2017-09-28T09:16:07  <ThomasV> when you import a key, you could also tell the wallet in which context it should be used
161 2017-09-28T09:16:08  <gmaxwell> I think you're thinking of what I mean by fill in the blanks technique, where you attempt to verify the script, assume all checksigs pass and record their inputs, and then go and sign any that you know the keys for.
162 2017-09-28T09:16:27  <gmaxwell> or perhaps you didn't. :)
163 2017-09-28T09:17:53  <ThomasV> I mean to tell the wallet which execution path is the key for
164 2017-09-28T09:18:31  <sipa> i don't understand why that's necessary, if the wallet knows all execution paths anyway
165 2017-09-28T09:18:59  <ThomasV> the wallet does not know how the script is going to be executed
166 2017-09-28T09:19:05  <sipa> so?
167 2017-09-28T09:19:29  <ThomasV> so, if I sign a transaction, I should provide that info
168 2017-09-28T09:19:31  *** bitbee has quit IRC
169 2017-09-28T09:19:47  <sipa> usually there are just a few branches, it can easily try all of that
170 2017-09-28T09:20:09  *** bitbee has joined #bitcoin-core-dev
171 2017-09-28T09:21:05  <sipa> but in general - i'm sure there are cases where it's not feasible (say you have 30 independent conditionals - you'd need to try 2^30 combinations)
172 2017-09-28T09:21:14  <ThomasV> sipa: there might be branches that you do not want to sign.
173 2017-09-28T09:22:10  <gmaxwell> ThomasV: I don't follow, it's for the execution path(s) that involve the corresponding public key.
174 2017-09-28T09:22:14  <sipa> at some point you can't expect a generic wallet to deal with arbitrarily complex scenarios, and you'll just need to write your own software i think
175 2017-09-28T09:23:42  <ThomasV> gmaxwell: maybe the same pubkey occurs in 2 branches
176 2017-09-28T09:24:38  <gmaxwell> Then it's the same secret... which choice you were signing with would be a signing time decision, I think, not an importmulti-time decision.
177 2017-09-28T09:25:55  <ThomasV> gmaxwell: exactly. my point is that making it an import time decision makes signing arbitrary scripts a lot simpler.
178 2017-09-28T09:26:30  <ThomasV> you only need to pass the position of the signature in the witness, and the length of the witness
179 2017-09-28T09:26:45  <ThomasV> and you don't need to fill the blanks, or parse scripts
180 2017-09-28T09:27:01  <gmaxwell> I don't follow your thinking at all there.
181 2017-09-28T09:27:56  <sipa> if there is a script that has a pubkey in multiple branches, meaning you're able to participate in multiple branches, and you have that key... why would you - at importing time - want to be forced to choose only one of those branches?
182 2017-09-28T09:28:12  <ThomasV> gmaxwell: import_privkey_with_role(privkey, redeemscript, role_in_witness)
183 2017-09-28T09:28:12  <sipa> sure, you may want to make that choice at signing time
184 2017-09-28T09:28:16  <gmaxwell> that sounds like you're thinking signatures in the witness always have a fixed position? they don't.. okay but I understand why you wouldn't want any understanding of script in general.
185 2017-09-28T09:28:41  <sipa> with signature aggregation there will just be a single signature anyway :)
186 2017-09-28T09:28:48  <sipa> much easier! *ducks*
187 2017-09-28T09:29:06  <ThomasV> gmaxwell: my point is precisely that they do not have a fixed position. that's what I mean by role
188 2017-09-28T09:29:29  <gmaxwell> but since a "stick signature in this position" approach cannot sign arbritary scripts or even remotely arbritary, is it really that unreasonable to do simple template matching of the script?
189 2017-09-28T09:30:04  <ThomasV> gmaxwell: why can't it sign arbitrary scripts?
190 2017-09-28T09:30:41  <ThomasV> the logic is "if I see that redeemscript, then I sign"
191 2017-09-28T09:30:59  <gmaxwell> ThomasV: because the position your signature needs to go into can depend on data set by another signer (for example) in each specific instance of signing.
192 2017-09-28T09:31:00  <ThomasV> no template matching needed
193 2017-09-28T09:31:47  <ThomasV> gmaxwell: in that case you import the same key with several roles
194 2017-09-28T09:32:22  <gmaxwell> e.g. if you have a signature that has a policy that looks like  (A || (B && C)) && D and you are D, the stack element your will sign with depends on which of the paths are in use by the OR people.
195 2017-09-28T09:33:00  <gmaxwell> ThomasV: well that would be a very inefficient interface if there were many paths, I don't think it would make sense for us to do it that way, since we can simply just run through the script and see what is actually needed.
196 2017-09-28T09:33:43  <gmaxwell> Esp with recently proposed future enancements e.g. mark or jl's tree constructions, there could be a huhdred possible locations for a redeemscript.
197 2017-09-28T09:33:48  *** promag has quit IRC
198 2017-09-28T09:34:23  <sipa> i'm sure there could be an alternate more lowlevel interface, where you say "this redeemscript can be signed for with this witness template... with a signature-for-key-A in position this, and a signature-for-key-B in position this, ..."
199 2017-09-28T09:34:54  <sipa> but that question isn't even relevant at this point - we only do signing of specific templates anyway
200 2017-09-28T09:35:23  <sipa> which i think will cover the vast majority of use cases - especially the uses cases for those who aren't able to write custom signing code themselves
201 2017-09-28T09:36:01  *** promag has joined #bitcoin-core-dev
202 2017-09-28T09:36:04  <gmaxwell> well the fill in the blanks would cover a far greater subset of those...
203 2017-09-28T09:36:32  <sipa> with MAST-like constructions something like that could make sense - where you're able to sign for a MAST root even if you don't know all MAST branches - only the ones you participate in
204 2017-09-28T09:40:11  *** goatpig has quit IRC
205 2017-09-28T09:43:17  *** eck has quit IRC
206 2017-09-28T09:44:03  *** eck has joined #bitcoin-core-dev
207 2017-09-28T09:44:21  *** promag has quit IRC
208 2017-09-28T09:44:39  <ThomasV> gmaxwell: good point. indeed, that would be inefficient.
209 2017-09-28T09:48:01  <ThomasV> sipa: so, the witness of a partially signed transaction would be a tree? in greg's example: ((sigA (sigB, sigC)), sigD), where sigX is either a signature or an empty placeholder
210 2017-09-28T09:48:36  <ThomasV> until it's fully signed
211 2017-09-28T09:49:18  <sipa> ThomasV: have you seen achow101'w partially signed transaction format?
212 2017-09-28T09:49:53  <ThomasV> no
213 2017-09-28T09:50:20  <ThomasV> is there a link?
214 2017-09-28T09:50:22  *** promag has joined #bitcoin-core-dev
215 2017-09-28T09:50:22  <sipa> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
216 2017-09-28T09:50:27  <ThomasV> thanks
217 2017-09-28T09:51:18  *** promag has quit IRC
218 2017-09-28T09:53:02  *** promag has joined #bitcoin-core-dev
219 2017-09-28T10:08:27  *** dabura667 has quit IRC
220 2017-09-28T10:12:39  *** promag_ has joined #bitcoin-core-dev
221 2017-09-28T10:12:40  *** promag has quit IRC
222 2017-09-28T10:14:01  *** AaronvanW has joined #bitcoin-core-dev
223 2017-09-28T10:15:22  *** Aaronvan_ has joined #bitcoin-core-dev
224 2017-09-28T10:18:29  *** AaronvanW has quit IRC
225 2017-09-28T10:24:24  *** promag_ has quit IRC
226 2017-09-28T10:29:42  *** JackH has joined #bitcoin-core-dev
227 2017-09-28T10:38:25  *** ThomasV has quit IRC
228 2017-09-28T10:38:59  *** wittysense has joined #bitcoin-core-dev
229 2017-09-28T10:43:45  *** wittysense has quit IRC
230 2017-09-28T10:48:49  *** meshcollider has joined #bitcoin-core-dev
231 2017-09-28T10:48:54  *** promag has joined #bitcoin-core-dev
232 2017-09-28T11:05:17  *** StopAndDecrypt_ has joined #bitcoin-core-dev
233 2017-09-28T11:09:22  *** aguycalled has joined #bitcoin-core-dev
234 2017-09-28T11:09:25  *** tiagotrs has joined #bitcoin-core-dev
235 2017-09-28T11:11:57  *** wump is now known as wumpus
236 2017-09-28T11:16:55  *** aguycalled has quit IRC
237 2017-09-28T11:18:57  *** promag has quit IRC
238 2017-09-28T11:20:14  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9a4aa8a0e7e...4202273ffa45
239 2017-09-28T11:20:14  <bitcoin-git> bitcoin/master fa082b4 MarcoFalke: doc: move gitian building to external repo...
240 2017-09-28T11:20:15  <bitcoin-git> bitcoin/master 4202273 Wladimir J. van der Laan: Merge #11401: doc: move gitian building to external repo...
241 2017-09-28T11:20:36  *** promag has joined #bitcoin-core-dev
242 2017-09-28T11:20:59  <bitcoin-git> [bitcoin] laanwj closed pull request #11401: doc: move gitian building to external repo (master...Mf1708-docGitianFedora) https://github.com/bitcoin/bitcoin/pull/11401
243 2017-09-28T11:23:45  *** JackH has quit IRC
244 2017-09-28T11:23:47  *** SopaXorzTaker has quit IRC
245 2017-09-28T11:24:22  *** SopaXorzTaker has joined #bitcoin-core-dev
246 2017-09-28T11:24:24  *** laurentmt has joined #bitcoin-core-dev
247 2017-09-28T11:25:34  *** promag has quit IRC
248 2017-09-28T11:42:23  *** m8tion has joined #bitcoin-core-dev
249 2017-09-28T11:43:22  *** wxxs has joined #bitcoin-core-dev
250 2017-09-28T11:49:08  *** belcher has quit IRC
251 2017-09-28T11:53:57  *** JackH has joined #bitcoin-core-dev
252 2017-09-28T12:01:31  *** belcher has joined #bitcoin-core-dev
253 2017-09-28T12:03:34  *** Ylbam has joined #bitcoin-core-dev
254 2017-09-28T12:20:50  *** ThomasV has joined #bitcoin-core-dev
255 2017-09-28T12:29:22  *** ThomasV has quit IRC
256 2017-09-28T12:37:25  *** tiagotrs has quit IRC
257 2017-09-28T12:39:40  *** wittysense has joined #bitcoin-core-dev
258 2017-09-28T12:44:21  *** wittysense has quit IRC
259 2017-09-28T12:58:40  *** owowo has quit IRC
260 2017-09-28T13:03:28  *** owowo has joined #bitcoin-core-dev
261 2017-09-28T13:04:35  *** wittysense has joined #bitcoin-core-dev
262 2017-09-28T13:10:48  <bitcoin-git> [bitcoin] fanquake opened pull request #11414: [docs] Remove partial gitian build instructions from descriptors dir. (master...gitian-cleanups) https://github.com/bitcoin/bitcoin/pull/11414
263 2017-09-28T13:16:28  *** promag has joined #bitcoin-core-dev
264 2017-09-28T13:37:32  *** Deacyded has quit IRC
265 2017-09-28T13:39:01  *** Deacyded has joined #bitcoin-core-dev
266 2017-09-28T13:40:30  *** afk11 has quit IRC
267 2017-09-28T13:40:49  *** afk11 has joined #bitcoin-core-dev
268 2017-09-28T13:46:18  *** Guyver2 has joined #bitcoin-core-dev
269 2017-09-28T13:58:31  *** meshcollider has quit IRC
270 2017-09-28T14:04:34  *** justanotheruser has quit IRC
271 2017-09-28T14:10:16  *** test123 has joined #bitcoin-core-dev
272 2017-09-28T14:14:11  *** tiagotrs has joined #bitcoin-core-dev
273 2017-09-28T14:14:31  *** test123 has quit IRC
274 2017-09-28T14:14:47  *** wraithm has joined #bitcoin-core-dev
275 2017-09-28T14:15:08  *** tiagotrs has quit IRC
276 2017-09-28T14:15:08  *** tiagotrs has joined #bitcoin-core-dev
277 2017-09-28T14:23:18  *** Ylbam has quit IRC
278 2017-09-28T14:28:05  *** promag has quit IRC
279 2017-09-28T14:28:41  *** Ylbam has joined #bitcoin-core-dev
280 2017-09-28T14:28:47  *** promag has joined #bitcoin-core-dev
281 2017-09-28T14:39:53  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/4202273ffa45...9a8e9167f263
282 2017-09-28T14:39:54  <bitcoin-git> bitcoin/master f77f0e4 Andrew Chow: Add warnings field to getblockchaininfo
283 2017-09-28T14:39:54  <bitcoin-git> bitcoin/master 8502b20 Andrew Chow: Unify help text for GetWarnings output in get*info RPCs
284 2017-09-28T14:39:55  <bitcoin-git> bitcoin/master 395cef7 Andrew Chow: Change getmininginfo errors field to warnings...
285 2017-09-28T14:40:23  <bitcoin-git> [bitcoin] laanwj closed pull request #10858: [RPC] Add "errors" field to getblockchaininfo and unify "errors" field in get*info RPCs (master...getblockchaininfo-errors) https://github.com/bitcoin/bitcoin/pull/10858
286 2017-09-28T14:46:00  *** promag has quit IRC
287 2017-09-28T14:57:28  *** vicenteH has quit IRC
288 2017-09-28T15:06:28  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/9a8e9167f263...9d31ed2e69fd
289 2017-09-28T15:06:29  <bitcoin-git> bitcoin/master 2416dd7 Cory Fields: net: separate resolving and conecting...
290 2017-09-28T15:06:29  <bitcoin-git> bitcoin/master 45fd754 Cory Fields: net: remove now-superfluous numeric resolve...
291 2017-09-28T15:06:30  <bitcoin-git> bitcoin/master b887676 Cory Fields: net: remove now-unused functions
292 2017-09-28T15:07:13  <bitcoin-git> [bitcoin] laanwj closed pull request #10663: net: split resolve out of connect (master...split-resolve-connect) https://github.com/bitcoin/bitcoin/pull/10663
293 2017-09-28T15:15:52  *** Murch has joined #bitcoin-core-dev
294 2017-09-28T15:19:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
295 2017-09-28T15:40:53  *** vicenteH has joined #bitcoin-core-dev
296 2017-09-28T15:58:21  *** promag has joined #bitcoin-core-dev
297 2017-09-28T15:58:43  *** wraithm has quit IRC
298 2017-09-28T15:58:44  *** wraithm has joined #bitcoin-core-dev
299 2017-09-28T16:01:47  *** JackH has quit IRC
300 2017-09-28T16:06:00  *** devid has quit IRC
301 2017-09-28T16:12:55  *** BashCo has quit IRC
302 2017-09-28T16:29:17  *** promag has quit IRC
303 2017-09-28T16:31:51  *** BashCo has joined #bitcoin-core-dev
304 2017-09-28T16:59:20  *** laurentmt has quit IRC
305 2017-09-28T17:00:23  <jonasschnelli> BlueMatt: how did you know I'm working on the RPC long poll notifications?
306 2017-09-28T17:00:54  <jonasschnelli> I started to pick it up yesterday
307 2017-09-28T17:06:10  *** timothy has quit IRC
308 2017-09-28T17:11:00  <BlueMatt> lol, I'm just going through old prs
309 2017-09-28T17:11:45  *** curioso has joined #bitcoin-core-dev
310 2017-09-28T17:14:31  <jtimon> I'm going to miss the meeting, review beg #8498 and #8994 if at any moment seems relevant
311 2017-09-28T17:14:34  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
312 2017-09-28T17:14:34  *** Emcy has joined #bitcoin-core-dev
313 2017-09-28T17:14:35  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
314 2017-09-28T17:17:10  *** Emcy_ has quit IRC
315 2017-09-28T17:18:12  <jtimon> and https://github.com/bitcoin/bitcoin/pull/10669 too, why not?
316 2017-09-28T17:25:36  *** goatpig has joined #bitcoin-core-dev
317 2017-09-28T17:26:01  *** Chris_Stewart_5 has quit IRC
318 2017-09-28T17:26:15  *** promag has joined #bitcoin-core-dev
319 2017-09-28T17:33:54  *** wittysense has quit IRC
320 2017-09-28T17:34:05  *** Evel-Knievel has quit IRC
321 2017-09-28T17:35:59  *** Emcy_ has joined #bitcoin-core-dev
322 2017-09-28T17:36:33  *** jtimon has quit IRC
323 2017-09-28T17:38:26  *** Emcy has quit IRC
324 2017-09-28T17:46:08  *** promag has quit IRC
325 2017-09-28T17:46:09  *** tiagotrs has quit IRC
326 2017-09-28T17:54:45  *** wvr has joined #bitcoin-core-dev
327 2017-09-28T17:55:42  *** meshcollider has joined #bitcoin-core-dev
328 2017-09-28T17:56:30  *** m8tion has quit IRC
329 2017-09-28T17:56:48  *** chjj has quit IRC
330 2017-09-28T18:02:13  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9d31ed2e69fd...a72003d794f3
331 2017-09-28T18:02:13  <bitcoin-git> bitcoin/master d552ed6 Paul Berg: Put back inadvertently removed copyright notices...
332 2017-09-28T18:02:14  <bitcoin-git> bitcoin/master a72003d Wladimir J. van der Laan: Merge #11318: Put back inadvertently removed copyright notices...
333 2017-09-28T18:02:54  <bitcoin-git> [bitcoin] laanwj closed pull request #11318: Put back inadvertently removed copyright notices (master...fix_copying) https://github.com/bitcoin/bitcoin/pull/11318
334 2017-09-28T18:04:10  <meshcollider> Heh I was expecting the meeting to be now, but New Zealand just switched to daylight savings time so I'm an hour early
335 2017-09-28T18:06:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
336 2017-09-28T18:11:04  *** mess110 has joined #bitcoin-core-dev
337 2017-09-28T18:15:34  <bitcoin-git> [bitcoin] danra closed pull request #11306: Refactor: Move core files from src root to src/core and improve inclu… (master...refactor/core-files) https://github.com/bitcoin/bitcoin/pull/11306
338 2017-09-28T18:18:17  *** wittysense has joined #bitcoin-core-dev
339 2017-09-28T18:25:42  *** promag has joined #bitcoin-core-dev
340 2017-09-28T18:30:02  *** promag has quit IRC
341 2017-09-28T18:35:11  <wumpus> yeah, DST remains an ever present source of annoyance with timing international meetings
342 2017-09-28T18:36:22  <wumpus> still a month to go here, october 29 winter time starts in NL
343 2017-09-28T18:41:07  <Sentineo> I like this period though, US will switch 2 weaks before Europe to winter time. So there i less time difference ;)
344 2017-09-28T18:44:24  *** JackH has joined #bitcoin-core-dev
345 2017-09-28T18:56:29  *** JackH has quit IRC
346 2017-09-28T18:56:57  *** abpa has joined #bitcoin-core-dev
347 2017-09-28T18:59:24  <luke-jr> you should all just adopt a tonal timezone-less clock ;)
348 2017-09-28T19:00:38  <luke-jr> meeting is at .9 regardless of what part of the year
349 2017-09-28T19:01:12  <instagibbs> meeting is now?
350 2017-09-28T19:01:24  <wumpus> yes
351 2017-09-28T19:01:28  <petertodd> if it is, then hi
352 2017-09-28T19:01:29  <wumpus> #startmeeting
353 2017-09-28T19:01:29  <lightningbot> Meeting started Thu Sep 28 19:01:29 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
354 2017-09-28T19:01:29  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
355 2017-09-28T19:01:35  <achow101> hi
356 2017-09-28T19:01:36  <meshcollider> Hello again
357 2017-09-28T19:01:47  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
358 2017-09-28T19:01:48  <meshcollider> lightningbot?
359 2017-09-28T19:02:10  <cfields> hi
360 2017-09-28T19:02:20  <wumpus> luke-jr: yes, you could ignore DST for yourself and live in GMT time, the difficulty is shop opening times and such :)
361 2017-09-28T19:02:22  <jnewbery> hi
362 2017-09-28T19:02:23  <kanzure> hi.
363 2017-09-28T19:02:29  <Chris_Stewart_5> hello
364 2017-09-28T19:02:32  <wumpus> oh no the bot is missing
365 2017-09-28T19:02:38  <wumpus> #action find the bot
366 2017-09-28T19:02:46  <achow101> is it?
367 2017-09-28T19:02:58  <petertodd> wumpus: one of the perils of replacing humans with machines
368 2017-09-28T19:03:13  <wumpus> ehh.. no it isn't, sorry
369 2017-09-28T19:03:33  <wumpus> petertodd: but it lives in the cloud! humans can't live in a cloud!
370 2017-09-28T19:03:42  <wumpus> #topic High priority for review
371 2017-09-28T19:04:00  * BlueMatt 's is staying....
372 2017-09-28T19:04:01  <BlueMatt> again
373 2017-09-28T19:04:22  <BlueMatt> 10663 got merged
374 2017-09-28T19:04:25  <BlueMatt> same with 10871
375 2017-09-28T19:04:44  <jonasschnelli> hi
376 2017-09-28T19:04:45  <wumpus> yes, finally
377 2017-09-28T19:04:57  <BlueMatt> =D
378 2017-09-28T19:05:19  <wumpus> BlueMatt: yours has wallet in the name, that seems to put a curse on it with regard to reviewers
379 2017-09-28T19:05:31  <luke-jr> XD
380 2017-09-28T19:05:33  <jonasschnelli> Maybe someone can review #10387 (in high prio), ideally cfields
381 2017-09-28T19:05:35  <gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Implement BIP159, define and signal NODE_NETWORK_LIMITED (pruned peers) by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
382 2017-09-28T19:05:45  <jonasschnelli> Would be great to have this in 0.16
383 2017-09-28T19:05:55  <wumpus> which reminds me
384 2017-09-28T19:05:57  <cfields> jonasschnelli: will do asap
385 2017-09-28T19:06:01  <wumpus> #topic put up 0.16 release schedule
386 2017-09-28T19:06:04  <jonasschnelli> cfields: thanks!
387 2017-09-28T19:06:11  <BlueMatt> wumpus: yea, I think so...I havent been pushing it cause folks want 0.15.1 first, but afterwards I really want that to go in asap, cause I really want to have it in early in 0.16 so it simmers for months
388 2017-09-28T19:06:40  <wumpus> 10387 is already in "high priority for review"
389 2017-09-28T19:06:45  <jonasschnelli> Yes
390 2017-09-28T19:06:49  <wumpus> BlueMatt: seems it has had quite some review though
391 2017-09-28T19:06:52  <jonasschnelli> Just no reviews. :)
392 2017-09-28T19:06:58  <BlueMatt> #11089 needs to get removed from high priority, it needs major rebase
393 2017-09-28T19:07:00  <gribble> https://github.com/bitcoin/bitcoin/issues/11089 | Enable various p2sh-p2wpkh functionality by luke-jr · Pull Request #11089 · bitcoin/bitcoin · GitHub
394 2017-09-28T19:07:02  <achow101> #10637 for high prio review?
395 2017-09-28T19:07:05  <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
396 2017-09-28T19:07:17  <wumpus> BlueMatt: ok
397 2017-09-28T19:07:22  <gmaxwell> jonasschnelli: Oh, I'm surprised that patch is so large, I was kinda hoping to see it widely backported so pruned nodes on older branches could see it advertised.
398 2017-09-28T19:07:26  <jonasschnelli> Maybe next to the release schedule for 0.16, ... what do we want in 0.16?
399 2017-09-28T19:07:37  <sipa> most of 11089's functionality is included in #11403
400 2017-09-28T19:07:38  <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
401 2017-09-28T19:07:44  <jonasschnelli> gmaxwell: I'm happy if you see a way how to reduce it
402 2017-09-28T19:07:47  <jonasschnelli> Or split it
403 2017-09-28T19:08:07  <gmaxwell> jonasschnelli: yea, will look. Sorry, didn't see it until now.
404 2017-09-28T19:08:12  <wumpus> 11089 removed for now
405 2017-09-28T19:08:13  <jonasschnelli> Although +264 −13 shouldn't be too large
406 2017-09-28T19:08:27  <jonasschnelli> (incl. new test)
407 2017-09-28T19:08:54  <morcos> oh man i feel like i'm buried under PR's to review ...   maybe i'd make some progress if you could review via tweet
408 2017-09-28T19:09:02  <jonasschnelli> heh
409 2017-09-28T19:09:18  <luke-jr> would be nice to have GUI multiwallet in 0.16, but #10615 is stuck on desires for refactoring :/
410 2017-09-28T19:09:19  <gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
411 2017-09-28T19:09:40  <BlueMatt> luke-jr: I think it is unacceptable to add so many more ifdef WALLET in bitcoin server
412 2017-09-28T19:09:45  <jonasschnelli> luke-jr: can you remove the rpcauth part? It's not necesdarry and contraversial.
413 2017-09-28T19:09:48  <wumpus> this is tagged for 0.16 right now (both issues and PRs):https://github.com/bitcoin/bitcoin/milestones/0.16.0
414 2017-09-28T19:09:48  <BlueMatt> (and believe it would be easy to remove them)
415 2017-09-28T19:09:52  <gmaxwell> jonasschnelli: I don't understand why the flags set would change at runtime?  Setting the flag is a property of the node's configuration.
416 2017-09-28T19:10:03  <sipa> morcos: well there is @BitcoinMerges...
417 2017-09-28T19:10:08  <gmaxwell> (and in our case we don't have any configuration where it shouldn't be set, AFAIK)
418 2017-09-28T19:10:23  <wumpus> morcos: well at least we can fit twice as much code in a tweet now...
419 2017-09-28T19:10:24  <morcos> sipa: that's brilliant, at least it would constantly remind me
420 2017-09-28T19:10:29  <jonasschnelli> gmaxwell: maybe no longer required with a single NODE_NETWORK_LIMITED bit
421 2017-09-28T19:10:32  <luke-jr> jonasschnelli: I think that's possible, but I don't see why it should be controversial, and doesn't help with BlueMatt's refactoring wants
422 2017-09-28T19:10:49  <jonasschnelli> luke-jr: it's a fact that it is contraversial
423 2017-09-28T19:10:57  <jonasschnelli> * controversial
424 2017-09-28T19:11:05  <gmaxwell> jonasschnelli: ah! right, so this code was originally based on the more complex spec.
425 2017-09-28T19:11:11  <BlueMatt> luke-jr: I dont think I'm the only one who objects to ifdef wallet's being added to http server cpp files........
426 2017-09-28T19:11:31  <jonasschnelli> gmaxwell: thanks for pointing out... i'll review it and check if I can remove the runtime switching
427 2017-09-28T19:11:34  <wumpus> BlueMatt: no, you aren't, that's obviously wrong, we've been working hard to remove those as they cause circular refs :(
428 2017-09-28T19:11:49  <jnewbery> luke-jr: cherry-picking the non-controversial commits from your PR gives us the GUI functionality without adding a bunch of server->wallet dependencies or the rpcauth stuff
429 2017-09-28T19:12:15  <luke-jr> jnewbery: I don't see how that's possible
430 2017-09-28T19:12:20  <gmaxwell> jonasschnelli: my completely ignorant (only barely read the patch) thought is that there should be one commit which should be a nearly one line change to just set the bit everywhere.. then another commit or two for the relay, then another for selection.  And the first commit we'd backport, maybe the second, but not the third.
431 2017-09-28T19:12:45  <luke-jr> BlueMatt: so httprpc calls a callback for "populate JSONRequest with metadata" which is only used for this one thing?
432 2017-09-28T19:12:50  <luke-jr> BlueMatt: or what did you have in mind?
433 2017-09-28T19:12:53  <wumpus> see e.g. #7965. We want to go toward 0 wallet references in bitcoin_server
434 2017-09-28T19:12:54  <gribble> https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub
435 2017-09-28T19:13:14  <jonasschnelli> gmaxwell: I thought it is basically like that (factored in a bit more commits though)
436 2017-09-28T19:13:17  <achow101> wumpus: we can check getinfo off that list now
437 2017-09-28T19:13:25  <wumpus> achow101: thanks good point
438 2017-09-28T19:13:30  <BlueMatt> luke-jr: yes, that would be sufficient
439 2017-09-28T19:13:33  <BlueMatt> imo
440 2017-09-28T19:13:54  <luke-jr> ok, I'll try that
441 2017-09-28T19:13:58  <wumpus> achow101: updated
442 2017-09-28T19:14:15  <BlueMatt> luke-jr: you may wish to seek concept acks on the *idea* of rpc auth-based multiwallet
443 2017-09-28T19:14:20  <BlueMatt> I'm ok with it, but I dont know if others are
444 2017-09-28T19:14:28  <luke-jr> #action refactor #10615 for a "populate JSONRequest" callback, and separate out rpcauth stuff
445 2017-09-28T19:14:29  <gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
446 2017-09-28T19:14:54  <gmaxwell> jonasschnelli: ah, right though the setter isn't simple like I expected but now I understand why.
447 2017-09-28T19:14:54  <jonasschnelli> BlueMatt , luke-jr : the rpcauth multiwallet is completely orthogonal to GUI multiwallet
448 2017-09-28T19:14:59  <gmaxwell> and that should be fixable.
449 2017-09-28T19:15:23  <wumpus> jonasschnelli: indeed, let's not confound things unnecessarily
450 2017-09-28T19:15:33  *** Cheeseo has joined #bitcoin-core-dev
451 2017-09-28T19:15:34  <luke-jr> jonasschnelli: yeah, I'll split it off
452 2017-09-28T19:15:48  <jonasschnelli> yes. It's smells like smuggling in controversial stuff packed in a nice feature
453 2017-09-28T19:15:55  <gmaxwell> Yes, please split those things up. (I say this as a supporter of rpcauth based multiwallet control)
454 2017-09-28T19:16:04  <sipa> i'm ok with rpcauth-based multiwallet, but i think it may be a longer-term thing; it would probably require some review of security of non-wallet RPCs (should a wallet-specific rpc user be allowed to call stop?)
455 2017-09-28T19:16:25  <luke-jr> sipa: well, it wasn't meant to be a security thing, but maybe we can consider that
456 2017-09-28T19:16:44  <sipa> yeah, just saying - i think multiwallet gui can be done much faster
457 2017-09-28T19:16:47  <luke-jr> right
458 2017-09-28T19:16:48  <BlueMatt> I was assuming rpcauth-based multiwallet would only allow you to call wallet functions
459 2017-09-28T19:16:52  <sipa> everyone clearly wants it
460 2017-09-28T19:16:56  <gmaxwell> sipa: main interest I have in it is anti-footgun. Can't spend accidentally what you don't have access too.
461 2017-09-28T19:16:58  <jonasschnelli> rpcauth opens up the usecase and suddenly users think Core is a 100k multiuser wallet system
462 2017-09-28T19:17:08  <jonasschnelli> we just need to be sure we want this
463 2017-09-28T19:17:08  <wumpus> yes, multiwallet GUI isn't controversial in any way
464 2017-09-28T19:17:18  <gmaxwell> jonasschnelli: Then we can simply say it isn't. I don't think that is a good argument.
465 2017-09-28T19:17:38  <morcos> yeah lets pleast punt on rpcauth for now... seems better use of our time to move towards splitting off wallet
466 2017-09-28T19:17:41  <wumpus> the gui even has some scaffolding already to be able to handle multiple wallets IIRC, of course it's not complete
467 2017-09-28T19:17:43  <achow101> gmaxwell: people will probably still use it that way though
468 2017-09-28T19:17:46  <luke-jr> leaving `stop` etc accessible makes it clearly not that IMO
469 2017-09-28T19:17:48  <jonasschnelli> We may end up in the same situation like the accounts... i'm not against it. But we should discuss it wisely and not related to GUI multiwallet
470 2017-09-28T19:17:55  *** PaulCapestany has quit IRC
471 2017-09-28T19:18:01  <wumpus> morcos: +1, I'm kind of sick of discussing that tbh
472 2017-09-28T19:18:12  <jonasschnelli> `/rpcauth (ack)
473 2017-09-28T19:18:17  <luke-jr> wumpus: #11383 is there already, just needs to get past this initial stuff
474 2017-09-28T19:18:19  <gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
475 2017-09-28T19:18:25  <wumpus> luke-jr: yes
476 2017-09-28T19:18:38  <wumpus> so anything that needs to be discussed with regard to  GUI multiwallet?
477 2017-09-28T19:19:04  <luke-jr> someone mentioned that they think the current design is too unobservable
478 2017-09-28T19:19:05  <wumpus> if not, any other topics?
479 2017-09-28T19:19:14  <jonasschnelli> the UI itself is not clear yeat. But luke-jr first approach is something we could have in 0.16
480 2017-09-28T19:19:25  <BlueMatt> yes, next topic?
481 2017-09-28T19:19:40  <jonasschnelli> topic: I wanted to ask if there are opinions against the concept of RPC long poll
482 2017-09-28T19:19:47  <jonasschnelli> I'd like to work on this for 0.16
483 2017-09-28T19:19:48  <wumpus> #topic RPC long poll
484 2017-09-28T19:19:49  <sipa> i'd like to bring up segwit wallet support
485 2017-09-28T19:20:00  <luke-jr> proposed topic: would be nice to get some code review on https://github.com/BitcoinHardfork/bitcoin/pulls PRs before November in case we need it (other PRs welcome)
486 2017-09-28T19:20:10  <BlueMatt> jonasschnelli: please give a tl;dr; of what it is :)
487 2017-09-28T19:20:12  <wumpus> jonasschnelli: no, no problems with it, I think it's superior to other ways we've considered
488 2017-09-28T19:20:14  <jonasschnelli> RPC long poll would allow similar push benefits then ZMQ offers but without any dependencies
489 2017-09-28T19:20:29  <gmaxwell> jonasschnelli: long poll for what specifically?
490 2017-09-28T19:20:36  <luke-jr> jonasschnelli: we already have RPC long poll
491 2017-09-28T19:20:37  <wumpus> for any of the current notifications
492 2017-09-28T19:20:43  <wumpus> blocks, transactions, wallet events
493 2017-09-28T19:20:47  <gmaxwell> you mean like blocks and transactions...
494 2017-09-28T19:20:48  <jonasschnelli> you open an http connection (with a timeout of lets say 60seconds)... once a new block/tx pops in, you get it back and reopen the timeout 60 channel
495 2017-09-28T19:20:49  <gmaxwell> ah.
496 2017-09-28T19:20:58  <jonasschnelli> It's how Cellphone OSes do push notifications
497 2017-09-28T19:21:00  <wumpus> yes. the stuff that now requires launching an external notify script
498 2017-09-28T19:21:03  <jonasschnelli> very nat friendlly
499 2017-09-28T19:21:11  <wumpus> jonasschnelli: yes, it's very basic and easy to use
500 2017-09-28T19:21:19  <gmaxwell> Well. "Better than ZMQ"-- part of the argument against it in the past was socket monopolization but with libevent now that should be much less of an issue.
501 2017-09-28T19:21:22  <jonasschnelli> Very easy to use... no ZMQ library, just an http client
502 2017-09-28T19:21:24  <sdaftuar> how does reopening work?  i don't understand how you avoid missing transactions in between
503 2017-09-28T19:21:41  <luke-jr> gmaxwell: hopefully. libevent has a history of having problems in this area IIRC
504 2017-09-28T19:21:46  <jonasschnelli> sdaftuar: you just open the http channel again... there is a queue on the server..
505 2017-09-28T19:21:47  <wumpus> it's not meant as a competition to ZMQ, ZMQ will stay
506 2017-09-28T19:21:51  <jonasschnelli> losing notifications is impossible
507 2017-09-28T19:21:57  <jonasschnelli> (or very unlikely)
508 2017-09-28T19:22:02  <luke-jr> sdaftuar: you have a session
509 2017-09-28T19:22:12  <gmaxwell> jonasschnelli: impossible and very unlikely are not the same. :P
510 2017-09-28T19:22:21  <cfields> didn't we have this discussion wrt waitfornewblock and friends? I'm missing how this is different
511 2017-09-28T19:22:23  <wumpus> zmq is for low latency notifications, longpoll is for easy notifications over the same channel RPC already works
512 2017-09-28T19:22:25  <jonasschnelli> yeah.. probably same level then ZMQ (where you can also loose nots)
513 2017-09-28T19:22:43  <wumpus> zmq requires careful extra setup
514 2017-09-28T19:22:50  <luke-jr> or order the events, and have the client request with the last-seen-event (as GBT does)
515 2017-09-28T19:22:52  <jonasschnelli> It would allow clients to better interect with Core without opening an ZMQ & RPC channel (only RPC)
516 2017-09-28T19:22:56  <gmaxwell> if you are using it to notice new transactions, losing a message means you fail to credit a customer with a $10,000 deposit... and look like a theif or even actually lose the money. :)
517 2017-09-28T19:23:00  <jonasschnelli> and it would allow *auth based notifications"
518 2017-09-28T19:23:03  <jonasschnelli> like wallet notifications
519 2017-09-28T19:23:10  <jonasschnelli> (which should be behing the auth)
520 2017-09-28T19:23:33  <jonasschnelli> notifications may lead to an RPC roundtrip...
521 2017-09-28T19:23:40  <wumpus> gmaxwell: true, but the -Xnotify that launches a script can also fail to launch a script in some cases, losing notification
522 2017-09-28T19:23:41  <BlueMatt> if its for wallet you can just use it to get info about when you need to call listsinceblock
523 2017-09-28T19:23:43  <gmaxwell> ZMQ has wire protocol incompatiblity between versions, which makes it harder to use except in very tightly coupled setups.
524 2017-09-28T19:23:44  <jonasschnelli> It just ellimitens constant triggering
525 2017-09-28T19:23:50  <BlueMatt> which isnt so bad...but for mempool its unclear how you can do it safely
526 2017-09-28T19:23:55  <wumpus> gmaxwell: we have to be realistic too
527 2017-09-28T19:23:59  <sipa> wumpus: but on the next notification you'll notice it
528 2017-09-28T19:24:11  <gmaxwell> wumpus: Is there a reason we can't give a reliable notification?
529 2017-09-28T19:24:12  <wumpus> sipa: yes, that's why the zmq notifications have sequence numebrs too
530 2017-09-28T19:24:15  <luke-jr> we probably don't want to use the same LP for wallet and non-wallet
531 2017-09-28T19:24:41  <wumpus> sipa: you'll notice that you've lost an event, you just don't know what it is so need to do reconciliation in that case
532 2017-09-28T19:24:54  <jonasschnelli> My LP PR (which I'm currently re-doing) has sequence numbers
533 2017-09-28T19:25:02  <cfields> ah
534 2017-09-28T19:25:04  <wumpus> gmaxwell: well the problem is that send buffers can be full
535 2017-09-28T19:25:16  <jonasschnelli> If you miss a notification, do a data re-sync
536 2017-09-28T19:25:19  <sipa> i wonder if we shouldn't think about something more generic... you configure "i have an RPC client, which is interested in all events which satisfy condition X, Y, Z....", and then there can be means for the client to read the event log, or get notifications when there are new events, ...
537 2017-09-28T19:25:20  <wumpus> gmaxwell: 100%(ish) reliable notifications means storing them to disk if the client isn't processing them
538 2017-09-28T19:25:34  <sipa> and the server keeps track of what the client has seen and hasn't
539 2017-09-28T19:25:50  <BlueMatt> (as long as all of those events come out of the CValidationInterface =D)
540 2017-09-28T19:25:53  <luke-jr> sipa: that makes me think of pruning - "I need to use block data, so don't prune until I say I'm done with it"
541 2017-09-28T19:25:53  <wumpus> gmaxwell: I mean reliable messaging/notification is a huge topic in itself..
542 2017-09-28T19:26:02  <luke-jr> sipa: not the same thing, but perhaps has some overlap
543 2017-09-28T19:26:04  <gmaxwell> wumpus: or allowing the send buffer to grow to the point that it gets swapped out and ultimately crashes. :)
544 2017-09-28T19:26:10  <sipa> luke-jr: indeed, it seems related
545 2017-09-28T19:26:19  <wumpus> gmaxwell: yes, in which case it's lost too
546 2017-09-28T19:26:21  <jonasschnelli> sipa: my LP PR does basically something like that. You can register a UUID for notifications and the server keeps track what you have received and what not
547 2017-09-28T19:26:29  <jonasschnelli> It's multi-client capable
548 2017-09-28T19:26:46  <wumpus> luke-jr: yeah there's certainly overlap there
549 2017-09-28T19:26:52  <gmaxwell> wumpus: yes, though cold start init is something that everything has to have and has to have tested, as it happens at every start.
550 2017-09-28T19:26:56  <wumpus> luke-jr: block consumers ideally should be able to set a low-water mark
551 2017-09-28T19:27:14  <luke-jr> maybe they should share jonasschnelli's UUID
552 2017-09-28T19:27:18  <wumpus> gmaxwell: well it needs reconciliation, you could also do that if you miss a notification ( which can be detected from the sequence number)
553 2017-09-28T19:27:40  <wumpus> gmaxwell: so if you have something to handle potential crashes, you also have something to handle the case where a message gets lost
554 2017-09-28T19:27:42  <luke-jr> although for block consumption, we'd want to store it in a persistent db IMO
555 2017-09-28T19:28:02  <luke-jr> (or could use rwconf and have a config param, but that seems ugly for this)
556 2017-09-28T19:28:16  <gmaxwell> obligitory question: Is any user asking for this or is it just interesting?
557 2017-09-28T19:28:39  <jonasschnelli> gmaxwell: Yes. Me as an user... :)
558 2017-09-28T19:28:42  <wumpus> yes yes yes
559 2017-09-28T19:28:48  <luke-jr> gmaxwell: the block consumption part would allow Armory to do pruning, at least ;0
560 2017-09-28T19:28:51  <wumpus> joinmarket for example would like a better notification mechanism
561 2017-09-28T19:28:52  <jonasschnelli> (for the hardware wallet client i'm working)
562 2017-09-28T19:28:55  <cfields> luke-jr: hmm, so clients could issue a single rpc command and have new blocks announcements replayed after a day offline?
563 2017-09-28T19:29:09  <wumpus> gmaxwell: they currently have a hack where you have to set walletnotify in bitcoin.conf, which isn't very flexible and easy to forget
564 2017-09-28T19:29:10  *** SopaXorzTaker has quit IRC
565 2017-09-28T19:29:15  <luke-jr> cfields: I don't see why not
566 2017-09-28T19:29:23  <wumpus> gmaxwell: if their software could just subscribe to events through RPC, that problem'd be solved
567 2017-09-28T19:29:33  <cfields> that's interesting
568 2017-09-28T19:29:34  <jonasschnelli> See also https://github.com/bitcoin/bitcoin/pull/10554
569 2017-09-28T19:29:35  <gmaxwell> wumpus: why doesn't it just poll?
570 2017-09-28T19:29:36  <wumpus> no need for restarting bitcoind even!
571 2017-09-28T19:29:37  <jonasschnelli> #10554
572 2017-09-28T19:29:39  <gribble> https://github.com/bitcoin/bitcoin/issues/10554 | ZMQ: add publishers for wallet transactions. by somdoron · Pull Request #10554 · bitcoin/bitcoin · GitHub
573 2017-09-28T19:29:41  <BlueMatt> jonasschnelli: if its not a big bother, then, as wumpus points out, can you ask the joinmarket guys if your proposed protocol is sufficient for them? would be good to be in sync on it
574 2017-09-28T19:29:52  <luke-jr> related: my GUI NetWatch branch has a circular memory-efficient buffer of weak-linked txs and blocks
575 2017-09-28T19:29:53  <wumpus> gmaxwell: because polling sucks
576 2017-09-28T19:29:55  <jonasschnelli> BlueMatt: good point
577 2017-09-28T19:30:10  <wumpus> it causes extra delays, at least, and uses more CPU time
578 2017-09-28T19:30:25  <wumpus> (depending on how fast you poll)
579 2017-09-28T19:30:40  <jonasschnelli> wumpus: and the UX may suck,... LP gives you a TX, block within ms not s
580 2017-09-28T19:30:51  <wumpus> I really don't understand why we're arguing whether to add a sane notification system at all and considering repetitive polling good enough
581 2017-09-28T19:30:52  <gmaxwell> ISTM the caller will need a consierable amount of complexity to avoid losing data, vs sending a poll every coupld seconds.  Polling faster than seconds hardly makes sense in the context of bitcoin in any case, since txn take seconds to propagate through the network.
582 2017-09-28T19:31:08  <gmaxwell> wumpus: because we already have one almost unused unreliable notification system.
583 2017-09-28T19:31:16  <wumpus> sigh, never mind
584 2017-09-28T19:31:19  <wumpus> another topic?
585 2017-09-28T19:31:24  <jonasschnelli> sipa had one
586 2017-09-28T19:31:34  <gmaxwell> bleh, I'm not trying to bludgon it.
587 2017-09-28T19:31:35  <wumpus> and no, zmq is not unused
588 2017-09-28T19:31:52  <jonasschnelli> IMO it is heavely used in some enterprises
589 2017-09-28T19:31:53  <wumpus> just that you're not using  or it's not good/reliable enough for you it doesn't mean no one is using it
590 2017-09-28T19:32:10  <gmaxwell> I've never encountered someone using it in production. I don't doubt that it is somewhere.
591 2017-09-28T19:32:17  <wumpus> as I've said many times, loss of messages can be handled if it can be detected, and it can be detected using the sequence numbers
592 2017-09-28T19:32:23  * BlueMatt 's preferred method of notification is the "hey, you should poll now" method
593 2017-09-28T19:32:26  <sipa> i think there is a lot of merit in creating a reliable event logging system for clients to observe
594 2017-09-28T19:32:36  <luke-jr> BlueMatt: indeed, blocknotify is sane IMO
595 2017-09-28T19:32:41  <sipa> if we have that, adding a notification for "you have new events!" seems both trivial and obvious
596 2017-09-28T19:32:52  <jnewbery> suggested topic: next Bitcoin Core meetup
597 2017-09-28T19:32:58  <jonasschnelli> BlueMatt: ZMQ / LP is  "hey, you should poll now"
598 2017-09-28T19:32:59  <cfields> agreed. and agree with wumpus. Seems like a no-brainer to me.
599 2017-09-28T19:33:00  <luke-jr> jnewbery: another one?
600 2017-09-28T19:33:01  <jonasschnelli> We only send hashes
601 2017-09-28T19:33:19  <BlueMatt> jonasschnelli: I wouldnt even send hashes
602 2017-09-28T19:33:27  <gmaxwell> But we don't get a report flow on it that suggests that its in use...  And the advice I give is to poll because it's reliable, hard to get wrong, and has no scaling issues on any system that can keep up with the network.   And the reason I was asking questions is because I was trying to understand what the gain in having another one would be... one thought I had was maybe it would be more reliab
603 2017-09-28T19:33:30  <BlueMatt> just do the old "disconnect upon new data" pattern
604 2017-09-28T19:33:33  <gmaxwell> le, but I see why thats hard.
605 2017-09-28T19:33:35  <luke-jr> blocknotify='killall -USR1 programname' ☺
606 2017-09-28T19:33:55  *** bitsegwit has joined #bitcoin-core-dev
607 2017-09-28T19:34:08  <sipa> 19:19:49 < sipa> i'd like to bring up segwit wallet support
608 2017-09-28T19:34:20  <wumpus> gmaxwell: you can do polling in addition to processing notifications, that's what I mean with 'reconciliation'
609 2017-09-28T19:34:24  <morcos> notification system for topic suggestions?
610 2017-09-28T19:34:39  <gmaxwell> Obviously if people want to work on it, I don't mind. I'll even spend some time reviewing it.  But there are so many other things we've left half complete... so thats just my reservation. I'm sorry for frustrating you.
611 2017-09-28T19:35:01  <wumpus> anyhow, time for sipa's topic
612 2017-09-28T19:35:06  <wumpus> #topic segwit wallet support
613 2017-09-28T19:35:13  <sipa> yay!
614 2017-09-28T19:35:14  <morcos> for the record i'm also wary about adding more and more notification systems, but that's not to say i don't think we shouldn't improve from where we are now
615 2017-09-28T19:35:25  <wumpus> morcos: you've just missed that topic
616 2017-09-28T19:35:29  <wumpus> :p
617 2017-09-28T19:35:50  <sipa> so, i have a PR #11403 which i think implements most of what we want, except some import/export and message signing
618 2017-09-28T19:35:52  <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
619 2017-09-28T19:36:00  <sipa> however, i think there are 2 differences compared to what we discussed before
620 2017-09-28T19:36:44  <sipa> 1) importprivkey works, and actually imports all corresponding addresses for that given key (P2PKH, P2SH-P2WPKH, P2WPKH)
621 2017-09-28T19:36:48  <wumpus> nice
622 2017-09-28T19:37:09  *** Aaronvan_ is now known as AaronvanW
623 2017-09-28T19:37:42  <sipa> that's not how i want things to work long term, but it's very hard and probably confusing to users to almost everywhere follow the "a key corresponds to all 3 forms of corresponding addresses", except when importing (and importing is inevitably needed anyway for testing)
624 2017-09-28T19:38:38  <sipa> 2) once you generate a segwit address with this patch, you can't really downgrade to older software anymore (unless you go fix your missing addresses with addwitnessaddress), though no new backup is needed
625 2017-09-28T19:39:05  <luke-jr> why 2?
626 2017-09-28T19:39:06  <BlueMatt> wait, why?
627 2017-09-28T19:39:07  <morcos> 2 confuses me
628 2017-09-28T19:39:19  <sipa> which differs from the earlier idea of every new addresses effectively calling addwitnessaddress
629 2017-09-28T19:39:24  <BlueMatt> yea, what we discussed was auto-addwitnessaddress
630 2017-09-28T19:39:34  <morcos> i think it depends on what we are expecting 0.16 to do
631 2017-09-28T19:39:39  <sipa> well, auto-addwitnessaddress doesn't actually achieve what you want either
632 2017-09-28T19:40:58  <morcos> if the manual upgrade of a wallet to 0.16 is going to auto add all 3 versions of all keys, then what you are suggesting seems maybe ok...   but that will lead to more bloat in 0.16 as opposed to just having the scripts already in the wallet moved over
633 2017-09-28T19:41:08  *** chjj has joined #bitcoin-core-dev
634 2017-09-28T19:41:37  <sipa> effectively what the patch does is just implicitly making redeemscripts for all your keys known, without writing them to the file
635 2017-09-28T19:42:00  <meshcollider> Oh so if you wrote them to the file downgrading would be fine
636 2017-09-28T19:42:32  <achow101> sipa: why not write them?
637 2017-09-28T19:42:32  <sipa> meshcollider: not really... new transactions you receive while downgrading are risky
638 2017-09-28T19:42:41  <sipa> achow101: bloat, and it doesn't fully solve the problem
639 2017-09-28T19:42:45  <BlueMatt> sipa: yes, why did you decide to do that over the previous discussion?
640 2017-09-28T19:43:03  <luke-jr> morcos: don't add segwit stuff for old keys..
641 2017-09-28T19:43:32  <sipa> BlueMatt: because keys the old version adds to the keypool during auto-topup won't get their witnesses added, and will go undetected
642 2017-09-28T19:43:39  <gmaxwell> meshcollider: writing them doesn't make downgrading fine though, because the downgraded one won't be adding them for things in the keypool. so in the presences of restores they'd potentially silently lose funds.
643 2017-09-28T19:43:55  <luke-jr> would be pretty ugly if the address list tripled in size simply with an upgrade; ideally we should only list one type per key, perhaps excepting the import case
644 2017-09-28T19:44:05  *** SopaXorzTaker has joined #bitcoin-core-dev
645 2017-09-28T19:44:06  <BlueMatt> sipa: huh? I figured youd "auto-addwitnessaddress" when you getnewaddress/get the address for gui/etc
646 2017-09-28T19:44:10  <BlueMatt> not when the key is generated
647 2017-09-28T19:44:17  <sipa> BlueMatt: that won't work at all
648 2017-09-28T19:44:27  <gmaxwell> luke-jr: we're kinda stuck with that right now, obviously when we change the wallet design we can move to a model where there is a 1:1 matching between chains and keys. But thats a major redesign.
649 2017-09-28T19:44:30  <sipa> BlueMatt: as old versions will then miss all transactions received while offline
650 2017-09-28T19:44:32  <luke-jr> gmaxwell: if you getnewaddress with an older version, you won't get a segwit address, so they don't *need* to be added..
651 2017-09-28T19:44:33  <BlueMatt> sipa: yes, please explain why
652 2017-09-28T19:44:42  <sipa> (their keypool entries won't have witnesses, so won't be watched for)
653 2017-09-28T19:44:48  <luke-jr> gmaxwell: we can leave existing keys alone, at least
654 2017-09-28T19:44:48  <BlueMatt> ah, i see your point
655 2017-09-28T19:44:52  *** SopaXorzTaker has quit IRC
656 2017-09-28T19:44:56  <gmaxwell> BlueMatt: then backup and restore is completely no durable and you'll miss payments if you start with a restored wallet...
657 2017-09-28T19:44:59  <gmaxwell> yea.
658 2017-09-28T19:45:25  *** SopaXorzTaker has joined #bitcoin-core-dev
659 2017-09-28T19:45:29  <luke-jr> gmaxwell: only if you restore a backup with an old version?
660 2017-09-28T19:45:36  <luke-jr> that seems like a very niche problem area
661 2017-09-28T19:45:42  <sipa> there is a possible best-effort approach of adding witnesses for all keypool entries and new addresses... but given that that's not even water tight...
662 2017-09-28T19:45:51  <luke-jr> "when restoring a backup, don't use old versions" seems the straightforward "fix"
663 2017-09-28T19:45:55  <gmaxwell> luke-jr: no, the best we could do is store a flag where the segwittyness starts and handle that, but because users are _already_ using addwitnessaddress this would not resolve their current recovery problems while adding for all does.
664 2017-09-28T19:46:22  *** mess110 has quit IRC
665 2017-09-28T19:46:26  <gmaxwell> luke-jr: this whole discussion is about old restores, if you don't do that all is fantastic in sipa's code.
666 2017-09-28T19:46:40  <luke-jr> gmaxwell: so I'm a user. I upgrade, and suddenly my address list has 500 new addresses. So instead of making new ones, I just use those up..
667 2017-09-28T19:46:46  <BlueMatt> sipa: so downgrades are broken anyway cause they wont know to scan for witness-ified scripts anyway
668 2017-09-28T19:46:50  <BlueMatt> (and you have to do a rescan or so)
669 2017-09-28T19:46:54  <gmaxwell> by old restores I mean downgrade.
670 2017-09-28T19:47:01  *** SopaXorzTaker has quit IRC
671 2017-09-28T19:47:08  <luke-jr> gmaxwell: it sounds like sipa's code will fail to work properly if you simply downgrade with a wallet that's used a segwit address
672 2017-09-28T19:47:20  <luke-jr> no backup/restore involved
673 2017-09-28T19:47:26  <BlueMatt> sipa: so it sounds like we're back to needing to bump wallet version?
674 2017-09-28T19:47:35  *** SopaXorzTaker has joined #bitcoin-core-dev
675 2017-09-28T19:47:41  <sipa> BlueMatt: that would be nice, yes...
676 2017-09-28T19:47:45  <gmaxwell> luke-jr: right, it doesn't downgrade.
677 2017-09-28T19:47:45  *** mess110 has joined #bitcoin-core-dev
678 2017-09-28T19:48:05  <gmaxwell> luke-jr: but downgrading is just not possible to support here. At best it can look kinda like it works but lose funds.
679 2017-09-28T19:48:10  <BlueMatt> sipa: so are we back to the wallet-overhaul-ish approach, then?
680 2017-09-28T19:48:13  <morcos> sipa: it would be really helpful if you would spell this all out in a document.  including how it'll interact with 0.16
681 2017-09-28T19:48:18  <luke-jr> if it doesn't downgrade, I see no value in this temporary approach
682 2017-09-28T19:48:24  <sipa> morcos: it's spelled out
683 2017-09-28T19:48:25  <sipa> BlueMatt: NO
684 2017-09-28T19:48:28  <gmaxwell> jesus fucking christ.
685 2017-09-28T19:48:39  <sipa> BlueMatt: all we need is a version number
686 2017-09-28T19:48:41  <morcos> lets find flaws in the overall plan now, and not wait and realize we made a mistake now that makes 0.16 more difficult
687 2017-09-28T19:48:47  <sipa> overhauling will take far longer
688 2017-09-28T19:48:49  <morcos> sipa: where is it spelled out
689 2017-09-28T19:48:53  <sipa> morcos: it doesn't make 0.16 harder
690 2017-09-28T19:48:54  <gmaxwell> luke-jr: If you don't see value in supporting segwit this year then I don't have anything more to discuss with you.
691 2017-09-28T19:48:56  <morcos> i agree, overhaul is goign to take a long time
692 2017-09-28T19:49:05  <morcos> but i just want to understand now what we are going to do
693 2017-09-28T19:49:10  <BlueMatt> sipa: well at a minimum its now blocked on hd upgrade, then, no?
694 2017-09-28T19:49:21  <sipa> BlueMatt: no
695 2017-09-28T19:49:24  <BlueMatt> why not?
696 2017-09-28T19:49:34  <gmaxwell> BlueMatt: there is a pretty straight forward fix, set the version to maximum and introduce a new version field.
697 2017-09-28T19:49:47  <BlueMatt> argh, lets not
698 2017-09-28T19:49:52  <sipa> hd upgrade requires a new backup
699 2017-09-28T19:49:54  <sipa> _this doesn't_
700 2017-09-28T19:50:12  <BlueMatt> hd upgrade requires no more backup than keypool topup
701 2017-09-28T19:50:15  <sipa> it should simply be "minimum software version to read this file is X"
702 2017-09-28T19:50:22  <BlueMatt> (hd upgrade doesnt neccessarily imply you *must* wipe your keypool)
703 2017-09-28T19:50:23  *** promag has joined #bitcoin-core-dev
704 2017-09-28T19:50:27  *** SopaXorzTaker has quit IRC
705 2017-09-28T19:50:35  <sipa> BlueMatt: it will write a hd master key though, which must be backed up
706 2017-09-28T19:50:36  <BlueMatt> (and is also quite simple)
707 2017-09-28T19:51:01  <BlueMatt> sipa: no more than topping up your keypool? or you mean you'd want to be able to use segwit-wallet without keypool topup and with an encrypted (and locked) wallet?
708 2017-09-28T19:51:09  *** SopaXorzTaker has joined #bitcoin-core-dev
709 2017-09-28T19:51:25  <sipa> so to be clear... it *is* possible to make downgrade work, if restoring a backup with an older version isn't a concern - though at the cost of some bloat
710 2017-09-28T19:51:33  <sipa> and it may make expectations unclear
711 2017-09-28T19:52:07  <BlueMatt> you mean as long as you dont restore a backup, just use the latest wallet, right?
712 2017-09-28T19:52:15  <BlueMatt> ie via the addwitnessaddress method?
713 2017-09-28T19:52:18  <sipa> yes
714 2017-09-28T19:52:22  <gmaxwell> restoring a backup is always a concern though.  I don't understand why downgrading suddenly shows up as a hard requirement. It's something that you generally can't do with a new feature except through the cheat of introducing it first but disabled.
715 2017-09-28T19:52:51  <BlueMatt> gmaxwell: yes, but we generally "support" it in the sense that you have to manually do -walletupgrade if you want new features
716 2017-09-28T19:52:56  <sdaftuar> gmaxwell: i agree that restoring a backup is important, and supporting downgrade not a big deal
717 2017-09-28T19:53:01  <morcos> sipa: i'm sorry if i missed this, but can you point me to where this is spelled out or just explain what we will do when you upgrade to a 0.16 wallet?  Add 3x number of keys pkscripts to your ismine set?  which we'll do for all keys in your wallet for all time?
718 2017-09-28T19:53:04  <gmaxwell> BlueMatt: don't restore a backup, don't run concurrent copies... perhaps some other corner cases we haven't considered.
719 2017-09-28T19:53:06  <BlueMatt> and thus we support running the latest version and going back to the previous release eg if there's some critical issue for you
720 2017-09-28T19:53:13  <sipa> > Every wallet key implicitly adds its corresponding P2WPKH script to the wallet's known redeemscripts - without writing to the file. This is simpler, needs significantly less space on disk, needs no one-time upgrade for existing keys, but does mean that once a SegWit address has been used, you can't really downgrade to older software anymore.
721 2017-09-28T19:53:16  <BlueMatt> "don't restore a backup"???
722 2017-09-28T19:53:21  <sipa> ^ from my PR description
723 2017-09-28T19:53:41  <BlueMatt> sipa: yes, to me that implies we need to bump wallet version
724 2017-09-28T19:53:45  <morcos> i would distinguish that from the addwitness approach where you wouldn't have to do that (but you could have an i'm upgrading from a backup option that does do that to make sure you didn't miss anything)
725 2017-09-28T19:53:53  <BlueMatt> which is fine, but that leads us back to the question of hd upgrade
726 2017-09-28T19:54:04  <BlueMatt> we can do some hack to let people upgrade to segwit-wallet without an hd upgrade
727 2017-09-28T19:54:12  <BlueMatt> or we can jsut implement hd upgrade, which I think is rather trivial
728 2017-09-28T19:54:28  <promag> instagibbs: is https://github.com/bitcoin/bitcoin/pull/11407/files#diff-06ca130427d8b52a085dc51ffea1a541R545 really necessary?
729 2017-09-28T19:54:32  <gmaxwell> BlueMatt: Trivial but invalidates their backups.
730 2017-09-28T19:54:37  <instagibbs> promag, meeting wait please
731 2017-09-28T19:54:47  <BlueMatt> gmaxwell: see previous discussion on keypool? or do you mean locked wallets?
732 2017-09-28T19:54:50  <BlueMatt> thats a rather narrow use-case, no?
733 2017-09-28T19:55:15  <sipa> BlueMatt: yeah, i don't know
734 2017-09-28T19:55:25  <sipa> i may be convinced of doing the addwitnessaddress approach
735 2017-09-28T19:55:36  * BlueMatt would prefer hd-upgrade over dirty hacks, but I'm open to discussion
736 2017-09-28T19:55:55  <sipa> though i'm uneasy with the inability to restore while downgrading
737 2017-09-28T19:56:06  <BlueMatt> yea, I'd tend to agree
738 2017-09-28T19:56:19  <luke-jr> what if we bump the wallet version only in backups?
739 2017-09-28T19:56:20  <sipa> on the other hand - everything will be fixed by upgrading again and rescanning
740 2017-09-28T19:56:26  <gmaxwell> BlueMatt: hdupgrade invalidates backups, even without a locked wallet. Though thats another point you have to unlock to do it.
741 2017-09-28T19:56:35  <wumpus> 3 minutes to go
742 2017-09-28T19:57:05  <gmaxwell> I think if restore isn't reliable we shouldn't run with the older version. Thats a big footgun in a mixed wallet where you may not notice a non-trivial percentage of funds vanishing.
743 2017-09-28T19:57:23  <luke-jr> backups don't need to use the same version as the latest-wallet
744 2017-09-28T19:57:34  <sipa> luke-jr: people use cp to make backups
745 2017-09-28T19:57:39  <luke-jr> sipa: that's broken
746 2017-09-28T19:57:43  <luke-jr> :/
747 2017-09-28T19:57:51  <sipa> luke-jr: irrelevant - it will cause lost funds
748 2017-09-28T19:58:04  <luke-jr> it can cause lost funds even as-is
749 2017-09-28T19:58:26  <gmaxwell> luke-jr: yes, but it's a minor addition to make it not load in older software.
750 2017-09-28T19:58:52  <jnewbery> suggested topic: next Bitcoin Core meetup
751 2017-09-28T19:58:52  <sipa> so, open for discussion perhaps on the PR: auto-add witnesses so downgrading when not restoring a backup works, or some scheme of versioning to make old software fail
752 2017-09-28T19:58:57  <sipa> endtopic
753 2017-09-28T19:58:59  <wumpus> #topic suggested topic: next Bitcoin Core meetup (jnewbery)
754 2017-09-28T19:59:01  <BlueMatt> sdaftuar: points out that downgrade + restore is always broken
755 2017-09-28T19:59:06  <achow101> jnewbery: already?
756 2017-09-28T19:59:08  <BlueMatt> cause even if you bump the version number....
757 2017-09-28T19:59:10  <instagibbs> NYC :D
758 2017-09-28T19:59:15  <BlueMatt> hence why its nice to have an explicit walletupgrade
759 2017-09-28T19:59:34  <jnewbery> ok, just a quick announcement - we're in the early stages of planning the next one in NYC the week of March 5th 2018
760 2017-09-28T19:59:34  <sipa> jnewbery: what timeframe were you thinking of?
761 2017-09-28T19:59:40  <luke-jr> BlueMatt: can you elaborate on sdaftuar's point after meeting?
762 2017-09-28T19:59:44  <jnewbery> more details to follow by email
763 2017-09-28T19:59:47  <BlueMatt> luke-jr: yes
764 2017-09-28T19:59:54  *** laurentmt has joined #bitcoin-core-dev
765 2017-09-28T20:00:02  <wumpus> achow101: better to plan it long in advance so people can take it into account, instead of on short notice
766 2017-09-28T20:00:15  <luke-jr> I'm expecting a baby in February, so I will probably pass on the March meetup
767 2017-09-28T20:00:17  <jonasschnelli> jnewbery: thanks for the date! thanks for organising.
768 2017-09-28T20:00:18  <cfields> jnewbery: woohoo! thanks for planning!
769 2017-09-28T20:00:24  <sipa> jnewbery: cool, on the way back from Financial Crypto :)
770 2017-09-28T20:00:26  <instagibbs> \o/ marked on it calender
771 2017-09-28T20:00:30  * jonasschnelli can't attend NYC... to bad
772 2017-09-28T20:00:30  <wumpus> jnewbery: works for me
773 2017-09-28T20:01:12  <cfields> luke-jr: didn't know that, congrats :)
774 2017-09-28T20:01:18  <wumpus> jonasschnelli: that's two times US in a row, let's plan another one in europe next
775 2017-09-28T20:01:19  <luke-jr> cfields: thx
776 2017-09-28T20:01:45  <promag> europe +1
777 2017-09-28T20:01:47  <jonasschnelli> wumpus: I can organise fall 2018 in Europe
778 2017-09-28T20:01:50  <luke-jr> we haven't done Australia or Russia yet. but those might just be inconvenient for too many people :p
779 2017-09-28T20:01:52  <jnewbery> New York is almost in Europe. Just a short flight :)
780 2017-09-28T20:02:00  <meshcollider> Australia +1 ;)
781 2017-09-28T20:02:01  <luke-jr> jnewbery: lol
782 2017-09-28T20:02:01  <achow101> lol
783 2017-09-28T20:02:16  <jonasschnelli> jnewbery: hehe
784 2017-09-28T20:02:22  <wumpus> austrialia would be fine with me too, russia meh
785 2017-09-28T20:02:26  <instagibbs> not incredibly bad for Tokyo folks
786 2017-09-28T20:02:27  * cfields votes for fanquake to host one at his place
787 2017-09-28T20:02:48  <wumpus> anyhow thanks everyone, it's time to wrap up the meeting
788 2017-09-28T20:02:52  * sipa votes for Iceland in the summer
789 2017-09-28T20:03:06  <jonasschnelli> Iceland would be cool...
790 2017-09-28T20:03:18  <jonasschnelli> and cold
791 2017-09-28T20:03:19  <wumpus> jonasschnelli: finally a meeting in UTC+0!
792 2017-09-28T20:03:20  <BlueMatt> wumpus: long since time
793 2017-09-28T20:03:20  <meshcollider> https://www.irccloud.com/pastebin/XrHj6tr8
794 2017-09-28T20:03:23  <wumpus> #endmeeting
795 2017-09-28T20:03:23  <lightningbot> Meeting ended Thu Sep 28 20:03:23 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
796 2017-09-28T20:03:23  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-28-19.01.html
797 2017-09-28T20:03:23  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-28-19.01.txt
798 2017-09-28T20:03:23  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-28-19.01.log.html
799 2017-09-28T20:03:48  <meshcollider> Oops didn't mean to post that at a snippet lol
800 2017-09-28T20:04:18  <jnewbery> sipa: is there a write-up of your current plans for the wallet in 0.15.0.1 and 0.16? I saw the PR notes, but I feel like I don't fully understand the longer term plans and the concerns that were raised in the meeting
801 2017-09-28T20:05:00  <luke-jr> meshcollider: eh, people can still review/open PRs without meeting discussion ;)
802 2017-09-28T20:05:21  <cfields> jonasschnelli: got a few min to talk about 10387?
803 2017-09-28T20:05:35  <wumpus> yes, meetings certainly aren't intended to become a bottleneck for discussion
804 2017-09-28T20:06:01  <sipa> jnewbery: sounds like something i need to write up
805 2017-09-28T20:06:16  <instagibbs> +1
806 2017-09-28T20:06:31  <wumpus> IRC meetings are basically for topics that need as many people as possible to give input
807 2017-09-28T20:06:46  <wumpus> for the rest please just discuss on github or IRC outside the meeting...
808 2017-09-28T20:06:54  <sipa> jonasschnelli: iceland can be up to 20C in summer :)
809 2017-09-28T20:07:12  <jnewbery> sipa: thanks :)
810 2017-09-28T20:07:34  <meshcollider> Yeah although the PRs Luke linked were in another repo and obviously super controversial, not just review heh
811 2017-09-28T20:08:22  <meshcollider> And yeah sipa: a writeup would be nice yeah I'm still confused as well haha
812 2017-09-28T20:11:04  <sipa> jonasschnelli: ... if you're lucky
813 2017-09-28T20:13:56  *** StopAndDecrypt_ is now known as StopAndDecrypt[m
814 2017-09-28T20:13:59  *** wasi has joined #bitcoin-core-dev
815 2017-09-28T20:14:15  *** StopAndDecrypt[m is now known as StopAndDecrypt|m
816 2017-09-28T20:14:53  *** StopAndDecrypt|m is now known as StopAndDecrypt_
817 2017-09-28T20:17:37  *** Chris_Stewart_5 has quit IRC
818 2017-09-28T20:18:22  *** eck has quit IRC
819 2017-09-28T20:19:06  *** eck has joined #bitcoin-core-dev
820 2017-09-28T20:24:21  <wraithm> 24 hours of sun heats things up (sort of)
821 2017-09-28T20:33:43  *** curioso has quit IRC
822 2017-09-28T20:52:21  *** SopaXorzTaker has quit IRC
823 2017-09-28T20:55:33  *** SopaXorzTaker has joined #bitcoin-core-dev
824 2017-09-28T20:56:38  *** SopaXorzTaker has quit IRC
825 2017-09-28T20:57:29  *** SopaXorzTaker has joined #bitcoin-core-dev
826 2017-09-28T20:59:39  *** Deacyde has joined #bitcoin-core-dev
827 2017-09-28T21:00:23  *** SopaXorzTaker has quit IRC
828 2017-09-28T21:01:20  *** SopaXorzTaker has joined #bitcoin-core-dev
829 2017-09-28T21:01:22  *** Deacyded has quit IRC
830 2017-09-28T21:02:44  *** SopaXorzTaker has quit IRC
831 2017-09-28T21:03:20  *** SopaXorzTaker has joined #bitcoin-core-dev
832 2017-09-28T21:04:27  *** SopaXorzTaker has quit IRC
833 2017-09-28T21:05:21  *** SopaXorzTaker has joined #bitcoin-core-dev
834 2017-09-28T21:06:35  *** SopaXorzTaker has quit IRC
835 2017-09-28T21:11:46  *** bitsegwit is now known as getSegwitty
836 2017-09-28T21:11:53  *** getSegwitty is now known as getSegwity
837 2017-09-28T21:22:56  *** SopaXorzTaker has joined #bitcoin-core-dev
838 2017-09-28T21:24:09  *** SopaXorzTaker has quit IRC
839 2017-09-28T21:24:49  *** SopaXorzTaker has joined #bitcoin-core-dev
840 2017-09-28T21:37:33  *** timothy has joined #bitcoin-core-dev
841 2017-09-28T21:40:27  *** Giszmo has quit IRC
842 2017-09-28T21:51:17  *** mess110 has quit IRC
843 2017-09-28T21:51:33  *** jtimon has joined #bitcoin-core-dev
844 2017-09-28T21:52:15  *** Guyver2 has quit IRC
845 2017-09-28T21:57:54  *** tknp has joined #bitcoin-core-dev
846 2017-09-28T22:05:16  *** SergioMassa has joined #bitcoin-core-dev
847 2017-09-28T22:11:44  *** Giszmo has joined #bitcoin-core-dev
848 2017-09-28T22:13:31  *** AaronvanW has quit IRC
849 2017-09-28T22:14:09  *** AaronvanW has joined #bitcoin-core-dev
850 2017-09-28T22:17:31  *** laurentmt has quit IRC
851 2017-09-28T22:31:06  <promag> sipa: is bench/bech32.cpp useful?
852 2017-09-28T22:32:14  <sipa> promag: it's just for addresses... hardly performance critical
853 2017-09-28T22:33:12  <promag> theres is base58, for comparison?
854 2017-09-28T22:34:16  *** StopAndDecrypt_ has quit IRC
855 2017-09-28T22:35:05  <gmaxwell> there is bench base58 because someone wanted to make 'optimizations' that sounded reasonable, but it's not reasonable to optimize things without a benchmark. :)
856 2017-09-28T22:35:38  <gmaxwell> if someone wanted to 'optimize' bech32 though they're just rip out the C++ one and put in the C one. :P
857 2017-09-28T22:36:38  <promag> heh that was me #7656
858 2017-09-28T22:36:40  <gribble> https://github.com/bitcoin/bitcoin/issues/7656 | Improve EncodeBase58 performance by promag · Pull Request #7656 · bitcoin/bitcoin · GitHub
859 2017-09-28T22:36:54  <gmaxwell> :)
860 2017-09-28T22:37:38  <gmaxwell> personally I'd just suggest waiting until someone wants to optimize it, though that code was already pessimized for the sake of readability, and the C version is quite a bit faster.
861 2017-09-28T22:39:04  <promag> why not add the C version?
862 2017-09-28T22:39:14  <sipa> it's less readable
863 2017-09-28T22:39:32  <sipa> we prefer C++ish code over Cish code where possible
864 2017-09-28T22:39:34  <gmaxwell> I don't think there is any case where the performance matters here.
865 2017-09-28T22:39:46  <gmaxwell> or at least where a factor of two would matter.
866 2017-09-28T22:39:49  <promag> it's also the reference implementation
867 2017-09-28T22:40:16  <sipa> there's also a C++ reference implementation
868 2017-09-28T22:40:24  <sipa> (which the code in my PR is based on)
869 2017-09-28T22:41:34  <promag> just curious.. anyway I've added bench/bech32.cpp while reviewing #11167
870 2017-09-28T22:41:38  <gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
871 2017-09-28T22:42:52  *** vicenteH has quit IRC
872 2017-09-28T22:44:30  *** promag has quit IRC
873 2017-09-28T22:46:12  *** promag has joined #bitcoin-core-dev
874 2017-09-28T22:47:14  *** Cheeseo has quit IRC
875 2017-09-28T22:50:10  *** promag has quit IRC
876 2017-09-28T23:01:32  *** getSegwity has quit IRC
877 2017-09-28T23:04:58  *** wraithm has quit IRC
878 2017-09-28T23:14:23  *** promag has joined #bitcoin-core-dev
879 2017-09-28T23:28:13  *** promag has joined #bitcoin-core-dev
880 2017-09-28T23:29:43  *** Giszmo has quit IRC
881 2017-09-28T23:34:03  *** promag has quit IRC
882 2017-09-28T23:37:18  *** promag has joined #bitcoin-core-dev
883 2017-09-28T23:43:18  *** Ylbam has quit IRC
884 2017-09-28T23:48:02  *** Giszmo has joined #bitcoin-core-dev
885 2017-09-28T23:56:31  *** timothy has quit IRC
886 2017-09-28T23:58:46  <promag> addwitnessaddress doesn't lock wallet, it should?
887 2017-09-28T23:59:36  *** abpa has quit IRC
888 2017-09-28T23:59:49  <sipa> i don't think so