Delivery-date: Thu, 02 Oct 2025 16:42:29 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::633 as permitted sender) client-ip=2a00:1450:4864:20::633;
MIME-Version: 1.0
References: <GDC-d847c0e8-4e35-40c5-87e7-2ab89e13ea09@google.com>
 <CAJowKgLE4kb7qT1NxXrmEssr8+fQGd-=7=m-BAsjePoti8TRRg@mail.gmail.com> <yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqylyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0=@protonmail.com>
In-Reply-To: <yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqylyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 2 Oct 2025 16:39:51 -0700
Message-ID: <CAJowKg+et-84+BvkwE=Kjkms-gX-2peT+jvDJSXbHT-MLXan7w@mail.gmail.com>
Subject: Re: [bitcoindev] OP_CHECKUTXOSETHASH idea
To: moonsettler <moonsettler@protonmail.com>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000e3062f0640358095"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

I agree, this doesn=E2=80=99t belong in general script where it could creat=
e
mempool weirdness; also the DoS surface is real if checkpoints can be
demanded arbitrarily.

Verification isn=E2=80=99t nearly as heavy as you suggest though. Every val=
idating
node already maintains the UTXO set; computing the salted hash once per
epoch is basically a linear scan with caching.  Incremental hashing
techniques can make it even faster.

To reduce attack surface: commitment in the coinbase only, at most once per
difficulty epoch. No mempool footprint, no risk of pinning attacks, and no
repeat scanning.  Nodes just compute and cache the root when they process
the epoch=E2=80=99s first block, then check a 32-byte value at the epoch=E2=
=80=99s end.
Producing that root is still expensive enough to require real incentives
(sponsor still has to pay for it, and that's OK) - checking it is trivial.

Voluntary and expensive to make, cheap to verify, consensus-enforced if
present but never mandatory. Miners and sponsors decide if it=E2=80=99s wor=
th
burning the cycles, nodes get a safe fast-sync path.

The key ingredient is sponsor-paid-work.  This thing disappears if nobody
wants to pay for it or mine it.

On Thu, Oct 2, 2025 at 3:40=E2=80=AFPM moonsettler <moonsettler@protonmail.=
com>
wrote:

> Hi Erik,
>
> Since it is costly for nodes to compute, this is a bit of a DOS vector. I
> would suggest to limit UTXO set commitments to every 2016 blocks (either
> the first or the last block of a difficult adjustment epoch).
>
> If it checks the UTXO set commitment of a previous block, it will not
> interfere with mining, for example always commit to the initial state of
> the difficult adjustment epoch at the end of the epoch. The hash can be
> calculated well in advance. It also would be the same in every check, so
> it's not possible to use it for denial of service.
>
> It's a bit interesting that the script can not be fully validated before
> it hits an actual block. It also allows for submitting a transaction into
> the mempool that might be invalid to mine, that needs additional steps fo=
r
> eviction. Wonder if this allows for weird new pinning attacks for free?
>
> Overall I have low confidence that this belongs in script instead of the
> coinbase transaction structure via a more specific soft fork.
>
> BR,
> moonsettler
>
> On Tuesday, September 30th, 2025 at 2:11 AM, Erik Aronesty <erik@q32.com>
> wrote:
>
> > 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 th=
e
> 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 c=
heckpoint
> would invalidate its block.
> >
> > In practice, the chain becomes more efficient for everyday use while th=
e
> historical record remains intact for those willing to bear the expense of
> maintaining it.
> >
> >
> >
> > --
> > 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/CAJowKgLE4kb7qT1NxXrmEssr8%2=
BfQGd-%3D7%3Dm-BAsjePoti8TRRg%40mail.gmail.com
> .
>

--=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/=
CAJowKg%2Bet-84%2BBvkwE%3DKjkms-gX-2peT%2BjvDJSXbHT-MLXan7w%40mail.gmail.co=
m.

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

<div dir=3D"ltr"><p>I agree, this doesn=E2=80=99t belong in general script =
where it could create mempool weirdness; also the DoS surface is real if ch=
eckpoints can be demanded arbitrarily.=C2=A0 <br><br>Verification isn=E2=80=
=99t nearly as heavy as you suggest though. Every validating node already m=
aintains the UTXO set; computing the salted hash once per epoch is basicall=
y a linear scan with caching.=C2=A0 Incremental hashing techniques can make=
 it even faster.</p>
<p>To reduce attack surface: commitment in the coinbase only, at most once =
per difficulty epoch. No mempool footprint, no risk of pinning attacks, and=
 no repeat scanning.=C2=A0 Nodes just compute and cache the root when they =
process the epoch=E2=80=99s first block, then check a 32-byte value at the =
epoch=E2=80=99s end. Producing that root is still expensive enough to requi=
re real incentives (sponsor still has to pay for it, and that&#39;s OK) - c=
hecking it is trivial.</p>
<p>Voluntary and expensive to make, cheap to verify, consensus-enforced if =
present but never mandatory. Miners and sponsors decide if it=E2=80=99s wor=
th burning the cycles, nodes get a safe fast-sync path.<br><br>The key ingr=
edient is sponsor-paid-work.=C2=A0 This thing disappears if nobody wants to=
 pay for it or mine it.</p></div><br><div class=3D"gmail_quote gmail_quote_=
container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 2, 2025 at 3:4=
0=E2=80=AFPM moonsettler &lt;<a href=3D"mailto:moonsettler@protonmail.com">=
moonsettler@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">Hi Erik,<br>
<br>
Since it is costly for nodes to compute, this is a bit of a DOS vector. I w=
ould suggest to limit UTXO set commitments to every 2016 blocks (either the=
 first or the last block of a difficult adjustment epoch).<br>
<br>
If it checks the UTXO set commitment of a previous block, it will not inter=
fere with mining, for example always commit to the initial state of the dif=
ficult adjustment epoch at the end of the epoch. The hash can be calculated=
 well in advance. It also would be the same in every check, so it&#39;s not=
 possible to use it for denial of service.<br>
<br>
It&#39;s a bit interesting that the script can not be fully validated befor=
e it hits an actual block. It also allows for submitting a transaction into=
 the mempool that might be invalid to mine, that needs additional steps for=
 eviction. Wonder if this allows for weird new pinning attacks for free?<br=
>
<br>
Overall I have low confidence that this belongs in script instead of the co=
inbase transaction structure via a more specific soft fork.<br>
<br>
BR,<br>
moonsettler<br>
<br>
On Tuesday, September 30th, 2025 at 2:11 AM, Erik Aronesty &lt;<a href=3D"m=
ailto:erik@q32.com" target=3D"_blank">erik@q32.com</a>&gt; wrote:<br>
<br>
&gt; A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allow=
ing miners to optionally commit a deterministic hash of the current UTXO se=
t 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.<br>
&gt; Because computing the full UTXO root is costly, this makes each checkp=
oint intentionally expensive to produce, ensuring that miners will only inc=
lude them when compensated with sufficient fees. Additionally, it could be =
limited to one per block.<br>
&gt; <br>
&gt; The result is a voluntary, self-limiting, incentive-aligned, fee-drive=
n system where checkpoints are cheaply consensus-enforced when included but=
 never mandatory.<br>
&gt; <br>
&gt; Most nodes could operate on a rolling history validated by occasional,=
 high-value commitments, while archival nodes remain free to preserve the f=
ull chain. This reduces the burden of initial sync and resource use without=
 sacrificing Bitcoin=E2=80=99s security model, since any invalid checkpoint=
 would invalidate its block.<br>
&gt; <br>
&gt; In practice, the chain becomes more efficient for everyday use while t=
he historical record remains intact for those willing to bear the expense o=
f maintaining it.<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" t=
arget=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
&gt; To view this discussion visit <a href=3D"https://groups.google.com/d/m=
sgid/bitcoindev/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePoti8TRRg%4=
0mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
.com/d/msgid/bitcoindev/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePot=
i8TRRg%40mail.gmail.com</a>.<br>
</blockquote></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/CAJowKg%2Bet-84%2BBvkwE%3DKjkms-gX-2peT%2BjvDJSXbHT-MLXan7w%40ma=
il.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/d/msgid/bitcoindev/CAJowKg%2Bet-84%2BBvkwE%3DKjkms-gX-2peT%2BjvDJSXbHT-=
MLXan7w%40mail.gmail.com</a>.<br />

--000000000000e3062f0640358095--