From: <eric@voskuil.org>
To: "'Fabian'" <fjahr@protonmail.com>
Cc: "'Bitcoin Development Mailing List'" <bitcoindev@googlegroups.com>
Subject: RE: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing
Date: Tue, 12 May 2026 11:56:33 -0400 [thread overview]
Message-ID: <02c201dce227$e808e050$b81aa0f0$@voskuil.org> (raw)
In-Reply-To: <KwFUBuvfLZdJTpAEO-BIK9YEFZcKTiJhWWNcjP3kEtvHOeWaxQMaMTO2pbRknTbtTKZFq_ZekjxSECNR7i3u9j_Z7PcFmL428FEDORl1BE8=@protonmail.com>
Hi Fabain,
Thanks for the reply. Comments inline.
> AssumeUTXO is a UX improvement for those interested in running a fully
> validating node. The option to get started in
> a very limited amount of time even under significant hardware constraints
> can motivate users to choose a full node over an SPV client if startup time is
> relevant for their decision.
It's not at all clear to me how this is a UX improvement. Get started doing what?
> And at some point of hardware constraints it definitely is, I think.
This implies that that hardware constraints are somehow overcome by this, which is not the case.
> In addition, it is a much easier decision for users to do IBD
> with assumevalid=0 as they are not required to wait for the completion of
> background IBD to take the next steps in their setup.
These aren't limitations inherent in protocol. The implementation details of a given node aren't relevant.
> Also, this proposal only improves the sourcing of the UTXO set. Currently this
> needs to happen through some third party source and loaded into the node
> manually which comes with it’s own set of potential risks (privacy, malware),
> being able to rely on the P2P network as a secure source is preferable to that.
This is again an implementation detail of a specific node. Neither assumevalid nor assumeutxo are protocol. These are trust-based features of a specific node implementation (not a "secure source"). The distribution of trusted blobs was a known design flaw of assumeutxo. But it has long been suggested that these could be just distributed via the p2p network. The similar bip64 was in 2014. Predictably the former is now being used to justify the latter. But of course this presents another problem, that of the cost of validating them, requiring full validation of the chain. So this inevitably leads to miner commitments.
> I think your main critique boils down to “this is a slippery slope” aside from
> your critique of assumeutxo... I can not refute
> critique of something that is not part of this proposal except for pointing out
> that what you are insinuating is not something I am working on or plan on
> working on...
Even if for some reason you cannot comment, I and others can. The above slide from trusted utxo downloads to p2p distribution of them makes the point already. Ad-hoc downloads was obviously going to lead to the p2p distribution proposal. And that proposal (here) is obviously going to lead to a new proposal for miner commitments to utxo state. This has been discussed as far back as 2015, and has been implemented in altcoins. It was a primary big-blocker proposal to resolve the inability to validate larger blocks. It achieves this by not validating them, which is of course the critique. Whether you would support that or not is not the relevant question.
> In contrast to some hypothetical dangerous future extension of this
> proposal that you are warning about...
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
https://gnusha.org/pi/bitcoindev/55FC6951.9010704@gmail.com/
> I am convinced that it does have real positive impact on users
> today, as I pointed out above.
Entirely dismissing these very relevant issues while assuming a "real positive impact" is not sound analysis. I am not aware of any use of a not validated full node. Maybe an untrusted block explorer, but there are plenty of those available online. Some full nodes do provide full functionality up to the point of validation, while building the chain (including block explorers).
This proposal is a bug (p2p trusted distribution) that attempts to fix the assumeutxo bug (ad-hoc trusted distribution), and the only "fix" to the latter will be miner commitments (soft fork). And there is no material benefit to any of it. The chain must still be fully validated, and is not usable until it is. Arguments in favor of this approach are thinly veiled support for a rolling utxo commitment scheme, as a "solution" to the lack of scalable implementation.
e
--
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/02c201dce227%24e808e050%24b81aa0f0%24%40voskuil.org.
next prev parent reply other threads:[~2026-05-12 16:02 UTC|newest]
Thread overview: 18+ 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 [this message]
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-16 22:39 ` Eric Voskuil
2026-05-19 9:32 ` josie
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='02c201dce227$e808e050$b81aa0f0$@voskuil.org' \
--to=eric@voskuil.org \
--cc=bitcoindev@googlegroups.com \
--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