bitcoin-dev

Continuing the discussion about noinput / anyprevout

Continuing the discussion about noinput / anyprevout

Original Postby Chris Stewart

Posted on: October 1, 2019 15:14 UTC

The discussion revolves around the usefulness of noinput/anyprevoutanyscript/anyprevout and the benefits it provides, particularly for eltoo.

There is general agreement on the adoption of these proposals to make better off-chain protocol designs. Concerns are raised about the potential misuse of no_input by bad wallet designers, but it is suggested that there are simpler ways to cut corners and there will always be plenty of good wallet options people can choose. Scripts signed with no_input signatures are only really exchanged and used for off-chain negotiations and should represent non-cooperative situations that involve signing parties who know not to reuse or share scripts with these public keys again.The advantages and disadvantages of chaperone signatures and output tagging/explicit opt-in are discussed. It is suggested that the lazy wallet designer advantage is not enough to justify the downsides of chaperone signatures, as they require additional code complexity to flag whether or not a chaperone output is included. 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 negatively impacts the anonymity set of taproot transactions and imposes a cost to unilateral closes of an additional translation transaction. Both costs are too high relative to the benefit gained of preventing sloppy reuse of public keys.It is suggested that BIP-118 and bip-anyprevout should be merged, but 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.