From: Sjors Provoost <sjors@sprovoost.nl>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Fabian <fjahr@protonmail.com>, eric@voskuil.org
Subject: Re: [bitcoindev] [BIP Draft] P2P UTXO Set Sharing
Date: Mon, 22 Jun 2026 20:43:47 +0200 [thread overview]
Message-ID: <A7B1ECA8-4DCF-4AAC-9FC4-0820C199A0DC@sprovoost.nl> (raw)
In-Reply-To: <02c201dce227$e808e050$b81aa0f0$@voskuil.org>
Hi Fabian, Eric and list,
It may be useful to analyse this with the following long term idea in mind:
1. Consider a node that's instantly on. By "on" I mean being able to verify an incoming transaction, with increasing confidence as the node gathers more information.
This allows you to take action, in response to the transaction, earlier then if you wait for 100% confidence. If 100% is the minimum acceptable level, the scheme is strictly worse, because you'll end up downloading more.
2. The best way to build such a node is with backward (block) validation. This can be done if blocks both _commit_ to the UTXO set and _contain_ everything needed to validate their state transition [0].
A new user could start with just a transaction, block hash and height, received out-of-bound from the sender. They should have zero confidence at this point.
Their node starts out with a zero knowledge proof for a header chain up to a recent height, downloads the remaining headers up to the block, then the block itself. They now have more confidence this a real transaction, but still less than SPV.
Now the node does a full header sync, now confidence is at SPV.
Then it syncs backward to whenever the commitments were first introduced. This gradually increases confidence further.
Then finally it forward-syncs the first million or so blocks from genesis. Now you're at 100%.
In this scheme a fraud proof is the block itself. Nodes can gossip block hashes as fraud hints. So a node can _disprove_ transaction validity quicker one can with just linear validation (in either direction).
(Unfortunately this degrades to a worst case of having to validate every block anyway, because your peers claim they're all invalid. It could be mitigated by disconnecting a peer if they make a false claim, and prioritising fraud-hints from outbound peers.)
3. Humans being what they are, they're going to stop somewhere (too early) in this process.
That applies to the above scenario, but also to the present AssumeUTXO implementation. It's reasonable to assume that many people would either delay validating deep history, or permanently skip it.
It doesn't matter whether the Bitcoin Core project supports that (discussed elsewhere in the thread). It's a single prompt and it's a selling point for alternative implementations. If a feature is a trivial patch to Bitcoin Core, and if there's a strong incentive to use it, you assume it will be used regardless of what developers think is best. We've seen this with changes to relay policy too.
The incentive to skip validating the deep past will increase over the decades / centuries. Unless Moore's Law keeps up, but we should not assume that.
So this is where the case scenario of concern comes to play:
> Op 12 mei 2026, om 17:56 heeft eric@voskuil.org het volgende geschreven:
>
> It is not hypothetical, and it is dangerous. This understanding is at least 11 years old:
>
>>> Full nodes using UTXO set commitments is a change to the bitcoin
>>> security model.
>>>
>>> Currently an attacker with >50% of the network hashrate can rewrite history.
>>>
>>> If full nodes rely on UTXO set commitments such an attacker could create
>>> an infinite number of bitcoins (as in many times more than the current
>>> 21 million bitcoin limit).
>>>
>>> Before we consider mechanisms for UTXO set commitments, we should
>>> seriously discuss whether the security model reduction is reasonable.
>
> - Patrick Strateman, 2015
4. As a minor point, in the current design, inflation shouldn't be a problem.
Nodes can and should calculate the total supply when loading the snapshot. It will however be a problem in a design where every block commits to the state transition, without including the full state. E.g. with Utreexo each block could contain the merkle forest at its height, but that doesn't tell you the total supply.
5. The bigger problem imo is theft, especially theft of coins that are unlikely to be claimed by someone else.
A malicious cabal of developers could commit a bad snapshot. The theft would be obvious to anyone looking at the code and verifying the snapshot with an earlier release. But users who don't verify the full history won't notice anything wrong until the stolen coins start moving.
This could be decades later. Only then do compromised nodes disconnect from old nodes and alternative implementations. That's when you (hopefully), see a chain split, depending on what miners are running.
A big delay between when people _know_ fraud happened, and the moment it starts impacting their choice of which chain to follow, seems quite dangerous. The people who initially called it out are forgotten and their warnings of this-will-go-wrong get boring. Then it finally happens, but there's sunk cost.
This requires a level of user complacency that's probably fatal for the project anyway, but still.
6. Given all this, it's reasonable to worry about incrementally moving towards UTXO set commitments, before we have a good design for them. Especially since there might not be a good design.
At the same time, I don't think the current situation is dangerous, and neither is the increment from downloading a torrent, to serving via p2p.
The reason is that I don't expect a UXTO commitment soft fork proposal to go anywhere, when IBD performance is the only argument for it. People would righty point out that there is plenty of room, at least in Bitcoin Core, to make it faster without a soft fork.
- Sjors
[0] https://gnusha.org/pi/bitcoindev/CAApLimjfPKDxmiy_SHjuOKbfm6HumFPjc9EFKvw=3NwZO8JcmQ@mail.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/A7B1ECA8-4DCF-4AAC-9FC4-0820C199A0DC%40sprovoost.nl.
next prev parent reply other threads:[~2026-06-22 19:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 15:36 [bitcoindev] [BIP Draft] P2P UTXO Set Sharing 'Fabian' via Bitcoin Development Mailing List
2026-05-05 16:01 ` [bitcoindev] " Eric Voskuil
2026-05-06 1:06 ` Antoine Riard
2026-05-07 21:50 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-07 21:34 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-12 15:56 ` eric
2026-05-15 23:08 ` Anthony Towns
2026-05-16 0:58 ` eric
2026-05-16 17:58 ` Saint Wenhao
2026-05-16 21:48 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-17 2:09 ` Eric Voskuil
2026-05-17 8:50 ` sadiq Ismail
2026-05-17 21:29 ` Eric Voskuil
2026-05-18 1:36 ` Eric Voskuil
2026-05-19 8:36 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-19 23:20 ` Eric Voskuil
2026-05-22 12:32 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-24 20:58 ` Eric Voskuil
2026-05-24 15:53 ` Eric Voskuil
2026-05-24 23:50 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-25 0:45 ` Eric Voskuil
2026-05-16 22:39 ` Eric Voskuil
2026-06-22 18:43 ` Sjors Provoost [this message]
2026-05-19 9:32 ` josie
2026-05-22 12:52 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-24 19:32 ` Eric Voskuil
2026-06-05 11:24 ` Anthony Towns
2026-06-08 11:37 ` Josie Baker
2026-06-11 3:01 ` Antoine Riard
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=A7B1ECA8-4DCF-4AAC-9FC4-0820C199A0DC@sprovoost.nl \
--to=sjors@sprovoost.nl \
--cc=bitcoindev@googlegroups.com \
--cc=eric@voskuil.org \
--cc=fjahr@protonmail.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