19:00:22 <achow101> #startmeeting 
19:00:22 <core-meetingbot> Meeting started Fri Dec 16 19:00:22 2022 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:22 <core-meetingbot> Available commands: action commands idea info link nick
19:00:28 <achow101> #bitcoin -core-dev Wallet Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr furszy gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack josibake jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos Murch nehan NicolasDorier
19:00:28 <achow101> paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar S3RK sipa vasild
19:00:53 <kanzure> hi
19:01:03 <achow101> There are no pre-proposed wallet meeting topics. Does anyone have anything to discuss this week?
19:01:10 <darosior> Hi
19:01:21 <sipa> hi
19:01:35 <brunoerg> hi
19:02:00 <furszy> hi
19:02:02 <darosior> I guess i'm curious if people have thought about using descriptors for estimating the size of inputs
19:02:26 <darosior> Rather than doing a dry run of the signing logic every time
19:02:37 <achow101> That seems reasonable
19:02:41 <Murch1> Hi
19:02:44 <darosior> It would really simplify things moving forward with more advanced scripts
19:03:10 <achow101> would it just use the worst case size estimation?
19:03:11 <Murch1> Also the wallet should keep track of its UTXOs
19:03:13 <darosior> Context:  #26567 and #24149
19:03:14 <gribble> https://github.com/bitcoin/bitcoin/issues/26567 | Wallet: estimate the size of signed inputs using descriptors by darosior · Pull Request #26567 · bitcoin/bitcoin · GitHub
19:03:17 <gribble> https://github.com/bitcoin/bitcoin/issues/24149 | Signing support for Miniscript Descriptors by darosior · Pull Request #24149 · bitcoin/bitcoin · GitHub
19:03:32 <darosior> achow101: yes but eventually we should tweak that for Taproot
19:04:13 <sipa> One old idea was that descriptors could contain annotations about which keys/subtrees are available or not.
19:04:32 <sipa> Or might be available.
19:04:44 <sipa> The miniscript logic can do size estimation with that information, though there is no way to encode that in descriptors now.
19:04:55 <darosior> Yeah. Also rust-miniscript is experimenting with another approach: https://github.com/rust-bitcoin/rust-miniscript/pull/481
19:06:04 <darosior> I didn't look into it, but on the surface it sounds similar to having annotations within the descriptor directly.
19:08:34 <achow101> how would that information would get from the user to the size estimation?
19:08:44 <achow101> since it could change per transaction
19:09:03 <darosior> Yeah, a downside is that it would be static
19:09:21 <darosior> (A downside to hardcoding it within the descriptor)
19:10:18 <sipa> yeah it's more flexible if it can be done on a per-signature level, but that's a UX nightmare
19:10:34 <sipa> but there may be useful static information as well
19:11:18 <darosior> But i guess it's already an improvement in some potential common usecases with Taproot like have keyspend for day-to-day and a timelocked cold key for recovery. You can tell the wallet you use day-to-day to expect that all transactions you will be creating with it will be for the keyspend, and to not overestimate.
19:11:37 <sipa> e.g. you know that any signature that your bitcoin core wallet will be involved in, will have access to that wallet's private key
19:11:44 <sipa> if it's not in a hardware wallet
19:12:25 <achow101> it would definitely be useful to indicate that the keypath is never going to be used
19:12:31 <darosior> Hmm you could emulate that with partial descriptors? Only import the complete descriptor for the branches you may use on this wallet. And when estimating the size the wallet ignores unknown branches.
19:12:46 <sipa> opr even better: the key path is always is going to be used
19:13:17 <sipa> darosior: Yeah, you could, but I think that's only part of the picture, because within one script the same thing applies
19:13:34 <sipa> And there you very much may want to know everything, even informaton about execution branches you won't use.
19:14:19 <furszy> separate thing,about the overpaying topic: if we overpay, coin selection would increase its chances to create a change output, which is something that we usually try to avoid.
19:14:34 <darosior> sipa: wouldn't it be uncommon to have different paths within a single branch?
19:14:47 <darosior> And for pre-Taproot you don't care, since you always publish the whole script anyway
19:15:49 <sipa> But even pre-taproot your witness estimation may very much depend on which keys are available.
19:20:06 <achow101> can we use descriptors to remove the need for the dummy signer entirely? Even with size estimation, we still need the dummy signer for filling PSBTs
19:21:12 <sipa> I think post-partial-descriptors we can actually move the signing logic into descriptors, rather than the other way around.
19:21:17 <sipa> And anything that interacts with signing like size estimation too.
19:21:32 <darosior> Yes i was thinking of going in this direction too.
19:22:41 <achow101> that could be useful
19:24:38 <achow101> anything else to discuss?
19:24:39 <darosior> I need to leave unfortunately. Thank you all for the discussion, happy to see there is interest in this.
19:25:20 <sipa> Murch had a topic I think
19:25:52 <furszy> i have a one too.
19:26:20 <achow101> Murch1: what was your topic?
19:27:04 <Murch1> Ah
19:27:32 <Murch1> No, just a ceterum censeo
19:27:42 <Murch1> The Bitcoin Core wallet should really keep track of its UTXO pool instead of recalculating it from its list of transactions every time it needs it
19:27:53 <achow101> furszy: go ahead
19:29:00 <furszy> Murch1: agree, I actually have a card in my board to move into that direction too.
19:29:01 <furszy> so
19:29:19 <furszy> my topic arose here
19:29:21 <furszy> https://github.com/bitcoin/bitcoin/pull/26661#issuecomment-1353087751
19:29:31 <furszy> it's the "Second point" there
19:29:44 <furszy> and S3RK answer to it.
19:30:23 <furszy> if we agree, could "standardize" it and create a guideline for it.
19:31:30 <achow101> I've actually tended to avoid using exceptions since we don't have general exception handling
19:31:45 <achow101> I've only really used them in places where there was no other way to return an error
19:32:26 <achow101> IIRC an exception will kill the gui
19:32:46 <Murch1> furszy: Awesome!
19:33:15 <achow101> but having some guidelines would probably be useful
19:33:49 <Murch1> Err, just to be clear, that was directed at furszy's UTXO pool plans
19:33:56 <furszy> yeah, I know achow101. I ended up adding a try catch to the GUI create tx flow because of it.
19:34:41 <furszy> but.. it sounds that we are avoiding having a somewhat "good" library structure because our qt framework can handle exceptions in a generic manner
19:34:52 <furszy> *can't
19:35:34 <furszy> which isn't something related to the wallet's module. It's a GUI issue.
19:36:13 <achow101> sure, but we need to consider the effects of throwing exceptions on the rest of the software
19:36:45 <achow101> it would be worthwhile to write up some guidelines and fix qt simultaneously
19:37:02 <achow101> given that we already do throw exceptions in some places that can already be problematic for the gui
19:38:24 <furszy> by fixing at you mean the place that require to catch the exception?
19:38:49 <furszy> or by trying to find a way to catch them all at once
19:39:02 <achow101> trying to catch them all generically
19:39:05 <achow101> like we do for the rpc
19:40:41 <furszy> yeah ok, I briefly tried it in the past but IIRC, there wasn't a way to catch exceptions on slots generically (at least not a way that worked fine on that time..)
19:41:44 <furszy> thus why ended up coding https://github.com/bitcoin-core/gui/pull/666
19:43:50 <achow101> hmm, that's something to look into again
19:44:07 <achow101> just generally though, we should try to avoid things that will cause crashes
19:44:33 <furszy> well. another possibility is to move all the gui backend calls to be done on a generic worker that catches all the exceptions.
19:45:20 <furszy> that could also helps in terms of the gui freezing time
19:46:01 <furszy> sort of "dispatcher"
19:46:03 <achow101> yeah, there's definitely improvements that could be made there
19:46:28 <furszy> yep. Will see if can cook something up for it.
19:46:38 <achow101> my main point was that when we write guidelines for how errors should be emitted, we need to keep in mind how the rest of the project will handle those
19:46:55 <achow101> and what we could do to make those parts handle them better
19:47:19 <achow101> any other topics to discuss?
19:50:29 <achow101> #endmeeting