19:03:30 #startmeeting 19:03:30 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:03:38 #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 jeremyrubin emilengler jonatack hebasto jb55 19:03:48 hi 19:03:50 hi 19:04:13 topics? 19:04:27 mine 19:04:53 I would also like to discuss watchonly descriptor wallet things 19:05:11 #topic (short topic) Return last processed block in most wallet RPCs (MarcoFalke) 19:05:30 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 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 This should be uncontroversial, but just making sure shouldn't hurt 19:06:25 All the wallet RPCs? 19:06:45 there are a bunch that don't return objects, and some that it probably doesn't matter 19:06:59 At least the ones that report the balance or otherwise depend on the latest block processed 19:08:06 FWIW I've added fetching multiwallet balances client-side to -getinfo 19:08:18 well getbalance returns just a number 19:08:34 so you would have to make that an object, which would break a ton of things 19:08:48 getbalances *smirk* 19:08:50 getbalance is superseded by getbalances anyway... could probably leave it be? 19:09:19 yeah but who uses that? 19:10:23 Maybe long term it makes sense to break the API 19:10:35 getreceivedby* also returns only a plain number 19:11:00 if the rpc doesn't return an object i'm not sure it's worth breaking only for that 19:11:24 api v2 (tm) 19:12:13 gettransaction, getbalances, getwalletinfo should be trivial to amend, since they are an object already 19:12:41 yes 19:12:44 jonatack: the API version is always v${VERSION_OF_BITCOIN_CORE} 19:14:21 Anyway, that was the short topic. My issue is here: #18567 19:14:22 https://github.com/bitcoin/bitcoin/issues/18567 | Return block hash with wallet calls · Issue #18567 · bitcoin/bitcoin · GitHub 19:14:29 MarcoFalke: right... bitcoin-cli -version 19:15:34 would it be ok to just not have it returned for getbalance and getreceivedby? 19:16:13 and getunconfirmedbalance 19:16:34 iirc those can include unconfirmed txs too so even at a given block hash, the balance can still change 19:16:59 I suspect most clients will ignore the value anyway 19:17:08 jonatack: I think that's the one rpc that this is completely useless for 19:17:19 achow101: Same is true for getbalances (it can change between blocks as well) 19:17:20 yes 19:17:34 MarcoFalke: sure, just trying not to cause things to explode 19:18:14 anyways, I think we can all just comment on the issue 19:18:57 #topic watchonly and descriptor wallets 19:19:23 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 one point that has come up in discussions is watchonly, in particular handling multisigs 19:20:48 where watchonly just means "you don't have all private keys in your wallet locally" ? 19:21:07 I think so 19:21:39 (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 ryanofsky suggested having some descriptors be marked as "watchonly" and others as not, independent of private keys 19:24:14 "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 i'm not sure how i feel about that 19:25:19 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 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 instagibbs also points out that if we allow descriptors with some but not all private keys, bumpfee and PSBT GUI break 19:27:26 how so? 19:27:34 so having a bool on the descriptors to indicate signing-ness or something would help with that 19:27:43 but it does feel like we're regressing to legacy wallet territory 19:27:48 i agree 19:28:06 sipa: they switch on disable_private_keys. so if not disable_private_keys, sign, otherwise show/copy psbt 19:28:28 but a multisig with some but not all privkeys is not disable_private_keys but will fail to sign 19:29:06 wouldn't it be better to have separate RPCs for when you expect a fully-signed output vs PSBT output? 19:29:21 and the latter would always work, and the former would just fail if not enough keys are present 19:30:06 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 sipa: I think that's reasonable 19:30:38 achow101: i think that's inherent to the no-mixed-wallet philosophy 19:31:07 if you really want coin selection to choose directly-spendable coins over multisig ones, you should have two separate wallets 19:31:41 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 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 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 right 19:33:56 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 those functionality may also be useful even when you do have all the private keys 19:34:32 right 19:34:53 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 (as they retain fee information) 19:35:22 and we should stop changing behavior based on disable_private_keys 19:36:05 yeah 19:36:10 any other topics? 19:36:12 at least for descriptor wallets... 19:37:55 sgtm (and good doc achow101, thanks) 19:39:12 #endmeeting