19:00:12 <wumpus> #startmeeting
19:00:12 <lightningbot> Meeting started Thu Aug 23 19:00:12 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:12 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:16 <sipa> hi
19:00:35 <gmaxwell> hi
19:00:35 <achow101> hi
19:00:59 <jonasschnelli> hi
19:01:04 <promag> hi
19:01:04 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark mi
19:01:08 <wumpus> chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
19:01:27 <wumpus> who has a topic?
19:01:42 <meshcollider> Hi
19:02:04 <jonasschnelli> topic proposal: tor plugable transport
19:02:08 <wumpus> MarcoFalke: I still don't see it, though I'm not sure what kind of button I'm looking for
19:02:41 <wumpus> let's start with high prio as usual
19:02:46 <wumpus> #topic high priority for review
19:03:23 <jonasschnelli> I'd like to add #14032 if that is appropriate
19:03:25 <gribble> https://github.com/bitcoin/bitcoin/issues/14032 | Add p2p layer encryption with ECDH/ChaCha20Poly1305 by jonasschnelli · Pull Request #14032 · bitcoin/bitcoin · GitHub
19:03:50 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  two were merged, one was added, this leaves five open
19:04:26 <wumpus> jonasschnelli: sure
19:04:44 <cfields> jonasschnelli: thanks, I'm excited to read that.
19:05:01 <jonasschnelli> I'm also excited to hear your feedback. :)
19:05:04 <wumpus> yes, very good to see a PR about that
19:05:07 <promag> jonasschnelli: do you think you can extract some commits to new PR's?
19:05:16 <MarcoFalke> I'd like to add #13961 (it is only refactoring, but drops the memory usage at compile time by 100Mb, also compiles faster)
19:05:18 <gribble> https://github.com/bitcoin/bitcoin/issues/13961 | util: Replace boost::signals2 with std::function by MarcoFalke · Pull Request #13961 · bitcoin/bitcoin · GitHubAsset 1Asset 1
19:05:40 <jonasschnelli> promag: I guess it's hard to make it smaller...
19:05:46 <wumpus> MarcoFalke: ok
19:05:46 <cfields> MarcoFalke: also nice :)
19:05:49 <achow101> topic suggestion: hardware wallet support
19:06:44 <wumpus> #topic tor pluggable transport (jonasschnelli)
19:06:59 <jonasschnelli> Tor has this concept of pluggable transports
19:07:01 <promag> jonasschnelli: could create a PR only with the first 3 commits, but let's talk later
19:07:04 <jonasschnelli> https://www.torproject.org/docs/pluggable-transports.html.en
19:07:08 <jonasschnelli> https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt
19:07:21 <Empact> jonasshnelli: First three commits look independent as prep work
19:07:25 <jonasschnelli> It a great concept to bypass DPI, censored envs...
19:07:56 * sipa suggests using gramtropy generated text over IRC
19:07:58 <jonasschnelli> Tor can start subprocesses that bootstrap a SOCK proxy to communicate with the counterparty
19:08:06 <gmaxwell> jonasschnelli: Why do you think we need something special for that?  We have proxy support already, which is all that is generally required for that sort of thing.
19:08:17 <jonasschnelli> I think supporting PT should be not to complicated in Core
19:08:30 <gmaxwell> I think it's so not complicated that we already have it. :)
19:08:36 <wumpus> I don't understand
19:08:40 <jonasschnelli> I'm unsure about the reverse proxy, the env vars and the auto-exec of that subprocess...
19:08:46 <wumpus> pluggable transports plug into *tor*
19:08:48 <sipa> jonasschnelli: what specific form of transport do you suggest?
19:08:53 <wumpus> bitcoin core can use tor
19:08:57 <wumpus> what else is needed?
19:09:12 <jonasschnelli> sipa: its not about specific transports,.. IMO its an API for other transport layers...
19:09:29 <sipa> jonasschnelli: it is to make tor communicate with other tor nodes using different transport layers
19:09:35 <sipa> what transport layer do you suggest?
19:09:37 <gmaxwell> The API is socks.
19:09:40 <wumpus> looks like a layer violation to worry about this? or do you want to make tor tunnel over bitcoin instead of the other way around?
19:09:43 <luke-jr> I also don't get it
19:09:46 <jonasschnelli> Maybe I got it wrong,.. but it looked to me after a pure transport layer (not tor)
19:10:07 <sipa> yes and no
19:10:07 <wumpus> yes, socks (+optional control port) is good enough as API
19:10:20 <wumpus> it's the only way it's recommended to use tor
19:10:20 <sipa> jonasschnelli: i'm very confused by what you suggest
19:10:45 <sipa> so far you've said "we can use tor pluggable transport", which is true for any tor user
19:10:51 <phantomcircuit> jonasschnelli, the pluggable transport presents a socks interface which tor uses instead of directly connecting
19:10:58 <sipa> how is it bitcoin specific, or what do you specifically propose?
19:11:00 <wumpus> integrating tor's code into bitcoin core is not a good idea
19:11:07 <kanzure> merge tor source tree
19:11:09 <phantomcircuit> it's not something that should be configured by things using tor
19:11:25 <wumpus> indeed, it's part of the tor configuration
19:11:27 <jonasschnelli> The idea is to make Bitcoin work in DPI env in case it would get blocked,.. like China or Iran
19:11:31 <jonasschnelli> Without relying on tor
19:11:36 <gmaxwell> wumpus: I think jonasschnelli suggests that we have support for these obfscuated transports without putting tor in the middle.  I think we already do (in fact, I used one of the ones made for tor to bridge bitcoin nodes last year when we were worried about china blocking bitcoin... before later changing to an icecast stream so that it wouldn't be identifyable by traffic analysis)
19:11:42 <jonasschnelli> Core could directly use obfs4
19:11:47 <gmaxwell> jonasschnelli: we already can.
19:11:56 <jonasschnelli> or meek
19:12:03 <sipa> jonasschnelli: ah!
19:12:14 <wumpus> gmaxwell: ohh, so using *part* of tor, just the obfuscation part...
19:12:18 <sipa> you mean using obfuscation for our own connections, even non tor ones
19:12:21 <jonasschnelli> Since its a separated project and a seperate binary
19:12:32 <gmaxwell> wumpus: well the obfuscation parts of tor aren't parts of tor, technicaly. But yes.
19:12:35 <wumpus> this sounds like scope creep to me
19:12:51 <gmaxwell> jonasschnelli: have you trie using obfs4. I did previously, it just worked.
19:12:55 <gmaxwell> tried*
19:13:02 <sipa> i would say if we're worried about that, you should also just use tor already
19:13:04 <wumpus> gmaxwell: it's tor project code
19:13:13 <wumpus> maybe not part of the tor repository, I don't know
19:13:15 <phantomcircuit> i dont see any reason to do this, anybody who needs this can already configure it with the socks proxy support
19:13:24 <wumpus> yes
19:13:39 <jonasschnelli> okay... fair points. /topic
19:13:56 <gmaxwell> AFAIK, it just works.  It's kinda limited though because none of them resist traffic analysis and it's SUPER easy to identify bitcoin traffic with traffic analysis. :)
19:14:27 <phantomcircuit> gmaxwell, iirc they're all super easy to identify anyways
19:14:33 <gmaxwell> If there was some addon we needed to make more of them work, I suppose that would be cool, but I dunno what that would be. At least the original obfs proxy that I used before was just a socks proxy.
19:15:10 <gmaxwell> phantomcircuit: well I think the idea in tor is that there are private ones.
19:15:24 <jonasschnelli> I think core <-> core could use the propose p2p encryption (with NewHope), but for censoring, is was unsure if we should relay on Tor or on the underlaying independent obfuscation projects.
19:15:25 <wumpus> oh the obfs layer itself is also a socks proxy?
19:15:42 <gmaxwell> wumpus: yes
19:15:47 <wumpus> tor is socks proxies all the way down and nothing else isn't it :)
19:16:02 <sipa> pigeons at the bottom of the stack
19:16:09 <wumpus> anyhow, yes, then we can already use it
19:16:22 <wumpus> sipa: pigeons for transaction broadcasting
19:16:24 <phantomcircuit> gmaxwell, the only ones that work are the domain fronting ones, so presumably only the private ones actually work
19:18:03 <wumpus> well the non-private ones become known very soon
19:18:07 <gmaxwell> (hm the thing I used before wasn't obfs4 it was an earlier version, they all look like they implement proxies regardless)
19:18:15 <wumpus> no matter how good the obfuscation is, if it's public that you run one...
19:19:04 <gmaxwell> In any case, I think jonasschnelli's spirt is right. I just don't actually think we need to do anything more than have socks support.
19:19:21 <wumpus> yes
19:19:24 <jonasschnelli> Even better then. :)
19:19:35 <gmaxwell> (it's certantly better to do protocol obfscuation via external proxies than to try to bake anything in...)
19:19:39 <sipa> how does the proxy know which peers need to use the obfuscation?
19:19:42 <phantomcircuit> gmaxwell, meek is the only one that works in china, it's domain fronting with gce
19:19:52 <sipa> you can't just blanket obfuscate all connections
19:20:04 <sipa> as our normal peer discovery will find peers that don't support it
19:20:24 <achow101> sipa: I think this would only work for outgoing connections
19:20:25 <wumpus> sipa: you wouldn't want to use normal peer discovery in such cases
19:20:44 <sipa> achow101: yes, of course
19:20:45 <sipa> wumpus: right
19:21:24 <wumpus> something needs to de-obfuscate incoming connections too, but I suppose that works by forwarding a listening port?
19:21:39 <gmaxwell> I think perhaps the useful 'feature' that might come for this is being able to provide per-peer proxy configs to addnode/connect.
19:21:55 <wumpus> or does it really need SOCKS5 binding
19:22:04 <jonasschnelli> I think achow101 has a topic
19:22:25 <wumpus> (which we don't support, we only use the proxy for outgoing, SOCKS binding is really really obscure)
19:22:37 <gmaxwell> I don't think there is need for socks5 binding.
19:22:48 <wumpus> okay
19:22:55 <wumpus> per-peer proxies could be useful, yes
19:23:10 <cfields> gmaxwell: interesting. I believe that'd be trivial to add, other than the syntax handling
19:23:52 <sipa> "netmask X uses proxy Y"
19:23:56 <gmaxwell> wumpus: https://www.comparitech.com/blog/vpn-privacy/hide-openvpn-traffic-obfsproxy-on-windows-and-linux-ec2/  you can see how you can hide arbritary crap with obfsproxy.
19:24:07 <wumpus> gmaxwell: thanks
19:24:25 <gmaxwell> sipa: don't want to go too far or proxychains becomes the right tool (it's a multiproxy routing daemon)
19:24:32 <sipa> ha
19:24:47 <sipa> that sounds like an improvements over sidechains or treechains
19:24:48 <phantomcircuit> gmaxwell, proxychains is never the right tool >.>
19:24:50 <gmaxwell> (it can even nest proxies)
19:25:05 <gmaxwell> phantomcircuit: but how else will I hax you through 7 proxies?
19:25:34 <wumpus> fwiw ssh has built-in support for proxy chaining in the client
19:26:19 <wumpus> #topic hardware wallet support (achow101)
19:26:29 <achow101> So with PSBT we can kind of do hardware wallet things
19:26:34 <gmaxwell> in any case, being able to net-scope or node scope proxies is something I would have used before, e.g. "addnode my node in the office via my ssh -D socks proxy".
19:26:53 <achow101> I've been working on a tool that takes a psbt and does the hardware wallet things: https://github.com/achow101/HWI
19:27:06 <jonasschnelli> great work achow101!
19:27:20 <gmaxwell> achow101: cool.
19:27:28 <wumpus> woohoo!
19:27:31 <achow101> but to actually get hww support, we still need a way to get derivation paths for imported keys and such. and for those keys to be part of the keypool
19:27:59 <jonasschnelli> why not a xpub watch-only wallet support?
19:28:20 <achow101> I know sipa has the output descriptors stuff that would work for this, but I think that still quite a ways off
19:28:41 <sipa> i can prioritize it more, but it's unclear how to keep things compatible
19:29:00 <sipa> do we want the old keystore based system and the new descriptor based system side by side?
19:29:01 <jonasschnelli> importing keys seems meh-ish for hardware-wallet. IMO the ideal use case for BIP32 pub key derivation
19:29:11 <sipa> that wouldn't be too hard, i think
19:29:25 <gmaxwell> I don't see why we shouldn't deploy the very narrow thing we need to make all the common hardware wallets work, so long as it won't prevent us from using descriptor based logic in tuhe future.
19:29:26 <sipa> but it would be much nicer if we also get to convert old keystores to desceiptors
19:29:32 <jonasschnelli> Also, xpub watch-only do not need keypools
19:29:42 <gmaxwell> jonasschnelli: yes it does.
19:29:59 <jonasschnelli> I don't see why but happy to learn...
19:30:03 <sipa> it's the equivalent of their gap limit
19:30:07 <gmaxwell> It doesn't have private key material, but it needs _something_ to look ahead with pubkeys and watch for payments.
19:30:16 <achow101> I did #14021 for importing keypaths into the wallet with importmulti, but it isn't ideal
19:30:19 <gribble> https://github.com/bitcoin/bitcoin/issues/14021 | Import key origin data through importmulti by achow101 · Pull Request #14021 · bitcoin/bitcoin · GitHubAsset 1Asset 1
19:30:49 <achow101> it ... works, but kinda sucks as you have to import more keys as you use them. And they aren't in the keypool
19:30:49 <jonasschnelli> gmaxwell: yes. Right. Correction: no keypool written to disk, only xpub, then derive on load
19:31:03 <sipa> i fear for more combinations and special cases to deal with
19:31:31 <gmaxwell> jonasschnelli: well it doesn't really matter if we save it to disk or not. It's harmless to do so.
19:31:57 <jonasschnelli> Yes. Thats right.
19:32:06 <gmaxwell> achow101: obviously as a stopgap importing keys at least allows development and/or testing.
19:32:59 <gmaxwell> achow101: but I assume what you really want is a wallet whos master key reflects the third-party keychain.  I fear the mess of mixed wallets.
19:33:04 <jonasschnelli> achow101: do you have a plan to make hww interaction more hassle free, like including USBHID in core </joke>?
19:33:29 <achow101> jonasschnelli: the idea I had was to use the HWI scripts and call them from Core.
19:33:58 <achow101> they implement all of the usb stuff
19:34:03 <gmaxwell> I think that should be out of of scope. We should implement a simple fork and stdio interface (or similar) to talk to hardware specific drivers.
19:34:32 <jonasschnelli> could one of the "hardware-wallets" just be a hot keystore? Similar to SSH Agent?
19:34:39 <gmaxwell> right.
19:34:40 <sipa> have metadata in the wallet that says "for these outputs, attempt to sign through device driver X"
19:34:52 <sipa> which is just an executable that gets invoked and sent a psbt
19:34:53 <gmaxwell> Even one using SGX+TPM, for example.
19:35:25 <gmaxwell> the drivers could then also provide their own UI, if required.
19:35:38 <gmaxwell> E.g. to get a passphrase.
19:35:51 <gmaxwell> or remind you to plug in the device.
19:35:52 <achow101> yup. I plan on adding a UI to HWI once I get everything actually working
19:36:00 <jonasschnelli> Yes. Becaue of the UI, I initially though every vendor must provide its own script/binary...
19:36:11 <sipa> jonasschnelli: yes
19:36:19 <jonasschnelli> Because again, plugins then endup outside of the vendors control
19:36:25 <jonasschnelli> Leading to outdated software
19:36:37 <gmaxwell> I'm sure it would eventually be possible to have "generic" drivers that work for a family of devices, but I think the industry is too immature for that.
19:36:48 <jonasschnelli> Indeed
19:37:07 <gmaxwell> sipa: how would we handle, e.g. "this script is multisig, with device X and device Y" ?
19:37:18 <gmaxwell> (er driver x and driver y)
19:37:20 <sipa> gmaxwell: list two drivers
19:37:27 <gmaxwell> sounds good.
19:37:34 <jonasschnelli> I was hoping for a protocol/API where Core starts a process and passes all relevant data and the vendors plugin there with rich UI "drivers"
19:37:41 <sipa> gmaxwell: the drivers would be metadata to descriptor records
19:37:45 <achow101> gmaxwell: wouldn't that be "this script has two keys and key 1 uses driver X and key 2 uses driver Y"
19:37:55 <sipa> so they would apply to all outputs derived using the same chain(s)
19:38:11 <sipa> achow101: doesn't even need to say which key is which device
19:38:20 <sipa> just "try signing using X, try signing using ay"
19:38:24 <sipa> *Y
19:39:42 <achow101> anyways, the main point of bringing up this topic was that I wanted to ask whether we should implement xpub watch only wallets or just wait for sipa to finish output descriptor wallets
19:39:46 <gmaxwell> This kind of interface could easily be used for things other than HWI. For example, green address has a 2fa service, where the service will sign its part of a multisig with you, if you pass a 2fa.  This could be supported by a simple driver that sends the tx to a service and gets the sig back.
19:40:25 <gmaxwell> jonasschnelli: I don't think we should be providing the HWI specific UI, because if we provide the UI we would constrain innovation there.
19:41:00 <jonasschnelli> Not Core. But the vendor could have a driver with UI
19:41:12 <jonasschnelli> (and network interface and whatnot)
19:41:13 <gmaxwell> right. I agree.
19:42:01 <gmaxwell> The interface between core and the driver is basically just a PSBT plus arguments provided in the driver config.
19:42:14 <gmaxwell> achow101: well I think thats between you and sipa mostly
19:42:28 <gmaxwell> I hope we don't end up with even more combinitorial explosion in the wallet, however.
19:42:37 <jonasschnelli> Yes. But IMO that only one part. How to get pubkey&metdata into core (and eventually multisig stuff) is still unlcear to me
19:42:52 <gmaxwell> like having to handle a wallet with mixed old plain keys, hd keys, achowpubkey, and descriptors all at once.
19:42:55 <jonasschnelli> (in a non RPCish way)
19:42:59 <sipa> jonasschnelli: descriptors :)
19:43:18 <jonasschnelli> sipa: I mean plug-n-play. :)
19:43:20 <sipa> jonasschnelli: i'll try to create a writeup on how to integrate them in the wallet
19:43:26 <sipa> jonasschnelli: "import a descriptor"
19:43:41 <gmaxwell> the descriptor thing could eventually be  "create new wallet with descriptor"  "paste in descriptor" "confirm"..
19:43:43 <sipa> ah, you mean GUI
19:43:47 <sipa> i have no clue.
19:43:53 <jonasschnelli> You plugin a HWW, the Core detects it and tells you "do you wanna use XYZ".
19:43:58 <jonasschnelli> *then
19:44:16 <gmaxwell> doubt we're going to have any detection anytime soon...
19:44:32 <gmaxwell> as that would require shipping a pile of vendor specific detection and interface code.
19:44:48 <jonasschnelli> Yes. But if we form an API or similar, we should not only focus on the PSBT part,... also on the how do I create a watch-only wallet (eventually also multisig)
19:45:04 <jonasschnelli> But I guess the descriptors are the answer here
19:45:32 <gmaxwell> Create a new wallet from a descriptor, or import a descriptor into a wallet.
19:46:05 <gmaxwell> sipa: maybe you can work with achow 101 on a descriptor-lite implementation that would be forward compatible with the full thing later, and is enough to support the common hardware wallets?
19:46:34 <sipa> gmaxwell: descriptors are also in the codebase
19:46:56 <sipa> *already
19:47:12 <gmaxwell> well I meant basically "enough stuff to be able to create an xpub with path autofilling watching wallet"
19:47:13 <sipa> the hard part is integrating them in the wallet of course
19:47:32 <sipa> but that isn't harder or easier depending on what the descriptors support
19:48:07 <achow101> gmaxwell: the problem with that is the wallet format needs to change
19:48:49 <sipa> i'll try to think it through
19:51:28 <wumpus> any other topics?
19:51:49 <gmaxwell> jonasschnelli: wanted to talk about encryption!
19:52:04 <wumpus> #topic P2P encryption (jonasschnelli)
19:52:10 <jonasschnelli> Not really... :) but happy to do
19:52:28 <gmaxwell> heh, what just going to open that big PR and go on vacation? :P
19:52:46 <jonasschnelli> The question for me now is, is the PR to large (2000lines) and how and when to add NewHope (quantum resistant handshake)
19:53:35 <jonasschnelli> If it is to large, how to split it into PR that make partially sense on its own (could add the crypto stuff beforehand, but meh)
19:53:42 <gmaxwell> so the PR can probably be broken into three parts:  (1) prepatory refactors, (2) inclusion of new primitives, (3) the thing itself.
19:53:58 <jonasschnelli> Yes. Agree.
19:54:05 <jonasschnelli> But would we merge 2 without 3?
19:54:21 <jonasschnelli> Maybe 2 with concrete chances that 3 gets merged
19:54:28 <gmaxwell> Yes. Exactly.
19:54:45 <jonasschnelli> 1 will be very small
19:54:53 <gmaxwell> Well if we changed our mind we could always take it out. We've put other primitives in in advance before.
19:55:10 <gmaxwell> e.g. bip32 key derrivation went unused for years.
19:55:14 <sipa> BIP32 derivation was in the codebase for 3 years before being used :)
19:55:15 <sipa> jinx.
19:55:21 <jonasschnelli> Indeed. But its 2018 now. :)
19:55:24 <jonasschnelli> Okay. I'll do the split then.
19:55:49 <wumpus> granted, that was before people neurotically deleted dead code :-)
19:55:53 <gmaxwell> It's fine,  I think that chacha stuff is mostly a distraction from the review of that PR.  It needs to be reviewed but mostly for build integration, etc.
19:56:05 <gmaxwell> wumpus: or even not-dead-yet code!
19:56:10 <jonasschnelli> heh
19:56:11 <sipa> wumpus: it wasn't dead! it had tests!
19:56:14 <wumpus> gmaxwell: even preemptively
19:56:42 <cfields> jonasschnelli: taking a quick look at your PR, was the handshake spec modified to be sent first thing? Or am I misreading the code?
19:56:50 <jonasschnelli> Yes. I can also try to extend the existing ChaCha20 RNG to be used for the crypto part
19:56:53 <wumpus> jonasschnelli: anyhow if it simplifies review, please do split it up
19:56:58 <jonasschnelli> cfields: yes
19:57:11 <jonasschnelli> cfields: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#Handshake
19:57:20 <jonasschnelli> Great. Will split
19:57:27 <promag> nice
19:57:57 <gmaxwell> jonasschnelli: when you split make sure all the parts are visible. E.g. I'll want to look at (3) while reviewing (1) just in case some refactor seems like it makes no sense on its own. :)
19:58:03 <cfields> jonasschnelli: woohoo, thanks
19:58:42 <jonasschnelli> gmaxwell: Yes. Good point. Will do.
19:59:00 <jonasschnelli> I guess keeping the "overall" PR somewhere helps to see the goal.
19:59:14 <gmaxwell> sipa has done that in the past, e.g. with the segwit rebase.
19:59:30 <jonasschnelli> The unanswered question is when and how to add the NewHope handshake part
19:59:38 <wumpus> yes, indeed, though we probably want to change the one in high-priority then
19:59:53 <jonasschnelli> Yes. Lets remove it for now
19:59:56 <jonasschnelli> (ill do that)
20:00:07 <wumpus> ok
20:00:12 <wumpus> #endmeeting