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):

Schedule	That input's witness weight	vs. today
Today (BIP-141)	1,650 WU	—
Flat 4 WU/byte above 400	5,400 WU	+938 vB
Graduated (this BIP)	2,900 WU	+313 vB

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#

Design	Bulk-data price (optimal evasion)	Lightning impact	15-of-15 P2WSH impact	Notes
Status quo	~1.0 WU/byte	—	—	4:1 subsidy vs. OP_RETURN
Full discount removal	4.0	+50–244 vB per input, by channel type/path	+1,238 vB	taxes the intended use to catch the unintended one
Flat discount cut to 2 WU/byte	2.0	+17–81 vB per input, by channel type/path	+413 vB	same floor as this BIP, but everyone pays
Flat threshold (400 B, then 4)	~2.07	none	+938 vB	simpler; 3× the multisig collateral
Graduated (this BIP)	~2.0	none	+313 vB	floor preserved, collateral minimized
Content/pattern rules (BIP-110 family)	~1.0 (bypassed pre-activation)	collateral via false positives	—	evasion demonstrated before activation; near-zero hashrate uptake
Executed-bytes-only discount	~1.07	breaks on preimages	—	preimage laundering, BIP-342 upgrade hooks
New output type with committed witness budgets	~1.0	none	none	toothless: evaders keep using existing P2TR forever (grandfathering)
Script-type / template-whitelist rates	~1.2 (key/hash slots)	none directly	depends on whitelist	slots are data containers; ossifies script innovation (see Rationale)

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:

Strategy	Rate (WU per payload byte)
Single 390 kB witness (status quo behavior)	3.98
Chunks of 4,000 B per input (optimal)	2.01
Chunks of 400 B per input	2.07
Preimage-laundering (defeats content rules)	no effect here — pricing is size-based; adds ~7%
OP_RETURN migration	4.00 + tx overhead
Today, for comparison	~1.00

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.

Witness	Size (B)	Δ weight	Effect
P2TR key-path spend	66	0	none
P2WPKH spend	~108	0	none
LN anchor spend	~116	0	none
LN justice / to_local sweep	~160–220	0	none
LN commitment (funding 2-of-2)	~222	0	none
2-of-3 P2WSH multisig	~254	0	none
LN HTLC-timeout / success	~286–325	0	none
MuSig2 n-of-n (any n, key path)	66	0	none
3-of-5 tapscript multisig	~405	+5 WU	~+1 vB; no cliff
11-of-15 P2WSH (federation-style)	~1,326	+926 WU	~+232 vB
15-of-15 P2WSH	~1,655	+1,255 WU	~+314 vB (witness cost ×1.76)
BitVM-class disprove (~100 kB)	100,000	+291,600 WU	pays ~3.9× — near parity
390 kB single-witness payload	390,000	+1.16 MWU	pays ~3.98× — parity
Optimally chunked bulk data	4,000 / input	—	pays ~2.01× (Appendix A)

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.