[BIP Draft] P2P UTXO Set Sharing

[Fabian]

Dear list,

I am sharing a BIP draft for sharing the UTXO set over the P2P network, an old idea that makes it possible to utilize AssumeUTXO without sourcing a UTXO set dump from a third party source. You can find the full text below or comment on the BIPs repository pull directly: https://github.com/bitcoin/bips/pull/2137

Fabian

```

  BIP: ?

  Layer: Peer Services

  Title: P2P UTXO Set Sharing

  Authors: Fabian Jahr <fj...@protonmail.com>

  Status: Draft

  Type: Specification

  Assigned: ?

  Discussion: ?

  Version: 0.2.0

  License: BSD-2-Clause

```

## Abstract

This BIP defines a P2P protocol extension for sharing full UTXO sets between peers. It introduces

a new service bit `NODE_UTXO_SET`, four new P2P messages (`getutxotree`, `utxotree`, `getutxoset`,

`utxoset`), and a chunk-hash list anchored to a Merkle root known to the requesting node, enabling

per-chunk verification. This allows nodes to bootstrap from a recent height by obtaining the

required UTXO set directly from the P2P network via mechanisms such as assumeutxo.

## Motivation

The assumeutxo feature (implemented in Bitcoin Core) allows nodes to begin operating from a serialized

UTXO set while validating

historical blocks in the background. However, there is currently no canonical source for obtaining this

data. Users must either generate one themselves from a fully synced node (using `dumptxoutset` in

Bitcoin Core), or download one from a third party.

By enabling UTXO set sharing over the P2P network, new nodes can obtain the data directly from

peers, removing the dependency on external infrastructure.

## Specification

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be

interpreted as described in RFC 2119.

### Service Bit

| Name | Bit | Description |

|------|-----|-------------|

| `NODE_UTXO_SET` | 12 (0x1000) | The node can serve complete UTXO set data for at least one height. |

A node MUST NOT set this bit unless it has at least one full UTXO set available to serve.

A node signaling `NODE_UTXO_SET` MUST be capable of responding to `getutxotree` and `getutxoset`

requests for every UTXO set it is willing to serve, including the full chunk-hash list and every

chunk of those sets.

### Data Structures

#### Serialized UTXO Set

The serialized UTXO set uses the format established by the Bitcoin Core RPC `dumptxoutset` (as of Bitcoin Core v31).

**Header (55 bytes):**

| Field | Type | Size | Description |

|-------|------|------|-------------|

| `magic` | `bytes` | 5 | `0x7574786fff` (ASCII `utxo` + `0xff`). |

| `version` | `uint16_t` | 2 | Format version. |

| `network_magic` | `bytes` | 4 | Network message start bytes. |

| `base_height` | `uint32_t` | 4 | Block height of the UTXO set. |

| `base_blockhash` | `uint256` | 32 | Block hash of the UTXO set. |

| `coins_count` | `uint64_t` | 8 | Total number of coins (UTXOs) in the set. |

**Body (coin data):**

Coins are grouped by transaction hash. For each group:

| Field | Type | Size | Description |

|-------|------|------|-------------|

| `txid` | `uint256` | 32 | Transaction hash. |

| `num_coins` | `compact_size` | 1–9 | Number of outputs for this txid. |

For each coin in the group:

| Field | Type | Size | Description |

|-------|------|------|-------------|

| `vout_index` | `compact_size` | 1–9 | Output index. |

| `coin` | `Coin` | variable | Serialized coin (varint-encoded code for height/coinbase, then compressed txout). |

Coins are ordered lexicographically by outpoint (txid, then vout index), matching the LevelDB iteration

order of the coins database.

#### Chunk Merkle Tree

The serialized UTXO set (header + body) is split into chunks of exactly 3,900,000 bytes (3.9 MB). The

last chunk contains the remaining bytes and may be smaller.

The leaf hash for each chunk is `SHA256d(chunk_data)`. The tree is built as a balanced binary tree. When

the number of nodes at a level is odd, the last node is duplicated before hashing the next level.

Interior nodes are computed as `SHA256d(left_child || right_child)`.

The leaves are delivered to the node in a single `utxotree` response. A node that knows

the Merkle root for a given UTXO set checks a received list of leaves by recomputing the root and

comparing. The Merkle root is the sole trust input required to verify the integrity of the received UTXO set.

`SHA256d` denotes double-SHA256: `SHA256d(x) = SHA256(SHA256(x))`.

### Messages

#### `getutxotree`

Sent to request the chunk-hash list for a specific UTXO set.

| Field | Type | Size | Description |

|-------|------|------|-------------|

| `block_hash` | `uint256` | 32 | Block hash identifying the requested UTXO set. |

A node that has advertised `NODE_UTXO_SET` and can serve the requested UTXO set MUST respond with

`utxotree`. If the serving node cannot fulfill the request, it MUST NOT respond. The requesting

node SHOULD apply a reasonable timeout and try another peer.

#### `utxotree`

Sent in response to `getutxotree`, delivering the full chunk-hash list along with per-snapshot

metadata.

| Field | Type | Size | Description |

|-------|------|------|-------------|

| `block_hash` | `uint256` | 32 | Block hash this data corresponds to. |

| `version` | `uint16_t` | 2 | Format version of the serialized UTXO set. |

| `data_length` | `uint64_t` | 8 | Total size of the serialized UTXO set in bytes (header + body). |

| `num_chunks` | `compact_size` | 1–9 | Number of chunks the serialized UTXO set is split into. |

| `chunk_hashes` | `uint256[]` | 32 × `num_chunks` | The ordered list of chunk hashes. |

Upon receiving a `utxotree` message, the node MUST recompute the Merkle root from

`chunk_hashes` and compare it against the Merkle root it knows for the corresponding UTXO set. If

the roots do not match, the node MUST discard the response and MUST disconnect the peer.

#### `getutxoset`

Sent to request a single chunk of UTXO set data. The requesting node MUST have received a `utxotree`

for the corresponding UTXO set before sending this message.

| Field | Type | Size | Description |

|-------|------|------|-------------|

| `block_hash` | `uint256` | 32 | Block hash identifying the requested UTXO set. |

| `chunk_index` | `uint32_t` | 4 | Zero-based index of the requested chunk. |

If the serving node cannot fulfill the request, it MUST NOT respond. The requesting node SHOULD apply

a reasonable timeout and try another peer.

#### `utxoset`

Sent in response to `getutxoset`, delivering one chunk.

| Field | Type | Size | Description |

|-------|------|------|-------------|

| `block_hash` | `uint256` | 32 | Block hash this data corresponds to. |

| `chunk_index` | `uint32_t` | 4 | Zero-based index of this chunk. |

| `data` | `bytes` | variable | Chunk payload, exactly 3.9 MB except for the last chunk. |

The transfer is receiver-driven: the requesting node sends one `getutxoset` per chunk. Chunks MAY be

requested in any order and from different peers.

Upon receiving a `utxoset` message, the node MUST compute `SHA256d(data)` and compare it against

`chunk_hashes[chunk_index]` from the `utxotree` it accepted for this UTXO set. If the hashes do not

match, the node MUST discard the chunk and MUST disconnect the peer. A node SHOULD also disconnect

a peer that sends a `utxoset` message with fields (`chunk_index`, `block_hash`) that do not match

the outstanding request.

After all chunks have been received, the node SHOULD parse the reassembled UTXO set against the

serialized UTXO set format to confirm it is well-formed.

### Protocol Flow

1. The requesting node identifies peers advertising `NODE_UTXO_SET`.

2. The requesting node sends `getutxotree` for the desired block hash to one or more of these peers.

3. Each peer responds with `utxotree`. The requesting node verifies the response by recomputing

   the Merkle root against a value it knows for the given UTXO set, either from a trusted source

   or by selecting a root with agreement among multiple peers.

4. The requesting node downloads chunks via `getutxoset`/`utxoset` exchanges, verifying each chunk

   against its entry in the accepted `utxotree` on receipt. On verification failure the peer is

   disconnected and download continues from another peer without losing already-verified chunks.

5. After all chunks are received, the node parses the reassembled UTXO set against the serialized

   UTXO set format to confirm that it is well-formed.

Serving nodes are free to limit the number of concurrent and repeated transfers per peer at their own

discretion to manage resource consumption.

## Rationale

**Usage of service bit 12:** Service bits allow selective peer discovery through

DNS seeds and addr relay. Bit 12 is chosen as the next unassigned bit after `NODE_P2P_V2` (bit 11, BIP 324).

**Direct request model:** Peers signal availability of UTXO sets via the `NODE_UTXO_SET`

service bit; the requesting node identifies the desired UTXO set by block hash when sending

`getutxotree`. The serving node responds only if it can serve that specific UTXO set.

**Per-chunk verification:** The chunk-hash list returned in `utxotree` enables each chunk to be verified

by direct lookup against the accepted list as it arrives, allowing immediate detection of corrupt data,

peer switching without data loss, and parallel download from multiple peers. The list itself is small

(~80 KB for a ~10 GB set). The specified serialization is deterministic, so all honest nodes produce

byte-identical output, guaranteeing Merkle root agreement.

**3.9 MB chunk size:** The number balances round trips (~2,560 for a ~10 GB set) against memory usage

for buffering and verifying a single chunk. Smaller chunks would increase protocol overhead; larger

chunks would increase memory pressure on constrained devices commonly used to run Bitcoin nodes.

Together with the additional message overhead, the `utxoset` message including the chunk data also

sits just below the theoretical maximum block size which means any implementation should be able to

handle messages of this size.

**Reusing the `dumptxoutset` format:** Avoids introducing a new serialization format and ensures

compatibility with UTXO sets already being generated and shared.

**Relationship to BIP 64:** BIP 64 defined a protocol for querying individual UTXOs by outpoint and is

now closed. This BIP addresses a different use case: bulk transfer of the entire UTXO set for node

bootstrapping.

## Reference Implementation

[Bitcoin Core implementation pull request](https://github.com/bitcoin/bitcoin/pull/35054)

## Copyright

This BIP is made available under the terms of the 2-clause BSD license. See

https://opensource.org/license/BSD-2-Clause for more information.

## Changelog

* __0.2.0__ (2026-05-04):

    * Dropped discovery before download approach, instead request the chunk-hash list via `getutxotree`/`utxotree`

    * Dropped per-chunk Merkle proofs; chunks verified directly against the chunk-hash list

    * Dropped `height` from requests (`block_hash` is the sole identifier); added format `version` to `utxotree`

    * Dropped references to the serialized hash; the Merkle root is the sole integrity check

* __0.1.0__ (2026-04-10):

    * Initial draft

[Eric Voskuil]

Concept NACK. It's bad enough that nodes are formalizing this off network, but incorporating it into p2p is another level of awful.

[Antoine Riard]

Hello Fabian, From a short read over the BIP, I'm wondering if the present BIP proposal wouldn't be better implemented as a feature on top of the BIP 434 (and that would be an opportunity to exercise the proposed mechanism). Keeping reserved a service bit means implementation that don't wish to support the feature don't have to parse / reserve it. Now, on the other hand it facilitates discovery at the peer layer by any bitcoin software. Second observation, there is no mention of the computational worst-case for the parsing and validation of the `utxotree`. What if the forwarding peer is an asshole and share you a crappy utxo set, where validity will be only asserted when you received and verify the latest utxo with the latest `utxoset`. There could be an intermediary "authentication" step a la BIP157 of the root itself, if you're peers assume-utxo servicing discovery is sane and you're connected to a least one honest peer that makes it harder to DoS the recipient. I'm worried it's a bit like BIP157 / BIP158 (or bloom filters fwiw), why a full-node implemention would go to bloat its p2p stack to support a client-server like flow (independently of the consideration that one find assume-utxo interesting as a validation model). Best, Antoine OTS hash: ba583724bad6f5251fd793abf626a598f64a1dcd9f5ff6b1f91e1cbd02c09774

[Fabian]

Hi Eric,

Thanks for sharing your feedback. I also read conversations on X so I am answering with those in mind as well even though not everything may have been spelled out in this thread explicitly.

Of course, the proposal is opt-in, just like AssumeUTXO itself. A node that does not use this feature is unaffected by it. Assumeutxo doesn’t change consensus, the header chain is validated before loading the UTXO set and full IBD still happens in the background. 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. And at some point of hardware constraints it definitely is, I think. 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.

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.

I think your main critique boils down to “this is a slippery slope” aside from your critique of assumeutxo and the Bitcoin Core architecture in general (see https://x.com/evoskuil/status/2052027207032164488). 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 of this proposal that you are warning about, I am convinced that it does have real positive impact on users today, as I pointed out above.

Fabian

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/19616822-8a03-4de1-99be-72d50479208fn%40googlegroups.com.

[Fabian]

Hi Antoine,

thanks for your feedback.

The idea to use BIP434 is indeed very tempting. I had lost track of that proposal for some time and that's why I didn't even think of it. I assumed it had stalled but I pinged AJ and there is now a stand-alone Bitcoin Core PR open for it. I will look over BIP434 again in detail and review the Bitcoin Core PR before I make a final decision on moving the proposal over, but my feeling right now is that this is likely to happen unless I am overlooking any roadblocks.

I am not sure I can follow your point on the computational worst case. If the node has the root of the Merkle tree of chunks embedded AssumeUTXO style or if it knows the root from somewhere else it will get an actual UTXO set. So I don't understand how the "crappy utxo set" would look like and get to the peer. I also can't really grasp the BIP157 scheme to help with this but that's probably because I am not understanding the issue to begin with. If you could give me a bit more details and/or a concrete example here that would be really great!

Thanks,

Fabian

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aa597737-e07e-4809-82bf-6226080db418n%40googlegroups.com.

[er...@voskuil.org]

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...@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

[Anthony Towns]

On Tue, May 12, 2026 at 11:56:33AM -0400, er...@voskuil.org wrote:
> > 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 [...]

> It's not at all clear to me how this is a UX improvement. Get started doing what?

Getting started validating blocks and transactions at the current tip;
ie receiving payments.

Obtaining the full Bitcoin blockchain currently requires downloading
about 600GB of data. At 250Mbps with perfectly well-behaved peers,
that's a bit under 7 hours. At the consumer level, bandwidth seems to
be the bottleneck, with modern PCs being able to validate the blockchain
in about that time.

AssumeUTXO significantly reduces the download requirement, with
the utxo snapshot at block 935000 being under 9GB. At 100Mbps with
perfectly well-behaved peers, that's about 15m to download. Adding in
another 8GB-34GB of actual block data to download (assuming that the
utxo snapshot people use will be between 4 and 17 weeks out of date)
brings that up to 30 minutes to an hour.

That is, it's something you can leave running over lunch, rather than
overnight.

(Sharing these figures, because up to a few weeks ago, my assumption was
that a fresh IBD over the network from Australia would take multiple days,
and I commonly see people expecting IBD to take a week or more)

Cheers,
aj

[er...@voskuil.org]

> From: Anthony Towns

> On Tue, May 12, 2026 at 11:56:33AM -0400, er...@voskuil.org wrote:
> > > 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 [...]

> > It's not at all clear to me how this is a UX improvement. Get started doing

> what?
>
> Getting started validating blocks and transactions at the current tip; ie
> receiving payments.

Receiving payments without having validated is an exceedingly unwise scenario, and not worthy of protocol support.

If you have not fully validated every block in history, you have not validated at all. The validity of a block requires the validity of all prior blocks.

There seems to be a common misapprehension that using a trusted utxo store is something akin to SPV. This is not the case. A node/wallet could certainly also implement SPV and use it while downloading/validating, though that eliminates the use case for trusted utxo state.

Using a trusted utxo store for transacting is equivalent to a fully trusting wallet. The person is 100% trusting that the state of their node is valid - having not validated any of it until having validated all of it. Accepting this as a matter of protocol is irresponsible.

If you want a reduced (vs. zero) level of security while downloading and validating the chain, I suggest implementing an SPV wallet that transitions to a full node wallet after downloading and validating the full chain.

> Obtaining the full Bitcoin blockchain currently requires downloading about
> 600GB of data. At 250Mbps with perfectly well-behaved peers, that's a bit
> under 7 hours. At the consumer level, bandwidth seems to be the bottleneck,
> with modern PCs being able to validate the blockchain in about that time.

Let's look at the trend:

May 2016
---------------------------------------------------------------------------
Blockchain size: ~80 GB
Median U.S. broadband speed: 39 Mbps
Download time: 4 hours 33 minutes

80 × 8,000 = 640,000 Mb
640,000 ÷ 39 ≈ 16,410 seconds
16,410 ÷ 3,600 ≈ 4.558 hours (4 hours 33 minutes)

May 2021
---------------------------------------------------------------------------
Blockchain size: 343.5 GB
Median U.S. broadband speed: 100 Mbps
Download time: 7 hours and 38 minutes

343.5 × 8,000 = 2,748,000 Mb
2,748,000 ÷ 100 = 27,480 seconds
27,480 ÷ 3,600 ≈ 7.633 hours (7 hours and 38 minutes)

May 2026
---------------------------------------------------------------------------
Blockchain size: 739.2 GB
Median U.S. broadband speed: 308 Mbps
Download time: 5 hours and 20 minutes

739.2 × 8,000 = 5,913,600 Mb
5,913,600 ÷ 308 = 19,200 seconds
19,200 ÷ 3,600 = 5.333… hours (5 hours and 20 minutes)

---------------------------------------------------------------------------

Despite a 4x max block size increase in 2016, download time is *decreasing*.

It only increased in early years because blocks went from empty to ~full (median block ~1MB in 2016), coupled with segwit 4MB limit impact.

> AssumeUTXO significantly reduces the download requirement, with the utxo
> snapshot at block 935000 being under 9GB. At 100Mbps with perfectly well-
> behaved peers, that's about 15m to download. Adding in another 8GB-34GB
> of actual block data to download (assuming that the utxo snapshot people use
> will be between 4 and 17 weeks out of date) brings that up to 30 minutes to
> an hour.

Downloading an additional 9GB only increases the total download requirement/time.

What has been increasing is the perception of increased block data exceeding Moore's Law. This perception has fed the spam debacle. This perception is rooted in the reality that sequential indexation (even without validation) does not (cannot) fully take advantage of advancing hardware. This is an implementation issue.

Chain growth is linearly bounded. Hardware growth at a given cost is exponential. Even Satoshi reasoned this out. What he didn't do in his prototype was provide a scalable implementation - he left that to us. Necessary download and validation time/cost is shrinking. Eventually downloading and validating the chain will be as cheap as texting a video clip has become. It wasn't long ago that too was unthinkable.

On a fast home Internet today, on the same machine I've been developing on since 2017, the full chain can be downloaded and fully validated in under 5 hours. That's less time than it took almost 10 years ago on the same machine - and my real Internet cost today is about half what it was at that time.

So I reiterate my NACK. This is a very unwise idea, without justification for network protocol integration.

Best,
Eric

[Fabian]

Hi Eric,

Sorry for the late reply. I'm responding to bits of both your last emails since

they made closely related points.

> It's not at all clear to me how this is a UX improvement. Get started doing what?

Aside from the most obvious case that was already named, receiving payments for

goods and services, I would name mining without a centralized template provider

as an equally important use case.

> Receiving payments without having validated is an exceedingly unwise scenario,

> and not worthy of protocol support.

For most merchants this scenario is much preferred to not receiving payments at

all for an extended period of time if they don't have great hardware and bandwidth

at their store or home. I also need to add that an AssumeUTXO node is not

"not validated". The header chain is fully validated before the snapshot is

loaded, and the historical blocks are validated in the background. The work is

the same, only the node becomes usable earlier.

That IBD sync time has been a real deterrent for users choosing a fully

validating node for their PoS setup is demonstrated by the fact that BTCPayServer

shipped their own AssumeUTXO equivalent before AssumeUTXO existed: https://docs.btcpayserver.org/Docker/fastsync/

They also did so with a worse trust model than what is proposed here, a tarball from

a single trusted source.

> There seems to be a common misapprehension that using a trusted utxo store is

> something akin to SPV. This is not the case. A node/wallet could certainly also

> implement SPV and use it while downloading/validating, though that eliminates

> the use case for trusted utxo state.

No such software exists, and I think the reason is that most users would not

bother validating anymore once they have turned to SPV. With AssumeUTXO the

situation is different: there is no option to skip background validation of the

chain.

There will always an alternative solution available for those who don't want to

or can't wait for IBD to finish, and it will always be a worse one than what is

being proposed here. Why should users bother with SPV then? We will continue

to lose users to custodial solutions if we are not willing to offer alternatives

with a UX that at least comes somewhat close to what today's consumers

are used to.

Being able to transact with IBD running in the background also takes away the

economic and other pressure off of those who need to get a node started quickly.

> 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.

AssumeUTXO is anchored to a hash that is hardcoded in Bitcoin Core and reviewed

in the open. Anyone running a fully validating node can independently reproduce

it from their own UTXO set. That has no relationship to miner behaviour or

PoW-based commitments, and Strateman's concern with about a >50% attacker

creating new bitcoin, does not apply to it. If anything, providing a working P2P

path for snapshot distribution reduces the pressure for any future commitment

scheme rather than enabling one, because the user-facing problem that motivates

commitments is already addressed.

> Even if for some reason you cannot comment, I and others can.

I did comment, I just pointed out that I cannot disprove something that doesn't

exist. I have not been part of any such conversations and I have not heard of

anyone being part of them.

> It is not hypothetical, and it is dangerous. This understanding is at least

> 11 years old:

Old mailing list conversations are useful context but they don't prove anything.

The author of the original Bitcoin Prototype software also wrote, "I don't

believe a second, compatible implementation of Bitcoin will ever be a good idea"

(https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/69/#2), and

that does not seem to have stopped you from working on libbitcoin. The Strateman

quote is a sound warning about a specific scheme, but it is not a scheme this

BIP proposes.

> These aren't limitations inherent in protocol. The implementation details of a given

> node aren't relevant.

The protocol's job here is to enable obtaining UTXO state from peers rather than from

a third-party website. What each implementation does with that capability is, indeed,

implementation. While AssumeUTXO is the primary motivation right now, there may

be other interesting use cases for this down the road.

> Median U.S. broadband speed

> Despite a 4x max block size increase in 2016, download time is decreasing.

Those figures use US-median broadband. Globally the picture is significantly

different, and a meaningful fraction of users rely on mobile or metered

connections where the difference between "over lunch" and "multiple days"

decides whether they run a node at all. The same applies to the 32 GB RAM

minimum noted for libbitcoin (https://nitter.net/evoskuil/status/2054456087252816267),

which already excludes a large share of consumer hardware outside high-income

regions.

I think disregarding hardware and network requirements of users in less developed

countries is causing much higher centralization pressures today than this UTXO

set sharing proposal ever could. Following the trajectory of the last few years

to its conclusion, the minimum is likely to be 64 GB next year, then 128 GB the

year after, and validating with libbitcoin will soon require the latest generation

of Nvidia chips. Validation time will keep going down on that path, but the

user base it serves will keep shrinking.

I am obviously exaggerating somewhat to make a point: it is easy to construct a

plausible-sounding slippery slope argument, including one about libbitcoin's

hardware trajectory. And I don't think you are able to prove today that libbitcoin

will not follow this path in the future. That is exactly why I don't find

your similar argument persuasive.

And in all seriousness, I think at least some Bitcoin implementations should aim to

be accessible with low bandwidth and minimum hardware requirements compatible

with widely available consumer hardware outside high-income regions. That is

what many of the developers I work with are aiming for.

Best,

Fabian

On Saturday, May 16th, 2026 at 7:58 PM, Saint Wenhao <saint...@gmail.com> wrote:

> I commonly see people expecting IBD to take a week or more

Because it is true, at least for me, and maybe also for some others. You can read some examples on forums, where people run full nodes, and post their progress on a regular basis: https://bitcointalk.org/index.php?topic=5480200

Currently, I started Initial Blockchain Download on some node. It is now around block 250,000, after few hours. It shows around 1 MB/s in the "Network Traffic" tab from the GUI client. Even if my Internet speed may be better than that, then still: it is limited by what my peers can provide. And if I check 10 connected nodes, and all use NETWORK_LIMITED flag, so all are in pruned mode, and all just act as proxies, fetching blocks from other full, archival nodes, then guess what: it is limited to the weakest link, the slowest node in the chain of connections.

When I did the same experiment some months ago, but this time from some VPS, running 24/7, my results were quite similar. Waiting around a week to be fully synced is normal for me, and I got used to that.

Also, I understand, why full, archival nodes, use rate limits: because otherwise, they would pay more bandwidth fees, if everyone would be able to get everything instantly, at full speed. Which is why when many people limit their connections, to not share too much data too fast, it is what it is. And it is normal, because nodes are not rewarded for their services, so they have no incentive to provide more, than the bare minimum they can handle.

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/002301dce4cf%2427bc3040%24773490c0%24%40voskuil.org.

[Saint Wenhao]

> I commonly see people expecting IBD to take a week or more

Because it is true, at least for me, and maybe also for some others. You can read some examples on forums, where people run full nodes, and post their progress on a regular basis: https://bitcointalk.org/index.php?topic=5480200

Currently, I started Initial Blockchain Download on some node. It is now around block 250,000, after few hours. It shows around 1 MB/s in the "Network Traffic" tab from the GUI client. Even if my Internet speed may be better than that, then still: it is limited by what my peers can provide. And if I check 10 connected nodes, and all use NETWORK_LIMITED flag, so all are in pruned mode, and all just act as proxies, fetching blocks from other full, archival nodes, then guess what: it is limited to the weakest link, the slowest node in the chain of connections.

When I did the same experiment some months ago, but this time from some VPS, running 24/7, my results were quite similar. Waiting around a week to be fully synced is normal for me, and I got used to that.

Also, I understand, why full, archival nodes, use rate limits: because otherwise, they would pay more bandwidth fees, if everyone would be able to get everything instantly, at full speed. Which is why when many people limit their connections, to not share too much data too fast, it is what it is. And it is normal, because nodes are not rewarded for their services, so they have no incentive to provide more, than the bare minimum they can handle.

sob., 16 maj 2026 o 03:01 <er...@voskuil.org> napisał(a):

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/002301dce4cf%2427bc3040%24773490c0%24%40voskuil.org.

[Eric Voskuil]

> From: Saint Wenhao

> Even if my Internet speed may be
> better than that, then still: it is limited by what my peers can provide.

This is a reasonable assumption, but it is not correct. P2P download speed is limited only by your bandwidth, not that of your peers. If you have extra capacity you add more peers. You drop the slower peers and connect to the faster peers - the ones offering capacity. You use standard deviation to detect which peers are slow. This will rapidly saturate your bandwidth, and is optimal for the P2P network. Your node may be pounding away at someone's laptop until timeout because the node software doesn't work this way. That's an implementation issue.

> And if I check 10 connected nodes, and all use NETWORK_LIMITED flag, so all
> are in   pruned mode, and all just act as proxies, fetching blocks from other full,
> archival nodes, then guess what: it is limited to the weakest link, the slowest
> node in the chain of connections.

This isn't how the protocol works. Addresses are advertised with their service bits. A node attempting to download blocks should not be connecting to a pruned peer. This is why this service bit exists. This is also why pruning is not good for the network. In 12 years of writing node software I have never seen peers produce a download limit. The chain can be consistently downloaded at the theoretical limit based on own bandwidth. We commonly operate from 1-2.5 Gbps and peers are never limiting.

> Also, I understand, why full, archival nodes, use rate limits: because
> otherwise, they would pay more bandwidth fees, if everyone would be able to
> get everything instantly, at full speed. Which is why when many people limit
> their connections, to not share too much data too fast, it is what it is. And it is
> normal, because nodes are not rewarded for their services, so they have no
> incentive to provide more, than the bare minimum they can handle.

Throttling is not a problem for the same reasons discussed above. Download time is local bandwidth limited, not peer limited. If you are downloading at a rate below your available bandwidth it is either because your hardware cannot keep up with your available bandwidth, or the software is not designed to.

Finally, I posted example bandwidths and related times over five and ten year periods to show the strongly declining relative trend despite strongly increasing data. There is no need anecdoting about bandwidth. It's easily obtained public information and a straightforward process to determine download time from these numbers.

https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds

> It shows around 1 MB/s in the "Network Traffic" tab from the GUI client.

This is about 1/5 of an Eritrean mobile phone, the slowest mobile rate on Earth, or 1/4 of a Cuban land line, the slowest wire rate on Earth. Seems like there's more going on here than bandwidth, but it is not caused by peers.

Best,
Eric

[Eric Voskuil]

From: Fabian

> The header chain is fully validated before the snapshot is loaded,

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.

> and the historical blocks are validated in the background.

The issue is the time before that completing. After validating it's moot.

> The work is the same, only the node becomes usable earlier.

Until the work is complete the node is not usable in the sense of a node - it hasn't validated.

> AssumeUTXO is anchored to a hash that is hardcoded in Bitcoin Core
> and reviewed in the open. Anyone running a fully validating node can
> independently reproduce it from their own UTXO set.

In this proposal there is no statement that everyone must trust Bitcoin Core. The proposal specifically states:

    "The Merkle root is the sole trust input required to verify the integrity of the received UTXO set."

and

    "[The Merkle root is]... either from a trusted source or by selecting a root with agreement among multiple peers."

The "agreement among peers" is why Bitcoin exists, so we can dismiss that as an infinite regression.

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. If not then we are back to the original problem that Bitcoin supposedly solved - where does this agreement come from.

Best,
Eric

[sadiq Ismail]

Hi Eric, Fabian, and list,

I am from a place with metered and slow bandwidth, so assuming U.S. internet bandwidth and speed specifications for IBD is incorrect
and ignores that not everyone shares the same reality.

I will share mine. The average Nigerian individual and business uses 4G broadband from one of the telco providers, using MTN here as an example, though all have relatively the same speed:
Download Speed: Up to 150Mbps
Upload Speed: Up to 50Mbps
These are advertised maximums; real world speeds are considerably lower.
I can use wallets to receive Bitcoin as an SPV, but once you want to sync the blockchain and have a node synced to the tip, I face a significant bottleneck.
The download was taking days due to frequent internet blackouts and other constraints. I think if a less-trusted setup were provided, like assumeUTXO with p2p sharing, 
Since my use case is data analysis, not receiving payments, I would not face this bottleneck and would definitely use it.
As a real example of the point Fabian made about using worse alternatives: I also travelled hundreds of kilometres to a different city to assumeDatadir by copying the datadir from a trusted friend.

The risk of the chain growing so large that syncing takes a long time is real, and I believe people from my background will simply assumeDatadir because of the cost/time of getting to the tip. It is worth noting that some also that some western cloud providers do not serve Nigeria at all. Hetzner, for example, does not, which makes robust cloud-based workarounds unavailable to us (This is changing very quickly with the recent trend of native African data centres).
AssumeUTXO helps eliminate that, because at least you are not trusting one person but a group of contributors committing to a hash, with headers-first sync and other safeguards assumeUTXO provides. The use case for assumeUTXO is very real and solves a real problem.

However, I am also concerned about the trust tradeoffs for users who want to validate. Having assumeUTXO may not incentivize innovations for speeding up IBD for Eric's demographic, and alternative approaches could be dismissed with: why speed up IBD if we have assumeUTXO? I think that should not be the case. AssumeUTXO is specifically tailored for certain users, but pursuing fast IBD with abundant resources is not necessarily in conflict with that. One can throw resources at IBD compute, use libbitcoin-style sync with faster peers, and get up to speed quickly, while the other simply CANNOT.

AssumeUTXO is, in my opinion, a lesser evil than, for example, assumeDatadir. I honestly do not like the tradeoff of having the software commit the hash or the complexity of multiple chain states in the Bitcoin Core codebase. It still has good utility and reduces tradeoffs, so I will not dismiss it completely. 

https://shop.mtn.ng/mtn-4g-broadband-router.html
https://www.reddit.com/r/hetzner/comments/1ajkhp0/reasons_for_rejecting_creation_of_account/ 

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/26c7fd2e-d35d-4ed4-9638-18c95efc75dfn%40googlegroups.com.

[Eric Voskuil]

> From: sadiq Ismail

Hi sadiq,

> I am from a place with metered and slow bandwidth, so assuming U.S.
> internet bandwidth and speed specifications for IBD is incorrect and ignores
> that not everyone shares the same reality.

No such assumption has been made. My post specifically addressed the performance *trend*, which contrary to common assumptions, is improving (everywhere) and will eventually render this question moot.

> I will share mine.

No number of performance anecdotes can address the outstanding critiques, but I'm happy to cover the other issues.

> I can use wallets to receive Bitcoin as an SPV

Okay, which is far better than a trusting wallet.

> but once you want to sync the and have a node synced to the tip,

> I face a significant bottleneck.

Why are you syncing the node? Presumably you want a fully validated node - for better than SPV security. You cannot get that from assuming it. You should sync and validate a node and then just connect your SPV wallet to it. This transitions you to actual full node security from SPV security, once that full node security actually exists.

> I think if a less-trusted setup were provided, like assumeutxo

Assuming is not "less trusted", it's fully trusted. I think you meant "less trustworthy".

> with p2p sharing, Since my use case is data analysis, not receiving payments,
> I would not face this bottleneck and would definitely use it.

It's not clear why you would want a less trustworthy (fully trusted) wallet when you can use a far more trustworthy SPV wallet. And you can transition that same wallet to zero trust once your node is validated, by just pointing your SPV wallet to the node. Furthermore you are not providing any justification for moving this into P2P, the trusted node feature you want already exists.

> As a real example of the point Fabian made about using worse alternatives: I
> also travelled hundreds of kilometres to a different city to assumeDatadir by
> copying the datadir from a trusted friend.

Incorporating Core's trusted utxo system into the P2P network does not change this at all. You could have just downloaded it from your friend, or anyone else you trust to provided it. Certainly that's better than downloading it from randos on the P2P network. And you would have the same download cost either way.

> The risk of the chain growing so large that syncing takes a long time is real

The opposite is happening. This is why I pointed out the declining cost trend. That applies everywhere, not just in the US. And in any case, trust would not be a solution. That's the problem Bitcoin exists to eliminate.

> AssumeUTXO helps eliminate that, because at least you are not trusting one
> person but a group of contributors committing to a hash

Who is the "group of contributors" that we are assuming has become the central authority on what is valid? I do not see this listed in the BIP. Is there to be a public key provided somehow so that we can all be assured that we are trusting the right authority? If only someone could devise a solution to this problem.

> with headers-first sync and other safeguards assumeUTXO provides.

There are no such other "safeguards". Headers first is DoS protection. This is not an SPV implementation.

> AssumeUTXO is, in my opinion, a lesser evil than, for example, assumeDatadir.

This is a false dichotomy. Using an SPV wallet while syncing your node is a far more secure and more efficient existing alternative. And it has the actual security that people seem to be assuming this has (see your headers comment above). There is no reason to choose any evil, and certainly no reason to impose it on the P2P network.

Best,
Eric

[Eric Voskuil]

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

[Fabian]

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

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/062656d4-7ddd-4fa4-8db0-48bae6d73b42n%40googlegroups.com.

[josie]

I think others have articulated legitimate concerns with the AssumeUTXO approach better than I can, so I'll try not to repeat them. 

I'd like to instead take a step back and ask why is this being proposed in the first place? Even if I agreed with the AssumeUTXO approach (I do not), I would still push back on p2p sharing. AssumeUTXO's trust model is built around a hash committed to in the Bitcoin Core binary, which the snapshot is then verified against. So why not just distribute the snapshot from bitcoincore.org along with the release? As you said, this is meant to be opt-in so why not keep it fully opt-in by not adding code and attack surface to the p2p code that everyone who runs Bitcoin Core will use?

Furthermore, having the snapshot be distributed by Bitcoin Core makes the trust model explicitly clear: if you don't trust downloading a snapshot from the Bitcoin Core website then you certainly shouldn't be trusting the hash committed to in the Bitcoin Core binary. This also makes the feature available to any user who wants to use it, without requiring a certain number of peers on the network to also support it. I'd much rather validate beforehand how many people are *actually* using this feature before we continue writing more code to support it.

I'd also like to comment on the bandwidth arguments being used as a justification for AssumeUTXO. This does not make sense to me. Low bandwidth areas are often on metered bandwidth and AssumeUTXO increases bandwidth usage, not decreases. Furthermore, if low bandwidth is a concern, has anyone taken the time to do the math and verify that the node will catch up to the snapshot in a reasonable amount of time? As a reminder, the node also needs to keep up with new blocks and transaction relay, which would take away available bandwidth/CPU from validating in the background. I keep hearing "accepting payments" as the use case, which implies to me the node would care a lot more about validating recently blocks and learning about transactions. This implies the node may never catch up, or catch up so slowly that it invalidates the trust model of AssumeUTXO.

In closing, if I may be a bit (humorous) crass, this feels like putting lipstick on a pig by trying to dress up a trusted protocol as less trusted than it actually is.

Cheers,

josie

[Eric Voskuil]

> From: Fabian

> > 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.

I did not say that you did.

You said in response to me (my comment first):

>>> Receiving payments without having validated is an exceedingly unwise scenario,
>>> and not worthy of protocol support.
>>

>> I also need to add that an AssumeUTXO node is not
>> "not validated". The header chain is fully validated before the snapshot is
>> loaded, and the historical blocks are validated in the background. The work

>> is the same, only the node becomes usable earlier.

We are clearly talking about the period between obtaining the assumption and having validated it. This is the entire purpose of the feature. Defending the security of the feature by referring to the time *after* the feature becomes irrelevant is non-responsive.

You are referring to header validation as if it provides some aspect of security in this period. The only way it could being doing so is SPV. So I said:

"Validating the headers is inconsequential if you are not verifying tx inclusion."

> What I wrote was that an AssumeUTXO node "is not 'not validated'".

And this is incorrect in the relevant period, and moot once that period ends.

> Headers are validated upfront and the historical chain is validated in the background.

The sole purpose of the feature is to use the node without validation. Validating headers is only useful for (1) SPV or (2) DoS protection while validating.

> Together, that is the same work as a normal IBD, performed in a different order.

It just happens that the order matters. You can't have it both ways.

> 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.

It seems that it's not apparent to you that you are exactly describing SPV. The recipient cannot validate the tx, or the block, or even the amount of the prevout for non-segwit txs. But he can verify inclusion - by doing exactly what SPV does. The wallet follows the strong chain, verifies inclusion, and assumes validity of what's included. This is exactly the SPV security model. SPV with extra steps.

However it has notable downsides in relation to SPV.

(1) startup cost is much higher (big download)
(2) wallet complexity is pushed into nodes (e.g. dual chainstate, see thread)
(3) inclusion proofs are not available for any tx supposedly confirmed within the assumption window (usage gap)
(4) trust must be established in the assumption in order to prevent very costly DoS (wasted full chain validation - same problem as swift sync)
(5) degrades the formerly trustless p2p network.

> The snapshot hash itself would still have to have been
> compromised through the source code review process.

This has been covered and is not relevant.

> Even then, background validation would detect the inconsistency when it
> reaches the snapshot height.

The person is already using the node, and this could carry on for weeks or forever. As you previously pointed out, this is a long-term solution to performance. At some point it might take years to perform a sequential validation.

> > 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 BIP intentionally leaves the source of the Merkle root to the
> implementation.

So the BIP punts this aspect of security, and yet you keep claiming it's secure because of Bitcoin Core and code review. You are trying to have it both ways here as well.

This proposes a very poorly implementation of what is fundamentally the SPV security model, for the period until a node can be fully validated. I don't see any justification for putting this into a node or the P2P network. People already widely use SPV wallets and direct them to their own full nodes for better security.

Best,
Eric