One proposal suggests creating an opcode called OP_CHECKSIG_WITHOUT_INPUT that would ignore any SIGHASH flags on a signature. Another member suggests encoding the new code in a tapscript public key type. The discussions revolve around the benefits and drawbacks of these proposals for off-chain protocols, particularly for eltoo.There is also a discussion about the usefulness of noinput/anyprevoutanyscript/anyprevout and their potential impact on off-chain protocol designs. While there is general agreement on the adoption of these proposals, concerns are raised about the potential misuse of no_input by bad wallet designers. However, it is suggested that there are simpler ways to cut corners and that good wallet options will always be available.The discussions also touch upon the advantages and disadvantages of chaperone signatures and output tagging/explicit opt-in. Some developers believe that the downsides of chaperone signatures outweigh their benefits, as they require additional code complexity. Output tagging is also seen as potentially negatively impacting the anonymity set of taproot transactions.Efforts are made to merge proposals such as BIP-118 and bip-anyprevout, but chaperone signatures and output tagging are suggested to be part of the discussion of security alternatives rather than the initial specification. It is emphasized that making core code simpler and handling potential issues in higher-level non-consensus code is preferable.In another Bitcoin development discussion, the idea of creating a new opcode called OP_CHECKSIG_WITHOUT_INPUT as an alternative to SIGHASH_NOINPUT is proposed. However, it is pointed out that there wouldn't be much difference between creating a new opcode and making a new tapscript public key type. The discussions explore the pros and cons of each approach, considering factors such as design space, potential bikeshedding, and signature verification modalities.The discussions also touch upon the proposal of output tagging as a solution for transaction malleability. While some developers see it as a viable solution, others oppose it because it goes against the uniformity of unspent Taproot outputs and may impose additional costs in terms of transaction complexity and anonymity.There are also discussions about the implementation of Decker-Russell-Osuntokun and its potential use cases. Suggestions are made regarding the use of trigger transactions, plain bip-schnorr-signed outputs, and off-chain payment networks to increase anonymity sets and ensure security.Overall, the discussions aim to find optimal solutions for off-chain protocol designs while considering factors such as security, simplicity, and usability.The author of the email expresses concerns about the potential risks associated with the introduction of SIGHASH_NOINPUT in the Bitcoin protocol, particularly in relation to address reuse. They highlight that if a digital signature from a cold storage address with a SIGHASH_NOINPUT signature is replayed on the blockchain, it could lead to fund loss. This becomes especially problematic if the second signing path that uses SIGHASH_NOINPUT gets mixed up with the first signing path that controls an exchange's on-chain funds.Despite these risks, SIGHASH_NOINPUT is seen as a valuable tool for off-chain protocols like Lightning, but it would require large economic entities such as exchanges to have a separate signing path using SIGHASH_NOINPUT to keep on-chain and off-chain hot wallet signing procedures distinct. The author also raises concerns about introducing more complexities into the protocol and suggests disallowing the use of SIGHASH protocols with unexpected behavior.The article discusses two proposals, BIP-118 and bip-anyprevout, which aim to allow rebinding of transactions to new outputs. However, there are still unclear points regarding the dangers of SIGHASH_NOINPUT and chaperone signatures. Chaperone signatures ensure there is no third-party malleability of transactions but have downsides such as additional size and the possibility of protocols using a globally known privkey. Output tagging is proposed as a way to disincentivize non-smart-contract cases by making output scripts unaddressable, potentially creating two domains: one for user-addressable destinations and one for contracts.Christian Decker, a developer at Blockstream, proposes "eltoo" transactions as a means to significantly reduce costs associated with using the Lightning Network. While these transactions are less flexible, they could replace existing ones in the Lightning Network, enabling almost instant and low-cost Bitcoin payments. Decker also suggests using output tagging and chaperone signatures alongside eltoo transactions to enhance security and efficiency.The email proposes the creation of a new opcode, OP_CHECKSIG_WITHOUT_INPUT, equivalent to SIGHASH_NOINPUT, which would be embedded in a Taproot script. This opcode would ignore any SIGHASH flags on a signature and instead hash the current transaction without input references before checking it against the signature. The author questions why there is less