BIP Draft: Segregated Data #2222

  11 | +  Requires: 144, 152, 339, ? (Segregated Data, Consensus layer)
  12 | +```
  13 | +
  14 | +## Abstract
  15 | +
  16 | +This BIP defines how **Segregated Data (SegData)** *entries* propagate between *peers*. The consensus BIP places entries in a block-level `segdata` *region* committed via the coinbase and validates every block from its base serialisation alone, so no node needs the region to validate, at the tip or at any depth. Entry presence, integrity, and retention are therefore relay policy. This BIP specifies how entries travel bundled with their referencing transactions, how a block's region is reconstructed from held entries, how nodes serve recent entries and advertise deeper retention, and how a node opts out in part or in full.

murchandamus commented at 4:16 PM on August 12, 2026:

Relay policy strikes me as the wrong term here. I would perhaps describe it as an optional node service.

  21 | +
  22 | +**Coverage tier**: A coarse band of retention depth beyond the recent-block floor, configuring a peer to serve entries within that range.
  23 | +
  24 | +**Entry-bearing relay**: Relay that carries SegData entries, bundled with their transactions and regions, as opposed to entry-stripped relay, which carries only the standard base serialisation.
  25 | +
  26 | +**Recent-block floor**: The most recent 288 blocks, within which a SegData peer MUST retain and serve every **available** entry.

murchandamus commented at 4:18 PM on August 12, 2026:

This Glossary section seems to contain parts of the Specification.

  23 | +
  24 | +**Entry-bearing relay**: Relay that carries SegData entries, bundled with their transactions and regions, as opposed to entry-stripped relay, which carries only the standard base serialisation.
  25 | +
  26 | +**Recent-block floor**: The most recent 288 blocks, within which a SegData peer MUST retain and serve every **available** entry.
  27 | +
  28 | +**Retention policy**: A node's local choice of how much history to keep and which entries to exclude, above the mandatory recent-block floor. It determines what the node can serve, and its depth is what the coverage tier advertises. The amount and exclusion controls are defined in the consensus BIP (§Prunability, §Reference Implementation), and this BIP standardises only the coverage signal, not their format.

murchandamus commented at 4:21 PM on August 12, 2026:

(§Prunability, §Reference Implementation)

I don’t see a section titled “Prunability”. Please use actual links to link to referenced sections. If you wish leave yourself reminders for outstanding todos, you could e.g., leave a “(TK)” in the corresponding spots.

  31 | +
  32 | +## Motivation
  33 | +
  34 | +To enable prunability of SegData entries, a SegData *reference* output carries only a 4-byte marker and 32-byte hash of the entry. The transaction alone does not carry the bytes a block builder needs to populate `segdata`. Consensus never requires the region, but the network must move entries from originator to miners, and on to any node that opts to receive them.
  35 | +
  36 | +SegData entries are deliberately outside transaction identity (see D2 below), which enables deduplication and per-entry retention but means the bytes do not travel with the transaction by construction.

murchandamus commented at 4:22 PM on August 12, 2026:

Please link to referenced sections.

  32 | +## Motivation
  33 | +
  34 | +To enable prunability of SegData entries, a SegData *reference* output carries only a 4-byte marker and 32-byte hash of the entry. The transaction alone does not carry the bytes a block builder needs to populate `segdata`. Consensus never requires the region, but the network must move entries from originator to miners, and on to any node that opts to receive them.
  35 | +
  36 | +SegData entries are deliberately outside transaction identity (see D2 below), which enables deduplication and per-entry retention but means the bytes do not travel with the transaction by construction.
  37 | +

murchandamus commented at 4:24 PM on August 12, 2026:

This section is describing the approach, however the motivation section should explain why a BIP is being written, how the existing situation presents a problem, and why the proposed idea resolves the issue or improves upon the current situation.

  33 | +
  34 | +To enable prunability of SegData entries, a SegData *reference* output carries only a 4-byte marker and 32-byte hash of the entry. The transaction alone does not carry the bytes a block builder needs to populate `segdata`. Consensus never requires the region, but the network must move entries from originator to miners, and on to any node that opts to receive them.
  35 | +
  36 | +SegData entries are deliberately outside transaction identity (see D2 below), which enables deduplication and per-entry retention but means the bytes do not travel with the transaction by construction.
  37 | +
  38 | +## Key design decisions

murchandamus commented at 4:24 PM on August 12, 2026:

At first glance this section seems to contain a mix of content that should either appear in the Specification or in the Rationale sections.

  64 | +
  65 | +### D4. Receiving the region is default-on, never mandatory
  66 | +
  67 | +The default policy is to receive and relay the region, so that data stays available and the node can serve and retain it. A node MAY decline mempool entry relay while still relaying ordinary transactions, MAY take new blocks base-only rather than extended, and MAY skip or prune historical entries per its retention policy, whose depth its coverage tier then advertises (D8). A node that receives no entries anywhere still tracks consensus exactly, differing only in what it can serve. Entry-stripped relay is the rule for pre-activation and non-negotiated peers, and the explicit choice for any peer.
  68 | +
  69 | +The full opt-out is a single participation switch (for concreteness, a Bitcoin Core `permitsegdata=0`). In this case the node advertises neither service bit, negotiates no entry relay, takes base-only blocks, and retains nothing, so it holds and serves no entries while validating fully. This is independent of `blocksonly`, which governs mempool transaction relay in general. A node running `blocksonly` with SegData still permitted continues to take and serve block regions.

murchandamus commented at 4:44 PM on August 12, 2026:

Here and generally, given that this BIP does not describe a consensus change, this proposal would overall be more approachable, if it took care to frame prescribed behavior as applying to software projects implementing the proposal rather than sounding like it were making claims about node behavior in general.

  97 | +### Service bits and negotiation
  98 | +
  99 | +- **`NODE_SEGDATA`** = `(1 << 12)`: the peer relays SegData entries and serves the full `segdata` archive since activation. The guarantee is one of depth, the full range since activation, not of every individual entry. Per-entry exclusions are permitted and answered with `notfound`, and only systematic failure to serve within range forfeits the claim (§Retention-coverage advertising). A node not covering the full range MUST NOT set the bit, the BIP-159 rule for `NODE_NETWORK`. Service bits travel in `addr` relay, so syncing nodes discover archival coverage before connecting.
 100 | +- **`NODE_SEGDATA_LIMITED`** = `(1 << 13)`: the peer relays SegData entries and guarantees serving `segdata` for the most recent 288 blocks (D7). The direct analogue of `NODE_NETWORK_LIMITED`, with the same 288-block window and the same reorg-serving rationale. Nodes setting `NODE_SEGDATA` SHOULD also set `NODE_SEGDATA_LIMITED`, as archival nodes signal both BIP-159 bits today.
 101 | +
 102 | +Both bits imply entry-relay capability. By default a node retains SegData for the blocks it stores, so a default-configured unpruned node is archival and sets both bits. A node retaining less sets only `NODE_SEGDATA_LIMITED` and advertises any intermediate coverage (§Retention-coverage advertising). If a connection's advertised coverage states a tier lower than the bits imply, that coverage governs for the connection. Bits are discovery hints in `addr` gossip and may be stale, and the advertised coverage is the per-connection commitment.

murchandamus commented at 4:55 PM on August 12, 2026:

Default behavior of nodes regarding optional features is an implementation decision. I would suggest describing the services without making claims about implementation details.

  99 | +- **`NODE_SEGDATA`** = `(1 << 12)`: the peer relays SegData entries and serves the full `segdata` archive since activation. The guarantee is one of depth, the full range since activation, not of every individual entry. Per-entry exclusions are permitted and answered with `notfound`, and only systematic failure to serve within range forfeits the claim (§Retention-coverage advertising). A node not covering the full range MUST NOT set the bit, the BIP-159 rule for `NODE_NETWORK`. Service bits travel in `addr` relay, so syncing nodes discover archival coverage before connecting.
 100 | +- **`NODE_SEGDATA_LIMITED`** = `(1 << 13)`: the peer relays SegData entries and guarantees serving `segdata` for the most recent 288 blocks (D7). The direct analogue of `NODE_NETWORK_LIMITED`, with the same 288-block window and the same reorg-serving rationale. Nodes setting `NODE_SEGDATA` SHOULD also set `NODE_SEGDATA_LIMITED`, as archival nodes signal both BIP-159 bits today.
 101 | +
 102 | +Both bits imply entry-relay capability. By default a node retains SegData for the blocks it stores, so a default-configured unpruned node is archival and sets both bits. A node retaining less sets only `NODE_SEGDATA_LIMITED` and advertises any intermediate coverage (§Retention-coverage advertising). If a connection's advertised coverage states a tier lower than the bits imply, that coverage governs for the connection. Bits are discovery hints in `addr` gossip and may be stale, and the advertised coverage is the per-connection commitment.
 103 | +
 104 | +- **`sendsegdata`**: an empty negotiation message sent between `version` and `verack`, following the [BIP-339](bip-0339.mediawiki) (`wtxidrelay`) pattern. A node sends it only to SegData peers (either bit) at a protocol version of 70017 or higher (proposed, pending assignment). Entry-bearing relay is active on a connection only when both sides have sent it. Otherwise the connection carries entry-stripped relay (D3). Sending `sendsegdata` after `verack` is a protocol violation.

murchandamus commented at 4:56 PM on August 12, 2026:

This approach has meanwhile been specified as BIP434: Peer Feature Negotiation.

 140 | +
 141 | +A node holds a reference-bearing transaction's entries bundled with it in the mempool, as `txent` delivers them, and MUST hold and validate every one, each against its reference hash, to accept the transaction as minable (D5). The entries count against `maxmempool` and are evicted with the transaction, so they add no resource beyond the mempool and no separate per-entry lifecycle.
 142 | +
 143 | +In the mempool a node MAY hold a shared entry once or once per referencing transaction, the latter matching the full-attribution feerate below. Maximum entry size is relay policy. A node rejects a zero-length entry as nonstandard, since an empty entry carries no data yet still costs a reference output. This is relay policy rather than consensus because per-entry length lives in the region, not the base serialisation, so an empty entry a miner includes anyway is harmless and simply not relayed onward in the mempool.
 144 | +
 145 | +For feerate, a transaction's weight includes the full `segdata` weight of every entry it references, even one shared with another mempool transaction. This over-estimates a shared entry (consensus counts it once per block) but never under-estimates, so feerate sorting, eviction, and RBF stay well-defined and conservative. `minrelaytxfee` applies to that full weight including the entry. Standardness checks the same attributed weight, so a reference-bearing transaction and the entries it pulls in are bounded by `MAX_STANDARD_TX_WEIGHT` like any other standard transaction. Block builders MAY refine with package-style accounting at template construction.

murchandamus commented at 5:01 PM on August 12, 2026:

It would be preferable to skip over prescribing all these implementation details by just saying that the segdata counts toward the transaction’s weight as one weight per byte which would imply the described behavior in this section.

  12 | +  Requires: 8, 141, 144, 340
  13 | +```
  14 | +
  15 | +## Abstract
  16 | +
  17 | +This BIP defines a new soft-fork-activated block *region*, **Segregated Data (SegData)**, dedicated to carrying script-isolated data *entries* outside the transaction and witness structures. A coinbase output commits to a Merkle root of the entry hashes and the region's total byte length. Consensus checks only that the *commitment* matches the *references* the transactions declare, and that the block's weight, including the SegData region, is within the limit. No node needs the region itself to validate, so its presence, integrity, and availability are relay policy, and an operator may decline or discard it in part or in full at any depth while the commitment stays permanent, placing the data burden on those who choose to retain it rather than on all.

murchandamus commented at 8:56 PM on August 14, 2026:

Still find the characterization as “relay policy” a misnomer. How about:

This BIP defines a new soft-fork-activated block *region*, **Segregated Data (SegData)**, dedicated to carrying script-isolated data *entries* outside the transaction and witness structures. A coinbase output commits to a Merkle root of the entry hashes and the region's total byte length. Consensus checks only that the *commitment* matches the *references* the transactions declare, and that the block's weight, including the SegData region, is within the limit. No node needs the region itself to validate, so its presence, integrity, and availability are optional, and an operator may decline or discard it in part or in full at any depth while the commitment stays permanent, placing the data burden on those who choose to retain it rather than on all.

  16 | +
  17 | +This BIP defines a new soft-fork-activated block *region*, **Segregated Data (SegData)**, dedicated to carrying script-isolated data *entries* outside the transaction and witness structures. A coinbase output commits to a Merkle root of the entry hashes and the region's total byte length. Consensus checks only that the *commitment* matches the *references* the transactions declare, and that the block's weight, including the SegData region, is within the limit. No node needs the region itself to validate, so its presence, integrity, and availability are relay policy, and an operator may decline or discard it in part or in full at any depth while the commitment stays permanent, placing the data burden on those who choose to retain it rather than on all.
  18 | +
  19 | +## Glossary
  20 | +
  21 | +**Arbitrary data**: Bytes placed on-chain for their content rather than to authorise or define a transfer of value.

murchandamus commented at 8:57 PM on August 14, 2026:

Terminology nit: Is it “on-chain” when it is optional?

  18 | +
  19 | +## Glossary
  20 | +
  21 | +**Arbitrary data**: Bytes placed on-chain for their content rather than to authorise or define a transfer of value.
  22 | +
  23 | +**Commitment**: A coinbase output which commits to the Merkle root of all entry hashes and the total length of the SegData region.

murchandamus commented at 8:59 PM on August 14, 2026:

“Commitment” is underspecified, please use a more descriptive term. E.g., Data Region Commitment or similar.

  33 | +This BIP establishes a region through which a user can explicitly declare an intent to carry *arbitrary data*. Bitcoin currently carries such data through several vectors, none of them purpose-built:
  34 | +
  35 | +1. **OP_RETURN tail bytes.** Retained by every non-pruned node at the full transaction weight.
  36 | +2. **Witness fields.** Retained by every non-pruned node at the witness discount.
  37 | +3. **Vanity P2PKH / P2SH addresses.** Bytes encoded in the address hash, occupying a UTXO-set entry on every node indefinitely.
  38 | +4. **Bare multisig outputs.** Bytes substituted for the public keys of non-P2SH multisig, occupying a UTXO-set entry on every node indefinitely, at more bytes per output than an address hash.

murchandamus commented at 9:01 PM on August 14, 2026:

Nit: A common construction uses 1-of-3 multisig with one real public key and keys used as data carrier. Such outputs are spendable.

  36 | +2. **Witness fields.** Retained by every non-pruned node at the witness discount.
  37 | +3. **Vanity P2PKH / P2SH addresses.** Bytes encoded in the address hash, occupying a UTXO-set entry on every node indefinitely.
  38 | +4. **Bare multisig outputs.** Bytes substituted for the public keys of non-P2SH multisig, occupying a UTXO-set entry on every node indefinitely, at more bytes per output than an address hash.
  39 | +5. **Script opcodes.** Bytes encoded as the opcode sequence of an executing script rather than as pushed data, retained by every non-pruned node and executed on validation.
  40 | +
  41 | +Because it shares the same structures as monetary data, every node receives, validates, and retains arbitrary data on the same terms, so storage and IBD bandwidth scale with total data-carriage demand for all alike.

murchandamus commented at 9:03 PM on August 14, 2026:

Avoid falling back to pronouns such as “it”, rather repeat the concrete term. (We are writing technical documentation, not prose.)

Because arbitrary data shares the same structures as monetary data, every node receives, validates, and retains arbitrary data on the same terms, so storage and IBD bandwidth scale with total data-carriage demand for all alike.

Also

so storage and IBD bandwidth scale with total data-carriage demand for all alike.

doesn’t seem right. Arbitrary data has to compete for limited blockspace, so clearly storage and IBD bandwidth do not scale with demand.

  46 | +- **Application-layer asset classes**, creating sustained demand for large payloads embedded in witness data that the witness discount makes economical for the payer.
  47 | +- **Arbitrary content**, which raises concern over node-operator exposure that varies by jurisdiction.
  48 | +
  49 | +Since arbitrary data defines no transfer, the ledger's validity does not depend on it at all. A node validates every block from its base serialisation, whether or not it holds the data, so receiving and retaining the data becomes an operator's choice rather than a requirement.
  50 | +
  51 | +Therefore a carrier using SegData allows the burden it places on the network to be reduced. No existing mechanism is able to do this. Enabling `prune` mode discards block data wholesale by depth, not selectively by type. OP_RETURN still leaves its bytes retained by every node. Witness fields undercut OP_RETURN's price but are no less permanent.

murchandamus commented at 9:07 PM on August 14, 2026:

This argument could be improved. Because the sender needs to pay for the weight of the segdata, but the segdata is optional to nodes, it reduces the storage burden for nodes even compared to a data commitment to off-chain data.

  48 | +
  49 | +Since arbitrary data defines no transfer, the ledger's validity does not depend on it at all. A node validates every block from its base serialisation, whether or not it holds the data, so receiving and retaining the data becomes an operator's choice rather than a requirement.
  50 | +
  51 | +Therefore a carrier using SegData allows the burden it places on the network to be reduced. No existing mechanism is able to do this. Enabling `prune` mode discards block data wholesale by depth, not selectively by type. OP_RETURN still leaves its bytes retained by every node. Witness fields undercut OP_RETURN's price but are no less permanent.
  52 | +
  53 | +Consequently, prunability enables a resource-constrained node to receive and retain a lighter but fully valid view of a block without SegData, making the case that data carriage can contribute to decentralisation rather than only burden it.

murchandamus commented at 9:10 PM on August 14, 2026:

I know we disagree on this, but I would operate under the assumption that a fully-validating node (full node) by default will not retain the segdata even if it otherwise doesn’t prune. When looking at it from that perspective, segdata senders pay to reduce the available blockweight corresponding to their data without putting the data on-chain, in exchange for node software being able to opt-in to storing and relaying the data.

  50 | +
  51 | +Therefore a carrier using SegData allows the burden it places on the network to be reduced. No existing mechanism is able to do this. Enabling `prune` mode discards block data wholesale by depth, not selectively by type. OP_RETURN still leaves its bytes retained by every node. Witness fields undercut OP_RETURN's price but are no less permanent.
  52 | +
  53 | +Consequently, prunability enables a resource-constrained node to receive and retain a lighter but fully valid view of a block without SegData, making the case that data carriage can contribute to decentralisation rather than only burden it.
  54 | +
  55 | +SegData is priced at witness parity or less, making it cost-competitive and economically rational, and places no restriction on the existing vectors. By offering this region, a channel is provided for data to be carried honestly (§Rationale) by Bitcoin and the operators that consent to it.

murchandamus commented at 9:13 PM on August 14, 2026:

SegData is priced at witness parity or less

My understanding was that you propose it getting the witness discount, but that the overhead would be less. If that’s so, I would suggest phrasing this first subsentence differently, as a starting point “SegData is subject to the witness discount, but requires less overhead than the common witness stuffing schemes, so overall cheaper.”

 102 | +
 103 | +The region length is the byte length of the `segdata` region. It is exactly the `SegData` byte-length operand of the weight formula (§Weight accounting), so with the consensus rate `r` a node holding only the base serialisation can compute and bound a block's total weight without fetching the region (§Uniform validation). The length is a visible field rather than part of the commitment hash because a node that skips the region must read it from the base serialisation. Its fixed 4-byte width keeps the commitment a constant 42-byte scriptPubKey matched by its exact form, as the BIP-141 witness commitment is.
 104 | +
 105 | +A SegData commitment output scriptPubKey is exactly 42 bytes: `6a2864617430` followed by the 32-byte commitment hash and 4-byte region length, with no trailing data. If more than one coinbase output matches this form, the one with the highest output index is the canonical SegData commitment. The others have no consensus meaning.
 106 | +
 107 | +If a block contains no SegData references in any transaction, the SegData commitment is optional and MAY be omitted. If present in such a block, it MUST commit to an empty Merkle root and declare region length zero.

murchandamus commented at 9:25 PM on August 14, 2026:

Had to read this paragraph more than once. Please explicitly reference concepts and avoid substituting pronouns.

If a block contains no SegData references in any transaction, the SegData commitment is optional and MAY be omitted. If a SegData commitment is present in a block without SegData references, it MUST commit to an empty Merkle root and declare region length zero.

 113 | +A transaction MAY include one or more SegData references. A reference is encoded as a 36-byte witness-v2 program, the same 4-byte marker + 32-byte hash as encoded in the commitment:
 114 | +
 115 | +```
 116 | +scriptPubKey: OP_2 OP_PUSHBYTES_36 <4-byte marker> <32-byte SegData entry hash>
 117 | +value:        0 (consensus-required)
 118 | +```

murchandamus commented at 9:30 PM on August 14, 2026:

Shouldn’t the SegData reference also readably commit to the SegData’s specific length? That way nodes could sum the lengths mentioned in the reference outputs and compare that to the SegData commitment length. Otherwise, a miner could mine a block in which it collects many transactions with SegData references, collecting their fees, underreporting their total weight, and it would be an acceptable block to all nodes that don’t carry SegData.

By committing to the length of the SegData in the SegData reference, the senders would sign the length, and the miner would not be able to underreport. While the SegData itself is not consensus relevant, its reported length is consensus relevant and relevant for comparing feerates of transactions.

 128 | +
 129 | +The matching reference and commitment pattern gives the protocol one identifying byte sequence at both layers. The marker selects the cryptographic suite defined by this BIP. A future BIP revising that suite would define a successor marker (`dat1`, `dat2`, and so on).
 130 | +
 131 | +The reference output is unspendable by consensus, MUST have value zero, and is excluded from the UTXO set (validation rule 4), so references do not contribute to chainstate growth. Its only purpose is to anchor the entry's identity in the transaction. Because value zero falls below the dust threshold, relaying a reference output requires a standardness exemption, specified in the companion peer-services BIP.
 132 | +
 133 | +A transaction MAY include multiple SegData reference outputs.

murchandamus commented at 9:31 PM on August 14, 2026:

Repeat of line 113.

 136 | +
 137 | +### Script isolation
 138 | +
 139 | +SegData is a pure-data write-only layer where entries are byte strings that exist solely to be committed and retrieved, never interpreted. The protocol's only handle on a SegData entry is its 32-byte tagged entry hash, which appears in the SegData reference scriptPubKey and in the SegData Merkle commitment. The hash itself is accessible to script like any other byte sequence in scriptPubKey, whereas the entry bytes it commits to are not.
 140 | +
 141 | +SegData entries MUST NOT be accessible to script execution. No present or future opcode may read, inspect, branch on, or otherwise depend on the contents of a SegData entry (§Why script isolation is a permanent invariant).

murchandamus commented at 9:34 PM on August 14, 2026:

As mentioned in the other document, please link to the referenced sections instead of using these § references.

 151 | +```
 152 | +base     = [header][tx_count: varint][tx_1]...[tx_n]
 153 | +tx_i     = transaction serialised per BIP-144 (with inline witness data if any)
 154 | +extended = [base][segdata]
 155 | +segdata  = [count: varint][entry_1][entry_2]...[entry_m]
 156 | +entry    = [length: varint][bytes: length]

murchandamus commented at 9:48 PM on August 14, 2026:

This presentation is ambiguous. When I first looked at it, it wasn’t clear to me whether the SegData entries follow their transaction inline or the SegData region is a separate section in the block until I read the next paragraph. Perhaps you could split the two block serializations into two separate blocks.

 165 | +
 166 | +A single canonical order governs both the layout of the `segdata` region and the leaves of the commitment Merkle tree. SegData entries are ordered by:
 167 | +
 168 | +1. Block-order of the first transaction containing a reference to the entry.
 169 | +2. Within a transaction, by output index of the SegData reference.
 170 | +3. If the same entry is referenced within or across transactions multiple times, it appears once at its first-referenced position.

murchandamus commented at 9:51 PM on August 14, 2026:

Why would anyone want to put the same data more than once? Is this really a use case that needs to be special-cased? Only the Merkle root makes it into the block, anyway.

 217 | +| Payload | SegData | Witness Commit+Reveal | Saving | Saving % |
 218 | +|----|----|----|----|----|
 219 | +| 256 B | ~737 WU (184 vB) | ~1,210 WU (303 vB) | ~473 WU (118 vB) | ~39% |
 220 | +| 1 KB | ~1,121 WU (280 vB) | ~1,996 WU (499 vB) | ~875 WU (219 vB) | ~44% |
 221 | +| 10 KB | ~5,729 WU (1,432 vB) | ~11,266 WU (2,817 vB) | ~5,537 WU (1,384 vB) | ~49% |
 222 | +| 100 KB | ~51,809 WU (12,952 vB) | ~103,960 WU (25,990 vB) | ~52,151 WU (13,038 vB) | ~50% |

murchandamus commented at 10:14 PM on August 14, 2026:

I’m confused by the values in these tables. If the payload is N = 256 B, priced at r = 1, and the per-payload cost is r × N + 188 WU, how is that not 1 × 256 + 188 = 444 WU = 111 vB`?

The column for Witness Commit+Reveal also seems wrong.

 223 | +
 224 | +### Validation rules (consensus)
 225 | +
 226 | +A block is valid only if:
 227 | +
 228 | +1. If any transaction contains a SegData reference output, the coinbase MUST contain at least one matching SegData commitment output. The canonical commitment is the matching output with the highest output index; any other matching outputs have no consensus meaning.

murchandamus commented at 10:14 PM on August 14, 2026:

Is there a reason to allow more than one commitment output?

 224 | +### Validation rules (consensus)
 225 | +
 226 | +A block is valid only if:
 227 | +
 228 | +1. If any transaction contains a SegData reference output, the coinbase MUST contain at least one matching SegData commitment output. The canonical commitment is the matching output with the highest output index; any other matching outputs have no consensus meaning.
 229 | +2. The commitment hash in the canonical SegData commitment MUST equal `tagged_hash("SegData/commitment", SegData Merkle root)`, where the Merkle root is computed over the 32-byte entry hashes carried in the block's SegData reference outputs, in canonical order. The leaves are the reference-output hashes, so this is checkable from the block's transactions alone, and it binds the commitment to the manifest the transactions declare.

murchandamus commented at 10:16 PM on August 14, 2026:

I’m not sure why we are introducing the term “canonical order”. As far as I understand it’s simply in the order of appearance in the block.

 226 | +A block is valid only if:
 227 | +
 228 | +1. If any transaction contains a SegData reference output, the coinbase MUST contain at least one matching SegData commitment output. The canonical commitment is the matching output with the highest output index; any other matching outputs have no consensus meaning.
 229 | +2. The commitment hash in the canonical SegData commitment MUST equal `tagged_hash("SegData/commitment", SegData Merkle root)`, where the Merkle root is computed over the 32-byte entry hashes carried in the block's SegData reference outputs, in canonical order. The leaves are the reference-output hashes, so this is checkable from the block's transactions alone, and it binds the commitment to the manifest the transactions declare.
 230 | +3. A SegData reference output MUST have value zero (0). A transaction containing a SegData reference output with non-zero value is invalid.
 231 | +4. A transaction spending a SegData reference output is invalid. Being unspendable and value zero, such outputs MUST NOT be added to the UTXO set, receiving the same treatment as OP_RETURN outputs so that data carriage adds no UTXO-set entries.

murchandamus commented at 10:19 PM on August 14, 2026:

This rule is unnecessary. The UTXO set is an abstraction used by Bitcoin Core that is not used by all Bitcoin implementations. It follows from the output being unspendable that it can be omitted from the UTXO set, not vice versa.

 229 | +2. The commitment hash in the canonical SegData commitment MUST equal `tagged_hash("SegData/commitment", SegData Merkle root)`, where the Merkle root is computed over the 32-byte entry hashes carried in the block's SegData reference outputs, in canonical order. The leaves are the reference-output hashes, so this is checkable from the block's transactions alone, and it binds the commitment to the manifest the transactions declare.
 230 | +3. A SegData reference output MUST have value zero (0). A transaction containing a SegData reference output with non-zero value is invalid.
 231 | +4. A transaction spending a SegData reference output is invalid. Being unspendable and value zero, such outputs MUST NOT be added to the UTXO set, receiving the same treatment as OP_RETURN outputs so that data carriage adds no UTXO-set entries.
 232 | +5. If no transaction in the block contains a SegData reference output, the SegData commitment output (if present) MUST commit to the empty Merkle root and a region length of zero.
 233 | +6. The block weight, computed with the SegData region length committed in the coinbase (§Weight accounting), MUST NOT exceed the block weight limit (`MAX_BLOCK_WEIGHT`).
 234 | +7. The SegData region length committed in the coinbase MUST NOT exceed `MAX_SEGDATA_REGION_LENGTH`, defined as `MAX_BLOCK_WEIGHT` less the 32-byte block hash a `segdata` message prepends. It is chosen so the region plus its 32-byte wire prefix stays within the peer-to-peer message limit, and that holds at every block weight, since the message limit already tracks `MAX_BLOCK_WEIGHT` so ordinary blocks relay. The whole region therefore always fits a single relay message. The committed region length is a byte count and `MAX_BLOCK_WEIGHT` is a weight in weight units, so the comparison is against the numeric value of `MAX_BLOCK_WEIGHT`. The region's own weight contribution is `r` times its byte length (§Weight accounting) and is bounded separately by rule 6.

murchandamus commented at 10:26 PM on August 14, 2026:

I don’t understand this rule. If r = 1, it is obsolete, because rule 6 already limits it more strictly. If 0 < r < 1, the total block size with SegData region could approach twice the block weight.

 231 | +4. A transaction spending a SegData reference output is invalid. Being unspendable and value zero, such outputs MUST NOT be added to the UTXO set, receiving the same treatment as OP_RETURN outputs so that data carriage adds no UTXO-set entries.
 232 | +5. If no transaction in the block contains a SegData reference output, the SegData commitment output (if present) MUST commit to the empty Merkle root and a region length of zero.
 233 | +6. The block weight, computed with the SegData region length committed in the coinbase (§Weight accounting), MUST NOT exceed the block weight limit (`MAX_BLOCK_WEIGHT`).
 234 | +7. The SegData region length committed in the coinbase MUST NOT exceed `MAX_SEGDATA_REGION_LENGTH`, defined as `MAX_BLOCK_WEIGHT` less the 32-byte block hash a `segdata` message prepends. It is chosen so the region plus its 32-byte wire prefix stays within the peer-to-peer message limit, and that holds at every block weight, since the message limit already tracks `MAX_BLOCK_WEIGHT` so ordinary blocks relay. The whole region therefore always fits a single relay message. The committed region length is a byte count and `MAX_BLOCK_WEIGHT` is a weight in weight units, so the comparison is against the numeric value of `MAX_BLOCK_WEIGHT`. The region's own weight contribution is `r` times its byte length (§Weight accounting) and is bounded separately by rule 6.
 235 | +
 236 | +No rule above needs the `segdata` region (§Uniform validation). The region itself is governed by relay policy, not consensus. That each referenced entry is present and hashes to its leaf, that the region carries no unreferenced entries, that it is canonically encoded, and that its byte length equals the committed length, are checks a node applies when it receives the region, as a condition of relaying and building on the block, not of the block's validity. They are specified in the companion peer-services BIP (§Region validation).

murchandamus commented at 10:30 PM on August 14, 2026:

Still don’t think this has anything to do with “relay policy”. At this point, I’d characterize it as an opt-in extension block.

 264 | +| `min_activation_height` | TBD (start + 18 months) |
 265 | +| `lockinontimeout` | TBD (§Open Questions) |
 266 | +
 267 | +Pre-activation, any output matching the SegData reference encoding (witness-v2 with a 36-byte program whose first 4 bytes are `0x64617430`) is treated as anyone-can-spend per BIP-141 §Witness program. Post-activation, such outputs become unspendable per this BIP's validation rules.
 268 | +
 269 | +At the activation height, any unspent output matching the encoding is removed from the UTXO set, the treatment rule 4 prescribes for outputs created after activation. This keeps chainstate contents, and therefore UTXO-set hashes, implementation-independent. Any value carried becomes permanently unspendable, as rule 4 already implies. The `dat0` marker makes accidental matches improbable and value-zero outputs are nonstandard pre-activation, so this set is expected to be empty.

murchandamus commented at 10:33 PM on August 14, 2026:

I have to think more about that, but activation modifying the UTXO set seems problematic to me, e.g., Utreexo doesn’t actively track the UTXO set.

 287 | +
 288 | +### Why "honest" is a technical term
 289 | +
 290 | +§Motivation describes SegData as letting data be carried "honestly". The term is technical, not moral. It refers to the transparency of the encoding. A SegData reference declares its bytes as a data payload, so an operator can recognise them and exercise a retention choice, and the network can differentiate declared data from monetary use. Data placed in witness envelopes or vanity addresses is opaque only in the narrow sense that it presents itself as a script or a key rather than as the data it is. This says nothing about whether the content is legitimate or should exist, only whether the carriage discloses what it is.
 291 | +
 292 | +### Why entry integrity is relay policy

murchandamus commented at 10:39 PM on August 14, 2026:

Relay policy refers to mempool acceptance rules and rules governing the relay of unconfirmed transactions. This proposal is talking about retention and relay of transaction parts as well as block data, before and after confirmation. Therefore, relay policy strikes me as an odd term in this context.

 309 | +
 310 | +### Why selective retention is not censorship
 311 | +
 312 | +Censorship would mean preventing publication, or erasing what was published. SegData does neither. What goes into a block is still chosen by miners and priced by fees, exactly as today. No consensus rule reads an entry's contents, and once a block is mined its commitment is permanent for every node. Choosing not to retain an entry does not remove it from the chain or stop it being included.
 313 | +
 314 | +What selective retention affects is availability, not the record. A node keeps SegData by default, as it does witness today, and its operator may now decline to host a copy, which the protocol never required anyway, since pruned nodes already discard block data. An entry may then end up with fewer copies than witness produces, but the availability floor is unchanged: one surviving copy, held by anyone anywhere, remains distributable and verifiable against the permanent commitment.

murchandamus commented at 10:44 PM on August 14, 2026:

A node keeps SegData by default, as it does witness today

You spend a lot of time establishing above that SegData is not consensus relevant. Default behavior of nodes regarding optional features is an implementation detail. Making claims about default behavior detracts from this document.

 108 | +
 109 | +SegData adds only this coinbase output, leaving the coinbase input witness and its BIP-141 reserved value unchanged. The SegData (40-byte) and BIP-141 witness commitments (36-byte) are distinct OP_RETURN outputs, further distinguished by their unique 4-byte markers, so each is detected and selected independently and a coinbase MAY carry both without ambiguity.
 110 | +
 111 | +### SegData reference in transactions
 112 | +
 113 | +A transaction MAY include one or more SegData references. A reference is encoded as a 36-byte witness-v2 program, the same 4-byte marker + 32-byte hash as encoded in the commitment:

murchandamus commented at 10:51 PM on August 14, 2026:

Why witness-v2 instead of v1?

 369 | +
 370 | +Existing transactions, address formats, and non-SegData-aware wallet software are unaffected. UTXO-set handling changes for exactly one output class and reference outputs are never added to the set (validation rule 4). All other outputs, including non-matching witness-v2 outputs, are handled as today.
 371 | +
 372 | +Block weight remains derivable for software outside the node. Although the `segdata` region is absent from the base serialisation, the SegData commitment carries the region byte length, so any holder of the base bytes computes a block's full weight from a proof-of-work-committed field without fetching the region.
 373 | +
 374 | +Per-transaction weight is a new break. BIP-141 kept the witness inside the transaction, so a transaction stayed computable from its own bytes. SegData puts the entry bytes outside the transaction, so a SegData transaction's weight, and therefore its feerate, needs the entry sizes and their attribution from a node (§Reference Implementation item 4). Committing the length in each reference (§Open Questions) would remove this break for SegData-aware software.

murchandamus commented at 10:55 PM on August 14, 2026:

I see, that answers my question from above. This of course means that anyone wanting to mine SegData transactions would need to participate in relay of SegData.

I still think that it would be more reliable if the references committed to the weight, as then even upgraded nodes that opt out of retention of SegData would be able to enforce the consensus rules. Otherwise, a miner lying about the size of the segdata could split the opt-out nodes from the opt-in nodes.

 380 | +1. Block validation changes: commitment-output detection, canonical-commitment selection, and reference-output validation (value, unspendability, and Merkle-root match). The `segdata` region itself is not parsed by consensus (§Uniform validation); region receipt and matching is a peer-services concern.
 381 | +2. Weight-accounting changes: per the extended formula in §Weight accounting.
 382 | +3. Storage layer changes: per-entry addressable `segdata` storage with a single allocation parameter, following the `-prune` idiom: the default retains everything, as unpruned block storage does, and the parameter opts into less. Storage MAY deduplicate identical entries across blocks, since each block's canonical entry list is derivable from its reference outputs and reconstructs the region from a content-addressed store exactly.
 383 | +4. RPC interface: inspection of retained entries, plus a manual `prunesegdata` call discarding a block's `segdata` or a single entry within it, refusing targets the node is committed to serve under its retention policy, as `pruneblockchain` refuses heights inside the pruned-node minimum. Selective retention policy thereby lives in external tooling driving this RPC, not in the node. Block and mempool reporting exposes weight with and without the SegData term: the full consensus weight, the three-term BIP-141 weight byte-holding tooling can still derive and cross-check, and the SegData component per block and per transaction (attributed entry weight). This keeps weight statistics comparable across activation and makes each block's data-carriage share directly observable.
 384 | +
 385 | +P2P propagation, service-bit advertising, request/response messages for SegData entries, and operator-policy retention mechanics belong to the companion peer-services BIP.

murchandamus commented at 10:59 PM on August 14, 2026:

Seems out of place for a consensus BIP.

 424 | +
 425 | +10. **Selective inclusion and class filtering.**
 426 | +  - *Risk*: the explicit `dat0` marker makes SegData references trivially identifiable, so a miner, a relay policy, or a regulator mandating one can filter the entire class by pattern match, with no content inspection. This is cheaper than identifying data hidden in witness envelopes or key fields, so SegData marginally lowers the cost of class-level filtering.
 427 | +  - *Mitigation*: inclusion is the ordinary censorship-resistance problem. A fee-paying SegData transaction is profit for whoever mines it, so durable exclusion requires majority hashrate and otherwise only delays confirmation, exactly as for any transaction. Relay-layer filtering impedes propagation but is trivially routed around. The same transparency that eases filtering is what makes SegData sheddable, and declining to *retain* an entry, unlike declining to mine it, is not censorship at all.
 428 | +
 429 | +The above are non-exhaustive. Community review is expected to surface additional considerations.

murchandamus commented at 11:07 PM on August 14, 2026:

As mentioned above, lying about the size of the SegData in the commitment would be a vector to split the network which should be addressed