Published on: 2018-09-26T20:40:02+00:00
The discussion on the bitcoin-dev mailing list revolves around the use of the NOINPUT flag in Bitcoin transactions. The main topic of discussion is whether or not to sign the sequence of other inputs in addition to the nSequence of the same input in BIP143.Jonas Nick suggests that NOINPUT should zero out the hashSequence for consistency with ANYONECANPAY, but this would create problems when using eltoo update scripts with OP_CSV. Eltoo update transactions have two branches (update and settlement), and removing OP_CSV could allow them to be taprootified.The settlement branch is a 2-of-2 multisig with a relative timelock using OP_CSV. Both parties' signatures are required to spend the update transaction, which can be signed with SINGLE since it doesn't use relative timelocks. However, there is a catch that hashSequence includes the sequence numbers of all transaction inputs.This can be solved by zeroing out the hashSequence whenever NOINPUT is combined with SINGLE. The modification to the current NOINPUT implementation has been provided. Although this approach has some downsides, such as not being able to rebind to an output with an OP_CSV that requires a larger sequence number unless signed with SIGHASH_SINGLE, it makes eltoo unilateral closes taprootifiable.On the other hand, the use of the SIGHASH_NOINPUT flag is causing concern for several reasons. Firstly, it allows for address reuse, which cannot be prevented due to the push payment nature of Bitcoin. Secondly, average users who rely on the GUI may not understand the technicalities happening behind the scenes. Additionally, as Lightning Network is not validated by the community, a user could manipulate their own node to require SIGHASH_NOINPUT as a condition of the channel, which poses risks for under-the-hood raw transaction risks where a transaction can be signed, but then allow the outs to alter value using a different opcode. This could be abused by a counterparty just editing it so that one party gets nothing and the other gets everything. Finally, allowing certain things to change after signing brings back malleability for those that use a TXID to identify if a transaction has been confirmed.There are also discussions on the naming of the SIGHASH_NOINPUT flag. Some suggest changing the name to "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to reflect its potential insecurity for traditional applications where third-party payments to an address can occur. However, others argue that address reuse is undefined behavior and nobody should assume that it is safe or works.Overall, the discussions revolve around finding the right balance between taprootifiability and security in Bitcoin transactions, particularly with regards to the use of the NOINPUT and SIGHASH_NOINPUT flags.Christian Decker has proposed a new sighash flag called `SIGHASH_NOINPUT` on the bitcoin-dev mailing list. This flag removes the commitment to the previous transaction input. However, there are concerns about its security and potential risks for wallets that might unknowingly use it.Gregory Maxwell suggests changing the name of the flag to something like "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to better reflect its vulnerability. Rusty Russell supports this suggestion, proposing "REUSE_VULNERABLE" as a name to scare people away from using it.The discussion revolves around the use of `SIGHASH_NOINPUT` and its potential risks. It is suggested that this flag should only be used in special protocols where the risk of reusing addresses is unlikely. There is concern about losing funds when a third party reuses a script pubkey, as funds can be lost when a troublemaker shows up. The risk is magnified because the third party address reuser has no way of knowing if this sighash flag has been or will be used with a particular scriptpubkey. The best mitigation strategy is to ensure that anyone using this flag fully understands the consequences.The discussion also includes considerations about signing with `SIGHASH_NOINPUT` versus signing with `SIGHASH_NONE`. It is more likely that wallets will sign things with `SIGHASH_NOINPUT` when using Lightning v2. There is a suggestion to limit or drop support for `SIGHASH_NONE` for segwit v1 addresses. It is also mentioned that having a separate opcode would have clean semantics but would use up NOP-codes. Additionally, there is a dependency on taproot that is not yet finalized.Laolu Osuntokun, a Bitcoin developer, expresses excitement over the resurrection of the no_input feature in Bitcoin. They suggest introducing a new sighash flag alongside no_input that could include additional flexible sighash flags. They propose a new CHECKSIG operator that would consume an available noop opcode. This approach allows developers to modify scripts within the context of merklized script executions.
Updated on: 2023-08-01T22:58:34.573011+00:00