--- Log opened Sun Feb 20 00:00:05 2022
05:34 < sanket1729> andytoshi: Do you think the 'intp here is useful? https://github.com/rust-bitcoin/rust-miniscript/blob/6a89bd0d1aa2a4b2e78d624276471727bf61b753/src/interpreter/mod.rs#L274
05:36 < sanket1729> I believe that since all of these things are `Copy`, we should just remove them in favor of simpler things. Unless you would want to keep the reference for some other reason
05:38 < andytoshi> sanket1729: yeah agreed, they're all copy, just hold them by value
05:39 < sanket1729> It will help simplify extending it x-only keys.
05:39 < andytoshi> i think i might've put a lifetime in there as part of a confused attempt to try to tie data to the descriptor in which in originated
05:39 < andytoshi> but that's dumb and unnecessary
05:39 < andytoshi> (if i did it for efficiency reasons that's even worse :))
05:39 < andytoshi> and if you did it, sorry to be insulting :P
05:40 < andytoshi> in any case -- yep, go ahead and remove the references/lifetime
05:40 < sanket1729> I think you did it, but I Acked it
05:40 < sanket1729> so, we are both to blame :)
05:40 < andytoshi> :)
05:41 < andytoshi> ah yeah -- you can see further down that we have an &'intp u32
05:41 < andytoshi> that definitely was not about efficiency. i think my idea was that users could compare the *pointer values* to determine which specific timelock they were looking at
05:41 < andytoshi> but in retrospect i think that's insane, from an API standpoint
05:42 < sanket1729> Agreed
05:43 < sanket1729> I was looking at musig2 support for psbt. There is one awkward thing, I think we might two separate mappings from agg_key -> [list_keys] for key spend (agg_key, leaf_version) -> [list_keys]
05:43 < sanket1729> because while signing for script spend, we sign a particular leaf, and while signing for key spend there is no leaf
05:44 < sanket1729> maybe sipa or achow101 have some suggest something here
05:45 < andytoshi> can you clarify what the leaf_version is used for here?
05:45 < sanket1729> Sorry
05:46 < sanket1729> I meant leaf hash
05:46 < sanket1729> not the leaf version
05:46 < andytoshi> ok :) that makes more sense
05:46 < andytoshi> this sounds reasonable .. i am also tempted to have a mapping (agg_key, Option<leaf_hash>) -> [list_keys]
05:46 < andytoshi> which i guess is equilavent
05:47 < sanket1729> I don't know how if it's a good idea to have these in psbt. 
05:47 < andytoshi> ah! yeah, sorry, i missed that we were talking about PSBT
05:47 < andytoshi> for PSBT i am tempted to use the all-zeros hash as the "leaf hash" for the keyspend path
05:47 < sanket1729> We have two separate PSBT_IN_KEY_SPEND and PSBT_IN_SCRIPT_SPEND
05:48 < sanket1729> Those are not the exact names, but we have two fields for key spend and script spend
05:48 <@sipa> i think those should just identity the aggregated keys
05:48 <@sipa> and then you'd have separate from either of one a field for aggkey -> list(constituent keys)
05:49 < andytoshi> i like that
05:49 <@sipa> keep the psbt fields separate from the "where keys are used" fields
05:51 < sanket1729> What is those in "those should just identity the aggregated keys"?
05:52 <@sipa> the keys jn PSBT_IN_KEYSPEND and PSBT_IN_SCRIPT_SPEND should be the aggregated keys, not the continuent ones
05:52 <@sipa> *constituent
05:53 <@sipa> and then you'd have a separate map for looking up what the constituent keys are for an aggregated keys, whether that aggregated key is used in a key path or a script path
05:55 < sanket1729> Yup, for some reason(I don't remember now) I was thinking that we need to also save leaf hash in the lookup map. I don't remember why, let me recall :P
05:55 <@sipa> because the leaf hash participates in the sighash calculation
05:56 <@sipa> so a signer who doesn't understand a script can still sign
05:56 <@sipa> by just seeing "oh, i participate in leaf hash X, here is a signature for that"
05:57 < sanket1729> Yep, so we need to new fields? aggkey_keyspend -> [list_keys] and (aggkey, leaf_hash) -> [list_keys]
05:57 < sanket1729> *two
05:58 <@sipa> no
05:58 <@sipa> i don't see why
05:58 <@sipa> the leaf hash information is already in the existing scriptpath field
05:59 <@sipa> the only added information needed for musig is a (aggkey -> list(keys)) one
06:06 < sanket1729> Makes sense. I had underlined on my board "Ask Pieter about Two fields", but now it sounds foolish. 
06:07 < sanket1729> Ah, now I see. It was about we don't have support for x-only-key ->  schnorr_sig. We only have (x-only-key, leaf_hash) -> schnorrisg
06:07 < sanket1729> The current PSBT_IN_TAP_KEY_SIG has no key, and value is key spend sig
06:08 < sanket1729> The normal PSBT_IN_PARTIAL_SIG could also be extended for x-only-key -> schnorr_sig
06:09 < sanket1729> The question is where do we store partial sigs of constituent keys in key spend path
06:09 < sanket1729> because they don't have a leaf hash
06:11 <@sipa> right, there may be a need to split those up
06:11 < sanket1729> Is it too late to change BIP371 to have key-value as a constituent key? 
06:11 < sanket1729> https://github.com/bitcoin/bips/blob/master/bip-0371.mediawiki
06:11 <@sipa> it's not used anywhere, i think?
06:11 < sanket1729> Nope
06:11 <@sipa> bitcoin core has a pr but it's not merged
06:13 < sanket1729> It can be output key if there is no aggregation. 
06:15 <@sipa> i think we may want to split things up further
06:15 <@sipa> separate the "this key is used in this key path" from "this key is bip32 derived from ..."
06:17 < sanket1729> What is "this key path"? There is only one key path right?
06:18 <@sipa> eh, script path
06:19 <@sipa> i'll spend some time thinking about this next week
06:20 < sanket1729> I am also confused about how interaction of PSBT_IN_TAP_BIP32_DERIVATION with BIP341 tweaking. The bip32 path would lead to internal secret key right?
06:21 < sanket1729> Maybe, this is what you are referring to > "this key is used in this script path" from "this key is bip32 derived from ..."
06:22 < sanket1729> nevermind, there is no tweaking for keys inside tapscript
09:09 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Ping timeout: 240 seconds]
09:23 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##miniscript
21:08 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection]
21:08 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##miniscript
21:26 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection]
21:26 -!- elsirion_ [~quassel@gateway/tor-sasl/elsirion] has joined ##miniscript
21:57 < sanket1729> Another thing to think about: If we asking the parties to do interaction via MuSig2 to compute nonces, it maybe reasonable to ask them to directly input the aggregated signature into psbt. 
22:04 < sanket1729> Or we want to design psbt so that parties to do aggregated nonce computation too in it too. I don't know if that's too invasive
--- Log closed Mon Feb 21 00:00:05 2022