--- Log opened Wed Nov 03 00:00:22 2021
03:18 -!- kallewoof [~quassel@user/kallewoof] has quit [Remote host closed the connection]
03:20 -!- kallewoof [~quassel@user/kallewoof] has joined ##miniscript
06:16 < sanket1729_> sipa: About musig descriptors, do you think it is useful to have wildcards in non-aggregated keys? i.e using musig2(K1/*, K2/*) over musig2(K1, K2)/*. 
06:17 <@sipa> i'm not sure
06:19 <@sipa> i can imagine that in some cases you just get participant pubkeys
06:19 <@sipa> and need to construct a deacriptor representing their musig aggregate for it
06:20 < sanket1729_> Yeah, musig2(K1, K2)/* is more efficient for scanning outputs on blockchain
06:20 <@sipa> which would call for a musig2(K1,K2), where Ki are just pubs (not xpubs)
06:20 <@sipa> and if you need to support that
06:20 <@sipa> it'd be extra work *not* to support musig2(K1/*,K2/*) as well
06:22 < sanket1729_> Does using musig2 on related keys change the security guarantees?
06:22 < _aj_> you'd get quadratic addresses if musig2(K1/*, K2/*) matched musig2(K1/4, K2/7)
06:23 <@sipa> _aj_: /* expansion happens in lockstep
06:25 < _aj_> sipa: cool, then +1 for musig(K1/*,K2/*) afaic
06:25 < sanket1729_> musig2(K1/*, K2/*) does aggregation for every derivation. Where the musig2(K1, K2)/* is only one aggregation
06:26 < sanket1729_> Assuming K1, K2 are regular pubs, not xkeys
06:27 <@sipa> really this is not the question
06:28 <@sipa> the question is whether we want to support (a) a musig(key,key) as valid key expression (b) musig(xkey,xkey) as valid xkey expression (c) both
06:28 <@sipa> an xkey expression is something that can be followed by /... derivation steps
06:28 < _aj_> i thought both, but derivations only when everything is xpub/xprv fwiw
06:29 <@sipa> and every xkey expression is obviously a valid key expression too
06:29 <@sipa> one issue is that all of this will also require ways to represent it in psbt
06:30 <@sipa> so if you permit everything, and compositions, you need to deal with e.g. musig(musig2(X1/3,P2/*),musig2(X3,X4)/*)
06:30 < sanket1729_> There is no harm is supporting both. 
06:31 < sanket1729_> I want to confirm my understanding that we should encourage users to use (a) over (b) (when both suit the use case) for efficiency reasons? 
06:31 <@sipa> (for signing, i imagine it'd all be flattened out, so it doesn't need nested musig signing support)
06:31 <@sipa> b is more efficient
06:31 <@sipa> or rather
06:32 <@sipa> for the purpose of implementing a sequence of xpub-derived multisig policies, (a) corresponds to musig(xpub1/.../*,xpub2/.../*)
06:32 <@sipa> while (b) corresponds to musig(xpub1/...,xpub2/...)/*
06:33 < sanket1729_> Yes, about the use-case of scanning funds from the blockchain using a descriptor.
06:33 <@sipa> b is more efficient
06:33 <@sipa> because the musig(xpub1/...,xpub2/...) part can be computed just once
06:34 <@sipa> and is shared across expansions
06:34 < sanket1729_> Yeah, I got confused over what (a) and (b) meant.
06:34 < sanket1729_> sorry, we are on the same page
06:34 <@sipa> ok
06:34 <@sipa> gtg, need to pack
06:35 < sanket1729_> happy journey and safe travels
07:06 -!- roconnor [~roconnor@host-45-58-217-8.dyn.295.ca] has quit [Ping timeout: 260 seconds]
07:16 -!- roconnor [~roconnor@host-45-58-217-8.dyn.295.ca] has joined ##miniscript
08:58 < sanket1729_> Does hardened derivation make sense if all the inner keys in musig2(k1, k2)/1'/* are xpriv?
08:58 <@sipa> probably not
09:00 < sanket1729_> Technically it should be possible to get aggregated priv key using all inner priv keys. But then why are doing musig2 in the first place :) ? Just use pk() combinator instead
09:06 <@sipa> right
09:06 <@sipa> because you can only expand the descriptor if you have access to all the privkeys
09:06 <@sipa> and if you do, why bother with musig
10:53 < jeremyrubin> Can you mpc compute hardened derivation on b?
11:04 <@sipa> in theory, sure, but that doesn*t really fit iv descripuors...
11:05 <@sipa> because descriiuors are a language for computing scriptPubKeds uutimateiy
11:07 <@sipa> sorry for bad typing, huge lag here
12:46 < jeremyrubin> I just meant to inquire about hardened vs non hardened derivation and preferences for music(a/*,b/*) if musig(a,b)/* was hard to do hardened for 
12:47 <@sipa> hardened derivation in general in combination with musig doesn't make much sense
12:47 <@sipa> the whole point is being able to aggregate using just participant pubkeys
12:47 <@sipa> if you're fine with interactive setup, there are many other approaches
12:50 < jeremyrubin> I thought musig 2 has interactive setup for nonce 
12:51 < jeremyrubin> And in general the signing protocols are interactive, right? Can't just use a broadcast channel?
12:52 < jeremyrubin> Ah I guess the non interactive part is just key gen that makes sense 
12:52 <@sipa> nonce = signing tike, not setup
12:52 <@sipa> signing time
20:33 -!- gnusha [~gnusha@user/gnusha] has quit [Ping timeout: 264 seconds]
--- Log closed Thu Nov 04 00:00:23 2021