From: Eric Voskuil <eric@voskuil.org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: OP_CHECKUTXOSETHASH idea
Date: Sun, 16 Nov 2025 11:11:16 -0800 (PST) [thread overview]
Message-ID: <76c1b5a1-5b78-4576-981f-4df69aefc9a6n@googlegroups.com> (raw)
In-Reply-To: <CAJowKgLE4kb7qT1NxXrmEssr8+fQGd-=7=m-BAsjePoti8TRRg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2923 bytes --]
Hi Erik,
> 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 is an old big-blocker idea, and still a terrible one. It effectively
reduces what we now call validation to majority hash power control. IOW
functionally equivalent to SPV. A few actual full nodes (maybe) validating
does not have the implied effect. For a node's validation to matter, the
node has to be accepting coin in trade. SPV entirely relies on the
presumption that a very large portion of economic activity is actually
validated. Very large means enough that majority hash power has a true
disincentive to intentionally mine invalid blocks, despite the reward for
doing so (e.g. unlimited inflation). What you are calling "archival nodes"
don't actually "preserve the full chain" for everyone else, because their
effect is limited to their own transactions. Otherwise we are talking about
fraud proofs, which is a conversation that doesn't end well.
> Because computing the full UTXO root is costly...
It is not, it's getting cheaper every year.
e
On Monday, September 29, 2025 at 8:11:51 PM UTC-4 Erik Aronesty 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/76c1b5a1-5b78-4576-981f-4df69aefc9a6n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3606 bytes --]
prev parent reply other threads:[~2025-11-16 19:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <GDC-d847c0e8-4e35-40c5-87e7-2ab89e13ea09@google.com>
2025-09-30 0:09 ` [bitcoindev] " Erik Aronesty
2025-10-02 22:40 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-02 23:39 ` Erik Aronesty
2025-10-03 16:12 ` Peter Todd
2025-10-03 22:15 ` Erik Aronesty
2025-11-16 19:11 ` Eric Voskuil [this message]
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=76c1b5a1-5b78-4576-981f-4df69aefc9a6n@googlegroups.com \
--to=eric@voskuil.org \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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