bitcoin-dev

Continuing the discussion about noinput / anyprevout

Continuing the discussion about noinput / anyprevout

Original Postby Christian Decker

Posted on: October 1, 2019 14:20 UTC

In a Bitcoin developers' mailing list, the proposal of output tagging as a solution for transaction malleability was discussed.

While some developers see output tagging as a viable solution, others like ZmnSCPxj oppose it because it goes against the uniformity of unspent Taproot outputs that reduces the variability of how outputs look like. Meanwhile, output tagging proponents believe that it minimizes the need for people to get creative to work around other proposals and chaperone signatures, which are viewed as heavy-handed and costly. Regarding Decker-Russell-Osuntokun implementations, ZmnSCPxj suggested using a standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction Output confirmed on-chain, followed by a "translator transaction" that pays out to a SegWit v16 output-tagged output kept off-chain. This is followed by the Decker-Russell-Osuntokun update transaction and state transaction, both signed with SIGHASH_NOINPUT spending the translator transaction output. While most developers agree that NOINPUT is useful, there are still questions about the usefulness of chaperone signatures and output tagging. Some developers suggest working around chaperone signatures by publishing a common known private key for all chaperone signatures since the most important security is in the NOINPUT signature anyway. Furthermore, developers discussed the general agreement on the usefulness of noinput/anyprevoutanyscript/ anyprevout, opposition or support for chaperone signatures introduced in anyprevout/anyprevoutanyscript, and the advantages and disadvantages of output tagging/explicit opt-in. Finally, ZmnSCPxj noted that while keeping outputs unidentifiable is desirable, this may not be possible for off-chain payment networks since they are gossiping about the existence of channels and binding them to outpoints to prove their existence anyway.