19:10:57 <achow101> #startmeeting 
19:10:57 <core-meetingbot> Meeting started Fri Mar 12 19:10:57 2021 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:10:58 <core-meetingbot> Available commands: action commands idea info link nick
19:11:34 <achow101> #bitcoin -core-dev Wallet Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag
19:11:34 <achow101> provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:11:47 <achow101> any topics?
19:12:41 <sipa> oh hi
19:13:13 <achow101> so we have taproot descriptors now, right?
19:13:30 <sipa> kind of
19:13:47 <sipa> maybe it's worth a discussion what they should look like (including some features the current PR doesn't have)
19:13:53 <achow101> well at least single key things
19:14:04 <sipa> but perhaps that should include sanket1729, andytoshi, and other people working with descriptors
19:14:22 <achow101> yes, that seems like a discussion that involves other people who are not here
19:14:44 <achow101> perhaps we should talk about the addresstype stuff?
19:14:51 <sipa> ok!
19:15:01 <achow101> #topic addresstypes for taproot (and future)
19:15:02 <core-meetingbot> topic: addresstypes for taproot (and future)
19:15:32 <meshcollider> hi (sorry I'm late)
19:15:49 <achow101> There was a discussion about what we should do for address types for taproot in #20861: https://github.com/bitcoin/bitcoin/pull/20861#discussion_r592054623
19:15:52 <gribble> https://github.com/bitcoin/bitcoin/issues/20861 | BIP 350: Implement Bech32m and use it for v1+ segwit addresses by sipa · Pull Request #20861 · bitcoin/bitcoin · GitHub
19:16:05 <achow101> which seems like something we should discuss in this meeting
19:16:12 <sipa> i think the discussion is actually kind of out of scope for 20861 itself
19:16:18 <achow101> agree
19:16:59 <achow101> from that discussion, sipa is in favor of adding bech32m, while I think we should move to naming the types by what they do
19:17:15 <sipa> it's more relevant for #21365, and probably even more when we'd think about supporting it by default
19:17:17 <gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa · Pull Request #21365 · bitcoin/bitcoin · GitHub
19:17:53 <achow101> yes
19:18:10 <sipa> achow101: imagine a successor to taproot appears, does it make sense for a wallet user to select on a *per-payment-request* basis between wit v1 and wit v2?
19:18:39 <sipa> i guess it may be a bit of a expert vs beginner usage question
19:18:53 <achow101> sipa: I would expect no
19:19:08 <sipa> because exposing it that way kind of forces people to know and care about the distinction
19:19:29 <sipa> it's of course a far future question, and maybe the debate is just silly to have at this point
19:19:30 <achow101> but I think that it makes sense to expect a user to want to stay with v1 until v2 is more mature
19:20:13 <sipa> absolutely, but i'd expect the wallet to expose a way to select between base58/bech32/bech32m addresses perhaps... and until some time bech32m wallets would just not without manual intervention have any witv2 descriptors
19:21:21 <sipa> same with taproot, you just wouldn't be able to get a taproot descriptor in your wallet without manual intervention until it's well activated, and then it'd get integrated in wallet creation/upgrade UIs
19:21:36 <Murch> mh. so, is this only about what name the v1 output addresses should be filed under in Bitcoin Cor}?
19:22:18 <sipa> the name, but also what things it should distinguish between
19:22:21 <Murch> I'd rather call them P2TR in that case than "bech32m" since the latter is just how the address is formatted
19:22:50 <Murch> Or would you expect that not to be distinct from v2+
19:22:52 <Murch> ?
19:22:53 <sipa> Murch: my point is that on a per address basis, what you care is *what does the sender support*
19:23:04 <achow101> sipa: so then creation would have an option to create only v1 if that is what the user wanted? and then we need some way to add a v2 later that isn't super difficult to use (like importdescriptors kind of is)
19:23:27 <achow101> but I guess a general upgrade path that adds descriptors for each witness version will be required anyways
19:23:28 <Murch> sipa: Yes, so it's important that you can generate an older type of address
19:23:29 <sipa> and if the sender supports bech32m, it should be up to your wallet (and its configuration) to decide whether to give a witv1 or witv2 address if a bech32m one is requested
19:23:57 <achow101> Murch: bech32m (should) apply to all future witness versions too
19:24:05 <Murch> achow101: yes
19:24:15 <Murch> sipa: But the receiver picks the address, not the sender
19:24:37 <Murch> so it's not like the sender will say "bech32m please" without the receiver intepreting that
19:24:38 <sipa> Murch: yes, but the receiver shouldn't care about witv1 vs witv2 on a per-receive-address basis
19:25:03 <sipa> if his wallet supports fancy witv2, he'd give a witv2
19:25:07 <sipa> if not, a witv1
19:25:13 <Murch> how do you know that, when we don't know what native segwit v2 will encompass? ;)
19:25:49 <sipa> my point is that non-expert senders and receivers shouldn't need to care about witness versions or taproot or whatever or not
19:25:59 <sipa> they only care about what address format they both understand
19:26:11 <Murch> And I disagree! ;)
19:26:58 <sipa> to be clear: i'm not saying there shouldn't be a way to decide between witv1 and witv2
19:27:07 <Murch> The sender is more concerned about compatibility, but the recipient may be more interested in picking the script among the compatible options
19:27:11 <sipa> but that's part of the wallet definition, not something you want per address basis
19:27:34 <Murch> oh, I guess that might have been a misunderstanding on my end
19:27:48 <sipa> if you have a witv2 wallet, it'll give a witv2 address if you request bech32m
19:27:58 <sipa> if you have a witv1 wallet, it'll give a witv1 address if you request bech32m
19:28:18 <Murch> but given what we saw with bech32 v0 vs v1+, do you actually expect wallets to be compatible with new segwit versions out of the box?
19:28:31 <sipa> i think what we decide here may influence that :)
19:28:46 <achow101> I hope that they will be now since the issue was brought to light
19:29:20 <sipa> if people start thinking about bc1p addresses as "taproot addresses", perhaps that'll not work as well as when people just think about them as bech32m addresses (that can do any future thing)
19:29:32 <Murch> okay, just to clarify, we're talking about the parameter that one would use to pick the address type when generating a new address, right?
19:29:39 <achow101> yes
19:30:02 <sipa> Murch: really the question is: how do we internally classify the descriptors
19:30:15 <Murch> right
19:30:24 <achow101> thinking on this further, I don't really have a strong argument for the per-version address type in a descriptor wallet
19:30:55 <sipa> and if that category is "BECH32M", that'd presumably mean in a witv1/witv2 world, you couldn't have a wallet that has a way to produce both witv1 and witv2 payment addresses
19:30:56 <Murch> So, your proposition is to not distinguish them at the address generation request level so that people may be forced to properly implement bech32m support?
19:30:58 <achow101> however in HWI, it makes sense since we are handling keys there, not descriptors. And the per-version address type makes sense in the keys model (like the legacy wallet and hardware wallets)
19:32:20 <achow101> Murch: not necessarily force but rather that there isn't any reason to choose between v1 or v2 at a per-payment-request level
19:32:21 <sipa> achow101: i guess what i want to avoid is that all wallets by default end up having 14 descriptors loaded just because they need to support p2pkh, and p2wpkh, and p2sh-p2wpkh, and p2tr, and p2witv2, and p2witv3, ...
19:32:35 <Murch> achow101: Yeah, that's a good point. Or when you try to recover an old wallet, you want to be able to specify the version to not necessarily be the latest
19:32:45 <achow101> sipa: 14 descriptors is better than 2000 keys :p
19:33:00 <sipa> achow101: what about 14 descriptors each pre-expanded to 1000 keys?
19:33:17 <achow101> that could be a problem
19:33:44 <jonatack> was afk...so IIUC the getnewaddress "address_type" options would be: "legacy", "p2sh-segwit", "bech32", "bech32m"
19:33:54 <sipa> vaguely relatedly, and maybe less long-term: i think we can merge the legacy and p2sh-segwit output types
19:34:06 <sipa> every sender supports both p2pkh and p2sh
19:34:13 <achow101> sipa: they still make sense for legacy wallets
19:34:21 <achow101> maybe we can merge them when those go away
19:35:07 <sipa> achow101: i guess that would imply for a legacy wallet that its future payment address cannot be p2pkh anymore
19:35:13 <Murch> I still feel like I don't fully understand the problem. We want to make sure that people implement bech32m forward-compatibly, so that they actually can send to all upcoming versions of native segwit outputs, but what is gained by artificially blurring the lines between them rather than having decent wallet logic to do either?
19:35:48 <achow101> sipa: there are some p2pkh holdouts
19:35:54 <Murch> heh.
19:36:04 <sipa> Murch: to me it's the other way around
19:36:05 <Murch> 47% of all outputs are still p2pkh.
19:36:38 <sipa> we've artifically introduced a distinction in the address-request logic that should be wallet logic, between p2sh-segwit and other p2sh
19:36:58 <sipa> and i hope we don't continue that
19:37:04 <Murch> I see
19:37:17 <achow101> sipa: I think that distinction is necessary in a wallet that operates on keys rather than descriptors
19:37:30 <Murch> But I guess my issue is that there are at least two different ways requests for addresses come to pass
19:38:01 <sipa> achow101: i think only for political reasons that we wanted to give people the option of not using segwit without explicitly opting in
19:38:07 <Murch> One: Sender tells receiver what address formats they speak, and receiver picks their preferred address from that set
19:38:20 <sipa> not an indefensible choice, but kind of a pity in retrospect
19:38:26 <Murch> two: Receiver wants to generate one specific type of address
19:39:12 <sipa> why would they want that?
19:39:20 <sipa> (on a per address basis)
19:39:21 <achow101> sipa: I disagree. For segwit and taproot, when HWI gets a key, it doesn't know which addresstype to turn the key into
19:39:47 <sipa> achow101: sure, that needs metadata
19:39:54 <sipa> could be a descriptor itself
19:40:02 <Murch> E.g. to recover a Taproot descriptor after everyone has moved on to a segwit v2 default
19:40:19 <sipa> yes, use the descriptor if you need to be explicit
19:40:34 <Murch> Oh, so there is another way to be specific.
19:40:50 <sipa> i think you're both talking about something that's a very different layer
19:41:01 <Murch> It does feel like that ^^
19:41:04 <sipa> this is purely about the question "what does a wallet configuration look like?"
19:41:27 <sipa> is it a map from {legacy,p2sh-segwit,segwit,taproot,witv2} to descriptors
19:41:40 <sipa> or is it a map from {base58,bech32,bech32m} to descriptors
19:42:03 <Murch> Yeah, but those two feel sort of orthogonal to me.
19:42:08 <sipa> if you want a wallet that generates p2pkh addresses (and have the expertise to understand what that means)... construct a wallet with a p2pkh descriptor
19:42:18 <Murch> okay
19:42:44 <achow101> so if you want a wallet that generates v1 addresses for the bech32m type, make a wallet that only has a v1 descriptor
19:42:50 <sipa> yes
19:43:38 <achow101> ok, that is reasonable to me. ACK on OutputType::BECH32M
19:43:44 <sipa> based on your reactions i feel like i'm turning this into a storm in a cup of water
19:43:51 <Murch> I'm kinda confused, because the receiver doesn't usually control what the sender can send to. So the receiver usually needs to be able to downgrade to enable the sender to pay them.
19:43:52 <sipa> (is that an idion in english?)
19:44:17 <achow101> sipa: I have never heard of that ideom
19:44:18 <sipa> Murch: one wallet can have simultaneously descriptors for base58, bech32, and bech32m
19:44:26 <Murch> right
19:44:27 <jonatack> in a teacup
19:44:28 <meshcollider> sipa: maybe storm in a teacup :)
19:44:58 <achow101> Murch: I think this whole discussion is predicated on wallets properly supporting future witness versions in bech32m
19:44:59 <sipa> and at address generation time you pick from those three (or even just the subset that is available; if you don't have a bech32m descriptor active, you can't generate an address for it)
19:45:30 <Murch> yeah
19:45:43 <sipa> i'd hate to see wallets that are forced to have descriptors of a dozen types just because or API needs a way to generate one for every possible constructions
19:46:01 <Murch> okay, I think I'm starting to get it.
19:46:11 <sipa> achow101: right, agree - and if that fails, we may need to add yet another output type to distinguish
19:46:21 <sipa> but doing so IMO should be predicated on sender's abilities
19:46:22 <achow101> sipa: well for users who use the same wallet and just keep upgrading them, eventually they'll have a descriptor for ever supported witness version :)
19:46:45 <sipa> we shouldn't turn every new descriptor into a new wallet type
19:47:06 <sipa> achow101: perhaps yes, that's fair
19:47:34 <sipa> jonatack, meshcollider: thanks, indeed!
19:47:44 <achow101> ok, any thing else to discuss?
19:47:50 <sipa> (in dutch we have the equivalent but in a glass of water)
19:47:51 <Murch> achow101: In a way, if Bitcoin Core handles it in a way that doesn't let users explicitly choose, it may become a driver for the sending side to interpret not being to send as a bug
19:48:09 <meshcollider> I'm in favour of the base58/bech32/bech32m optioning after this discussion
19:48:22 <achow101> I have one more topic related to descriptors
19:48:26 <Murch> alternatively, people will complain that Bitcoin Core's new wallets are incompatible, and they go back to using v0
19:48:40 <sipa> Murch: that's what descriptors are for
19:48:48 <sipa> they let you exactly configure what you want
19:48:58 <achow101> What do we do about combo() with taproot and future single key things?
19:49:35 <achow101> Murch: I wonder if the current incompatibility is partially due to Core having that same behavior early on
19:49:59 <sipa> Murch: bitcoin core wallet files store the descriptor, and the only supported way to backup, is copying the wallet file (and perhaps in the future, dumping just the descriptors)... in both cases, there shouldn't ever be incompatibilities
19:50:27 <Murch> Not sure whether Bitcoin Core is used in enough transactions to have that sort of influence. Sometimes it feels that Bitcoin Core is more popular among hodlers. ;)
19:50:38 <Murch> Did your survey say something about that?
19:50:46 <sipa> if you try to "recover" a wallet from seed phrases or something like that without any metadata, that's bound to cause problems, but that's exactly a reason not to do that...
19:51:02 <Murch> Right
19:51:12 <achow101> Murch: I haven't looked at the data yet
19:51:48 <sipa> achow101: can you currently import a combo() descriptor?
19:51:51 <Murch> And if a wallet actually supports sending to v1 but doesn't support sending to v2, you could still fall back to v0, if you only have v2 instead of v1 addresses in your wallet config.
19:52:04 <achow101> sipa: combo can be imported as an inactive descriptor
19:52:17 <achow101> (i.e. not used for getnewaddress)
19:52:25 <sipa> right, makes sense
19:52:46 <sipa> i think we should see combo/addr/raw as kind of special top-level things, that aren't quite as supported as the rest
19:52:59 <sipa> and for future stuff only use 1-descriptor-one-sPK
19:53:09 <achow101> sipa: I guess the question is whether combo should make taproot single key spks
19:53:17 <sipa> i say no
19:53:23 <achow101> I'm inclined to say no, but we should document that
19:53:38 <sipa> it wouldn't be hard to add that, but i feel we shouldn't extend combo
19:54:14 <Murch> Okay, OutputType::BECH32M sounds reasonable
19:54:16 <sipa> its original purpose was migrating/mimicking legacy wallets
19:54:17 <achow101> I actually think we shouldn't have had combo, raw, or addr descriptors in the first place
19:54:31 <sipa> achow101: i tend to agree, in retrospect
19:55:13 <sipa> and legacy wallets hopefully never support taproot
19:55:39 <achow101> if taproot requires descriptor wallets, that will surely drive adoption of descriptor wallets :)
19:55:47 <sipa> :))))))))
19:55:58 <achow101> any other topics?
19:56:21 <sipa> dropping support for combo()/raw()/addr() ;)
19:56:25 <Murch> hah
19:56:43 <achow101> It probably wouldn't actually cause that much of a problem
19:56:44 <sipa> i can't imagine many things relying on it
19:57:04 <sipa> it's kind of neat that inferdescriptor always returns _something_, but it's also kind of pointless
19:57:04 <achow101> I might have to update my migratewallet branch but that's it
19:57:13 <Murch> P2PKH is actually down to 45% of the inputs and 43% of the outputs.
19:57:49 <achow101> sipa: yes raw(<spk i just entered>) is not particularly useful
19:58:35 <achow101> #endmeeting