From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 19 May 2026 19:04:21 -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 1wPWIG-0000Lv-CT for bitcoindev@gnusha.org; Tue, 19 May 2026 19:04:21 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-439bc8a6ce4sf5867430fac.2 for ; Tue, 19 May 2026 19:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779242653; x=1779847453; 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=74IGNkouxFj73eyFfkOVpuHmfGqqqNdJNn3HTOvMsog=; b=aXjU0IkPamdo0lV+kjz87y8eCJD2kD2zyCADTGEpHVpfDyhSePqdx4tGnYECfeSXOY awAzpmz4QSIVh6Lg3RDBA7dPTs9bQ4aOzwrn7BCWleBooRiojBPTi9yQdPVraySwH46P 3L4BGSEzTbgCz7FXnL8qmhBulj6l7PJFMkMxUg6ITXA0TDGGwNdI0q8AaqPpHqGKUZf3 nu5VD5WzWQgwz0zn+NCg2fQ3JrBcK08MuEcOmIO8K8qPuaRPvNxuP2TgCp49rTX1oN3L 4NZW502CynDOFx3eHpnmUyLCAcH5e9QBNdg1nHNynF4xUgLyxdxcdVCuB55Mjy9XSKMa 6fhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil.org; s=google; t=1779242653; x=1779847453; 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=74IGNkouxFj73eyFfkOVpuHmfGqqqNdJNn3HTOvMsog=; b=oszGlrxuqgVf6rNzNitAoTZkSZpWlw88k/1XA/pzZ/wToNoL0IS0b878BNGEvilxWX uf9DD5HQgTByOzEoNsmHL6eMzmqmtFel6rkcXeJDM6QklP6dWElS85QQMTZtX5KnyZBe wNvK2Gs2I9+mnHC1HF8P8FuelxIyzfHYL6eMgsEviQKifj5KOQYfmTV0IyyRdymMGuZl EkQnabTXEVv2Deyr9UR51y1zul3Bnmwv7pxO51ThDae7sm6JCqcJJNYXylXnpWpvwuHI Jaw0TF7LnOKJhBpP0D+Ht36wfj2BCg/+DdxatXz4fFjS8XAYqNCJzcGaL06yLWUjhwP9 LbSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779242653; x=1779847453; 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=74IGNkouxFj73eyFfkOVpuHmfGqqqNdJNn3HTOvMsog=; b=mdM2epQYqvBcXlE/kVLvoA8ZzIkGZLYrTqkV0anehWh7t7WZTQ4i3+yHbA5syEplfJ pU63zOXDxQabNlQj+x013y3RdBZ7R1FbEl+UyxhIht5ikBCuy9HmUUe/nB+7ms5NjBzn I8UiDL1u4ktPtENuq8fqInXW+OZyz20+JgP/0MOfGKj2n0XmTpz503+bMbCMZ/m6OQUc ejdzlMCpygKAAISh2d53dJkUnnJrDVclYkMzJTxUg2XQZFCZDgmE3OWDo5qLToEFA+Sk J5c7cATQQ7f4vqivtP+wpXhksok17+Ysuk/HBgBczPN5Y+reYgJXBaUm0cdnI5/tkTAc /WWw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8Nzmoqc7okKx640OIhMZel6/Yl4FAM6g6ImMBu5FaIj3Fk8YgptHubgPLo46EJR2qLDdWoocYAOxz9@gnusha.org X-Gm-Message-State: AOJu0YzY4dxJ0AHvVAKXCVQs0S6xnGXiRoX66HFZy+oJ/JKrPtnBIH/B TTUNHDApBk9b+4tuBHdlpJU1PQFqx6q1AmvyINIC6ge6vO/nMbcmaVbb X-Received: by 2002:a05:6871:5e8f:b0:42f:e6c8:2ea8 with SMTP id 586e51a60fabf-43a2d9625f1mr14358688fac.6.1779242653150; Tue, 19 May 2026 19:04:13 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNLRdaQnUqhZyiDm9RUyQT38Yb8mrVGFgrdSMMLEjVVXg==" Received: by 2002:a05:6870:2492:b0:439:d3ee:8e40 with SMTP id 586e51a60fabf-43a01d46d5cls5488933fac.1.-pod-prod-09-us; Tue, 19 May 2026 19:04:08 -0700 (PDT) X-Received: by 2002:a05:6808:6704:b0:464:3d5d:d9d4 with SMTP id 5614622812f47-482e592e921mr14516758b6e.39.1779242648298; Tue, 19 May 2026 19:04:08 -0700 (PDT) Received: by 2002:a05:690c:4507:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7c698ddb9c3ms7b3; Tue, 19 May 2026 16:20:09 -0700 (PDT) X-Received: by 2002:a05:690c:c0b:b0:7d0:ef8:6898 with SMTP id 00721157ae682-7d00ef86958mr38184887b3.14.1779232808711; Tue, 19 May 2026 16:20:08 -0700 (PDT) Date: Tue, 19 May 2026 16:20:08 -0700 (PDT) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: <20050ee8-6bd6-4372-a81e-ef51ffcc376an@googlegroups.com> In-Reply-To: <6F9aFh3mB9geayXC2ScrYoLxVlN-4Kc3yuLDjc0mZPK4kIehqoKobca8fADI65TNuwNslVHDMWq3YyRMFgI7HyXI-tY9spsQqbNJ42gGPsM=@protonmail.com> References: <002301dce4cf$27bc3040$773490c0$@voskuil.org> <26c7fd2e-d35d-4ed4-9638-18c95efc75dfn@googlegroups.com> <062656d4-7ddd-4fa4-8db0-48bae6d73b42n@googlegroups.com> <6F9aFh3mB9geayXC2ScrYoLxVlN-4Kc3yuLDjc0mZPK4kIehqoKobca8fADI65TNuwNslVHDMWq3YyRMFgI7HyXI-tY9spsQqbNJ42gGPsM=@protonmail.com> Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1164038_644556148.1779232808085" X-Original-Sender: eric@voskuil.org 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_1164038_644556148.1779232808085 Content-Type: multipart/alternative; boundary="----=_Part_1164039_636812456.1779232808085" ------=_Part_1164039_636812456.1779232808085 Content-Type: text/plain; charset="UTF-8" > 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 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/20050ee8-6bd6-4372-a81e-ef51ffcc376an%40googlegroups.com. ------=_Part_1164039_636812456.1779232808085 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > From: Fabian

> > Validating the headers is inconseque= ntial if you are not verifying tx
> > inclusion. That's what SPV= is, and people should not be misled into
> > believing that thi= s is SPV.
>
> I did not claim header validation alone vali= dates 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 hav= ing 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 ch= ain 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 clearl= y talking about the period between obtaining the assumption and having vali= dated it. This is the entire purpose of the feature. Defending the security= of the feature by referring to the time *after* the feature becomes irrele= vant is non-responsive.

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

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

> Wh= at I wrote was that an AssumeUTXO node "is not 'not validated'".

And this is incorrect in the relevant period, and moot once that period en= ds.

> 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 fo= r (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 us= er
> into accepting a transaction that spends UTXOs which exist onl= y in a malicious
> snapshot, the majority of mining hashpower would= have to be running nodes that
> accepted and continued to run base= d only on the same malicious snapshot.

It seems that it's not ap= parent to you that you are exactly describing SPV. The recipient cannot val= idate the tx, or the block, or even the amount of the prevout for non-segwi= t txs. But he can verify inclusion - by doing exactly what SPV does. The wa= llet follows the strong chain, verifies inclusion, and assumes validity of = what's included. This is exactly the SPV security model. SPV with extra ste= ps.

However it has notable downsides in relation to SPV.
(1) startup cost is much higher (big download)
(2) wallet complexi= ty is pushed into nodes (e.g. dual chainstate, see thread)
(3) inclusi= on proofs are not available for any tx supposedly confirmed within the assu= mption window (usage gap)
(4) trust must be established in the assumpt= ion in order to prevent very costly DoS (wasted full chain validation - sam= e problem as swift sync)
(5) degrades the formerly trustless p2p netwo= rk.

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

Th= is has been covered and is not relevant.

> Even then, backgro= und 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 i= s a long-term solution to performance. At some point it might take years to= perform a sequential validation.

> > Above you make the e= xplicit 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 i= ntentionally leaves the source of the Merkle root to the
> implemen= tation.

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

This proposes a very poo= rly 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

--
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/20050ee8-6bd6-4372-a81e-ef51ffcc376an%40googlegroups.com.
------=_Part_1164039_636812456.1779232808085-- ------=_Part_1164038_644556148.1779232808085--