From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 22 Jun 2026 12:03:12 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wbjvM-0006jq-7d for bitcoindev@gnusha.org; Mon, 22 Jun 2026 12:03:12 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-43d2c778510sf4969780fac.1 for ; Mon, 22 Jun 2026 12:03:11 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1782154986; cv=pass; d=google.com; s=arc-20240605; b=RRwDmDyf5UD993BNti5qKaANFzJXCdNFN050XrluSxJFHRwUhR7lGOHRXVD01QIY/M 5kz9xiigT+zbjlA2TonI/KMycKuwsuW/vjasa8CAvDdBaafklQ/qnG0stvT9qHA5txm5 QgXDrcXlDHa8CRl1tSvFKSc/+Wm3BMxdQWmKD2AWdfpxjLxTBSIQaRu3zo3IONGw561r Thw8DY6cnXdGuNvAKmSnwK7pN8A7O1hkYg3Vtz5kQ2rqcQ/m4f/aPfw0jYKocg/8krdJ o5JbagEP4k6b0khqm1/SOe3zBDBzR0UR4U5P6ixgFGQQNaao/9tpqwtS/D/TYY2heKh7 5JkA== ARC-Message-Signature: i=2; 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:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:feedback-id:sender:dkim-signature; bh=6pS+3Ffu7V2sAPqw74YmyX51oJ8ddYhQr2MfpuVy5L4=; fh=ANqQSkQ7xIk00Oxk6Qqhf9ewNo/zLem3nYOVa1qDz7g=; b=Fu/IEgzPRl15ukAwaL3LFLtZzvgdiOyidF1aFA7Yrow2hw4srmZJ7PlEGZkg4BtcN3 WLarl8y8NZgOYesE6DkFq8GmJcbacXPr9zjWhc2Mbf+cj+VrVo7w6egHKyvuqAsUfN1u P9Wo9kFfGv2AULKx1eOnHroP/m3w2ZZRAj6pPocfqBOD7piyILwm4VtMftyrnjpkvZB1 WOx61HfUJ1F9wNN37lJe093fcj+xm3aGs7Lq/7hLTIl/R2T+hQ33Q6eTuBYk8Q21/ALs z+UgXQRfjsjrAbfxkJNUkm5deAieWFGLuDUZI76WOfsNVO9hO9G9lvwXQijluXPQTXu6 ISpg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=bSzRQ9JF; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=DSjLagmI; spf=pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.145 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1782154986; x=1782759786; 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:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:feedback-id:sender:from:to:cc:subject:date:message-id :reply-to; bh=6pS+3Ffu7V2sAPqw74YmyX51oJ8ddYhQr2MfpuVy5L4=; b=uCj8KnvPs3zqES5Cq1UgOYt39cb6/zuGZMgVVYT+8VaLAyqDbBDF3wgI6abfwqV3pX hT4m3hgeMlK5PR2NYaNzXFzdPMW9xAH6c6HisVekroYFITVtROVYAGjVFeD3sAbfgTeY ht8S92ynHEXQiJyTotfXEESm7y9ArrOBjRw3Abs4p8AP8P8/AYgCSPeBnINJ/jMjOYw5 9dgP05qdgZmxZjTQ1Dk/foPm0jYaXg4LKhSkS9Oer0Twq3dtFp4FAc3IcK67epJXv29l M9vevDZAC5f9YKoR2vJ5qsAf5D88YGNid4yCQ9dRpzM3g1AurNS9OLKfTp8HGBgThAtI CtHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782154986; x=1782759786; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:feedback-id:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=6pS+3Ffu7V2sAPqw74YmyX51oJ8ddYhQr2MfpuVy5L4=; b=qAR/txbrWNNaufzdUs+X5qwCm2PQHzYE8EcpgpnG3aw8qb0jZLqWZ+xeo68ryKbGbx 9BPMFat2x4ZxMeTbyaH4ZD17mUajlbe7YiVbaJBhJ9CLAwT+oi38oW71SA/7kkhcGdia saYgeEv+36gYpPqJ+hZoVkF7tqFFOM9wiioKW1hGE9TJDiBDlAZV70F2rtw1y9AN7yDp I1TzsaU7cREgBn0SCnu2LCMb/HQdnuZsJrgStdc8Ua0hI9VugKB2H9bGyznykqZouqTQ VOYx1gOejYxa3lsO2Q5QYGsvZc8FpF823xtUM2Z3XQ7yPoTbWdyxfIA93dmj7hcD9esv Ji/Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AHgh+Ro9yq3cCCWj/T90t/YIpTn4Zydxkt/WCx+nL/slmWrkH/hQ2rvMRH7QN4Iqxn7DYSqbJBK4KqDjIJFF@gnusha.org X-Gm-Message-State: AOJu0YziLvE7RKFKXKgaG6nrQa1dnktWAOzHhV8zzs/73S8+IgC52+62 unW02Cd5T9eh8OXalgR4U8JtSpz2fE5Q80iySIQskr3XiEk6ATLPNj2u X-Received: by 2002:a05:6870:8881:b0:41c:bab:5f9d with SMTP id 586e51a60fabf-447169bd8afmr11225902fac.4.1782154985738; Mon, 22 Jun 2026 12:03:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUecrYPsBaOK3jwN4T+yQ3942FQc8zVCdD5Y5hr2+YtqnQ==" Received: by 2002:a05:687c:23d8:10b0:447:4a70:4987 with SMTP id 586e51a60fabf-4474a70b767ls772059fac.2.-pod-prod-03-us; Mon, 22 Jun 2026 12:03:00 -0700 (PDT) X-Received: by 2002:a05:6808:1529:b0:489:7060:4b05 with SMTP id 5614622812f47-489b078592cmr15170660b6e.21.1782154980773; Mon, 22 Jun 2026 12:03:00 -0700 (PDT) Received: by 2002:a05:6808:2007:10b0:487:5060:f86f with SMTP id 5614622812f47-4896a37eb49msb6e; Mon, 22 Jun 2026 11:44:02 -0700 (PDT) X-Received: by 2002:a05:6a00:2294:b0:835:45bf:9660 with SMTP id d2e1a72fcca58-845561b605emr16125237b3a.42.1782153841632; Mon, 22 Jun 2026 11:44:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782153841; cv=none; d=google.com; s=arc-20260327; b=sQftO8lMTcfx9PvxNVrgNoYlD9+EjGw0oLrU3p89Ig2hffa2pBk2uVoDXJsfXuK4H0 31ZZjdNiM+zbZyVoCYzis4ylbgleRB3fxHcX30ghH88762K7w1cyNCnl0tP4bbdi2Hl5 Dmzhg1D1TB3jecOCrlnvvWbf20rn1r+HjKwj6fO2vn0KiUkq9vuYXgqRxleMbMNZDtzV QghFyXT11x1FC5BLUKaVbqLgyugsWHeyuVQ+kdFGAkl1FPO8PaibLkztQfpi0O0vmgvF e2zeEkXmF5a00n4JP9RtPINFMhaNGQsgxDft++WmHdevPm9YOUHgoue2dxCnJl9Z7UZZ vhHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:feedback-id:dkim-signature :dkim-signature; bh=92uex2qPHGtNGVoB62gL6yJHDcio10num+rNS3g34GA=; fh=x85vIkMWDAjp0WLYQI+1mBMe1xoAB0wjexmTIj8cong=; b=FOyxt61LNwK1zx93wIcjTNjBglpcMox9PKuZqo0PYQ49VrFmsmXD7h+6v3Jftnwy6p Mo/PCWeohO+VWH4+d7xGYcWgueev2zPLHn0Ai6fxy9pw5LY3tVw7Cs05bynwyoZdzzH4 n/erIi+XHVS9DA5IlB/JpQGH+ovKktNakopWqCaJN3Kn2MaKKlE7pUmCJojBF6BSN9Au BWTCGVauBAyBFup27Z0tk5lWuqrKAe9n8aLA16X54jDDyY0ew6BMZDYBpNRn4BTG9DMV cbKzD4DUFvhKkJ+th+qUnZIj0qSkrWWeBvQEIXDqSQd/FmAoiOQwHFAFagRtcsCncK60 r3gQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=bSzRQ9JF; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=DSjLagmI; spf=pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.145 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl Received: from fout-b2-smtp.messagingengine.com (fout-b2-smtp.messagingengine.com. [202.12.124.145]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-84567f32630si242931b3a.4.2026.06.22.11.44.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jun 2026 11:44:01 -0700 (PDT) Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.145 as permitted sender) client-ip=202.12.124.145; Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfout.stl.internal (Postfix) with ESMTP id 3EC9A1D000B3; Mon, 22 Jun 2026 14:44:00 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Mon, 22 Jun 2026 14:44:00 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGkhTQl3Wynlpvf79WaS8H+oWXc43BX8aY1d8NLjoqWJh8axOdG/m2F3E8bNCZAlP GAF+BCenyk5LwmuIIP8outQBpbU3/d5xHt3eX3R38ymNL7ouMeTuEMUvOBmj/Bq/wCBJKw tHApjLR1Q2AQ7k4yK54s/1W6IxPqWPFL9nWiumw7x/2gDTp94iS4i/VlanAP4ojRoT8Kle fdKF0RS7yLkIOHVMxtsQfM6Q0/usrCzUA+9Ip+1AQPmF2Ed42J3ew5T407O0xfI+n4J8jC IO04qZ0ZqwhiYenY+EIRWC6SNJf6SqUZvtf+GhznUwG9tpDx541mXt7rj4fHtaSsGZHsGu S0a6Mm1nkQzT7Nx8IaYasgHybT9N2mya65mlRx7JhIiePDxmi+42aB3fic6i1XsQUkv2B4 2cKtdDeTjDnRiwXE60/sWOAdv4em3MAuc5zTAqpEQKMsDQeHAZlYVqmlW/AFesbjb3CTdp MDkb03aB5i6lBCIhIjH6HPsnZZRa6C4E37ktP4AZNkTXIZCV9+1FWzDRgcKrSV3kX/7+B0 VBmU44TxAXxkxEcNdATbhAILdl7YslMSxX/GLxooO2bBbQNQA7xx2Z29My9ofZu8dMasaV RljkqoVMgzHBwc9TR5xxC0zaD7b8cETA1+c7x8xXOHHL4PbtmAjhkjUxyRyg X-ME-Proxy: Feedback-ID: ie5e042df:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 22 Jun 2026 14:43:59 -0400 (EDT) Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [bitcoindev] [BIP Draft] P2P UTXO Set Sharing From: Sjors Provoost In-Reply-To: <02c201dce227$e808e050$b81aa0f0$@voskuil.org> Date: Mon, 22 Jun 2026 20:43:47 +0200 Cc: Fabian , eric@voskuil.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <19616822-8a03-4de1-99be-72d50479208fn@googlegroups.com> <02c201dce227$e808e050$b81aa0f0$@voskuil.org> To: Bitcoin Development Mailing List X-Mailer: Apple Mail (2.3864.600.51.1.1) X-Original-Sender: sjors@sprovoost.nl X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=bSzRQ9JF; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=DSjLagmI; spf=pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.145 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl 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.8 (/) Hi Fabian, Eric and list, It may be useful to analyse this with the following long term idea in mind: 1. Consider a node that's instantly on. By "on" I mean being able to verify= an incoming transaction, with increasing confidence as the node gathers mo= re information. This allows you to take action, in response to the transaction, earlier the= n if you wait for 100% confidence. If 100% is the minimum acceptable level,= the scheme is strictly worse, because you'll end up downloading more. 2. The best way to build such a node is with backward (block) validation. T= his can be done if blocks both _commit_ to the UTXO set and _contain_ every= thing needed to validate their state transition [0]. A new user could start with just a transaction, block hash and height, rece= ived out-of-bound from the sender. They should have zero confidence at this= point. Their node starts out with a zero knowledge proof for a header chain up to = a recent height, downloads the remaining headers up to the block, then the = block itself. They now have more confidence this a real transaction, but st= ill less than SPV. Now the node does a full header sync, now confidence is at SPV. Then it syncs backward to whenever the commitments were first introduced. T= his gradually increases confidence further. Then finally it forward-syncs the first million or so blocks from genesis. = Now you're at 100%. In this scheme a fraud proof is the block itself. Nodes can gossip block ha= shes as fraud hints. So a node can _disprove_ transaction validity quicker = one can with just linear validation (in either direction). (Unfortunately this degrades to a worst case of having to validate every bl= ock anyway, because your peers claim they're all invalid. It could be mitig= ated by disconnecting a peer if they make a false claim, and prioritising f= raud-hints from outbound peers.) 3. Humans being what they are, they're going to stop somewhere (too early) = in this process. That applies to the above scenario, but also to the present AssumeUTXO impl= ementation. It's reasonable to assume that many people would either delay v= alidating deep history, or permanently skip it. It doesn't matter whether the Bitcoin Core project supports that (discussed= elsewhere in the thread). It's a single prompt and it's a selling point fo= r alternative implementations. If a feature is a trivial patch to Bitcoin C= ore, and if there's a strong incentive to use it, you assume it will be use= d regardless of what developers think is best. We've seen this with changes= to relay policy too. The incentive to skip validating the deep past will increase over the decad= es / centuries. Unless Moore's Law keeps up, but we should not assume that. So this is where the case scenario of concern comes to play: > Op 12 mei 2026, om 17:56 heeft eric@voskuil.org het volgende geschreven: >=20 > It is not hypothetical, and it is dangerous. This understanding is at lea= st 11 years old: >=20 >>> Full nodes using UTXO set commitments is a change to the bitcoin >>> security model. >>>=20 >>> Currently an attacker with >50% of the network hashrate can rewrite his= tory. >>>=20 >>> If full nodes rely on UTXO set commitments such an attacker could creat= e >>> an infinite number of bitcoins (as in many times more than the current >>> 21 million bitcoin limit). >>>=20 >>> Before we consider mechanisms for UTXO set commitments, we should >>> seriously discuss whether the security model reduction is reasonable. >=20 > - Patrick Strateman, 2015 4. As a minor point, in the current design, inflation shouldn't be a proble= m. Nodes can and should calculate the total supply when loading the snapshot. = It will however be a problem in a design where every block commits to the s= tate transition, without including the full state. E.g. with Utreexo each b= lock could contain the merkle forest at its height, but that doesn't tell y= ou the total supply. 5. The bigger problem imo is theft, especially theft of coins that are unli= kely to be claimed by someone else. A malicious cabal of developers could commit a bad snapshot. The theft woul= d be obvious to anyone looking at the code and verifying the snapshot with = an earlier release. But users who don't verify the full history won't notic= e anything wrong until the stolen coins start moving. This could be decades later. Only then do compromised nodes disconnect from= old nodes and alternative implementations. That's when you (hopefully), se= e a chain split, depending on what miners are running. A big delay between when people _know_ fraud happened, and the moment it st= arts impacting their choice of which chain to follow, seems quite dangerous= . The people who initially called it out are forgotten and their warnings o= f this-will-go-wrong get boring. Then it finally happens, but there's sunk = cost. This requires a level of user complacency that's probably fatal for the pro= ject anyway, but still. 6. Given all this, it's reasonable to worry about incrementally moving towa= rds UTXO set commitments, before we have a good design for them. Especially= since there might not be a good design. At the same time, I don't think the current situation is dangerous, and nei= ther is the increment from downloading a torrent, to serving via p2p. The reason is that I don't expect a UXTO commitment soft fork proposal to g= o anywhere, when IBD performance is the only argument for it. People would = righty point out that there is plenty of room, at least in Bitcoin Core, to= make it faster without a soft fork. - Sjors [0] https://gnusha.org/pi/bitcoindev/CAApLimjfPKDxmiy_SHjuOKbfm6HumFPjc9EFK= vw=3D3NwZO8JcmQ@mail.gmail.com/=20 --=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/= A7B1ECA8-4DCF-4AAC-9FC4-0820C199A0DC%40sprovoost.nl.