19:00:31 <achow101> #startmeeting 
19:00:31 <core-meetingbot> Meeting started Fri Nov 19 19:00:31 2021 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:32 <core-meetingbot> Available commands: action commands idea info link nick
19:00:32 <meshcollider> Anyone around for a wallet meeting?
19:00:37 <provoostenator> hi
19:00:39 <meshcollider> Oh hi :)
19:00:54 <achow101> #bitcoin -core-dev Wallet Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
19:00:54 <achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:02 <achow101> meshcollider: it seems so
19:01:15 <sipa> hi
19:01:18 <provoostenator> Tl&dr achow101 has many PR's,  most need review :-)
19:01:41 <achow101> I have one pre-proposed meeting topic
19:01:57 <achow101> are there additional topics we should discuss today?
19:01:58 <fjahr> hi
19:02:14 <michaelfolkson> hi
19:02:42 <achow101> #topic how to estimate sizes for taproot inputs (achow101)
19:02:43 <core-meetingbot> topic: how to estimate sizes for taproot inputs (achow101)
19:02:59 <sipa> that's a hard one
19:03:04 <gene> hi
19:03:20 <sipa> one early idea from a while ago was that descriptors themselves can contain hints about which keys are available
19:03:39 <provoostenator> That would suggest different participants have different descriptors.
19:03:43 <sipa> indeed
19:04:11 <achow101> sipa: how does miniscript deal with this problem?
19:04:28 <sipa> the question is the same
19:04:42 <sipa> sanket1729_: ping
19:05:05 <provoostenator> Every wallet should be able to know what it can sign with?
19:05:15 <sipa> miniscript as logic for doing size estimation given a set of availability information for keys/preimages
19:05:23 <sipa> *has
19:05:25 <provoostenator> The more tricky part is if a wallet can sign in 2 ways, but another wallet can only sign in 1
19:05:42 <achow101> one part of this issue is that not all information is available to watch only wallets
19:06:12 <achow101> I have a branch that does do better estimation if private keys are available as it will end up estimating with the branch it will sign with
19:06:24 <provoostenator> Maybe WalletDescriptor can hold and serialize more info for this puprose?
19:06:43 <sipa> it's perhaps metadata that should live outside of descriptors
19:06:50 <fjahr> the underlying assumption of taproot is there is one cooperative path that should be the default, can't we assume the key spent then by default and only fall back to other hints when they are present?
19:07:25 <provoostenator> WalletDescriptor tracks the range, creation time.  Though it doesn't track if the descriptor is change or not. So I supporse this info could be elsewhere too
19:07:34 <achow101> fjahr: the problem is how do you know when to fallback
19:08:01 <achow101> in particular if the inputs are not being chosen by the user
19:09:01 <achow101> #23502 implements going with the largest case, but this means it will overpay if there is a script path
19:09:02 <gribble> https://github.com/bitcoin/bitcoin/issues/23502 | wallet: Avoid underpaying transaction fees when signing taproot spends by achow101 · Pull Request #23502 · bitcoin/bitcoin · GitHub
19:09:02 <sipa> and it's complicated further by the fact that in psbt-land, you may be choosing the transaction before knowing who can sign
19:09:06 <provoostenator> For now we could be lazy and just assume the keypath is used,  unless the send RPC specifies a script path?
19:09:30 <provoostenator> Similary a PSBT could specify the script path (needs a new field).
19:10:07 <provoostenator> (send RPC or any of the other sending and signing RPC's)
19:10:15 <sipa> for PSBT i think the problem decomposes into two separate ones
19:10:28 <achow101> provoostenator: how would that work if you don't know what inputs will be chosen?
19:11:25 <provoostenator> You mean for SIGHASH_SINGLE type transactions?
19:11:30 <sipa> one is the ability to tell walletcreatefundedstuffs which keys will be present at signing, to make it better estimate the signing cost
19:11:52 <provoostenator> Or do you mean as part of coin selection?
19:11:59 <sipa> coin selection
19:12:11 <provoostenator> We'd have to asses for each coin which paths are available, seems indeed painful.
19:12:15 <sipa> the other is making processpsbt only emit information about key/script paths whose signing cost falls within the intended feerate
19:12:46 <sipa> so if it's instructed to construct something which assuming a key path will be used, it needn't include information about script paths at all (of which there could be tons)
19:14:38 <achow101> sipa: the latter sounds doable, the first, not so much
19:14:43 <provoostenator> I guess every wallet UTXO could be associated with entries in the wallet database the represent the fee and required keys for the keypath and each scriptpath?
19:15:03 <provoostenator> (not the fee,  but the weight to spend)
19:15:35 <bitcoin-git> [bitcoin] hebasto opened pull request #23556: build, qt: Fix regression in rendering on macOS Big Sur (master...211119-macstyle) https://github.com/bitcoin/bitcoin/pull/23556
19:18:06 <provoostenator> Or perhaps things can be simplified, because within each descriptor the rules are the same.
19:18:35 <achow101> provoostenator: I don't think it would be necessary to associate anything with each utxo
19:19:00 <achow101> it's all with the descriptors, we need to be able to figure out what will be available at signing for each descriptor
19:19:31 <sanket1729_> hello
19:20:33 <sanket1729_> achow101: the information about potentially available singing keys can be in the psbt right?
19:20:44 <sipa> sanket1729_: that's too late
19:20:56 <sipa> you need this information when doing coin selection
19:20:57 <achow101> sanket1729_: yes, but the question is for constructing the PSBT in the first place
19:21:08 <achow101> when inputs are being chosen
19:21:38 <sanket1729_> yeah, why can you not have that while inputs are chosen? You just choose the change output last?
19:22:00 <achow101> one possibility is to add an option to all the fund/send rpcs that has a list of key (origins?) of the keys that will be available at signing?
19:22:41 <provoostenator> I just realized the availability is not static.
19:22:53 <provoostenator> So yeah, providing it at coin selection time seems the only way.
19:23:32 <provoostenator> E.g. in a 3-of-3 setup with scriptpath(s) for 2-of-3 fallback,  the wallet can't know if you have 2 or 3 signers available.
19:23:38 <sipa> sanket1729_: there is no algorithmic difficulty here
19:23:42 <sipa> more a logistical
19:23:55 <sipa> how does the right information get to be available to the right things
19:24:28 <sipa> e.g. do descriptors need metadata about all keys, whether they will or won't be oresent
19:24:30 <provoostenator> Maybe by default we assume everything is available (keypath), and then there's an option to provide fingerprints.
19:24:33 <sipa> what if that information changes
19:24:39 <provoostenator> And/or explictly point to script paths
19:24:54 <achow101> sipa: one thing that would be useful is for a way to say in a descriptor that the internal key is bogus
19:25:31 <provoostenator> tr(null)
19:25:47 <sipa> achow101: we definitely need that, but i think that's somewhat orthogonal
19:26:03 <sipa> there should just be a convenient way of constructing script-only tr descriptors
19:27:31 <sipa> the reason why i didn't include that already is because there are many ways of doing that
19:27:54 <sipa> including ones that are more private
19:28:02 <sipa> but more complex
19:28:03 <achow101> sipa: it's kind of relevant as whether or not the script path is taken has a significant impact on the estimated size
19:28:43 <sipa> right
19:28:50 <sanket1729_> > sipa: one is the ability to tell walletcreatefundedstuffs which keys will be present at signing, to make it better estimate the signing cost. Is this hard to do logistically? Can we not use psbtv2 here?
19:29:17 <sipa> sanket1729_: pabtv2 is just a format, the information has to come from somewhere
19:29:33 <sanket1729_> But the change output does not need to fixed
19:29:46 <achow101> sanket1729_: there is no guarantee that a change output exists
19:29:55 <sipa> nor that it is recognizable
19:30:09 <achow101> and coin selection now operates on effective values, so being able to calculate the fee for each input is necessary
19:30:14 <sipa> or that it is acceptable for particular signers to modify it
19:31:21 <bitcoin-git> [bitcoin] whitslack opened pull request #23557: configure.ac: remove Bashism (master...fix-configure-bashism) https://github.com/bitcoin/bitcoin/pull/23557
19:32:58 <provoostenator> ^ Antiba strikes again!
19:33:04 <achow101> anyways, it seems like the only real solution is to add options that allow the user to specify what will be available
19:33:51 <sipa> yeah...
19:34:05 <provoostenator> In any case that's a good start.
19:34:29 <achow101> what if no availability information is provided?
19:34:40 <achow101> assume worst case? or assume key path?
19:34:45 <provoostenator> So the current PR's either underestimate or overestimate the fee? That seems pretty bad.
19:34:57 <provoostenator> I would assume keypath
19:35:18 <achow101> provoostenator: currently we underestimate, #23502 changes to always overestimate so at least we never underpay
19:35:20 <gribble> https://github.com/bitcoin/bitcoin/issues/23502 | wallet: Avoid underpaying transaction fees when signing taproot spends by achow101 · Pull Request #23502 · bitcoin/bitcoin · GitHub
19:35:23 <provoostenator> And warn if you then try to sign scriptpath
19:35:56 <provoostenator> Maybe we shouldn't even automatically pick a scriptpath for signing.
19:36:11 <sipa> the problem is that signing isn't a single step
19:36:13 <provoostenator> At least not until we figure out this fee dilemma.
19:36:37 <provoostenator> Right, there's a dummy signer to get the fee estimate, and then the real signer?
19:36:43 <sipa> it's not an issue as long as all tr supports in non-aggregated keys and single-key pk scripts
19:37:06 <sipa> but just because you don't have the keypath private key, does not mean nobody had
19:38:15 <sipa> meshcollider: btw, i'm reviewing the error location PR, but got sidetracked again
19:38:16 <provoostenator> I think in a wallet without private keys, you can assume _someone_ has the keypath private key.
19:38:33 <provoostenator> In  a wallet with private keys, but where you don't have the internal key, it's tricker.
19:38:48 <meshcollider> sipa: thanks! No worries :)
19:38:57 <provoostenator> But from the above discussion I gather we should still pick the keypath and just assuem someone else signs it. Unless the user says otherwise
19:39:01 <achow101> provoostenator: in a wallet with private keys, we can know there is a private key and choose the path that uses it
19:39:08 <achow101> (assuming pk scripts only)
19:39:24 <provoostenator> But that may not be desireable, because that path might be a fallback option.
19:40:22 <achow101> but always assuming keypath might mean we underpay the fee accidentally
19:40:24 <provoostenator> (I guess the example here would be a 1-of-2 threshold signature with single key fallbacks)
19:40:42 <sipa> another possibility is not caring too much about it, because unless you have giant scripts/scriptsizes, it won't make a giant different to the vsize
19:40:50 <provoostenator> We would have to assume it for both coin selection and signing.
19:41:15 <sipa> also assuming a functioning block space market, which may be a dream...
19:41:25 <achow101> sipa: the jump from keypath to any script path is pretty significant
19:41:53 <provoostenator> And spending the wrong fee is not good for privacy.
19:42:23 <achow101> (a basic script path is at least 1.5 times larger than keypath)
19:43:06 <provoostenator> E.g. a 1.5 sat/byte transaction would strongly suggest there was a keypath.
19:44:03 <sipa> provoostenator: i was assuming a functioning block space market; i agree that dealing with minrelay situation is harder
19:45:16 <achow101> any other topics to discuss?
19:46:20 <achow101> #endmeeting