19:04:00 <achow101> #startmeeting 
19:04:01 <core-meetingbot> Meeting started Fri Jul 30 19:04:00 2021 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:04:01 <core-meetingbot> Available commands: action commands idea info link nick
19:04:09 <michaelfolkson> hi
19:04:14 <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 lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
19:04:14 <achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:04:28 <S3RK> hi
19:04:33 <sipa> hi
19:04:34 <achow101> any topics to discuss?
19:04:46 <kvaciral[m]> hi
19:05:00 <michaelfolkson> I'll ask a couple of questions if there are no topics
19:05:31 <achow101> michaelfolkson: go ahead
19:06:30 <michaelfolkson> So there are a couple of PRs #22364 and #19602 making Taproot, bech32m the defaults (and intended to be merged after activation)
19:06:31 <gribble> https://github.com/bitcoin/bitcoin/issues/22364 | wallet: Make a tr() descriptor by default by achow101 · Pull Request #22364 · bitcoin/bitcoin · GitHub
19:06:33 <gribble> https://github.com/bitcoin/bitcoin/issues/19602 | wallet: Migrate legacy wallets to descriptor wallets by achow101 · Pull Request #19602 · bitcoin/bitcoin · GitHub
19:06:58 <michaelfolkson> These are intended to a version post activation (from what I can understand)
19:07:09 <S3RK> I believe 19602 is unrelated to taproot, no?
19:07:17 <achow101> 19602 is unrelated to taproot
19:07:29 <michaelfolkson> Are these dependent on whether other wallets in the ecosystem support Taproot?
19:08:08 <michaelfolkson> Oh sorry got wrong PR number, Sjors PR to make bech32m default was supposed to be
19:08:13 <achow101> michaelfolkson: no. the default address type will remain bech32
19:08:20 <achow101> so p2wpkh will be the default address type
19:08:36 <michaelfolkson> #22260 it should have been
19:08:37 <gribble> https://github.com/bitcoin/bitcoin/issues/22260 | Make bech32m the default, except where needed. Update GUI checkbox. by Sjors · Pull Request #22260 · bitcoin/bitcoin · GitHub
19:09:03 <achow101> 22260 would be dependent on the rest of the ecosystem being able to accept bech32m addresses
19:09:59 <michaelfolkson> Right. And #22364 is in same boat?
19:10:00 <gribble> https://github.com/bitcoin/bitcoin/issues/22364 | wallet: Make a tr() descriptor by default by achow101 · Pull Request #22364 · bitcoin/bitcoin · GitHub
19:10:28 <michaelfolkson> Wallets in ecosystem would need to be able to send to P2TR (which hopefully they will)
19:10:34 <achow101> no, 22364 just needs activation
19:10:39 <sipa> no, that just enables the wallet to construct p2tr addresses
19:10:44 <sipa> it won't create them unless asked to
19:10:54 <achow101> 22364 give the option for users to make p2tr addresses, but do not give them out by default
19:11:20 <sipa> right now, you need to manually import a tr() descriptor before you can construct p2tr addresses
19:11:27 <S3RK> I have a related question. What's the path to add tr descriptor to an exisitng wallet?
19:11:32 <sipa> with 22364, such a tr() descriptor will be created by default
19:11:40 <achow101> with 22364 should also need an option in the GUI which I think can be taken from 22260
19:12:02 <achow101> S3RK: currently the only way is to use importdescriptors
19:12:13 <michaelfolkson> Ohh ok. I thought that was making the default descriptor a Taproot descriptor. That is just allowing you to make a Taproot descriptor, gotcha
19:12:20 <achow101> but I think we should add something (maybe to upgradewallet) that can generate a tr descriptor for the wallet
19:12:36 <S3RK> achow101: yes, I was thinking the same
19:12:50 <S3RK> manually constructing tr based on your existing master key is a bit tedious
19:12:52 <sipa> michaelfolkson: there is no "default descriptor"
19:13:09 <sipa> michaelfolkson: there is a default descriptor per address type
19:13:30 <sipa> right now, no default bech32m descriptor is created, so no bech32m addresses can be requested
19:13:43 <sipa> with 22364, a default bech32m descriptor will be created
19:13:59 <sipa> (but there will also still be default bech32 and legacy descriptors)
19:14:25 <michaelfolkson> Ok thanks
19:15:12 <michaelfolkson> Then a question on Miniscript (that we discussed at the last wallet meeting)
19:15:15 <S3RK> achow101: do you have any toughts on how a new command might work? we don't want a command just for the taproot, do we?
19:15:42 <michaelfolkson> But I'll wait for above to finish
19:15:59 <achow101> S3RK: I'm thinking maybe a new RPC for generating descriptors in general
19:16:27 <S3RK> what's the input for it would look like?
19:16:53 <achow101> generatedescriptor bech32m
19:16:54 <achow101> ?
19:17:01 <S3RK> michaelfolkson: sorry for hijacking your quesitons
19:17:24 <prayank> getnewdescriptor -tr ?
19:17:27 <michaelfolkson> No it is fine, I'm not only one here :)
19:17:37 <achow101> I think the argument would be the address type, and the descriptor generated depends on whatever the default for the address type we choose
19:17:43 <achow101> this would change with future descriptors though
19:18:28 <achow101> there's also some issues with sharing the same master private key as other descriptors (or rather lack of)
19:18:31 <sipa> achow101: how would it know what key to use?
19:18:58 <S3RK> good question
19:19:07 <achow101> sipa: generate a new one?
19:19:13 <S3RK> meh..
19:19:35 <S3RK> now when I create new wallet don't I have one master key for all descriptors?
19:19:36 <sipa> achow101: i'm mostly asking because i wonder if it could be extended later to help with a multisig workflow
19:19:53 <achow101> S3RK: yes
19:20:09 <S3RK> it's really nice to have one master key I think. I'd like to keep that
19:20:16 <achow101> sipa: how would that work?
19:20:30 <sipa> achow101: i don't really know...
19:20:52 <achow101> S3RK: after a wallet is created, there isn't really a concept of "the wallet's master private key"
19:21:11 <achow101> especially if people import things afterwards
19:21:55 <S3RK> yeah, I understand. But I that was the promise of HD
19:22:12 <achow101> the promise of descriptors is also that it doesn't matter
19:22:29 <achow101> since the key is in the descriptor
19:22:48 <gene> hi
19:23:30 <S3RK> I kind of agree, but harder to backup and interropability is worse
19:23:33 <achow101> S3RK: there could be a second argument that gives the address type to take the master privkey from
19:23:51 <sipa> S3RK: well you need to backup either the wallet file, or the descriptors individually
19:24:01 <sipa> just having the key is not enough in any case
19:24:13 <achow101> e.g. "generatedescriptor bech32m bech32" would mean "make a descriptor that makes bech32m addresses using the master key from the current active external bech32 descriptor"
19:24:41 <sipa> but with a different derivation path?
19:24:51 <achow101> yes
19:25:03 <sipa> how would it figure out what path to use?
19:25:10 <S3RK> sipa: yes and there is also limited amount of derivations paths. I can just generate descriptors for all of them
19:25:22 <sipa> S3RK: i really dislike that notion :)
19:26:14 <sipa> especially if multisig becomes more common, with individual signers participating possibly in multiple multisigs, you can't just assume you can iterate over all possible derivation paths
19:26:45 <achow101> sipa: I think it would just use the default derivation path. for tr that's in BIP 86
19:26:58 <S3RK> yes, multisig makes everything more complicated
19:27:21 <sipa> achow101: right, fair; perhaps it could check if that some other descriptor already uses that default derivation path
19:28:29 <achow101> if we wanted to be more specific about which descriptor to take things from, we do have a descriptor id thing
19:29:20 <achow101> but we might want to formalize descriptor ids before using them
19:29:54 <gene> does the concept of domain separation apply to descriptors?
19:30:42 <S3RK> gene: what do you mean by domain separation?
19:31:20 <gene> having a specific prefix for derivation paths specific to the use-case
19:32:09 <achow101> gene: the point of descriptors is that we can move away from doing that because the derivation paths are explicit in the descriptor
19:32:19 <S3RK> there is a notion of an "account" in the derivation path. not sure if that's what you want
19:33:14 <gene> not account, more like all tr addrs use m/45' where all normal use m/44'
19:33:20 <prayank> Do we have any transaction on Testnet that has P2TR outputs? If someone tried and has transaction id, please share. I want to check few things in my node, different explorers.
19:33:35 <achow101> sipa: we could also make the derivation path be overridden by the user
19:33:53 <michaelfolkson> prayank: We do, I'll find you a link
19:33:54 <achow101> gene: that exists already, see BIPs 44/49/84/86
19:34:08 <gene> achow101: thanks +1
19:34:28 <S3RK> sipa achow101: thanks for you ideas. we don't have to solve it now. Let's think about it and check back later
19:35:03 <achow101> right, we still have time
19:35:12 <achow101> michaelfolkson: you had somehing else?
19:35:47 <michaelfolkson> Right on Miniscript...
19:36:11 <michaelfolkson> I know nothing ever is final, final but is Miniscript considered "final" now. Time for a BIP etc?
19:36:31 <michaelfolkson> There are still small changes being made every now and again
19:37:18 <michaelfolkson> It seems gnarly getting these libraries into Core (Minisketch, Miniscript etc) when Core can change, the PR can change and the external library can change
19:38:00 <michaelfolkson> Presumably the libsecp approach of keeping it as an external library rather than a subset of it being merged into Core isn't viable
19:38:13 <achow101> looking briefly at rust-miniscript, it seems like changes aren't really being made to miniscript itself but rather to the specific implementation
19:38:30 <michaelfolkson> And this would be final like Miniscript version 1, obviously Miniscript would change with Taproot etc
19:38:40 <sipa> i don't tyink the current spec will change anymore
19:38:42 <achow101> I think the same can be said of sipa's c++ miniscript implementation
19:38:56 <sipa> but the c++ miniscript repo isn"t even up to date with that spec i think
19:39:10 <sipa> of course more extensions can be added
19:39:12 <michaelfolkson> There are a few issues and open PRs on sipa's C++ implementation
19:39:23 <michaelfolkson> (I think... from memory)
19:39:30 <achow101> sipa: is your website still the up to date spec?
19:39:45 <sipa> there has been some.more activity recently, so i think we'll be able to make.progress there soonish
19:39:51 <sipa> achow101: i don't remember
19:39:55 <sipa> too swapped out...
19:40:44 <sipa> (afk)
19:40:54 <prayank> michaelfolkson: Thanks :) you can share here. I will check in logs if my IRC app disconnects.
19:41:41 <michaelfolkson> James' Python implementation has been sitting there for a similar time so it would nice to get a "
19:41:47 <michaelfolkson> "final" BIP spec
19:41:49 <achow101> I can ask sanket or andytoshi if either of them would like to write a BIP
19:42:15 <michaelfolkson> Happy to help (and not be named as a co-author on the BIP)
19:42:28 <michaelfolkson> If needed
19:42:28 <achow101> (I expect the only person who is actually fully up to date on all of the particulars is sanket)
19:43:27 <michaelfolkson> Ok cool, that was my question having glanced over the open Miniscript PR earlier
19:43:57 <achow101> anything else to discuss?
19:44:05 <S3RK> I have one more small question
19:44:09 <michaelfolkson> And ideally not 10 BIPs for Miniscript :)
19:44:14 <michaelfolkson> ducks
19:44:36 <S3RK> how do we decide whether make listing private descriptors a separate RPC? #21500
19:44:38 <gribble> https://github.com/bitcoin/bitcoin/issues/21500 | wallet, rpc: add an option to list private descriptors by S3RK · Pull Request #21500 · bitcoin/bitcoin · GitHub
19:45:09 <achow101> S3RK: I think that's a personal preference type of thing
19:45:25 <achow101> I don't particularly care either way, but it makes sense to continue to just add an option to the existing RPC
19:45:48 <S3RK> me too. should I solicit more opinions?
19:46:38 <achow101> I don't think many people care
19:47:12 <S3RK> ok. oh.. one more thing
19:47:22 <S3RK> do we want to consider a CI setup without BDB?
19:47:37 <gene> adding a separate RPC could increase security by allowing people to disable it
19:47:47 <achow101> S3RK: that would probably be a good idea
19:48:00 <achow101> gene: There's currently no way to disable specific RPCs
19:48:12 <gene> oh...
19:48:34 <gene> guessing no way to disable RPC options then either?
19:48:57 <achow101> that's correct
19:49:33 <gene> may look into how much work it would be to add that feature
19:50:03 <achow101> anything else?
19:50:12 <S3RK> nope
19:50:14 <michaelfolkson> Nope
19:50:18 <achow101> #endmeeting