19:00:24 <achow101> #startmeeting 
19:00:25 <core-meetingbot> Meeting started Fri Aug 13 19:00:24 2021 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:25 <core-meetingbot> Available commands: action commands idea info link nick
19:00:31 <michaelfolkson> hi
19:00:32 <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:00:32 <achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:00:52 <achow101> anyone have any wallet topics to talk about?
19:00:52 <fjahr> hi
19:01:10 <michaelfolkson> I have some more Taproot descriptor questions if there is nothing else
19:01:34 <achow101> I think S3RK had something, if he's around
19:02:19 <achow101> michaelfolkson: go ahead
19:03:07 <michaelfolkson> Ok cool. So I watched your Twitch session on creating a new generatedescriptor RPC
19:03:11 <michaelfolkson> https://www.twitch.tv/videos/1105987609
19:03:50 <michaelfolkson> I'm trying to check that I understand the problem you're trying to solve. (You did say there were a number of possible approaches)
19:04:43 <michaelfolkson> So I could have a HD tree with ECDSA child pubkeys. Could I continue to use that HD tree and generate Schnorr pubkeys?
19:05:17 <achow101> yes, they're points on the same curve
19:05:26 <michaelfolkson> Either reusing the same private keys (not ideal) or just generate more child private keys and turn them into Schnorr pubkeys
19:06:14 <michaelfolkson> Ok so one question is whether to start a new HD tree for your Taproot descriptors or continue using an existing one
19:06:14 <achow101> ecdsa pubkeys and schnorr pubkeys are fundamentally the same thing
19:06:24 <michaelfolkson> A user might want to do one or the other?
19:06:57 <achow101> it's generally discouraged to use the same pubkeys in different addresses
19:07:27 <michaelfolkson> Right but lower leaves on the same tree or just start afresh with a new tree?
19:08:03 <achow101> BIP 86 suggests a derivation path to use for keys used in taproot addresses
19:08:18 <achow101> most other wallets will probably use that
19:08:30 <michaelfolkson> Ok
19:08:51 <Murch[m]> Same keys for two different signing algos is dangerous because you may leak the key
19:09:12 <achow101> with descriptors, it doesn't particularly matter whether we use the same master key because it is encoded in the descriptor itself
19:09:35 <michaelfolkson> Murch: I think that was covered here right? https://bitcoin.stackexchange.com/questions/107924/are-there-risks-to-using-the-same-private-key-for-both-ecdsa-and-schnorr-signatu
19:10:40 <michaelfolkson> As long as you don't reuse nonces you are ok even if you are using the same private key to generate a ECDSA pubkey and a Schnorr pubkey
19:11:32 <achow101> deterministic nonces make that basically impossible
19:12:26 <michaelfolkson> I think you're ok using the same private key to generate (and sign from) a ECDSA pubkey and a Schnorr pubkey but you probably shouldn't do it
19:13:18 <Murch[m]> That seems right, but still like an unnecessary risk, when just deriving another subtree is trivial
19:13:23 <achow101> it's not good from a privacy perspective; same applies to using the same pubkey in segwit and non-segwit addresses
19:13:44 <sipa> i would discourage reusing the same keys for two different algorithms, but there are no known attacks against it per se
19:13:58 <Murch[m]> Ah yeah, good point. Reusing keys is essentially the same as address reuse
19:14:24 <michaelfolkson> Ok cool, another question... might a user want to migrate from a HD tree of non-Taproot pubkeys to a HD tree of Taproot pubkeys?
19:14:36 <sipa> what does that mean?
19:15:13 <michaelfolkson> You have a HD tree pre Taproot activation with ECDSA child pubkeys
19:15:37 <michaelfolkson> Then you want to transfer that over to a HD tree post Taproot activation with Schnorr child pubkeys
19:16:12 <michaelfolkson> In future for things like CHECKSIGADD support you'd want as many pubkeys as possible to be Schnorr right?
19:16:28 <sipa> that's irrelevant
19:16:44 <sipa> you'd need to move them again to a CHECKSIGADD based svript
19:17:17 <sipa> and they're strictly separate
19:17:32 <sipa> you *cannot* use ECDSA signatures in taproot outputs
19:17:33 <Murch[m]> What script you use to create `scriptPubKeys` is orthogonal from the keys
19:18:38 <michaelfolkson> Aren't the Schnorr pubkeys that you're using for the Taproot multisig address generated from the HD tree?
19:18:51 <achow101> michaelfolkson: you would use a different derivation path
19:19:28 <sipa> michaelfolkson: hmm, i don't know where to start; you're confusing very different layers i think
19:19:48 <bitcoin-git> [bitcoin] jamesob opened pull request #22699: doc: add libboost-thread-dev to build-unix (master...2021-08-build-unix-boost-thread) https://github.com/bitcoin/bitcoin/pull/22699
19:19:54 <sipa> in a taproot output, by definition all keys are schnorr keys
19:20:17 <sipa> and what keys were used on those funfs before that point is irrelevent
19:20:23 <sipa> *funds
19:20:45 <michaelfolkson> They are but they are generated somewhere. And they could be generated within a HD tree.... never mind I'll revisit if I'm confused
19:20:57 <Murch[m]> michaelfolkson: The HD Tree specifies your private keys. The public keys are strictly derived data from the private keys.
19:20:59 <sipa> yes, they can be generated by an HD tree
19:21:16 <Murch[m]> And `scriptPubKeys` are yet another level of derivation from the involved public keys
19:21:51 <sipa> but schnorr keys and ecdsa keys aren't fundamentally different
19:22:03 <michaelfolkson> Ok so my concept of a ECDSA HD tree and a Schnorr HD tree doesn't make any sense
19:22:08 <sipa> they use slightly different encoding, and ideally you use a separate tree branch for it
19:22:14 <sipa> but they're all just keys
19:22:26 <sipa> and if you use a key in a taproot output, it's by definition a schnorr key
19:22:43 <michaelfolkson> Ok thanks
19:23:39 <michaelfolkson> Is there any future proofing that needs to be thought about for CHECKSIGADD, MuSig when thinking about this generatedescriptor RPC? I'm assuming not from the above
19:24:04 <sipa> not as long as generatedescriptor doesn't use any of those
19:24:07 <achow101> michaelfolkson: we won't generate such descriptors. they involve more than one party, we can't automatically generate them
19:25:25 <achow101> I intend for generatedescriptor to be solely for single key descriptors, either to rotate keys, or to add a new single key descriptor
19:25:41 <michaelfolkson> Ok so the generatedescriptor is just a one off design/code challenge because we haven't previously created descriptors before... (at least for Taproot)...
19:25:48 <achow101> yes
19:26:25 <michaelfolkson> Ok cool, thanks
19:27:06 <achow101> anything else to discuss?
19:27:26 <michaelfolkson> Did you work on alternative approaches to the one who did in the Twitch stream?
19:27:35 <achow101> no
19:27:44 <michaelfolkson> You're happy with that one?
19:27:47 <achow101> no
19:27:54 <achow101> just busy with other stuff
19:28:02 <michaelfolkson> Fair enough :)
19:28:09 <michaelfolkson> Ok that's all from me
19:28:48 <achow101> anyone else have anything to discuss?
19:29:34 <achow101> #endmeeting