Continuing the discussion about noinput / anyprevout

Posted by ZmnSCPxj

Oct 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.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback