19:03:30 <achow101> #startmeeting
19:03:30 <lightningbot> Meeting started Fri Apr 10 19:03:30 2020 UTC.  The chair is achow101. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:30 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:03:38 <achow101> #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball ariard digi_james amiti fjahr
19:03:38 <achow101> jeremyrubin emilengler jonatack hebasto jb55
19:03:48 <jonatack> hi
19:03:50 <MarcoFalke> hi
19:04:13 <achow101> topics?
19:04:27 <MarcoFalke> mine
19:04:53 <achow101> I would also like to discuss watchonly descriptor wallet things
19:05:11 <achow101> #topic (short topic) Return last processed block in most wallet RPCs (MarcoFalke)
19:05:30 <MarcoFalke> In light of #17954 and generally that the wallet may fall behind on the best tip, the RPCs should return the last processed block
19:05:37 <gribble> https://github.com/bitcoin/bitcoin/issues/17954 | wallet: Remove calls to Chain::Lock methods by ryanofsky · Pull Request #17954 · bitcoin/bitcoin · GitHub
19:05:53 <MarcoFalke> This should be uncontroversial, but just making sure shouldn't hurt
19:06:25 <achow101> All the wallet RPCs?
19:06:45 <achow101> there are a bunch that don't return objects, and some that it probably doesn't matter
19:06:59 <MarcoFalke> At least the ones that report the balance or otherwise depend on the latest block processed
19:08:06 <jonatack> FWIW I've added fetching multiwallet balances client-side to -getinfo
19:08:18 <achow101> well getbalance returns just a number
19:08:34 <achow101> so you would have to make that an object, which would break a ton of things
19:08:48 <MarcoFalke> getbalances *smirk*
19:08:50 <jonatack> getbalance is superseded by getbalances anyway... could probably leave it be?
19:09:19 <achow101> yeah but who uses that?
19:10:23 <MarcoFalke> Maybe long term it makes sense to break the API
19:10:35 <MarcoFalke> getreceivedby* also returns only a plain number
19:11:00 <jonatack> if the rpc doesn't return an object i'm not sure it's worth breaking only for that
19:11:24 <jonatack> api v2 (tm)
19:12:13 <MarcoFalke> gettransaction, getbalances, getwalletinfo should be trivial to amend, since they are an object already
19:12:41 <achow101> yes
19:12:44 <MarcoFalke> jonatack: the API version is always v${VERSION_OF_BITCOIN_CORE}
19:14:21 <MarcoFalke> Anyway, that was the short topic. My issue is here: #18567
19:14:22 <gribble> https://github.com/bitcoin/bitcoin/issues/18567 | Return block hash with wallet calls · Issue #18567 · bitcoin/bitcoin · GitHub
19:14:29 <jonatack> MarcoFalke: right... bitcoin-cli -version
19:15:34 <achow101> would it be ok to just not have it returned for getbalance and getreceivedby?
19:16:13 <jonatack> and getunconfirmedbalance
19:16:34 <achow101> iirc those can include unconfirmed txs too so even at a given block hash, the balance can still change
19:16:59 <MarcoFalke> I suspect most clients will ignore the value anyway
19:17:08 <achow101> jonatack: I think that's the one rpc that this is completely useless for
19:17:19 <MarcoFalke> achow101: Same is true for getbalances (it can change between blocks as well)
19:17:20 <jonatack> yes
19:17:34 <achow101> MarcoFalke: sure, just trying not to cause things to explode
19:18:14 <achow101> anyways, I think we can all just comment on the issue
19:18:57 <achow101> #topic watchonly and descriptor wallets
19:19:23 <achow101> yesterday I wrote https://gist.github.com/achow101/94d889715afd49181f8efdca1f9faa25 which describes some of the motivations, use cases, and issues for descriptor wallets
19:20:15 <achow101> one point that has come up in discussions is watchonly, in particular handling multisigs
19:20:48 <sipa> where watchonly just means "you don't have all private keys in your wallet locally" ?
19:21:07 <achow101> I think so
19:21:39 <sipa> (i bring that up, because say in a HW wallet situation, just because the key is not in your wallet.dat, doesn't mean you don't have the ability to spend)
19:23:16 <achow101> ryanofsky suggested having some descriptors be marked as "watchonly" and others as not, independent of private keys
19:24:14 <achow101> "I wonder if in this kind of wallet, ability to mark individual descriptors watchonly or not, ability to display two balances, and ability to have RPCs that know which descriptors are intended for signing regardless of whether private keys are present might help with UX, and maybe let someone get away with just having have one bitcoin wallet instead of two and having to exporting/import between them."
19:24:40 <sipa> i'm not sure how i feel about that
19:25:19 <sipa> there really shouldn't be a descriptor in the first place for the stuff you don't care about (and turning it into a watchonly thing to separate it feels like a hack)
19:26:16 <sipa> i also don't have a better solution for how you'd go from "create single-key thing first, and then construct a multisig out of it"
19:27:14 <achow101> instagibbs also points out that if we allow descriptors with some but not all private keys, bumpfee and PSBT GUI break
19:27:26 <sipa> how so?
19:27:34 <achow101> so having a bool on the descriptors to indicate signing-ness or something would help with that
19:27:43 <achow101> but it does feel like we're regressing to legacy wallet territory
19:27:48 <sipa> i agree
19:28:06 <achow101> sipa: they switch on disable_private_keys. so if not disable_private_keys, sign, otherwise show/copy psbt
19:28:28 <achow101> but a multisig with some but not all privkeys is not disable_private_keys but will fail to sign
19:29:06 <sipa> wouldn't it be better to have separate RPCs for when you expect a fully-signed output vs PSBT output?
19:29:21 <sipa> and the latter would always work, and the former would just fail if not enough keys are present
19:30:06 <achow101> the other problem is that coin selection may choose to include a multisig utxo that you can't always sign for so sometimes sending will fail
19:30:14 <achow101> sipa: I think that's reasonable
19:30:38 <sipa> achow101: i think that's inherent to the no-mixed-wallet philosophy
19:31:07 <sipa> if you really want coin selection to choose directly-spendable coins over multisig ones, you should have two separate wallets
19:31:41 <sipa> the idea that you'd ever want those two mixed in the same wallet was a mistake i think, and it's what we're getting rid of?
19:31:44 <achow101> right. I don't think it's really a supported use case, but I'm not sure that we can/should block it
19:32:14 <sipa> i think to the extent possible the behavior of wallets and RPCs should not depend on whether you happen to have a private key locally
19:33:19 <achow101> right
19:33:56 <achow101> I think the separate RPCs and buttons idea mostly solves this. we can disable the signing one when explicitly there are no private keys
19:34:16 <achow101> those functionality may also be useful even when you do have all the private keys
19:34:32 <sipa> right
19:34:53 <sipa> maybe you want to get a PSBT out even when you have all private keys, e.g. for a final auditing on a secure machine before broadcasting or so
19:35:04 <sipa> (as they retain fee information)
19:35:22 <achow101> and we should stop changing behavior based on disable_private_keys
19:36:05 <sipa> yeah
19:36:10 <achow101> any other topics?
19:36:12 <sipa> at least for descriptor wallets...
19:37:55 <jonatack> sgtm (and good doc achow101, thanks)
19:39:12 <achow101> #endmeeting