This feature has the potential to introduce another footgun into the bitcoin protocol with address reuse, and exchanges reusing addresses for cold storage with large sums of money could be vulnerable to replaying signatures on the blockchain until their wallet is drained. However, the proposal may be useful for off-chain protocols like Lightning.During the CoreDev meeting in Amsterdam, there was a discussion on whether to use "noinput" signatures for Taproot. The proposal is to let users spend an output without revealing it as a previous input, which can make Lightning channel updates faster and more efficient. While some people support this proposal, there are concerns about its security, especially if multi-party transactions are involved. In response to these concerns, developers suggested using "chaperone signatures," which are signatures that must be authorized by all parties involved in the transaction. Additionally, the idea of using chaperone signatures to ensure there is no third-party malleability of transactions is proposed. It has downsides such as additional size and protocols can still use a globally known private key. However, it addresses first-party malleability.It is imperative to keep the second signing path that uses sighash_noinput separate from the first signing path that controls an exchange's on-chain funds. It is also discussed that some developers may want to use sighash_noinput to cheapen or reduce the complexity of making a wallet implementation. This concern can be addressed by making people aware of how the feature should be used.Another proposal to achieve disincentives to non-smart-contract cases is output tagging. Instead of using addresses for taproot v1 outputs, a segwit version 16 v16 would be used that supports taproot. This would have the desired effect of not allowing generic wallets to send to these addresses or users accidentally sending funds to what was supposed to be a one-off script used internally in the off-chain contract.However, output tagging may hurt fungibility as it marks outputs used in a contract and makes them identifiable. Therefore, there have been discussions on creating two domains: one for user-addressable destinations which users can use with their general-purpose wallets and one domain for contracts, which users cannot send to directly.The questions that remain to be addressed are the usefulness of noinput/anyprevoutanyscript/anyprevout beyond eltoo, general agreement on the usefulness of noinput/anyprevoutanyscript/anyprevout, strong support or opposition to the chaperone signatures introduced in anyprevout/anyprevoutanyscript, advantages and disadvantages of output tagging/explicit opt-in, and whether BIP-118 and bip-anyprevout should be merged.