--- Log opened Fri Oct 22 00:00:10 2021
06:09 -!- enick_103 [~afilini-m@51.15.93.184] has quit [Ping timeout: 252 seconds]
06:22 -!- enick_103 [~afilini-m@2001:bc8:1828:245::2] has joined ##miniscript
06:44 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##miniscript
06:47 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Quit: elsirion]
06:47 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##miniscript
09:48 < sanket1729_> andytoshi: The current Descriptor Trait is does not find it well with the taproot descriptors. There is no notion of script code in tr descriptors, there are multiple "underlying scripts"
10:25 -!- gene [~gene@gateway/tor-sasl/gene] has joined ##miniscript
10:49 < jeremyrubin> few ideas: modify it to take a Option<Path> and mandate that it be None for non TR? If None & TR return the key path?
10:58 < andytoshi> sanket1729_: hmmmmm. i will think hard about this
10:58 < andytoshi> i think jeremyrubin may have the right idea here
10:58 < andytoshi> that we should make a lot of the "underlying scripts" be Options and possibly even tapbranches
11:09 < jeremyrubin> it also probably makes sense to just add an API which is "add to psbt" or something
11:10 < jeremyrubin> do we know what TR PSBTs will look like yet?
11:10 < jeremyrubin> IIRC for signatures, Taproot scripts only side the exact script code and *not* the path, which leads to a malleability bug for TR scripts like {x, x}
11:11 < jeremyrubin> (and otherwise essentially has codesep semantics)
11:13 < jeremyrubin> one thing that's kinda interesting is it does seem like there's a bit of a missing spec for "sign this PSBT at these 5 scripts" and have later signers keep on adding sigs and hope to fully intersect on some satisfaction... psbts require (currently) pre coordination to pick a branch.
11:13 <@sipa> my assunption was that by default you'd sign for all branches you could
11:13 <@sipa> unless there are too many, in which case i don't really know what to do
11:14 <@sipa> but i suspect the vast majority will just have one or a few scripts anyway
11:20 < jeremyrubin> sipa that seems like a bad idea perhaps? what if there's a sub-protocol where you only want to exchange sigs if some other condition is met?
11:21 < jeremyrubin> E.g., imagine {absolute timeout + Alice, Alice + Bob}
11:21 < jeremyrubin> you would not want to sign Alice's timeout clause for the attempted cooperation of Alice + Bob?
11:22 < jeremyrubin> so i think it should be just all branches specified
11:22 < jeremyrubin> This could potentially be handled e.g. by allowing the stubbing out of branches i mentioned in the tr descriptor pr
11:24 <@sipa> i can imagine there are cases where you don't want to sign everything, in particular when hashlocks are involved
11:24 <@sipa> but i'm not sure i see the problem in this example
11:27 < gene> can one embed a TR script inside a non-TR output (e.g. P2SH-P2TR)? mainly thinking about for PTLC, with TR being one conditional branch
11:27 <@sipa> no
11:27 < gene> damn, didn't think so
11:27 < gene> that would be cool though
11:27 <@sipa> see footnote 3 in BIP341: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-3
11:28 < jeremyrubin> gene what are you trying to do actually tho
11:28 < jeremyrubin> it sounds like what you're wanting works, just not the way you asked
11:28 <@sipa> oh, i misread the question
11:28 < gene> yeah, probably works with dependent transactions, which I need to research more
11:29 <@sipa> TR is an output type, not a script type
11:29 <@sipa> TR outputs can contain multiple scripts; for now the only possible scripts are BIP342 ones
11:29 < gene> basically, want to do an ECDSA-2P key spend in one branch, and a taproot spend in the other branch
11:29 <@sipa> why would you want that?
11:29 < gene> chained transaction for CoinSWap
11:29 <@sipa> it's not possible, BIP342 scripts don't support ECDSA
11:30 <@sipa> but you should just use 2-party schnorr like MuSig or so instead
11:30 <@sipa> far easier
11:30 < gene> right, was a long-shot hope that some magic existed there
11:30 <@sipa> i can't imagine a use case that really needs ECDSA-2P and can't use musig/schnorr instead
11:31 < gene> right, we're talking about using it for larger anonymity set with current Bitcoin spends
11:31 < jeremyrubin> "i paid a bunch of money for these ecdsa only hsms"
11:31 < gene> currently I have it speced to use two transactions
11:31 < gene> two outputs*
11:32 <@sipa> gene: if you're using a BIP342 script or taproot output, there is no way to have a joint anonimity set with already
11:32 < gene> right, the BIP342 part is a backout output, used for when the ECDSA-2P tx fails
11:32 <@sipa> putting it in P2SH won't help you, because at spending time it still looks distinct
11:32 <@sipa> yeah, no, that's inherently impossible
11:33 < gene> thanks :)
11:33 <@sipa> taproot is what _adds_ the feature of having backout scripts in the first palce
11:33 <@sipa> so they're inherently going to look different from anything that existed before
11:35 < gene> there is a case to be made for gradual taproot adoption for coinswap, using ECDSA-2P (w/ TR backout) in the meantime
11:35 < gene> mostly centered on the anonymity set argument
11:36 <@sipa> the idea of even having different script versions within one output, and only revealing the one used, itself is introduced by BIP341 
11:36 <@sipa> so its outputs are always going to look distinct
11:36 <@sipa> jeremyrubin: perfect reason to keep using ECDSA with pre-taproot outputs... but you can't expect to take advantage of the new things either then
11:39 < jeremyrubin> yeah it's fair you said can't imagine and I could :) things like kzen are like this i think
11:40 <@sipa> gene: so even if there was a way of using ECDSA (and ECDSA-2P) within TR, and even if there was a P2SH-wrapped TR, spends would still look distinct from P2WPKH or P2PKH spends
11:41 < gene> sipa: that makes sense, appreciate the explanation. sounds like it will be better to keep them as separate outputs, and make the ECDSA-2P commit to spending into the BIP342 output
11:41 < gene> better == actually possible ;)
11:45 <@sipa> right
13:18 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
14:10 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection]
14:11 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##miniscript
14:31 -!- Netsplit *.net <-> *.split quits: fjahr, darosior
14:31 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has joined ##miniscript
14:34 -!- darosior [~darosior@194.36.189.246] has joined ##miniscript
19:31 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has quit [Ping timeout: 258 seconds]
19:32 -!- fjahr [sid374480@uxbridge.irccloud.com] has joined ##miniscript
--- Log closed Sat Oct 23 00:00:12 2021