On Thu, Mar 14, 2019 at 05:22:59AM +0000, ZmnSCPxj via Lightning-dev wrote: > When reading through your original post I saw you mentioned something about > output tagging somehow conflicting with Taproot, so I assumed Taproot is not > useable in this case.
I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput), so if you used a tagged output, you could do everything normal taproot address could, but also do noinput sigs for them. So you might have: funding tx -> cooperative claim funding tx -> update 3 [TAGGED] -> settlement 3 -> claim funding tx -> update 3 [TAGGED] -> update 4 [TAGGED,NOINPUT] -> settlement 4 [TAGGED,NOINPUT] -> claim [NOINPUT] In the cooperative case, no output tagging needed. For the unilateral case, you need to tag all the update tx's, because they *could* be spend by a later update with a NOINPUT sig, and if that actually happens, then the settlement tx also needs to use a NOINPUT sig, and if you're using scriptless scripts to resolve HTLCs, claiming/refunding the HTLCs needs a partially-pre-signed tx which also needs to be a NOINPUT sig, meaning the settlement tx also needs to be tagged in that case. You'd only need the script path for the last case where there actually are multiple updates, but because you have to have a tagged output in the second case anyway, maybe you've already lost privacy and always using NOINPUT and the script path for update and settlement tx's would be fine. > However, it is probably more likely that I simply misunderstood what you > said, so if you can definitively say that it would be possible to hide the > clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a > Taproot then I am fine. Yeah, that's my thinking. > Minor pointless reactions: > > 5. if you're using scriptless scripts to do HTLCs, you'll need to > > allow for NOINPUT sigs when claiming funds as well (and update > > the partial signatures for the non-NOINPUT cases if you want to > > maximise privacy), which is a bit fiddly > If I remember accurately, we do not allow bilateral/cooperative close when > HTLC is in-flight. > However, I notice that later you point out that a non-cheating unilateral > close does not need NOINPUT, so I suppose. the above thought applies to that > case. Yeah, exactly. Trying to maximise privacy there has the disadvantage that you have to do a new signature for every in-flight HTLC every time you update the state, which could be a lot of signatures for very active channels. Cheers, aj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev