Author: Christian Decker 2019-05-20 13:03:24
Published on: 2019-05-20T13:03:24+00:00
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.
Updated on: 2023-06-02T18:35:54.434237+00:00