Delivery-date: Thu, 02 Oct 2025 15:45:55 -0700
Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 109.224.244.24 as permitted sender) client-ip=109.224.244.24;
Date: Thu, 02 Oct 2025 22:40:00 +0000
To: Erik Aronesty <erik@q32.com>
From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] OP_CHECKUTXOSETHASH idea
Message-ID: <yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqylyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0=@protonmail.com>
In-Reply-To: <CAJowKgLE4kb7qT1NxXrmEssr8+fQGd-=7=m-BAsjePoti8TRRg@mail.gmail.com>
References: <GDC-d847c0e8-4e35-40c5-87e7-2ab89e13ea09@google.com> <CAJowKgLE4kb7qT1NxXrmEssr8+fQGd-=7=m-BAsjePoti8TRRg@mail.gmail.com>
Feedback-ID: 38540639:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Reply-To: moonsettler <moonsettler@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hi Erik,

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).

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's not pos=
sible 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 for evi=
ction. Wonder if this allows for weird new pinning attacks for free?

Overall I have low confidence that this belongs in script instead of the co=
inbase transaction structure via a more specific soft fork.

BR,
moonsettler

On Tuesday, September 30th, 2025 at 2:11 AM, Erik Aronesty <erik@q32.com> w=
rote:

> A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allowing=
 miners to optionally commit a deterministic hash of the current UTXO set i=
nto a block. If present, all nodes must verify its correctness or reject th=
e 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 checkpoin=
t intentionally expensive to produce, ensuring that miners will only includ=
e them when compensated with sufficient fees. Additionally, it could be lim=
ited to one per block.
>=20
> The result is a voluntary, self-limiting, incentive-aligned, fee-driven s=
ystem where checkpoints are cheaply consensus-enforced when included but ne=
ver mandatory.
>=20
> Most nodes could operate on a rolling history validated by occasional, hi=
gh-value commitments, while archival nodes remain free to preserve the full=
 chain. This reduces the burden of initial sync and resource use without sa=
crificing Bitcoin=E2=80=99s security model, since any invalid checkpoint wo=
uld invalidate its block.
>=20
> In practice, the chain becomes more efficient for everyday use while the =
historical record remains intact for those willing to bear the expense of m=
aintaining it.
>=20
>=20
>=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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePoti8TRRg%40mail.gmail.co=
m.

--=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/=
yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqy=
lyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0%3D%40protonmail.com.