bitcoin-dev
Continuing the discussion about noinput / anyprevout
Posted on: October 3, 2019 03:07 UTC
The proposal suggests a more radical excision by removing SIGHASH
from signatures and putting SIGHASH
on public keys.
However, this may not be practical for key path spends as it would lose some of the indistinguishability of taproot addresses and be more expensive than having the sighash be in witness data. The nonexistence of sighash byte implies SIGHASH_ALL
, and for offchain anyway the desired path is to end up with an n-of-n MuSig SIGHASH_ALL
signed mutual close transaction. The problems with SIGHASH_NONE
SIGHASH_SINGLE
are no worse than using SIGHASH_ALL
to pay to "1*G". As the existing sighashes are not particularly used anyway, additional restrictions on them are relatively immaterial. One way of looking at a transaction spending UTXO "U" to address "A" is that "script" lets you enforce conditions on the transaction when you create "A", "sighash" lets you enforce conditions on the transaction when you sign the transaction, and nlocktime, nsequence, taproot annex are ways you express conditions on the transaction. In that view, "sighash" is actually an extremely simple scripting language itself (with a total of six possible scripts). Only one of the scripts is widely used, another has an edge use it sucks at (assurance contracts). This does not seem like a good design, rather legacy cruft.