Witness Data

What Is Witness Data?

Witness data is the portion of a Bitcoin transaction that contains the cryptographic proof authorizing the spend: digital signatures, public keys, redemption scripts, and any other data required to satisfy the spending conditions of the inputs being consumed. Before SegWit, this data was embedded directly in each input's scriptSig field. After SegWit, it was moved to a separate structure called the "witness," appended to the transaction but logically separated from the inputs and outputs.

The word "witness" comes from cryptographic terminology: a witness is the piece of evidence that proves a statement is true. In Bitcoin's case, the statement is "this transaction is authorized by the owner of these coins," and the witness is the signature that proves it. By segregating (separating) the witness from the rest of the transaction, SegWit solved several long-standing protocol issues while simultaneously creating new possibilities for how block space is priced and used.

How It Works

A Bitcoin transaction has two main regions after SegWit: the base transaction data and the witness data. The base transaction contains the version, inputs (referencing previous outputs), outputs (amounts and locking scripts), and locktime. The witness data sits in a parallel structure, indexed by input position.

Transaction Structure

A SegWit transaction serializes differently depending on context. For the transaction ID (txid), the witness is excluded. For network transmission and storage, the witness is included:

// Legacy transaction layout (pre-SegWit)
[version][inputs with scriptSig][outputs][locktime]

// SegWit transaction layout
[version][marker][flag][inputs][outputs][witness][locktime]

// The marker (0x00) and flag (0x01) signal SegWit format
// Each input has a corresponding witness field:
//   witness[0] = data for input 0 (e.g., signature + pubkey)
//   witness[1] = data for input 1
//   ...

The critical detail: when computing the txid, the witness fields are stripped. This means changing the witness (for example, altering a signature's encoding) does not change the transaction ID. This is the fix for transaction malleability that motivated SegWit in the first place.

What Goes in the Witness

The contents of the witness depend on the script type being spent. Common witness structures include:

• P2WPKH (Pay-to-Witness-Public-Key-Hash): the witness contains two items: a signature and a compressed public key. This is the simplest SegWit spend.
• P2WSH (Pay-to-Witness-Script-Hash): the witness contains the arguments needed to satisfy the script, followed by the script itself. For a 2-of-3 multisig, this would be two signatures plus the redeem script.
• P2TR (Taproot): the witness contains either a single Schnorr signature for key-path spends, or the script, control block, and script arguments for script-path spends.
• HTLC redemptions: the witness includes a signature and a preimage (for success) or a signature and timeout proof (for refund).

// P2WPKH witness example
witness: [
  <71-byte signature>,
  <33-byte compressed pubkey>
]

// P2TR key-path spend witness
witness: [
  <64-byte Schnorr signature>
]

// P2TR script-path spend witness
witness: [
  <script arguments...>,
  <script>,
  <control block>
]

The Witness Discount

SegWit introduced a new way to measure transaction size: weight units. Instead of counting raw bytes, Bitcoin now uses this formula:

weight = (base_size * 4) + witness_size

// base_size  = transaction size without witness data
// witness_size = size of the witness data only
// Max block weight = 4,000,000 weight units

// Example: a transaction with 100 base bytes and 200 witness bytes
// weight = (100 * 4) + 200 = 600 weight units

This means each byte of witness data effectively costs one-quarter as much as a byte of non-witness data. A signature byte in the witness counts as 1 weight unit, while an output byte counts as 4. Transaction fees are calculated based on weight, so moving data into the witness makes it cheaper.

The discount was designed with a specific rationale: witness data is only needed for validation, not for determining the UTXO set. Nodes that have already validated a block can prune witness data without affecting their ability to verify future transactions. Since witness data imposes less long-term cost on the network, it gets a lower fee rate.

For a deeper look at how fees interact with block space, see Bitcoin fee market dynamics.

Block Size Implications

Before SegWit, blocks were limited to 1 MB of raw data. SegWit replaced this with a 4,000,000 weight unit limit. A block filled entirely with non-witness data would still be 1 MB (1,000,000 bytes * 4 = 4,000,000 weight units). But a block containing typical SegWit transactions, where roughly 60% of the data is witness data, can hold around 2 to 2.3 MB of raw data.

This was an effective block size increase achieved without changing the block size parameter itself: a key design choice that allowed SegWit to deploy as a soft fork rather than a hard fork. Nodes that did not upgrade simply ignored the witness data (which was hidden in a structure they treated as valid by default).

Use Cases

Ordinals and Inscriptions

The witness discount has had an unexpected second life as the economic foundation for Ordinals inscriptions. Inscription data (images, text, HTML, and other arbitrary content) is embedded in the witness of a Taproot transaction, taking advantage of the 75% fee discount to store data on-chain at a fraction of what it would cost in non-witness space.

An inscription is typically structured as a Taproot script-path spend where the script contains OP_FALSE OP_IF ... OP_ENDIF blocks that push the inscription data. Since the script lives in the witness, all of this content benefits from the witness discount:

// Simplified inscription structure in witness
witness: [
  <signature>,
  <inscription script: OP_FALSE OP_IF
    OP_PUSH "ord"
    OP_PUSH 1          // content-type tag
    OP_PUSH "image/png"
    OP_PUSH 0          // body separator
    OP_PUSH <image data chunk 1>
    OP_PUSH <image data chunk 2>
    ...
  OP_ENDIF
  OP_CHECKSIG>,
  <control block>
]

A 100 KB image stored in the witness costs roughly 25 KB worth of fees (100,000 weight units instead of 400,000). This discount is the primary reason inscriptions are economically viable. Without the witness discount, the same data would cost four times as much in fees.

The BRC-20 token standard also relies on inscription data stored in witness space to record token mint and transfer operations.

Enabling Advanced Scripts

The witness provides a natural home for complex spending conditions without burdening the UTXO set. Bitcoin Script programs in the witness are only revealed and validated at spend time. This means:

• Miniscript policies can encode sophisticated multi-party spending conditions in the witness, with the full script only appearing when the UTXO is spent.
• Taproot script trees can contain dozens of alternative spending paths in the witness, but only the path actually used is revealed on chain.
• PSBTs (Partially Signed Bitcoin Transactions) use the witness structure to collect signatures from multiple parties before broadcast.

Lightning Network and Layer 2 Protocols

The transaction malleability fix provided by witness data separation was the prerequisite for the Lightning Network. Before SegWit, a third party could alter a transaction's signature encoding, changing its txid without invalidating it. This broke any protocol that relied on pre-signed transactions referencing specific txids: the foundation of payment channels.

With witness data excluded from the txid, pre-signed transaction chains became reliable. This enabled not only Lightning but also other layer 2 constructions like channel factories, splicing, and eltoo. For more on how payment channels depend on this property, see payment channels: concept to implementation.

Risks and Considerations

Witness Data Pruning and Node Costs

The premise that witness data can be pruned after validation is true in theory but complicated in practice. Full archival nodes still store all witness data for historical blocks. The growth in witness-heavy transactions (especially inscriptions) has increased storage requirements significantly. A full Bitcoin node's blockchain data has grown from roughly 450 GB before Ordinals to well over 600 GB, with witness data accounting for a substantial share of the increase.

Discount Incentive Effects

The witness discount was designed to encourage efficient UTXO management, but it also created an incentive to pack data into the witness. The Ordinals use case was not anticipated when the discount was designed. Critics argue the discount underprices the actual cost of storing inscription data, since nodes cannot practically prune recent witness data and many archive it indefinitely.

Proposals like adjusting the witness discount ratio have been discussed, though any change would require a soft or hard fork and careful analysis of the impact on existing transaction types.

Backward Compatibility

Legacy (non-SegWit) transactions do not have a witness field. Their entire transaction data counts at 4x weight, making them more expensive per byte than SegWit equivalents. Wallets that still generate legacy addresses pay higher fees for the same economic effect. Most modern wallets default to SegWit or Taproot addresses, but legacy UTXOs still exist on chain and will continue to be spent for years to come.

Witness Size Limits

Individual witness items are limited to 10,000 bytes under consensus rules (with Taproot relaxing the per-element limit for script-path spends). The total witness for a single input in a standard Taproot transaction can be up to about 400,000 weight units. These limits constrain what can be stored in a single transaction but still allow for substantial data embedding across multiple inputs or transactions.

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.