From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 11 Jun 2026 02:34:32 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wXbnz-0003XX-6v for bitcoindev@gnusha.org; Thu, 11 Jun 2026 02:34:32 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-43d1e4bca47sf8481439fac.3 for ; Thu, 11 Jun 2026 02:34:30 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1781170465; cv=pass; d=google.com; s=arc-20240605; b=T92pfWdE+raWUORtqr05t1BqTyxHpbkAP3iPEMx1zoyZe5tv2gQ9sGarG34vqOezlo A5GBGm0cRopXVIhAJj5ApCjot7n6Dfb4viK2q2J36h+Q3EoCttqQEu8R7hNemQ7Depdh dQILKy9aziz4dKls7TXrvu+frhXoZ/783AoXvWMI5o62QFv5inXV/z4+s2kwUluxsRRO Wo56cQ7gqbHQ/XDHz1tzYGsIBKzcvYWFzWxeE9t7YEKrdkRndiN3SZ/m8ZdDH+dMbI7M 9sbD7W8docOm7/9icXHD5Au4DwjxJ6lRJbbVVJRKiPdPcJqZvUBYIrTb4a4c9pv+Mygf ktyQ== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=64Nqob7zhgJB7C0sj0lKKI7xzrl6vNF04eE/vsCRHMQ=; fh=wRdtG8kc+/g8ZONqXo7f3yq22BM5cq5YMpygIhbx7Qc=; b=dDw2BkVZkxur1O1mnIPuvczSfSCREbP8p5EP6UcBRf8Zi6d5ouEXIsjMb5/ocMFLsc uqKe1Icoc3DX+yn4ehC2w0pPNKn4tAwW/gp1mhd5ooiZHDbJASeZ3FpGPGaZ78tb/xUg dMEEXiH06gIaAokwK68Tn3zx/eudVxW7qsU/G3SMuLX/AOWD7ltgaT8blQ35TV3CuV9M 64K/ayf9+X+zO9HP/5JDTx7d/ClHghhVWvJENH2ualBUJzyzddGzMXMnWAehy2T7fekN nrgBxfx9pPmmh9AbNuTiCZWUjb/aAlDJETIb41gqul//dbVn4J8oJzjkxY+6oa0RDXOj Au3Q==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=hVz663fm; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122e as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781170465; x=1781775265; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=64Nqob7zhgJB7C0sj0lKKI7xzrl6vNF04eE/vsCRHMQ=; b=uH2Zo9XNa4ZaVx/7OqWnuxh1YlOPbHMsmwRrRyKAsFnpvhYXa5SnSaGkrN5gykiyUg DoXPQw3kjywujqKWy6obBwGkWgUTZbIIwetc7UmPcQKqfR05itKv2CFt72EsUTRU+0bQ 64k5LmPAj6HzpEhef79DX06pA30aq0dhli7G+/Z/3R3cU6svuaT9enXgL8kuF6rH2ry/ Nc+UJGW+A6WfneJKtjVE1/aq6RtP6p/+/k7HUw9+vJjRPw76loBGK5sQyMCpYQU4b0rq fdIzMVJgl83qnnkr1nnnfayZwVNHUAHXPtjtFC57LhrcH+/R2Aj+VRDH3FTbNp7I3Syf 70oA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781170465; x=1781775265; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=64Nqob7zhgJB7C0sj0lKKI7xzrl6vNF04eE/vsCRHMQ=; b=IDOO0wkpeHpMfB1cGgYDSwNqf30eevjjErdtqrZN5PmBFAywCJ9tkKQPUOO453jnIu A3kzK14tYlVR24+AoTlGJ2uuboWOEYAuhP27VRB/+r7VSvZJXQUsajFEv5vSyHmnNK7X 8ea7l+TGsQGeri/4V6ZbeWicAMGe/xe6Kp01Ytj2fSDU/K0p6B2dpgXPfg5+FaE8CrxU MjKQtWI8t2ERCh6SduzNc7mWGigJtOL2kyeLp+RhyVpUCtE1IuXsxoa5fKz4mZEyb8h6 1E6THKZBwkW0l9Cr438Lrw5GfFVh/PHDXj1efayrT4SZukRyhuopOpqon8qtVMVApucg T46w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781170465; x=1781775265; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=64Nqob7zhgJB7C0sj0lKKI7xzrl6vNF04eE/vsCRHMQ=; b=L2KPdPowZc11oJnTTTp6aYxosfPEQy9pkaUUAXzJSvheduLPcBNsgC1ovMVSYUvaT2 T957abwcPt2jsB4lrp0cQh+cNJWKAimWtUHRtzBCFP8achxQpY5fJXwzlIUzh611Wfh0 t6pFgI16VMqc1QZwSE0JOKSzAUazVASPJ/zs8JWK7AM24S1NoB9JgdQiw5qu+vieUn7M aLpteTk2YT7nuJjYzitopPrpPRa06/tjpm0mA74ZlUGvzpcIIF5bdOIHm6UAtRMz4cp4 8QGf3gMqHh+OWm0myxqvQ/N+U/6yZ1aw5IxPlRfevx5GdTZGn2V8t37lhvKPr1EwdcI8 Rlmg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+dleuNyf7+CNv44/kZ+2UHwmaouhCGQBqVRDGNpam5za1m9OwRN3j6Ok4qEbRn69o5yHh5IA66YhDE@gnusha.org X-Gm-Message-State: AOJu0YznbVVSM5y4ibxtucNcEUt4g7OVUj/ac7t3I2EoO2DpmmqqDHGz mQiv7oZ1rYOggamBze2/HMQoWfvVB52WI/SVhRVEQW8C0w8k093EKouN X-Received: by 2002:a05:6871:289c:b0:439:b9e8:8850 with SMTP id 586e51a60fabf-44241fa98d1mr1124807fac.30.1781170464877; Thu, 11 Jun 2026 02:34:24 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUfph/JHlja/FZebumw0INgarHpqWO8I9nTe9lge/QADtg==" Received: by 2002:a05:6871:e683:b0:430:279e:462b with SMTP id 586e51a60fabf-4410921ebdcls3154721fac.0.-pod-prod-06-us; Thu, 11 Jun 2026 02:34:20 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ9h9sTGdwF6ec4RnwT92SHbDwG4fzE8I+4FNdXWQgvN8hDU2vAYWQDt3UDofiSo/aaFb5wsub8rW0md@googlegroups.com X-Received: by 2002:a05:6808:4f14:b0:485:6129:1112 with SMTP id 5614622812f47-4871a126823mr1666088b6e.29.1781170460545; Thu, 11 Jun 2026 02:34:20 -0700 (PDT) Received: by 2002:a05:6808:e853:20b0:479:9f23:6621 with SMTP id 5614622812f47-4870205c41cmsb6e; Wed, 10 Jun 2026 20:01:44 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ9pycAHS2pmqIxtcnpbExTcv81MhTsLnZXVrZJ16TwQe+EXvuVlyfnhdOGOiVAeFECiKebVwVM9kNL6@googlegroups.com X-Received: by 2002:a05:6820:1519:b0:69e:3dae:7f11 with SMTP id 006d021491bc7-69ecae2ec7fmr633838eaf.16.1781146904126; Wed, 10 Jun 2026 20:01:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781146904; cv=pass; d=google.com; s=arc-20240605; b=QEApL1McLcJSS39300DLC0IXQBhvtpjdOYRBolcHYlu4efL5nTORRagKmob7D+O6No qcEOWj9OYFpEh3MeVrx/4CSEvMb68oghDLgJwhoSW0eS35H0c62G06//3oawtMQcKKzJ ql4Vsutm6mTg3i++RYQbgrTpVHwXqwxoBP9UUWQyLRfKXmv+6yVHNpmRPw7m4Gvp4iL0 288cYaMfOPtVWDht/F6BzaO9Z4HSJbSjD5fr9nbyD5KwxDt9RgzZD/K/MGrgAWub1LCM LvdlikoKPw7qy9tJpc+yrqzGiwAs0I6wEBsYwkqNdPw3JqEX0ltOmW7sEikmiIL8+vm0 KCgQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=kqGtiBrY6YlDAdorXGai+7HMwWh4vAIuwSTaFw7/TEA=; fh=i+su4JaTQugHv5LEr4MzlplkcuybRMl3/gSVQba3S50=; b=WR773/YkbPp5O7+oZCqX1qulJPvcvAZQgX93uti6FoMPUsouKQDkBtQkP1tTJh7hK4 0B9xhmjdKQrgCcPPOGL79hRfEMynjygzFlaJiYZ1EFgl8//OJdfGGyLafC0SsGW87UAv yOmPS2wZ+4vTpvJcGJBSe+GJ/xlUPJNgt/3iNZvfF9q0tvtvLa6Dt3XAvZsyWW0kEOGx cz4jL5cZobtKlMbeWeVcKeDkVOmgZEUlsmWsVIRVOE9CQTaX/LAPIG2sFSa9HEJrbE5T Ri5+BQw8gUQNyCASj4k2RbIj0DBrtVSeq5NPvvX7gWsbTxyJefFkFQAzsEopxwmZLj8M IhUA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=hVz663fm; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122e as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-dl1-x122e.google.com (mail-dl1-x122e.google.com. [2607:f8b0:4864:20::122e]) by gmr-mx.google.com with ESMTPS id 006d021491bc7-69ecb5bf798si20814eaf.2.2026.06.10.20.01.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2026 20:01:44 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122e as permitted sender) client-ip=2607:f8b0:4864:20::122e; Received: by mail-dl1-x122e.google.com with SMTP id a92af1059eb24-13721dfd471so9691322c88.1 for ; Wed, 10 Jun 2026 20:01:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781146903; cv=none; d=google.com; s=arc-20240605; b=VuQswf+5doRUDG93J60lH2r/WIKwYpVoDviWwoyxplg8EQbJwgC9DyaBLp9dVfJNCU MlP1DT598c+XwaX9gASEyis2hN/k/CMl2Sh/EMWwUwoxyh6EZJuFaztbiiLPiHvamDi4 pIC2z6y1tjO4X87I0YLmdEdvDaeAF3i0vinwbEQMt/YcGCh7omq5EbwYLw8ullJ60Kfq AjGjFGsQzUg6ASfpRq65lZNZ8xFNhbcD3r0RhMZuQiIrZboT2NqNci6XORyYELAgEXEM qcsWzoehiWLQGCxKIrqNP6fMjAp8lpi+WiId5mzF1J7NQ0pAA3ki892QUUtuP9mt2196 oKCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=kqGtiBrY6YlDAdorXGai+7HMwWh4vAIuwSTaFw7/TEA=; fh=i+su4JaTQugHv5LEr4MzlplkcuybRMl3/gSVQba3S50=; b=f+PYyrrCLFbTOYdkdL8EA0sQVUZ49Lp3DBwq0Gvgc5mzIOn6ambNnDyAT1Yqt2KKpE kq1T1N7RsGHVB4H44L5rsqfHWMZfeYBftlfU2nc4TfOssKr3wLEjye+BAqzgOl0bwpiU TyA2Kk51t141xia08pmrBdekwgRs944D3ajUVIHln6KCtfqZqvPdph1Z0/eixl7jom+z 7Sb2CuJXA3TDu+97b/A2pe0KJbvoXCLjeUuKoKijU9tIkmohgSVCh/EYcJJg3jOLh2Yr SScj+F8FfBxGVDMRy7/Oz5rgt18UrbVXvSfjKIg6CPJcum6LDnWgqZQ0ik4PeeGExm+e Bxjg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ9nU/RvDdfZ6PPOxsPS4T1DC1tSBu3W5UX0NoAjyhzTZKIRvk6Zurb+3Fc/MsmGS81LTzvJ5VNVElw4@googlegroups.com X-Gm-Gg: Acq92OHZ5jrx1ZRMnli+KPndiubSpjMbSCqryx8Iq/YyQs+S3NmboPOMAY0QtRm5iYy UEZm8teUzuqEDe2Xb88sRRWz+f3HOKCIPY7llaIEj7OK2QshMywcGvIwlBPuYkPd1krOCXnZDF4 DFgx8zLFVPLhJKInAidYJ8HrgqnHJ6soyjsBP/JrIGeqEzIkaAQaxjtxN+EnLXj/xBEoJOe1WQa NhEL8LSEQqG4tvq+3F1kQs6uFaBGMaIg9fOLYwTJpBP9htz6T1TmOutCy8ddrqgsZzbzXXqSSXZ V7BVfIpZ55kzUg/8rTyiTc/qAX3zZQ== X-Received: by 2002:a05:701b:2314:b0:136:6883:c4bf with SMTP id a92af1059eb24-1384217baa8mr348227c88.15.1781146902748; Wed, 10 Jun 2026 20:01:42 -0700 (PDT) MIME-Version: 1.0 References: <8661e699-47d8-46e4-a561-41c5d2fdc0e6n@googlegroups.com> In-Reply-To: From: Antoine Riard Date: Thu, 11 Jun 2026 04:01:30 +0100 X-Gm-Features: AVVi8CfoTqbKjUIV_GcW9jP8du_WDjWl0UB4dSn_wRjTM0TTwq1O5n5wf9A9-Vk Message-ID: Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing To: Josie Baker Cc: Anthony Towns , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006e61300653f194e4" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=hVz663fm; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122e as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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.5 (/) --0000000000006e61300653f194e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabian, > 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. Ya es ist ein gut frage, i think i've been confused by the following point documented in your bip draft "either from a trusted source or by selecting a root with agreement among multiple peers". For the first alternative, i.e a root of the merkle tree of chunks of the utxo set, the chunk can be verified one by one against the hardcoded value in a software implementation. I was thinking more about the second alternative where it's an agreement among multiple peers, where it sounds step one sybil all your peers (what can be done for the bip 157 security model), then step two provide crappy utxo step, the correctness (not even talking about the authenticity of the utxo set itself) of the merkle root is only received when you got the latest chunk. Whatever the "source" security model, I think you have a cpu asymmetrical denial-of-service issue, i.e a "honeypot" adversary runs a full-node on azure peer for good connectivity, announces the node_utxo_set flag and starts to malleated chunks to provoke SHA256 failure and make you run for nothing cpu cycles. Of course, you have a variant of the attack, where the peer announce the chunk, however wait up to max_timeout value minus some delay and announce the chunk (it's open source software the timeout is a public value, the enemy knows the system). And so on as a malicious peer can fast feed your addrman with node_utxo_set flags. Same issue than for bip 157 / bip 158, there is no economical symmetry between the servicing peers and the receiving ones, so only a minority of networks peers can be expected to flag it, easier for an adversary to override your local addrman, or whatever addr store... Implementing this protocol robustly is a monster of complexity, and frankly from an implementation viewpoint it's not worthy the complexity at the P2P level, e.g if you take bitcoin core network stake there is already far enough problems with tx or blocks relays. Moving forward with this proposal, my practical suggestion would be to spli= t this bip in two documents: one as an overlay-network implemented above BIP434 feature mechanism (that way if you don't like it, shrug about it), and another one to precise the "source" security model (that way if you don't trust bitcoin core development process or you know that gregory wuille make security mistakes sometimes error humanum est, an implementation is more free to craft one). Especially for the latest one, I do think there would be value for assume-utxo to have more a web-of-trust model for the "source", where the utxo set would be authenticated against a hash value countersigned by your friends PGP (we have already bip 322 for the signed messages iirc). All a suggestion, though fro= m overlooking on the discussion in this ML thread, it sounds to me one constructive way to move forward. Finally, it's been raised the thing that utxo set could be committed by the miners in the headers (see jamesob original proposal https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal). If the idea is only to improve UX a la btc pay, I don't see it. We should still encourage as much possible to validate the chain in full, merely for the sake of pure p2p network robustness. On my side, low-key interested by assume-utxo for weird ideas of mine making the life better for p2p systems built on top of bitcoin https://gnusha.org/pi/bitcoindev/CALZpt+FRPThy4qwYThXOY_YJWsGKJuCOqpX1Zt_8S= qkeA4bQsg@mail.gmail.com/ though better not to introduce single point of failure. Best, Antoine OTS hash: 652a1929cf878decd58d94285603d791260970f62beb890279c118f5d3d3a10c Le lun. 8 juin 2026 =C3=A0 13:10, Josie Baker a =C3=A9crit= : > Hi aj, > > I want to push back on this framing: > > > Trying to prevent other people from making different choices and helpin= g > their peers who make the same choices doesn=E2=80=99t seem a sensible use= of your > time. > > Disagreeing with a technical design, or arguing that it should not be > merged into Bitcoin Core or added to the p2p protocol, is not the same > thing as trying to prevent people from making different choices. People a= re > free to build, maintain, fork, distribute, and use software with differen= t > trust and architectural tradeoffs. Most importantly, people are also free > to offer critiques. > > This distinction matters. If every architectural objection gets reframed > as =E2=80=9Cyou are trying to prevent people from choosing differently,= =E2=80=9D then > review shifts away from the merits of the design and toward the motives o= f > the reviewer. Bitcoin protocol review necessarily includes saying =E2=80= =9CI do not > think this is a good idea,=E2=80=9D and sometimes even =E2=80=9CI think t= his existing > feature should be removed.=E2=80=9D That is how a conservative project av= oids > accumulating complexity and compounding technical debt. > > Cheers, > josie > > On Fri, Jun 5, 2026 at 1:24=E2=80=AFPM Anthony Towns = wrote: > >> On Tue, May 19, 2026 at 02:32:33AM -0700, josie wrote: >> > I'd like to instead take a step back and ask why is this being propose= d >> 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? >> >> Is Bitcoin a P2P network, or a product from Bitcoin Core? Should we >> design protocols that treat everyone in the P2P network as peers, or >> should we give Bitcoin Core a privileged position? >> >> The current draft of the BIP gives a fixed formula for which blocks to >> take snapshots from that any node developer can use, with no dependence >> on when Bitcoin Core happens to make releases, defines a fixed format >> for encoding those snapshots, and allows anyone interested to securely >> distribute those snapshots, whether the use the same node software or >> not. Isn't that fundamentally more in-tune with how Bitcoin should work >> than "oh, just download and trust the data from this website" ? >> >> (Even if you don't think people should be running different clients, >> having the *option* to do so avoids people being vendor lock-in being >> used to gain undue influence; and having as much as possible happen over >> P2P networks rather than client/server systems via well-known domains >> is one step at reducing vendor lock-in) >> >> In practical terms, currently there are new releases hosted on >> bitcoincore.org every month or two, which look like they include ~4GB of >> debug-enabled archives, and maybe ~1GB of release data. Adding an extra >> ~10GB every 3 or 6 months is probably okay, though the extra transfer >> bandwidth for new installs might be significant and less reasonable. I'm >> not sure what the speed of downloading the utxoset is likely to be -- >> I get maybe 16MB/s currently, but maybe you'd expect that to go down >> significantly if setting up a new node went from a 100MB to 100x that. >> >> > 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? >> >> Part of being "opt-in" includes having the code already available, so >> it's just a matter of setting a config option, rather than implementing >> the spec yourself. >> >> > Furthermore, having the snapshot be distributed by Bitcoin Core makes >> the >> > trust model explicitly clear: if you don't trust downloading a snapsho= t >> > from the Bitcoin Core website then you certainly shouldn't be trusting >> the >> > hash committed to in the Bitcoin Core binary. >> >> If the download is secured by a hash, then issue isn't whether you trust >> the download (you check the hash anyway), it's whether the download >> might be unavailable, censored, or unreasonably slow. P2P distribution >> gives you different, potentially better, tradeoffs there. >> >> > 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. >> >> Hosting the data on a single centralised site is exactly equivalent to >> one well-known node on the P2P network supporting 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 bandwidt= h >> > usage, not decreases. >> >> The increase in bandwidth of downloading the utxo set and also downloadi= ng >> the entire blockchain history is about the same as maybe five weeks' >> of block data. If you can't afford that, you likely can't afford IBD at >> all. Conversely, if you've got some unmetered way of doing IBD, then you >> can likely use the same method for the utxo set download. If that method >> happens to be "I already have a local node that I want to duplicate", >> then having utxo set sharing over p2p makes that more convenient. >> >> > 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 nod= e >> > also needs to keep up with new blocks and transaction relay, which wou= ld >> > take away available bandwidth/CPU from validating in the background. >> >> A node can run in blocksonly mode to avoid transaction relay costs, and >> if a node can't keep up in blocksonly mode while doing background IBD, >> it also likely can't catch up just doing foreground IBD -- it's the same >> amount of data to receive and process either way. >> >> > 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. >> >> The time to download and reconstruct a particular recent utxo set from >> a snapshot is significantly lower than the time taken to do an entire >> IBD up to that same point. Without a utxo set (or a utreexo root) you >> aren't yet running a node, so you can't do whatever you were wanting to >> do with your node, which is presumably accepting payments. >> >> If you're willing to spend the time to IBD, or willing to adopt a >> different trust model that takes even less time, that's fine, you >> should continue using other approaches. Trying to prevent other people >> from making different choices and helping their peers who make the same >> choices doesn't seem a sensible use of your time. I realise I'm fighting >> against the "there's a right way to do things; my way is that right way; >> doing it any other way is wrong; and wrong things should be prevented >> at every turn" meme, but oh well, that's my way, I guess. >> >> Of course, If there are some novel tradeoffs that would change people's >> minds about whether AssumeUTXO is what they want if they knew about them= , >> then that's good to know about, but I don't think you've come up with >> anything along those lines. >> >> Cheers, >> aj >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/bitcoindev/rThmyI8ZN3Q/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CADpMdeOx5c3yJ1b_0OC-07m5_uv= ObQRSAfwxKm3CvX59anCYhw%40mail.gmail.com > > . > --=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/= CALZpt%2BGqDOVQqtmSZnK3cGzu33ivfK6ZZsQzCHfUqFWbbE%2BDVQ%40mail.gmail.com. --0000000000006e61300653f194e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fabian,

> I am not sure I can follow your poi= nt 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 somew= here else it will get an actual UTXO set.

Ya es ist ein gut frage, = i think i've been confused by the following
point documented in your= bip draft "either from a trusted source or
by selecting a root wit= h agreement among multiple peers". For the
first alternative, i.e a= root of the merkle tree of chunks of the
utxo set, the chunk can be ver= ified one by one against the hardcoded
value in a software implementatio= n.

I was thinking more about the second alternative where it's a= n agreement
among multiple peers, where it sounds step one sybil all you= r peers
(what can be done for the bip 157 security model), then step two= provide
crappy utxo step, the correctness (not even talking about the a= uthenticity
of the utxo set itself) of the merkle root is only received = when you got
the latest chunk.

Whatever the "source" se= curity model, I think you have a cpu asymmetrical
denial-of-service issu= e, i.e a "honeypot" adversary runs a full-node on
azure peer f= or good connectivity, announces the node_utxo_set flag and
starts to mal= leated chunks to provoke SHA256 failure and make you run for
nothing cpu= cycles. Of course, you have a variant of the attack, where
the peer ann= ounce the chunk, however wait up to max_timeout value minus
some delay a= nd announce the chunk (it's open source software the timeout
is a pu= blic value, the enemy knows the system).

And so on as a malicious p= eer can fast feed your addrman with node_utxo_set
flags. Same issue than= for bip 157 / bip 158, there is no economical symmetry
between the serv= icing peers and the receiving ones, so only a minority of
networks peers= can be expected to flag it, easier for an adversary to override
your lo= cal addrman, or whatever addr store...

Implementing this protocol ro= bustly is a monster of complexity, and frankly
from an implementation vi= ewpoint it's not worthy the complexity at the P2P
level, e.g if you = take bitcoin core network stake there is already far enough
problems wit= h tx or blocks relays.

Moving forward with this proposal, my practic= al suggestion would be to split
this bip in two documents: one as an ove= rlay-network implemented above BIP434
feature mechanism (that way if you= don't like it, shrug about it), and another
one to precise the &quo= t;source" security model (that way if you don't trust bitcoin
c= ore development process or you know that gregory wuille make security mista= kes
sometimes error humanum est, an implementation is more free to craft= one).

Especially for the latest one, I do think there would be valu= e for assume-utxo
to have more a web-of-trust model for the "source= ", where the utxo set would be
authenticated against a hash value c= ountersigned by your friends PGP (we have
already bip 322 for the signed= messages iirc). All a suggestion, though from
overlooking on the discus= sion in this ML thread, it sounds to me one constructive
way to move for= ward.

Finally, it's been raised the thing that utxo set could be= committed by the
miners in the headers (see jamesob original proposal <= br>https://github.com/jamesob/assumeutxo-docs/tree/2019-04-propo= sal/proposal).
If the idea is only to improve UX a la btc pay, I don= 't see it. We should
still encourage as much possible to validate th= e chain in full, merely for
the sake of pure p2p network robustness.
=
On my side, low-key interested by assume-utxo for weird ideas of minemaking the life better for p2p systems built on top of bitcoin
https://gnusha.org/pi/bitcoindev/CALZpt+FRPT= hy4qwYThXOY_YJWsGKJuCOqpX1Zt_8SqkeA4bQsg@mail.gmail.com/
though bett= er not to introduce single point of failure.

Best,
Antoine
OTS= hash: 652a1929cf878decd58d94285603d791260970f62beb890279c118f5d3d3a10c
Le=C2=A0lun. 8 juin 2026 =C3=A0=C2=A013:10, Josie Baker &= lt;josie@2140.dev> a =C3=A9crit=C2= =A0:
Hi aj,=C2=A0

I want to push back on this framing:

> = Trying to prevent other people from making different choices and helping th= eir peers who make the same choices doesn=E2=80=99t seem a sensible use of = your time.

Disagreeing with a technical design, or arguing that it s= hould not be merged into Bitcoin Core or added to the p2p protocol, is not = the same thing as trying to prevent people from making different choices. P= eople are free to build, maintain, fork, distribute, and use software with = different trust and architectural tradeoffs. Most importantly, people are a= lso free to offer critiques.

This distinction matters. If every= architectural objection gets reframed as =E2=80=9Cyou are trying to preven= t people from choosing differently,=E2=80=9D then review shifts away from t= he merits of the design and toward the motives of the reviewer. Bitcoin pro= tocol review necessarily includes saying =E2=80=9CI do not think this is a = good idea,=E2=80=9D and sometimes even =E2=80=9CI think this existing featu= re should be removed.=E2=80=9D That is how a conservative project avoids ac= cumulating complexity and compounding technical debt.

Cheers,
<= div>josie

On Fri, Jun 5, 2026 at 1:24=E2=80=AFPM Anthony Towns <aj@erisian.com.au&= gt; wrote:
On Tu= e, May 19, 2026 at 02:32:33AM -0700, josie wrote:
> 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 n= ot),
> 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 snaps= hot
> is then verified against. So why not just distribute the snapshot from=
> bitcoincore.org along with the release?

Is Bitcoin a P2P network, or a product from Bitcoin Core? Should we
design protocols that treat everyone in the P2P network as peers, or
should we give Bitcoin Core a privileged position?

The current draft of the BIP gives a fixed formula for which blocks to
take snapshots from that any node developer can use, with no dependence
on when Bitcoin Core happens to make releases, defines a fixed format
for encoding those snapshots, and allows anyone interested to securely
distribute those snapshots, whether the use the same node software or
not. Isn't that fundamentally more in-tune with how Bitcoin should work=
than "oh, just download and trust the data from this website" ?
(Even if you don't think people should be running different clients, having the *option* to do so avoids people being vendor lock-in being
used to gain undue influence; and having as much as possible happen over P2P networks rather than client/server systems via well-known domains
is one step at reducing vendor lock-in)

In practical terms, currently there are new releases hosted on
bit= coincore.org every month or two, which look like they include ~4GB of debug-enabled archives, and maybe ~1GB of release data. Adding an extra
~10GB every 3 or 6 months is probably okay, though the extra transfer
bandwidth for new installs might be significant and less reasonable. I'= m
not sure what the speed of downloading the utxoset is likely to be --
I get maybe 16MB/s currently, but maybe you'd expect that to go down significantly if setting up a new node went from a 100MB to 100x that.

> 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?<= br>
Part of being "opt-in" includes having the code already available= , so
it's just a matter of setting a config option, rather than implementing=
the spec yourself.

> Furthermore, having the snapshot be distributed by Bitcoin Core makes = the
> trust model explicitly clear: if you don't trust downloading a sna= pshot
> from the Bitcoin Core website then you certainly shouldn't be trus= ting the
> hash committed to in the Bitcoin Core binary.

If the download is secured by a hash, then issue isn't whether you trus= t
the download (you check the hash anyway), it's whether the download
might be unavailable, censored, or unreasonably slow. P2P distribution
gives you different, potentially better, tradeoffs there.

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

Hosting the data on a single centralised site is exactly equivalent to
one well-known node on the P2P network supporting 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 band= width
> areas are often on metered bandwidth and AssumeUTXO increases bandwidt= h
> usage, not decreases.

The increase in bandwidth of downloading the utxo set and also downloading<= br> the entire blockchain history is about the same as maybe five weeks' of block data. If you can't afford that, you likely can't afford IB= D at
all. Conversely, if you've got some unmetered way of doing IBD, then yo= u
can likely use the same method for the utxo set download. If that method happens to be "I already have a local node that I want to duplicate&qu= ot;,
then having utxo set sharing over p2p makes that more convenient.

> Furthermore, if low bandwidth is a concern, has
> anyone taken the time to do the math and verify that the node will cat= ch up
> to the snapshot in a reasonable amount of time? As a reminder, the nod= e
> also needs to keep up with new blocks and transaction relay, which wou= ld
> take away available bandwidth/CPU from validating in the background.
A node can run in blocksonly mode to avoid transaction relay costs, and
if a node can't keep up in blocksonly mode while doing background IBD,<= br> it also likely can't catch up just doing foreground IBD -- it's the= same
amount of data to receive and process either way.

> 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 ab= out
> transactions. This implies the node may never catch up, or catch up so=
> slowly that it invalidates the trust model of AssumeUTXO.

The time to download and reconstruct a particular recent utxo set from
a snapshot is significantly lower than the time taken to do an entire
IBD up to that same point. Without a utxo set (or a utreexo root) you
aren't yet running a node, so you can't do whatever you were wantin= g to
do with your node, which is presumably accepting payments.

If you're willing to spend the time to IBD, or willing to adopt a
different trust model that takes even less time, that's fine, you
should continue using other approaches. Trying to prevent other people
from making different choices and helping their peers who make the same
choices doesn't seem a sensible use of your time. I realise I'm fig= hting
against the "there's a right way to do things; my way is that righ= t way;
doing it any other way is wrong; and wrong things should be prevented
at every turn" meme, but oh well, that's my way, I guess.

Of course, If there are some novel tradeoffs that would change people's=
minds about whether AssumeUTXO is what they want if they knew about them, then that's good to know about, but I don't think you've come u= p with
anything along those lines.

Cheers,
aj

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://group= s.google.com/d/topic/bitcoindev/rThmyI8ZN3Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitco= indev+unsubscribe@googlegroups.com.
To view this discussion visit https://= groups.google.com/d/msgid/bitcoindev/CADpMdeOx5c3yJ1b_0OC-07m5_uvObQRSAfwxK= m3CvX59anCYhw%40mail.gmail.com.

--
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/bitcoindev/CALZpt%2BGqDOVQqtmSZnK3cGzu33ivfK6ZZsQzCHfUqFWbbE%2BDVQ%= 40mail.gmail.com.
--0000000000006e61300653f194e4--