• Repairing the Witness Discount
• BIP-XXXX (Draft): Graduated Witness Weight
  • Abstract
  • Motivation
    • What the discount is for
    • The arbitrage
    • Goal: repair the subsidy, not restrict the use
  • Specification
    • Definitions
    • Weight computation
    • Block validity
    • Policy recommendations (non-consensus)
    • Activation
  • Rationale
    • Why price by size and not by content
    • Why not price by script type
    • Why per-input granularity
    • Why a graduated schedule rather than a single threshold
    • Why the top rate is exactly 4 WU/byte
    • Alternatives considered
    • Resulting equilibrium
  • Backwards compatibility
    • Soft fork
    • Existing outputs and pre-signed transactions
    • Wallets, fee estimation, mining
  • Deployment path
  • Open questions
  • Appendix A: Evasion equilibrium analysis
  • Appendix B: Impact table (strawman constants)
  • Appendix C: Separable companion — witness quantity ceiling
  • References
  • Acknowledgements

§Repairing the Witness Discount

I never posted the whole BIP I wrote. Instead I tried to post to the Bitcoin mailing list with the idea. The post was not allowed on the forum with the reason being that it seemed like an “LLM enhanced shower thought” and that “my premise that the discount is for signatures is not factually correct”. While I understand the moderation for the mailing list, I’d like to think my original submission was more than an LLM enhanced shower thought. The only reason I did not provide my entire draft was because 1. it’s a draft… and 2. The whole reason of the post was to illicit feedback to further improve my full draft. Then I was encouraged to go get feedback elsewhere. So here I am in elsewhere. Illiciting feedback. I never said the discount was for just signatures. It is my understanding the witness is discounted because this is information you MUST include in your transaction for signatures, PUBLIC KEYS and SCRIPTS. Am I wrong that is what the dicount is for? Anyways here is the original post that was denied from the mailing list. Followed by the Full draft of the unpublished BIP.

Original Post:
Subject: The witness discount and bulk data

Hey everyone,

I’ve been thinking about this since bip110 failed. I don’t want to relitigate that whole mess, but I think it aimed at the wrong target. Filtering data by content at the consensus layer is an arms race you can’t win, the workarounds
were published before it even activated. The complaint underneath it was real though, it just isn’t about data. It’s about price.

The witness discount exists to price the stuff you have to publish to spend a coin. Signatures, keys, scripts. Those bytes never touch the UTXO set and get pruned after validation, so they cost the network less, and they’re naturally small. A signature is 72 bytes. Nothing about that rationale covers a 400kb payload, but the discount is unbounded, so ever since taproot removed the script size limits it’s been acting as a 4:1 subsidy for storing data in the witness instead of OP_RETURN. That’s the only reason the envelope trick exists. I don’t care that people store data on chain. I care that they pay a
quarter of what every other byte in the block pays, on a discount that was designed for signatures.

So the idea I want to float: keep the discount where it does its job and phase it out where only bulk data lives. Per input, the first 400 witness
bytes cost 1 WU/byte like today, then 2 WU/byte up to 4000, then 4 WU/byte (full price) above that. It’s purely additive on top of bip141 weight, so it’s a strict tightening and a clean soft fork. No content rules, no templates, nothing becomes invalid. Any witness of 400 bytes or less per input is completely untouched, same weight, same fees, presigned transactions included, and that covers every lightning transaction type with room to spare. The numbers are strawmen, they’d have to come from real chain data.

To be upfront about what it actually achieves: the cheapest evasion is chunking data across inputs, and inputs and outputs already pay full price, so bulk data realistically lands around 2x today’s price rather than 4x. Lazy single witness payloads do pay the full 4x. Getting the floor all the way to 4x would mean pushing the threshold below lightning’s own witness sizes, so I’d rather admit the 2x now than oversell it.

Before I write this up as a proper draft I wanted to test the waters here first. Does pricing by size and never by content hold up? Is there prior arton graduated witness pricing I should read? And is there interest in a real study of witness sizes across the whole chain to pin down the constants, and maybe deploying it as standardness only first so we can see how relay and fees react before anyone brings up activation.

Cheers,
Ocean

This was the message that was denied from posting for the stated reasons.
Now here would be my full draft I would have ammended with feedback.

§BIP-XXXX (Draft): Graduated Witness Weight

BIP: XXXX (to be assigned)
Layer: Consensus (soft fork)
Title: Graduated Witness Weight
Author: OceanSlim <oceanslim@gmx.com>
Comments-URI: TODO (Delving Bitcoin thread)
Status: Draft
Type: Standards Track
Created: 2026-08-18
License: BSD-2-Clause
         CC0-1.0

§Abstract

This BIP proposes a change to transaction weight accounting: the SegWit witness
discount (1 weight unit per byte) is retained in full for the first
Q1 = 400 serialized witness bytes of each input, tapers to 2 WU/byte between
Q1 and Q2 = 4,000 bytes, and ends entirely (4 WU/byte, parity with
non-witness data) above Q2. All constants are strawman values pending
empirical study (see Open Questions).

The change is a pure tightening of block validity — computed weight can only
increase — and is therefore deployable as a soft fork. No script, output type,
or transaction becomes invalid. No content rule of any kind is introduced.

The purpose is to repair a pricing error, not to restrict data storage.
Arbitrary data remains storable in witnesses without restriction; it simply
stops receiving a subsidy that was designed for signatures and spending
scripts. Under the strawman parameters, the effective price of bulk witness
data rises from ~1.0 WU/byte to a floor of ~2.0 WU/byte against optimal
evasion, and to ~4.0 WU/byte (full parity with OP_RETURN) for naive
single-witness payloads — while every witness at or below 400 bytes per input,
which includes all deployed Lightning Network transaction types, is bit-for-bit
unaffected: identical weight, identical fees, identical pre-signed fee rates.

§Motivation

§What the discount is for

BIP-141 defines transaction weight as base_size × 3 + total_size,
equivalently 4 WU per non-witness byte and 1 WU per witness byte. The discount
exists because witness bytes impose lower long-term cost on the network: they
never enter the UTXO set, and they are prunable after validation. Its intended
beneficiaries are the bytes a spender must publish to satisfy a spending
condition — signatures, public keys, and scripts.

Nothing in that rationale prices bulk payloads. A signature is 64–73 bytes; a
public key is 32–65; the overwhelming majority of spending scripts ever
published are a few hundred bytes at most. The discount’s economic
justification is bounded in size by the needs of actual spending, but the
discount itself is unbounded.

§The arbitrage

Since the activation of Taproot, which removed practical script-size limits
inside the witness, this unbounded discount has functioned as a 4:1 price
subsidy for storing arbitrary data in witnesses relative to every other
location — including OP_RETURN, the output type explicitly designed for data
carriage, whose bytes pay full price. The entire “envelope” construction
(OP_FALSE OP_IF <payload> OP_ENDIF inside a tapscript leaf) exists to
capture this arbitrage. Single-input witness payloads of hundreds of
kilobytes, priced at one quarter of the rate any other byte in the block pays,
have been a routine feature of the chain since 2023.

This proposal takes no position on whether such data should be stored. It
takes the position that no byte should receive the witness discount unless it
falls within the size regime the discount was designed to serve.

§Goal: repair the subsidy, not restrict the use

Explicit non-goals, stated here because recent history (see BIP-110) makes
them the default assumption:

• No content inspection. Consensus cannot distinguish data from
  cryptographic material and this proposal does not try (Rationale,
  “Why price by size and not by content”).
• No new validity limits. Nothing that is storable today becomes
  unstorable. There is no cap on witness size, payload size, or block data
  share in this proposal. (One pre-existing bound does move: with the block
  weight limit unchanged, the largest single witness that fits in a block
  falls from ~4.0 MB to ~1.0 MB under the new accounting. Larger payloads
  remain storable chunked, at the Appendix A price.)
• No retroactive effect. Every currently spendable output remains
  spendable; no pre-signed transaction with per-input witnesses ≤ Q1
  changes weight by even one unit.

The single goal: bulk witness bytes pay a price consistent with the rest of
the block, and the discount survives — fully intact — for the spending-sized
witnesses it was created for.

§Specification

§Definitions

For each transaction input i, let w_i be the serialized size in bytes of
that input’s witness field as defined by BIP-141: the compactSize item count,
plus, for each item, its compactSize length prefix and its data. For a
non-SegWit input, w_i = 0. The coinbase witness (the 32-byte BIP-141
commitment nonce) is treated identically; at 34 serialized bytes it is far
below Q1 and unaffected.

Constants (strawman values; see Open Questions):

Q1 = 400      # full-discount quota per input, bytes
Q2 = 4000     # taper limit per input, bytes

§Weight computation

The witness surcharge for input i:

surcharge(w) = 1 * min( max(w - Q1, 0), Q2 - Q1 )   # bytes in (Q1, Q2] cost 2 WU
             + 3 * max( w - Q2, 0 )                 # bytes above Q2 cost 4 WU

The transaction’s weight becomes:

weight'(tx) = bip141_weight(tx) + sum( surcharge(w_i) for each input i )

Equivalently: each input’s witness bytes cost 1 WU/byte up to Q1, 2 WU/byte
from Q1 to Q2, and 4 WU/byte above Q2. The marker, flag, and all
non-witness bytes are accounted exactly as in BIP-141.

§Block validity

After activation, a block is invalid if the sum of weight' over its
transactions exceeds 4,000,000 WU. No other consensus rule changes. In
particular:

• No transaction-level validity rule is added; only block weight accounting
  changes. Transactions of any witness size remain consensus-valid.
• Block assembly remains a one-dimensional knapsack over weight' — no new
  limit dimension is introduced (contrast Appendix C).
• The BIP-342 tapscript execution budget remains defined over serialized
  witness size and is unaffected.

§Policy recommendations (non-consensus)

Implementations should apply weight' wherever bip141_weight is used for
fee-rate and standardness purposes (e.g., the 400,000 WU standard transaction
limit), so that mempool acceptance, fee estimation, and mining converge on
consensus accounting. A preview flag enabling weight'-based policy ahead of
activation is the recommended first deployment (see Deployment path).

§Activation

Deliberately unspecified in this draft. The author’s position: activation
parameters (BIP 8, thresholds, timeline) should be proposed only after the
policy-preview phase has produced deployment data and the parameter study in
Open Questions is complete. This draft explicitly disclaims flag-day
activation absent overwhelming ecosystem consensus. A proposal of this kind
earns activation; it does not schedule it.

§Rationale

§Why price by size and not by content

Every content-based approach — pattern filters, “executed bytes only”
discounts, envelope detection — fails against laundering, and fails worst at
the consensus layer where the cost of being wrong is a chain split:

• Preimage laundering. A rule that discounts only bytes that “matter to
  execution” is satisfied by passing every 520-byte data chunk through
  OP_SHA256 <32-byte hash> OP_EQUALVERIFY (~7% overhead). The chunk is now
  a hash preimage the script verifies — the same species of witness material
  as a Lightning HTLC preimage. Excluding it excludes Lightning.
• Upgrade-hook laundering. BIP-342 defines any public key that is not 32
  bytes as an “unknown pubkey type” whose signature check succeeds
  automatically, deliberately, to permit future key types. A 520-byte blob
  used as a “public key” with any nonempty “signature” is executed, used,
  and valid by design. Closing this closes Taproot’s upgrade path.
• Template whitelists (“discount only known script shapes”) are content
  rules in disguise and ossify script innovation; see the dedicated
  subsection below.

Size is the only signal consensus can price without lying to itself, and it is
sufficient: legitimate witness material is bounded in size by the needs of
spending conditions, while data storage requires bulk. The two populations
barely overlap, and where they do (large multisig), the graduated schedule
prices the overlap gently rather than excluding it.

§Why not price by script type

Rate schedules keyed to script type are mechanically implementable — consensus
observes the spent scriptPubKey template, the witness structure, and the
revealed script — and were considered in two forms. Both are rejected.

By spent output type (e.g., cheaper rates for P2WPKH or key-path spends).
Beyond making weight a function of prevout context rather than of the
transaction serialization alone (a layering cost for fee estimation, PSBT
tooling, and raw-transaction handling), this adds nothing: honest script types
already have characteristic sizes (key-path 66 B, P2WPKH ~108 B, deployed
Lightning scripts ≤ ~325 B), so the graduated size schedule prices them
implicitly — without naming them and therefore without freezing the type
system.

By revealed-script template whitelist (full discount only for approved
script shapes). Script templates are made of opcodes plus slots, and slots
hold uniform-random-looking bytes: public keys and hashes. A template
whitelist is therefore a schedule of approved data containers. Concretely:

• In any k-of-n multisig template, only k keys ever prove possession by
  signing; the remaining n − k key slots accept arbitrary 32–33-byte strings.
  Bare-multisig data storage (“Stamps”) is the deployed proof, and it is the
  UTXO-bloating worst case of the genre. A whitelist admitting large-n
  multisig yields bulk data at ~1.2 WU/byte — cheaper than this proposal’s
  floor; capping n small to prevent that taxes real federations, reproducing
  the same size trade-off this BIP makes, but entangled with semantic rules.
• Requiring possession proofs for every discounted slot (all keys sign)
  contradicts k-of-n’s purpose, still leaks through hash slots (a script’s
  hash-lock bytes are data when the spender uses the other branch), and turns
  discount-claiming into mandatory signature validation — inviting worst-case
  block validation cost as an evasion side effect.
• Every future protocol — new opcodes via OP_SUCCESS, novel miniscript
  compositions, LN-symmetry, vault covenants — would pay full price until a
  soft fork adds its template. The whitelist converts permissionless script
  innovation, the design goal of tapscript, into a consensus petition process.
  Miniscript’s composability alone makes the legitimate-template set
  unenumerable.

The general principle: consensus can verify form, not meaning. A script
type is a claim about meaning; any discount attached to it is arbitraged by
matching the form. Size is the one self-authenticating attribute a byte has,
and — because honest types have characteristic sizes — pricing by size is
pricing by type, minus the ossification. (One narrow exception is clean:
a future witness or leaf version can launch with its own weight rules from
day one, since nothing is grandfathered there; that is compatible with, and
orthogonal to, this proposal.)

§Why per-input granularity

• Per-item quotas are useless: a witness item’s length prefix is 1 byte,
  so chunking data into item-sized pieces costs ~1% overhead and defeats any
  per-item rule.
• Per-transaction quotas price evasion highest (each chunk needs a whole
  transaction) but tax legitimate aggregation: a 50-input batched channel
  close or coinjoin legitimately carries kilobytes of aggregate witness.
  Batching must not be penalized.
• Per-input quotas are the fixed point: every legitimate witness is
  attached to an input that exists for spending reasons, while an evader must
  manufacture inputs — and inputs are the one thing that cannot be
  manufactured at a discount, because input and output bytes pay 4 WU/byte
  already. Per-input pricing turns the evasion path itself into the surcharge
  (Appendix A).

§Why a graduated schedule rather than a single threshold

A flat rule (1 WU/byte to 400, 4 WU/byte above) yields the same evasion
equilibrium (~2×; Appendix A) but triples the collateral on the rare
legitimate mid-size witness. Example, 15-of-15 P2WSH multisig (~1,650-byte
witness):

The mid tier exists purely to soften collateral on legitimate large scripts;
it does not weaken the data price floor, which is set by Q1 and the
input-manufacturing cost (Appendix A). There is also no cliff anywhere in the
schedule: a witness one byte over Q1 pays one extra weight unit.

§Why the top rate is exactly 4 WU/byte

Parity, not punishment. The principle is that no byte should pay less than
normal price merely for being in the witness; charging witness bytes more
than non-witness bytes would invert the incentive and push payloads toward
outputs and scriptSigs — including UTXO-bloating encodings, which are strictly
worse for the network than witness data. 4 WU/byte above Q2 makes bulk
witness storage cost what OP_RETURN storage costs, no less and no more.

§Alternatives considered

§Resulting equilibrium

Under the strawman constants (derivation in Appendix A):

• A rational bulk-data user chunks payloads at 4,000 bytes per input and pays
  ~2.01 WU/byte — double today’s price, with the additional non-price
  costs of chunked storage (UTXO manufacture and management, reassembly
  indexing, loss of the single-witness payload format).
• A naive single-witness payload pays ~3.98 WU/byte — full parity.
• Migrating to OP_RETURN costs 4.0 WU/byte. Under this proposal’s framing,
  such migration is success, not leakage: the byte is paying full price in
  the location designed for it.
• Every input with witness ≤ 400 bytes pays exactly what it pays today.

The residual gap between the ~2.0 floor and full parity is not a design flaw
but a theorem: it equals the cost of manufacturing inputs, and raising it
further requires lowering Q1 into the size range of deployed Lightning
witnesses (Appendix A, “Why the floor cannot be pushed to 4× cleanly”).

§Backwards compatibility

§Soft fork

For every transaction, surcharge ≥ 0, hence weight' ≥ bip141_weight. Any
block valid under the new rule (Σ weight' ≤ 4M) satisfies
Σ bip141_weight ≤ 4M and is therefore valid under current rules. Old nodes
accept all new blocks; the change is a strict tightening. No transaction is
ever invalid by this rule, so there is no transaction-relay incompatibility
class — only weight accounting differs.

§Existing outputs and pre-signed transactions

• Every currently spendable UTXO remains spendable. No funds are frozen or
  confiscated under any parameterization.
• Any pre-signed transaction whose per-input witnesses are ≤ Q1 — which
  includes every deployed Lightning transaction type (Appendix B) — has
  identical weight before and after activation: same fee rate, same relay
  behavior, same RBF/CPFP arithmetic.
• Pre-signed transactions with witnesses above Q1 (rare; large-script
  vaults and similar) remain valid but their effective fee rate is diluted by
  bip141_weight / weight'. For a 1,000-byte-witness input this is ~13%.
  Mitigations exist in all modern designs (CPFP, anchors). A census of such
  protocols is a required pre-activation work item (Open Questions).

§Wallets, fee estimation, mining

Wallets and estimators that obtain vsize/weight from node software inherit the
new accounting automatically. Coin selection and fee logic need no changes for
witnesses ≤ Q1. Block template construction is unchanged in structure
(single weight dimension, same greedy/ancestor-score algorithms).

§Deployment path

1. Publish with analysis first. This document, its equilibrium math, and
   a full-chain empirical witness-size study (Open Questions) go to Delving
   Bitcoin for adversarial review before any activation discussion.
2. Policy preview. A patch (Core and/or Knots) adding
   -graduatedwitnessweight as a standardness option: mempool acceptance
   and fee-rate computation use weight'. Zero consensus risk, fully
   reversible, and it produces the decisive dataset: how relay, fee markets,
   and data users actually respond, including evasion behavior in the wild.
3. Parameter freeze. Q1/Q2 set from measured witness-size
   distributions with published safety margins over every deployed protocol.
4. Activation proposal. Only after 1–3, as a separate document, through
   ordinary BIP process. The precedent to imitate is BIP-54’s unhurried
   assignment-to-Complete arc, not any recent attempt to schedule consensus
   on a deadline.

§Open questions

• Empirical constants. Q1 = 400 / Q2 = 4,000 are strawman values. A
  full-chain histogram of per-input witness sizes, partitioned into
  envelope/data-bearing and other witnesses, is required. Q1 should clear
  the largest observed non-data witness class in wide deployment
  (currently Lightning HTLC paths, ~325 B) with explicit margin; whether
  512 is a better Q1 than 400 is an empirical question.
• Future protocol headroom. BitVM-class constructions publish
  100 kB-scale witnesses and would pay near-parity under this proposal. The
  author’s view is that this is the principle working as intended — bulk is
  bulk — but affected-protocol review belongs in the Delving thread.
• Mid-tier rate. 2 WU/byte matches the floor set by Q1-chunking
  (Appendix A); raising it buys nothing against evaders and only taxes large
  multisig. If review moves Q1, the mid rate should be re-derived, not
  assumed.
• Standardness cap interaction. Whether the 400,000 WU standard
  transaction limit should be computed over weight' (recommended above) or
  left on BIP-141 accounting during the preview phase.
• Activation mechanics. Entirely open by design.

§Appendix A: Evasion equilibrium analysis

Setup. An evader wants to store P bytes of payload in witnesses at
minimum total weight. Chunking across inputs is the general evasion: each
chunk-input carries T serialized witness bytes, of which ~45 bytes are
envelope machinery (control block + prefixes + push opcodes), so payload per
input is T − 45.

Per-chunk fixed cost. Each additional input requires:

• the input itself: 36 (outpoint) + 1 (empty scriptSig length) + 4
  (nSequence) = 41 bytes × 4 WU = 164 WU;
• the creation, in some prior transaction, of the output it spends — the
  smallest script-path-capable outputs (P2TR, P2WSH) are 43 bytes × 4 WU =
  172 WU (fan-out transaction overhead amortizes to ~0 at scale).

Total: ~336 WU of full-price bytes per chunk, unavoidable because inputs
and outputs already pay 4 WU/byte. This is the mechanism of the proposal: the
evasion path is made of exactly the bytes that were never discounted.

Cost per payload byte. With the graduated schedule, witness weight for a
T-byte witness (Q1 ≤ T ≤ Q2) is 400 + 2(T − 400) = 2T − 400, so:

rate(T) = (336 + 2T − 400) / (T − 45) = (2T − 64) / (T − 45)     Q1 ≤ T ≤ Q2
rate(T) = (336 + T) / (T − 45)                                    T ≤ Q1

Both branches are decreasing in T; above Q2 the marginal rate is 4 and
rate increases. The global optimum is exactly T = Q2:

The floor as a formula. The equilibrium price is

floor = min( (Q1 + 336)   / (Q1 − 45),    # chunk at Q1, all bytes at rate 1
             (2·Q2 − 64)  / (Q2 − 45) )   # chunk at Q2, mid tier engaged

With the strawman constants the branches evaluate to 2.07 and 2.01. The mid
rate is chosen so its branch sits at, not below, the Q1-chunking bound:
raising it buys nothing (evaders shift to Q1-sized chunks at 2.07), while a
lower mid rate would itself become the floor.

Why the floor cannot be pushed to 4× cleanly. Solving
(Q1 + 336)/(Q1 − 45) = 4 gives Q1 = 172 bytes — below deployed Lightning
HTLC and justice witnesses (~220–325 B). Every parameterization achieving
full parity against optimal evasion taxes Lightning’s own witnesses; every
parameterization that exempts Lightning concedes a floor near 2×. The
schedule can move along this curve but not off it. This proposal chooses the
Lightning-exempt point and states the concession plainly, with the
observation that at ~2× plus chunking’s fixed costs, the evader is no longer
meaningfully subsidized — they are paying most of freight through the
full-price input/output bytes the evasion forces them to buy.

§Appendix B: Impact table (strawman constants)

Approximate serialized per-input witness sizes; Δ is the weight change for
that input.

All Lightning rows are zero by construction of Q1; this is the load-bearing
safety property and the reason Q1 cannot chase the last 2× (Appendix A).

§Appendix C: Separable companion — witness quantity ceiling

A complementary, independently deployable soft fork: a second block-level
limit Σ w_i ≤ X (e.g., X = 2,000,000 bytes) alongside the 4 MWU weight
limit, with precedent in the coexisting sigops limit. Properties: no
transaction’s validity or price changes outside data-saturated blocks; data
bids against data for the witness lane under load rather than against
payments; worst-case serialized block size falls from ~4.0 MB to 2.5 MB,
bounding IBD and archival growth. Cost: block assembly becomes
two-dimensional. This BIP is a price floor; the ceiling is quantity control.
They compose, but are deliberately not bundled — each should be judged alone.

§References

• BIP-141: Segregated Witness — weight definition and discount
• BIP-341 / BIP-342: Taproot / Tapscript — script-size limit removal, unknown pubkey types, execution budget
• BIP-54: Consensus Cleanup — process model for narrowly-scoped tightenings
• BIP-110: Reduced Data Temporary Softfork — the content-rule approach and its outcome; this proposal is designed on the opposite methodology
• BIP-8 / BIP-2 — activation and process
• Bitcoin Optech: Consensus cleanup

§Acknowledgements

TODO — reviewers on the Delving Bitcoin thread.