From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 19 May 2026 04:09:27 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wPIKD-0006Jk-AL for bitcoindev@gnusha.org; Tue, 19 May 2026 04:09:27 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-43a4f4a252csf3382407fac.2 for ; Tue, 19 May 2026 04:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779188959; x=1779793759; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=9X7noKQLSdug13MDX7BF/ai/CdsVCOsefBzaswtR48o=; b=vDk7fIYgxodQJazpzDxIKStAUcECRRbtaOtELEAKkdHSeElorJ623ogYRztSIIY5/6 7moxnN5+zikrkmimyOA2IErtlv98uqZXeYKutBtD1tRp3AyWpMvzkfSlb2PUEJENpMK7 oM/aaqnkpz3KfTxwOvdNxCyFt2FaJwU8abJsEVUYuNjBsA7BU7qfZde8kO/na7v3XD1G 5kMKVCfmPXZuJ6OYhgkqrvDtWcMACDNBsbQGxnUH5B+0SEPs62/M4RBgLA9HyFp3098Y wY5WxJ2mX3Bez9cVgXE5O6aDEinu7+BWpdf0nsDkp+Zjj78jPug6bgnM6JL5GOCFMEJ6 M6UQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20251104.gappssmtp.com; s=20251104; t=1779188959; x=1779793759; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=9X7noKQLSdug13MDX7BF/ai/CdsVCOsefBzaswtR48o=; b=G8UAx3CQSdUfacvtPBYx2BPztIiXc7VCgnyadwAQaPE7pOyOn4emhVrqa2QqZUwxnE ALMiEUFXApa8Gdu9+oRyAlF4LNpMWQgApAO16TrttfF5FUMCCjyNo8vnk2TwQDIBa0Z+ OiwKuKt6OS9Uvyl/T/FxG7WoG5BIeiKBehmeGqNcM68qsbuuWPHwhDMzsguZnQUoW9tS Q221ASMMurE2UD+BjQA2hlgtQwKivVtaFGbLy04E/4Cu6pxZfb+Vlh++OeoBOGZULnGl 8eSU7qjnsXrUsYgYB+IQHI900We8dJEfg0pZUAZjRwlP9YLEAyPUpkxQicGEzuCR83aK iZPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779188959; x=1779793759; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=9X7noKQLSdug13MDX7BF/ai/CdsVCOsefBzaswtR48o=; b=T0bI+hRs/yUNriAiZDGe4aFvTH+EG//ArH0mv8/Z++Nm1YpxV4lm4YEZC0mU+EOTZx CIWVp3W1DhJdzB0ejRxduVEmtr9f3ZbPvRQnDevtN9v8onR9D3gPivXDg/3j8aOrUmoM 4BVRI8Is2PNnTZn1y4oPP6N4+05rYgiut82HGYqp2Y+Q1cYxNsR3I0pBWd7Av6/HoBd1 IHmFSv+6UE8tEYa3x//5nJ+6kRZKhHBtle4iQjuTXEBTAkUBupVYhpO2KkHcbmO9WwzH JHHVGqFsCPp/UZi2mQ9LS1iOdcXIFiKf3jUCEUFMgLvexNSycHc6hN6v0DlmVOiw7uf+ vY1A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/XUG7CYHkzy0lskC+RCjxQN+z6uZ3Q0K60ilTNdwkvL7k0Lom+1qRTlQI8hLJPFx/YsXNE22IKzYwu@gnusha.org X-Gm-Message-State: AOJu0YwCRhwrFGYgomt2l64Rs0M4oQhY1cgWi6P8xB3w1QgHHcLYckB3 E9cecwLnNe5SP2enztuuKwBa+qbKwqrQ3sEiIgNIjjnsiSNEFBNsCt2u X-Received: by 2002:a05:6870:a093:b0:42c:22a5:6fe7 with SMTP id 586e51a60fabf-43a2dd17614mr12157228fac.20.1779188959163; Tue, 19 May 2026 04:09:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMN0vZtV5FQ1reEjJnKjNTZCaJKkRpIHYpqmuE5n+WVHuw==" Received: by 2002:a05:6871:7c17:b0:430:b76:607f with SMTP id 586e51a60fabf-439cd14f500ls2570484fac.2.-pod-prod-00-us-canary; Tue, 19 May 2026 04:09:14 -0700 (PDT) X-Received: by 2002:a05:6809:1:20b0:484:3c85:b4b2 with SMTP id 5614622812f47-4843c85ce77mr5695166b6e.13.1779188954133; Tue, 19 May 2026 04:09:14 -0700 (PDT) Received: by 2002:a05:690c:6202:b0:7ba:f1b3:9504 with SMTP id 00721157ae682-7c6993cf1f6ms7b3; Tue, 19 May 2026 02:32:34 -0700 (PDT) X-Received: by 2002:a05:690c:3481:b0:7bd:69b8:f2ec with SMTP id 00721157ae682-7c948513117mr158664337b3.15.1779183153528; Tue, 19 May 2026 02:32:33 -0700 (PDT) Date: Tue, 19 May 2026 02:32:33 -0700 (PDT) From: josie To: Bitcoin Development Mailing List Message-Id: <8661e699-47d8-46e4-a561-41c5d2fdc0e6n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1291428_1674585386.1779183153079" X-Original-Sender: josie@2140.dev Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_1291428_1674585386.1779183153079 Content-Type: multipart/alternative; boundary="----=_Part_1291429_647718646.1779183153079" ------=_Part_1291429_647718646.1779183153079 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think others have articulated legitimate concerns with the AssumeUTXO=20 approach better than I can, so I'll try not to repeat them.=20 I'd like to instead take a step back and ask why is this being proposed in= =20 the first place? Even if I agreed with the AssumeUTXO approach (I do not),= =20 I would still push back on p2p sharing. AssumeUTXO's trust model is built= =20 around a hash committed to in the Bitcoin Core binary, which the snapshot= =20 is then verified against. So why not just distribute the snapshot from=20 bitcoincore.org along with the release? As you said, this is meant to be=20 opt-in so why not keep it fully opt-in by not adding code and attack=20 surface to the p2p code that everyone who runs Bitcoin Core will use? Furthermore, having the snapshot be distributed by Bitcoin Core makes the= =20 trust model explicitly clear: if you don't trust downloading a snapshot=20 from the Bitcoin Core website then you certainly shouldn't be trusting the= =20 hash committed to in the Bitcoin Core binary. This also makes the feature= =20 available to any user who wants to use it, without requiring a certain=20 number of peers on the network to also support it. I'd much rather validate= =20 beforehand how many people are *actually* using this feature before we=20 continue writing more code to support it. I'd also like to comment on the bandwidth arguments being used as a=20 justification for AssumeUTXO. This does not make sense to me. Low bandwidth= =20 areas are often on metered bandwidth and AssumeUTXO increases bandwidth=20 usage, not decreases. Furthermore, if low bandwidth is a concern, has=20 anyone taken the time to do the math and verify that the node will catch up= =20 to the snapshot in a reasonable amount of time? As a reminder, the node=20 also needs to keep up with new blocks and transaction relay, which would=20 take away available bandwidth/CPU from validating in the background. I keep= =20 hearing "accepting payments" as the use case, which implies to me the node= =20 would care a lot more about validating recently blocks and learning about= =20 transactions. This implies the node may never catch up, or catch up so=20 slowly that it invalidates the trust model of AssumeUTXO. In closing, if I may be a bit (humorous) crass, this feels like putting=20 lipstick on a pig by trying to dress up a trusted protocol as less trusted= =20 than it actually is. Cheers, josie On Tuesday, May 5, 2026 at 5:39:56=E2=80=AFPM UTC+2 Fabian wrote: > Dear list, > > I am sharing a BIP draft for sharing the UTXO set over the P2P network, a= n=20 > old idea that makes it possible to utilize AssumeUTXO without sourcing a= =20 > UTXO set dump from a third party source. You can find the full text below= =20 > or comment on the BIPs repository pull directly:=20 > https://github.com/bitcoin/bips/pull/2137 > > Fabian > > > ``` > BIP: ? > Layer: Peer Services > Title: P2P UTXO Set Sharing > Authors: Fabian Jahr > 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=20 > between peers. It introduces > a new service bit `NODE_UTXO_SET`, four new P2P messages (`getutxotree`,= =20 > `utxotree`, `getutxoset`, > `utxoset`), and a chunk-hash list anchored to a Merkle root known to the= =20 > requesting node, enabling > per-chunk verification. This allows nodes to bootstrap from a recent=20 > height by obtaining the > required UTXO set directly from the P2P network via mechanisms such as=20 > assumeutxo. > > ## Motivation > > The assumeutxo feature (implemented in Bitcoin Core) allows nodes to begi= n=20 > operating from a serialized > UTXO set while validating > historical blocks in the background. However, there is currently no=20 > canonical source for obtaining this > data. Users must either generate one themselves from a fully synced node= =20 > (using `dumptxoutset` in=20 > Bitcoin Core), or download one from a third party. > > By enabling UTXO set sharing over the P2P network, new nodes can obtain= =20 > the data directly from > peers, removing the dependency on external infrastructure. > > ## Specification > > The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in=20 > 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=20 > data for at least one height. | > > A node MUST NOT set this bit unless it has at least one full UTXO set=20 > available to serve. > A node signaling `NODE_UTXO_SET` MUST be capable of responding to=20 > `getutxotree` and `getutxoset` > requests for every UTXO set it is willing to serve, including the full=20 > 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= =20 > 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= =20 > 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=E2=80=939 | Number of outputs for this= txid. | > > For each coin in the group: > > | Field | Type | Size | Description | > |-------|------|------|-------------| > | `vout_index` | `compact_size` | 1=E2=80=939 | Output index. | > | `coin` | `Coin` | variable | Serialized coin (varint-encoded code for= =20 > height/coinbase, then compressed txout). | > > Coins are ordered lexicographically by outpoint (txid, then vout index),= =20 > matching the LevelDB iteration > order of the coins database. > > #### Chunk Merkle Tree > > The serialized UTXO set (header + body) is split into chunks of exactly= =20 > 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= =20 > as a balanced binary tree. When > the number of nodes at a level is odd, the last node is duplicated before= =20 > 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= =20 > node that knows > the Merkle root for a given UTXO set checks a received list of leaves by= =20 > recomputing the root and > comparing. The Merkle root is the sole trust input required to verify the= =20 > integrity of the received UTXO set. > > `SHA256d` denotes double-SHA256: `SHA256d(x) =3D 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=20 > UTXO set. | > > A node that has advertised `NODE_UTXO_SET` and can serve the requested=20 > UTXO set MUST respond with > `utxotree`. If the serving node cannot fulfill the request, it MUST NOT= =20 > 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=20 > 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= =20 > in bytes (header + body). | > | `num_chunks` | `compact_size` | 1=E2=80=939 | Number of chunks the seri= alized=20 > UTXO set is split into. | > | `chunk_hashes` | `uint256[]` | 32 =C3=97 `num_chunks` | The ordered lis= t of=20 > chunk hashes. | > > Upon receiving a `utxotree` message, the node MUST recompute the Merkle= =20 > root from > `chunk_hashes` and compare it against the Merkle root it knows for the=20 > corresponding UTXO set. If > the roots do not match, the node MUST discard the response and MUST=20 > disconnect the peer. > > #### `getutxoset` > > Sent to request a single chunk of UTXO set data. The requesting node MUST= =20 > 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=20 > UTXO set. | > | `chunk_index` | `uint32_t` | 4 | Zero-based index of the requested=20 > chunk. | > > If the serving node cannot fulfill the request, it MUST NOT respond. The= =20 > 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= =20 > the last chunk. | > > The transfer is receiver-driven: the requesting node sends one=20 > `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)`= =20 > and compare it against > `chunk_hashes[chunk_index]` from the `utxotree` it accepted for this UTXO= =20 > set. If the hashes do not > match, the node MUST discard the chunk and MUST disconnect the peer. A=20 > node SHOULD also disconnect > a peer that sends a `utxoset` message with fields (`chunk_index`,=20 > `block_hash`) that do not match > the outstanding request. > > After all chunks have been received, the node SHOULD parse the reassemble= d=20 > 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= =20 > one or more of these peers. > 3. Each peer responds with `utxotree`. The requesting node verifies the= =20 > response by recomputing > the Merkle root against a value it knows for the given UTXO set, eithe= r=20 > from a trusted source > or by selecting a root with agreement among multiple peers. > 4. The requesting node downloads chunks via `getutxoset`/`utxoset`=20 > exchanges, verifying each chunk > against its entry in the accepted `utxotree` on receipt. On=20 > verification failure the peer is > disconnected and download continues from another peer without losing= =20 > already-verified chunks. > 5. After all chunks are received, the node parses the reassembled UTXO se= t=20 > 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=20 > transfers per peer at their own > discretion to manage resource consumption. > > ## Rationale > > **Usage of service bit 12:** Service bits allow selective peer discovery= =20 > through > DNS seeds and addr relay. Bit 12 is chosen as the next unassigned bit=20 > after `NODE_P2P_V2` (bit 11, BIP 324). > > **Direct request model:** Peers signal availability of UTXO sets via the= =20 > `NODE_UTXO_SET` > service bit; the requesting node identifies the desired UTXO set by block= =20 > hash when sending > `getutxotree`. The serving node responds only if it can serve that=20 > specific UTXO set. > > **Per-chunk verification:** The chunk-hash list returned in `utxotree`=20 > enables each chunk to be verified > by direct lookup against the accepted list as it arrives, allowing=20 > immediate detection of corrupt data, > peer switching without data loss, and parallel download from multiple=20 > peers. The list itself is small > (~80 KB for a ~10 GB set). The specified serialization is deterministic,= =20 > 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= =20 > GB set) against memory usage > for buffering and verifying a single chunk. Smaller chunks would increase= =20 > protocol overhead; larger > chunks would increase memory pressure on constrained devices commonly use= d=20 > to run Bitcoin nodes. > Together with the additional message overhead, the `utxoset` message=20 > including the chunk data also > sits just below the theoretical maximum block size which means any=20 > implementation should be able to > handle messages of this size. > > **Reusing the `dumptxoutset` format:** Avoids introducing a new=20 > serialization format and ensures > compatibility with UTXO sets already being generated and shared. > > **Relationship to BIP 64:** BIP 64 defined a protocol for querying=20 > individual UTXOs by outpoint and is > now closed. This BIP addresses a different use case: bulk transfer of the= =20 > 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. S= ee > 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=20 > chunk-hash list via `getutxotree`/`utxotree` > * Dropped per-chunk Merkle proofs; chunks verified directly against= =20 > the chunk-hash list > * Dropped `height` from requests (`block_hash` is the sole=20 > identifier); added format `version` to `utxotree` > * Dropped references to the serialized hash; the Merkle root is the= =20 > sole integrity check > * __0.1.0__ (2026-04-10): > * Initial draft > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 8661e699-47d8-46e4-a561-41c5d2fdc0e6n%40googlegroups.com. ------=_Part_1291429_647718646.1779183153079 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think others have articulated legitimate concerns with the AssumeUTXO app= roach better than I can, so I'll try not to repeat them.=C2=A0

I'd like to instead take a step back and ask why is this being pro= posed 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 i= s built around a hash committed to in the Bitcoin Core binary, which the sn= apshot is then verified against. So why not just distribute the snapshot fr= om 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 surfa= ce 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 sn= apshot from the Bitcoin Core website then you certainly shouldn't be trusti= ng the hash committed to in the Bitcoin Core binary. This also makes the fe= ature available to any user who wants to use it, without requiring a certai= n number of peers on the network to also support it. I'd much rather valida= te beforehand how many people are *actually* using this feature before we c= ontinue writing more code to support it.

I= 'd also like to comment on the bandwidth arguments being used as a justific= ation for AssumeUTXO. This does not make sense to me. Low bandwidth areas a= re often on metered bandwidth and AssumeUTXO increases bandwidth usage, not= decreases. Furthermore, if low bandwidth is a concern, has anyone taken th= e time to do the math and verify that the node will catch up to the snapsho= t in a reasonable amount of time? As a reminder, the node also needs to kee= p 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 m= ore about validating recently blocks and learning about transactions. This = implies the node may never catch up, or catch up so slowly that it invalida= tes the trust model of AssumeUTXO.

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

Cheers,
josie
On Tuesday, May 5, 2026= at 5:39:56=E2=80=AFPM UTC+2 Fabian wrote:
Dear list,=

I am sharing a BIP draft for sharing the UTXO set over the P2P n= etwork, an old idea that makes it possible to utilize AssumeUTXO without so= urcing a UTXO set dump from a third party source. You can find the full tex= t below or comment on the BIPs repository pull directly:=C2=A0ht= tps://github.com/bitcoin/bips/pull/2137

Fabian


```
= =C2=A0 BIP: ?
=C2=A0 Layer: Peer Services
=C2=A0 Title: P2P UTXO Set Sharing
=C2= =A0 Authors: Fabian Jahr <fj...@protonmail.com>
=C2=A0= Status: Draft
=C2=A0 Type: Specification
=C2=A0 Assigned: ?
=C2=A0 Discussion: ?=
=C2=A0 Version: 0.2.0
=C2=A0= License: BSD-2-Clause
```

## Abstract

This BIP def= ines a P2P protocol extension for sharing full UTXO sets between peers. It = introduces
a new service bit `NODE_UTXO_SET`, four n= ew 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 mech= anisms such as assumeutxo.

## Motivat= ion

The assumeutxo feature (implement= ed in Bitcoin Core) allows nodes to begin operating from a serialized
UTXO set while validating
historic= al blocks in the background. However, there is currently no canonical sourc= e for obtaining this
data. Users must either generat= e one themselves from a fully synced node (using `dumptxoutset` in <= /div>
Bitcoin Core), or download one from a third party.

By enabling UTXO set sharing over the P2P net= work, new nodes can obtain the data directly from
pe= ers, removing the dependency on external infrastructure.
<= br>
## Specification

= The key words "MUST", "MUST NOT", "SHOULD", &= quot;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 s= erve complete UTXO set data for at least one height. |
A node MUST NOT set this bit unless it has at least one f= ull UTXO set available to serve.
A node signaling `N= ODE_UTXO_SET` MUST be capable of responding to `getutxotree` and `getutxose= t`
requests for every UTXO set it is willing to serv= e, including the full chunk-hash list and every
chun= k of those sets.

### Data Structures<= /span>

#### Serialized UTXO Set
=

The serialized UTXO set uses the format establish= ed by the Bitcoin Core RPC `dumptxoutset` (as of Bitcoin Core v31).<= /div>

**Header (55 bytes):**

=
| Field | Type | Size | Description |
|-------|------|------|-------------|
| `magic` |= `bytes` | 5 | `0x7574786fff` (ASCII `utxo` + `0xff`). |
<= span>| `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 h= ash of the UTXO set. |
| `coins_count` | `uint64_t` = | 8 | Total number of coins (UTXOs) in the set. |

**Body (coin data):**

Co= ins are grouped by transaction hash. For each group:

<= /div>
| Field | Type | Size | Description |
|-------|------|------|-------------|
| `txid` | `= uint256` | 32 | Transaction hash. |
| `num_coins` | = `compact_size` | 1=E2=80=939 | Number of outputs for this txid. |

For each coin in the group:
<= br>
| Field | Type | Size | Description |
= |-------|------|------|-------------|
| `vout_= index` | `compact_size` | 1=E2=80=939 | 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 ind= ex), matching the LevelDB iteration
order of the coi= ns 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 duplic= ated before hashing the next level.
Interior nodes a= re computed as `SHA256d(left_child || right_child)`.

<= /div>
The leaves are delivered to the node in a single `utxotree`= response. A node that knows
the Merkle root for a g= iven UTXO set checks a received list of leaves by recomputing the root and<= /span>
comparing. The Merkle root is the sole trust input r= equired to verify the integrity of the received UTXO set.
=
`SHA256d` denotes double-SHA256: `SHA256d(x) =3D SHA25= 6(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 request= ed UTXO set. |

A node that has advert= ised `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 SH= OULD apply a reasonable timeout and try another peer.

=
#### `utxotree`

Sent= in response to `getutxotree`, delivering the full chunk-hash list along wi= th per-snapshot
metadata.

| Field | Type | Size | Description |
|-= ------|------|------|-------------|
| `block_hash` |= `uint256` | 32 | Block hash this data corresponds to. |
<= span>| `version` | `uint16_t` | 2 | Format version of the serialized UTXO s= et. |
| `data_length` | `uint64_t` | 8 | Total size = of the serialized UTXO set in bytes (header + body). |
| `num_chunks` | `compact_size` | 1=E2=80=939 | Number of chunks the ser= ialized UTXO set is split into. |
| `chunk_hashes` |= `uint256[]` | 32 =C3=97 `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 correspond= ing UTXO set. If
the roots do not match, the node MU= ST discard the response and MUST disconnect the peer.

=
#### `getutxoset`

Se= nt to request a single chunk of UTXO set data. The requesting node MUST hav= e received a `utxotree`
for the corresponding UTXO s= et before sending this message.

| Fie= ld | 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 t= he request, it MUST NOT respond. The requesting node SHOULD apply
a reasonable timeout and try another peer.
<= br>
#### `utxoset`

Se= nt in response to `getutxoset`, delivering one chunk.

=
| Field | Type | Size | Description |
|-------|------|------|-------------|
| `block_ha= sh` | `uint256` | 32 | Block hash this data corresponds to. |
<= div>| `chunk_index` | `uint32_t` | 4 | Zero-based index of this chunk= . |
| `data` | `bytes` | variable | Chunk payload, e= xactly 3.9 MB except for the last chunk. |

= The transfer is receiver-driven: the requesting node sends one `getut= xoset` per chunk. Chunks MAY be
requested in any ord= er and from different peers.

Upon rec= eiving a `utxoset` message, the node MUST compute `SHA256d(data)` and compa= re it against
`chunk_hashes[chunk_index]` from the `= utxotree` it accepted for this UTXO set. If the hashes do not
<= div>match, the node MUST discard the chunk and MUST disconnect the pe= er. A node SHOULD also disconnect
a peer that sends = a `utxoset` message with fields (`chunk_index`, `block_hash`) that do not m= atch
the outstanding request.

<= /div>
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.

<= span>### Protocol Flow

1. The request= ing 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 w= ith `utxotree`. The requesting node verifies the response by recomputing
=C2=A0 =C2=A0the Merkle root against a value it knows = for the given UTXO set, either from a trusted source
=C2=A0 =C2=A0or by selecting a root with agreement among multiple peers.
4. The requesting node downloads chunks via `getutxos= et`/`utxoset` exchanges, verifying each chunk
=C2=A0= =C2=A0against its entry in the accepted `utxotree` on receipt. On verifica= tion failure the peer is
=C2=A0 =C2=A0disconnected a= nd download continues from another peer without losing already-verified chu= nks.
5. After all chunks are received, the node pars= es the reassembled UTXO set against the serialized
= =C2=A0 =C2=A0UTXO set format to confirm that it is well-formed.

Serving nodes are free to limit the number of co= ncurrent and repeated transfers per peer at their own
discretion to manage resource consumption.

## Rationale

**Usage of servi= ce bit 12:** Service bits allow selective peer discovery through
DNS seeds and addr relay. Bit 12 is chosen as the next unassig= ned bit after `NODE_P2P_V2` (bit 11, BIP 324).

<= div>**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 t= hat specific UTXO set.

**Per-chunk ve= rification:** The chunk-hash list returned in `utxotree` enables each chunk= to be verified
by direct lookup against the accepte= d list as it arrives, allowing immediate detection of corrupt data,<= /div>
peer switching without data loss, and parallel download fro= m multiple peers. The list itself is small
(~80 KB f= or a ~10 GB set). The specified serialization is deterministic, so all hone= st nodes produce
byte-identical output, guaranteeing= Merkle root agreement.

**3.9 MB chun= k size:** The number balances round trips (~2,560 for a ~10 GB set) against= memory usage
for buffering and verifying a single c= hunk. Smaller chunks would increase protocol overhead; larger
<= div>chunks would increase memory pressure on constrained devices comm= only used to run Bitcoin nodes.
Together with the ad= ditional message overhead, the `utxoset` message including the chunk data a= lso
sits just below the theoretical maximum block si= ze which means any implementation should be able to
= handle messages of this size.

**Reusi= ng the `dumptxoutset` format:** Avoids introducing a new serialization form= at and ensures
compatibility with UTXO sets already = being generated and shared.

**Relatio= nship 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.

## Refer= ence Implementation

[Bitcoin Core imp= lementation pull request](https://github.com/bitcoin/bitcoin/pu= ll/35054)

## Copyright

This BIP is made available under the terms of t= he 2-clause BSD license. See
## Changelog

* __0.= 2.0__ (2026-05-04):
=C2=A0 =C2=A0 * Dropped discover= y before download approach, instead request the chunk-hash list via `getutx= otree`/`utxotree`
=C2=A0 =C2=A0 * Dropped per-chunk = Merkle proofs; chunks verified directly against the chunk-hash list<= /div>
=C2=A0 =C2=A0 * Dropped `height` from requests (`block_hash= ` is the sole identifier); added format `version` to `utxotree`
=C2=A0 =C2=A0 * Dropped references to the serialized hash; the = Merkle root is the sole integrity check
* __0.1.0__ = (2026-04-10):
=C2=A0 =C2=A0 * Initial draft

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/8661e699-47d8-46e4-a561-41c5d2fdc0e6n%40googlegroups.com.
------=_Part_1291429_647718646.1779183153079-- ------=_Part_1291428_1674585386.1779183153079--