Continuing the discussion about noinput / anyprevout



Summary:

The Lightning-dev mailing list discussed the usefulness of noinput/anyprevoutanyscript/anyprevout and its advantages for off-chain protocol designs, particularly eltoo. The benefits include less interactive payment channel negotiation. Some concerns were raised about potential misuse or abuse of rebindable transactions, but these concerns can be addressed. One concern is the possibility of a 'bad wallet designer' misusing noinput, but there are simpler ways to cut corners and many good wallet options available. Scripts signed with no_input signatures are only used for off-chain negotiations and very few should ever appear on chain. Those that do should represent non-cooperative situations that involve signing parties who know not to reuse or share scripts with these public keys again.The discussion also touched on chaperone signatures introduced in anyprevout/anyprevoutanyscript and output tagging/explicit opt-in. While some support chaperone signatures, others believe the lazy wallet designer advantage is not enough to justify the downsides, and the additional code complexity required to flag whether or not a chaperone output is included. Output tagging could negatively impact the anonymity set of taproot transactions and impose 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 was suggested that BIP-118 and bip-anyprevout be merged, as it would reduce confusion and make discussions simpler. However, belt-and-suspender protections like chaperone signatures and tagged outputs have their own impacts on code complexity, on-chain transaction sizes, and transaction anonymity that must be considered. 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 core code can be made simpler, and foot-guns handled in higher level non-consensus code, the better.


Updated on: 2023-06-02T20:36:27.157660+00:00