--- Day changed Thu Sep 28 2017 00:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 00:07 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 00:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 01:08 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 01:13 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt] 01:15 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 01:36 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 01:36 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has joined #bitcoin-core-dev 01:36 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 01:38 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 01:41 < ThomasV> can someone clarify the syntax of importmulti? 01:41 < ThomasV> "Array of strings giving pubkeys that must occur in the output or redeemscript" 01:41 < ThomasV> does that mean that for each execution path of redeemScript, you have to import a different array of pubkeys? 01:42 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has quit [Ping timeout: 248 seconds] 01:46 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:49 < sipa> ThomasV: signing with anything other than pure multisig is not supported, so there can't be multiple execution paths 01:49 < sipa> so no, it's just the list of all public keys that appear 01:49 < ThomasV> sipa: will the syntax need to be changed for other scripts? 01:50 < sipa> i think it's also only necessary for single-pubkey cases 01:50 < sipa> if you give the redeemscript, you're good 01:50 < sipa> if you want solvability or signability 01:53 < 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, ...) 01:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zwptfmxfhdtgxjna] has quit [Quit: Connection closed for inactivity] 01:56 < ThomasV> sipa: so if you pass pubkeys you do not need to pass redeemscript? 01:57 < sipa> rather the other way around 01:57 < sipa> passing pubkeys (i think) is only useful for single-key cases (pay to pubkey etc) 01:58 < ThomasV> but why is it an array, then? 01:58 < ThomasV> and the doc says "Array of strings giving pubkeys that must occur in the output or redeemscript" 01:59 < ThomasV> that suggests an execution path 01:59 < sipa> yes - you're free to pass in multiple keys if they all appear 01:59 < sipa> that doesn't mean that you need to 01:59 < ThomasV> hmm 01:59 < sipa> presumably it's for being future proofness 02:00 < ThomasV> ok, so future plan is to extend that to arbitrary scripts? 02:00 < sipa> we'll only ever be able to sign the scripts we can sign 02:00 < sipa> importmulti is just a way for passing in all the information the signing logic may possibly need 02:02 < gmaxwell> I don't believe its computationally tractable to be able to sign actually arbritary scripts. 02:02 < 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 02:02 < sipa> ThomasV: if it knows the redeemscript, it knows all possible execution paths 02:02 < ThomasV> so I would expect that info to be passed to importmulti 02:02 < gmaxwell> Though there are presumably large classes that could be signed automatically, or partially using the fill in the blanks technique. 02:03 < sipa> (but currently no scripts with conditionals are supported in the signer) 02:03 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 02:04 < ThomasV> sipa: it depends what you mean by "it knows". does the signing logic execute the redeem script in order to figure that out? 02:05 < ThomasV> (or parse it) 02:05 < sipa> it uses template matching 02:05 < sipa> again, the current logic can't deal with anything other than P2PK, P2PKH, P2SH, and simple multisig 02:05 < ThomasV> ok, so the only template it currently has is pure multisig 02:06 < sipa> however, i believe that the interface for importmulti doesn't need changing 02:06 < sipa> if the signing logic gets extended 02:06 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 02:07 < 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 02:08 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds] 02:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 02:14 < 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 02:15 -!- bitbee [~bitbee@138.197.209.248] has quit [Remote host closed the connection] 02:15 -!- bitbee [~bitbee@138.197.209.248] has joined #bitcoin-core-dev 02:16 < ThomasV> when you import a key, you could also tell the wallet in which context it should be used 02:16 < 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. 02:16 < gmaxwell> or perhaps you didn't. :) 02:17 < ThomasV> I mean to tell the wallet which execution path is the key for 02:18 < sipa> i don't understand why that's necessary, if the wallet knows all execution paths anyway 02:18 < ThomasV> the wallet does not know how the script is going to be executed 02:19 < sipa> so? 02:19 < ThomasV> so, if I sign a transaction, I should provide that info 02:19 -!- bitbee [~bitbee@138.197.209.248] has quit [Remote host closed the connection] 02:19 < sipa> usually there are just a few branches, it can easily try all of that 02:20 -!- bitbee [~bitbee@138.197.209.248] has joined #bitcoin-core-dev 02:21 < 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) 02:21 < ThomasV> sipa: there might be branches that you do not want to sign. 02:22 < gmaxwell> ThomasV: I don't follow, it's for the execution path(s) that involve the corresponding public key. 02:22 < 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 02:23 < ThomasV> gmaxwell: maybe the same pubkey occurs in 2 branches 02:24 < 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. 02:25 < ThomasV> gmaxwell: exactly. my point is that making it an import time decision makes signing arbitrary scripts a lot simpler. 02:26 < ThomasV> you only need to pass the position of the signature in the witness, and the length of the witness 02:26 < ThomasV> and you don't need to fill the blanks, or parse scripts 02:27 < gmaxwell> I don't follow your thinking at all there. 02:27 < 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? 02:28 < ThomasV> gmaxwell: import_privkey_with_role(privkey, redeemscript, role_in_witness) 02:28 < sipa> sure, you may want to make that choice at signing time 02:28 < 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. 02:28 < sipa> with signature aggregation there will just be a single signature anyway :) 02:28 < sipa> much easier! *ducks* 02:29 < ThomasV> gmaxwell: my point is precisely that they do not have a fixed position. that's what I mean by role 02: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? 02:30 < ThomasV> gmaxwell: why can't it sign arbitrary scripts? 02:30 < ThomasV> the logic is "if I see that redeemscript, then I sign" 02:30 < 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. 02:31 < ThomasV> no template matching needed 02:31 < ThomasV> gmaxwell: in that case you import the same key with several roles 02:32 < 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. 02:33 < 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. 02:33 < 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. 02:33 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 02:34 < 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, ..." 02:34 < sipa> but that question isn't even relevant at this point - we only do signing of specific templates anyway 02:35 < 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 02:36 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 02:36 < gmaxwell> well the fill in the blanks would cover a far greater subset of those... 02:36 < 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 02:40 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has quit [Quit: Page closed] 02:43 -!- eck [~eck@fsf/member/eck] has quit [Quit: we out here] 02:44 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev 02:44 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 02:44 < ThomasV> gmaxwell: good point. indeed, that would be inefficient. 02:48 < 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 02:48 < ThomasV> until it's fully signed 02:49 < sipa> ThomasV: have you seen achow101'w partially signed transaction format? 02:49 < ThomasV> no 02:50 < ThomasV> is there a link? 02:50 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 02:50 < sipa> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki 02:50 < ThomasV> thanks 02:51 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 02:53 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 03:08 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 03:12 -!- promag_ [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 03:12 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Read error: Connection reset by peer] 03:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:15 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 03:24 -!- promag_ [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 03:29 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev 03:38 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds] 03:38 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has joined #bitcoin-core-dev 03:43 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has quit [Ping timeout: 248 seconds] 03:48 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-anyournevbeaebkb] has joined #bitcoin-core-dev 03:48 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 04:05 -!- StopAndDecrypt_ [~StopAndDe@142.75.255.199] has joined #bitcoin-core-dev 04:09 -!- aguycalled [~aguycalle@2a02:2450:102d:8105:e884:edcd:16f3:cf79] has joined #bitcoin-core-dev 04:09 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev 04:11 -!- wump is now known as wumpus 04:16 -!- aguycalled [~aguycalle@2a02:2450:102d:8105:e884:edcd:16f3:cf79] has quit [] 04:18 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 04:20 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9a4aa8a0e7e...4202273ffa45 04:20 < bitcoin-git> bitcoin/master fa082b4 MarcoFalke: doc: move gitian building to external repo... 04:20 < bitcoin-git> bitcoin/master 4202273 Wladimir J. van der Laan: Merge #11401: doc: move gitian building to external repo... 04:20 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 04:20 < 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 04:23 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 248 seconds] 04:23 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 04:24 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 04:24 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 04:25 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Ping timeout: 264 seconds] 04:42 -!- m8tion [~m8tion@81-65-53-254.rev.numericable.fr] has joined #bitcoin-core-dev 04:43 -!- wxxs [~chatzilla@134.19.187.45] has joined #bitcoin-core-dev 04:49 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 04:53 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev 05:01 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 05:03 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xwzivtrsqbebcfeh] has joined #bitcoin-core-dev 05:20 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 05:29 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds] 05:37 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 258 seconds] 05:39 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has joined #bitcoin-core-dev 05:44 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has quit [Ping timeout: 246 seconds] 05:58 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 248 seconds] 06:03 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 06:04 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has joined #bitcoin-core-dev 06:10 < 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 06:16 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 06:37 -!- Deacyded [~Deacyde@unaffiliated/deacyde] has quit [Read error: Connection reset by peer] 06:39 -!- Deacyded [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev 06:40 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection] 06:40 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 06:46 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:58 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-anyournevbeaebkb] has quit [Quit: Connection closed for inactivity] 07:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] 07:10 -!- test123 [c29e2dc2@gateway/web/freenode/ip.194.158.45.194] has joined #bitcoin-core-dev 07:14 -!- tiagotrs [~tiago@pD9FD6A77.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 07:14 -!- test123 [c29e2dc2@gateway/web/freenode/ip.194.158.45.194] has quit [Client Quit] 07:14 -!- wraithm [~wraithm@38.126.31.226] has joined #bitcoin-core-dev 07:15 -!- tiagotrs [~tiago@pD9FD6A77.dip0.t-ipconnect.de] has quit [Changing host] 07:15 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev 07:23 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xwzivtrsqbebcfeh] has quit [Quit: Connection closed for inactivity] 07:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 07:28 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tkatpiwlslaqerky] has joined #bitcoin-core-dev 07:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 07:39 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/4202273ffa45...9a8e9167f263 07:39 < bitcoin-git> bitcoin/master f77f0e4 Andrew Chow: Add warnings field to getblockchaininfo 07:39 < bitcoin-git> bitcoin/master 8502b20 Andrew Chow: Unify help text for GetWarnings output in get*info RPCs 07:39 < bitcoin-git> bitcoin/master 395cef7 Andrew Chow: Change getmininginfo errors field to warnings... 07:40 < 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 07:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 07:57 -!- vicenteH [~user@93.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] 08:06 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/9a8e9167f263...9d31ed2e69fd 08:06 < bitcoin-git> bitcoin/master 2416dd7 Cory Fields: net: separate resolving and conecting... 08:06 < bitcoin-git> bitcoin/master 45fd754 Cory Fields: net: remove now-superfluous numeric resolve... 08:06 < bitcoin-git> bitcoin/master b887676 Cory Fields: net: remove now-unused functions 08:07 < 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 08:15 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:19 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 08:40 -!- vicenteH [~user@93.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 08:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 08:58 -!- wraithm [~wraithm@38.126.31.226] has quit [Changing host] 08:58 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #bitcoin-core-dev 09:01 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 255 seconds] 09:06 -!- devid [d8fdc5d2@gateway/web/freenode/ip.216.253.197.210] has quit [Quit: Page closed] 09:12 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 09:29 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 09:31 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:59 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt] 10:00 < jonasschnelli> BlueMatt: how did you know I'm working on the RPC long poll notifications? 10:00 < jonasschnelli> I started to pick it up yesterday 10:06 -!- timothy [tredaelli@redhat/timothy] has quit [Ping timeout: 240 seconds] 10:11 < BlueMatt> lol, I'm just going through old prs 10:11 -!- curioso [~curioso@46.173.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev 10:14 < jtimon> I'm going to miss the meeting, review beg #8498 and #8994 if at any moment seems relevant 10:14 < 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 10:14 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 10:14 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub 10:17 -!- Emcy_ [~MC@unaffiliated/emcy] has quit [Ping timeout: 240 seconds] 10:18 < jtimon> and https://github.com/bitcoin/bitcoin/pull/10669 too, why not? 10:25 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev 10:26 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 10:26 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:33 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has quit [Quit: Lost terminal] 10:34 -!- Evel-Knievel [~Evel-Knie@178-119-237-211.access.telenet.be] has quit [] 10:35 -!- Emcy_ [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 10:36 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 10:38 -!- Emcy [~MC@unaffiliated/emcy] has quit [Ping timeout: 246 seconds] 10:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 10:46 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 248 seconds] 10:54 -!- wvr [~wvr@17.red-83-33-81.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 10:55 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-lgfbakywavogjmzr] has joined #bitcoin-core-dev 10:56 -!- m8tion [~m8tion@81-65-53-254.rev.numericable.fr] has quit [Read error: Connection reset by peer] 10:56 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 11:02 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9d31ed2e69fd...a72003d794f3 11:02 < bitcoin-git> bitcoin/master d552ed6 Paul Berg: Put back inadvertently removed copyright notices... 11:02 < bitcoin-git> bitcoin/master a72003d Wladimir J. van der Laan: Merge #11318: Put back inadvertently removed copyright notices... 11:02 < bitcoin-git> [bitcoin] laanwj closed pull request #11318: Put back inadvertently removed copyright notices (master...fix_copying) https://github.com/bitcoin/bitcoin/pull/11318 11:04 < 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 11:06 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 11:11 -!- mess110 [~kiki@78.97.218.2] has joined #bitcoin-core-dev 11:15 < 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 11:18 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has joined #bitcoin-core-dev 11:25 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 11:30 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 11:35 < wumpus> yeah, DST remains an ever present source of annoyance with timing international meetings 11:36 < wumpus> still a month to go here, october 29 winter time starts in NL 11:41 < Sentineo> I like this period though, US will switch 2 weaks before Europe to winter time. So there i less time difference ;) 11:44 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev 11:56 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Ping timeout: 255 seconds] 11:56 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 11:59 < luke-jr> you should all just adopt a tonal timezone-less clock ;) 12:00 < luke-jr> meeting is at .9 regardless of what part of the year 12:01 < instagibbs> meeting is now? 12:01 < wumpus> yes 12:01 < petertodd> if it is, then hi 12:01 < wumpus> #startmeeting 12:01 < lightningbot> Meeting started Thu Sep 28 19:01:29 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:01 < achow101> hi 12:01 < meshcollider> Hello again 12:01 < 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 12:01 < meshcollider> lightningbot? 12:02 < cfields> hi 12:02 < wumpus> luke-jr: yes, you could ignore DST for yourself and live in GMT time, the difficulty is shop opening times and such :) 12:02 < jnewbery> hi 12:02 < kanzure> hi. 12:02 < Chris_Stewart_5> hello 12:02 < wumpus> oh no the bot is missing 12:02 < wumpus> #action find the bot 12:02 < achow101> is it? 12:02 < petertodd> wumpus: one of the perils of replacing humans with machines 12:03 < wumpus> ehh.. no it isn't, sorry 12:03 < wumpus> petertodd: but it lives in the cloud! humans can't live in a cloud! 12:03 < wumpus> #topic High priority for review 12:03 * BlueMatt 's is staying.... 12:04 < BlueMatt> again 12:04 < BlueMatt> 10663 got merged 12:04 < BlueMatt> same with 10871 12:04 < jonasschnelli> hi 12:04 < wumpus> yes, finally 12:04 < BlueMatt> =D 12:05 < wumpus> BlueMatt: yours has wallet in the name, that seems to put a curse on it with regard to reviewers 12:05 < luke-jr> XD 12:05 < jonasschnelli> Maybe someone can review #10387 (in high prio), ideally cfields 12:05 < 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 12:05 < jonasschnelli> Would be great to have this in 0.16 12:05 < wumpus> which reminds me 12:05 < cfields> jonasschnelli: will do asap 12:06 < wumpus> #topic put up 0.16 release schedule 12:06 < jonasschnelli> cfields: thanks! 12:06 < 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 12:06 < wumpus> 10387 is already in "high priority for review" 12:06 < jonasschnelli> Yes 12:06 < wumpus> BlueMatt: seems it has had quite some review though 12:06 < jonasschnelli> Just no reviews. :) 12:06 < BlueMatt> #11089 needs to get removed from high priority, it needs major rebase 12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/11089 | Enable various p2sh-p2wpkh functionality by luke-jr · Pull Request #11089 · bitcoin/bitcoin · GitHub 12:07 < achow101> #10637 for high prio review? 12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub 12:07 < wumpus> BlueMatt: ok 12:07 < 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. 12:07 < jonasschnelli> Maybe next to the release schedule for 0.16, ... what do we want in 0.16? 12:07 < sipa> most of 11089's functionality is included in #11403 12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub 12:07 < jonasschnelli> gmaxwell: I'm happy if you see a way how to reduce it 12:07 < jonasschnelli> Or split it 12:08 < gmaxwell> jonasschnelli: yea, will look. Sorry, didn't see it until now. 12:08 < wumpus> 11089 removed for now 12:08 < jonasschnelli> Although +264 −13 shouldn't be too large 12:08 < jonasschnelli> (incl. new test) 12:08 < 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 12:09 < jonasschnelli> heh 12:09 < luke-jr> would be nice to have GUI multiwallet in 0.16, but #10615 is stuck on desires for refactoring :/ 12:09 < 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 12:09 < BlueMatt> luke-jr: I think it is unacceptable to add so many more ifdef WALLET in bitcoin server 12:09 < jonasschnelli> luke-jr: can you remove the rpcauth part? It's not necesdarry and contraversial. 12:09 < wumpus> this is tagged for 0.16 right now (both issues and PRs):https://github.com/bitcoin/bitcoin/milestones/0.16.0 12:09 < BlueMatt> (and believe it would be easy to remove them) 12:09 < 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. 12:10 < sipa> morcos: well there is @BitcoinMerges... 12:10 < gmaxwell> (and in our case we don't have any configuration where it shouldn't be set, AFAIK) 12:10 < wumpus> morcos: well at least we can fit twice as much code in a tweet now... 12:10 < morcos> sipa: that's brilliant, at least it would constantly remind me 12:10 < jonasschnelli> gmaxwell: maybe no longer required with a single NODE_NETWORK_LIMITED bit 12:10 < 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 12:10 < jonasschnelli> luke-jr: it's a fact that it is contraversial 12:10 < jonasschnelli> * controversial 12:11 < gmaxwell> jonasschnelli: ah! right, so this code was originally based on the more complex spec. 12: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........ 12:11 < jonasschnelli> gmaxwell: thanks for pointing out... i'll review it and check if I can remove the runtime switching 12:11 < wumpus> BlueMatt: no, you aren't, that's obviously wrong, we've been working hard to remove those as they cause circular refs :( 12:11 < 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 12:12 < luke-jr> jnewbery: I don't see how that's possible 12:12 < 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. 12:12 < luke-jr> BlueMatt: so httprpc calls a callback for "populate JSONRequest with metadata" which is only used for this one thing? 12:12 < luke-jr> BlueMatt: or what did you have in mind? 12:12 < wumpus> see e.g. #7965. We want to go toward 0 wallet references in bitcoin_server 12:12 < gribble> https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub 12:13 < jonasschnelli> gmaxwell: I thought it is basically like that (factored in a bit more commits though) 12:13 < achow101> wumpus: we can check getinfo off that list now 12:13 < wumpus> achow101: thanks good point 12:13 < BlueMatt> luke-jr: yes, that would be sufficient 12:13 < BlueMatt> imo 12:13 < luke-jr> ok, I'll try that 12:13 < wumpus> achow101: updated 12:14 < BlueMatt> luke-jr: you may wish to seek concept acks on the *idea* of rpc auth-based multiwallet 12:14 < BlueMatt> I'm ok with it, but I dont know if others are 12:14 < luke-jr> #action refactor #10615 for a "populate JSONRequest" callback, and separate out rpcauth stuff 12:14 < 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 12:14 < gmaxwell> jonasschnelli: ah, right though the setter isn't simple like I expected but now I understand why. 12:14 < jonasschnelli> BlueMatt , luke-jr : the rpcauth multiwallet is completely orthogonal to GUI multiwallet 12:14 < gmaxwell> and that should be fixable. 12:15 < wumpus> jonasschnelli: indeed, let's not confound things unnecessarily 12:15 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 12:15 < luke-jr> jonasschnelli: yeah, I'll split it off 12:15 < jonasschnelli> yes. It's smells like smuggling in controversial stuff packed in a nice feature 12:15 < gmaxwell> Yes, please split those things up. (I say this as a supporter of rpcauth based multiwallet control) 12:16 < 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?) 12:16 < luke-jr> sipa: well, it wasn't meant to be a security thing, but maybe we can consider that 12:16 < sipa> yeah, just saying - i think multiwallet gui can be done much faster 12:16 < luke-jr> right 12:16 < BlueMatt> I was assuming rpcauth-based multiwallet would only allow you to call wallet functions 12:16 < sipa> everyone clearly wants it 12:16 < gmaxwell> sipa: main interest I have in it is anti-footgun. Can't spend accidentally what you don't have access too. 12:16 < jonasschnelli> rpcauth opens up the usecase and suddenly users think Core is a 100k multiuser wallet system 12:17 < jonasschnelli> we just need to be sure we want this 12:17 < wumpus> yes, multiwallet GUI isn't controversial in any way 12:17 < gmaxwell> jonasschnelli: Then we can simply say it isn't. I don't think that is a good argument. 12:17 < morcos> yeah lets pleast punt on rpcauth for now... seems better use of our time to move towards splitting off wallet 12:17 < wumpus> the gui even has some scaffolding already to be able to handle multiple wallets IIRC, of course it's not complete 12:17 < achow101> gmaxwell: people will probably still use it that way though 12:17 < luke-jr> leaving `stop` etc accessible makes it clearly not that IMO 12:17 < 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 12:17 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Quit: .] 12:18 < wumpus> morcos: +1, I'm kind of sick of discussing that tbh 12:18 < jonasschnelli> `/rpcauth (ack) 12:18 < luke-jr> wumpus: #11383 is there already, just needs to get past this initial stuff 12:18 < gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub 12:18 < wumpus> luke-jr: yes 12:18 < wumpus> so anything that needs to be discussed with regard to GUI multiwallet? 12:19 < luke-jr> someone mentioned that they think the current design is too unobservable 12:19 < wumpus> if not, any other topics? 12:19 < jonasschnelli> the UI itself is not clear yeat. But luke-jr first approach is something we could have in 0.16 12:19 < BlueMatt> yes, next topic? 12:19 < jonasschnelli> topic: I wanted to ask if there are opinions against the concept of RPC long poll 12:19 < jonasschnelli> I'd like to work on this for 0.16 12:19 < wumpus> #topic RPC long poll 12:19 < sipa> i'd like to bring up segwit wallet support 12:20 < 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) 12:20 < BlueMatt> jonasschnelli: please give a tl;dr; of what it is :) 12:20 < wumpus> jonasschnelli: no, no problems with it, I think it's superior to other ways we've considered 12:20 < jonasschnelli> RPC long poll would allow similar push benefits then ZMQ offers but without any dependencies 12:20 < gmaxwell> jonasschnelli: long poll for what specifically? 12:20 < luke-jr> jonasschnelli: we already have RPC long poll 12:20 < wumpus> for any of the current notifications 12:20 < wumpus> blocks, transactions, wallet events 12:20 < gmaxwell> you mean like blocks and transactions... 12:20 < 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 12:20 < gmaxwell> ah. 12:20 < jonasschnelli> It's how Cellphone OSes do push notifications 12:21 < wumpus> yes. the stuff that now requires launching an external notify script 12:21 < jonasschnelli> very nat friendlly 12:21 < wumpus> jonasschnelli: yes, it's very basic and easy to use 12:21 < 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. 12:21 < jonasschnelli> Very easy to use... no ZMQ library, just an http client 12:21 < sdaftuar> how does reopening work? i don't understand how you avoid missing transactions in between 12:21 < luke-jr> gmaxwell: hopefully. libevent has a history of having problems in this area IIRC 12:21 < jonasschnelli> sdaftuar: you just open the http channel again... there is a queue on the server.. 12:21 < wumpus> it's not meant as a competition to ZMQ, ZMQ will stay 12:21 < jonasschnelli> losing notifications is impossible 12:21 < jonasschnelli> (or very unlikely) 12:22 < luke-jr> sdaftuar: you have a session 12:22 < gmaxwell> jonasschnelli: impossible and very unlikely are not the same. :P 12:22 < cfields> didn't we have this discussion wrt waitfornewblock and friends? I'm missing how this is different 12:22 < wumpus> zmq is for low latency notifications, longpoll is for easy notifications over the same channel RPC already works 12:22 < jonasschnelli> yeah.. probably same level then ZMQ (where you can also loose nots) 12:22 < wumpus> zmq requires careful extra setup 12:22 < luke-jr> or order the events, and have the client request with the last-seen-event (as GBT does) 12:22 < jonasschnelli> It would allow clients to better interect with Core without opening an ZMQ & RPC channel (only RPC) 12:22 < 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. :) 12:23 < jonasschnelli> and it would allow *auth based notifications" 12:23 < jonasschnelli> like wallet notifications 12:23 < jonasschnelli> (which should be behing the auth) 12:23 < jonasschnelli> notifications may lead to an RPC roundtrip... 12:23 < wumpus> gmaxwell: true, but the -Xnotify that launches a script can also fail to launch a script in some cases, losing notification 12:23 < BlueMatt> if its for wallet you can just use it to get info about when you need to call listsinceblock 12:23 < gmaxwell> ZMQ has wire protocol incompatiblity between versions, which makes it harder to use except in very tightly coupled setups. 12:23 < jonasschnelli> It just ellimitens constant triggering 12:23 < BlueMatt> which isnt so bad...but for mempool its unclear how you can do it safely 12:23 < wumpus> gmaxwell: we have to be realistic too 12:23 < sipa> wumpus: but on the next notification you'll notice it 12:24 < gmaxwell> wumpus: Is there a reason we can't give a reliable notification? 12:24 < wumpus> sipa: yes, that's why the zmq notifications have sequence numebrs too 12:24 < luke-jr> we probably don't want to use the same LP for wallet and non-wallet 12:24 < 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 12:24 < jonasschnelli> My LP PR (which I'm currently re-doing) has sequence numbers 12:25 < cfields> ah 12:25 < wumpus> gmaxwell: well the problem is that send buffers can be full 12:25 < jonasschnelli> If you miss a notification, do a data re-sync 12:25 < 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, ... 12:25 < wumpus> gmaxwell: 100%(ish) reliable notifications means storing them to disk if the client isn't processing them 12:25 < sipa> and the server keeps track of what the client has seen and hasn't 12:25 < BlueMatt> (as long as all of those events come out of the CValidationInterface =D) 12:25 < 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" 12:25 < wumpus> gmaxwell: I mean reliable messaging/notification is a huge topic in itself.. 12:26 < luke-jr> sipa: not the same thing, but perhaps has some overlap 12:26 < gmaxwell> wumpus: or allowing the send buffer to grow to the point that it gets swapped out and ultimately crashes. :) 12:26 < sipa> luke-jr: indeed, it seems related 12:26 < wumpus> gmaxwell: yes, in which case it's lost too 12:26 < 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 12:26 < jonasschnelli> It's multi-client capable 12:26 < wumpus> luke-jr: yeah there's certainly overlap there 12:26 < 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. 12:26 < wumpus> luke-jr: block consumers ideally should be able to set a low-water mark 12:27 < luke-jr> maybe they should share jonasschnelli's UUID 12:27 < wumpus> gmaxwell: well it needs reconciliation, you could also do that if you miss a notification ( which can be detected from the sequence number) 12:27 < wumpus> gmaxwell: so if you have something to handle potential crashes, you also have something to handle the case where a message gets lost 12:27 < luke-jr> although for block consumption, we'd want to store it in a persistent db IMO 12:28 < luke-jr> (or could use rwconf and have a config param, but that seems ugly for this) 12:28 < gmaxwell> obligitory question: Is any user asking for this or is it just interesting? 12:28 < jonasschnelli> gmaxwell: Yes. Me as an user... :) 12:28 < wumpus> yes yes yes 12:28 < luke-jr> gmaxwell: the block consumption part would allow Armory to do pruning, at least ;0 12:28 < wumpus> joinmarket for example would like a better notification mechanism 12:28 < jonasschnelli> (for the hardware wallet client i'm working) 12:28 < cfields> luke-jr: hmm, so clients could issue a single rpc command and have new blocks announcements replayed after a day offline? 12:29 < 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 12:29 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 264 seconds] 12:29 < luke-jr> cfields: I don't see why not 12:29 < wumpus> gmaxwell: if their software could just subscribe to events through RPC, that problem'd be solved 12:29 < cfields> that's interesting 12:29 < jonasschnelli> See also https://github.com/bitcoin/bitcoin/pull/10554 12:29 < gmaxwell> wumpus: why doesn't it just poll? 12:29 < wumpus> no need for restarting bitcoind even! 12:29 < jonasschnelli> #10554 12:29 < gribble> https://github.com/bitcoin/bitcoin/issues/10554 | ZMQ: add publishers for wallet transactions. by somdoron · Pull Request #10554 · bitcoin/bitcoin · GitHub 12:29 < 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 12:29 < luke-jr> related: my GUI NetWatch branch has a circular memory-efficient buffer of weak-linked txs and blocks 12:29 < wumpus> gmaxwell: because polling sucks 12:29 < jonasschnelli> BlueMatt: good point 12:30 < wumpus> it causes extra delays, at least, and uses more CPU time 12:30 < wumpus> (depending on how fast you poll) 12:30 < jonasschnelli> wumpus: and the UX may suck,... LP gives you a TX, block within ms not s 12:30 < 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 12:30 < 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. 12:31 < gmaxwell> wumpus: because we already have one almost unused unreliable notification system. 12:31 < wumpus> sigh, never mind 12:31 < wumpus> another topic? 12:31 < jonasschnelli> sipa had one 12:31 < gmaxwell> bleh, I'm not trying to bludgon it. 12:31 < wumpus> and no, zmq is not unused 12:31 < jonasschnelli> IMO it is heavely used in some enterprises 12:31 < 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 12:32 < gmaxwell> I've never encountered someone using it in production. I don't doubt that it is somewhere. 12:32 < 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 12:32 * BlueMatt 's preferred method of notification is the "hey, you should poll now" method 12:32 < sipa> i think there is a lot of merit in creating a reliable event logging system for clients to observe 12:32 < luke-jr> BlueMatt: indeed, blocknotify is sane IMO 12:32 < sipa> if we have that, adding a notification for "you have new events!" seems both trivial and obvious 12:32 < jnewbery> suggested topic: next Bitcoin Core meetup 12:32 < jonasschnelli> BlueMatt: ZMQ / LP is "hey, you should poll now" 12:32 < cfields> agreed. and agree with wumpus. Seems like a no-brainer to me. 12:33 < luke-jr> jnewbery: another one? 12:33 < jonasschnelli> We only send hashes 12:33 < BlueMatt> jonasschnelli: I wouldnt even send hashes 12:33 < 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 12:33 < BlueMatt> just do the old "disconnect upon new data" pattern 12:33 < gmaxwell> le, but I see why thats hard. 12:33 < luke-jr> blocknotify='killall -USR1 programname' ☺ 12:33 -!- bitsegwit [~seggggwit@modemcable106.221-20-96.mc.videotron.ca] has joined #bitcoin-core-dev 12:34 < sipa> 19:19:49 < sipa> i'd like to bring up segwit wallet support 12:34 < wumpus> gmaxwell: you can do polling in addition to processing notifications, that's what I mean with 'reconciliation' 12:34 < morcos> notification system for topic suggestions? 12:34 < 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. 12:35 < wumpus> anyhow, time for sipa's topic 12:35 < wumpus> #topic segwit wallet support 12:35 < sipa> yay! 12:35 < 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 12:35 < wumpus> morcos: you've just missed that topic 12:35 < wumpus> :p 12:35 < sipa> so, i have a PR #11403 which i think implements most of what we want, except some import/export and message signing 12:35 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub 12:36 < sipa> however, i think there are 2 differences compared to what we discussed before 12:36 < sipa> 1) importprivkey works, and actually imports all corresponding addresses for that given key (P2PKH, P2SH-P2WPKH, P2WPKH) 12:36 < wumpus> nice 12:37 -!- Aaronvan_ is now known as AaronvanW 12:37 < 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) 12: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 12:39 < luke-jr> why 2? 12:39 < BlueMatt> wait, why? 12:39 < morcos> 2 confuses me 12:39 < sipa> which differs from the earlier idea of every new addresses effectively calling addwitnessaddress 12:39 < BlueMatt> yea, what we discussed was auto-addwitnessaddress 12:39 < morcos> i think it depends on what we are expecting 0.16 to do 12:39 < sipa> well, auto-addwitnessaddress doesn't actually achieve what you want either 12:40 < 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 12:41 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 12:41 < sipa> effectively what the patch does is just implicitly making redeemscripts for all your keys known, without writing them to the file 12:42 < meshcollider> Oh so if you wrote them to the file downgrading would be fine 12:42 < achow101> sipa: why not write them? 12:42 < sipa> meshcollider: not really... new transactions you receive while downgrading are risky 12:42 < sipa> achow101: bloat, and it doesn't fully solve the problem 12:42 < BlueMatt> sipa: yes, why did you decide to do that over the previous discussion? 12:43 < luke-jr> morcos: don't add segwit stuff for old keys.. 12:43 < sipa> BlueMatt: because keys the old version adds to the keypool during auto-topup won't get their witnesses added, and will go undetected 12:43 < 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. 12:43 < 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 12:44 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 12:44 < BlueMatt> sipa: huh? I figured youd "auto-addwitnessaddress" when you getnewaddress/get the address for gui/etc 12:44 < BlueMatt> not when the key is generated 12:44 < sipa> BlueMatt: that won't work at all 12:44 < 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. 12:44 < sipa> BlueMatt: as old versions will then miss all transactions received while offline 12:44 < 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.. 12:44 < BlueMatt> sipa: yes, please explain why 12:44 < sipa> (their keypool entries won't have witnesses, so won't be watched for) 12:44 < luke-jr> gmaxwell: we can leave existing keys alone, at least 12:44 < BlueMatt> ah, i see your point 12:44 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 12:44 < gmaxwell> BlueMatt: then backup and restore is completely no durable and you'll miss payments if you start with a restored wallet... 12:44 < gmaxwell> yea. 12:45 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 12:45 < luke-jr> gmaxwell: only if you restore a backup with an old version? 12:45 < luke-jr> that seems like a very niche problem area 12:45 < 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... 12:45 < luke-jr> "when restoring a backup, don't use old versions" seems the straightforward "fix" 12:45 < 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. 12:46 -!- mess110 [~kiki@78.97.218.2] has quit [Quit: Leaving] 12:46 < gmaxwell> luke-jr: this whole discussion is about old restores, if you don't do that all is fantastic in sipa's code. 12:46 < 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.. 12:46 < BlueMatt> sipa: so downgrades are broken anyway cause they wont know to scan for witness-ified scripts anyway 12:46 < BlueMatt> (and you have to do a rescan or so) 12:46 < gmaxwell> by old restores I mean downgrade. 12:47 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 12:47 < 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 12:47 < luke-jr> no backup/restore involved 12:47 < BlueMatt> sipa: so it sounds like we're back to needing to bump wallet version? 12:47 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 12:47 < sipa> BlueMatt: that would be nice, yes... 12:47 < gmaxwell> luke-jr: right, it doesn't downgrade. 12:47 -!- mess110 [~kiki@78.97.218.2] has joined #bitcoin-core-dev 12:48 < gmaxwell> luke-jr: but downgrading is just not possible to support here. At best it can look kinda like it works but lose funds. 12:48 < BlueMatt> sipa: so are we back to the wallet-overhaul-ish approach, then? 12:48 < 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 12:48 < luke-jr> if it doesn't downgrade, I see no value in this temporary approach 12:48 < sipa> morcos: it's spelled out 12:48 < sipa> BlueMatt: NO 12:48 < gmaxwell> jesus fucking christ. 12:48 < sipa> BlueMatt: all we need is a version number 12:48 < 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 12:48 < sipa> overhauling will take far longer 12:48 < morcos> sipa: where is it spelled out 12:48 < sipa> morcos: it doesn't make 0.16 harder 12:48 < 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. 12:48 < morcos> i agree, overhaul is goign to take a long time 12:49 < morcos> but i just want to understand now what we are going to do 12:49 < BlueMatt> sipa: well at a minimum its now blocked on hd upgrade, then, no? 12:49 < sipa> BlueMatt: no 12:49 < BlueMatt> why not? 12:49 < gmaxwell> BlueMatt: there is a pretty straight forward fix, set the version to maximum and introduce a new version field. 12:49 < BlueMatt> argh, lets not 12:49 < sipa> hd upgrade requires a new backup 12:49 < sipa> _this doesn't_ 12:50 < BlueMatt> hd upgrade requires no more backup than keypool topup 12:50 < sipa> it should simply be "minimum software version to read this file is X" 12:50 < BlueMatt> (hd upgrade doesnt neccessarily imply you *must* wipe your keypool) 12:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 12:50 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 12:50 < sipa> BlueMatt: it will write a hd master key though, which must be backed up 12:50 < BlueMatt> (and is also quite simple) 12:51 < 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? 12:51 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 12:51 < 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 12:51 < sipa> and it may make expectations unclear 12:52 < BlueMatt> you mean as long as you dont restore a backup, just use the latest wallet, right? 12:52 < BlueMatt> ie via the addwitnessaddress method? 12:52 < sipa> yes 12:52 < 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. 12:52 < BlueMatt> gmaxwell: yes, but we generally "support" it in the sense that you have to manually do -walletupgrade if you want new features 12:52 < sdaftuar> gmaxwell: i agree that restoring a backup is important, and supporting downgrade not a big deal 12:53 < 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? 12:53 < gmaxwell> BlueMatt: don't restore a backup, don't run concurrent copies... perhaps some other corner cases we haven't considered. 12:53 < 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 12:53 < 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. 12:53 < BlueMatt> "don't restore a backup"??? 12:53 < sipa> ^ from my PR description 12:53 < BlueMatt> sipa: yes, to me that implies we need to bump wallet version 12:53 < 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) 12:53 < BlueMatt> which is fine, but that leads us back to the question of hd upgrade 12:54 < BlueMatt> we can do some hack to let people upgrade to segwit-wallet without an hd upgrade 12:54 < BlueMatt> or we can jsut implement hd upgrade, which I think is rather trivial 12:54 < promag> instagibbs: is https://github.com/bitcoin/bitcoin/pull/11407/files#diff-06ca130427d8b52a085dc51ffea1a541R545 really necessary? 12:54 < gmaxwell> BlueMatt: Trivial but invalidates their backups. 12:54 < instagibbs> promag, meeting wait please 12:54 < BlueMatt> gmaxwell: see previous discussion on keypool? or do you mean locked wallets? 12:54 < BlueMatt> thats a rather narrow use-case, no? 12:55 < sipa> BlueMatt: yeah, i don't know 12:55 < sipa> i may be convinced of doing the addwitnessaddress approach 12:55 * BlueMatt would prefer hd-upgrade over dirty hacks, but I'm open to discussion 12:55 < sipa> though i'm uneasy with the inability to restore while downgrading 12:56 < BlueMatt> yea, I'd tend to agree 12:56 < luke-jr> what if we bump the wallet version only in backups? 12:56 < sipa> on the other hand - everything will be fixed by upgrading again and rescanning 12:56 < gmaxwell> BlueMatt: hdupgrade invalidates backups, even without a locked wallet. Though thats another point you have to unlock to do it. 12:56 < wumpus> 3 minutes to go 12:57 < 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. 12:57 < luke-jr> backups don't need to use the same version as the latest-wallet 12:57 < sipa> luke-jr: people use cp to make backups 12:57 < luke-jr> sipa: that's broken 12:57 < luke-jr> :/ 12:57 < sipa> luke-jr: irrelevant - it will cause lost funds 12:58 < luke-jr> it can cause lost funds even as-is 12:58 < gmaxwell> luke-jr: yes, but it's a minor addition to make it not load in older software. 12:58 < jnewbery> suggested topic: next Bitcoin Core meetup 12:58 < 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 12:58 < sipa> endtopic 12:58 < wumpus> #topic suggested topic: next Bitcoin Core meetup (jnewbery) 12:59 < BlueMatt> sdaftuar: points out that downgrade + restore is always broken 12:59 < achow101> jnewbery: already? 12:59 < BlueMatt> cause even if you bump the version number.... 12:59 < instagibbs> NYC :D 12:59 < BlueMatt> hence why its nice to have an explicit walletupgrade 12:59 < 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 12:59 < sipa> jnewbery: what timeframe were you thinking of? 12:59 < luke-jr> BlueMatt: can you elaborate on sdaftuar's point after meeting? 12:59 < jnewbery> more details to follow by email 12:59 < BlueMatt> luke-jr: yes 12:59 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 13:00 < wumpus> achow101: better to plan it long in advance so people can take it into account, instead of on short notice 13:00 < luke-jr> I'm expecting a baby in February, so I will probably pass on the March meetup 13:00 < jonasschnelli> jnewbery: thanks for the date! thanks for organising. 13:00 < cfields> jnewbery: woohoo! thanks for planning! 13:00 < sipa> jnewbery: cool, on the way back from Financial Crypto :) 13:00 < instagibbs> \o/ marked on it calender 13:00 * jonasschnelli can't attend NYC... to bad 13:00 < wumpus> jnewbery: works for me 13:01 < cfields> luke-jr: didn't know that, congrats :) 13:01 < wumpus> jonasschnelli: that's two times US in a row, let's plan another one in europe next 13:01 < luke-jr> cfields: thx 13:01 < promag> europe +1 13:01 < jonasschnelli> wumpus: I can organise fall 2018 in Europe 13:01 < luke-jr> we haven't done Australia or Russia yet. but those might just be inconvenient for too many people :p 13:01 < jnewbery> New York is almost in Europe. Just a short flight :) 13:02 < meshcollider> Australia +1 ;) 13:02 < luke-jr> jnewbery: lol 13:02 < achow101> lol 13:02 < jonasschnelli> jnewbery: hehe 13:02 < wumpus> austrialia would be fine with me too, russia meh 13:02 < instagibbs> not incredibly bad for Tokyo folks 13:02 * cfields votes for fanquake to host one at his place 13:02 < wumpus> anyhow thanks everyone, it's time to wrap up the meeting 13:02 * sipa votes for Iceland in the summer 13:03 < jonasschnelli> Iceland would be cool... 13:03 < jonasschnelli> and cold 13:03 < wumpus> jonasschnelli: finally a meeting in UTC+0! 13:03 < BlueMatt> wumpus: long since time 13:03 < meshcollider> https://www.irccloud.com/pastebin/XrHj6tr8 13:03 < wumpus> #endmeeting 13:03 < lightningbot> Meeting ended Thu Sep 28 20:03:23 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:03 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-28-19.01.html 13:03 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-28-19.01.txt 13:03 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-28-19.01.log.html 13:03 < meshcollider> Oops didn't mean to post that at a snippet lol 13:04 < 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 13:05 < luke-jr> meshcollider: eh, people can still review/open PRs without meeting discussion ;) 13:05 < cfields> jonasschnelli: got a few min to talk about 10387? 13:05 < wumpus> yes, meetings certainly aren't intended to become a bottleneck for discussion 13:06 < sipa> jnewbery: sounds like something i need to write up 13:06 < instagibbs> +1 13:06 < wumpus> IRC meetings are basically for topics that need as many people as possible to give input 13:06 < wumpus> for the rest please just discuss on github or IRC outside the meeting... 13:06 < sipa> jonasschnelli: iceland can be up to 20C in summer :) 13:07 < jnewbery> sipa: thanks :) 13:07 < meshcollider> Yeah although the PRs Luke linked were in another repo and obviously super controversial, not just review heh 13:08 < meshcollider> And yeah sipa: a writeup would be nice yeah I'm still confused as well haha 13:11 < sipa> jonasschnelli: ... if you're lucky 13:13 -!- StopAndDecrypt_ is now known as StopAndDecrypt[m 13:13 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 13:14 -!- StopAndDecrypt[m is now known as StopAndDecrypt|m 13:14 -!- StopAndDecrypt|m is now known as StopAndDecrypt_ 13:17 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds] 13:18 -!- eck [~eck@fsf/member/eck] has quit [Quit: we out here] 13:19 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev 13:24 < wraithm> 24 hours of sun heats things up (sort of) 13:33 -!- curioso [~curioso@46.173.61.94.rev.vodafone.pt] has quit [Remote host closed the connection] 13:52 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 240 seconds] 13:55 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 13:56 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 13:57 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 13:59 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev 14:00 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 14:01 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 14:01 -!- Deacyded [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 260 seconds] 14:02 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 14:03 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 14:04 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 14:05 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 14:06 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 14:11 -!- bitsegwit is now known as getSegwitty 14:11 -!- getSegwitty is now known as getSegwity 14:22 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 14:24 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 14:24 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 14:25 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Max SendQ exceeded] 14:37 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 14:40 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Ping timeout: 260 seconds] 14:51 -!- mess110 [~kiki@78.97.218.2] has quit [Quit: Leaving] 14:51 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 14:52 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 14:57 -!- tknp [~tknp@unaffiliated/tknp] has joined #bitcoin-core-dev 15:05 -!- SergioMassa [~sergio@191.187.138.54] has joined #bitcoin-core-dev 15:11 -!- Giszmo [~leo@ip-59-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 15:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 15:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:17 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 15:31 < promag> sipa: is bench/bech32.cpp useful? 15:32 < sipa> promag: it's just for addresses... hardly performance critical 15:33 < promag> theres is base58, for comparison? 15:34 -!- StopAndDecrypt_ [~StopAndDe@142.75.255.199] has quit [Ping timeout: 255 seconds] 15:35 < 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. :) 15:35 < gmaxwell> if someone wanted to 'optimize' bech32 though they're just rip out the C++ one and put in the C one. :P 15:36 < promag> heh that was me #7656 15:36 < gribble> https://github.com/bitcoin/bitcoin/issues/7656 | Improve EncodeBase58 performance by promag · Pull Request #7656 · bitcoin/bitcoin · GitHub 15:36 < gmaxwell> :) 15:37 < 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. 15:39 < promag> why not add the C version? 15:39 < sipa> it's less readable 15:39 < sipa> we prefer C++ish code over Cish code where possible 15:39 < gmaxwell> I don't think there is any case where the performance matters here. 15:39 < gmaxwell> or at least where a factor of two would matter. 15:39 < promag> it's also the reference implementation 15:40 < sipa> there's also a C++ reference implementation 15:40 < sipa> (which the code in my PR is based on) 15:41 < promag> just curious.. anyway I've added bench/bech32.cpp while reviewing #11167 15:41 < gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub 15:42 -!- vicenteH [~user@93.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 15:44 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 15:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 15:47 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Read error: Connection reset by peer] 15:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 240 seconds] 16:01 -!- getSegwity [~seggggwit@modemcable106.221-20-96.mc.videotron.ca] has quit [Ping timeout: 260 seconds] 16:04 -!- wraithm [~wraithm@unaffiliated/wraithm] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 16:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 16:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Client Quit] 16:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 16:29 -!- Giszmo [~leo@ip-59-233.219.201.nextelmovil.cl] has quit [Read error: No route to host] 16:34 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 16:37 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 16:43 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tkatpiwlslaqerky] has quit [Quit: Connection closed for inactivity] 16:48 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev 16:56 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 16:58 < promag> addwitnessaddress doesn't lock wallet, it should? 16:59 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 16:59 < sipa> i don't think so 17:00 < sipa> unless SetAddressBook needs a lock, let me see 17:01 < sipa> nope 17:01 -!- Geoffy [~Geo@178-119-187-213.access.telenet.be] has quit [] 17:01 < promag> right, AddCScript is thread safe 17:03 < promag> sipa: however CWallet::AddCScript should be atomic, and it's not 17:04 < sipa> promag: ? 17:04 < promag> nevermind, it exits 17:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 17:18 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 17:26 -!- wxxs [~chatzilla@134.19.187.45] has quit [Remote host closed the connection] 17:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 17:35 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-lgfbakywavogjmzr] has quit [Quit: Connection closed for inactivity] 17:36 -!- To7 [~theo@2604:2000:1382:b7:5d67:ff32:8632:e814] has quit [Ping timeout: 252 seconds] 17:55 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 17:57 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 17:58 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Client Quit] 18:04 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-danqabdxtobxwiwp] has joined #bitcoin-core-dev 18:19 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 18:20 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 18:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 18:34 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 18:35 -!- lari [~quassel@195.148.220.32] has quit [Read error: Connection reset by peer] 18:57 -!- lari [~quassel@195.148.220.32] has joined #bitcoin-core-dev 19:17 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has quit [Ping timeout: 255 seconds] 19:19 -!- trippysa1mon [~trippysal@cyberdynesys.org] has quit [Ping timeout: 240 seconds] 19:21 -!- NielsvG [~Necrathex@2001:981:9573:1:d044:2ff:fe29:ad61] has joined #bitcoin-core-dev 19:21 -!- NielsvG [~Necrathex@2001:981:9573:1:d044:2ff:fe29:ad61] has quit [Changing host] 19:21 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has joined #bitcoin-core-dev 19:25 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 19:28 -!- trippysalmon [~trippysal@cyberdynesys.org] has joined #bitcoin-core-dev 19:39 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #11412: Simplify GetWarnings() (master...2017/09/getwarnings) https://github.com/bitcoin/bitcoin/pull/11412 19:40 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 20:03 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 248 seconds] 20:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds] 20:04 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds] 20:04 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 20:05 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds] 20:05 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 248 seconds] 20:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 248 seconds] 20:12 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has quit [Quit: Leaving] 20:12 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds] 20:15 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-danqabdxtobxwiwp] has quit [Quit: Connection closed for inactivity] 20:26 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 20:26 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 20:26 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 20:32 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 20:35 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ibroegxycjkdkuhi] has joined #bitcoin-core-dev 20:45 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 20:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 20:46 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 20:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 258 seconds] 20:53 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has quit [Ping timeout: 240 seconds] 20:59 < achow101> how do we handle RPC api changes? 20:59 < ossifrage> I think I just managed to get the client to take the fee from the wrong side of the transaction 21:00 < achow101> I want to change addmultisigaddress's output from an address to a json object with an address and redeemscript field, so what's the best way to do that? 21:02 < jonasschnelli> achow101: just do it and make sure it's mentioned in the release notes? 21:02 < jonasschnelli> API changes should be avoided, yes. But also we should not have every new RPC call static made in stone 21:03 < luke-jr> IMO just do it for that specific case, mainly because it's not useful for non-testing 21:04 < achow101> ok 21:05 -!- SergioMassa [~sergio@191.187.138.54] has quit [Ping timeout: 248 seconds] 21:09 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 21:10 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 21:19 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 21:30 < bitcoin-git> [bitcoin] achow101 opened pull request #11415: [RPC] Disallow using addresses in createmultisig (master...createmultisig-no-addr) https://github.com/bitcoin/bitcoin/pull/11415 21:34 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 21:35 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 21:44 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 258 seconds] 21:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 21:50 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has joined #bitcoin-core-dev 21:51 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 248 seconds] 21:54 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 21:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 21:56 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has quit [Ping timeout: 240 seconds] 21:59 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 22:12 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 22:12 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 22:24 -!- tknp [~tknp@unaffiliated/tknp] has quit [Quit: tknp] 22:24 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 22:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 22:29 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tmxuybwwpbuctxik] has joined #bitcoin-core-dev 22:36 -!- jimmysong_ [~Jimmy@23-112-39-203.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev 22:39 -!- jimmysong [~Jimmy@23-112-39-203.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 240 seconds] 22:40 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 22:41 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 22:42 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 258 seconds] 22:43 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has quit [Quit: Coyote finally caught me] 22:44 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 258 seconds] 22:52 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has joined #bitcoin-core-dev 22:57 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has quit [Ping timeout: 240 seconds] 22:59 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 23:01 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 23:09 -!- jimmysong_ [~Jimmy@23-112-39-203.lightspeed.austtx.sbcglobal.net] has quit [Read error: Connection reset by peer] 23:09 -!- pbase [~pbase@unaffiliated/pbase] has joined #bitcoin-core-dev 23:10 -!- jimmysong_ [~Jimmy@23-112-39-203.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev 23:13 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 23:15 < esotericnonsense> looking back on the meeting; I've done some work previously on serverside ZMQ tracking of topics, it's kind of a hack on the protocol but you can detect when a client disconnects and queue up messages for them for some period, if you combine that with sequence numbers and overlap them you can mitigate missing messages to some extent, but it's still a hack on the ZMQ semantics for pubsub 23:15 < esotericnonsense> (and makes the notifications stateful) 23:23 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds] 23:25 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ibroegxycjkdkuhi] has quit [Quit: Connection closed for inactivity] 23:36 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 248 seconds] 23:52 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has joined #bitcoin-core-dev 23:53 < bitcoin-git> [bitcoin] jl2012 opened pull request #11417: Correct typo in comments (master...patch-19) https://github.com/bitcoin/bitcoin/pull/11417 23:57 -!- wittysense [~wittysens@c-73-232-144-188.hsd1.tx.comcast.net] has quit [Ping timeout: 246 seconds] 23:58 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev