From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 24 May 2026 14:01:34 -0700 Received: from mail-oi1-f185.google.com ([209.85.167.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wRFx0-0004RU-2U for bitcoindev@gnusha.org; Sun, 24 May 2026 14:01:34 -0700 Received: by mail-oi1-f185.google.com with SMTP id 5614622812f47-4857b690d44sf1255475b6e.3 for ; Sun, 24 May 2026 14:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779656487; x=1780261287; 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=WyyklyhLeI/L3nNp+NeBvXSXQY034p6eZHEZg/udiT4=; b=TLdqeurHG7VzRW4vsqDXY9Cw7bcGl4rW/ywbR4IKRHiBvxF+MyyOa0BBZr/2rLa0uV +xSBIQUWCj5f7jlZAcb+6feks72wgqB2JJzbNNq3zeFfDz+ET/fbjUpQsuJy2EF7/Lmj /PPmiNOiXTbOTSuSeEEvTWhBDz2n1h5h67aZAXpNf9KcTkgeSoVWF+Q73holy2GcFNWg D8fR1jx61xCrrsnsji7EkhKbhIb4DVcDq/gdlqJJZSPMvoGegFJK9+bR0RePQ9yw4BZD RK08UE6IEx6XSYEhNafCRyEcdOf1M/Ia7KWuit2x0F1XShMNzoFql1TmAxQi1LB2QOsY YMsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil.org; s=google; t=1779656487; x=1780261287; 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=WyyklyhLeI/L3nNp+NeBvXSXQY034p6eZHEZg/udiT4=; b=hmhNHeRi7Qs3iZk5h8MHUZWsFUlrOhQ5OdccJUWN9MnnMNl18rc2DbMRmWkXc7QRCE 4Lr7HhFO2TOi3DRZXffzuIqZmqOKVBiJkRAZSGKGkn9epHWwNBgoq0Vskp0fuWjBi4gp Gb+lx1NAgKr0zwzLmZLMe9ebtS9AhfU2hjl7fT+wEJ0rDDhCLBqwJejxbvXc8a8ff3Do FoFaQIa3ght+6ModmNj/0DAy67On7JvGG3klmEnoTo2o1Li1AmAuMZNAi48ij0HJzI9d WTGsWX3CC4bfj1VHVn9AxSkHZBZMVYmB5TIFEy4FT0gJK83j5uuriunmokI91bNVYq3V 5L+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779656487; x=1780261287; 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=WyyklyhLeI/L3nNp+NeBvXSXQY034p6eZHEZg/udiT4=; b=cgxPpRgZCq4dAgd1IxIFEjvcQjkQ0/LEQoBxLK8GOBbw5ezjdCZDFxFCcdOvJjEzpo +3MYjpL4mSqsJTn1aVSe/ZSQF1R8eyrvBe2Fv2D9ZXIUKeDVCgGtfGqPOwCViSTfrJuz jMbMATKev7E7do7+RT6Z9vs/31aTFV6BqYdg6vrAebGGW0MxFYI3pbt97tuaNxteK3ux 4HHQNe0F1FgqsDBaEhYpp8gcupGWCyOyJJr/oc6xmhXj+ZzbD4PNjA5ngbyZHDs7qBP0 TmQCFPgt5+PGHkM/eySS8/jnDPD3QFuWoWkq+C6MmytBoSZBpPKnLnb6lCOl20yiw8dr +vVQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ+rLSkggtO1M8zQiFK3fSwECxThc/BBRd4hvqc7YkzDYe5OpyD9GmLarM36K1FjEbzXnGQ8XielvkTJ@gnusha.org X-Gm-Message-State: AOJu0YxgBimcT2f40IqCsAE1eVh5/Jy6KnzURj6hzBTOzMO3AhzYtavS ObnM9Ndr0uUCixAXgJ3eWkoyilI2PhOAK8t5Z9+EaXIGNgsi1n/Nr6jO X-Received: by 2002:a05:6808:80a6:b0:485:29d7:70a9 with SMTP id 5614622812f47-4854a3e178cmr7433536b6e.41.1779656486675; Sun, 24 May 2026 14:01:26 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMPBgllkjOvi0XkVPhjJyDYe56C7xh8AUSoH1AcFbUrJFQ==" Received: by 2002:a05:6870:f22a:b0:43b:6f92:1c26 with SMTP id 586e51a60fabf-43b6f92c577ls1617749fac.0.-pod-prod-09-us; Sun, 24 May 2026 14:01:21 -0700 (PDT) X-Received: by 2002:a05:6808:6603:b0:479:d779:353e with SMTP id 5614622812f47-4854a3fa397mr7511738b6e.24.1779656481354; Sun, 24 May 2026 14:01:21 -0700 (PDT) Received: by 2002:a05:690c:a081:20b0:7ba:f1b3:9504 with SMTP id 00721157ae682-7d36931b84cms7b3; Sun, 24 May 2026 13:58:27 -0700 (PDT) X-Received: by 2002:a05:690c:9c10:b0:7cf:e22b:fc49 with SMTP id 00721157ae682-7d3356de6camr130580357b3.31.1779656306608; Sun, 24 May 2026 13:58:26 -0700 (PDT) Date: Sun, 24 May 2026 13:58:26 -0700 (PDT) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: <1c4389e4-e38c-4080-b8a7-f2886d5b923cn@googlegroups.com> In-Reply-To: References: <26c7fd2e-d35d-4ed4-9638-18c95efc75dfn@googlegroups.com> <062656d4-7ddd-4fa4-8db0-48bae6d73b42n@googlegroups.com> <6F9aFh3mB9geayXC2ScrYoLxVlN-4Kc3yuLDjc0mZPK4kIehqoKobca8fADI65TNuwNslVHDMWq3YyRMFgI7HyXI-tY9spsQqbNJ42gGPsM=@protonmail.com> <20050ee8-6bd6-4372-a81e-ef51ffcc376an@googlegroups.com> Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_666192_1225588116.1779656306140" 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_666192_1225588116.1779656306140 Content-Type: multipart/alternative; boundary="----=_Part_666193_605425738.1779656306140" ------=_Part_666193_605425738.1779656306140 Content-Type: text/plain; charset="UTF-8" > Hi Eric, > > I disagree that SPV-during-IBD is "far more trustworthy." Sipa already > said this better than I could in the Bitcoin Core pull request discussion > but SPV by construction never validates UTXO state and instead trusts > hashrate majority for chain validity In this thread on May 7th you wrote: >>> I can not refute critique of something that is not part of this proposal >>> except for pointing out that what you are insinuating is not something I >>> am working on or plan on working on and I am not aware of anyone working >>> on skipping IBD and I would not endorse such a proposal if it were to be >>> published. In contrast to some hypothetical dangerous future extension... On the Bitcoin Core pull request entitled "p2p: UTXO set sharing" #35054, the presumably same Sipa on May 20th wrote: >> So my question is: if we had the option of a assumeutxo with P2P sync, but >> without background re-validation, would that tilt the scales for commenters >> here, in one way or the other? The reduction in bandwidth, computation, and >> validation code complexity may make it more appealing. and in a follow-up post: >> I refer to the current approach of background validation of the chain prior >> to the pre-assumeutxo sync point as re-validation, because it is validating >> something that is already trusted to be correct anyway. I am arguing for - >> at least as a thought experiment - dropping that re-validation. That indeed >> means not validating it. >> ... >> The dual chainstate is only there for re-validation. I am suggesting not >> doing that. >> ... >> I think getting rid of the background re-validation actually improves upon >> that, by ripping off the facade that makes it seem like something better >> than a trusted hash in the source code. https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4501781606 Despite the fact that this is clearly a proposal (even if initially presented as a "thought experiment") to drop validation from your proposal, and that you said just 13 days earlier, "I would not endorse such a proposal". You are not only failing to reject it - you are quoting favorably from the very same post. You rejected this possibility as a "slippery slope" argument. > AssumeUTXO trusts the same code-review process that already covers the > consensus rules implementation. It is a different trust model and I > don't think one is better than the other. Who's review process? The Central Bitcoin Team? > SPV also has many downsides which are well documented... BIP 157/158 resolves > the privacy issues but still doesn't validate UTXO state. Which is why there is full validation. Assume utxo also does not validate the utxo state (it assumes it). So you aren't even suggesting a distinction. > Your point about wallet-complexity in the node goes both ways: SPV requires > a wallet to implement filter matching, Merkle-inclusion verification, > and SPV-specific message handling, while AssumeUTXO requires no wallet > changes. No changes are necessary to any wallets without this proposal. > I also don't see how the "very costly DoS" could happen. > If somehow a maleated snapshot wouldn't match that snapshot > can be replaced by the fully validated UTXO set but there is no scenario > where the full chain validation is wasted. If you trusted the wrong bros, and you actually validate, you will find out once you finish validation, and at that point (assuming implementation) you will have the correct state. However you will have to validate everything above the assumption, since the previous "validation" was based on an invalid assumption. So that portion of the validation is wasted. And all transactions accepted until that is completed are also verified only by SPV. > And, as I pointed out earlier, > I don't see one or the other model as more trusted and so I also don't see > the p2p as more or less trustless with this proposal. The proposal is fully trusting a central authority. SPV is trusting that majority hash power is kept in check by the majority of economy actually validating. These proposals of nobody validating beyond SPV shift the entire security model of Bitcoin (as I pointed out in my first post here and you rejected as a "slippery slope argument") to SPV *without the check*, IOW majority hash power control over validity. > Finally, you said "People already widely use SPV wallets and direct them > to their own full nodes for better security." If people already have their > full node then they certainly have no need for AssumeUTXO. So I think your > arguments just don't speak to the use case the BIP targets. My argument speaks directly to the rationalization for fundamentally changing the trust model of Bitcoin as matter or protocol specification. Nobody is suggesting that implementations can't keep shipping "assume valid", "assume utxo", "assume utreexo", and whatever other trust-centralized modes they can come up with. However this community protocol process must not be coopted into providing cover for trust-me-bro "consensus". > However, I'm not dismissing SPV-during-IBD as a potentially interesting > development that someone could explore. It's already in widespread use and suffers only from the terrible experience of having to sync up a node and then having to sync up an Electrum server, each of which can take days to weeks. Those are very solvable problems. 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/1c4389e4-e38c-4080-b8a7-f2886d5b923cn%40googlegroups.com. ------=_Part_666193_605425738.1779656306140 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Hi Eric,
>
> I disagree that SPV-during-IBD is "far mo= re trustworthy." Sipa already
> said this better than I could in th= e Bitcoin Core pull request discussion
> but SPV by construction ne= ver validates UTXO state and instead trusts
> hashrate majority for= chain validity

In this thread on May 7th you wrote:

= >>> I can not refute critique of something that is not part of thi= s proposal
>>> except for pointing out that what you are insi= nuating is not something I
>>> am working on or plan on worki= ng on and I am not aware of anyone working
>>> on skipping IB= D and I would not endorse such a proposal if it were to be
>>>= ; published. In contrast to some hypothetical dangerous future extension...=

On the Bitcoin Core pull request entitled "p2p: UTXO set sharin= g" #35054, the presumably same Sipa on May 20th wrote:

>> = So my question is: if we had the option of a assumeutxo with P2P sync, but<= br />>> without background re-validation, would that tilt the scales = for commenters
>> here, in one way or the other? The reduction i= n bandwidth, computation, and
>> validation code complexity may = make it more appealing.

and in a follow-up post:

>= > I refer to the current approach of background validation of the chain = prior
>> to the pre-assumeutxo sync point as re-validation, beca= use it is validating
>> something that is already trusted to be = correct anyway. I am arguing for -
>> at least as a thought expe= riment - dropping that re-validation. That indeed
>> means not v= alidating it.
>> ...
>> The dual chainstate is only t= here for re-validation. I am suggesting not
>> doing that.
= >> ...
>> I think getting rid of the background re-validat= ion actually improves upon
>> that, by ripping off the facade th= at makes it seem like something better
>> than a trusted hash in= the source code.

https://github.com/bitcoin/bitcoin/pull/35054#= issuecomment-4501781606

Despite the fact that this is clearly a = proposal (even if initially presented as a "thought experiment") to drop va= lidation from your proposal, and that you said just 13 days earlier, "I wou= ld not endorse such a proposal". You are not only failing to reject it - yo= u are quoting favorably from the very same post. You rejected this possibil= ity as a "slippery slope" argument.

> AssumeUTXO trusts the s= ame code-review process that already covers the
> consensus rules i= mplementation. It is a different trust model and I
> don't think on= e is better than the other.

Who's review process? The Central Bi= tcoin Team?

> SPV also has many downsides which are well docu= mented... BIP 157/158 resolves
> the privacy issues but still doesn= 't validate UTXO state.

Which is why there is full validation.
Assume utxo also does not validate the utxo state (it assumes it)= . So you aren't even suggesting a distinction.

> Your point a= bout wallet-complexity in the node goes both ways: SPV requires
> a= wallet to implement filter matching, Merkle-inclusion verification,
&= gt; and SPV-specific message handling, while AssumeUTXO requires no wallet<= br />> changes.

No changes are necessary to any wallets witho= ut this proposal.

> I also don't see how the "very costly DoS= " could happen.
> If somehow a maleated snapshot wouldn't match tha= t snapshot
> can be replaced by the fully validated UTXO set but th= ere is no scenario
> where the full chain validation is wasted.

If you trusted the wrong bros, and you actually validate, you will = find out once you finish validation, and at that point (assuming implementa= tion) you will have the correct state. However you will have to validate ev= erything above the assumption, since the previous "validation" was based on= an invalid assumption. So that portion of the validation is wasted. And al= l transactions accepted until that is completed are also verified only by S= PV.

> And, as I pointed out earlier,
> I don't see on= e or the other model as more trusted and so I also don't see
> the = p2p as more or less trustless with this proposal.

The proposal i= s fully trusting a central authority. SPV is trusting that majority hash po= wer is kept in check by the majority of economy actually validating. These = proposals of nobody validating beyond SPV shift the entire security model o= f Bitcoin (as I pointed out in my first post here and you rejected as a "sl= ippery slope argument") to SPV *without the check*, IOW majority hash power= control over validity.

> Finally, you said "People already w= idely use SPV wallets and direct them
> to their own full nodes for= better security." If people already have their
> full node then th= ey certainly have no need for AssumeUTXO. So I think your
> argumen= ts just don't speak to the use case the BIP targets.

My argument= speaks directly to the rationalization for fundamentally changing the trus= t model of Bitcoin as matter or protocol specification.

Nobody i= s suggesting that implementations can't keep shipping "assume valid", "assu= me utxo", "assume utreexo", and whatever other trust-centralized modes they= can come up with.

However this community protocol process must = not be coopted into providing cover for trust-me-bro "consensus".

> However, I'm not dismissing SPV-during-IBD as a potentially interest= ing
> development that someone could explore.

It's alrea= dy in widespread use and suffers only from the terrible experience of havin= g to sync up a node and then having to sync up an Electrum server, each of = which can take days to weeks. Those are very solvable problems.

= 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/1c4389e4-e38c-4080-b8a7-f2886d5b923cn%40googlegroups.com.
------=_Part_666193_605425738.1779656306140-- ------=_Part_666192_1225588116.1779656306140--