Bitcoin Sighash Types Reference: ALL, NONE, SINGLE, AnyOneCanPay

What Are Bitcoin Sighash Types?

A sighash (signature hash) type is a flag appended to every digital signature in a Bitcoin transaction. It tells the network which parts of the transaction the signer committed to when producing the signature. By varying the sighash flag, a signer can choose to lock down the entire transaction or leave certain inputs and outputs open for modification by other parties.

The default behavior (SIGHASH_ALL) signs everything: all inputs and all outputs. This is what every standard wallet uses. The other sighash types exist for advanced protocols: crowdfunding, collaborative transactions, atomic swaps, and payment channel updates. Understanding them is essential for anyone working with Bitcoin Script, PSBTs, or multi-party signing workflows.

Sighash Type Summary

Bitcoin defines three base sighash types and one modifier. The modifier (ANYONECANPAY) is combined with any base type via bitwise OR, producing six total combinations. Each combination controls which inputs and outputs the signature covers.

Taproot (BIP 341) adds a seventh option: SIGHASH_DEFAULT (0x00), which behaves identically to SIGHASH_ALL but allows the sighash byte to be omitted from the signature, saving one byte (64 bytes instead of 65).

Base Sighash Types Explained

SIGHASH_ALL (0x01)

The standard sighash type used by virtually all wallet software. The signer commits to every input and every output in the transaction. Once signed, nothing can be added, removed, or modified. This provides the strongest guarantee: the exact transaction you approved is the one that confirms on-chain.

Use case: every normal payment. When you send bitcoin from a wallet, the signature uses SIGHASH_ALL unless the software explicitly requests something different.

SIGHASH_NONE (0x02)

Signs all inputs but no outputs. The signer agrees to spend their coins but places no constraints on where the funds go. Any party with access to the partially signed transaction can set or change the output destinations. Other inputs' nSequence values are set to zero, allowing sequence-based replacement.

Use case: rare in practice and dangerous if misused. Applicable in multi-party protocols where one participant provides inputs and a trusted coordinator determines the destinations. In a single-input transaction, SIGHASH_NONE is equivalent to a blank check: a miner could intercept the transaction and redirect all funds.

SIGHASH_SINGLE (0x03)

Signs all inputs and only the output at the same index as the signing input. If input 0 is being signed, only output 0 is committed to. Additional outputs can be added or modified by other parties. Like SIGHASH_NONE, other inputs' nSequence values are set to zero.

Use case: CoinJoin and collaborative transactions. Each participant signs their own input-output pair independently. A coordinator assembles all pairs into a single transaction. Each signer only cares that their specific output is preserved.

The ANYONECANPAY Modifier

SIGHASH_ANYONECANPAY (0x80) is not a standalone sighash type. It is a modifier flag combined with any of the three base types using bitwise OR. When set, the signature commits only to the input being signed, not to any other inputs in the transaction. This allows third parties to add their own inputs after the signature is created.

ALL|ANYONECANPAY (0x81)

Signs only the current input and all outputs. Anyone can add additional inputs to the transaction. The output set is fixed: the signer knows exactly where the funds will go.

Use case: crowdfunding. A fundraiser creates a transaction with a single output for the target amount. Contributors each add an input signed with ALL|ANYONECANPAY. The transaction is only valid once enough inputs accumulate to cover the output. If the goal is not met, the transaction cannot broadcast. This is the Bitcoin equivalent of a Kickstarter-style "all or nothing" pledge.

NONE|ANYONECANPAY (0x82)

Signs only the current input and no outputs. This is the most permissive combination: anyone can add inputs, and the output destinations are completely unconstrained. The signer is effectively saying: "I relinquish control of these coins."

Use case: unconditional donations or dust sweeping. Extremely dangerous in practice. The Atomicals Market exploit in November 2023 leveraged this sighash type: attackers modified output destinations on transactions signed with 0x82, redirecting funds to attacker-controlled addresses.

SINGLE|ANYONECANPAY (0x83)

Signs only the current input and its corresponding output at the same index. Other inputs and outputs can be added freely.

Use case: atomic token swaps and colored coin exchanges. A seller signs: "I will provide this UTXO as long as this specific payment output is included." The buyer completes the transaction by adding their payment input and the output they receive. This pattern appears in Ordinals and BRC-20 marketplaces where sellers list inscription UTXOs for sale.

Practical Use Cases by Sighash Type

Sighash Behavior Across Transaction Formats

The way sighash types are processed differs across Bitcoin's three signature verification eras: legacy, SegWit v0 (BIP 143), and Taproot (BIP 341). Each upgrade improved security and efficiency.

Legacy Signing

The original algorithm copies the entire transaction, zeroes out input scripts, applies sighash-specific modifications, serializes the result, appends the sighash type as 4 bytes little-endian, and double-SHA256 hashes everything. This process has O(n²) complexity because the full transaction is re-serialized for every input signature.

SegWit v0 (BIP 143)

BIP 143 introduced a new digest algorithm that computes intermediate hashes (hashPrevouts, hashSequence, hashOutputs) once and reuses them across inputs, reducing complexity to O(n). It also commits to the input value, which is critical for hardware wallet security: without this, a compromised software wallet could lie about the input amount, causing the hardware wallet to sign a transaction with an inflated fee.

Taproot (BIP 341)

Taproot signing goes further than BIP 143 in several ways. It commits to all input amounts (not just the current input), preventing fee manipulation by malicious co-signers. It commits to all spent scriptPubKeys, preventing script substitution attacks. It uses tagged hashes for domain separation. And it fixes the SIGHASH_SINGLE bug: if the input index has no corresponding output, the transaction is invalid rather than silently producing a predictable hash. Schnorr signatures under Taproot are exactly 64 bytes for SIGHASH_DEFAULT or 65 bytes with an explicit sighash byte appended. For a broader look at Taproot's impact, see our research on Taproot and Schnorr signatures.

Proposed: SIGHASH_ANYPREVOUT (BIP 118)

BIP 118 proposes two new sighash flags for Taproot script-path spends: SIGHASH_ANYPREVOUT (0x41) and SIGHASH_ANYPREVOUTANYSCRIPT (0xc1). Unlike existing sighash types, these do not commit to the specific UTXO being spent. A signature created with ANYPREVOUT can be "rebound" to spend a different UTXO, as long as the script conditions match.

The primary motivation is the eltoo (LN-Symmetry) protocol for Lightning channels. With ANYPREVOUT, each channel state update can replace any previous state without requiring penalty transactions or storing old revocation keys. BIP 118 is currently in draft status and has been tested on Bitcoin Signet via Bitcoin Inquisition, but it has not been activated on mainnet.

Sighash Types in PSBTs

In the PSBT format (BIP 174), the sighash type is stored as an optional per-input field with key type 0x03 (PSBT_IN_SIGHASH_TYPE). The value is a 4-byte unsigned little-endian integer.

When a sighash type is present in the PSBT input, the signer must verify that the requested type is acceptable before producing a signature. If no sighash type is specified, the signer defaults to SIGHASH_ALL. This is particularly important for multisig workflows where all signers must agree on the same sighash type. You can inspect PSBT sighash fields using our PSBT inspector tool or decode raw transaction signatures with the transaction decoder.

Security Considerations

Non-default sighash types introduce real risks when misused. Developers implementing custom signing logic should understand these failure modes:

• SIGHASH_NONE in a single-input transaction lets any party (including a miner) redirect the funds to any address
• NONE|ANYONECANPAY (0x82) is the most dangerous combination: the signer loses control over both inputs and outputs. The Atomicals Market exploit in November 2023 demonstrated this when attackers altered output destinations on transactions signed with 0x82
• Legacy SIGHASH_SINGLE has a known bug: if the input index exceeds the number of outputs, the signing algorithm returns the hash 0x0000...0001 (the 256-bit number 1) instead of failing. An attacker who obtains a signature over this predictable hash can spend any UTXO at that address. Taproot fixes this by making such transactions invalid
• Legacy signing does not commit to input values, so a compromised software wallet can trick a hardware wallet into signing a transaction with excessive fees. BIP 143 (SegWit) and BIP 341 (Taproot) fix this by including input amounts in the signed digest

Rule of thumb: Never use a non-default sighash type unless your protocol specifically requires it. When you do, validate that the combination matches your security assumptions before broadcasting.

Frequently Asked Questions

What is the default sighash type in Bitcoin?

SIGHASH_ALL (0x01) is the default for legacy and SegWit transactions. For Taproot transactions, SIGHASH_DEFAULT (0x00) is functionally identical to SIGHASH_ALL but saves one byte by omitting the sighash byte from the 64-byte Schnorr signature. Every standard wallet uses one of these two unless the transaction involves an advanced protocol.

How do sighash types relate to transaction malleability?

Sighash types determine which transaction fields are covered by the signature. Fields left unsigned can be modified without invalidating the signature, which is a form of intentional malleability. SegWit eliminated third-party malleability of the txid by moving signatures to the witness, but the sighash mechanism still controls which parts of the transaction the signer commits to. Taproot adds a specific rule: a 65-byte signature must not have 0x00 as the sighash byte to prevent third parties from converting 64-byte default signatures into 65-byte ones (which would change the wtxid).

Can I use different sighash types for different inputs in the same transaction?

Yes. Each input is signed independently with its own sighash flag. A transaction can have one input signed with SIGHASH_ALL and another signed with SIGHASH_SINGLE. This is how CoinJoin transactions work: each participant signs their own input with the sighash type appropriate for their role in the transaction.

Where is the sighash byte stored in a transaction?

For legacy and SegWit v0 transactions, the sighash byte is appended as the last byte of the DER-encoded ECDSA signature push (making a typical signature 71 to 73 bytes). For Taproot transactions, an explicit sighash byte is appended after the 64-byte Schnorr signature (65 bytes total). If the Taproot signature is exactly 64 bytes, the sighash is implicitly SIGHASH_DEFAULT. During digest computation, legacy and SegWit append the sighash as 4 bytes little-endian, while Taproot uses a single byte in the SigMsg preimage.

What is SIGHASH_ANYPREVOUT and is it available today?

SIGHASH_ANYPREVOUT is defined in BIP 118 as a new sighash flag that does not commit to the specific UTXO being spent. This enables protocols like eltoo (LN-Symmetry) where signatures can be rebound to different UTXOs. As of 2026, BIP 118 remains a draft proposal. It has been tested on Bitcoin Signet via Bitcoin Inquisition but has not been activated on mainnet through a soft fork.

Why did SegWit change the sighash algorithm?

The legacy sighash algorithm has O(n²) complexity: the entire transaction is re-serialized and re-hashed for every input. For transactions with many inputs, this creates a denial-of-service vector where a specially crafted transaction takes disproportionately long to verify. BIP 143 (SegWit v0) introduced intermediate hash caching that reduces this to O(n). It also added input value commitment, which protects hardware wallets from fee manipulation attacks. BIP 341 (Taproot) extended these protections further by committing to all input amounts and all spent scriptPubKeys.

How do sighash types work with multisig and PSBTs?

In a PSBT workflow, the PSBT_IN_SIGHASH_TYPE field (key 0x03) specifies which sighash type each signer should use. If present, the signer must validate the requested type before signing. For multisig and MuSig2 schemes, all co-signers must agree on the same sighash type because the aggregated signature commits to a single digest. If no sighash type is specified in the PSBT, signers default to SIGHASH_ALL.

This reference is for informational purposes only and does not constitute financial or security advice. Sighash behavior differs across transaction formats and Bitcoin software versions. Always consult the relevant BIPs (143, 174, 341) and test thoroughly before implementing custom signing logic in production systems.