bitcoin-dev
Continuing the discussion about noinput / anyprevout
Posted on: October 3, 2019 01:47 UTC
In a Lightning-dev discussion about the issues with SIGHASH_NONE
and SIGHASH_SINGLE
, ZmnSCPxj proposed that SIGHASH
be removed from signatures, and instead put on public keys.
This would remove the problems with SIGHASH_NONE
and SIGHASH_SINGLE
. However, the proposal may not work for key path spends as it could lose some of the indistinguishability of taproot addresses, making it more expensive than having the sighash in witness data. Therefore, sighashes would still be included in key path signatures, which could make the behavior confusingly different between signing for key path and script path spends. The problems with NONE and SINGLE are no worse than using SIGHASH_ALL to pay to "1*G". The use of NOINPUT/ANYPREVOUT is worse because it could allow someone to steal funds from other UTXOs, similar to nonce-reuse. Committing to enabling NOINPUT for an address may make sense, but the same is not necessary for other sighashes generally.One way to look at a transaction spending UTXO "U" to address "A" is that the "script" lets you enforce conditions on the transaction when you create "A", while the "sighash" lets you enforce conditions on the transaction when you sign the transaction. Nlocktime, nsequence, and taproot annex express conditions on the transaction. In this view, "sighash" is actually an extremely simple scripting language itself with a total of six possible scripts. Finally, graftroot allows updating those conditions for address "A" after the fact.