12017-09-28T00:00:20  *** justanotheruser has joined #bitcoin-core-dev
  22017-09-28T00:06:07  *** georges_ has joined #bitcoin-core-dev
  32017-09-28T00:07:51  *** georges_ has quit IRC
  42017-09-28T00:20:34  *** merehap__ has joined #bitcoin-core-dev
  52017-09-28T00:20:35  *** merehap_ has quit IRC
  62017-09-28T00:26:24  *** goatpig has joined #bitcoin-core-dev
  72017-09-28T00:28:12  *** Ylbam has quit IRC
  82017-09-28T00:31:18  *** Miezel has quit IRC
  92017-09-28T00:39:06  *** chjj has joined #bitcoin-core-dev
 102017-09-28T00:43:13  *** promag has joined #bitcoin-core-dev
 112017-09-28T00:43:20  *** justanotheruser has quit IRC
 122017-09-28T00:43:37  *** justanotheruser has joined #bitcoin-core-dev
 132017-09-28T00:47:29  *** promag has quit IRC
 142017-09-28T00:49:39  *** ekerstein has quit IRC
 152017-09-28T00:51:01  *** dabura667 has joined #bitcoin-core-dev
 162017-09-28T00:51:02  *** ekerstein has joined #bitcoin-core-dev
 172017-09-28T00:52:10  *** ekerstein has left #bitcoin-core-dev
 182017-09-28T01:21:57  *** Murch has quit IRC
 192017-09-28T01:37:28  *** kebman has quit IRC
 202017-09-28T01:41:03  *** tknp has quit IRC
 212017-09-28T02:07:56  *** justan0theruser has joined #bitcoin-core-dev
 222017-09-28T02:08:26  *** justan0theruser has joined #bitcoin-core-dev
 232017-09-28T02:09:48  *** justanotheruser has quit IRC
 242017-09-28T02:16:03  *** ensign has quit IRC
 252017-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
 262017-09-28T02:18:16  *** ensign has joined #bitcoin-core-dev
 272017-09-28T02:26:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 282017-09-28T02:31:39  *** PaulCape_ has quit IRC
 292017-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
 302017-09-28T02:33:21  <sipa> oh, no; you're just talking about the sanity check
 312017-09-28T02:33:31  <sipa> that should be an assert really, and it can go above, indeed
 322017-09-28T02:36:43  *** PaulCapestany has joined #bitcoin-core-dev
 332017-09-28T02:43:17  *** meshcollider has quit IRC
 342017-09-28T02:47:18  <jimpo> sipa: So it's safe if I change that to an assert at the top?
 352017-09-28T02:51:31  *** meshcollider has joined #bitcoin-core-dev
 362017-09-28T02:54:54  <sipa> jimpo: imo, yes
 372017-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
 382017-09-28T02:55:23  <jimpo> I'm running the test suite on it now. Let's see...
 392017-09-28T03:10:24  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ef8340d25f7c...d90a00eabed0
 402017-09-28T03:10:24  <bitcoin-git> bitcoin/master 22f816e Wladimir J. van der Laan: net: Improve and document SOCKS code...
 412017-09-28T03:10:25  <bitcoin-git> bitcoin/master d90a00e Jonas Schnelli: Merge #11397: net: Improve and document SOCKS code...
 422017-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
 432017-09-28T03:15:56  *** ghost43 has quit IRC
 442017-09-28T03:18:21  *** Chris_Stewart_5 has quit IRC
 452017-09-28T03:22:50  *** ghost43 has joined #bitcoin-core-dev
 462017-09-28T03:27:35  *** justanotheruser has joined #bitcoin-core-dev
 472017-09-28T03:29:37  *** justan0theruser has quit IRC
 482017-09-28T03:32:19  *** gijensen has quit IRC
 492017-09-28T03:32:50  *** wolfspraul has quit IRC
 502017-09-28T03:33:28  *** ghost43 has quit IRC
 512017-09-28T03:33:52  *** comboy has quit IRC
 522017-09-28T03:34:29  *** justanotheruser has quit IRC
 532017-09-28T03:34:47  *** ghost43 has joined #bitcoin-core-dev
 542017-09-28T03:34:49  *** justanotheruser has joined #bitcoin-core-dev
 552017-09-28T03:38:02  *** gijensen has joined #bitcoin-core-dev
 562017-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
 572017-09-28T03:39:33  *** wolfspraul has joined #bitcoin-core-dev
 582017-09-28T03:39:39  *** comboy has joined #bitcoin-core-dev
 592017-09-28T03:53:42  *** ndrst has quit IRC
 602017-09-28T04:01:06  *** Guest26486 has joined #bitcoin-core-dev
 612017-09-28T04:03:56  *** intcat has quit IRC
 622017-09-28T04:08:00  *** intcat has joined #bitcoin-core-dev
 632017-09-28T04:11:54  <jonasschnelli> Beg for reviews on #7061 (from 2015!)
 642017-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
 652017-09-28T04:21:52  <warren> I liked sipa's comment "I would still prefer an approach that imports with birthdate instead of explicit rescanning."
 662017-09-28T04:22:34  <warren> opportunity to optionally encode a birthdate in the address, but there was concern of bikeshedding or something
 672017-09-28T04:27:25  *** ghost43 has quit IRC
 682017-09-28T04:27:51  *** ghost43 has joined #bitcoin-core-dev
 692017-09-28T04:38:59  *** wittysense has quit IRC
 702017-09-28T04:45:07  *** promag has joined #bitcoin-core-dev
 712017-09-28T04:47:08  *** twistedline has quit IRC
 722017-09-28T04:49:21  *** promag has quit IRC
 732017-09-28T05:12:50  *** ghost43 has quit IRC
 742017-09-28T05:13:04  *** Guest26486 is now known as ndrst
 752017-09-28T05:13:08  *** ndrst has joined #bitcoin-core-dev
 762017-09-28T05:13:32  *** ghost43 has joined #bitcoin-core-dev
 772017-09-28T05:17:42  *** Geoffy has joined #bitcoin-core-dev
 782017-09-28T05:27:32  *** Ylbam has joined #bitcoin-core-dev
 792017-09-28T05:41:35  *** twistedline has joined #bitcoin-core-dev
 802017-09-28T05:48:33  *** twistedline has quit IRC
 812017-09-28T05:49:50  *** M has joined #bitcoin-core-dev
 822017-09-28T05:50:14  *** M is now known as Guest54972
 832017-09-28T05:51:29  *** Guest54972 has quit IRC
 842017-09-28T05:53:22  *** lifeofguenter has quit IRC
 852017-09-28T05:56:24  *** twistedline has joined #bitcoin-core-dev
 862017-09-28T05:57:49  *** lifeofguenter has joined #bitcoin-core-dev
 872017-09-28T06:01:17  *** chjj has quit IRC
 882017-09-28T06:07:52  *** ghost43 has quit IRC
 892017-09-28T06:08:29  *** ghost43 has joined #bitcoin-core-dev
 902017-09-28T06:34:11  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/d90a00eabed0...c9a4aa8a0e7e
 912017-09-28T06:34:12  <bitcoin-git> bitcoin/master 3826253 Wladimir J. van der Laan: rpc: Handle `getinfo` locally in bitcoin-cli w/ `-getinfo`...
 922017-09-28T06:34:12  <bitcoin-git> bitcoin/master 5e69a43 John Newbery: Add test for bitcoin-cli -getinfo...
 932017-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)...
 942017-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
 952017-09-28T06:35:40  *** wittysense has joined #bitcoin-core-dev
 962017-09-28T06:38:50  *** ghost43 has quit IRC
 972017-09-28T06:39:04  *** ghost43 has joined #bitcoin-core-dev
 982017-09-28T06:40:35  *** wittysense has quit IRC
 992017-09-28T06:43:17  *** meshcollider has quit IRC
1002017-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
1012017-09-28T06:44:59  *** chjj has joined #bitcoin-core-dev
1022017-09-28T06:51:36  *** BashCo has quit IRC
1032017-09-28T07:05:35  *** promag has joined #bitcoin-core-dev
1042017-09-28T07:07:07  *** promag has quit IRC
1052017-09-28T07:13:13  *** BashCo has joined #bitcoin-core-dev
1062017-09-28T08:08:05  *** laurentmt has joined #bitcoin-core-dev
1072017-09-28T08:13:51  *** laurentmt has quit IRC
1082017-09-28T08:15:09  *** promag has joined #bitcoin-core-dev
1092017-09-28T08:36:07  *** promag has quit IRC
1102017-09-28T08:36:24  *** wittysense has joined #bitcoin-core-dev
1112017-09-28T08:36:53  *** promag has joined #bitcoin-core-dev
1122017-09-28T08:38:38  *** ThomasV has joined #bitcoin-core-dev
1132017-09-28T08:41:11  <ThomasV> can someone clarify the syntax of importmulti?
1142017-09-28T08:41:17  <ThomasV> "Array of strings giving pubkeys that must occur in the output or redeemscript"
1152017-09-28T08:41:55  <ThomasV> does that mean that for each execution path of redeemScript, you have to import a different array of pubkeys?
1162017-09-28T08:42:41  *** wittysense has quit IRC
1172017-09-28T08:46:08  *** timothy has joined #bitcoin-core-dev
1182017-09-28T08:49:11  <sipa> ThomasV: signing with anything other than pure multisig is not supported, so there can't be multiple execution paths
1192017-09-28T08:49:49  <sipa> so no, it's just the list of all public keys that appear
1202017-09-28T08:49:54  <ThomasV> sipa: will the syntax need to be changed for other scripts?
1212017-09-28T08:50:05  <sipa> i think it's also only necessary for single-pubkey cases
1222017-09-28T08:50:14  <sipa> if you give the redeemscript, you're good
1232017-09-28T08:50:25  <sipa> if you want solvability or signability
1242017-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, ...)
1252017-09-28T08:56:18  *** Ylbam has quit IRC
1262017-09-28T08:56:38  <ThomasV> sipa: so if you pass pubkeys you do not need to pass redeemscript?
1272017-09-28T08:57:29  <sipa> rather the other way around
1282017-09-28T08:57:49  <sipa> passing pubkeys (i think) is only useful for single-key cases (pay to pubkey etc)
1292017-09-28T08:58:23  <ThomasV> but why is it an array, then?
1302017-09-28T08:58:56  <ThomasV> and the doc says  "Array of strings giving pubkeys that must occur in the output or redeemscript"
1312017-09-28T08:59:13  <ThomasV> that suggests an execution path
1322017-09-28T08:59:22  <sipa> yes - you're free to pass in multiple keys if they all appear
1332017-09-28T08:59:29  <sipa> that doesn't mean that you need to
1342017-09-28T08:59:36  <ThomasV> hmm
1352017-09-28T08:59:43  <sipa> presumably it's for being future proofness
1362017-09-28T09:00:07  <ThomasV> ok, so future plan is to extend that to arbitrary scripts?
1372017-09-28T09:00:36  <sipa> we'll only ever be able to sign the scripts we can sign
1382017-09-28T09:00:53  <sipa> importmulti is just a way for passing in all the information the signing logic may possibly need
1392017-09-28T09:02:15  <gmaxwell> I don't believe its computationally tractable to be able to sign actually arbritary scripts.
1402017-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
1412017-09-28T09:02:43  <sipa> ThomasV: if it knows the redeemscript, it knows all possible execution paths
1422017-09-28T09:02:44  <ThomasV> so I would expect that info to be passed to importmulti
1432017-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.
1442017-09-28T09:03:13  <sipa> (but currently no scripts with conditionals are supported in the signer)
1452017-09-28T09:03:46  *** promag has quit IRC
1462017-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?
1472017-09-28T09:05:00  <ThomasV> (or parse it)
1482017-09-28T09:05:17  <sipa> it uses template matching
1492017-09-28T09:05:41  <sipa> again, the current logic can't deal with anything other than P2PK, P2PKH, P2SH, and simple multisig
1502017-09-28T09:05:49  <ThomasV> ok, so the only template it currently has is pure multisig
1512017-09-28T09:06:06  <sipa> however, i believe that the interface for importmulti doesn't need changing
1522017-09-28T09:06:15  <sipa> if the signing logic gets extended
1532017-09-28T09:06:43  *** promag has joined #bitcoin-core-dev
1542017-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
1552017-09-28T09:08:28  *** intcat has quit IRC
1562017-09-28T09:10:35  *** intcat has joined #bitcoin-core-dev
1572017-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
1582017-09-28T09:15:16  *** bitbee has quit IRC
1592017-09-28T09:15:54  *** bitbee has joined #bitcoin-core-dev
1602017-09-28T09:16:07  <ThomasV> when you import a key, you could also tell the wallet in which context it should be used
1612017-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.
1622017-09-28T09:16:27  <gmaxwell> or perhaps you didn't. :)
1632017-09-28T09:17:53  <ThomasV> I mean to tell the wallet which execution path is the key for
1642017-09-28T09:18:31  <sipa> i don't understand why that's necessary, if the wallet knows all execution paths anyway
1652017-09-28T09:18:59  <ThomasV> the wallet does not know how the script is going to be executed
1662017-09-28T09:19:05  <sipa> so?
1672017-09-28T09:19:29  <ThomasV> so, if I sign a transaction, I should provide that info
1682017-09-28T09:19:31  *** bitbee has quit IRC
1692017-09-28T09:19:47  <sipa> usually there are just a few branches, it can easily try all of that
1702017-09-28T09:20:09  *** bitbee has joined #bitcoin-core-dev
1712017-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)
1722017-09-28T09:21:14  <ThomasV> sipa: there might be branches that you do not want to sign.
1732017-09-28T09:22:10  <gmaxwell> ThomasV: I don't follow, it's for the execution path(s) that involve the corresponding public key.
1742017-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
1752017-09-28T09:23:42  <ThomasV> gmaxwell: maybe the same pubkey occurs in 2 branches
1762017-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.
1772017-09-28T09:25:55  <ThomasV> gmaxwell: exactly. my point is that making it an import time decision makes signing arbitrary scripts a lot simpler.
1782017-09-28T09:26:30  <ThomasV> you only need to pass the position of the signature in the witness, and the length of the witness
1792017-09-28T09:26:45  <ThomasV> and you don't need to fill the blanks, or parse scripts
1802017-09-28T09:27:01  <gmaxwell> I don't follow your thinking at all there.
1812017-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?
1822017-09-28T09:28:12  <ThomasV> gmaxwell: import_privkey_with_role(privkey, redeemscript, role_in_witness)
1832017-09-28T09:28:12  <sipa> sure, you may want to make that choice at signing time
1842017-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.
1852017-09-28T09:28:41  <sipa> with signature aggregation there will just be a single signature anyway :)
1862017-09-28T09:28:48  <sipa> much easier! *ducks*
1872017-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
1882017-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?
1892017-09-28T09:30:04  <ThomasV> gmaxwell: why can't it sign arbitrary scripts?
1902017-09-28T09:30:41  <ThomasV> the logic is "if I see that redeemscript, then I sign"
1912017-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.
1922017-09-28T09:31:00  <ThomasV> no template matching needed
1932017-09-28T09:31:47  <ThomasV> gmaxwell: in that case you import the same key with several roles
1942017-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.
1952017-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.
1962017-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.
1972017-09-28T09:33:48  *** promag has quit IRC
1982017-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, ..."
1992017-09-28T09:34:54  <sipa> but that question isn't even relevant at this point - we only do signing of specific templates anyway
2002017-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
2012017-09-28T09:36:01  *** promag has joined #bitcoin-core-dev
2022017-09-28T09:36:04  <gmaxwell> well the fill in the blanks would cover a far greater subset of those...
2032017-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
2042017-09-28T09:40:11  *** goatpig has quit IRC
2052017-09-28T09:43:17  *** eck has quit IRC
2062017-09-28T09:44:03  *** eck has joined #bitcoin-core-dev
2072017-09-28T09:44:21  *** promag has quit IRC
2082017-09-28T09:44:39  <ThomasV> gmaxwell: good point. indeed, that would be inefficient.
2092017-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
2102017-09-28T09:48:36  <ThomasV> until it's fully signed
2112017-09-28T09:49:18  <sipa> ThomasV: have you seen achow101'w partially signed transaction format?
2122017-09-28T09:49:53  <ThomasV> no
2132017-09-28T09:50:20  <ThomasV> is there a link?
2142017-09-28T09:50:22  *** promag has joined #bitcoin-core-dev
2152017-09-28T09:50:22  <sipa> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
2162017-09-28T09:50:27  <ThomasV> thanks
2172017-09-28T09:51:18  *** promag has quit IRC
2182017-09-28T09:53:02  *** promag has joined #bitcoin-core-dev
2192017-09-28T10:08:27  *** dabura667 has quit IRC
2202017-09-28T10:12:39  *** promag_ has joined #bitcoin-core-dev
2212017-09-28T10:12:40  *** promag has quit IRC
2222017-09-28T10:14:01  *** AaronvanW has joined #bitcoin-core-dev
2232017-09-28T10:15:22  *** Aaronvan_ has joined #bitcoin-core-dev
2242017-09-28T10:18:29  *** AaronvanW has quit IRC
2252017-09-28T10:24:24  *** promag_ has quit IRC
2262017-09-28T10:29:42  *** JackH has joined #bitcoin-core-dev
2272017-09-28T10:38:25  *** ThomasV has quit IRC
2282017-09-28T10:38:59  *** wittysense has joined #bitcoin-core-dev
2292017-09-28T10:43:45  *** wittysense has quit IRC
2302017-09-28T10:48:49  *** meshcollider has joined #bitcoin-core-dev
2312017-09-28T10:48:54  *** promag has joined #bitcoin-core-dev
2322017-09-28T11:05:17  *** StopAndDecrypt_ has joined #bitcoin-core-dev
2332017-09-28T11:09:22  *** aguycalled has joined #bitcoin-core-dev
2342017-09-28T11:09:25  *** tiagotrs has joined #bitcoin-core-dev
2352017-09-28T11:11:57  *** wump is now known as wumpus
2362017-09-28T11:16:55  *** aguycalled has quit IRC
2372017-09-28T11:18:57  *** promag has quit IRC
2382017-09-28T11:20:14  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9a4aa8a0e7e...4202273ffa45
2392017-09-28T11:20:14  <bitcoin-git> bitcoin/master fa082b4 MarcoFalke: doc: move gitian building to external repo...
2402017-09-28T11:20:15  <bitcoin-git> bitcoin/master 4202273 Wladimir J. van der Laan: Merge #11401: doc: move gitian building to external repo...
2412017-09-28T11:20:36  *** promag has joined #bitcoin-core-dev
2422017-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
2432017-09-28T11:23:45  *** JackH has quit IRC
2442017-09-28T11:23:47  *** SopaXorzTaker has quit IRC
2452017-09-28T11:24:22  *** SopaXorzTaker has joined #bitcoin-core-dev
2462017-09-28T11:24:24  *** laurentmt has joined #bitcoin-core-dev
2472017-09-28T11:25:34  *** promag has quit IRC
2482017-09-28T11:42:23  *** m8tion has joined #bitcoin-core-dev
2492017-09-28T11:43:22  *** wxxs has joined #bitcoin-core-dev
2502017-09-28T11:49:08  *** belcher has quit IRC
2512017-09-28T11:53:57  *** JackH has joined #bitcoin-core-dev
2522017-09-28T12:01:31  *** belcher has joined #bitcoin-core-dev
2532017-09-28T12:03:34  *** Ylbam has joined #bitcoin-core-dev
2542017-09-28T12:20:50  *** ThomasV has joined #bitcoin-core-dev
2552017-09-28T12:29:22  *** ThomasV has quit IRC
2562017-09-28T12:37:25  *** tiagotrs has quit IRC
2572017-09-28T12:39:40  *** wittysense has joined #bitcoin-core-dev
2582017-09-28T12:44:21  *** wittysense has quit IRC
2592017-09-28T12:58:40  *** owowo has quit IRC
2602017-09-28T13:03:28  *** owowo has joined #bitcoin-core-dev
2612017-09-28T13:04:35  *** wittysense has joined #bitcoin-core-dev
2622017-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
2632017-09-28T13:16:28  *** promag has joined #bitcoin-core-dev
2642017-09-28T13:37:32  *** Deacyded has quit IRC
2652017-09-28T13:39:01  *** Deacyded has joined #bitcoin-core-dev
2662017-09-28T13:40:30  *** afk11 has quit IRC
2672017-09-28T13:40:49  *** afk11 has joined #bitcoin-core-dev
2682017-09-28T13:46:18  *** Guyver2 has joined #bitcoin-core-dev
2692017-09-28T13:58:31  *** meshcollider has quit IRC
2702017-09-28T14:04:34  *** justanotheruser has quit IRC
2712017-09-28T14:10:16  *** test123 has joined #bitcoin-core-dev
2722017-09-28T14:14:11  *** tiagotrs has joined #bitcoin-core-dev
2732017-09-28T14:14:31  *** test123 has quit IRC
2742017-09-28T14:14:47  *** wraithm has joined #bitcoin-core-dev
2752017-09-28T14:15:08  *** tiagotrs has quit IRC
2762017-09-28T14:15:08  *** tiagotrs has joined #bitcoin-core-dev
2772017-09-28T14:23:18  *** Ylbam has quit IRC
2782017-09-28T14:28:05  *** promag has quit IRC
2792017-09-28T14:28:41  *** Ylbam has joined #bitcoin-core-dev
2802017-09-28T14:28:47  *** promag has joined #bitcoin-core-dev
2812017-09-28T14:39:53  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/4202273ffa45...9a8e9167f263
2822017-09-28T14:39:54  <bitcoin-git> bitcoin/master f77f0e4 Andrew Chow: Add warnings field to getblockchaininfo
2832017-09-28T14:39:54  <bitcoin-git> bitcoin/master 8502b20 Andrew Chow: Unify help text for GetWarnings output in get*info RPCs
2842017-09-28T14:39:55  <bitcoin-git> bitcoin/master 395cef7 Andrew Chow: Change getmininginfo errors field to warnings...
2852017-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
2862017-09-28T14:46:00  *** promag has quit IRC
2872017-09-28T14:57:28  *** vicenteH has quit IRC
2882017-09-28T15:06:28  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/9a8e9167f263...9d31ed2e69fd
2892017-09-28T15:06:29  <bitcoin-git> bitcoin/master 2416dd7 Cory Fields: net: separate resolving and conecting...
2902017-09-28T15:06:29  <bitcoin-git> bitcoin/master 45fd754 Cory Fields: net: remove now-superfluous numeric resolve...
2912017-09-28T15:06:30  <bitcoin-git> bitcoin/master b887676 Cory Fields: net: remove now-unused functions
2922017-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
2932017-09-28T15:15:52  *** Murch has joined #bitcoin-core-dev
2942017-09-28T15:19:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2952017-09-28T15:40:53  *** vicenteH has joined #bitcoin-core-dev
2962017-09-28T15:58:21  *** promag has joined #bitcoin-core-dev
2972017-09-28T15:58:43  *** wraithm has quit IRC
2982017-09-28T15:58:44  *** wraithm has joined #bitcoin-core-dev
2992017-09-28T16:01:47  *** JackH has quit IRC
3002017-09-28T16:06:00  *** devid has quit IRC
3012017-09-28T16:12:55  *** BashCo has quit IRC
3022017-09-28T16:29:17  *** promag has quit IRC
3032017-09-28T16:31:51  *** BashCo has joined #bitcoin-core-dev
3042017-09-28T16:59:20  *** laurentmt has quit IRC
3052017-09-28T17:00:23  <jonasschnelli> BlueMatt: how did you know I'm working on the RPC long poll notifications?
3062017-09-28T17:00:54  <jonasschnelli> I started to pick it up yesterday
3072017-09-28T17:06:10  *** timothy has quit IRC
3082017-09-28T17:11:00  <BlueMatt> lol, I'm just going through old prs
3092017-09-28T17:11:45  *** curioso has joined #bitcoin-core-dev
3102017-09-28T17:14:31  <jtimon> I'm going to miss the meeting, review beg #8498 and #8994 if at any moment seems relevant
3112017-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
3122017-09-28T17:14:34  *** Emcy has joined #bitcoin-core-dev
3132017-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
3142017-09-28T17:17:10  *** Emcy_ has quit IRC
3152017-09-28T17:18:12  <jtimon> and https://github.com/bitcoin/bitcoin/pull/10669 too, why not?
3162017-09-28T17:25:36  *** goatpig has joined #bitcoin-core-dev
3172017-09-28T17:26:01  *** Chris_Stewart_5 has quit IRC
3182017-09-28T17:26:15  *** promag has joined #bitcoin-core-dev
3192017-09-28T17:33:54  *** wittysense has quit IRC
3202017-09-28T17:34:05  *** Evel-Knievel has quit IRC
3212017-09-28T17:35:59  *** Emcy_ has joined #bitcoin-core-dev
3222017-09-28T17:36:33  *** jtimon has quit IRC
3232017-09-28T17:38:26  *** Emcy has quit IRC
3242017-09-28T17:46:08  *** promag has quit IRC
3252017-09-28T17:46:09  *** tiagotrs has quit IRC
3262017-09-28T17:54:45  *** wvr has joined #bitcoin-core-dev
3272017-09-28T17:55:42  *** meshcollider has joined #bitcoin-core-dev
3282017-09-28T17:56:30  *** m8tion has quit IRC
3292017-09-28T17:56:48  *** chjj has quit IRC
3302017-09-28T18:02:13  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9d31ed2e69fd...a72003d794f3
3312017-09-28T18:02:13  <bitcoin-git> bitcoin/master d552ed6 Paul Berg: Put back inadvertently removed copyright notices...
3322017-09-28T18:02:14  <bitcoin-git> bitcoin/master a72003d Wladimir J. van der Laan: Merge #11318: Put back inadvertently removed copyright notices...
3332017-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
3342017-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
3352017-09-28T18:06:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3362017-09-28T18:11:04  *** mess110 has joined #bitcoin-core-dev
3372017-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
3382017-09-28T18:18:17  *** wittysense has joined #bitcoin-core-dev
3392017-09-28T18:25:42  *** promag has joined #bitcoin-core-dev
3402017-09-28T18:30:02  *** promag has quit IRC
3412017-09-28T18:35:11  <wumpus> yeah, DST remains an ever present source of annoyance with timing international meetings
3422017-09-28T18:36:22  <wumpus> still a month to go here, october 29 winter time starts in NL
3432017-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 ;)
3442017-09-28T18:44:24  *** JackH has joined #bitcoin-core-dev
3452017-09-28T18:56:29  *** JackH has quit IRC
3462017-09-28T18:56:57  *** abpa has joined #bitcoin-core-dev
3472017-09-28T18:59:24  <luke-jr> you should all just adopt a tonal timezone-less clock ;)
3482017-09-28T19:00:38  <luke-jr> meeting is at .9 regardless of what part of the year
3492017-09-28T19:01:12  <instagibbs> meeting is now?
3502017-09-28T19:01:24  <wumpus> yes
3512017-09-28T19:01:28  <petertodd> if it is, then hi
3522017-09-28T19:01:29  <wumpus> #startmeeting
3532017-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.
3542017-09-28T19:01:29  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3552017-09-28T19:01:35  <achow101> hi
3562017-09-28T19:01:36  <meshcollider> Hello again
3572017-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
3582017-09-28T19:01:48  <meshcollider> lightningbot?
3592017-09-28T19:02:10  <cfields> hi
3602017-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 :)
3612017-09-28T19:02:22  <jnewbery> hi
3622017-09-28T19:02:23  <kanzure> hi.
3632017-09-28T19:02:29  <Chris_Stewart_5> hello
3642017-09-28T19:02:32  <wumpus> oh no the bot is missing
3652017-09-28T19:02:38  <wumpus> #action find the bot
3662017-09-28T19:02:46  <achow101> is it?
3672017-09-28T19:02:58  <petertodd> wumpus: one of the perils of replacing humans with machines
3682017-09-28T19:03:13  <wumpus> ehh.. no it isn't, sorry
3692017-09-28T19:03:33  <wumpus> petertodd: but it lives in the cloud! humans can't live in a cloud!
3702017-09-28T19:03:42  <wumpus> #topic High priority for review
3712017-09-28T19:04:00  * BlueMatt 's is staying....
3722017-09-28T19:04:01  <BlueMatt> again
3732017-09-28T19:04:22  <BlueMatt> 10663 got merged
3742017-09-28T19:04:25  <BlueMatt> same with 10871
3752017-09-28T19:04:44  <jonasschnelli> hi
3762017-09-28T19:04:45  <wumpus> yes, finally
3772017-09-28T19:04:57  <BlueMatt> =D
3782017-09-28T19:05:19  <wumpus> BlueMatt: yours has wallet in the name, that seems to put a curse on it with regard to reviewers
3792017-09-28T19:05:31  <luke-jr> XD
3802017-09-28T19:05:33  <jonasschnelli> Maybe someone can review #10387 (in high prio), ideally cfields
3812017-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
3822017-09-28T19:05:45  <jonasschnelli> Would be great to have this in 0.16
3832017-09-28T19:05:55  <wumpus> which reminds me
3842017-09-28T19:05:57  <cfields> jonasschnelli: will do asap
3852017-09-28T19:06:01  <wumpus> #topic put up 0.16 release schedule
3862017-09-28T19:06:04  <jonasschnelli> cfields: thanks!
3872017-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
3882017-09-28T19:06:40  <wumpus> 10387 is already in "high priority for review"
3892017-09-28T19:06:45  <jonasschnelli> Yes
3902017-09-28T19:06:49  <wumpus> BlueMatt: seems it has had quite some review though
3912017-09-28T19:06:52  <jonasschnelli> Just no reviews. :)
3922017-09-28T19:06:58  <BlueMatt> #11089 needs to get removed from high priority, it needs major rebase
3932017-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
3942017-09-28T19:07:02  <achow101> #10637 for high prio review?
3952017-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
3962017-09-28T19:07:17  <wumpus> BlueMatt: ok
3972017-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.
3982017-09-28T19:07:26  <jonasschnelli> Maybe next to the release schedule for 0.16, ... what do we want in 0.16?
3992017-09-28T19:07:37  <sipa> most of 11089's functionality is included in #11403
4002017-09-28T19:07:38  <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
4012017-09-28T19:07:44  <jonasschnelli> gmaxwell: I'm happy if you see a way how to reduce it
4022017-09-28T19:07:47  <jonasschnelli> Or split it
4032017-09-28T19:08:07  <gmaxwell> jonasschnelli: yea, will look. Sorry, didn't see it until now.
4042017-09-28T19:08:12  <wumpus> 11089 removed for now
4052017-09-28T19:08:13  <jonasschnelli> Although +264 −13 shouldn't be too large
4062017-09-28T19:08:27  <jonasschnelli> (incl. new test)
4072017-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
4082017-09-28T19:09:02  <jonasschnelli> heh
4092017-09-28T19:09:18  <luke-jr> would be nice to have GUI multiwallet in 0.16, but #10615 is stuck on desires for refactoring :/
4102017-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
4112017-09-28T19:09:40  <BlueMatt> luke-jr: I think it is unacceptable to add so many more ifdef WALLET in bitcoin server
4122017-09-28T19:09:45  <jonasschnelli> luke-jr: can you remove the rpcauth part? It's not necesdarry and contraversial.
4132017-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
4142017-09-28T19:09:48  <BlueMatt> (and believe it would be easy to remove them)
4152017-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.
4162017-09-28T19:10:03  <sipa> morcos: well there is @BitcoinMerges...
4172017-09-28T19:10:08  <gmaxwell> (and in our case we don't have any configuration where it shouldn't be set, AFAIK)
4182017-09-28T19:10:23  <wumpus> morcos: well at least we can fit twice as much code in a tweet now...
4192017-09-28T19:10:24  <morcos> sipa: that's brilliant, at least it would constantly remind me
4202017-09-28T19:10:29  <jonasschnelli> gmaxwell: maybe no longer required with a single NODE_NETWORK_LIMITED bit
4212017-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
4222017-09-28T19:10:49  <jonasschnelli> luke-jr: it's a fact that it is contraversial
4232017-09-28T19:10:57  <jonasschnelli> * controversial
4242017-09-28T19:11:05  <gmaxwell> jonasschnelli: ah! right, so this code was originally based on the more complex spec.
4252017-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........
4262017-09-28T19:11:31  <jonasschnelli> gmaxwell: thanks for pointing out... i'll review it and check if I can remove the runtime switching
4272017-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 :(
4282017-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
4292017-09-28T19:12:15  <luke-jr> jnewbery: I don't see how that's possible
4302017-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.
4312017-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?
4322017-09-28T19:12:50  <luke-jr> BlueMatt: or what did you have in mind?
4332017-09-28T19:12:53  <wumpus> see e.g. #7965. We want to go toward 0 wallet references in bitcoin_server
4342017-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
4352017-09-28T19:13:14  <jonasschnelli> gmaxwell: I thought it is basically like that (factored in a bit more commits though)
4362017-09-28T19:13:17  <achow101> wumpus: we can check getinfo off that list now
4372017-09-28T19:13:25  <wumpus> achow101: thanks good point
4382017-09-28T19:13:30  <BlueMatt> luke-jr: yes, that would be sufficient
4392017-09-28T19:13:33  <BlueMatt> imo
4402017-09-28T19:13:54  <luke-jr> ok, I'll try that
4412017-09-28T19:13:58  <wumpus> achow101: updated
4422017-09-28T19:14:15  <BlueMatt> luke-jr: you may wish to seek concept acks on the *idea* of rpc auth-based multiwallet
4432017-09-28T19:14:20  <BlueMatt> I'm ok with it, but I dont know if others are
4442017-09-28T19:14:28  <luke-jr> #action refactor #10615 for a "populate JSONRequest" callback, and separate out rpcauth stuff
4452017-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
4462017-09-28T19:14:54  <gmaxwell> jonasschnelli: ah, right though the setter isn't simple like I expected but now I understand why.
4472017-09-28T19:14:54  <jonasschnelli> BlueMatt , luke-jr : the rpcauth multiwallet is completely orthogonal to GUI multiwallet
4482017-09-28T19:14:59  <gmaxwell> and that should be fixable.
4492017-09-28T19:15:23  <wumpus> jonasschnelli: indeed, let's not confound things unnecessarily
4502017-09-28T19:15:33  *** Cheeseo has joined #bitcoin-core-dev
4512017-09-28T19:15:34  <luke-jr> jonasschnelli: yeah, I'll split it off
4522017-09-28T19:15:48  <jonasschnelli> yes. It's smells like smuggling in controversial stuff packed in a nice feature
4532017-09-28T19:15:55  <gmaxwell> Yes, please split those things up. (I say this as a supporter of rpcauth based multiwallet control)
4542017-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?)
4552017-09-28T19:16:25  <luke-jr> sipa: well, it wasn't meant to be a security thing, but maybe we can consider that
4562017-09-28T19:16:44  <sipa> yeah, just saying - i think multiwallet gui can be done much faster
4572017-09-28T19:16:47  <luke-jr> right
4582017-09-28T19:16:48  <BlueMatt> I was assuming rpcauth-based multiwallet would only allow you to call wallet functions
4592017-09-28T19:16:52  <sipa> everyone clearly wants it
4602017-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.
4612017-09-28T19:16:58  <jonasschnelli> rpcauth opens up the usecase and suddenly users think Core is a 100k multiuser wallet system
4622017-09-28T19:17:08  <jonasschnelli> we just need to be sure we want this
4632017-09-28T19:17:08  <wumpus> yes, multiwallet GUI isn't controversial in any way
4642017-09-28T19:17:18  <gmaxwell> jonasschnelli: Then we can simply say it isn't. I don't think that is a good argument.
4652017-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
4662017-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
4672017-09-28T19:17:43  <achow101> gmaxwell: people will probably still use it that way though
4682017-09-28T19:17:46  <luke-jr> leaving `stop` etc accessible makes it clearly not that IMO
4692017-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
4702017-09-28T19:17:55  *** PaulCapestany has quit IRC
4712017-09-28T19:18:01  <wumpus> morcos: +1, I'm kind of sick of discussing that tbh
4722017-09-28T19:18:12  <jonasschnelli> `/rpcauth (ack)
4732017-09-28T19:18:17  <luke-jr> wumpus: #11383 is there already, just needs to get past this initial stuff
4742017-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
4752017-09-28T19:18:25  <wumpus> luke-jr: yes
4762017-09-28T19:18:38  <wumpus> so anything that needs to be discussed with regard to  GUI multiwallet?
4772017-09-28T19:19:04  <luke-jr> someone mentioned that they think the current design is too unobservable
4782017-09-28T19:19:05  <wumpus> if not, any other topics?
4792017-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
4802017-09-28T19:19:25  <BlueMatt> yes, next topic?
4812017-09-28T19:19:40  <jonasschnelli> topic: I wanted to ask if there are opinions against the concept of RPC long poll
4822017-09-28T19:19:47  <jonasschnelli> I'd like to work on this for 0.16
4832017-09-28T19:19:48  <wumpus> #topic RPC long poll
4842017-09-28T19:19:49  <sipa> i'd like to bring up segwit wallet support
4852017-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)
4862017-09-28T19:20:10  <BlueMatt> jonasschnelli: please give a tl;dr; of what it is :)
4872017-09-28T19:20:12  <wumpus> jonasschnelli: no, no problems with it, I think it's superior to other ways we've considered
4882017-09-28T19:20:14  <jonasschnelli> RPC long poll would allow similar push benefits then ZMQ offers but without any dependencies
4892017-09-28T19:20:29  <gmaxwell> jonasschnelli: long poll for what specifically?
4902017-09-28T19:20:36  <luke-jr> jonasschnelli: we already have RPC long poll
4912017-09-28T19:20:37  <wumpus> for any of the current notifications
4922017-09-28T19:20:43  <wumpus> blocks, transactions, wallet events
4932017-09-28T19:20:47  <gmaxwell> you mean like blocks and transactions...
4942017-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
4952017-09-28T19:20:49  <gmaxwell> ah.
4962017-09-28T19:20:58  <jonasschnelli> It's how Cellphone OSes do push notifications
4972017-09-28T19:21:00  <wumpus> yes. the stuff that now requires launching an external notify script
4982017-09-28T19:21:03  <jonasschnelli> very nat friendlly
4992017-09-28T19:21:11  <wumpus> jonasschnelli: yes, it's very basic and easy to use
5002017-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.
5012017-09-28T19:21:22  <jonasschnelli> Very easy to use... no ZMQ library, just an http client
5022017-09-28T19:21:24  <sdaftuar> how does reopening work?  i don't understand how you avoid missing transactions in between
5032017-09-28T19:21:41  <luke-jr> gmaxwell: hopefully. libevent has a history of having problems in this area IIRC
5042017-09-28T19:21:46  <jonasschnelli> sdaftuar: you just open the http channel again... there is a queue on the server..
5052017-09-28T19:21:47  <wumpus> it's not meant as a competition to ZMQ, ZMQ will stay
5062017-09-28T19:21:51  <jonasschnelli> losing notifications is impossible
5072017-09-28T19:21:57  <jonasschnelli> (or very unlikely)
5082017-09-28T19:22:02  <luke-jr> sdaftuar: you have a session
5092017-09-28T19:22:12  <gmaxwell> jonasschnelli: impossible and very unlikely are not the same. :P
5102017-09-28T19:22:21  <cfields> didn't we have this discussion wrt waitfornewblock and friends? I'm missing how this is different
5112017-09-28T19:22:23  <wumpus> zmq is for low latency notifications, longpoll is for easy notifications over the same channel RPC already works
5122017-09-28T19:22:25  <jonasschnelli> yeah.. probably same level then ZMQ (where you can also loose nots)
5132017-09-28T19:22:43  <wumpus> zmq requires careful extra setup
5142017-09-28T19:22:50  <luke-jr> or order the events, and have the client request with the last-seen-event (as GBT does)
5152017-09-28T19:22:52  <jonasschnelli> It would allow clients to better interect with Core without opening an ZMQ & RPC channel (only RPC)
5162017-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. :)
5172017-09-28T19:23:00  <jonasschnelli> and it would allow *auth based notifications"
5182017-09-28T19:23:03  <jonasschnelli> like wallet notifications
5192017-09-28T19:23:10  <jonasschnelli> (which should be behing the auth)
5202017-09-28T19:23:33  <jonasschnelli> notifications may lead to an RPC roundtrip...
5212017-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
5222017-09-28T19:23:41  <BlueMatt> if its for wallet you can just use it to get info about when you need to call listsinceblock
5232017-09-28T19:23:43  <gmaxwell> ZMQ has wire protocol incompatiblity between versions, which makes it harder to use except in very tightly coupled setups.
5242017-09-28T19:23:44  <jonasschnelli> It just ellimitens constant triggering
5252017-09-28T19:23:50  <BlueMatt> which isnt so bad...but for mempool its unclear how you can do it safely
5262017-09-28T19:23:55  <wumpus> gmaxwell: we have to be realistic too
5272017-09-28T19:23:59  <sipa> wumpus: but on the next notification you'll notice it
5282017-09-28T19:24:11  <gmaxwell> wumpus: Is there a reason we can't give a reliable notification?
5292017-09-28T19:24:12  <wumpus> sipa: yes, that's why the zmq notifications have sequence numebrs too
5302017-09-28T19:24:15  <luke-jr> we probably don't want to use the same LP for wallet and non-wallet
5312017-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
5322017-09-28T19:24:54  <jonasschnelli> My LP PR (which I'm currently re-doing) has sequence numbers
5332017-09-28T19:25:02  <cfields> ah
5342017-09-28T19:25:04  <wumpus> gmaxwell: well the problem is that send buffers can be full
5352017-09-28T19:25:16  <jonasschnelli> If you miss a notification, do a data re-sync
5362017-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, ...
5372017-09-28T19:25:20  <wumpus> gmaxwell: 100%(ish) reliable notifications means storing them to disk if the client isn't processing them
5382017-09-28T19:25:34  <sipa> and the server keeps track of what the client has seen and hasn't
5392017-09-28T19:25:50  <BlueMatt> (as long as all of those events come out of the CValidationInterface =D)
5402017-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"
5412017-09-28T19:25:53  <wumpus> gmaxwell: I mean reliable messaging/notification is a huge topic in itself..
5422017-09-28T19:26:02  <luke-jr> sipa: not the same thing, but perhaps has some overlap
5432017-09-28T19:26:04  <gmaxwell> wumpus: or allowing the send buffer to grow to the point that it gets swapped out and ultimately crashes. :)
5442017-09-28T19:26:10  <sipa> luke-jr: indeed, it seems related
5452017-09-28T19:26:19  <wumpus> gmaxwell: yes, in which case it's lost too
5462017-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
5472017-09-28T19:26:29  <jonasschnelli> It's multi-client capable
5482017-09-28T19:26:46  <wumpus> luke-jr: yeah there's certainly overlap there
5492017-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.
5502017-09-28T19:26:56  <wumpus> luke-jr: block consumers ideally should be able to set a low-water mark
5512017-09-28T19:27:14  <luke-jr> maybe they should share jonasschnelli's UUID
5522017-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)
5532017-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
5542017-09-28T19:27:42  <luke-jr> although for block consumption, we'd want to store it in a persistent db IMO
5552017-09-28T19:28:02  <luke-jr> (or could use rwconf and have a config param, but that seems ugly for this)
5562017-09-28T19:28:16  <gmaxwell> obligitory question: Is any user asking for this or is it just interesting?
5572017-09-28T19:28:39  <jonasschnelli> gmaxwell: Yes. Me as an user... :)
5582017-09-28T19:28:42  <wumpus> yes yes yes
5592017-09-28T19:28:48  <luke-jr> gmaxwell: the block consumption part would allow Armory to do pruning, at least ;0
5602017-09-28T19:28:51  <wumpus> joinmarket for example would like a better notification mechanism
5612017-09-28T19:28:52  <jonasschnelli> (for the hardware wallet client i'm working)
5622017-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?
5632017-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
5642017-09-28T19:29:10  *** SopaXorzTaker has quit IRC
5652017-09-28T19:29:15  <luke-jr> cfields: I don't see why not
5662017-09-28T19:29:23  <wumpus> gmaxwell: if their software could just subscribe to events through RPC, that problem'd be solved
5672017-09-28T19:29:33  <cfields> that's interesting
5682017-09-28T19:29:34  <jonasschnelli> See also https://github.com/bitcoin/bitcoin/pull/10554
5692017-09-28T19:29:35  <gmaxwell> wumpus: why doesn't it just poll?
5702017-09-28T19:29:36  <wumpus> no need for restarting bitcoind even!
5712017-09-28T19:29:37  <jonasschnelli> #10554
5722017-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
5732017-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
5742017-09-28T19:29:52  <luke-jr> related: my GUI NetWatch branch has a circular memory-efficient buffer of weak-linked txs and blocks
5752017-09-28T19:29:53  <wumpus> gmaxwell: because polling sucks
5762017-09-28T19:29:55  <jonasschnelli> BlueMatt: good point
5772017-09-28T19:30:10  <wumpus> it causes extra delays, at least, and uses more CPU time
5782017-09-28T19:30:25  <wumpus> (depending on how fast you poll)
5792017-09-28T19:30:40  <jonasschnelli> wumpus: and the UX may suck,... LP gives you a TX, block within ms not s
5802017-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
5812017-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.
5822017-09-28T19:31:08  <gmaxwell> wumpus: because we already have one almost unused unreliable notification system.
5832017-09-28T19:31:16  <wumpus> sigh, never mind
5842017-09-28T19:31:19  <wumpus> another topic?
5852017-09-28T19:31:24  <jonasschnelli> sipa had one
5862017-09-28T19:31:34  <gmaxwell> bleh, I'm not trying to bludgon it.
5872017-09-28T19:31:35  <wumpus> and no, zmq is not unused
5882017-09-28T19:31:52  <jonasschnelli> IMO it is heavely used in some enterprises
5892017-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
5902017-09-28T19:32:10  <gmaxwell> I've never encountered someone using it in production. I don't doubt that it is somewhere.
5912017-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
5922017-09-28T19:32:23  * BlueMatt 's preferred method of notification is the "hey, you should poll now" method
5932017-09-28T19:32:26  <sipa> i think there is a lot of merit in creating a reliable event logging system for clients to observe
5942017-09-28T19:32:36  <luke-jr> BlueMatt: indeed, blocknotify is sane IMO
5952017-09-28T19:32:41  <sipa> if we have that, adding a notification for "you have new events!" seems both trivial and obvious
5962017-09-28T19:32:52  <jnewbery> suggested topic: next Bitcoin Core meetup
5972017-09-28T19:32:58  <jonasschnelli> BlueMatt: ZMQ / LP is  "hey, you should poll now"
5982017-09-28T19:32:59  <cfields> agreed. and agree with wumpus. Seems like a no-brainer to me.
5992017-09-28T19:33:00  <luke-jr> jnewbery: another one?
6002017-09-28T19:33:01  <jonasschnelli> We only send hashes
6012017-09-28T19:33:19  <BlueMatt> jonasschnelli: I wouldnt even send hashes
6022017-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
6032017-09-28T19:33:30  <BlueMatt> just do the old "disconnect upon new data" pattern
6042017-09-28T19:33:33  <gmaxwell> le, but I see why thats hard.
6052017-09-28T19:33:35  <luke-jr> blocknotify='killall -USR1 programname' ☺
6062017-09-28T19:33:55  *** bitsegwit has joined #bitcoin-core-dev
6072017-09-28T19:34:08  <sipa> 19:19:49 < sipa> i'd like to bring up segwit wallet support
6082017-09-28T19:34:20  <wumpus> gmaxwell: you can do polling in addition to processing notifications, that's what I mean with 'reconciliation'
6092017-09-28T19:34:24  <morcos> notification system for topic suggestions?
6102017-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.
6112017-09-28T19:35:01  <wumpus> anyhow, time for sipa's topic
6122017-09-28T19:35:06  <wumpus> #topic segwit wallet support
6132017-09-28T19:35:13  <sipa> yay!
6142017-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
6152017-09-28T19:35:25  <wumpus> morcos: you've just missed that topic
6162017-09-28T19:35:29  <wumpus> :p
6172017-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
6182017-09-28T19:35:52  <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
6192017-09-28T19:36:00  <sipa> however, i think there are 2 differences compared to what we discussed before
6202017-09-28T19:36:44  <sipa> 1) importprivkey works, and actually imports all corresponding addresses for that given key (P2PKH, P2SH-P2WPKH, P2WPKH)
6212017-09-28T19:36:48  <wumpus> nice
6222017-09-28T19:37:09  *** Aaronvan_ is now known as AaronvanW
6232017-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)
6242017-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
6252017-09-28T19:39:05  <luke-jr> why 2?
6262017-09-28T19:39:06  <BlueMatt> wait, why?
6272017-09-28T19:39:07  <morcos> 2 confuses me
6282017-09-28T19:39:19  <sipa> which differs from the earlier idea of every new addresses effectively calling addwitnessaddress
6292017-09-28T19:39:24  <BlueMatt> yea, what we discussed was auto-addwitnessaddress
6302017-09-28T19:39:34  <morcos> i think it depends on what we are expecting 0.16 to do
6312017-09-28T19:39:39  <sipa> well, auto-addwitnessaddress doesn't actually achieve what you want either
6322017-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
6332017-09-28T19:41:08  *** chjj has joined #bitcoin-core-dev
6342017-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
6352017-09-28T19:42:00  <meshcollider> Oh so if you wrote them to the file downgrading would be fine
6362017-09-28T19:42:32  <achow101> sipa: why not write them?
6372017-09-28T19:42:32  <sipa> meshcollider: not really... new transactions you receive while downgrading are risky
6382017-09-28T19:42:41  <sipa> achow101: bloat, and it doesn't fully solve the problem
6392017-09-28T19:42:45  <BlueMatt> sipa: yes, why did you decide to do that over the previous discussion?
6402017-09-28T19:43:03  <luke-jr> morcos: don't add segwit stuff for old keys..
6412017-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
6422017-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.
6432017-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
6442017-09-28T19:44:05  *** SopaXorzTaker has joined #bitcoin-core-dev
6452017-09-28T19:44:06  <BlueMatt> sipa: huh? I figured youd "auto-addwitnessaddress" when you getnewaddress/get the address for gui/etc
6462017-09-28T19:44:10  <BlueMatt> not when the key is generated
6472017-09-28T19:44:17  <sipa> BlueMatt: that won't work at all
6482017-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.
6492017-09-28T19:44:30  <sipa> BlueMatt: as old versions will then miss all transactions received while offline
6502017-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..
6512017-09-28T19:44:33  <BlueMatt> sipa: yes, please explain why
6522017-09-28T19:44:42  <sipa> (their keypool entries won't have witnesses, so won't be watched for)
6532017-09-28T19:44:48  <luke-jr> gmaxwell: we can leave existing keys alone, at least
6542017-09-28T19:44:48  <BlueMatt> ah, i see your point
6552017-09-28T19:44:52  *** SopaXorzTaker has quit IRC
6562017-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...
6572017-09-28T19:44:59  <gmaxwell> yea.
6582017-09-28T19:45:25  *** SopaXorzTaker has joined #bitcoin-core-dev
6592017-09-28T19:45:29  <luke-jr> gmaxwell: only if you restore a backup with an old version?
6602017-09-28T19:45:36  <luke-jr> that seems like a very niche problem area
6612017-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...
6622017-09-28T19:45:51  <luke-jr> "when restoring a backup, don't use old versions" seems the straightforward "fix"
6632017-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.
6642017-09-28T19:46:22  *** mess110 has quit IRC
6652017-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.
6662017-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..
6672017-09-28T19:46:46  <BlueMatt> sipa: so downgrades are broken anyway cause they wont know to scan for witness-ified scripts anyway
6682017-09-28T19:46:50  <BlueMatt> (and you have to do a rescan or so)
6692017-09-28T19:46:54  <gmaxwell> by old restores I mean downgrade.
6702017-09-28T19:47:01  *** SopaXorzTaker has quit IRC
6712017-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
6722017-09-28T19:47:20  <luke-jr> no backup/restore involved
6732017-09-28T19:47:26  <BlueMatt> sipa: so it sounds like we're back to needing to bump wallet version?
6742017-09-28T19:47:35  *** SopaXorzTaker has joined #bitcoin-core-dev
6752017-09-28T19:47:41  <sipa> BlueMatt: that would be nice, yes...
6762017-09-28T19:47:45  <gmaxwell> luke-jr: right, it doesn't downgrade.
6772017-09-28T19:47:45  *** mess110 has joined #bitcoin-core-dev
6782017-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.
6792017-09-28T19:48:10  <BlueMatt> sipa: so are we back to the wallet-overhaul-ish approach, then?
6802017-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
6812017-09-28T19:48:18  <luke-jr> if it doesn't downgrade, I see no value in this temporary approach
6822017-09-28T19:48:24  <sipa> morcos: it's spelled out
6832017-09-28T19:48:25  <sipa> BlueMatt: NO
6842017-09-28T19:48:28  <gmaxwell> jesus fucking christ.
6852017-09-28T19:48:39  <sipa> BlueMatt: all we need is a version number
6862017-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
6872017-09-28T19:48:47  <sipa> overhauling will take far longer
6882017-09-28T19:48:49  <morcos> sipa: where is it spelled out
6892017-09-28T19:48:53  <sipa> morcos: it doesn't make 0.16 harder
6902017-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.
6912017-09-28T19:48:56  <morcos> i agree, overhaul is goign to take a long time
6922017-09-28T19:49:05  <morcos> but i just want to understand now what we are going to do
6932017-09-28T19:49:10  <BlueMatt> sipa: well at a minimum its now blocked on hd upgrade, then, no?
6942017-09-28T19:49:21  <sipa> BlueMatt: no
6952017-09-28T19:49:24  <BlueMatt> why not?
6962017-09-28T19:49:34  <gmaxwell> BlueMatt: there is a pretty straight forward fix, set the version to maximum and introduce a new version field.
6972017-09-28T19:49:47  <BlueMatt> argh, lets not
6982017-09-28T19:49:52  <sipa> hd upgrade requires a new backup
6992017-09-28T19:49:54  <sipa> _this doesn't_
7002017-09-28T19:50:12  <BlueMatt> hd upgrade requires no more backup than keypool topup
7012017-09-28T19:50:15  <sipa> it should simply be "minimum software version to read this file is X"
7022017-09-28T19:50:22  <BlueMatt> (hd upgrade doesnt neccessarily imply you *must* wipe your keypool)
7032017-09-28T19:50:23  *** promag has joined #bitcoin-core-dev
7042017-09-28T19:50:27  *** SopaXorzTaker has quit IRC
7052017-09-28T19:50:35  <sipa> BlueMatt: it will write a hd master key though, which must be backed up
7062017-09-28T19:50:36  <BlueMatt> (and is also quite simple)
7072017-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?
7082017-09-28T19:51:09  *** SopaXorzTaker has joined #bitcoin-core-dev
7092017-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
7102017-09-28T19:51:33  <sipa> and it may make expectations unclear
7112017-09-28T19:52:07  <BlueMatt> you mean as long as you dont restore a backup, just use the latest wallet, right?
7122017-09-28T19:52:15  <BlueMatt> ie via the addwitnessaddress method?
7132017-09-28T19:52:18  <sipa> yes
7142017-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.
7152017-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
7162017-09-28T19:52:56  <sdaftuar> gmaxwell: i agree that restoring a backup is important, and supporting downgrade not a big deal
7172017-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?
7182017-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.
7192017-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
7202017-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.
7212017-09-28T19:53:16  <BlueMatt> "don't restore a backup"???
7222017-09-28T19:53:21  <sipa> ^ from my PR description
7232017-09-28T19:53:41  <BlueMatt> sipa: yes, to me that implies we need to bump wallet version
7242017-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)
7252017-09-28T19:53:53  <BlueMatt> which is fine, but that leads us back to the question of hd upgrade
7262017-09-28T19:54:04  <BlueMatt> we can do some hack to let people upgrade to segwit-wallet without an hd upgrade
7272017-09-28T19:54:12  <BlueMatt> or we can jsut implement hd upgrade, which I think is rather trivial
7282017-09-28T19:54:28  <promag> instagibbs: is https://github.com/bitcoin/bitcoin/pull/11407/files#diff-06ca130427d8b52a085dc51ffea1a541R545 really necessary?
7292017-09-28T19:54:32  <gmaxwell> BlueMatt: Trivial but invalidates their backups.
7302017-09-28T19:54:37  <instagibbs> promag, meeting wait please
7312017-09-28T19:54:47  <BlueMatt> gmaxwell: see previous discussion on keypool? or do you mean locked wallets?
7322017-09-28T19:54:50  <BlueMatt> thats a rather narrow use-case, no?
7332017-09-28T19:55:15  <sipa> BlueMatt: yeah, i don't know
7342017-09-28T19:55:25  <sipa> i may be convinced of doing the addwitnessaddress approach
7352017-09-28T19:55:36  * BlueMatt would prefer hd-upgrade over dirty hacks, but I'm open to discussion
7362017-09-28T19:55:55  <sipa> though i'm uneasy with the inability to restore while downgrading
7372017-09-28T19:56:06  <BlueMatt> yea, I'd tend to agree
7382017-09-28T19:56:19  <luke-jr> what if we bump the wallet version only in backups?
7392017-09-28T19:56:20  <sipa> on the other hand - everything will be fixed by upgrading again and rescanning
7402017-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.
7412017-09-28T19:56:35  <wumpus> 3 minutes to go
7422017-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.
7432017-09-28T19:57:23  <luke-jr> backups don't need to use the same version as the latest-wallet
7442017-09-28T19:57:34  <sipa> luke-jr: people use cp to make backups
7452017-09-28T19:57:39  <luke-jr> sipa: that's broken
7462017-09-28T19:57:43  <luke-jr> :/
7472017-09-28T19:57:51  <sipa> luke-jr: irrelevant - it will cause lost funds
7482017-09-28T19:58:04  <luke-jr> it can cause lost funds even as-is
7492017-09-28T19:58:26  <gmaxwell> luke-jr: yes, but it's a minor addition to make it not load in older software.
7502017-09-28T19:58:52  <jnewbery> suggested topic: next Bitcoin Core meetup
7512017-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
7522017-09-28T19:58:57  <sipa> endtopic
7532017-09-28T19:58:59  <wumpus> #topic suggested topic: next Bitcoin Core meetup (jnewbery)
7542017-09-28T19:59:01  <BlueMatt> sdaftuar: points out that downgrade + restore is always broken
7552017-09-28T19:59:06  <achow101> jnewbery: already?
7562017-09-28T19:59:08  <BlueMatt> cause even if you bump the version number....
7572017-09-28T19:59:10  <instagibbs> NYC :D
7582017-09-28T19:59:15  <BlueMatt> hence why its nice to have an explicit walletupgrade
7592017-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
7602017-09-28T19:59:34  <sipa> jnewbery: what timeframe were you thinking of?
7612017-09-28T19:59:40  <luke-jr> BlueMatt: can you elaborate on sdaftuar's point after meeting?
7622017-09-28T19:59:44  <jnewbery> more details to follow by email
7632017-09-28T19:59:47  <BlueMatt> luke-jr: yes
7642017-09-28T19:59:54  *** laurentmt has joined #bitcoin-core-dev
7652017-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
7662017-09-28T20:00:15  <luke-jr> I'm expecting a baby in February, so I will probably pass on the March meetup
7672017-09-28T20:00:17  <jonasschnelli> jnewbery: thanks for the date! thanks for organising.
7682017-09-28T20:00:18  <cfields> jnewbery: woohoo! thanks for planning!
7692017-09-28T20:00:24  <sipa> jnewbery: cool, on the way back from Financial Crypto :)
7702017-09-28T20:00:26  <instagibbs> \o/ marked on it calender
7712017-09-28T20:00:30  * jonasschnelli can't attend NYC... to bad
7722017-09-28T20:00:30  <wumpus> jnewbery: works for me
7732017-09-28T20:01:12  <cfields> luke-jr: didn't know that, congrats :)
7742017-09-28T20:01:18  <wumpus> jonasschnelli: that's two times US in a row, let's plan another one in europe next
7752017-09-28T20:01:19  <luke-jr> cfields: thx
7762017-09-28T20:01:45  <promag> europe +1
7772017-09-28T20:01:47  <jonasschnelli> wumpus: I can organise fall 2018 in Europe
7782017-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
7792017-09-28T20:01:52  <jnewbery> New York is almost in Europe. Just a short flight :)
7802017-09-28T20:02:00  <meshcollider> Australia +1 ;)
7812017-09-28T20:02:01  <luke-jr> jnewbery: lol
7822017-09-28T20:02:01  <achow101> lol
7832017-09-28T20:02:16  <jonasschnelli> jnewbery: hehe
7842017-09-28T20:02:22  <wumpus> austrialia would be fine with me too, russia meh
7852017-09-28T20:02:26  <instagibbs> not incredibly bad for Tokyo folks
7862017-09-28T20:02:27  * cfields votes for fanquake to host one at his place
7872017-09-28T20:02:48  <wumpus> anyhow thanks everyone, it's time to wrap up the meeting
7882017-09-28T20:02:52  * sipa votes for Iceland in the summer
7892017-09-28T20:03:06  <jonasschnelli> Iceland would be cool...
7902017-09-28T20:03:18  <jonasschnelli> and cold
7912017-09-28T20:03:19  <wumpus> jonasschnelli: finally a meeting in UTC+0!
7922017-09-28T20:03:20  <BlueMatt> wumpus: long since time
7932017-09-28T20:03:20  <meshcollider> https://www.irccloud.com/pastebin/XrHj6tr8
7942017-09-28T20:03:23  <wumpus> #endmeeting
7952017-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)
7962017-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
7972017-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
7982017-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
7992017-09-28T20:03:48  <meshcollider> Oops didn't mean to post that at a snippet lol
8002017-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
8012017-09-28T20:05:00  <luke-jr> meshcollider: eh, people can still review/open PRs without meeting discussion ;)
8022017-09-28T20:05:21  <cfields> jonasschnelli: got a few min to talk about 10387?
8032017-09-28T20:05:35  <wumpus> yes, meetings certainly aren't intended to become a bottleneck for discussion
8042017-09-28T20:06:01  <sipa> jnewbery: sounds like something i need to write up
8052017-09-28T20:06:16  <instagibbs> +1
8062017-09-28T20:06:31  <wumpus> IRC meetings are basically for topics that need as many people as possible to give input
8072017-09-28T20:06:46  <wumpus> for the rest please just discuss on github or IRC outside the meeting...
8082017-09-28T20:06:54  <sipa> jonasschnelli: iceland can be up to 20C in summer :)
8092017-09-28T20:07:12  <jnewbery> sipa: thanks :)
8102017-09-28T20:07:34  <meshcollider> Yeah although the PRs Luke linked were in another repo and obviously super controversial, not just review heh
8112017-09-28T20:08:22  <meshcollider> And yeah sipa: a writeup would be nice yeah I'm still confused as well haha
8122017-09-28T20:11:04  <sipa> jonasschnelli: ... if you're lucky
8132017-09-28T20:13:56  *** StopAndDecrypt_ is now known as StopAndDecrypt[m
8142017-09-28T20:13:59  *** wasi has joined #bitcoin-core-dev
8152017-09-28T20:14:15  *** StopAndDecrypt[m is now known as StopAndDecrypt|m
8162017-09-28T20:14:53  *** StopAndDecrypt|m is now known as StopAndDecrypt_
8172017-09-28T20:17:37  *** Chris_Stewart_5 has quit IRC
8182017-09-28T20:18:22  *** eck has quit IRC
8192017-09-28T20:19:06  *** eck has joined #bitcoin-core-dev
8202017-09-28T20:24:21  <wraithm> 24 hours of sun heats things up (sort of)
8212017-09-28T20:33:43  *** curioso has quit IRC
8222017-09-28T20:52:21  *** SopaXorzTaker has quit IRC
8232017-09-28T20:55:33  *** SopaXorzTaker has joined #bitcoin-core-dev
8242017-09-28T20:56:38  *** SopaXorzTaker has quit IRC
8252017-09-28T20:57:29  *** SopaXorzTaker has joined #bitcoin-core-dev
8262017-09-28T20:59:39  *** Deacyde has joined #bitcoin-core-dev
8272017-09-28T21:00:23  *** SopaXorzTaker has quit IRC
8282017-09-28T21:01:20  *** SopaXorzTaker has joined #bitcoin-core-dev
8292017-09-28T21:01:22  *** Deacyded has quit IRC
8302017-09-28T21:02:44  *** SopaXorzTaker has quit IRC
8312017-09-28T21:03:20  *** SopaXorzTaker has joined #bitcoin-core-dev
8322017-09-28T21:04:27  *** SopaXorzTaker has quit IRC
8332017-09-28T21:05:21  *** SopaXorzTaker has joined #bitcoin-core-dev
8342017-09-28T21:06:35  *** SopaXorzTaker has quit IRC
8352017-09-28T21:11:46  *** bitsegwit is now known as getSegwitty
8362017-09-28T21:11:53  *** getSegwitty is now known as getSegwity
8372017-09-28T21:22:56  *** SopaXorzTaker has joined #bitcoin-core-dev
8382017-09-28T21:24:09  *** SopaXorzTaker has quit IRC
8392017-09-28T21:24:49  *** SopaXorzTaker has joined #bitcoin-core-dev
8402017-09-28T21:37:33  *** timothy has joined #bitcoin-core-dev
8412017-09-28T21:40:27  *** Giszmo has quit IRC
8422017-09-28T21:51:17  *** mess110 has quit IRC
8432017-09-28T21:51:33  *** jtimon has joined #bitcoin-core-dev
8442017-09-28T21:52:15  *** Guyver2 has quit IRC
8452017-09-28T21:57:54  *** tknp has joined #bitcoin-core-dev
8462017-09-28T22:05:16  *** SergioMassa has joined #bitcoin-core-dev
8472017-09-28T22:11:44  *** Giszmo has joined #bitcoin-core-dev
8482017-09-28T22:13:31  *** AaronvanW has quit IRC
8492017-09-28T22:14:09  *** AaronvanW has joined #bitcoin-core-dev
8502017-09-28T22:17:31  *** laurentmt has quit IRC
8512017-09-28T22:31:06  <promag> sipa: is bench/bech32.cpp useful?
8522017-09-28T22:32:14  <sipa> promag: it's just for addresses... hardly performance critical
8532017-09-28T22:33:12  <promag> theres is base58, for comparison?
8542017-09-28T22:34:16  *** StopAndDecrypt_ has quit IRC
8552017-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. :)
8562017-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
8572017-09-28T22:36:38  <promag> heh that was me #7656
8582017-09-28T22:36:40  <gribble> https://github.com/bitcoin/bitcoin/issues/7656 | Improve EncodeBase58 performance by promag · Pull Request #7656 · bitcoin/bitcoin · GitHub
8592017-09-28T22:36:54  <gmaxwell> :)
8602017-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.
8612017-09-28T22:39:04  <promag> why not add the C version?
8622017-09-28T22:39:14  <sipa> it's less readable
8632017-09-28T22:39:32  <sipa> we prefer C++ish code over Cish code where possible
8642017-09-28T22:39:34  <gmaxwell> I don't think there is any case where the performance matters here.
8652017-09-28T22:39:46  <gmaxwell> or at least where a factor of two would matter.
8662017-09-28T22:39:49  <promag> it's also the reference implementation
8672017-09-28T22:40:16  <sipa> there's also a C++ reference implementation
8682017-09-28T22:40:24  <sipa> (which the code in my PR is based on)
8692017-09-28T22:41:34  <promag> just curious.. anyway I've added bench/bech32.cpp while reviewing #11167
8702017-09-28T22:41:38  <gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
8712017-09-28T22:42:52  *** vicenteH has quit IRC
8722017-09-28T22:44:30  *** promag has quit IRC
8732017-09-28T22:46:12  *** promag has joined #bitcoin-core-dev
8742017-09-28T22:47:14  *** Cheeseo has quit IRC
8752017-09-28T22:50:10  *** promag has quit IRC
8762017-09-28T23:01:32  *** getSegwity has quit IRC
8772017-09-28T23:04:58  *** wraithm has quit IRC
8782017-09-28T23:14:23  *** promag has joined #bitcoin-core-dev
8792017-09-28T23:28:13  *** promag has joined #bitcoin-core-dev
8802017-09-28T23:29:43  *** Giszmo has quit IRC
8812017-09-28T23:34:03  *** promag has quit IRC
8822017-09-28T23:37:18  *** promag has joined #bitcoin-core-dev
8832017-09-28T23:43:18  *** Ylbam has quit IRC
8842017-09-28T23:48:02  *** Giszmo has joined #bitcoin-core-dev
8852017-09-28T23:56:31  *** timothy has quit IRC
8862017-09-28T23:58:46  <promag> addwitnessaddress doesn't lock wallet, it should?
8872017-09-28T23:59:36  *** abpa has quit IRC
8882017-09-28T23:59:49  <sipa> i don't think so