bitcoin-dev

Continuing the discussion about noinput / anyprevout

Continuing the discussion about noinput / anyprevout

Original Postby ZmnSCPxj

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.