--- Log opened Mon Jan 31 00:00:45 2022
06:14 < michaelfolkson> I'm thinking it is going to be challenging to integrate MuSig2, FROST options into the Policy -> Miniscript compiler process. Surely that requires the user to declare at the same time as declaring their policy whether they can follow a MuSig2, FROST protocol or not. The resulting Miniscript will be different depending on whether they are able to or not
06:14 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has joined ##miniscript
06:14 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined ##miniscript
06:15 < michaelfolkson> Unless MuSig2, FROST become so widespread that the compiler just assumes MuSig2, FROST is available
06:15 < michaelfolkson> Maybe it does for a future Miniscript version
06:16 <@sipa> FROST you can't compile to, as it needs interactive setup.
06:17 <@sipa> It's something that can be used by specialized software designed for it, but it doesn't nicely fit in the descriptor/psbt world
06:21 < michaelfolkson> I was thinking you'd just receive a Miniscript with single keys in it instead of k-of-n's. Obviously Miniscript can't represent interactivity or offchain stuff, only script
06:23 < michaelfolkson> But you'd have to do the interactive setup first to get the single key, yup
09:36 < jeremyrubin> this isn't a huge issue in Rust Miniscript at least, you can abstract the Key type with a translation function that handles your networked stuff 
09:36 < jeremyrubin> so it can be handled cleanly at a layer up
09:37 <@sipa> I was talking about the descriptor/psbt workflow, not any particular implementation.
09:37 < jeremyrubin> i was responding to " Policy -> Miniscript compiler process"
09:38 < jeremyrubin> obvious for descriptors you need a concrete thing, and you can't differentiate FROST keys from MuSig keys during a roundtrip
09:38 <@sipa> Unless you mean that FROST would become a feature of the compiler, making the compiler itself to networking, I don't see how they fit together.
09:39 <@sipa> Also secrets that need to be stored somewhere to be available at signing time...
09:39 < jeremyrubin> at least in rust-miniscript, Policy is parametrized by a generic Key type that has customizable trait based logic to convert to a bitcoin::PublicKey
09:40 < jeremyrubin> hijacking that would let a user do networked stuff at key translation time, altho the types maybe need to be upgraded to fallible types
09:40 <@sipa> I think we're talking besides each other.
09:41 < jeremyrubin> (there are some bugs in this logic more generally that have been declared wontfix i think that upset me, but so it goes)
09:41 < jeremyrubin> sure, I'm just talking about Policy not descriptor stuff
09:42 < jeremyrubin> i don't think miniscript can cary this information nor is it roundtrippable 
09:42 <@sipa> Right.
09:43 <@sipa> You'd need a descriptor that contains the negotiated secrets somehow. Even if that were implemented, it'd be super unsafe.
09:45 < jeremyrubin> altho in theory if you allow injecting data into e.g. a dead tapleaf branch you could at least store the metadata somewhere it gets carried around, even if unusable
09:45 < jeremyrubin> but descriptors shouldn't really contain private data
09:46 < jeremyrubin> altho I guess tapleaf branches can be made into "inherent" htlcs by having some secret prefix padding? makes my head hurt so i'm going to pretend no one will do that
09:47 <@sipa> descriptors can contain private date
09:47 <@sipa> data
09:47 <@sipa> you can put private keys in them
09:48 <@sipa> (though that's just syntactic sugar for the equivalent descripor with a public key, and then additionally "oh and the private key for that is X")
09:48 <@sipa> i don't see what this has to do with tapleafs, this doesn't need to affect the spk
09:49 <@sipa> it'd be something inside the key expressions, not the script level
17:17 -!- midnight [~midnight@user/midnight] has quit [Remote host closed the connection]
17:17 -!- midnight [~midnight@user/midnight] has joined ##miniscript
21:45 -!- rishabh [~rishabh@14.139.82.6] has joined ##miniscript
21:50 -!- rishabh [~rishabh@14.139.82.6] has quit [Quit: Ping timeout (120 seconds)]
--- Log closed Tue Feb 01 00:00:46 2022