From: Eric Voskuil <eric@voskuil.org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing
Date: Sun, 24 May 2026 13:58:26 -0700 (PDT) [thread overview]
Message-ID: <1c4389e4-e38c-4080-b8a7-f2886d5b923cn@googlegroups.com> (raw)
In-Reply-To: <GWGvdFMTFt85N06FBbO-RCCeP-MH5T3jpeOohf7hg1FwZTDng5CUeGOoj3yrtOa-ZgMZuAsHSeY5sgJyGtLorodlFsbHgWgZhSlfDkzfTGQ=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5824 bytes --]
> Hi Eric,
>
> I disagree that SPV-during-IBD is "far more trustworthy." Sipa already
> said this better than I could in the Bitcoin Core pull request discussion
> but SPV by construction never validates UTXO state and instead trusts
> hashrate majority for chain validity
In this thread on May 7th you wrote:
>>> 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 and I am not aware of anyone working
>>> on skipping IBD and I would not endorse such a proposal if it were to be
>>> published. In contrast to some hypothetical dangerous future
extension...
On the Bitcoin Core pull request entitled "p2p: UTXO set sharing" #35054,
the presumably same Sipa on May 20th wrote:
>> So my question is: if we had the option of a assumeutxo with P2P sync,
but
>> without background re-validation, would that tilt the scales for
commenters
>> here, in one way or the other? The reduction in bandwidth, computation,
and
>> validation code complexity may make it more appealing.
and in a follow-up post:
>> I refer to the current approach of background validation of the chain
prior
>> to the pre-assumeutxo sync point as re-validation, because it is
validating
>> something that is already trusted to be correct anyway. I am arguing for
-
>> at least as a thought experiment - dropping that re-validation. That
indeed
>> means not validating it.
>> ...
>> The dual chainstate is only there for re-validation. I am suggesting not
>> doing that.
>> ...
>> I think getting rid of the background re-validation actually improves
upon
>> that, by ripping off the facade that makes it seem like something better
>> than a trusted hash in the source code.
https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4501781606
Despite the fact that this is clearly a proposal (even if initially
presented as a "thought experiment") to drop validation from your proposal,
and that you said just 13 days earlier, "I would not endorse such a
proposal". You are not only failing to reject it - you are quoting
favorably from the very same post. You rejected this possibility as a
"slippery slope" argument.
> AssumeUTXO trusts the same code-review process that already covers the
> consensus rules implementation. It is a different trust model and I
> don't think one is better than the other.
Who's review process? The Central Bitcoin Team?
> SPV also has many downsides which are well documented... BIP 157/158
resolves
> the privacy issues but still doesn't validate UTXO state.
Which is why there is full validation.
Assume utxo also does not validate the utxo state (it assumes it). So you
aren't even suggesting a distinction.
> Your point about wallet-complexity in the node goes both ways: SPV
requires
> a wallet to implement filter matching, Merkle-inclusion verification,
> and SPV-specific message handling, while AssumeUTXO requires no wallet
> changes.
No changes are necessary to any wallets without this proposal.
> I also don't see how the "very costly DoS" could happen.
> If somehow a maleated snapshot wouldn't match that snapshot
> can be replaced by the fully validated UTXO set but there is no scenario
> where the full chain validation is wasted.
If you trusted the wrong bros, and you actually validate, you will find out
once you finish validation, and at that point (assuming implementation) you
will have the correct state. However you will have to validate everything
above the assumption, since the previous "validation" was based on an
invalid assumption. So that portion of the validation is wasted. And all
transactions accepted until that is completed are also verified only by SPV.
> And, as I pointed out earlier,
> I don't see one or the other model as more trusted and so I also don't see
> the p2p as more or less trustless with this proposal.
The proposal is fully trusting a central authority. SPV is trusting that
majority hash power is kept in check by the majority of economy actually
validating. These proposals of nobody validating beyond SPV shift the
entire security model of Bitcoin (as I pointed out in my first post here
and you rejected as a "slippery slope argument") to SPV *without the
check*, IOW majority hash power control over validity.
> Finally, you said "People already widely use SPV wallets and direct them
> to their own full nodes for better security." If people already have their
> full node then they certainly have no need for AssumeUTXO. So I think your
> arguments just don't speak to the use case the BIP targets.
My argument speaks directly to the rationalization for fundamentally
changing the trust model of Bitcoin as matter or protocol specification.
Nobody is suggesting that implementations can't keep shipping "assume
valid", "assume utxo", "assume utreexo", and whatever other
trust-centralized modes they can come up with.
However this community protocol process must not be coopted into providing
cover for trust-me-bro "consensus".
> However, I'm not dismissing SPV-during-IBD as a potentially interesting
> development that someone could explore.
It's already in widespread use and suffers only from the terrible
experience of having to sync up a node and then having to sync up an
Electrum server, each of which can take days to weeks. Those are very
solvable problems.
Best,
Eric
--
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/1c4389e4-e38c-4080-b8a7-f2886d5b923cn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6738 bytes --]
next prev parent reply other threads:[~2026-05-24 21:01 UTC|newest]
Thread overview: 27+ 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 [this message]
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-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
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=1c4389e4-e38c-4080-b8a7-f2886d5b923cn@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