Delivery-date: Mon, 29 Sep 2025 17:11:57 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62d as permitted sender) client-ip=2a00:1450:4864:20::62d;
MIME-Version: 1.0
References: <GDC-d847c0e8-4e35-40c5-87e7-2ab89e13ea09@google.com>
In-Reply-To: <GDC-d847c0e8-4e35-40c5-87e7-2ab89e13ea09@google.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 29 Sep 2025 17:09:15 -0700
Message-ID: <CAJowKgLE4kb7qT1NxXrmEssr8+fQGd-=7=m-BAsjePoti8TRRg@mail.gmail.com>
Subject: [bitcoindev] OP_CHECKUTXOSETHASH idea
To: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000a4ee0e063ff9902e"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--000000000000a4ee0e063ff9902e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allowing
miners to optionally commit a deterministic hash of the current UTXO set
into a block. If present, all nodes must verify its correctness or reject
the block; if absent, the block is still valid. Old nodes treat the opcode
as unspendable, so backward compatibility is preserved.

Because computing the full UTXO root is costly, this makes each checkpoint
intentionally expensive to produce, ensuring that miners will only include
them when compensated with sufficient fees. Additionally, it could be
limited to one per block.

The result is a voluntary, self-limiting, incentive-aligned, fee-driven
system where checkpoints are cheaply consensus-enforced when included but
never mandatory.

Most nodes could operate on a rolling history validated by occasional,
high-value commitments, while archival nodes remain free to preserve the
full chain. This reduces the burden of initial sync and resource use
without sacrificing Bitcoin=E2=80=99s security model, since any invalid che=
ckpoint
would invalidate its block.

In practice, the chain becomes more efficient for everyday use while the
historical record remains intact for those willing to bear the expense of
maintaining it.

--=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/=
CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePoti8TRRg%40mail.gmail.com.

--000000000000a4ee0e063ff9902e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">A soft fork could introduce a new opcode, `OP_CHECKUTXOSE=
THASH`, allowing miners to optionally commit a deterministic hash of the cu=
rrent UTXO set into a block. If present, all nodes must verify its correctn=
ess or reject the block; if absent, the block is still valid. Old nodes tre=
at the opcode as unspendable, so backward compatibility is preserved.=C2=A0=
<div dir=3D"auto"><br></div><div dir=3D"auto">Because computing the full UT=
XO root is costly, this makes each checkpoint intentionally expensive to pr=
oduce, ensuring that miners will only include them when compensated with su=
fficient fees. Additionally, it could be limited to one per block.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">The result is a voluntary, self-=
limiting, incentive-aligned, fee-driven system where checkpoints are cheapl=
y consensus-enforced when included but never mandatory.=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Most nodes could operate on a rolling=
 history validated by occasional, high-value commitments, while archival no=
des remain free to preserve the full chain. This reduces the burden of init=
ial sync and resource use without sacrificing Bitcoin=E2=80=99s security mo=
del, since any invalid checkpoint would invalidate its block.=C2=A0</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">In practice, the chain becomes =
more efficient for everyday use while the historical record remains intact =
for those willing to bear the expense of maintaining it.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto"><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePoti8TRRg%40mail=
.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.co=
m/d/msgid/bitcoindev/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePoti8T=
RRg%40mail.gmail.com</a>.<br />

--000000000000a4ee0e063ff9902e--