From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Erik Aronesty <erik@q32•com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] OP_CHECKUTXOSETHASH idea
Date: Thu, 02 Oct 2025 22:40:00 +0000 [thread overview]
Message-ID: <yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqylyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0=@protonmail.com> (raw)
In-Reply-To: <CAJowKgLE4kb7qT1NxXrmEssr8+fQGd-=7=m-BAsjePoti8TRRg@mail.gmail.com>
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 for 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 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’s security model, since any invalid checkpoint 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.
>
>
>
> --
> 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%2BfQGd-%3D7%3Dm-BAsjePoti8TRRg%40mail.gmail.com.
--
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/yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqylyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0%3D%40protonmail.com.
next prev parent reply other threads:[~2025-10-02 22:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <GDC-d847c0e8-4e35-40c5-87e7-2ab89e13ea09@google.com>
2025-09-30 0:09 ` Erik Aronesty
2025-10-02 22:40 ` 'moonsettler' via Bitcoin Development Mailing List [this message]
2025-10-02 23:39 ` Erik Aronesty
2025-10-03 16:12 ` Peter Todd
2025-10-03 22:15 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqylyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=erik@q32$(echo .)com \
--cc=moonsettler@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox