bitcoin-dev

Continuing the discussion about noinput / anyprevout

Continuing the discussion about noinput / anyprevout

Original Postby Ethan Heilman

Posted on: October 1, 2019 14:27 UTC

The email thread discusses the usefulness of noinput, anyprevoutanyscript and anyprevout.

Richard Myers supports the unification and adoption of the sighash_noinput and anyprevoutput* proposals to enable eltoo, but also to make possible better off-chain protocol designs generally. He believes that concerns about rebindable transactions can be classified and addressed. The potential problem of a bad wallet designer misusing noinput is not too compelling as there are simpler ways to cut corners and there will always be plenty of good wallet options people can choose from. Scripts signed with no_input signatures are only really exchanged and used for off-chain negotiations, very few should ever appear on chain.The downsides of chaperone signatures outweigh the advantages. One additional downside is the additional code complexity required to flag whether or not a chaperone output is included. By comparison, the code changes for creating a no_input digest that skips the prevout and prevscript parts of a tx is much less intrusive and easier to maintain.Output tagging may negatively impact the anonymity set of taproot transactions. The suggested work around would impose a cost to unilateral closes of an additional translation transaction and not using the work around would cause a hit to anonymity for off-chain script users. Both costs are too high relative to the benefit gained of preventing sloppy reuse of public keys.Richard believes that BIP-118 and bip-anyprevout should be merged. He also thinks both chaperone signatures and output tagging should become part of the discussion of security alternatives, but not part of the initial specification. Efforts like descriptors will help people follow best practices when working with complex scripts without pushing extra complexity for safety into the consensus layer of bitcoin. Anywhere we can make core code simpler, and handle foot-guns in higher level non-consensus code, the better.