From: defenwycke <cal.defenwycke@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: segOP potential BIP discussion
Date: Thu, 30 Oct 2025 14:25:25 -0700 (PDT) [thread overview]
Message-ID: <a5ec8a97-3884-40eb-9276-8536f664c0e0n@googlegroups.com> (raw)
In-Reply-To: <c38d00f7-a42b-4f7b-899e-11e823a43d7dn@googlegroups.com>
[-- 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 --]
next prev parent reply other threads:[~2025-10-30 21:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 23:40 [bitcoindev] " defenwycke
2025-10-30 21:25 ` defenwycke [this message]
2025-11-01 12:00 ` [bitcoindev] " 'moonsettler' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a5ec8a97-3884-40eb-9276-8536f664c0e0n@googlegroups.com \
--to=cal.defenwycke@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox