19:00:56 <wumpus> #startmeeting
19:00:56 <lightningbot> Meeting started Thu Jun 28 19:00:56 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:56 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:12 <achow101> hi
19:01:17 <sipa> hi
19:01:24 <jonasschnelli> hi
19:01:24 <cfields> hi
19:01:43 <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 meshcollider jnewbery maaku fanquake promag provoostenator
19:02:06 <promag> hi
19:02:08 <kanzure> hi.
19:02:12 <instagibbs> hi
19:02:23 <jnewbery> half a hi. May be a little distracted for the next ~45 minutes
19:02:37 <wumpus> I've had a really crappy week so haven't been able to do much, sorry for that
19:02:49 <sipa> sorry to hear that
19:02:58 <wumpus> #topic high priority for review
19:03:42 <sipa> Currently on the list: #13425 #12196 #13062
19:03:45 <gribble> https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
19:03:47 <cfields> wumpus: :(
19:03:49 <gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
19:03:52 <wumpus> only three PRs!
19:03:52 <gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
19:04:26 <jonasschnelli> For 12196, I'm not sure if it make sense to adopt sipas output scripts descriptors in the PR itself (or later)
19:04:33 <sipa> i'd like to bring up an idea i've been working on for future wallet design/ismine logic, which may interact with #12196
19:04:35 <jonasschnelli> (since it already has some reviews/acks)
19:04:37 <gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
19:05:22 <wumpus> jonasschnelli: I think it makes sense to merge something, as you say it has a lot of ACKs, further improvements can be done later unless the current state is really unacceptable
19:05:27 <bitcoin-git> [13bitcoin] 15jnewbery opened pull request #13566: Fix get balance (06master...06fix_get_balance) 02https://github.com/bitcoin/bitcoin/pull/13566
19:05:41 <sipa> wumpus: it's more so that we create something that remains compatible with future APIs
19:05:48 <meshcollider> Hi
19:06:00 <wumpus> sipa: the API will have to be finalized before the 0.17 release
19:06:02 <sipa> (but i understand the desire to merge something; my comment would only apply to the xpub functionality)
19:06:37 <wumpus> so FWIW feature freeze for 0.17 is 2018-07-16, if the PR is already merged by then then improvement can be considered a bugfix
19:06:49 <sipa> perhaps i should clarify the scope
19:06:56 <jonasschnelli> Yes. Please
19:07:02 <sipa> my idea for output descriptors is here: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82
19:07:10 <sipa> i also have a prototype implementation for most of it
19:07:23 <wumpus> nice!
19:07:47 <jonasschnelli> Yes. I really like it.
19:07:47 <promag> wumpus: for 0.17, dyn multi-wallet in the UI is required?
19:07:51 <sipa> it is a general language that encodes all information about how to spend a whole set of keys with associated addresses/scripts/private keys/.... into one string, including support for multisig etc
19:07:56 <wumpus> promag: why?
19:08:15 <promag> it's a question
19:08:30 <wumpus> promag: we want toh ave things consistent before a release, at least, apart from that it's simply a matter of what makes it in
19:08:45 <sipa> my desire is that the entire wallet moves to something like that (so it's an implementation of my wallet descriptor rant i wrote a while ago: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2)
19:08:56 <wumpus> I recognized it :)
19:09:04 <cfields> sipa: +1, that makes a ton of sense
19:09:11 <sipa> so import/export would operate at the level of those descriptors, instead of individual keys/scripts/pubkeys/hdchains/...
19:09:40 <sipa> importmulti is already compatible with that design, for a large extent
19:10:15 <sipa> the entirety of that idea is certainly not for 0.17, however
19:10:46 <sipa> but that doesn't mean it can't be used already in relatively small scoped things already
19:10:52 <sipa> and scanutxoset is one of those
19:10:54 <jonasschnelli> what API changes would you propose for scantxoutset so we can migrate towards the output descriptors in the same cycle as migrating importmulti?
19:11:01 <wumpus> that would be very last minute, but at least using it as a guideline to be compatible with the current stuff makes sense
19:11:23 <sipa> jonasschnelli: you may not like this, but what about just dropping xpub support from the PR right now
19:11:36 <jonasschnelli> sipa: this makes the PR pretty useless... :(
19:11:42 <sipa> and then i'll PR the descriptor language, together with integration into scanutxoset
19:12:06 <sipa> jonasschnelli: i understand
19:12:10 <sipa> feel free to disagree
19:12:15 <wumpus> it makes sense to divide it up like that
19:12:18 <jonasschnelli> But if the API break would be complex and painful, we can do that.
19:12:33 <wumpus> makes tha change smaller and less complex
19:12:39 <jonasschnelli> I don't disagree... :)
19:12:48 <wumpus> (besides sipa's point of course)
19:13:11 <sipa> if your concern is that it may not make it in for 0.17, you can still PR the (already written) xpub support as is later, before feature freeze?
19:13:37 <jonasschnelli> Sure... I guess its also not utterly bad if the xpub will be in 0.18.
19:13:47 <jonasschnelli> Okay. Will remove the xpub stuff
19:14:03 <sipa> thank you. i promise i'll work on having a PRable implementation soon
19:14:25 <jonasschnelli> The question of a gap limit came up recently (related to the xpub situation) but this concept seems not to work with utxo based scans..
19:14:32 <jonasschnelli> So a fixed lookup window makes more sense IMO
19:15:15 <sipa> agree
19:15:50 <sipa> jonasschnelli: that's actually a good point against having a gap limit inside the descriptor language
19:15:59 <sipa> (as a gap limit is not relevant for all use cases)
19:16:16 <jonasschnelli> gap limit is a broken concept IMO
19:16:59 <jonasschnelli> I would not use it in the descriptors...
19:18:06 <sipa> in the context of high priority PRs that's all i have to say about it; but we can discuss this idea in more detail as a separate topic if there's interest
19:18:26 <jonasschnelli> Thanks for working on this sipa. will give more feedback soon.
19:18:32 <wumpus> any proposals for adding high-priority PRs, or rmaoving them?
19:18:57 <wumpus> heh I already considered doing a #topic change
19:19:04 <jonasschnelli> I have two topic requests: a) Cipherseed, b) Cores BIP32 derivation "standard"
19:19:44 <promag> wumpus: I'll complete #13100 soon and it could go to hp list
19:19:46 <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add menu entry to open wallet by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
19:20:03 <wumpus> let's add it whwen it's ready then
19:20:07 <promag> once ready
19:20:08 <promag> yes
19:20:30 <wumpus> #topic cipherseed
19:20:33 <jonasschnelli> I have a specification draft for a new seed format similar to BIP39 with some neat properties and – before sending to the ML – would appreciate feedback.
19:20:33 <jonasschnelli> https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
19:21:22 <jonasschnelli> (its more an announcement then a topic, sry)
19:22:06 <wumpus> #link https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
19:22:20 <wumpus> thanks for letting us know, will have a look
19:22:34 <wumpus> right, as no one has read it, I don't think there's much to discuss now
19:22:46 <wumpus> #topic cores BIP32 derivation "standard"
19:22:50 <jonasschnelli> It came up today in a discussion: Cores BIP32 derivation scheme is not specified in a BIP
19:23:12 <jonasschnelli> Some people think its vanilla/native BIP32... but its not... while other do native BIP32
19:23:26 <jonasschnelli> I'm not sure if we should define a standard for out derivation scheme...
19:23:34 <jonasschnelli> (would be a very short proposal)
19:23:42 <wumpus> agree ti would be good if the difference would be documented somewhere
19:23:46 <sipa> jonasschnelli: my thinking is that with output descriptors we can pretty much freely change it
19:23:47 <jonasschnelli> The BIP32 based derivation scheme has that security risk
19:24:08 <sipa> (including unhardened etc)
19:24:44 <jonasschnelli> Changing the scheme is one point,... but there are wallets out there following a derivation scheme that is not specified in word
19:24:47 <jonasschnelli> *words
19:25:01 <luke-jr> how does it affect other implementations?
19:25:03 <sipa> we could have a doc in our source tree that describes it
19:25:22 <wumpus> luke-jr: only in the sense that other implementations might want to replicate it
19:25:22 <sipa> i don't think it needs to be a bip; there's no real desire to convince others to adopt the same, i think?
19:25:31 <jonasschnelli> luke-jr: in case someone wants to import Cores xprivs...
19:25:33 <luke-jr> wumpus: why?
19:25:50 <wumpus> luke-jr: I don't know
19:25:57 <luke-jr> jonasschnelli: but not import a proper wallet in entirety?
19:26:13 <jonasschnelli> I precautionally wrote a tiny BIP,... but could also be used as an internal document: https://gist.github.com/jonasschnelli/0d383888ac51d5120540571173e35451
19:26:20 <luke-jr> (if there were a BIP, I would think it should cover the whole wallet format, not *just* derivation)
19:26:36 <sipa> luke-jr: saw my descriptor proposal above? :)
19:26:45 <achow101> just documnting the derivation in the docs repo is sufficient imo
19:26:52 <jonasschnelli> I think following BIP32 for "hot" wallets with private key export options is not ideal... Electrum does that as example
19:27:57 <sipa> my point is that i don't think our scheme is particularly an improvement over alternatives, or has all that much design we want to convince others about
19:28:08 <sipa> it's just one of many choices, and the one we made
19:28:18 <jonasschnelli> Agree with that. Yes.
19:28:23 <sipa> so we should just document it
19:28:28 <jonasschnelli> ack
19:28:54 <achow101> +1
19:28:55 <gmaxwell> Seems good.
19:29:22 <wumpus> agree
19:30:36 <wumpus> I think this leaves sipa's topic, but I think that's more or less discussed already?
19:31:10 <sipa> yeah, probably needs people reading the idea first to discuss more; can be done offline
19:31:44 <wumpus> right
19:31:47 <jonasschnelli> sipa: how would it interact with the keypool, flexible keypath?
19:31:56 <jonasschnelli> and a xpub
19:31:59 <sipa> jonasschnelli: keypool goes away
19:32:06 <wumpus> good riddance
19:32:35 <sipa> there is ephemeral data in the wallet associated with the descriptor (which is a black box, and descriptor specific), but in practice contains the expanded pubkeys
19:32:57 <sipa> that takes the place of the keypool- but those things don't all translate to independent keys in the wallet
19:33:06 <sipa> there would just be a single private key in your wallet, for example
19:33:22 <sipa> (or none at all; it can be in a hardware device too)
19:33:46 <sipa> flexible keypath... the descriptor just contains the path
19:34:11 <sipa> you can change it to whatever you like (but default wallets would of course pick some standard scheme)
19:34:51 <sipa> or rather you can import things with whatever path you like
19:36:09 <wumpus> makes sense
19:36:27 <jonasschnelli> Would it make sense that the descriptor support pkh(d34db33f/44'/0'/0':<seed>/1/i). (seed along with xpriv)?
19:36:32 <jonasschnelli> for backward compatibility
19:36:53 <sipa> jonasschnelli: i've thought about that, but that makes descriptors non-canonical
19:37:06 <sipa> (as in: you can't convert them to "public" form and back, and retain all information)
19:37:56 <sipa> i'm unsure how to deal with that; my thinking is initially no
19:38:13 <sipa> you can always implement it as an extra utility that converts from seed based format
19:38:20 <jonasschnelli> There is always the option of externally converting the seed to an xpriv, yes
19:39:06 <jonasschnelli> we can encode seeds into xprivs *duck*
19:39:44 <gmaxwell> Not to hijack, but has there been any progress towards implementing P2P link ephemeral encryption lately?  I know we were kinda waiting for some other networking refactors.
19:40:10 <sipa> cfields: ping?
19:40:12 <wumpus> #topic  P2Plink ephemeral encryptio
19:40:18 <jonasschnelli> I'm ready to pick that up any moment but was under the impression that sipa had plans to implement it
19:40:32 <jonasschnelli> I started with the implementation but halted at some point...
19:40:46 <jonasschnelli> I'm also not sure if we should delay it further more for "refactors"
19:40:55 <gmaxwell> I believed sipa did too, but asformentioned delays.
19:41:00 <cfields> heh, I was waiting on it to firm up. Guess we were waiting in circles :)
19:41:10 <wumpus> hehe
19:41:10 <cfields> jonasschnelli: for sure
19:41:22 <jonasschnelli> BTW: armory has implemented it and has plans to PR it to Core
19:41:26 <gmaxwell> Sipa and I made some major advances in the authentication part but the encryption doesn't need to wait on that.
19:41:27 <jonasschnelli> (not sure how soon and in what quality)
19:41:28 <sipa> cfields: waiting for encryption proposal to firm up before implementing it? or before continuing with network refactors?
19:41:44 <wumpus> jonasschnelli: oh wow
19:42:04 <jonasschnelli> Agree with gmaxwell. Authentication can be added later.
19:42:22 <cfields> sipa: i've had to put the net stuff on the backburner for now, so certainly don't wait for that.
19:42:30 <sipa> cfields: cool
19:43:07 <jonasschnelli> cfields: I think BIP151 is almost final (there is some issues with the version handshake)... the only thing that was holding me back where possible network refactors to first wait for
19:43:15 <cfields> I'm happy to help with the implementation. I was thinking we were waiting on the auth stuff.
19:43:24 <luke-jr> jonasschnelli: it can't be Final until it is adopted..
19:43:25 <gmaxwell> no, they're designed to operated independantly.
19:43:31 <jonasschnelli> Auth is additional and implementation wise it comes after 151
19:43:37 <sipa> we can implement 151 without 150
19:43:51 <gmaxwell> I would rather not use the prior auth design, we have better ones now.
19:43:54 <jonasschnelli> Yes. 150 can also be replaced (coexist) with other auth proposals
19:43:59 <sipa> fair
19:44:08 <jonasschnelli> Agree with that.
19:44:32 <jonasschnelli> sipas prework is here AFAIK: https://gist.github.com/sipa/29118d3fcfac69f9930d57433316c039
19:44:46 <sipa> i need to pick that up again
19:44:50 <gmaxwell> but right, there is no need delay 151 on auth-- it's completely oblivious to auth.
19:45:04 <jonasschnelli> I guess it uses some non-standard crypto stuff though
19:45:25 <sipa> jonasschnelli: no, https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
19:45:39 <jonasschnelli> Oh. Mistaken your gist. Thansk
19:45:42 <jonasschnelli> *thanks
19:45:45 <sipa> the other link is just some cool trick, not a serious proposal
19:46:48 <jonasschnelli> Okay. If no one else wants to work on the implementation, I will continue then with BIP151 impl.
19:47:08 <gmaxwell> Basically there was an open question of if we wanted the encryption handshake to operate in such a way that there are no fixed bytes for easy blocking/detection.  But I think we thought the benefits were too dubious.
19:47:24 <gmaxwell> Esp since traffic patterns will identify bitcoin p2p links very clearly.
19:47:34 <cfields> too dubious? you mean foiled by dpi anyway?
19:47:40 <gmaxwell> And so probably better to just stick to something simple.
19:47:47 <jonasschnelli> Agree
19:47:55 <wumpus> hiding what kind of connection something is is very difficult
19:48:03 <gmaxwell> cfields: foiled by traffic analysis or smarer DPI (that does EC operations to match traffic)
19:48:09 <gmaxwell> smarter*
19:48:35 <gmaxwell> People can always carry bitcoin over other transports in any case, ... ones that can do things like pad out to a constant bitrate...
19:48:52 <gmaxwell> but we're certantly not going to make BIP151 do that. :P
19:48:56 <cfields> mm, that's a good point
19:49:24 <wumpus> which is why tor went with pluggable obfuscation layers, this for example: https://arxiv.org/pdf/1305.3199.pdf
19:49:47 <wumpus> might be creeping the scope a bit too much
19:50:18 <gmaxwell> in any case, changing the handshake to be harder to detect was the only 'maybe' design change that I'm aware of any of us considering.
19:50:25 <gmaxwell> For 151.
19:51:03 <jonasschnelli> You mean an obfuscation of the encryption handshake?
19:51:13 <gmaxwell> So I think we're good to implement, and the only changes that might be proposed would be ones that arose as a side effect of implementing and benchmarking.
19:51:18 <gmaxwell> jonasschnelli: yes.
19:52:01 <jonasschnelli> Yes. I think there is freedom to change the specs during implementation...
19:52:04 <gmaxwell> And my view is that it's not worthwhile because without other more complex obfscuation (which will be bandwidth costly) it'll still be pretty detectable.
19:52:08 <jonasschnelli> It's not really deployed on the network yet
19:52:51 <gmaxwell> right.
19:53:31 <jonasschnelli> Yes. Better not obscure and put efforts in a long term solutions (stuff like the ScrambleSuit)
19:54:13 <cfields> my only complaint was that it required message parsing to complete the handshake, but it's been a while since I looked, so I'm not sure if that's still the case. I also got the impression that nobody else seemed all that bothered by that anyway.
19:55:06 <jonasschnelli> can you elaborate a bit more on " it required message parsing to complete the handshak"?
19:56:18 <cfields> jonasschnelli: we can discuss after the meeting, I need to take a look at the current spec
19:56:25 <jonasschnelli> sure. Thanks cfields
19:59:47 <wumpus> #endmeeting