From: "'Fabian' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Eric Voskuil <eric@voskuil.org>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing
Date: Tue, 19 May 2026 08:36:54 +0000 [thread overview]
Message-ID: <6F9aFh3mB9geayXC2ScrYoLxVlN-4Kc3yuLDjc0mZPK4kIehqoKobca8fADI65TNuwNslVHDMWq3YyRMFgI7HyXI-tY9spsQqbNJ42gGPsM=@protonmail.com> (raw)
In-Reply-To: <062656d4-7ddd-4fa4-8db0-48bae6d73b42n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 3688 bytes --]
Hi Eric,
> Validating the headers is inconsequential if you are not verifying tx
> inclusion. That's what SPV is, and people should not be misled into believing
> that this is SPV.
I did not claim header validation alone validates the UTXO set, and I have not
suggested AssumeUTXO is SPV. What I wrote was that an AssumeUTXO node "is not
'not validated'". Headers are validated upfront and the historical chain is
validated in the background. Together, that is the same work as a normal IBD,
performed in a different order.
The trust window during background validation is also limited, and the attack
surface within it is narrow. An incoming payment can only be confirmed in a
mined block on the headers-validated chain. For an attacker to trick the user
into accepting a transaction that spends UTXOs which exist only in a malicious
snapshot, the majority of mining hashpower would have to be running nodes that
accepted and continued to run based only on the same malicious snapshot. The
snapshot hash itself would still have to have been compromised through the
source code review process. Even then, background validation would detect the
inconsistency when it reaches the snapshot height.
> Above you make the explicit claim that Bitcoin Core is the oracle for this
> "sole trust input". If that is the case you should add it to the proposal so
> that people are fully aware. If so the proposal establishes a central
> authority for validity.
The AssumeUTXO hash is a constant in Bitcoin Core source code. It is added via
a normal pull request, reviewed by multiple contributors, and any user with a
fully validated UTXO set can independently reproduce it. It carries the same
trust as every other part of the codebase including very similar constants,
such as the genesis block hash, assumevalid, the network magic, the DNS seed
list. If that makes Bitcoin Core a "central authority for validity," the same
has been true of every released version since 2009 and the same applies to
libbitcoin and any other implementation, where users similarly trust the code
they have built and run.
The BIP intentionally leaves the source of the Merkle root to the
implementation. The protocol's job is to enable transferring and verifying UTXO
data once a root is known, not to dictate how each implementation establishes
that root. Bitcoin Core's existing AssumeUTXO feature is one concrete example
of how this can work; other implementations are free to choose differently.
Best,
Fabian
On Monday, May 18th, 2026 at 3:48 AM, Eric Voskuil <eric@voskuil.org> wrote:
> Hi sadiq,
>
> I apologize for missing this comment:
>
>> Since my use case is data analysis, not receiving payments...
>
> If security is not essential to your use case you can simply download from a trusted source. This is not a valid use case for the P2P network.
>
> 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/062656d4-7ddd-4fa4-8db0-48bae6d73b42n%40googlegroups.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/6F9aFh3mB9geayXC2ScrYoLxVlN-4Kc3yuLDjc0mZPK4kIehqoKobca8fADI65TNuwNslVHDMWq3YyRMFgI7HyXI-tY9spsQqbNJ42gGPsM%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 5696 bytes --]
next prev parent reply other threads:[~2026-05-19 11:09 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
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 [this message]
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='6F9aFh3mB9geayXC2ScrYoLxVlN-4Kc3yuLDjc0mZPK4kIehqoKobca8fADI65TNuwNslVHDMWq3YyRMFgI7HyXI-tY9spsQqbNJ42gGPsM=@protonmail.com' \
--to=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