Continuing the discussion about noinput / anyprevout

The bitcoin-dev mailing list has recently seen renewed interest in eltoo, and a proof-of-concept implementation has been established. This has sparked discussions regarding clean abstractions for off-chain protocols, leading to the reconsideration of the sighash_noinput proposal (BIP-118), as well as AJ's bip-anyprevout proposal. There are several open questions that remain to be addressed, including general agreement on the usefulness of noinput/anyprevoutanyscript/anyprevout, strong support or opposition to chaperone signatures, and the same for output tagging/explicit opt-in. However, an important question that was missed from this list is whether we understand the dangers of noinput/anyprevout-style constructions. The author believes that anyprevout signatures make the address you're signing for less safe and may cause you to lose funds when additional coins are sent to the same address, although this can be avoided with careful handling or by not caring about losing funds in the event of address reuse. He also suggests that being able to guarantee that an address cannot be signed with an anyprevout signature is valuable, so having it be opt-in at the tapscript level is advantageous. Receiving funds spent via an anyprevout signature does not involve any qualitatively new double-spending/malleability risks. Additionally, he argues that output tagging is unnecessary and there is no need for users to mark anyprevout spends as "tainted" to wait for more confirmations than normal before considering those funds safe. The author recommends having a public testnet where every weird noinput/anyprevout case is demonstrated and tested to ensure that all concerns are addressed.