Sighash Flag

What Is a Sighash Flag?

A sighash flag (signature hash flag) is a byte value appended to every digital signature in a Bitcoin transaction. It instructs the network which parts of the transaction the signer has committed to. When a node evaluates a signature using OP_CHECKSIG, it reads this byte to determine what transaction data to include in the hash that gets verified against the signature.

Think of it as a scope declaration for a signature. By default, a signature locks down the entire transaction: every input and every output. But sighash flags let signers selectively commit to only certain parts, leaving the rest open for others to modify. This flexibility is what makes collaborative transaction construction, crowdfunding, and advanced Bitcoin Script patterns possible.

The sighash flag is the final byte of the signature. For legacy and SegWit transactions, the format is a DER-encoded ECDSA signature followed by one byte. For Taproot transactions using Schnorr signatures, a 64-byte signature implicitly uses SIGHASH_DEFAULT, while a 65-byte signature includes an explicit sighash byte.

How It Works

There are three base sighash types and one modifier that can be combined with any base type via bitwise OR. This produces six standard combinations, each defining a different signing scope.

Base Sighash Types

SIGHASH_ALL (0x01) is the default. Nearly every Bitcoin transaction uses it. The signature commits to every input and every output, making the entire transaction immutable once signed. No fields can be added or modified without invalidating the signature.

SIGHASH_NONE (0x02) commits to all inputs but no outputs. After signing, anyone can change where the funds go. This effectively creates a blank check: the signer pledges their UTXO but lets someone else decide the destination.

SIGHASH_SINGLE (0x03) commits to all inputs and only the output at the same index as the signed input. Other outputs can be freely added or modified. This allows multiple parties to each lock in their own input-output pair independently.

The ANYONECANPAY Modifier

SIGHASH_ANYONECANPAY (0x80) is not a standalone type but a modifier combined with any base flag via bitwise OR. It changes the input scope from "all inputs" to "only the input being signed." This produces three additional combinations:

Signing Process

When a signature is evaluated, the process follows these steps:

1. The public key and signature are popped from the script stack
2. The sighash byte is extracted from the final byte of the signature
3. A serialized copy of the transaction is built, including or excluding fields based on the sighash flag
4. The 4-byte little-endian sighash type is appended to the serialized data
5. The result is hashed (double-SHA256 for legacy/SegWit, tagged hash for Taproot)
6. The signature is verified against this hash using the public key on secp256k1

// Sighash flag byte values
SIGHASH_ALL            = 0x01  // Signs all inputs and all outputs
SIGHASH_NONE           = 0x02  // Signs all inputs, no outputs
SIGHASH_SINGLE         = 0x03  // Signs all inputs, matching output only
SIGHASH_ANYONECANPAY   = 0x80  // Modifier: sign only the current input

// Combined flags (bitwise OR)
SIGHASH_ALL|ANYONECANPAY    = 0x81  // One input, all outputs
SIGHASH_NONE|ANYONECANPAY   = 0x82  // One input, no outputs
SIGHASH_SINGLE|ANYONECANPAY = 0x83  // One input, matching output

// Taproot addition
SIGHASH_DEFAULT        = 0x00  // Implicit ALL (64-byte Schnorr sig)

Evolution Across Transaction Types

The sighash algorithm has been refined with each major Bitcoin upgrade. Legacy transactions suffer from O(n²) hashing complexity because the entire transaction must be re-serialized for each input. SegWit (BIP-143) fixed this by introducing intermediate hashes (hashPrevouts, hashSequence, hashOutputs) that are reusable across inputs, reducing complexity to O(n). SegWit also added the input value to the signed data, enabling secure offline signing for hardware wallets.

Taproot (BIP-341) further improved the algorithm by committing to all input amounts and scriptPubKeys (not just the current input's), fixing a class of fee-manipulation attacks against signing devices. It also introduced tagged hashes and the SIGHASH_DEFAULT type, and fixed the historical SIGHASH_SINGLE bug where using the flag without a corresponding output returned a hash of "1" instead of failing.

Use Cases

Standard Payments (SIGHASH_ALL)

The vast majority of Bitcoin transactions use SIGHASH_ALL. The signer commits to every input and output, ensuring the transaction cannot be modified after signing. This is the appropriate choice for simple payments, exchanges, and any scenario where the signer wants complete control over the final transaction.

Crowdfunding (ALL | ANYONECANPAY)

SIGHASH_ALL combined with ANYONECANPAY enables trustless crowdfunding. A fundraiser creates a transaction with a single output paying the target amount. Supporters each add an input signed with 0x81, pledging their funds while locking the output. The transaction is only valid once enough inputs are gathered to cover the output. No trusted intermediary holds funds, and pledges cannot be collected until the goal is reached.

This is often constructed using PSBTs (Partially Signed Bitcoin Transactions), where the incomplete transaction is passed between participants for signing.

Batch Payments and Dust Collection (NONE | ANYONECANPAY)

SIGHASH_NONE combined with ANYONECANPAY (0x82) signs only a single input with no output commitment. This allows a consolidation service to collect many small UTXOs into a single transaction. Each UTXO owner signs their input without caring about the destination, and the aggregator constructs the final outputs.

Collaborative Transactions (SINGLE | ANYONECANPAY)

SIGHASH_SINGLE combined with ANYONECANPAY (0x83) commits to exactly one input-output pair. Multiple participants can each independently sign their own pair, then combine them into a single transaction. This pattern is useful for CoinJoin-style privacy transactions, atomic swaps, and multi-party protocols where each participant controls their own slice of the transaction.

Flexible Output Assignment (SIGHASH_NONE)

SIGHASH_NONE (0x02) creates a bearer instrument: the signer commits their input but allows anyone to set the outputs. While rarely used in practice due to the risk of fund misappropriation, it has applications in specialized protocols where output assignment is delegated intentionally.

SIGHASH_ANYPREVOUT (BIP-118)

BIP-118 proposes two new sighash types exclusively for Taproot script path spends: SIGHASH_ANYPREVOUT (0x41) and SIGHASH_ANYPREVOUTANYSCRIPT (0xc1). As of 2026, this proposal remains in draft status and has not been activated on Bitcoin mainnet.

SIGHASH_ANYPREVOUT removes the commitment to the specific outpoint (txid:vout) being spent. The signature can be reused with any UTXO that has a matching script and amount. SIGHASH_ANYPREVOUTANYSCRIPT goes further, also removing the commitment to the amount and script, allowing the signature to apply to any UTXO whose script the key can satisfy.

The primary motivation is enabling eltoo (LN-Symmetry): a more efficient Lightning Network channel design where any later state can replace any earlier state without penalty transactions. Current Lightning channels require storing revocation data for every prior state, creating "toxic waste" that grows over the channel's lifetime. With ANYPREVOUT, update transactions can rebind to any previous state, simplifying channel management and enabling cleaner force-close resolution. BIP-118 would also benefit constructions like payment pools and more efficient discreet log contracts.

Why It Matters

Sighash flags are a foundational building block of Bitcoin's programmability. Without them, every signature would lock down the entire transaction, making collaborative and multi-party protocols impossible. The flexibility they provide underpins constructions from simple PSBTs to complex covenant proposals.

For developers building on Bitcoin Layer 2 solutions, understanding sighash flags is essential. Protocols like the Lightning Network rely on specific sighash types to construct commitment transactions, and emerging proposals like BIP-118 could reshape how off-chain protocols are designed. The Taproot upgrade refined the sighash algorithm to be more secure and efficient, and future soft forks may introduce additional sighash types that unlock new protocol designs.

For a deeper look at how Bitcoin's scripting system evaluates signatures and processes sighash flags, see the Bitcoin Script programmability research article.

Risks and Considerations

Accidental Fund Loss with Non-Default Flags

Using any sighash flag other than SIGHASH_ALL reduces the scope of what the signature protects. A transaction signed with SIGHASH_NONE allows anyone to redirect the funds by modifying the outputs. SIGHASH_ANYONECANPAY allows additional inputs to be added, potentially changing the effective fee. Wallet software should clearly warn users when non-default sighash flags are in use, and most wallets restrict usage to SIGHASH_ALL for safety.

The SIGHASH_SINGLE Bug

In legacy transactions, if SIGHASH_SINGLE is used but no output exists at the matching index, the signing algorithm returns a hash of "1" instead of failing. Anyone who obtains a signature over this predictable hash value can potentially spend other UTXOs controlled by the same key. Bitcoin Core prevents users from creating such transactions, and Taproot fully fixed this by rejecting the transaction as invalid. However, the bug persists in consensus rules for legacy transaction types to avoid requiring a hard fork.

Complexity in Multi-Party Protocols

Protocols that use non-default sighash flags require careful coordination between participants. The order of inputs and outputs matters for SIGHASH_SINGLE. Timeouts and sequence numbers interact with sighash flags in subtle ways. Using PSBTs and well-tested libraries like Miniscript helps manage this complexity, but developers should thoroughly understand the signing semantics before implementing custom sighash logic.

Replay Risk with ANYPREVOUT

The proposed SIGHASH_ANYPREVOUT intentionally allows signature reuse across UTXOs. While this is the desired behavior for protocols like eltoo, it introduces replay risk: a signature could be applied to unintended UTXOs if the same script and amount appear elsewhere. BIP-118 mitigates this by requiring a new public key version (0x01) so that standard keys cannot accidentally produce replayable signatures.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.