19:06:29 <meshcollider> #startmeeting
19:06:29 <lightningbot> Meeting started Fri Nov 30 19:06:29 2018 UTC.  The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:29 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:06:30 <sipa> go ahead :)
19:06:40 <kanzure> hi.
19:06:43 <provoostenator> hi
19:06:50 <promag> hi, again
19:07:12 <meshcollider> #topic wallet specific configuration
19:08:00 <provoostenator> (to resume from above) some of these settings are booleans which can be built on top of the flag setter/getter added in #13756
19:08:05 <gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: "avoid_reuse" wallet flag for improved privacy by kallewoof · Pull Request #13756 · bitcoin/bitcoin · GitHub
19:09:19 <provoostenator> Other things are strings, so would require a little more work, a new RPC method similar to setwalletflag (or we rename it).
19:10:30 <meshcollider> jnewbery's issue is #13044 right
19:10:32 <gribble> https://github.com/bitcoin/bitcoin/issues/13044 | [RFC] Long term plan for wallet command-line args · Issue #13044 · bitcoin/bitcoin · GitHub
19:10:33 <gmaxwell> Sometimes things that are booleans eventually get more settings, avoid reuse, case in point, is likely to evolve into a treshold of how much extra you're willing to pay to avoid reuse.
19:11:10 <provoostenator> Which suggests we should rename setwalletflag to something more generic like setwalletconfig?
19:13:03 <provoostenator> sipa: does your wallet overhaul ambition include completely changing the way data is stored in it, or can we just add this type of setting data without getting in the way of the descriptor refactor?
19:14:00 <meshcollider> I believe the plan is just to slowly migrate the actual keys and scripts at the moment, no change to the rest
19:15:09 <meshcollider> Perhaps this config change should be taken out into its own PR though if it's going to become more independent
19:16:02 <provoostenator> Or we change it later, but before the next release.
19:16:11 <promag> could start to add support for per-wallet options (which take the global option value) - which affects RPC and UI - then discuss how to load/store them?
19:16:13 <provoostenator> Though that's always scary
19:16:34 <sipa> provoostenator: i have no intention of touching anything but keys/scripts
19:17:16 <provoostenator> promag: storing the settings in the wallet should be great for GUI development, way less tedious than dealing with gArgs
19:17:45 <promag> dumb question: do old versions destroy unknown records in wallets?
19:17:46 <provoostenator> We just need a generic way to store a map of settings.
19:18:03 <provoostenator> Not sure, but you can always bump the wallet version to prevent that AFAIK.
19:19:13 <sipa> promag: no
19:19:36 <provoostenator> How old wallets deal with new payloads is the kind of thing we can test with #12134 (shameless plug).
19:19:40 <gribble> https://github.com/bitcoin/bitcoin/issues/12134 | Build previous releases and run functional tests by Sjors · Pull Request #12134 · bitcoin/bitcoin · GitHub
19:19:48 <provoostenator> *old clients
19:21:08 <provoostenator> I might at some point volunteer to write this generic settings stuff, but feel free to beat me to it.
19:21:44 <meshcollider> Sounds good
19:21:53 <meshcollider> Ok next topic then?
19:21:58 <provoostenator> But I think it's the cleanest way to add information about hardware wallets to specific wallets.
19:22:45 <achow101> i think jonasschnelli added a bit field of features supported with the privkey disabled stuff, so we could have the per wallet options already
19:23:24 <provoostenator> achow101 correct, and 13756 ^ adds avoid_reuse as another flag, but flags can only be boolean.
19:24:01 <provoostenator> In addition that PR adds getters and setters for these flags.
19:24:27 <promag> #13756
19:24:30 <gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: "avoid_reuse" wallet flag for improved privacy by kallewoof · Pull Request #13756 · bitcoin/bitcoin · GitHub
19:25:01 <provoostenator> (next topic works for me)
19:25:18 <achow101> related to that, we should make the address type and change type a wallet specific setting
19:25:32 <achow101> but that doesn't work well as a boolean, so it would need it's own field
19:25:47 <provoostenator> achow101: indeed, plus this whole list: #13044
19:25:48 <gribble> https://github.com/bitcoin/bitcoin/issues/13044 | [RFC] Long term plan for wallet command-line args · Issue #13044 · bitcoin/bitcoin · GitHub
19:26:09 <meshcollider> Yeah John's issue covers that
19:26:11 <provoostenator> Yes, now you're repeating the entire thing above :-)
19:26:21 <achow101> ah, there's an issue tracking this
19:26:23 <achow101> cool
19:26:23 <meshcollider> Ok let's move on
19:26:25 <meshcollider> #topic rw_config progress (provoostenator)
19:26:55 <provoostenator> #11082
19:26:58 <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
19:27:23 <provoostenator> This is great. I build some QT stuff on top of it, which makes me reluctant to touch any settings related UI until that's merged.
19:28:56 <provoostenator> Maybe more people can review it before hopefully a final rebase?
19:30:29 <provoostenator> In ancient version of this PR luke-jr added a whole bunch of settings from Knots along with this. That was too much at once, but the idea of making it easier to add more settings to the GUI is certainly appealing.
19:30:49 <promag> provoostenator: probably rebasing first is better?
19:31:05 <promag> provoostenator: but I'll take a look too
19:31:08 <provoostenator> Well, he already did that two weeks ago.
19:31:29 <meshcollider> This isn't wallet specific, but I'll take a look too yep
19:31:42 <achow101> topic suggestion: external signers api (provoostenator's idea mentioned earlier)
19:32:02 <provoostenator> True, though I'd say 99% of GUI users are using it as a wallet, and it's blocking wallet stuff.
19:33:04 <meshcollider> Perhaps we can add it to high priority once Luke's getbalance stuff is gone :)
19:33:25 <meshcollider> #topic externals signers API
19:33:34 <provoostenator> I wrote a document to describe what hardware wallet signing RPC calls could look like, what the hardware script should do (mostly achow101's HWI already does), and how that all ties together: https://github.com/Sjors/bitcoin/blob/2018/11/rpc-signer/doc/external-signer.md
19:33:52 <provoostenator> And when I say "hardware" I mean any program that can sign things.
19:34:23 <provoostenator> So could also be a remote multisig service that sends you a bunch of text messages with a cool down period. But local hardware is the easiest.
19:34:39 <achow101> if we were to include hwi now, the commands used would have to have a bunch of flags
19:35:21 <provoostenator> The way I see it we wouldn't include HWI in Core, at least not yet. The user would be expected to download HWI or alternative on their own.
19:35:41 <achow101> so some genralized api using descriptors would be useful, especially for having other external signers other than hwi. so someone could write their own program for their hardware device drivers and not have to repliacte all of the same options
19:36:28 <achow101> the only problem i see is that a descriptor requires knowledge of keys, but you may not have knowledge of keys to begin with to get the descriptor
19:36:48 <provoostenator> I introduced the concept of a pseudo-descriptor (see "Signer API") to get around that.
19:37:19 <provoostenator> E.g. wpkh(00000000/84h/1h/0h/0/*) means "gimme all the receive keys"
19:37:42 <provoostenator> The answer to which would be an actual descriptor, or an array of descriptors if the final derivation is hardened.
19:38:07 <sipa> why is it not an actual descriptor?
19:38:13 <sipa> (only half following)
19:38:20 <provoostenator> The flow is as follows:
19:38:21 <achow101> sipa: you don't have the keys yet, you are trying to get them
19:38:34 <provoostenator> Wallet asks driver for a list of devices, and their master fingerprin
19:38:59 <provoostenator> Wallet asks driver for keys given a master fingerprint and derivation hints
19:39:00 <sipa> the wallet should just ask the driver for a descriptor for its receive addresses?
19:39:03 <meshcollider> So basically it is a descriptor with a placeholder key which gets replaced?
19:39:07 <sipa> why does that need to look like a descriptor
19:39:39 <provoostenator> It also needs to ask for change addresses.
19:39:46 <provoostenator> What it needs depends on the wallet.
19:39:51 <meshcollider> Is it just to specify the format?
19:39:53 <provoostenator> So a descriptor keeps it generic.
19:40:15 <sipa> i think my question is: should it treat HW devices/drivers that deal with arbitrary key trees, and the wallet decides which keys to use for what
19:40:25 <sipa> or is it the driver that decides which keys to use for what
19:40:31 <provoostenator> I was thinking both.
19:40:45 <sipa> that seems like the worst of both worlds :)
19:40:46 <provoostenator> By default we ask for a standard BIP44/49/84 path
19:41:05 <provoostenator> But the driver can tell us, via enumerate (the first thing we call), that the device insists on a different structure.
19:41:20 <provoostenator> But I agree this needs more thought.
19:41:49 <sipa> yeah, ok, you can see it as a 'hint' from the wallet "hey this key path would seem nice to me, agree?"
19:41:54 <provoostenator> We could also, like sipa suggests, just require that the driver tells us what the receive and change trees are.
19:42:35 <provoostenator> But I prefer the hint option, because for example the user may have already set changetype and receivetype for a reason.
19:42:52 <provoostenator> Whereas the driver might default to something lame backwards compatible like p2sh wrapped segwit.
19:43:17 <sipa> that makes sense
19:43:54 <provoostenator> Also, I wonder if the concept of "change chain" and "receive chain" is abstract enough to allow for more fancy things. For multisig it should be.
19:44:49 <provoostenator> We probably need some way for the driver to communicate capabilities.
19:45:37 <provoostenator> Which again could look like descriptors for lack anything else, e.g. to indicate which address types and whether multisig is supported.
19:45:41 <achow101> add a new command "getfeatures"?
19:46:02 <provoostenator> achow101: or just spit it out as part of the enumerate command, but yes.
19:49:12 <meshcollider> Alright, any other topics?
19:50:05 <provoostenator> sipa asked for volunteers write tests for #14565
19:50:08 <gribble> https://github.com/bitcoin/bitcoin/issues/14565 | Overhaul importmulti logic by sipa · Pull Request #14565 · bitcoin/bitcoin · GitHub
19:50:53 <provoostenator> (just repeating that here for the log)
19:51:34 <provoostenator> There's about a dozen PR's built on top, including my (pre)WIP RPC stuff.
19:52:24 <meshcollider> Yeah I have one built on that too
19:52:39 <meshcollider> Maybe I'll write the tests to speed things up
19:52:49 <meshcollider> Alright I guess that's it then :)
19:52:53 <meshcollider> #endmeeting