Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-20 📝 Original message: ZmnSCPxj via ...

📅 Original date posted:2019-05-20
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:

>> Can you expand on that? Why do we need to "make use of the
>> collaborative path" (maybe it's unclear to me what you mean by
>> collaborative path here)?
>
> The collaborative path is the use of the taproot-tweaked public key to
> sign, without revealing any scripts. The bip-taproot proposal
> specifically disallows all `SIGHASH` that is not the current set of
> valid `SIGHASH` flags when using this path, and thus does not include
> `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
>
> New `SIGHASH` types *are* allowed in bip-tapscript (i.e. when signing
> for a `OP_CHECKSIG` variant inside a taproot script), and this is
> where the proposal of aj builds upon.
>
> For myself, I do not see any point in using the collaborative path
> unless we are cooperatively closing anyway. And once we are
> cooperatively closing, we can agree to spend the funding txo without
> requiring that `SIGHASH_ANYPREVOUT` be used (since we already have
> fallbacks in case of cooperation failure, i.e. the existing
> update/settlement txes). So again I do not see this to be an issue.
> (I could be wrong)

You are correct. I forgot that the updates, besides being signed by both
parties, also need to enforce the correct ordering through the CLTV
opcode which cannot be part of the key path (thanks AJ for the correct
name). Hence only collaborative closes can use the key path, which means
we sadly don't gain much from using taproot in the update-settlement
structure, i.e., the unilateral case is always visible on-chain.

Cheers,
Christian