* [bitcoindev] segOP potential BIP discussion
@ 2025-10-29 23:40 defenwycke
2025-10-30 21:25 ` [bitcoindev] " defenwycke
0 siblings, 1 reply; 3+ messages in thread
From: defenwycke @ 2025-10-29 23:40 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 13060 bytes --]
Hi all,
I attempted to propose a BIP earlier today. I was notified of my incorrect
actions versus core procedures.
See attached or below - my proposal for discussion.
Regards
Defenwycke.
---
A proposed discussion of segOP
Author: Defenwycke / defenwycke@icloud.com
29.10.2025
segOP (Segregated OP_RETURN)
A proposed extension to Bitcoin transactions. It introduces a
dedicated, structured, full-fee data lane for on-chain data, without
disrupting existing transaction rules. Think of it like this - segOP is to
arbitrary data what SegWit was to signatures — a clean, isolated,
forward-compatible path that preserves old-node harmony while restoring fee
fairness.
Abstract:
segOP defines a new segregated data section for Bitcoin transactions,
cryptographically committed via OP_SUCCESS184. It standardizes on-chain
metadata storage by enforcing full fees, structured TLV encoding, and a 100
KB cap, while remaining backward-compatible with legacy nodes.
It is not:
- A replacement for OP_RETURN
- An off-chain mechanism
- A hard fork
It is:
- A soft-fork-safe, future-proof, SegWit-style data section
- Full-fee (4 weight units per byte)
- Structured (TLV + Merkle-root verified)
- Limited to 100 KB per transaction
What issues could segOP rectify?:
1. Ordinals abuse witness discount. segOP will apply full fee rate for
large data.
2. No structured metadata lane. segOP introduces TLV-encoded +
Merkle-verified section.
3. Witness discount abused for megabytes. segOP Enforces 100 KB cap.
4. OP_RETURN unstructured & limited. segOP = structured + verifiable.
5. Spam cheap storage. segOP deters spam with fees.
In short - segOP restores fairness — data pays its real weight cost,
preserving block space for financial use.
Where segOP lives:
Transaction Layout (Post-segOP)
Transaction
├── nVersion
├── vin (inputs)
├── vout (outputs)
│ └── P2SOP Output ← segOP anchor
├── witness (if any)
├── segOP marker (0xFA)
├── segOP section (if present)
│ ├── chunk_count (varint)
│ ├── TLV chunk 1
│ ├── TLV chunk 2
│ └── ...
└── nLockTime
Activation rules:
- segOP section only appears if at least one P2SOP output exists.
- Old nodes ignore unknown post-witness data → transaction valid
(soft-fork safe).
- New nodes validate the segOP section against the Merkle root in the
P2SOP output.
How segOP works:
segOP extends the Bitcoin transaction format by adding a new optional
section after the witness field.
This section is linked cryptographically to a special output type — the
P2SOP output — whose script commits to the Merkle root of the segOP data.
The design mirrors SegWit: a segregated data structure, excluded from
txid but included in wtxid, ensuring backward compatibility.
1. Transaction Creation
When a wallet or protocol wants to include on-chain structured
data (for example, a document hash, timestamp, or proof set), it performs
the following steps:
a. Build TLV Chunks
Each data element is encoded in Type-Length-Value (TLV)
format:
- type (varint)
- length (varint)
- value (bytes)
Each type defines a data meaning (e.g., type=1:
manifest, type=2: payload, type=3: metadata, etc.). This allows future
extensions without breaking parsers.
b. Construct the Merkle Tree
Each TLV is hashed as:
leaf = dsha256(0x00 || TLV)
and combined recursively:
node = dsha256(0x01 || left || right)
until a single Merkle root is produced. This root
uniquely commits to all TLV data while allowing compact partial proofs.
c. Commit to the Root (P2SOP Output)
The wallet then inserts a special output into the
transaction: scriptPubKey = OP_SUCCESS184 0x20 <32-byte Merkle root>
(OP_SUCCESS184 is reserved for soft-fork activation).
Legacy nodes treat it as “always true,” so the
transaction remains spendable under pre-segOP rules.
The 32-byte push commits to the root of the segOP
section.
Multiple P2SOP outputs may exist if a transaction
carries multiple data trees, but each must be validated independently.
d. Serialize the segOP Section
After the witness data, a segOP marker (0xFA) signals
presence, followed by the serialized data:
0xFA
varint: chunk_count
[TLV #1]
[TLV #2]
...
This section is included in the wtxid but not the txid,
keeping legacy hashes unchanged (soft-fork compatible).
2. Transaction Relay and Policy
segOP transactions are relayed like any other, with a few
policy rules:
- Size limit: The total size of segOP data (plus OP_RETURN
+ witness data >520 B) must not exceed 100,000 bytes. This prevents block
bloat.
- Fee treatment: segOP data counts at 4 weight units per
byte (no discount), restoring parity between data and signatures.
- Standardness check: Non-mining nodes enforce segOP as a
standard policy rule (like SegWit’s P2WSH), rejecting noncompliant data
from mempool relay.
These are policy rules, not consensus, but miners enforcing
them makes segOP behavior uniform across the network.
3. Validation (Node-Level)
When a segOP transaction reaches a full node, validation
happens in three stages:
a. Detect segOP Presence
- If any output script begins with OP_SUCCESS184, the
node checks for a corresponding segOP section at the end of the transaction
serialization.
- If no segOP section is found → transaction invalid
under segOP rules.
b. Verify Size and Fee
The node computes total data size:
- All OP_RETURN payloads
- All segOP TLVs
- All witness items >520 bytes (these count as
“data”)
- If this exceeds 100 KB, the transaction is
invalid.
- The total weight is adjusted to include all segOP
bytes at full cost.
c. Verify Merkle Root
- The node rebuilds the TLV Merkle tree and ensures:
- calculated_root == <root in P2SOP output>
- If the root mismatches → reject.
- This makes segOP cryptographically bound to the
transaction body, just like Taproot commits to script paths.
4. Inclusion in a Block
- Miners include segOP transactions normally.
- When calculating block weight: segOP bytes count fully (4
WU/byte).
- segOP does not alter the legacy 4M weight limit but competes
fairly for space.
- Miners can optionally expose segOP data through RPC or
indexing APIs (e.g., gettxoutdata), similar to how they expose witness data.
5. Verification by Light Clients
- Because segOP uses a Merkle structure: SPV clients or oracles
can request proofs for individual TLVs without downloading full data. For
example, a timestamp verifier can request: getsegopproof <txid>
<chunk_type> and receive the TLV + Merkle proof + root verification path.
This makes segOP efficient for decentralized proof storage or timestamping
protocols.
6. Spending a P2SOP Output
- Spending a P2SOP output works like spending an OP_SUCCESS
output: Until activation, it behaves as anyone-can-spend, ensuring
soft-fork safety. After activation, future consensus rules can restrict or
redefine P2SOP redemption scripts.
- Example forward path: A future BIP may define OP_SUCCESS184
redemption to require proof of segOP validity or special conditions (e.g.,
hash preimage commitments). Until then, nodes treat these outputs as valid
spends, ensuring no forks.
7. Post-Activation Behavior
- After segOP activation: All upgraded nodes enforce the 100 KB
cap and Merkle root validation.
- Legacy nodes still accept the transactions, unaware of segOP
structure.
- Any mismatch between segOP section and root simply makes the
tx invalid for upgraded miners — thus ensuring consensus alignment.
Examples of segOP:
Example 1: Timestamp a Document (50 KB)
TLV #1: Type = 1, Manifest (JSON)
TLV #2: Type = 2, PDF payload (50 KB)
Build Merkle root → abc123...
Create output:
OP_SUCCESS184 0x20 abc123...
segOP section:
0x02 # chunk count
<TLV1> <TLV2>
Fee: ≈ $30 at current full-fee rates
Permanent, verifiable, structured.
Example 2: Ordinals Tries 3.8 MB
data_size = 3.8 MB → REJECTED (exceeds 100 KB cap)
Attempt in witness → REJECTED (data > 520 B → full fee policy → cap
still enforced)
Example 3: Normal BTC Send
No P2SOP output : No segOP section
Fee Unchanged (~$0.09)
Normal transactions unaffected.
How to Use segOP:
Build a segOP Transaction (Python)
# 1. Prepare TLV chunks
manifest = b'{"type":"proof","size":50000}'
payload = b'50 KB of data...'
tlv1 = varint(1) + varint(len(manifest)) + manifest
tlv2 = varint(2) + varint(len(payload)) + payload
# 2. Build Merkle root
def dsha256(x): return sha256(sha256(x)).digest()
leaf1 = dsha256(b'\x00' + tlv1)
leaf2 = dsha256(b'\x00' + tlv2)
root = dsha256(b'\x01' + leaf1 + leaf2)
# 3. Create P2SOP output
p2sop = b'\xb8\x20' + root
# 4. Build segOP section
segop = b'\xFA' + varint(2) + tlv1 + tlv2 # 0xFA marker
# 5. Attach to tx
tx.vout.append(CTxOut(0, CScript(p2sop)))
tx.segop_section = segop
Validation Logic (C++ Pseudocode):
bool CheckSegOP(const CTransaction& tx) {
size_t total_data = 0;
for (const auto& out : tx.vout) {
if (out.scriptPubKey[0] == OP_SUCCESS184) {
// segOP output detected
if (!tx.HasSegOPSection()) return false;
total_data += tx.segOPSectionSize();
}
if (out.scriptPubKey[0] == OP_RETURN &&
out.scriptPubKey.size() > 1) {
total_data += out.scriptPubKey.size() - 1;
}
}
for (const auto& in : tx.vin) {
for (const auto& item : in.scriptWitness.stack) {
if (item.size() > 520)
total_data += item.size(); // witness data counts
fully
}
}
if (total_data > 100000) return false; // 100 KB consensus cap
// Apply full weight to data for fee calc
tx.virtual_size += total_data;
return true;
}
Soft Fork Proof:
- Old node: Ignores segOP
- New node: Validates segOP
- No chain split
- Backward compatible
- Miner-activated soft fork possible via versionbits
Developer Q&A:
Where is segOP serialized? : After witness, before nLockTime
Does it affect txid? : No - only wtxid
Can old nodes parse it? : Yes (ignored like witness)
Max size? : 100 KB total data
Fee rate? : Full fee (4 WU/byte)
Can I use OP_RETURN too? : Yes — total combined data ≤ 100 KB
Future extensions? : TLV unknown types ignored (safe forward-compat)
How do I signal presence? : 0xFA marker after witness
Conclusion:
- On-chain
- Structured (TLV + Merkle)
- Full-fee and fair
- Soft-fork safe
- Future-proof
segOP introduces the clean, capped, verifiable data lane Bitcoin needs
— ending witness discount abuse while preserving freedom for legitimate
metadata.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c38d00f7-a42b-4f7b-899e-11e823a43d7dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 57496 bytes --]
[-- Attachment #2: A proposed discussion of segOP.txt --]
[-- Type: text/plain, Size: 12339 bytes --]
A proposed discussion of segOP
Author: Defenwycke / defenwycke@icloud.com
29.10.2025
segOP (Segregated OP_RETURN)
A proposed extension to Bitcoin transactions. It introduces a dedicated, structured, full-fee data lane for on-chain data, without disrupting existing transaction rules. Think of it like this - segOP is to arbitrary data what SegWit was to signatures — a clean, isolated, forward-compatible path that preserves old-node harmony while restoring fee fairness.
Abstract:
segOP defines a new segregated data section for Bitcoin transactions, cryptographically committed via OP_SUCCESS184. It standardizes on-chain metadata storage by enforcing full fees, structured TLV encoding, and a 100 KB cap, while remaining backward-compatible with legacy nodes.
It is not:
- A replacement for OP_RETURN
- An off-chain mechanism
- A hard fork
It is:
- A soft-fork-safe, future-proof, SegWit-style data section
- Full-fee (4 weight units per byte)
- Structured (TLV + Merkle-root verified)
- Limited to 100 KB per transaction
What issues could segOP rectify?:
1. Ordinals abuse witness discount. segOP will apply full fee rate for large data.
2. No structured metadata lane. segOP introduces TLV-encoded + Merkle-verified section.
3. Witness discount abused for megabytes. segOP Enforces 100 KB cap.
4. OP_RETURN unstructured & limited. segOP = structured + verifiable.
5. Spam cheap storage. segOP deters spam with fees.
In short - segOP restores fairness — data pays its real weight cost, preserving block space for financial use.
Where segOP lives:
Transaction Layout (Post-segOP)
Transaction
├── nVersion
├── vin (inputs)
├── vout (outputs)
│ └── P2SOP Output ← segOP anchor
├── witness (if any)
├── segOP marker (0xFA)
├── segOP section (if present)
│ ├── chunk_count (varint)
│ ├── TLV chunk 1
│ ├── TLV chunk 2
│ └── ...
└── nLockTime
Activation rules:
- segOP section only appears if at least one P2SOP output exists.
- Old nodes ignore unknown post-witness data → transaction valid (soft-fork safe).
- New nodes validate the segOP section against the Merkle root in the P2SOP output.
How segOP works:
segOP extends the Bitcoin transaction format by adding a new optional section after the witness field.
This section is linked cryptographically to a special output type — the P2SOP output — whose script commits to the Merkle root of the segOP data.
The design mirrors SegWit: a segregated data structure, excluded from txid but included in wtxid, ensuring backward compatibility.
1. Transaction Creation
When a wallet or protocol wants to include on-chain structured data (for example, a document hash, timestamp, or proof set), it performs the following steps:
a. Build TLV Chunks
Each data element is encoded in Type-Length-Value (TLV) format:
- type (varint)
- length (varint)
- value (bytes)
Each type defines a data meaning (e.g., type=1: manifest, type=2: payload, type=3: metadata, etc.). This allows future extensions without breaking parsers.
b. Construct the Merkle Tree
Each TLV is hashed as:
leaf = dsha256(0x00 || TLV)
and combined recursively:
node = dsha256(0x01 || left || right)
until a single Merkle root is produced. This root uniquely commits to all TLV data while allowing compact partial proofs.
c. Commit to the Root (P2SOP Output)
The wallet then inserts a special output into the transaction: scriptPubKey = OP_SUCCESS184 0x20 <32-byte Merkle root> (OP_SUCCESS184 is reserved for soft-fork activation).
Legacy nodes treat it as “always true,” so the transaction remains spendable under pre-segOP rules.
The 32-byte push commits to the root of the segOP section.
Multiple P2SOP outputs may exist if a transaction carries multiple data trees, but each must be validated independently.
d. Serialize the segOP Section
After the witness data, a segOP marker (0xFA) signals presence, followed by the serialized data:
0xFA
varint: chunk_count
[TLV #1]
[TLV #2]
...
This section is included in the wtxid but not the txid, keeping legacy hashes unchanged (soft-fork compatible).
2. Transaction Relay and Policy
segOP transactions are relayed like any other, with a few policy rules:
- Size limit: The total size of segOP data (plus OP_RETURN + witness data >520 B) must not exceed 100,000 bytes. This prevents block bloat.
- Fee treatment: segOP data counts at 4 weight units per byte (no discount), restoring parity between data and signatures.
- Standardness check: Non-mining nodes enforce segOP as a standard policy rule (like SegWit’s P2WSH), rejecting noncompliant data from mempool relay.
These are policy rules, not consensus, but miners enforcing them makes segOP behavior uniform across the network.
3. Validation (Node-Level)
When a segOP transaction reaches a full node, validation happens in three stages:
a. Detect segOP Presence
- If any output script begins with OP_SUCCESS184, the node checks for a corresponding segOP section at the end of the transaction serialization.
- If no segOP section is found → transaction invalid under segOP rules.
b. Verify Size and Fee
The node computes total data size:
- All OP_RETURN payloads
- All segOP TLVs
- All witness items >520 bytes (these count as “data”)
- If this exceeds 100 KB, the transaction is invalid.
- The total weight is adjusted to include all segOP bytes at full cost.
c. Verify Merkle Root
- The node rebuilds the TLV Merkle tree and ensures:
- calculated_root == <root in P2SOP output>
- If the root mismatches → reject.
- This makes segOP cryptographically bound to the transaction body, just like Taproot commits to script paths.
4. Inclusion in a Block
- Miners include segOP transactions normally.
- When calculating block weight: segOP bytes count fully (4 WU/byte).
- segOP does not alter the legacy 4M weight limit but competes fairly for space.
- Miners can optionally expose segOP data through RPC or indexing APIs (e.g., gettxoutdata), similar to how they expose witness data.
5. Verification by Light Clients
- Because segOP uses a Merkle structure: SPV clients or oracles can request proofs for individual TLVs without downloading full data. For example, a timestamp verifier can request: getsegopproof <txid> <chunk_type> and receive the TLV + Merkle proof + root verification path. This makes segOP efficient for decentralized proof storage or timestamping protocols.
6. Spending a P2SOP Output
- Spending a P2SOP output works like spending an OP_SUCCESS output: Until activation, it behaves as anyone-can-spend, ensuring soft-fork safety. After activation, future consensus rules can restrict or redefine P2SOP redemption scripts.
- Example forward path: A future BIP may define OP_SUCCESS184 redemption to require proof of segOP validity or special conditions (e.g., hash preimage commitments). Until then, nodes treat these outputs as valid spends, ensuring no forks.
7. Post-Activation Behavior
- After segOP activation: All upgraded nodes enforce the 100 KB cap and Merkle root validation.
- Legacy nodes still accept the transactions, unaware of segOP structure.
- Any mismatch between segOP section and root simply makes the tx invalid for upgraded miners — thus ensuring consensus alignment.
Examples of segOP:
Example 1: Timestamp a Document (50 KB)
TLV #1: Type = 1, Manifest (JSON)
TLV #2: Type = 2, PDF payload (50 KB)
Build Merkle root → abc123...
Create output:
OP_SUCCESS184 0x20 abc123...
segOP section:
0x02 # chunk count
<TLV1> <TLV2>
Fee: ≈ $30 at current full-fee rates
Permanent, verifiable, structured.
Example 2: Ordinals Tries 3.8 MB
data_size = 3.8 MB → REJECTED (exceeds 100 KB cap)
Attempt in witness → REJECTED (data > 520 B → full fee policy → cap still enforced)
Example 3: Normal BTC Send
No P2SOP output : No segOP section
Fee Unchanged (~$0.09)
Normal transactions unaffected.
How to Use segOP:
Build a segOP Transaction (Python)
# 1. Prepare TLV chunks
manifest = b'{"type":"proof","size":50000}'
payload = b'50 KB of data...'
tlv1 = varint(1) + varint(len(manifest)) + manifest
tlv2 = varint(2) + varint(len(payload)) + payload
# 2. Build Merkle root
def dsha256(x): return sha256(sha256(x)).digest()
leaf1 = dsha256(b'\x00' + tlv1)
leaf2 = dsha256(b'\x00' + tlv2)
root = dsha256(b'\x01' + leaf1 + leaf2)
# 3. Create P2SOP output
p2sop = b'\xb8\x20' + root
# 4. Build segOP section
segop = b'\xFA' + varint(2) + tlv1 + tlv2 # 0xFA marker
# 5. Attach to tx
tx.vout.append(CTxOut(0, CScript(p2sop)))
tx.segop_section = segop
Validation Logic (C++ Pseudocode):
bool CheckSegOP(const CTransaction& tx) {
size_t total_data = 0;
for (const auto& out : tx.vout) {
if (out.scriptPubKey[0] == OP_SUCCESS184) {
// segOP output detected
if (!tx.HasSegOPSection()) return false;
total_data += tx.segOPSectionSize();
}
if (out.scriptPubKey[0] == OP_RETURN && out.scriptPubKey.size() > 1) {
total_data += out.scriptPubKey.size() - 1;
}
}
for (const auto& in : tx.vin) {
for (const auto& item : in.scriptWitness.stack) {
if (item.size() > 520)
total_data += item.size(); // witness data counts fully
}
}
if (total_data > 100000) return false; // 100 KB consensus cap
// Apply full weight to data for fee calc
tx.virtual_size += total_data;
return true;
}
Soft Fork Proof:
- Old node: Ignores segOP
- New node: Validates segOP
- No chain split
- Backward compatible
- Miner-activated soft fork possible via versionbits
Developer Q&A:
Where is segOP serialized? : After witness, before nLockTime
Does it affect txid? : No - only wtxid
Can old nodes parse it? : Yes (ignored like witness)
Max size? : 100 KB total data
Fee rate? : Full fee (4 WU/byte)
Can I use OP_RETURN too? : Yes — total combined data ≤ 100 KB
Future extensions? : TLV unknown types ignored (safe forward-compat)
How do I signal presence? : 0xFA marker after witness
Conclusion:
- On-chain
- Structured (TLV + Merkle)
- Full-fee and fair
- Soft-fork safe
- Future-proof
segOP introduces the clean, capped, verifiable data lane Bitcoin needs — ending witness discount abuse while preserving freedom for legitimate metadata.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] Re: segOP potential BIP discussion
2025-10-29 23:40 [bitcoindev] segOP potential BIP discussion defenwycke
@ 2025-10-30 21:25 ` defenwycke
2025-11-01 12:00 ` 'moonsettler' via Bitcoin Development Mailing List
0 siblings, 1 reply; 3+ messages in thread
From: defenwycke @ 2025-10-30 21:25 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 33450 bytes --]
Hi all,
I thought more about this today. Please see update below. Open to ideas and
discussion.
KR
Defenwycke
# segOP : Segregated OP_RETURN # A Structured and Fee-Fair Data Extension
for Bitcoin ## Technical Paper — October 2025 ## Author : Defenwycke ##
Abstract Bitcoin’s four-million-weight-unit block limit was meant to price
blockspace fairly, yet Segregated Witness introduced an asymmetry: witness
bytes cost one weight unit while base bytes cost four. That
discount—intended for signatures—has become a subsidy for arbitrary data.
Large image and metadata “inscriptions” now fill much of each block while
paying a fraction of what monetary transactions pay. The result is a
distorted fee market: blocks remain full but miners earn less and real
users queue longer. segOP (Segregated OP_RETURN) restores balance without a
hard fork. It defines a structured, priced data lane inside the
transaction—full fee rate, capped at 100 KB, TLV-encoded and
Merkle-verifiable. Each payload pays the same 4 WU per byte as ordinary
transaction data. Economic modelling shows miner revenue roughly doubling
and genuine payment throughput increasing about 75 %, while spam falls
naturally. The proposal is soft-fork safe, easily pruned, and backward
compatible. ## 1 Introduction ### 1.1 Why This Matters Bitcoin’s strength
lies in simplicity: every byte competes equally for limited space. Since
2017, witness discounting has broken that symmetry. A 1 MB batch of
signatures or data in the witness section now costs only ¼ of what it would
in the base section. That imbalance has turned the witness into a
subsidised data store. Ordinary users fund cheap on-chain storage for
unrelated content, miners lose fees, and block propagation slows. ### 1.2
Goal of segOP segOP re-introduces equal pricing. It doesn’t forbid data; it
merely isolates and meters it properly. Like SegWit separated signatures
for malleability reasons, segOP separates arbitrary data for economic
fairness. Every byte again pays its way. ## 2 Problem Statement ### 2.1 The
Fee Distortion | Rule | Current Value | Impact |
|----------------------|------------------|----------------------| | Block
weight limit | 4 000 000 WU | Hard cap | | Witness discount | ¼ WU / B |
Data cheap | | Max script element | 520 B | Protects validation | | UTXO
retention | Permanent | Growing state | Because witness data is so cheap,
100 KB of arbitrary content weighs 100 000 WU instead of 400 000 WU. Miners
still fill blocks to 4 M WU, but earn less; users compete against
discounted junk. The imbalance is economic, not cryptographic. ### 2.2
Consequences Fee market signal blurred — cheap spam masks real demand.
Throughput loss — genuine tx count falls ≈ 40–60 %. Revenue loss — full
blocks yield low fees. Propagation load — bigger blocks take longer to
relay. Without change, history repeats: larger chain, lower income, weaker
incentives. ## 3 Proposal — segOP (Segregated OP_RETURN) segOP introduces a
new optional section after the witness. It carries arbitrary structured
data at full cost (4 WU/B) and is capped at 100 KB per transaction.
Presence is signalled by a new flag bit (0x02). Legacy nodes ignore it;
upgraded nodes parse and charge for it. ### 3.1 Design Summary | Parameter
| Rule | Purpose |
|----------------|-------------------------|-----------------------------|
| Encoding | TLV (Type-Length-Value) | Self-describing, extensible | |
Maximum size | 100 000 B | Stops bloat | | Cost per byte | 4 WU | Restores
parity | | Witness limit | 520 B | Protects execution | | Placement | After
witness | Deterministic layout | | Compatibility | Soft-fork safe | Old
nodes ignore | ### 3.2 Why Equal Pricing Matters You can’t legislate away
spam; you fix it by removing its subsidy. segOP ends the discount, making
large data pay the same rate as payments. Abuse becomes uneconomic—no
blacklists or heuristics needed. ### 3.3 Compatibility Old nodes ignore bit
0x02. txid excludes segOP data → no malleability risk. Deployment via
version-bits or miner policy. ### 3.4 Analogy SegWit separated signatures
for security; segOP separates data for fairness. Both reduce friction
between innovation and consensus. ## 4. Economic Model segOP changes the
economics of blockspace by removing the discount that allows data to
underpay for its size. To understand its impact, we can model the block in
three parts: normal transactions, discounted data (today’s reality), and
segOP data (the proposed model). ### 4.1 Variables and Setup Let: - `Wb` =
block weight limit → 4,000,000 weight units - `Wtx` = average transaction
weight → 600 weight units - `S` = segOP payload size → 100,000 bytes -
`WsegOP` = segOP weight = 4 × S = 400,000 weight units - `f` = fee rate in
satoshis per virtual byte (sat/vB) We define the following relationships:
FsegOP = f × S T = (Wb - 400,000 × n) / Wtx Fblock = n × FsegOP + T × (f ×
150) Where: - `n` is the number of segOP payloads in a block. - `FsegOP` is
the fee paid by one segOP transaction. - `Fblock` is the total fee income
for the block. This gives a rough but useful estimate of how miner revenue
scales when blocks contain different mixes of segOP data and normal
transactions. ### 4.2 Scenario A — Current Situation (Discounted Witness
Data) In the current network, around sixty percent of block weight can be
consumed by discounted witness data. That data pays only one quarter of the
fee rate that normal bytes would, so the block fills up faster but
generates less revenue. A typical block might contain about 2,600 normal
transactions and yield around 0.006 BTC in fees. The network looks busy,
but most of the block is effectively subsidised storage. ### 4.3 Scenario B
— segOP Introduced (Full-Fee Data Lane) With segOP active, arbitrary data
still fits on-chain, but it now pays the same four weight units per byte as
everything else. Assume three segOP payloads of 100 KB each per block.
Under these conditions, the block includes roughly 4,600 normal
transactions and produces around 0.013 BTC in total fees. Miners earn more,
users see more legitimate transactions confirmed, and blockspace pricing
becomes honest again. ### 4.4 Scenario C — No Discounted Data If the
network were used purely for monetary transactions, a full block would
contain roughly 6,600 standard transactions at an average total fee of
about 0.010 BTC. This represents the upper bound for throughput but not
necessarily the most balanced use of blockspace. ### 4.5 Interpretation
Spam deterrence: Data becomes too expensive to abuse; only purposeful data
remains. Fair market: Each byte competes equally, eliminating hidden
discounts. Higher throughput: More monetary transactions per block because
junk is no longer cheap. Miner incentive: Full blocks now pay full rewards;
revenue rises naturally. Stable propagation: Blocks remain smaller and more
predictable in structure, improving relay speed. segOP doesn’t require a
new policy or central coordination—it simply restores the natural balance
of the fee market through equal pricing. ## 5 Behavioural and Economic
Implications Spam deterrence — once data costs full rate, stuffing blocks
is uneconomic. Fair market — every byte competes equally. Higher throughput
— fewer bloated transactions. Better miner income — full blocks now mean
full fees. Predictable propagation — smaller, uniform payloads reduce
latency. It’s a market fix, not a ban list. ## 6 Security and Consensus ###
6.1 Considerations segOP changes accounting, not consensus. Validation
logic stays deterministic; legacy nodes remain valid peers. | Risk |
Mitigation |
|-------------------------|------------------------------------------------|
| Soft-fork compatibility | Unrecognised flag ignored by old nodes | |
Malleability | segOP excluded from txid | | Script safety | 520 B element
limit unchanged | | Resource load | ≤ 100 KB per tx caps memory | | Replay
risk | Flag bit isolated from version | ### 6.2 Validation Flow
(pseudocode) ```python def validate_tx(tx): check_structure(tx)
check_inputs_outputs(tx) if tx.flag & 0x01: # SegWit validate_witness(tx)
for w in tx.witness: for item in w: if len(item) > 520: raise
ScriptError("witness element too large") if tx.flag & 0x02: # segOP seg =
tx.segop if seg.length > 100_000: raise PolicyError("segOP payload too
large") charge_weight(seg.length * 4) validate_tlv(seg.tlv) ``` The logic
is simple: include data, pay for data. ## 7 Implementation and Flag
Structure | Flag Bit | Meaning | Present In | Cost Model |
|-----------|---------------------|-------------|-----------------------------|
| 0x00 | Legacy (no witness) | Pre-SegWit | 4 WU/B | | 0x01 | SegWit only |
Post-2017 | 1 WU witness | | 0x02 | segOP only | Future | 4 WU segOP | |
0x03 | SegWit + segOP | Mixed | 1 WU witness + 4 WU segOP | Older software
ignores 0x02, so segOP deploys as a soft fork with zero disruption. ## 8
Transaction Encoding ### 8.1 Example (segOP Flag + P2SOP) A working example
showing how segOP coexists with SegWit, commented line-by-line. ```jsonc {
"version": 2, // transaction version "flag": 3, // 0x01 = SegWit, 0x02 =
segOP → 0x03 = both "vin": [ { "txid": "aa...aa", // previous transaction
hash "vout": 0, // output index "scriptSig": "", // empty for SegWit spend
"sequence": 4294967295 } ], "vout": [ { "value": 0.01000000, // spendable
output "scriptPubKey": { "type": "witness_v0_keyhash", "hex":
"0014abcdef..." } }, { "value": 0.00000000, // zero-value marker
"scriptPubKey": { "type": "nulldata", "asm": "OP_RETURN OP_SEGOP", //
Pay-to-segOP marker "hex": "6a045345474f50" // ASCII “SEGOP” } } ],
"witness": [ [ "3045...01", "02ab...cd" ] // standard sig + pubkey ],
"segop": { "length": 1024, // total segOP bytes (≤100 000) "tlv": [ {
"type": 1, // data hash "len": 32, "value": "d4d95998b5...e3" }, { "type":
2, // declared data length "len": 2, "value": "03e8" // 1000 bytes }, {
"type": 3, // optional Merkle root "len": 32, "value": "12ab...9f" } ] },
"locktime": 0 } ``` ### 8.2 Validation flow: 1. Detect flag & 0x02. 2.
Reject if segop.length > 100 000. 3. Weight = segop.length × 4. 4. Witness
elements ≤ 520 B. 5. Fee = (base_vbytes + segop.length) × feerate. ### 8.3
segOP Field definitions | Field | Purpose | Effect |
|-----------|-----------------------|--------------------------| | flag:3 |
SegWit + segOP active | Full-price accounting | | vout[1] | P2SOP output |
Marker only | | segop | Structured payload | TLV encoded | | length | Total
bytes | Hard cap enforced | | tlv | Typed entries | Verifiable meta | ## 9
Long-Term Storage and Pruning Strategy ### 9.1 Background A node only needs
the UTXO set and headers to enforce consensus; it doesn’t need to host
everyone’s history forever. Bitcoin Core already prunes full blocks to save
space but cannot surgically drop arbitrary data inside them. segOP fixes
that: since its data are self-contained and fully paid, they can be
forgotten safely once validated. ### 9.2 Pruning Process Validate segOP
payload and hash. Record its type, length, hash commitment. Delete payload
after chosen horizon. Keep headers and commitments for audit. The node
remains consensus-equivalent but disk-light. ### 9.3 Selective Retention |
TLV Type | Example | Keep? | Reason |
|-----------|---------------------|-------|----------------| | 1 | Hash or
Merkle root | Yes | Audit proof | | 2 | Declared length | Yes | Accounting
| | 10 | Raw payload | No | Space saving | ### 9.4 Policy Flags | Flag |
Value | Description | |------|--------|-------------| | `-prunesegop` | 1 |
Enable segOP pruning | | `-prunesegopheight` | 2016 | Start pruning after
2016 blocks | | `-prunewitness` | 1 | Enable witness pruning | |
`-prunewitnessheight` | 2016 | Start pruning after 2016 blocks | |
`-keepsegopcommitments` | 1 | Preserve segOP Merkle commitments | ### 9.5
Storage Projection To understand the long-term effect of segOP on storage,
it helps to model three realistic futures: the monetary-only baseline, the
current discounted-data situation, and a segOP-priced and pruned network.
In a **monetary-only scenario**, blocks average around 1 megabyte of actual
transaction data. At roughly 52,560 blocks per year, that equals about 52
gigabytes annually or roughly 525 gigabytes per decade. This represents the
"clean" Bitcoin model — payments only, no arbitrary data. It’s the lower
bound for full-node storage. In the **discounted-data future** (the
situation we already see today with Ordinals and similar use cases), most
blocks reach 2.5 megabytes on average once the witness discount is
exploited. That comes to around 1.3 terabytes per decade, and it keeps
climbing if large cheap data continues to fill every block. In this world,
node operators are forced to host other people’s content indefinitely while
earning less from fees — unsustainable for the long term. In the
**segOP-priced and pruned model**, blocks still carry roughly 1 megabyte of
payment data, but they may also include up to 1 megabyte of segOP payloads.
The key difference is that segOP data is fully paid for and can be safely
pruned after validation. A node that keeps a two-week rolling window of
segOP data (about 2,000 blocks) would only need an additional 2 gigabytes
of temporary disk space. After pruning, the total long-term requirement
stabilises near the same 525-gigabyte range as the monetary-only case —
effectively holding the line on growth. In short, segOP allows Bitcoin to
support data-rich use cases **without** forcing every node to store
terabytes of history. Heavy users pay for their data, and those who want to
keep it can, while everyone else can prune and move on. ### 9.6 Integrity
After Pruning Payloads may go, but commitments stay : block hashes still
cover segOP roots, headers prove existence, archives can re-serve data
verifiable by hash. ### 9.7 Data Retention Layers ```
┌─────────────────────────────────────────────┐ │ BITCOIN NODE │
└─────────────────────────────────────────────┘ │ ▼
┌─────────────────────────────────────────────┐ │ CORE CONSENSUS (UTXO +
Headers) │ └─────────────────────────────────────────────┘ │ ▼
┌─────────────────────────────────────────────┐ │ RECENT WINDOW (Blocks +
Witness + segOP) │ └─────────────────────────────────────────────┘ │ ▼
┌─────────────────────────────────────────────┐ │ PRUNED HISTORY (Old
payloads deleted) │ └─────────────────────────────────────────────┘ │ ▼
┌─────────────────────────────────────────────┐ │ ARCHIVE / ORACLE NODE
(optional history) │ └─────────────────────────────────────────────┘ ```
### 9.8 Pruning Economics 10-year pruned node ≈ 500 GB. 10-year archive ≈
1–3 TB. Only voluntary archives bear that cost— not everyone. ### 9.9 Data
Ownership and Access Model Under current rules, full nodes host other
people’s junk indefinitely. segOP changes that by making data
self-contained and prunable. After validation, nodes may drop payloads
while keeping hashes and lengths. They stay in consensus without carrying
unwanted content. Those who want the data keep it; those who don’t prune
it. Archive (or oracle) nodes voluntarily retain all segOP payloads and
offer them through APIs or Lightning-paywalled endpoints. Because every
payload carries its own Merkle root or SHA-256 hash, clients can verify
authenticity independently. No node is forced to store other people’s data;
each operator chooses their own weight class. It’s fee fairness at
inclusion and storage fairness after confirmation — a complete economic
loop. ## 10 Operational Profiles ### 10.1 Profile A — Home Node Light
validation on small hardware. `-prune=550` `-prunesegop=1`
`-prunesegopheight=2016` Keeps two weeks of history; fully validating; tiny
disk footprint. ### 10.2 Profile B — Mining / Economic Node `-prune=20000`
`-prunesegop=1` `-prunesegopheight=8064` `-keepsegopcommitments=1` Keeps 3
months of segOP for fee analysis and template testing. ### 10.3 Profile C —
Archive / Oracle Node `-prune=0` `-prunesegop=0` `-keepsegopcommitments=1`
Stores everything, serves API or Lightning requests, earns sats for data.
### 10.4 Profile D — Enterprise / Auditor `-prune=0` `-prunesegop=1`
`-prunesegopheight=40320` Keeps 9 months of segOP for audit; drops old
payloads. ### 10.5 Summary Table | Profile | Purpose | SegOP Policy |
Storage | Notes |
|----------|------------|----------------------|---------------------------|-------------------|
| A | Home | Prune after 2 weeks | Approx. 500 GB (decade) | Light +
private | | B | Miner | Keep 2–3 months | Approx. 1 TB (decade) | Analytics
| | C | Archive | Keep forever | Approx. 1–3 TB (decade) | Monetisable | |
D | Enterprise | Keep 9 months | Approx. 1 TB (decade) | Compliance | ###
10.6 Network Equilibrium Before segOP, every node bloats together. After
segOP, the network diversifies but remains coherent: light nodes stay
light, heavy nodes get paid, everyone shares the same rules. ## 11
Limitations and Future Work Standardisation: define TLV type registry.
Miner policy: optional feerate minimum for segOP data. Tooling: RPC & GUI
support for segOP construction. Pruning: implement -prunesegop flag for
disk control. Testing: run signet experiments on fee behaviour. Extensions:
explore Lightning-anchored retrieval oracles. ## 12 Conclusion segOP
restores honest pricing to blockspace. It changes nothing about Bitcoin’s
monetary rules—just how data is metered. By isolating large payloads into a
capped, fully-priced lane, it removes spam incentives while keeping
on-chain creativity alive. Keep the 520 B limit for signatures. Let data
live in segOP, pay full rate, and prune it later. That’s all. The outcome:
smaller chainstate, stronger miners, faster propagation, and fairer
economics - Bitcoin doing what it was designed to do. ## References [1] P.
Wuille et al., BIP-141: Segregated Witness (Consensus Layer), 2017. [2]
Bitcoin Core Source Code, MAX_SCRIPT_ELEMENT_SIZE = 520, 2012. [3] S.
Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [4] M.
Murch, Understanding the Mempool and Fee Market, 2020. [5] Defenwycke,
BIP-FAIR: Fair Fee Accounting for On-Chain Data (Draft), 2025.
On Wednesday, October 29, 2025 at 11:55:52 PM UTC defenwycke wrote:
> Hi all,
>
> I attempted to propose a BIP earlier today. I was notified of my incorrect
> actions versus core procedures.
>
> See attached or below - my proposal for discussion.
>
> Regards
>
> Defenwycke.
>
> ---
>
> A proposed discussion of segOP
> Author: Defenwycke / defen...@icloud.com
> 29.10.2025
>
> segOP (Segregated OP_RETURN)
>
> A proposed extension to Bitcoin transactions. It introduces a
> dedicated, structured, full-fee data lane for on-chain data, without
> disrupting existing transaction rules. Think of it like this - segOP is to
> arbitrary data what SegWit was to signatures — a clean, isolated,
> forward-compatible path that preserves old-node harmony while restoring fee
> fairness.
>
> Abstract:
>
> segOP defines a new segregated data section for Bitcoin transactions,
> cryptographically committed via OP_SUCCESS184. It standardizes on-chain
> metadata storage by enforcing full fees, structured TLV encoding, and a 100
> KB cap, while remaining backward-compatible with legacy nodes.
>
> It is not:
>
> - A replacement for OP_RETURN
> - An off-chain mechanism
> - A hard fork
>
> It is:
>
> - A soft-fork-safe, future-proof, SegWit-style data section
> - Full-fee (4 weight units per byte)
> - Structured (TLV + Merkle-root verified)
> - Limited to 100 KB per transaction
>
> What issues could segOP rectify?:
>
> 1. Ordinals abuse witness discount. segOP will apply full fee rate for
> large data.
> 2. No structured metadata lane. segOP introduces TLV-encoded +
> Merkle-verified section.
> 3. Witness discount abused for megabytes. segOP Enforces 100 KB cap.
> 4. OP_RETURN unstructured & limited. segOP = structured + verifiable.
> 5. Spam cheap storage. segOP deters spam with fees.
>
> In short - segOP restores fairness — data pays its real weight cost,
> preserving block space for financial use.
>
> Where segOP lives:
>
> Transaction Layout (Post-segOP)
> Transaction
> ├── nVersion
> ├── vin (inputs)
> ├── vout (outputs)
> │ └── P2SOP Output ← segOP anchor
> ├── witness (if any)
> ├── segOP marker (0xFA)
> ├── segOP section (if present)
> │ ├── chunk_count (varint)
> │ ├── TLV chunk 1
> │ ├── TLV chunk 2
> │ └── ...
> └── nLockTime
>
> Activation rules:
>
> - segOP section only appears if at least one P2SOP output exists.
> - Old nodes ignore unknown post-witness data → transaction valid
> (soft-fork safe).
> - New nodes validate the segOP section against the Merkle root in the
> P2SOP output.
>
> How segOP works:
>
> segOP extends the Bitcoin transaction format by adding a new optional
> section after the witness field.
> This section is linked cryptographically to a special output type —
> the P2SOP output — whose script commits to the Merkle root of the segOP
> data.
>
> The design mirrors SegWit: a segregated data structure, excluded from
> txid but included in wtxid, ensuring backward compatibility.
>
> 1. Transaction Creation
>
> When a wallet or protocol wants to include on-chain structured
> data (for example, a document hash, timestamp, or proof set), it performs
> the following steps:
>
> a. Build TLV Chunks
>
> Each data element is encoded in Type-Length-Value
> (TLV) format:
>
> - type (varint)
> - length (varint)
> - value (bytes)
>
> Each type defines a data meaning (e.g., type=1:
> manifest, type=2: payload, type=3: metadata, etc.). This allows future
> extensions without breaking parsers.
>
> b. Construct the Merkle Tree
>
> Each TLV is hashed as:
>
> leaf = dsha256(0x00 || TLV)
> and combined recursively:
> node = dsha256(0x01 || left || right)
>
> until a single Merkle root is produced. This root
> uniquely commits to all TLV data while allowing compact partial proofs.
>
> c. Commit to the Root (P2SOP Output)
>
> The wallet then inserts a special output into the
> transaction: scriptPubKey = OP_SUCCESS184 0x20 <32-byte Merkle root>
> (OP_SUCCESS184 is reserved for soft-fork activation).
> Legacy nodes treat it as “always true,” so the
> transaction remains spendable under pre-segOP rules.
> The 32-byte push commits to the root of the segOP
> section.
> Multiple P2SOP outputs may exist if a transaction
> carries multiple data trees, but each must be validated independently.
>
> d. Serialize the segOP Section
>
> After the witness data, a segOP marker (0xFA) signals
> presence, followed by the serialized data:
>
> 0xFA
> varint: chunk_count
> [TLV #1]
> [TLV #2]
> ...
>
> This section is included in the wtxid but not the
> txid, keeping legacy hashes unchanged (soft-fork compatible).
>
> 2. Transaction Relay and Policy
>
> segOP transactions are relayed like any other, with a few
> policy rules:
>
> - Size limit: The total size of segOP data (plus OP_RETURN
> + witness data >520 B) must not exceed 100,000 bytes. This prevents block
> bloat.
> - Fee treatment: segOP data counts at 4 weight units per
> byte (no discount), restoring parity between data and signatures.
> - Standardness check: Non-mining nodes enforce segOP as a
> standard policy rule (like SegWit’s P2WSH), rejecting noncompliant data
> from mempool relay.
>
> These are policy rules, not consensus, but miners
> enforcing them makes segOP behavior uniform across the network.
>
> 3. Validation (Node-Level)
>
> When a segOP transaction reaches a full node, validation
> happens in three stages:
>
> a. Detect segOP Presence
>
> - If any output script begins with OP_SUCCESS184, the
> node checks for a corresponding segOP section at the end of the transaction
> serialization.
> - If no segOP section is found → transaction invalid
> under segOP rules.
>
> b. Verify Size and Fee
>
> The node computes total data size:
> - All OP_RETURN payloads
> - All segOP TLVs
> - All witness items >520 bytes (these count as
> “data”)
> - If this exceeds 100 KB, the transaction is
> invalid.
> - The total weight is adjusted to include all
> segOP bytes at full cost.
>
> c. Verify Merkle Root
>
> - The node rebuilds the TLV Merkle tree and ensures:
> - calculated_root == <root in P2SOP output>
> - If the root mismatches → reject.
> - This makes segOP cryptographically bound to the
> transaction body, just like Taproot commits to script paths.
>
> 4. Inclusion in a Block
>
> - Miners include segOP transactions normally.
> - When calculating block weight: segOP bytes count fully (4
> WU/byte).
> - segOP does not alter the legacy 4M weight limit but competes
> fairly for space.
> - Miners can optionally expose segOP data through RPC or
> indexing APIs (e.g., gettxoutdata), similar to how they expose witness data.
>
> 5. Verification by Light Clients
>
> - Because segOP uses a Merkle structure: SPV clients or
> oracles can request proofs for individual TLVs without downloading full
> data. For example, a timestamp verifier can request: getsegopproof <txid>
> <chunk_type> and receive the TLV + Merkle proof + root verification path.
> This makes segOP efficient for decentralized proof storage or timestamping
> protocols.
>
> 6. Spending a P2SOP Output
>
> - Spending a P2SOP output works like spending an OP_SUCCESS
> output: Until activation, it behaves as anyone-can-spend, ensuring
> soft-fork safety. After activation, future consensus rules can restrict or
> redefine P2SOP redemption scripts.
> - Example forward path: A future BIP may define OP_SUCCESS184
> redemption to require proof of segOP validity or special conditions (e.g.,
> hash preimage commitments). Until then, nodes treat these outputs as valid
> spends, ensuring no forks.
>
> 7. Post-Activation Behavior
>
> - After segOP activation: All upgraded nodes enforce the 100
> KB cap and Merkle root validation.
> - Legacy nodes still accept the transactions, unaware of segOP
> structure.
> - Any mismatch between segOP section and root simply makes the
> tx invalid for upgraded miners — thus ensuring consensus alignment.
>
> Examples of segOP:
>
> Example 1: Timestamp a Document (50 KB)
> TLV #1: Type = 1, Manifest (JSON)
> TLV #2: Type = 2, PDF payload (50 KB)
> Build Merkle root → abc123...
> Create output:
> OP_SUCCESS184 0x20 abc123...
> segOP section:
> 0x02 # chunk count
> <TLV1> <TLV2>
> Fee: ≈ $30 at current full-fee rates
> Permanent, verifiable, structured.
>
> Example 2: Ordinals Tries 3.8 MB
> data_size = 3.8 MB → REJECTED (exceeds 100 KB cap)
> Attempt in witness → REJECTED (data > 520 B → full fee policy →
> cap still enforced)
>
> Example 3: Normal BTC Send
> No P2SOP output : No segOP section
> Fee Unchanged (~$0.09)
> Normal transactions unaffected.
>
> How to Use segOP:
>
> Build a segOP Transaction (Python)
>
> # 1. Prepare TLV chunks
> manifest = b'{"type":"proof","size":50000}'
> payload = b'50 KB of data...'
> tlv1 = varint(1) + varint(len(manifest)) + manifest
> tlv2 = varint(2) + varint(len(payload)) + payload
>
> # 2. Build Merkle root
> def dsha256(x): return sha256(sha256(x)).digest()
> leaf1 = dsha256(b'\x00' + tlv1)
> leaf2 = dsha256(b'\x00' + tlv2)
> root = dsha256(b'\x01' + leaf1 + leaf2)
>
> # 3. Create P2SOP output
> p2sop = b'\xb8\x20' + root
>
> # 4. Build segOP section
> segop = b'\xFA' + varint(2) + tlv1 + tlv2 # 0xFA marker
>
> # 5. Attach to tx
> tx.vout.append(CTxOut(0, CScript(p2sop)))
> tx.segop_section = segop
>
> Validation Logic (C++ Pseudocode):
>
> bool CheckSegOP(const CTransaction& tx) {
> size_t total_data = 0;
>
> for (const auto& out : tx.vout) {
> if (out.scriptPubKey[0] == OP_SUCCESS184) {
> // segOP output detected
> if (!tx.HasSegOPSection()) return false;
> total_data += tx.segOPSectionSize();
> }
> if (out.scriptPubKey[0] == OP_RETURN &&
> out.scriptPubKey.size() > 1) {
> total_data += out.scriptPubKey.size() - 1;
> }
> }
>
> for (const auto& in : tx.vin) {
> for (const auto& item : in.scriptWitness.stack) {
> if (item.size() > 520)
> total_data += item.size(); // witness data counts
> fully
> }
> }
>
> if (total_data > 100000) return false; // 100 KB consensus cap
>
> // Apply full weight to data for fee calc
> tx.virtual_size += total_data;
> return true;
> }
>
> Soft Fork Proof:
>
> - Old node: Ignores segOP
> - New node: Validates segOP
> - No chain split
> - Backward compatible
> - Miner-activated soft fork possible via versionbits
>
> Developer Q&A:
>
> Where is segOP serialized? : After witness, before nLockTime
> Does it affect txid? : No - only wtxid
> Can old nodes parse it? : Yes (ignored like witness)
> Max size? : 100 KB total data
> Fee rate? : Full fee (4 WU/byte)
> Can I use OP_RETURN too? : Yes — total combined data ≤ 100 KB
> Future extensions? : TLV unknown types ignored (safe forward-compat)
> How do I signal presence? : 0xFA marker after witness
>
>
> Conclusion:
>
> - On-chain
> - Structured (TLV + Merkle)
> - Full-fee and fair
> - Soft-fork safe
> - Future-proof
>
> segOP introduces the clean, capped, verifiable data lane Bitcoin needs
> — ending witness discount abuse while preserving freedom for legitimate
> metadata.
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a5ec8a97-3884-40eb-9276-8536f664c0e0n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 75845 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Re: segOP potential BIP discussion
2025-10-30 21:25 ` [bitcoindev] " defenwycke
@ 2025-11-01 12:00 ` 'moonsettler' via Bitcoin Development Mailing List
0 siblings, 0 replies; 3+ messages in thread
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-11-01 12:00 UTC (permalink / raw)
To: defenwycke; +Cc: Bitcoin Development Mailing List
Hi Defenwycke,
I think this is not a horrible idea, there might be future demand for a pruneable proof of publication space.
But, your proposal does not provide an incentive for anyone to adopt it. If it was cheaper than witness space,
I think it would be a serious consideration especially for rollups.
The idea that the bytes incur full cost (4WU) makes it on arrival economically speaking.
Also it's a bit unclear how consensus and nodes in sync would interact with the "recent window".
It's a reasonable approach to mandate the presence of such an extension block near the chain-tip, but
nodes by default should not download or verify it during IBD. This would only add a constant burden to nodes,
while allowing bitcoin to scale on higher layers more that require such proof of publication mechanism for
their security.
Thinking that this would be used by graffiti type payloads that especially are seeking the permanence, persistence
and replication of bitcoin transactional data, or that metaprotocols that want to use the block space as an archival
layer for their own token ledgers is I'm afraid completely misguided or even delusional.
BR,
moonsettler
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3S1IMGSH6z-3Ho81Ugp9o-ltTwpIC-4ow6bn6aEAtK4XrkG5HTkvTw0BeZFpPILfabdp7rz_LDHEBWX_XZk0a7nKR4sJRUp_3B7pAMaJ86I%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-11-01 12:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-10-29 23:40 [bitcoindev] segOP potential BIP discussion defenwycke
2025-10-30 21:25 ` [bitcoindev] " defenwycke
2025-11-01 12:00 ` 'moonsettler' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox