lightning-dev

Eltoo, anyprevout and chaperone signatures

Eltoo, anyprevout and chaperone signatures

Original Postby Christian Decker

Posted on: May 20, 2019 13:03 UTC

In a Lightning-dev post, ZmnSCPxj asked for clarification on the "collaborative path" mentioned in a previous message.

The collaborative path refers to using the taproot-tweaked public key to sign without revealing any scripts. The bip-taproot proposal disallows all SIGHASH flags except for the current set of valid ones when using this path, which means it does not include SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT. However, new SIGHASH types are allowed in bip-tapscript. ZmnSCPxj believes there is no point in using the collaborative path unless parties are cooperatively closing anyway. Once they agree to spend the funding txo, they don't need to require SIGHASH_ANYPREVOUT since they already have fallbacks in case of cooperation failure. Christian later posted a response acknowledging 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. Therefore, only collaborative closes can use the key path, and we do not gain much from using taproot in the update-settlement structure; the unilateral case is always visible on-chain.