From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 30 Oct 2025 14:58:55 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEafU-0003Jd-Dg for bitcoindev@gnusha.org; Thu, 30 Oct 2025 14:58:55 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-3d1b82f5880sf2327389fac.1 for ; Thu, 30 Oct 2025 14:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761861526; x=1762466326; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=eAmDGm3qVQf8XIRO0dTN1dGZRhElf0ku/UN2pc8ZkZg=; b=HlbBg1GTXltGUQTTrQnG7vJ153yWYUa+l5f6yQjghgbcZhZYbRXbvL2e5UlNsTSO3C 7Ydif6fMW2wi1bdJT/4qZrowsZn4UXXkIza2s95LW6DDxv6Zry/zu6n5nVs49Q1STMLU J60xW6NHpZCMGQD8WGa98/lSTRs8cmjjFY1Jb+JLUXszA4/xTq3iDKeYhYgQJ9yCQb2W 4IXe4VTBwojIHDuZ679HuBflliRncIEeZXjblU7gyUrBp81q6+YpymLB+Fnqgt1bk2sY EQgw9vJ1nSoGns0GtlQVdwwRS9LJN+KzgnDUe4w+dH97tz5YDPS5EeRYk6V0x99w1Crr hrCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761861526; x=1762466326; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=eAmDGm3qVQf8XIRO0dTN1dGZRhElf0ku/UN2pc8ZkZg=; b=Ty+3U0RdFydIU0zHpAaLQjtb18I0kxggcUOUtYq991JcIb462qx2DY31EGCkMrIIgJ Pe8u4seuLnniHpytPI90X8dLG1s/iDQpvNqRjH5Bd1ll5YyGb2wRWFDE0O7Ee7LXqdcx erW7uudVohY1zni5Rk/+evowebzAHo4k+I6+4P9FZLsZs7UTbbS1fY0BDYZsiNcFyXDH tpPliEMmrUFtIMPzVr0OQSN8OlfmoT1jm11998T9AoaLNM1yZnbC+mcLGsBk6s2TWa+Q rHkgMjXCmqaqGxm32qpdT/x3hDIhgJLhe67NVgor8WxSaa9RDJpLngWRfLEhKTSX36c0 VboA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761861526; x=1762466326; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=eAmDGm3qVQf8XIRO0dTN1dGZRhElf0ku/UN2pc8ZkZg=; b=iMpky+Ese/VpOE3Zh90+haensf1wtE3GNmcBv23Hq/IREH9SLeabKOfmm96DswINoU cnY//6xNJYzjpXZU8+lWA39WiOGFe5rkGamdS1S+xcX+TOBFCve/xcjEctUHdmhiYuM0 BXErZuQ+/A7sN+cDXd6YgWj+Tkt3Q5oDeeU2/O3RntnTCV/a0+OfVLtngCj3fNkGr0PB srRH4gGzUtGzmI3ulmVX+NRvgjBTGCTEPgarTqbDH71E5vPPRkcmg8y+Yfk8uYDw0xji L26/KOlnQSCvk14+I3lqNa1wuGHmrkA5WH48flbdSWzhjX/mGTVPIBgpzaybBQDNscq/ zIqA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCX37M5url51AjDhXWxaok8fAcqhfQIY0Cb421ccfnaAzRAmEmO8BCxjEEUJa5u1ISeE7GvNG5pCHGU+@gnusha.org X-Gm-Message-State: AOJu0Yzy+FFyoXRA2i3oTISgx3Gw6GigRMQ17tlziXR+S13QBvHe7EF/ tENUYlt/fktufjzuE2tDTjihySc4tsF8yvIIjTfQ305Ach2p1EMAgPwn X-Google-Smtp-Source: AGHT+IEXX2PSrlRJUxLCkRNELIzTRtID2zCG4ozruBJNfe0VYVfYS0lqgnu0YAhJSDR9ov5Zv3I3mg== X-Received: by 2002:a05:6870:2047:b0:315:60a6:c27b with SMTP id 586e51a60fabf-3daba0bea5cmr731277fac.10.1761861525921; Thu, 30 Oct 2025 14:58:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+a3R2pWPJ6VCBu3reF+5amXhXYa+6jjL9w6wIgOF84ekw==" Received: by 2002:a05:6870:11c7:b0:3d3:2f56:6730 with SMTP id 586e51a60fabf-3d8b9665bafls571620fac.0.-pod-prod-03-us; Thu, 30 Oct 2025 14:58:40 -0700 (PDT) X-Received: by 2002:a05:6808:4f52:b0:439:af2f:d1d5 with SMTP id 5614622812f47-44f95f46cf3mr553838b6e.39.1761861520120; Thu, 30 Oct 2025 14:58:40 -0700 (PDT) Received: by 2002:a05:690c:dc1:b0:785:e55d:2dfd with SMTP id 00721157ae682-78649982b58ms7b3; Thu, 30 Oct 2025 14:25:27 -0700 (PDT) X-Received: by 2002:a05:690e:d50:b0:63e:11f9:6fa6 with SMTP id 956f58d0204a3-63f922d9e16mr779483d50.44.1761859525434; Thu, 30 Oct 2025 14:25:25 -0700 (PDT) Date: Thu, 30 Oct 2025 14:25:25 -0700 (PDT) From: defenwycke To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: [bitcoindev] Re: segOP potential BIP discussion MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_127922_921181906.1761859525060" X-Original-Sender: cal.defenwycke@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_127922_921181906.1761859525060 Content-Type: multipart/alternative; boundary="----=_Part_127923_298848317.1761859525060" ------=_Part_127923_298848317.1761859525060 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I thought more about this today. Please see update below. Open to ideas and= =20 discussion.=20 KR Defenwycke # segOP : Segregated OP_RETURN # A Structured and Fee-Fair Data Extension= =20 for Bitcoin ## Technical Paper =E2=80=94 October 2025 ## Author : Defenwyck= e ##=20 Abstract Bitcoin=E2=80=99s four-million-weight-unit block limit was meant t= o price=20 blockspace fairly, yet Segregated Witness introduced an asymmetry: witness= =20 bytes cost one weight unit while base bytes cost four. That=20 discount=E2=80=94intended for signatures=E2=80=94has become a subsidy for a= rbitrary data.=20 Large image and metadata =E2=80=9Cinscriptions=E2=80=9D now fill much of ea= ch block while=20 paying a fraction of what monetary transactions pay. The result is a=20 distorted fee market: blocks remain full but miners earn less and real=20 users queue longer. segOP (Segregated OP_RETURN) restores balance without a= =20 hard fork. It defines a structured, priced data lane inside the=20 transaction=E2=80=94full fee rate, capped at 100 KB, TLV-encoded and=20 Merkle-verifiable. Each payload pays the same 4 WU per byte as ordinary=20 transaction data. Economic modelling shows miner revenue roughly doubling= =20 and genuine payment throughput increasing about 75 %, while spam falls=20 naturally. The proposal is soft-fork safe, easily pruned, and backward=20 compatible. ## 1 Introduction ### 1.1 Why This Matters Bitcoin=E2=80=99s st= rength=20 lies in simplicity: every byte competes equally for limited space. Since=20 2017, witness discounting has broken that symmetry. A 1 MB batch of=20 signatures or data in the witness section now costs only =C2=BC of what it = would=20 in the base section. That imbalance has turned the witness into a=20 subsidised data store. Ordinary users fund cheap on-chain storage for=20 unrelated content, miners lose fees, and block propagation slows. ### 1.2= =20 Goal of segOP segOP re-introduces equal pricing. It doesn=E2=80=99t forbid = data; it=20 merely isolates and meters it properly. Like SegWit separated signatures=20 for malleability reasons, segOP separates arbitrary data for economic=20 fairness. Every byte again pays its way. ## 2 Problem Statement ### 2.1 The= =20 Fee Distortion | Rule | Current Value | Impact |=20 |----------------------|------------------|----------------------| | Block= =20 weight limit | 4 000 000 WU | Hard cap | | Witness discount | =C2=BC WU / B= |=20 Data cheap | | Max script element | 520 B | Protects validation | | UTXO=20 retention | Permanent | Growing state | Because witness data is so cheap,= =20 100 KB of arbitrary content weighs 100 000 WU instead of 400 000 WU. Miners= =20 still fill blocks to 4 M WU, but earn less; users compete against=20 discounted junk. The imbalance is economic, not cryptographic. ### 2.2=20 Consequences Fee market signal blurred =E2=80=94 cheap spam masks real dema= nd.=20 Throughput loss =E2=80=94 genuine tx count falls =E2=89=88 40=E2=80=9360 %.= Revenue loss =E2=80=94 full=20 blocks yield low fees. Propagation load =E2=80=94 bigger blocks take longer= to=20 relay. Without change, history repeats: larger chain, lower income, weaker= =20 incentives. ## 3 Proposal =E2=80=94 segOP (Segregated OP_RETURN) segOP intr= oduces a=20 new optional section after the witness. It carries arbitrary structured=20 data at full cost (4 WU/B) and is capped at 100 KB per transaction.=20 Presence is signalled by a new flag bit (0x02). Legacy nodes ignore it;=20 upgraded nodes parse and charge for it. ### 3.1 Design Summary | Parameter= =20 | Rule | Purpose |=20 |----------------|-------------------------|-----------------------------|= =20 | Encoding | TLV (Type-Length-Value) | Self-describing, extensible | |=20 Maximum size | 100 000 B | Stops bloat | | Cost per byte | 4 WU | Restores= =20 parity | | Witness limit | 520 B | Protects execution | | Placement | After= =20 witness | Deterministic layout | | Compatibility | Soft-fork safe | Old=20 nodes ignore | ### 3.2 Why Equal Pricing Matters You can=E2=80=99t legislat= e away=20 spam; you fix it by removing its subsidy. segOP ends the discount, making= =20 large data pay the same rate as payments. Abuse becomes uneconomic=E2=80=94= no=20 blacklists or heuristics needed. ### 3.3 Compatibility Old nodes ignore bit= =20 0x02. txid excludes segOP data =E2=86=92 no malleability risk. Deployment v= ia=20 version-bits or miner policy. ### 3.4 Analogy SegWit separated signatures= =20 for security; segOP separates data for fairness. Both reduce friction=20 between innovation and consensus. ## 4. Economic Model segOP changes the=20 economics of blockspace by removing the discount that allows data to=20 underpay for its size. To understand its impact, we can model the block in= =20 three parts: normal transactions, discounted data (today=E2=80=99s reality)= , and=20 segOP data (the proposed model). ### 4.1 Variables and Setup Let: - `Wb` = =3D=20 block weight limit =E2=86=92 4,000,000 weight units - `Wtx` =3D average tra= nsaction=20 weight =E2=86=92 600 weight units - `S` =3D segOP payload size =E2=86=92 10= 0,000 bytes -=20 `WsegOP` =3D segOP weight =3D 4 =C3=97 S =3D 400,000 weight units - `f` =3D= fee rate in=20 satoshis per virtual byte (sat/vB) We define the following relationships:= =20 FsegOP =3D f =C3=97 S T =3D (Wb - 400,000 =C3=97 n) / Wtx Fblock =3D n =C3= =97 FsegOP + T =C3=97 (f =C3=97=20 150) Where: - `n` is the number of segOP payloads in a block. - `FsegOP` is= =20 the fee paid by one segOP transaction. - `Fblock` is the total fee income= =20 for the block. This gives a rough but useful estimate of how miner revenue= =20 scales when blocks contain different mixes of segOP data and normal=20 transactions. ### 4.2 Scenario A =E2=80=94 Current Situation (Discounted Wi= tness=20 Data) In the current network, around sixty percent of block weight can be= =20 consumed by discounted witness data. That data pays only one quarter of the= =20 fee rate that normal bytes would, so the block fills up faster but=20 generates less revenue. A typical block might contain about 2,600 normal=20 transactions and yield around 0.006 BTC in fees. The network looks busy,=20 but most of the block is effectively subsidised storage. ### 4.3 Scenario B= =20 =E2=80=94 segOP Introduced (Full-Fee Data Lane) With segOP active, arbitrar= y data=20 still fits on-chain, but it now pays the same four weight units per byte as= =20 everything else. Assume three segOP payloads of 100 KB each per block.=20 Under these conditions, the block includes roughly 4,600 normal=20 transactions and produces around 0.013 BTC in total fees. Miners earn more,= =20 users see more legitimate transactions confirmed, and blockspace pricing=20 becomes honest again. ### 4.4 Scenario C =E2=80=94 No Discounted Data If th= e=20 network were used purely for monetary transactions, a full block would=20 contain roughly 6,600 standard transactions at an average total fee of=20 about 0.010 BTC. This represents the upper bound for throughput but not=20 necessarily the most balanced use of blockspace. ### 4.5 Interpretation=20 Spam deterrence: Data becomes too expensive to abuse; only purposeful data= =20 remains. Fair market: Each byte competes equally, eliminating hidden=20 discounts. Higher throughput: More monetary transactions per block because= =20 junk is no longer cheap. Miner incentive: Full blocks now pay full rewards;= =20 revenue rises naturally. Stable propagation: Blocks remain smaller and more= =20 predictable in structure, improving relay speed. segOP doesn=E2=80=99t requ= ire a=20 new policy or central coordination=E2=80=94it simply restores the natural b= alance=20 of the fee market through equal pricing. ## 5 Behavioural and Economic=20 Implications Spam deterrence =E2=80=94 once data costs full rate, stuffing = blocks=20 is uneconomic. Fair market =E2=80=94 every byte competes equally. Higher th= roughput=20 =E2=80=94 fewer bloated transactions. Better miner income =E2=80=94 full bl= ocks now mean=20 full fees. Predictable propagation =E2=80=94 smaller, uniform payloads redu= ce=20 latency. It=E2=80=99s a market fix, not a ban list. ## 6 Security and Conse= nsus ###=20 6.1 Considerations segOP changes accounting, not consensus. Validation=20 logic stays deterministic; legacy nodes remain valid peers. | Risk |=20 Mitigation |=20 |-------------------------|------------------------------------------------= |=20 | Soft-fork compatibility | Unrecognised flag ignored by old nodes | |=20 Malleability | segOP excluded from txid | | Script safety | 520 B element= =20 limit unchanged | | Resource load | =E2=89=A4 100 KB per tx caps memory | |= Replay=20 risk | Flag bit isolated from version | ### 6.2 Validation Flow=20 (pseudocode) ```python def validate_tx(tx): check_structure(tx)=20 check_inputs_outputs(tx) if tx.flag & 0x01: # SegWit validate_witness(tx)= =20 for w in tx.witness: for item in w: if len(item) > 520: raise=20 ScriptError("witness element too large") if tx.flag & 0x02: # segOP seg =3D= =20 tx.segop if seg.length > 100_000: raise PolicyError("segOP payload too=20 large") charge_weight(seg.length * 4) validate_tlv(seg.tlv) ``` The logic= =20 is simple: include data, pay for data. ## 7 Implementation and Flag=20 Structure | Flag Bit | Meaning | Present In | Cost Model |=20 |-----------|---------------------|-------------|--------------------------= ---|=20 | 0x00 | Legacy (no witness) | Pre-SegWit | 4 WU/B | | 0x01 | SegWit only |= =20 Post-2017 | 1 WU witness | | 0x02 | segOP only | Future | 4 WU segOP | |=20 0x03 | SegWit + segOP | Mixed | 1 WU witness + 4 WU segOP | Older software= =20 ignores 0x02, so segOP deploys as a soft fork with zero disruption. ## 8=20 Transaction Encoding ### 8.1 Example (segOP Flag + P2SOP) A working example= =20 showing how segOP coexists with SegWit, commented line-by-line. ```jsonc {= =20 "version": 2, // transaction version "flag": 3, // 0x01 =3D SegWit, 0x02 = =3D=20 segOP =E2=86=92 0x03 =3D both "vin": [ { "txid": "aa...aa", // previous tra= nsaction=20 hash "vout": 0, // output index "scriptSig": "", // empty for SegWit spend= =20 "sequence": 4294967295 } ], "vout": [ { "value": 0.01000000, // spendable= =20 output "scriptPubKey": { "type": "witness_v0_keyhash", "hex":=20 "0014abcdef..." } }, { "value": 0.00000000, // zero-value marker=20 "scriptPubKey": { "type": "nulldata", "asm": "OP_RETURN OP_SEGOP", //=20 Pay-to-segOP marker "hex": "6a045345474f50" // ASCII =E2=80=9CSEGOP=E2=80= =9D } } ],=20 "witness": [ [ "3045...01", "02ab...cd" ] // standard sig + pubkey ],=20 "segop": { "length": 1024, // total segOP bytes (=E2=89=A4100 000) "tlv": [= {=20 "type": 1, // data hash "len": 32, "value": "d4d95998b5...e3" }, { "type":= =20 2, // declared data length "len": 2, "value": "03e8" // 1000 bytes }, {=20 "type": 3, // optional Merkle root "len": 32, "value": "12ab...9f" } ] },= =20 "locktime": 0 } ``` ### 8.2 Validation flow: 1. Detect flag & 0x02. 2.=20 Reject if segop.length > 100 000. 3. Weight =3D segop.length =C3=97 4. 4. W= itness=20 elements =E2=89=A4 520 B. 5. Fee =3D (base_vbytes + segop.length) =C3=97 fe= erate. ### 8.3=20 segOP Field definitions | Field | Purpose | Effect |=20 |-----------|-----------------------|--------------------------| | flag:3 |= =20 SegWit + segOP active | Full-price accounting | | vout[1] | P2SOP output |= =20 Marker only | | segop | Structured payload | TLV encoded | | length | Total= =20 bytes | Hard cap enforced | | tlv | Typed entries | Verifiable meta | ## 9= =20 Long-Term Storage and Pruning Strategy ### 9.1 Background A node only needs= =20 the UTXO set and headers to enforce consensus; it doesn=E2=80=99t need to h= ost=20 everyone=E2=80=99s history forever. Bitcoin Core already prunes full blocks= to save=20 space but cannot surgically drop arbitrary data inside them. segOP fixes=20 that: since its data are self-contained and fully paid, they can be=20 forgotten safely once validated. ### 9.2 Pruning Process Validate segOP=20 payload and hash. Record its type, length, hash commitment. Delete payload= =20 after chosen horizon. Keep headers and commitments for audit. The node=20 remains consensus-equivalent but disk-light. ### 9.3 Selective Retention |= =20 TLV Type | Example | Keep? | Reason |=20 |-----------|---------------------|-------|----------------| | 1 | Hash or= =20 Merkle root | Yes | Audit proof | | 2 | Declared length | Yes | Accounting= =20 | | 10 | Raw payload | No | Space saving | ### 9.4 Policy Flags | Flag |=20 Value | Description | |------|--------|-------------| | `-prunesegop` | 1 |= =20 Enable segOP pruning | | `-prunesegopheight` | 2016 | Start pruning after= =20 2016 blocks | | `-prunewitness` | 1 | Enable witness pruning | |=20 `-prunewitnessheight` | 2016 | Start pruning after 2016 blocks | |=20 `-keepsegopcommitments` | 1 | Preserve segOP Merkle commitments | ### 9.5= =20 Storage Projection To understand the long-term effect of segOP on storage,= =20 it helps to model three realistic futures: the monetary-only baseline, the= =20 current discounted-data situation, and a segOP-priced and pruned network.= =20 In a **monetary-only scenario**, blocks average around 1 megabyte of actual= =20 transaction data. At roughly 52,560 blocks per year, that equals about 52= =20 gigabytes annually or roughly 525 gigabytes per decade. This represents the= =20 "clean" Bitcoin model =E2=80=94 payments only, no arbitrary data. It=E2=80= =99s the lower=20 bound for full-node storage. In the **discounted-data future** (the=20 situation we already see today with Ordinals and similar use cases), most= =20 blocks reach 2.5 megabytes on average once the witness discount is=20 exploited. That comes to around 1.3 terabytes per decade, and it keeps=20 climbing if large cheap data continues to fill every block. In this world,= =20 node operators are forced to host other people=E2=80=99s content indefinite= ly while=20 earning less from fees =E2=80=94 unsustainable for the long term. In the=20 **segOP-priced and pruned model**, blocks still carry roughly 1 megabyte of= =20 payment data, but they may also include up to 1 megabyte of segOP payloads.= =20 The key difference is that segOP data is fully paid for and can be safely= =20 pruned after validation. A node that keeps a two-week rolling window of=20 segOP data (about 2,000 blocks) would only need an additional 2 gigabytes= =20 of temporary disk space. After pruning, the total long-term requirement=20 stabilises near the same 525-gigabyte range as the monetary-only case =E2= =80=94=20 effectively holding the line on growth. In short, segOP allows Bitcoin to= =20 support data-rich use cases **without** forcing every node to store=20 terabytes of history. Heavy users pay for their data, and those who want to= =20 keep it can, while everyone else can prune and move on. ### 9.6 Integrity= =20 After Pruning Payloads may go, but commitments stay : block hashes still=20 cover segOP roots, headers prove existence, archives can re-serve data=20 verifiable by hash. ### 9.7 Data Retention Layers ```=20 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 BITCOIN NODE =E2= =94=82=20 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=82 =E2=96=BC=20 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 CORE CONSENSUS (= UTXO +=20 Headers) =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2= =94=82 =E2=96=BC=20 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 RECENT WINDOW (B= locks +=20 Witness + segOP) =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98= =E2=94=82 =E2=96=BC=20 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 PRUNED HISTORY (= Old=20 payloads deleted) =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =98 =E2=94=82 =E2=96=BC=20 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 ARCHIVE / ORACLE= NODE=20 (optional history) =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =98 ```=20 ### 9.8 Pruning Economics 10-year pruned node =E2=89=88 500 GB. 10-year arc= hive =E2=89=88=20 1=E2=80=933 TB. Only voluntary archives bear that cost=E2=80=94 not everyon= e. ### 9.9 Data=20 Ownership and Access Model Under current rules, full nodes host other=20 people=E2=80=99s junk indefinitely. segOP changes that by making data=20 self-contained and prunable. After validation, nodes may drop payloads=20 while keeping hashes and lengths. They stay in consensus without carrying= =20 unwanted content. Those who want the data keep it; those who don=E2=80=99t = prune=20 it. Archive (or oracle) nodes voluntarily retain all segOP payloads and=20 offer them through APIs or Lightning-paywalled endpoints. Because every=20 payload carries its own Merkle root or SHA-256 hash, clients can verify=20 authenticity independently. No node is forced to store other people=E2=80= =99s data;=20 each operator chooses their own weight class. It=E2=80=99s fee fairness at= =20 inclusion and storage fairness after confirmation =E2=80=94 a complete econ= omic=20 loop. ## 10 Operational Profiles ### 10.1 Profile A =E2=80=94 Home Node Lig= ht=20 validation on small hardware. `-prune=3D550` `-prunesegop=3D1`=20 `-prunesegopheight=3D2016` Keeps two weeks of history; fully validating; ti= ny=20 disk footprint. ### 10.2 Profile B =E2=80=94 Mining / Economic Node `-prune= =3D20000`=20 `-prunesegop=3D1` `-prunesegopheight=3D8064` `-keepsegopcommitments=3D1` Ke= eps 3=20 months of segOP for fee analysis and template testing. ### 10.3 Profile C = =E2=80=94=20 Archive / Oracle Node `-prune=3D0` `-prunesegop=3D0` `-keepsegopcommitments= =3D1`=20 Stores everything, serves API or Lightning requests, earns sats for data.= =20 ### 10.4 Profile D =E2=80=94 Enterprise / Auditor `-prune=3D0` `-prunesegop= =3D1`=20 `-prunesegopheight=3D40320` Keeps 9 months of segOP for audit; drops old=20 payloads. ### 10.5 Summary Table | Profile | Purpose | SegOP Policy |=20 Storage | Notes |=20 |----------|------------|----------------------|---------------------------= |-------------------|=20 | A | Home | Prune after 2 weeks | Approx. 500 GB (decade) | Light +=20 private | | B | Miner | Keep 2=E2=80=933 months | Approx. 1 TB (decade) | A= nalytics=20 | | C | Archive | Keep forever | Approx. 1=E2=80=933 TB (decade) | Monetisa= ble | |=20 D | Enterprise | Keep 9 months | Approx. 1 TB (decade) | Compliance | ###= =20 10.6 Network Equilibrium Before segOP, every node bloats together. After=20 segOP, the network diversifies but remains coherent: light nodes stay=20 light, heavy nodes get paid, everyone shares the same rules. ## 11=20 Limitations and Future Work Standardisation: define TLV type registry.=20 Miner policy: optional feerate minimum for segOP data. Tooling: RPC & GUI= =20 support for segOP construction. Pruning: implement -prunesegop flag for=20 disk control. Testing: run signet experiments on fee behaviour. Extensions:= =20 explore Lightning-anchored retrieval oracles. ## 12 Conclusion segOP=20 restores honest pricing to blockspace. It changes nothing about Bitcoin=E2= =80=99s=20 monetary rules=E2=80=94just how data is metered. By isolating large payload= s into a=20 capped, fully-priced lane, it removes spam incentives while keeping=20 on-chain creativity alive. Keep the 520 B limit for signatures. Let data=20 live in segOP, pay full rate, and prune it later. That=E2=80=99s all. The o= utcome:=20 smaller chainstate, stronger miners, faster propagation, and fairer=20 economics - Bitcoin doing what it was designed to do. ## References [1] P.= =20 Wuille et al., BIP-141: Segregated Witness (Consensus Layer), 2017. [2]=20 Bitcoin Core Source Code, MAX_SCRIPT_ELEMENT_SIZE =3D 520, 2012. [3] S.=20 Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [4] M.=20 Murch, Understanding the Mempool and Fee Market, 2020. [5] Defenwycke,=20 BIP-FAIR: Fair Fee Accounting for On-Chain Data (Draft), 2025. On Wednesday, October 29, 2025 at 11:55:52=E2=80=AFPM UTC defenwycke wrote: > Hi all, > > I attempted to propose a BIP earlier today. I was notified of my incorrec= t=20 > 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=20 > dedicated, structured, full-fee data lane for on-chain data, without=20 > disrupting existing transaction rules. Think of it like this - segOP is t= o=20 > arbitrary data what SegWit was to signatures =E2=80=94 a clean, isolated,= =20 > forward-compatible path that preserves old-node harmony while restoring f= ee=20 > fairness. > > Abstract: > > segOP defines a new segregated data section for Bitcoin transactions,= =20 > cryptographically committed via OP_SUCCESS184. It standardizes on-chain= =20 > metadata storage by enforcing full fees, structured TLV encoding, and a 1= 00=20 > 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 fo= r=20 > large data. > 2. No structured metadata lane. segOP introduces TLV-encoded +=20 > Merkle-verified section. > 3. Witness discount abused for megabytes. segOP Enforces 100 KB cap. > 4. OP_RETURN unstructured & limited. segOP =3D structured + verifiabl= e. > 5. Spam cheap storage. segOP deters spam with fees. > > In short - segOP restores fairness =E2=80=94 data pays its real weigh= t cost,=20 > preserving block space for financial use. > > Where segOP lives: > > Transaction Layout (Post-segOP) > Transaction > =E2=94=9C=E2=94=80=E2=94=80 nVersion > =E2=94=9C=E2=94=80=E2=94=80 vin (inputs) > =E2=94=9C=E2=94=80=E2=94=80 vout (outputs) > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 P2SOP Output =E2=86=90 segOP = anchor > =E2=94=9C=E2=94=80=E2=94=80 witness (if any) > =E2=94=9C=E2=94=80=E2=94=80 segOP marker (0xFA) > =E2=94=9C=E2=94=80=E2=94=80 segOP section (if present) > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 chunk_count (varint) > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 TLV chunk 1 > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 TLV chunk 2 > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 ... > =E2=94=94=E2=94=80=E2=94=80 nLockTime > > Activation rules: > > - segOP section only appears if at least one P2SOP output exists. > - Old nodes ignore unknown post-witness data =E2=86=92 transaction va= lid=20 > (soft-fork safe). > - New nodes validate the segOP section against the Merkle root in the= =20 > P2SOP output. > > How segOP works: > > segOP extends the Bitcoin transaction format by adding a new optional= =20 > section after the witness field. > This section is linked cryptographically to a special output type =E2= =80=94=20 > the P2SOP output =E2=80=94 whose script commits to the Merkle root of the= segOP=20 > data. > > The design mirrors SegWit: a segregated data structure, excluded from= =20 > txid but included in wtxid, ensuring backward compatibility. > > 1. Transaction Creation > > When a wallet or protocol wants to include on-chain structure= d=20 > data (for example, a document hash, timestamp, or proof set), it performs= =20 > the following steps: > > a. Build TLV Chunks > > Each data element is encoded in Type-Length-Value=20 > (TLV) format: > > - type (varint) > - length (varint) > - value (bytes) > > Each type defines a data meaning (e.g., type=3D1:=20 > manifest, type=3D2: payload, type=3D3: metadata, etc.). This allows futur= e=20 > extensions without breaking parsers. > > b. Construct the Merkle Tree > > Each TLV is hashed as: > > leaf =3D dsha256(0x00 || TLV) > and combined recursively: > node =3D dsha256(0x01 || left || right) > > until a single Merkle root is produced. This root=20 > 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=20 > transaction: scriptPubKey =3D OP_SUCCESS184 0x20 <32-byte Merkle root>=20 > (OP_SUCCESS184 is reserved for soft-fork activation). > Legacy nodes treat it as =E2=80=9Calways true,=E2=80= =9D so the=20 > transaction remains spendable under pre-segOP rules. > The 32-byte push commits to the root of the segOP=20 > section. > Multiple P2SOP outputs may exist if a transaction=20 > carries multiple data trees, but each must be validated independently. > > d. Serialize the segOP Section > > After the witness data, a segOP marker (0xFA) signals= =20 > presence, followed by the serialized data: > > 0xFA > varint: chunk_count > [TLV #1] > [TLV #2] > ... > > This section is included in the wtxid but not the=20 > txid, keeping legacy hashes unchanged (soft-fork compatible). > > 2. Transaction Relay and Policy > > segOP transactions are relayed like any other, with a few=20 > policy rules: > > - Size limit: The total size of segOP data (plus OP_RETUR= N=20 > + witness data >520 B) must not exceed 100,000 bytes. This prevents block= =20 > bloat. > - Fee treatment: segOP data counts at 4 weight units per= =20 > byte (no discount), restoring parity between data and signatures. > - Standardness check: Non-mining nodes enforce segOP as a= =20 > standard policy rule (like SegWit=E2=80=99s P2WSH), rejecting noncomplian= t data=20 > from mempool relay. > > These are policy rules, not consensus, but miners=20 > enforcing them makes segOP behavior uniform across the network. > > 3. Validation (Node-Level) > > When a segOP transaction reaches a full node, validation=20 > happens in three stages: > > a. Detect segOP Presence > > - If any output script begins with OP_SUCCESS184, the= =20 > node checks for a corresponding segOP section at the end of the transacti= on=20 > serialization. > - If no segOP section is found =E2=86=92 transaction = invalid=20 > 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=20 > =E2=80=9Cdata=E2=80=9D) > - If this exceeds 100 KB, the transaction is=20 > invalid. > - The total weight is adjusted to include all=20 > segOP bytes at full cost. > > c. Verify Merkle Root > > - The node rebuilds the TLV Merkle tree and ensures: > - calculated_root =3D=3D > - If the root mismatches =E2=86=92 reject. > - This makes segOP cryptographically bound to the=20 > 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= =20 > WU/byte). > - segOP does not alter the legacy 4M weight limit but compete= s=20 > fairly for space. > - Miners can optionally expose segOP data through RPC or=20 > indexing APIs (e.g., gettxoutdata), similar to how they expose witness da= ta. > > 5. Verification by Light Clients > > - Because segOP uses a Merkle structure: SPV clients or=20 > oracles can request proofs for individual TLVs without downloading full= =20 > data. For example, a timestamp verifier can request: getsegopproof = =20 > and receive the TLV + Merkle proof + root verification path.= =20 > This makes segOP efficient for decentralized proof storage or timestampin= g=20 > protocols. > > 6. Spending a P2SOP Output > > - Spending a P2SOP output works like spending an OP_SUCCESS= =20 > output: Until activation, it behaves as anyone-can-spend, ensuring=20 > soft-fork safety. After activation, future consensus rules can restrict o= r=20 > redefine P2SOP redemption scripts. > - Example forward path: A future BIP may define OP_SUCCESS184= =20 > redemption to require proof of segOP validity or special conditions (e.g.= ,=20 > hash preimage commitments). Until then, nodes treat these outputs as vali= d=20 > spends, ensuring no forks. > > 7. Post-Activation Behavior > > - After segOP activation: All upgraded nodes enforce the 100= =20 > KB cap and Merkle root validation. > - Legacy nodes still accept the transactions, unaware of segO= P=20 > structure. > - Any mismatch between segOP section and root simply makes th= e=20 > tx invalid for upgraded miners =E2=80=94 thus ensuring consensus alignmen= t. > > Examples of segOP: > > Example 1: Timestamp a Document (50 KB) > TLV #1: Type =3D 1, Manifest (JSON) > TLV #2: Type =3D 2, PDF payload (50 KB) > Build Merkle root =E2=86=92 abc123... > Create output: > OP_SUCCESS184 0x20 abc123... > segOP section: > 0x02 # chunk count > > Fee: =E2=89=88 $30 at current full-fee rates > Permanent, verifiable, structured. > > Example 2: Ordinals Tries 3.8 MB > data_size =3D 3.8 MB =E2=86=92 REJECTED (exceeds 100 KB cap) > Attempt in witness =E2=86=92 REJECTED (data > 520 B =E2=86=92 ful= l fee policy =E2=86=92=20 > 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 =3D b'{"type":"proof","size":50000}' > payload =3D b'50 KB of data...' > tlv1 =3D varint(1) + varint(len(manifest)) + manifest > tlv2 =3D varint(2) + varint(len(payload)) + payload > > # 2. Build Merkle root > def dsha256(x): return sha256(sha256(x)).digest() > leaf1 =3D dsha256(b'\x00' + tlv1) > leaf2 =3D dsha256(b'\x00' + tlv2) > root =3D dsha256(b'\x01' + leaf1 + leaf2) > > # 3. Create P2SOP output > p2sop =3D b'\xb8\x20' + root > > # 4. Build segOP section > segop =3D b'\xFA' + varint(2) + tlv1 + tlv2 # 0xFA marker > > # 5. Attach to tx > tx.vout.append(CTxOut(0, CScript(p2sop))) > tx.segop_section =3D segop > > Validation Logic (C++ Pseudocode): > > bool CheckSegOP(const CTransaction& tx) { > size_t total_data =3D 0; > > for (const auto& out : tx.vout) { > if (out.scriptPubKey[0] =3D=3D OP_SUCCESS184) { > // segOP output detected > if (!tx.HasSegOPSection()) return false; > total_data +=3D tx.segOPSectionSize(); > } > if (out.scriptPubKey[0] =3D=3D OP_RETURN &&=20 > out.scriptPubKey.size() > 1) { > total_data +=3D out.scriptPubKey.size() - 1; > } > } > > for (const auto& in : tx.vin) { > for (const auto& item : in.scriptWitness.stack) { > if (item.size() > 520) > total_data +=3D item.size(); // witness data coun= ts=20 > fully > } > } > > if (total_data > 100000) return false; // 100 KB consensus ca= p > > // Apply full weight to data for fee calc > tx.virtual_size +=3D 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 =E2=80=94 total combined data =E2=89= =A4 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 need= s=20 > =E2=80=94 ending witness discount abuse while preserving freedom for legi= timate=20 > metadata. > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= a5ec8a97-3884-40eb-9276-8536f664c0e0n%40googlegroups.com. ------=_Part_127923_298848317.1761859525060 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all,

I thought more about this today. Please see update below= . Open to ideas and discussion.=C2=A0

KR

Defenwycke
# segOP : Segregated OP_RETURN # A Structured and Fee-Fair Data Extension for Bitcoin ## Technical Paper =E2=80=94 October 2025 ## Author : Defenwycke ## Abstract Bitcoin=E2=80=99s four-million-weight-unit block limit was meant to price b= lockspace fairly, yet Segregated Witness introduced an asymmetry: witness b= ytes cost one weight unit while base bytes cost four. That discount=E2=80=94intended for signatures=E2=80=94has become a subsidy = for arbitrary data. Large image and metadata =E2=80=9Cinscriptions=E2=80=9D now fill much of ea= ch block while paying a fraction of what monetary transactions pay. The result is a distorted fee market: blocks remain full but miners earn le= ss 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=E2=80=94fu= ll 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=E2=80=99s 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 = =C2=BC 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 lo= se fees, and block propagation slows. ### 1.2 Goal of segOP segOP re-introduces equal pricing. It doesn=E2=80=99t 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 | =C2=BC 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 00= 0 WU instead of 400 000 WU. Miners still fill blocks to 4 M WU, but earn less; users compete against di= scounted junk. The imbalance is economic, not cryptographic. ### 2.2 Consequences Fee market signal blurred =E2=80=94 cheap spam masks real demand. Throughput loss =E2=80=94 genuine tx count falls =E2=89=88 40=E2=80=9360 %. Revenue loss =E2=80=94 full blocks yield low fees. Propagation load =E2=80=94 bigger blocks take longer to relay. Without change, history repeats: larger chain, lower income, weaker incenti= ves. ## 3 Proposal =E2=80=94 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=E2=80=99t 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=E2=80=94no blacklists or heuristics needed. ### 3.3 Compatibility Old nodes ignore bit 0x02. txid excludes segOP data =E2=86=92 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 all= ows data to underpay for its size. =20 To understand its impact, we can model the block in three parts: normal tra= nsactions, discounted data (today=E2=80=99s reality), and segOP data (the p= roposed model). ### 4.1 Variables and Setup Let: - `Wb` =3D block weight limit =E2=86=92 4,000,000 weight units =20 - `Wtx` =3D average transaction weight =E2=86=92 600 weight units =20 - `S` =3D segOP payload size =E2=86=92 100,000 bytes =20 - `WsegOP` =3D segOP weight =3D 4 =C3=97 S =3D 400,000 weight units =20 - `f` =3D fee rate in satoshis per virtual byte (sat/vB) =20 We define the following relationships: FsegOP =3D f =C3=97 S T =3D (Wb - 400,000 =C3=97 n) / Wtx Fblock =3D n =C3=97 FsegOP + T =C3=97 (f =C3=97 150) Where: - `n` is the number of segOP payloads in a block. =20 - `FsegOP` is the fee paid by one segOP transaction. =20 - `Fblock` is the total fee income for the block. This gives a rough but useful estimate of how miner revenue scales when blo= cks contain different mixes of segOP data and normal transactions. ### 4.2 Scenario A =E2=80=94 Current Situation (Discounted Witness Data) In the current network, around sixty percent of block weight can be consume= d by discounted witness data. =20 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 aro= und 0.006 BTC in fees. The network looks busy, but most of the block is effectively subsidised sto= rage. ### 4.3 Scenario B =E2=80=94 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. =20 Assume three segOP payloads of 100 KB each per block. Under these conditions, the block includes roughly 4,600 normal transaction= s and produces around 0.013 BTC in total fees. =20 Miners earn more, users see more legitimate transactions confirmed, and blo= ckspace pricing becomes honest again. ### 4.4 Scenario C =E2=80=94 No Discounted Data If the network were used purely for monetary transactions, a full block wou= ld contain roughly 6,600 standard transactions at an average total fee of a= bout 0.010 BTC. =20 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=E2=80=99t require a new policy or central coordination=E2=80=94= it simply restores the natural balance of the fee market through equal pric= ing. ## 5 Behavioural and Economic Implications Spam deterrence =E2=80=94 once data costs full rate, stuffing blocks is une= conomic. Fair market =E2=80=94 every byte competes equally. Higher throughput =E2=80=94 fewer bloated transactions. Better miner income =E2=80=94 full blocks now mean full fees. Predictable propagation =E2=80=94 smaller, uniform payloads reduce latency. It=E2=80=99s a market fix, not a ban list. ## 6 Security and Consensus=20 ### 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 | =E2=89=A4 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 =3D 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 disr= uption. ## 8 Transaction Encoding=20 ### 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 =3D SegWit, 0x02 =3D segOP = =E2=86=92 0x03 =3D 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 =E2=80=9CSEGOP=E2=80=9D } } ], "witness": [ [ "3045...01", "02ab...cd" ] // standard sig + pubkey ], "segop": { "length": 1024, // total segOP bytes (=E2=89=A4100 0= 00) "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 =3D segop.length =C3=97 4. 4. Witness elements =E2=89=A4 520 B. 5. Fee =3D (base_vbytes + segop.length) =C3=97 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= =E2=80=99t need to host everyone=E2=80=99s 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 ca= n 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 t= hree 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. =20 At roughly 52,560 blocks per year, that equals about 52 gigabytes annually = or roughly 525 gigabytes per decade. =20 This represents the "clean" Bitcoin model =E2=80=94 payments only, no arbit= rary data. =20 It=E2=80=99s 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. =20 That comes to around 1.3 terabytes per decade, and it keeps climbing if lar= ge cheap data continues to fill every block. =20 In this world, node operators are forced to host other people=E2=80=99s con= tent indefinitely while earning less from fees =E2=80=94 unsustainable for = the long term. In the **segOP-priced and pruned model**, blocks still carry roughly 1 mega= byte of payment data, but they may also include up to 1 megabyte of segOP p= ayloads. =20 The key difference is that segOP data is fully paid for and can be safely p= runed after validation. =20 A node that keeps a two-week rolling window of segOP data (about 2,000 bloc= ks) would only need an additional 2 gigabytes of temporary disk space. =20 After pruning, the total long-term requirement stabilises near the same 525= -gigabyte range as the monetary-only case =E2=80=94 effectively holding the= line on growth. In short, segOP allows Bitcoin to support data-rich use cases **without** f= orcing every node to store terabytes of history. =20 Heavy users pay for their data, and those who want to keep it can, while ev= eryone else can prune and move on. ### 9.6 Integrity After Pruning Payloads may go, but commitments stay : block hashes still cover segOP root= s, headers prove existence, archives can re-serve data verifiable by hash. ### 9.7 Data Retention Layers ``` =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 BITCOIN NODE =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=82 =E2=96=BC =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 CORE CONSENSUS (UTXO + Headers) =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=82 =E2=96=BC =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 RECENT WINDOW (Blocks + Witness + segOP) =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=82 =E2=96=BC =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 PRUNED HISTORY (Old payloads deleted) =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=82 =E2=96=BC =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 ARCHIVE / ORACLE NODE (optional history) =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 ``` ### 9.8 Pruning Economics 10-year pruned node =E2=89=88 500 GB. 10-year archive =E2=89=88 1=E2=80=933 TB. Only voluntary archives bear that cost=E2=80=94 not everyone. ### 9.9 Data Ownership and Access Model Under current rules, full nodes host other people=E2=80=99s junk indefinite= ly. 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=E2=80=99t prune it. Archive (or oracle) nodes voluntarily retain all segOP payloads and offer t= hem 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=E2=80=99s data; each operator choos= es their own weight class. It=E2=80=99s fee fairness at inclusion and storage fairness after confirmat= ion =E2=80=94 a complete economic loop. ## 10 Operational Profiles ### 10.1 Profile A =E2=80=94 Home Node Light validation on small hardware. `-prune=3D550` `-prunesegop=3D1` `-prunesegopheight=3D2016` Keeps two weeks of history; fully validating; tiny disk footprint. ### 10.2 Profile B =E2=80=94 Mining / Economic Node `-prune=3D20000` `-prunesegop=3D1` `-prunesegopheight=3D8064` `-keepsegopcommitments=3D1` Keeps 3 months of segOP for fee analysis and template testing. ### 10.3 Profile C =E2=80=94 Archive / Oracle Node `-prune=3D0` `-prunesegop=3D0` `-keepsegopcommitments=3D1` Stores everything, serves API or Lightning requests, earns sats for data. ### 10.4 Profile D =E2=80=94 Enterprise / Auditor `-prune=3D0` `-prunesegop=3D1` `-prunesegopheight=3D40320` 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=E2=80=933 months | Approx. 1 TB (deca= de) | Analytics | | C | Archive | Keep forever | Approx. 1=E2=80=933 TB (de= cade) | 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 diversif= ies but remains coherent: light nodes stay light, heavy nodes get paid, eve= ryone 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=E2=80=99s monetary rules=E2=80=94just how = data is metered. By isolating large payloads into a capped, fully-priced lane, it removes sp= am 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=E2=80=99s all. The outcome: smaller chainstate, stronger miners, faster propagation, and f= airer 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 =3D 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), 20= 25.

On Wednesday, October 29, 2025 at 11:55:52=E2=80=AFPM UTC defe= nwycke wrote:
Hi all,

I attempted to propose a BI= P earlier today. I was notified of my incorrect actions versus core procedu= res.

See attached or below - my proposal for discussion.

Regards

Defenwycke.

---

A proposed discussion of segOP
Author: Defenwycke /=C2=A0defen...@icloud.com=
29.10.2= 025

segOP (Segregat= ed OP_RETURN)
=C2= =A0=C2=A0=C2=A0 A proposed extension to Bitcoin transactions. It introduces= a dedicated, structured, full-fee data lane for on-chain data, without dis= rupting existing transaction rules. Think of it like this - segOP is to arb= itrary data what SegWit was to signatures =E2=80=94 a clean, isolated, forw= ard-compatible path that preserves old-node harmony while restoring fee fai= rness.

<= /div>
Abstract:

=C2=A0=C2=A0=C2=A0 se= gOP defines a new segregated data section for Bitcoin transactions, cryptog= raphically committed via OP_SUCCESS184. It standardizes on-chain metadata s= torage by enforcing full fees, structured TLV encoding, and a 100 KB cap, w= hile remaining backward-compatible with legacy nodes.

It is not:

=C2=A0=C2=A0=C2=A0 - A replacement for OP_RETURN=
=C2=A0=C2= =A0=C2=A0 - An off-chain mechanism
=C2=A0=C2=A0=C2=A0 - A hard fork

It is:

=C2=A0=C2=A0=C2=A0 - A soft-fork-safe, future-proo= f, SegWit-style data section
=C2=A0=C2=A0=C2=A0 - Full-fee (4 weight units per byte)
=C2=A0=C2=A0= =C2=A0 - Structured (TLV + Merkle-root verified)
=C2=A0=C2=A0=C2=A0 - Limited to 100 KB= per transaction

Wh= at issues could segOP rectify?:

=C2=A0=C2=A0=C2=A0 1. Ordinals abuse witness discount. segOP w= ill apply full fee rate for large data.
=C2=A0=C2=A0=C2=A0 2. No structured metadata la= ne. segOP introduces TLV-encoded + Merkle-verified section.
=C2=A0=C2=A0=C2=A0 3. Witne= ss discount abused for megabytes. segOP Enforces 100 KB cap.
=C2=A0=C2=A0=C2=A0 4. OP_R= ETURN unstructured & limited. segOP =3D structured + verifiable.
<= div style=3D"color:rgba(0,0,0,0.88);font-family:"SF Pro Text",sys= tem-ui,sans-serif;font-size:17px;letter-spacing:-0.37px">=C2=A0=C2=A0=C2=A0= 5. Spam cheap storage. segOP deters spam with fees.

=C2=A0=C2=A0=C2=A0 In short - segOP resto= res fairness =E2=80=94 data pays its real weight cost, preserving block spa= ce for financial use.

Where segOP lives:

=C2=A0=C2=A0=C2=A0 Transaction Layout (Post-segOP)
=C2=A0=C2=A0=C2=A0 Transaction
=C2=A0=C2=A0= =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 nVersion
=C2=A0=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94= =80 vin (inputs)
=C2=A0=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 vout (outputs)
=C2=A0=C2=A0=C2=A0 = =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 P2SOP Output =E2=86=90 se= gOP anchor
= =C2=A0=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 witness (if any)
=C2=A0=C2=A0=C2=A0 =E2= =94=9C=E2=94=80=E2=94=80 segOP marker (0xFA)
=C2=A0=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2= =94=80 segOP section (if present)
=C2=A0=C2=A0=C2=A0 =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2= =94=80=E2=94=80 chunk_count (varint)
=C2=A0=C2=A0=C2=A0 =E2=94=82=C2=A0=C2=A0 =E2=94=9C= =E2=94=80=E2=94=80 TLV chunk 1
=C2=A0=C2=A0=C2=A0 =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94= =80=E2=94=80 TLV chunk 2
=C2=A0=C2=A0=C2=A0 =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2= =94=80 ...
= =C2=A0=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 nLockTime

Activation rules:

=C2=A0=C2=A0=C2=A0 - segOP section onl= y appears if at least one P2SOP output exists.
=C2=A0=C2=A0=C2=A0 - Old nodes ignore un= known post-witness data =E2=86=92 transaction valid (soft-fork safe).
=
=C2=A0=C2=A0=C2= =A0 - New nodes validate the segOP section against the Merkle root in the P= 2SOP output.

How se= gOP works:
<= br>
=C2=A0= =C2=A0=C2=A0 segOP extends the Bitcoin transaction format by adding a new o= ptional section after the witness field.
=C2=A0=C2=A0=C2=A0 This section is linked cryp= tographically to a special output type =E2=80=94 the P2SOP output =E2=80=94= whose script commits to the Merkle root of the segOP data.

=C2=A0=C2=A0=C2=A0 The design mirr= ors SegWit: a segregated data structure, excluded from txid but included in= wtxid, ensuring backward compatibility.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1. Transac= tion Creation
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When a wall= et or protocol wants to include on-chain structured data (for example, a do= cument hash, timestamp, or proof set), it performs the following steps:

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a. Bu= ild TLV Chunks

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Each data element is encoded in Type-L= ength-Value (TLV) format:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - = type (varint)
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - value (by= tes)

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Each type defines a data meaning (e.g., type=3D= 1: manifest, type=3D2: payload, type=3D3: metadata, etc.). This allows futu= re extensions without breaking parsers.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b. Construct the Merkle Tree

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Each TLV is hashed as:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf =3D dsha256(= 0x00 || TLV)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and combined recursively:
<= div style=3D"color:rgba(0,0,0,0.88);font-family:"SF Pro Text",sys= tem-ui,sans-serif;font-size:17px;letter-spacing:-0.37px">=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 node =3D dsha256(0x01 || left || right)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 until a single Merkle root is produced. This root uniquely commit= s to all TLV data while allowing compact partial proofs.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c. Commit to the Roo= t (P2SOP Output)

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The wallet then inserts a special o= utput into the transaction: scriptPubKey =3D OP_SUCCESS184 0x20 <32-byte= Merkle root> (OP_SUCCESS184 is reserved for soft-fork activation).
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Legacy nodes treat it as =E2=80=9Calways true,=E2= =80=9D so the transaction remains spendable under pre-segOP rules.
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 The 32-byte push commits to the root of the segOP sec= tion.
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Multiple P2SOP outputs may exist if a tra= nsaction carries multiple data trees, but each must be validated independen= tly.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 d. Serialize the segOP Section

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 After the witness= data, a segOP marker (0xFA) signals presence, followed by the serialized d= ata:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 0xFA
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 varint: chunk_= count
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [TLV #1]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [T= LV #2]
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This sectio= n is included in the wtxid but not the txid, keeping legacy hashes unchange= d (soft-fork compatible).

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2. Transaction Relay and = Policy

<= /div>
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 segOP transactions a= re relayed like any other, with a few policy rules:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Size limit: The total si= ze of segOP data (plus OP_RETURN + witness data >520 B) must not exceed = 100,000 bytes. This prevents block bloat.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Fee treatment: segOP data c= ounts at 4 weight units per byte (no discount), restoring parity between da= ta and signatures.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 - Standardness check: Non-mining nodes enforce seg= OP as a standard policy rule (like SegWit=E2=80=99s P2WSH), rejecting nonco= mpliant data from mempool relay.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 These are policy rules, not consensus, but m= iners enforcing them makes segOP behavior uniform across the network.
=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 3. Validation (Node-Level)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 When a segOP transaction reaches a full node, validation= happens in three stages:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 a. Detect segOP Presence

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - = If any output script begins with OP_SUCCESS184, the node checks for a corre= sponding segOP section at the end of the transaction serialization.
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - If no segOP section is found =E2=86=92 transaction = invalid under segOP rules.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 b. Verify Size and Fee

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The n= ode computes total data size:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 - All OP_RETURN payloads
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 - All segOP TLVs
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 - All witness items >520 bytes (these count as =E2=80=9Cdata=E2=80= =9D)
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - If this exceeds= 100 KB, the transaction is invalid.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 - The total weight is adjusted to include all segOP bytes a= t full cost.

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 c. Verify Merkle Root

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - The node rebuilds = the TLV Merkle tree and ensures:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - calculated_r= oot =3D=3D <root in P2SOP output>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - If = the root mismatches =E2=86=92 reject.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - This m= akes segOP cryptographically bound to the transaction body, just like Tapro= ot commits to script paths.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4. Inclusion in a Block=

<= div style=3D"color:rgba(0,0,0,0.88);font-family:"SF Pro Text",sys= tem-ui,sans-serif;font-size:17px;letter-spacing:-0.37px">=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Miners include segOP tra= nsactions normally.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = - When calculating block weight: segOP bytes count fully (4 WU/byte).
=
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - segOP does not alter = the legacy 4M weight limit but competes fairly for space.
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Miners can optionally expose segO= P data through RPC or indexing APIs (e.g., gettxoutdata), similar to how th= ey expose witness data.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5. Verification by Light Cl= ients

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Because segOP uses= a Merkle structure: SPV clients or oracles can request proofs for individu= al TLVs without downloading full data. For example, a timestamp verifier ca= n request: getsegopproof <txid> <chunk_type> and receive the TL= V + Merkle proof + root verification path. This makes segOP efficient for d= ecentralized proof storage or timestamping protocols.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 6. Spending a P2SOP Output

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 - Spending a P2SOP output works like spending an OP_SUCCESS output: Unt= il activation, it behaves as anyone-can-spend, ensuring soft-fork safety. A= fter activation, future consensus rules can restrict or redefine P2SOP rede= mption scripts.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Ex= ample forward path: A future BIP may define OP_SUCCESS184 redemption to req= uire proof of segOP validity or special conditions (e.g., hash preimage com= mitments). Until then, nodes treat these outputs as valid spends, ensuring = no forks.
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7. Post-Activation Behavior

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - After segOP activation: All upgraded= nodes enforce the 100 KB cap and Merkle root validation.
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Legacy nodes still accept the tra= nsactions, unaware of segOP structure.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 - Any mismatch between segOP section and root simply mak= es the tx invalid for upgraded miners =E2=80=94 thus ensuring consensus ali= gnment.

=
Examples of= segOP:

=
=C2=A0=C2= =A0=C2=A0 Example 1: Timestamp a Document (50 KB)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 TLV #1: Type =3D 1, Manifest (JSON)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T= LV #2: Type =3D 2, PDF payload (50 KB)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Build= Merkle root =E2=86=92 abc123...
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Create outp= ut:
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OP_SUCCESS184 0x20 abc123...
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 segOP section:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x02=C2= =A0 # chunk count
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <TLV1> <TLV2><= /div>
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fee: =E2=89=88 $30 at current full-fee rates=
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Permanent, verifiable, structured.
<= div style=3D"color:rgba(0,0,0,0.88);font-family:"SF Pro Text",sys= tem-ui,sans-serif;font-size:17px;letter-spacing:-0.37px">
=C2=A0=C2=A0=C2=A0 Exampl= e 2: Ordinals Tries 3.8 MB
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data_size =3D 3.8= MB =E2=86=92 REJECTED (exceeds 100 KB cap)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Attempt in witness =E2=86=92 REJECTED (data > 520 B =E2=86=92 full fee p= olicy =E2=86=92 cap still enforced)

=C2=A0=C2=A0=C2=A0 Example 3: Normal BTC Send
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 No P2SOP output : No segOP section
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Fee Unchanged (~$0.09)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Normal tran= sactions unaffected.


=C2=A0=C2=A0=C2=A0 Build a segOP Transaction (Python)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 # 1. Prepare TLV chunks
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 manifest =3D b&#= 39;{"type":"proof","size":50000}'
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 payload=C2=A0 =3D b'50 KB of data...'
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 tlv1 =3D varint(1) + varint(len(manifest)) + ma= nifest
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tlv2 =3D varint(2) + varint(len(pay= load)) + payload

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # 2. Build Merkle root
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 def dsha256(x): return sha256(sha256(x)).digest()
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf1 =3D dsha256(b'\x00' + tlv1)
=
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf2 =3D dsha256(b'\x00' + tlv2)
=
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 root=C2=A0 =3D dsha256(b'\x01' + leaf1 = + leaf2)
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # 3. Create P2SOP output
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 p2sop =3D b'\xb8\x20' + root

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 # 4. Build segOP section
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 segop =3D b'= ;\xFA' + varint(2) + tlv1 + tlv2=C2=A0 # 0xFA marker

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 # 5. Attach to tx
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tx.vout.append(CTxO= ut(0, CScript(p2sop)))
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tx.segop_section =3D = segop

=C2=A0=C2=A0= =C2=A0 Validation Logic (C++ Pseudocode):

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bool Chec= kSegOP(const CTransaction& tx) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 size_t total_data =3D 0;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 for (const auto& out : tx.vout) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (out.script= PubKey[0] =3D=3D OP_SUCCESS184) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // segOP ou= tput detected
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 total_data +=3D tx.segOPSectionSize();=
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 }
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 if (out.scriptPubKey[0] =3D=3D OP_RETURN && out.script= PubKey.size() > 1) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 total_data +=3D out.scr= iptPubKey.size() - 1;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 }
=
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (const aut= o& in : tx.vin) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 for (const auto& item : in.scriptWitness.st= ack) {
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (item.size() > 520)
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 total_data +=3D item.size(); // wit= ness data counts fully
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 }
=
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (total_data= > 100000) return false; // 100 KB consensus cap

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 // Apply full weight to data for fee calc
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tx.virtual_size +=3D total= _data;
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return true= ;
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

Soft Fork Proof:

=C2=A0=C2=A0=C2=A0 - Old node: Ignores segOP
=C2=A0=C2=A0=C2=A0 - New no= de: Validates segOP
=C2=A0=C2=A0=C2=A0 - No chain split
=C2=A0=C2=A0=C2=A0 - Backward compatible
=C2=A0=C2=A0= =C2=A0 - Miner-activated soft fork possible via versionbits

Developer Q&A:

=C2=A0=C2=A0=C2=A0 Where is segOP = serialized? : After witness, before nLockTime
=C2=A0=C2=A0=C2=A0 Does it affect txid? := No - only wtxid
=C2=A0=C2=A0=C2=A0 Can old nodes parse it? : Yes (ignored like witness= )
=C2=A0=C2= =A0=C2=A0 Max size? : 100 KB total data
=C2=A0=C2=A0=C2=A0 Fee rate? : Full fee (4 WU/b= yte)
=C2=A0= =C2=A0=C2=A0 Can I use OP_RETURN too? : Yes =E2=80=94 total combined data = =E2=89=A4 100 KB
=C2=A0=C2=A0=C2=A0 Future extensions? : TLV unknown types ignored (saf= e forward-compat)
=C2=A0=C2=A0=C2=A0 How do I signal presence? : 0xFA marker after witn= ess


Conclusion:

=C2=A0=C2=A0=C2=A0 - On-cha= in
=C2=A0=C2= =A0=C2=A0 - Structured (TLV + Merkle)
=C2=A0=C2=A0=C2=A0 - Full-fee and fair
=C2=A0=C2=A0=C2=A0 - S= oft-fork safe

=C2=A0=C2=A0=C2=A0 segOP introduces the clean, capped, ver= ifiable data lane Bitcoin needs =E2=80=94 ending witness discount abuse whi= le preserving freedom for legitimate metadata.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/a5ec8a97-3884-40eb-9276-8536f664c0e0n%40googlegroups.com.
------=_Part_127923_298848317.1761859525060-- ------=_Part_127922_921181906.1761859525060--