19:00:36 <achow101> #startmeeting 
19:00:37 <core-meetingbot`> Meeting started Fri Jan 28 19:00:36 2022 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:37 <core-meetingbot`> Available commands: action commands idea info link nick
19:00:47 <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 Murch nehan NicolasDorier paveljanik
19:00:47 <achow101> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar S3RK sipa vasild
19:01:04 <michaelfolkson> hi
19:01:15 <darosior> hi
19:01:42 <achow101> There's one pre-proposed meeting topic, any others people want to add?
19:01:48 <sipa> hi
19:01:55 <darosior> Hmm maybe i failed to add mine?
19:02:12 <michaelfolkson> [18:12:49]  <darosior> #proposedwalletmeetingtopic labels for ranged descriptors
19:02:16 <achow101> oops, 2 pre-proposed topics
19:02:45 <achow101> #topic labels for ranged descriptors (darosior)
19:02:45 <core-meetingbot`> topic: labels for ranged descriptors (darosior)
19:02:49 <laanwj> hi
19:03:11 <darosior> So as part of the Miniscript work, i tested the branch against my application (which uses Miniscript internally and the descriptor wallet as watchonly to track 2 main descriptors) and discovered that labels are deactivated for range descriptors.
19:03:12 <darosior> However labels are pretty useful to differentiate the coins when you have multiple descriptors on the same watchonly wallet (which i think is the intent?). Typically for triage in the `listsinceblock` or `listunspent` results: i think i'm just an instance and they are useful as well.
19:03:12 <darosior> So i wondered what people here thought about enabling the same features to the descriptor level, to not have to add all addresses to the address book in advance (which i guessed is the reason to disable them for range descriptors in the first place?). Or if something else than labels was envisioned to enable the same features.
19:03:46 <darosior> s/and they are useful as well/ and they are useful as well to others/
19:04:29 <achow101> the reason that labels were not implemented originally was because it seemed odd to me that someone would want to assign the same label to all addresses generated by a descriptor
19:04:32 <sipa> What are you thinking of, something like a label template on the descriptor, with say a %i in it that gets replaced by the index?
19:04:38 <sipa> Or just the same label for everything?
19:04:57 <achow101> and also I think there was some complexity with applying labels to addresses that did not exist yet
19:05:18 <darosior> The same label for any address derived for this descriptor. Something to say "this received coin is for this descriptor"
19:06:40 <achow101> if you think it's something people will use, go for it
19:06:54 <michaelfolkson> Sorry for the ELI5 but by label do you mean the subscripts of Miniscript?
19:07:07 <darosior> No i mean a metadata to identify a descriptor
19:07:28 <darosior> Could just add the descriptor itself to the result, i guess, although i'd to think how a client of the API would manage that
19:07:41 <sipa> No, label, as in the setlabel RPC.
19:07:47 <sipa> and getaddressesbylabel
19:07:48 <michaelfolkson> Oh ok
19:08:21 <darosior> Ok, thanks. It was mainly to know if there were prior discussions on this topic. Guess i'm done :)
19:08:38 <achow101> I'm not sure I understand the use case, but I am ambivalent on this
19:09:01 <achow101> #topic Taproot support in the wallet (open PRs, latest thinking) (michaelfolkson)
19:09:02 <core-meetingbot`> topic: Taproot support in the wallet (open PRs, latest thinking) (michaelfolkson)
19:09:03 <sipa> Likewise.
19:09:05 <darosior> I can describe the motivation better in an issue, if that's helpful
19:09:20 <achow101> darosior: please do
19:09:49 <michaelfolkson> Ok.. so was just looking over the Taproot related PRs. #22558 is marked as high prio
19:10:44 <michaelfolkson> This should be tested in tandem with #24043?
19:11:05 <achow101> they are orthogonal
19:11:06 <michaelfolkson> To do a Taproot multisig you need the Taproot multisig descriptor right?
19:11:26 <michaelfolkson> And that is only introduced in #24043
19:11:43 <achow101> #22558 is just for the basic taproot fields to actually be able to do any kind of watchonly taproot spend
19:12:14 <michaelfolkson> But to be passing around Taproot multisig PSBTs you need to have setup a Taproot multisig.... right?
19:12:31 <sipa> the multisig part is in 24043
19:12:31 <achow101> psbt is for more than just multisigs
19:12:38 <sipa> the taproot psbt part is in 22558
19:12:46 <sipa> if you want taproot multisig psbt, then you indeed need both
19:12:47 <achow101> #22558 is needed to work with HWI for example
19:12:55 <achow101> just to do a single key taproot spend
19:13:40 <michaelfolkson> Ah ok. So to test #24043 you should be doing a single key taproot spend
19:14:28 <michaelfolkson> And then to test Taproot multisig wait for #24043 or test in tandem with #24043
19:14:40 <achow101> too many 24043's in that sentence
19:14:51 <jonatack> hi
19:15:59 <michaelfolkson> I guess what I'm saying is to get #22558 merged test with a single key Taproot spend
19:16:44 <michaelfolkson> The alternative would be to make both #22558 and #24043 high prio
19:17:13 <michaelfolkson> Ok that makes sense (I think)
19:17:16 <achow101> yes, 22558 can be tested with single key spends
19:17:56 <michaelfolkson> So then moving to #24043
19:18:38 <michaelfolkson> This seems a stopgap to me (which is fine, just testing my understanding)
19:19:17 <michaelfolkson> But presumably longer term a Taproot enabled Miniscript would tell you which 2-of-3 arrangement is most efficient
19:19:45 <sipa> No, that information is implied by miniscript.
19:20:03 <sipa> If you have a miniscript/descriptor, the script is already decided.
19:20:23 <sipa> Which one is most efficient is trivial; the question is which one is applicable.
19:20:50 <sipa> Because using e.g. FROST threshold key as internal taproot key will always be the most efficient possible for any kind of multisig.
19:20:56 <michaelfolkson> So when you say "later replaced with Miniscript based implementation" what are you referring to?
19:21:48 <sipa> That's just an implementation aspect, not something observable.
19:21:50 <michaelfolkson> I see as a descriptor as a one to one mapping with script. But Miniscript is a one to many mapping to script depending on the subscripts
19:22:04 <sipa> What are subscripts?
19:22:17 <michaelfolkson> Like the _a etc
19:22:21 <sipa> No, miniscript is a 1-to-1 mapping with (a subset of) script.
19:22:35 <michaelfolkson> Sorry shouldn't say sub*script*, makes things complicated
19:23:01 <sipa> The functions in miniscript (e.g. "multi_a", "and_v", ...) we call "fragments". if you're looking for terminology.
19:23:42 <sipa> Let me try to explain what that sentence was about, unless someone has something else to discuss?
19:24:34 <sipa> achow101?
19:24:43 <michaelfolkson> There aren't any other topics
19:25:01 <achow101> I don't have any topics
19:25:19 <sipa> Ok, so, currently the bitcoin core codebase doesn't have miniscript implemented.
19:25:56 <sipa> Miniscript covers a bunch of different things, but it at least is sort of an extension of descriptors, as well as generic signing support for miniscript-compatible scripts, and a few other things.
19:26:40 <sipa> In the long term, with the miniscript codebase integrated into bitcoin core, a significant part of the logic around descriptors and signing can be handled by miniscript, which does lots of things generically.
19:26:56 <michaelfolkson> I'm thinking eventually you could almost ditch the term "descriptors" entirely. Everything would be Miniscript
19:27:17 <sipa> I very strongly hope it's the other way around.
19:27:24 <sipa> Miniscript is the name of research project, it's not something "visible".
19:27:39 <sipa> The part that is visible are what it enables in descriptors.
19:27:47 <michaelfolkson> Ok whatever, but it would all be one thing under one name
19:27:54 <sipa> Definitely.
19:28:34 <michaelfolkson> So this new multi_a descriptor would eventually be ditched right?
19:28:49 <sipa> No?
19:28:58 <sipa> In favor of what?
19:29:44 <michaelfolkson> A Miniscript equivalent that would give you the script for n-of-n which is optimal
19:30:15 <michaelfolkson> You say in the PR n-of-n isn't optimal, but k-of-n (k<n) is optimal
19:30:18 <sipa> Once we add support for a particular descriptor we cannot remove it, as it'd break wallets that have such a descriptor.
19:30:36 <sipa> michaelfolkson: Yes, and that miniscript equivalent would be called multi_a, which behaves exactly the same as the one we have now.
19:30:55 <sipa> Only it'd be done via the miniscript codebase, instead of a special-case inside the descriptor codebase.
19:31:05 <sipa> But as a user you wouldn't be able to tell the difference.
19:31:30 <michaelfolkson> There would be multi_a for k-of-n and say a multi_b for n-of-n?
19:31:39 <sipa> For example, yes.
19:31:59 <michaelfolkson> Ok gotcha
19:32:21 <michaelfolkson> The wallet estimating witness size incorrectly will be addressed in follow up PR?
19:32:39 <sipa> Or perhaps and_v(v:pk(A),v:pk(B),...,pk(Z)).
19:33:04 <sipa> Which is more in line with how miniscript treats the optimal n-of-n script.
19:33:27 <sipa> Size estimation is a hard question, I don't really have a good solution.
19:33:43 <sipa> You can't in general predict which branch signers will be using.
19:34:04 <sipa> Perhaps something where you can pass to the fundraw* RPC which keys/signers are available.
19:34:13 <sipa> I think people have discussed something like that in the past.
19:34:29 <michaelfolkson> Doesn't Miniscript give you the most efficient option (and hence can estimate the witness sizes of the various spending paths)?
19:34:50 <michaelfolkson> Solved by Miniscript (if we can get that merged)
19:34:51 <sipa> No.
19:35:14 <sipa> Miniscript is just a way of writing scripts in a different way that allows more generic reasoning over them.
19:35:30 <sipa> You're talking about the miniscript policy compiler, which is one application of the things you can do with miniscript.
19:35:32 <Murch> hi
19:35:47 <sipa> But that's not something I'm expecting would be integrated into Bitcoin Core.
19:36:19 <sipa> It's not estimating witness sizes that's hard - miniscript can do that, as can our current codebase.
19:36:20 <michaelfolkson> Ok gotcha. You will be able to do that external to Core but Core won't have access to the compiler (necessarily)
19:36:31 <sipa> The difficulty is making the code know which keys are available, so it knows which branch to pick.
19:36:54 <sipa> That's just a logistic issue.
19:37:32 <michaelfolkson> Ok final question (thanks btw). I'm assuming all the build stuff that was done for Minisketch will need to be done for Miniscript?
19:38:11 <sipa> nope, nothing
19:38:17 <sipa> because miniscript isn't a separate library
19:38:27 <sipa> it'll just be merged into bitcoin core
19:39:13 <michaelfolkson> By separate library you just mean separate repo...?
19:39:30 <sipa> No.
19:39:49 <sipa> Minisketch is a library you build separately, with an API, you can build applications against, ...
19:40:05 <sipa> Miniscript is just a bunch of source files which are mostly intended to be integrated into Bitcoin Core.
19:40:33 <sipa> The future of the repository after that point is unclear; perhaps we keep it just for the compiler/website.
19:40:44 <michaelfolkson> There will be no Miniscript "API" or applications built using the Miniscript "library"?
19:40:44 <sipa> Perhaps people want to spend time on actually turning the miniscript codebase into a library that's independently usable, ...
19:41:00 <michaelfolkson> Oh ok you've answered that
19:41:04 <sipa> That's right. It needs Bitcoin Core right now.
19:41:18 <michaelfolkson> Ok thanks, all my questions
19:42:09 <achow101> any other topics?
19:43:10 <achow101> #endmeeting