From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 22 May 2026 06:47:11 -0700 Received: from mail-ot1-f59.google.com ([209.85.210.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wQQDW-0008H9-MY for bitcoindev@gnusha.org; Fri, 22 May 2026 06:47:11 -0700 Received: by mail-ot1-f59.google.com with SMTP id 46e09a7af769-7e60737a946sf571015a34.1 for ; Fri, 22 May 2026 06:47:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779457624; cv=pass; d=google.com; s=arc-20240605; b=HD60RzAC7IOAjukcBL9THLUZBPhzItx2wmNzivE65L/fj/zdYspP4ptX0TSoNfIKam KUasSocd/pXeNwt1vjes5+AMB7s/xQ9VImcq05Xzgw42NrBo6vsQxlNu0xLpTBlA1uXW BqPv+kJLzJsqMAvZmAm5PYHqYMrkX+r9Rdr0yc9PGoZvsFnKx7fFlC/OWRGsO8HwwKAq hG0oNP52PReXW4fyFhhDiLREVWKit9b14WCYPSC4aRngRV4bLg8TJyTF7BZlAgpXNJxz MZVQPpd1l0+X+WpCO+/66t/Aa6vQY4vFfZzijioijAgbl29AQcKylQw6jSXbkLGse1v5 7odA== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=FOr6JF53WFFq0gkU9jFMp/bEL06D+yxr5ueeostfwOU=; fh=W9MtDwk3U0Z6cjNI38s4PJUyUU7zsPsTXdzA8Px5QkM=; b=URhGXTegYZSEp0uDDjmUURd0O6SO8D3rheDJfmrjV2k9yW0loRbOVX/PbNGGVs6gNR qGPj+IeCOLccfQ+d2OFqUa9JvwLX4REjmpLRmxdLZx8HqzC6GKjh0jSJ/PrAoSyIjg71 Vu83rU6zBvExCGNx6tGV2tTLgXOyj+HwQ7D37dzD//JmZl5DeRW1Uqj52rrMnz0RK00y aRMT1ZOql0dj0FyE2JW5wHGzYeapRXmv0urp4XPNh2lURm4OVcjtkBHUQcuiwkX8Vagr y2VOgKjG0t0aqecbrbnPcjfT1+Hwt0jV56ckdpUHWHgSF/tEaydGUFey89pnarX4iBpD vwFg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Iwo7uvHT; spf=pass (google.com: domain of fjahr@protonmail.com designates 79.135.106.28 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779457624; x=1780062424; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=FOr6JF53WFFq0gkU9jFMp/bEL06D+yxr5ueeostfwOU=; b=iZi9tHG0+sev3xT3Rzw6nNw2KPelJy0w9qkOk89OD8jX/G96LxVEfmrnuSDC9uLMvj TumPA4bCXhpNOxVq0+xEqagXPmtA5uyGggf04mBw6vKjx8QzlQeMeVlrgCvBa42q9k4L OdWz95dH5yXihagXD3esC6XAMvna8IysG7D+hSaL43h4a06uC3fwizakSaGWa/KgcDoI oPGbHvZHhR6nEZC1t8QifS0eYixQMPvNe7TlA00jDf6kzGpAO5sEgY895Vcdan4y359a k1Vt4hWycw76wmsz7BptqY2yJ/Js0I6vvbSMNRMz6Vj80rcAwEjG52N7lIeCvGJCNmjZ WjrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779457624; x=1780062424; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FOr6JF53WFFq0gkU9jFMp/bEL06D+yxr5ueeostfwOU=; b=S9JTzD/L2dpYyAP2CcmIYY+QpOJH/gLVC+LbGXKbykS/D7wKkNg2585fFUax+jAgrw B1yB7lNeNfndYSGgXOYrNmcND9kOCFzrCRatdWOw8YlrscMKZ0C7L/nljWpU8pWsDzFY CsNg0c4vDUDMlqxLrI1YCQ4rW1iSfjpWwXaw4scXHQoJMBB8VnBgMFCGr+9waTBEPSFv rg3iApO+AN3+USscJUcgIUeFR+QU3HuDH4cCG7i5MYrUfweGpB/pZUt+80X8HLgDsAyk AaTJ9f9XIEr3v6qC0NCaPAM0qCoPmWQDtmPUCDTGMJOLE3OBVqVOgCXiqP6SDKxpZZBs uFPA== X-Forwarded-Encrypted: i=2; AFNElJ+WJKz50ih6ZywYyFpjJ0iBH7B+LeIj2VBl55G3J6HVV9I5BwJppZkdz7nhO0XSJ7FfE/0eoNxTr13K@gnusha.org X-Gm-Message-State: AOJu0YyiGd1Gjg6IbKT47fhWjW4gug2rYlubdoYhLmJJkV3N/tLmHuiB ZRRTqJh2/HVwG6FHugtbljryIXfmhXI4x/QEhhcut6GSU8NfTuNAifCF X-Received: by 2002:a05:6808:169f:b0:485:4179:aaca with SMTP id 5614622812f47-4854a48fcbdmr1686061b6e.43.1779457624444; Fri, 22 May 2026 06:47:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOyTZpsrm1YcHHpkxpIIwfqOKFzqGpaDvzieBsWS28fQA==" Received: by 2002:a05:6870:8e0a:b0:43b:781c:b5e with SMTP id 586e51a60fabf-43b781c0c2bls198169fac.1.-pod-prod-03-us; Fri, 22 May 2026 06:46:59 -0700 (PDT) X-Received: by 2002:a05:6808:23c9:b0:47c:7c7c:c792 with SMTP id 5614622812f47-48549ecf769mr2378365b6e.7.1779457619485; Fri, 22 May 2026 06:46:59 -0700 (PDT) Received: by 2002:ab3:640a:0:b0:301:8327:726e with SMTP id a1c4a302cd1d6-301dee2776fmsc7a; Fri, 22 May 2026 05:32:07 -0700 (PDT) X-Received: by 2002:a05:6512:685:b0:5a8:628c:60b0 with SMTP id 2adb3069b0e04-5aa322b1332mr1030574e87.2.1779453125043; Fri, 22 May 2026 05:32:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779453125; cv=none; d=google.com; s=arc-20240605; b=PZHrzCuWGI2ivADMJ+d3nKi9hbdT7BNt96Edcrc3yGVX3arNq8NTkgat94mcH90b7t 5d+hI/Si8lWdqeMkWuyV0CwU44HpG8Y4gNA5pnnJGur5dK1FTZvsGcp/5QJRkER4W2rp 4JgOBMo4YNlKD/u024mWGZh4DS9nWkBcaC4dq8pPGC/SdfxY2cA10MB9Z33mV5vAwM1b wSlDDbxKhCB9CJgr7fLfnEVCiIxLaPti89rNOF/d5161Eh2bQqKIPT2AXBKURq3Qm7NU PWoa8/Grn4+y2+RfEdUGNADJktPsV6iMv0Gr2EOxGmBTE1El5/rePTzqZaCqHG/pXmNs Y84g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=BAOgtaPZsMOLqwgrSenaIRCHF/ifulkT/TuirV+I1A8=; fh=VUyRMGDsLDyKXHBc8DWjokFBiSMTvXavinKdBJZhUls=; b=VySC2wRkqb0pL48a3HzwXRXhAZdJeLwPwAr8FoCpqAujMgVZvrPbcqg1HMvvV6mo4+ e5zLtydxT11lMBDfQl9VKa7dF1/Ju076GnXtha3jLR4slEq3iiwrW0zXSukPE9/8EXkm tuVS9vf0PLaXKFw1IIKxJ5vOTXUB/gZkAPTCGghsQj5XdvKQ+QQucykEaCHQ9NOoMmDs fE7HYGgxOnQXhwR28cAZ2Y0orAs7ueEs2SS1veB9Xuccf9ixJDqP1yz8ISJZYN/PPrFE 6I8h9yqchZegmdOso8WbZPYUjmVXOjzN4nEIN1bnuaCioVVDcTYFB69mrtawZbRoZXXc zZ/w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Iwo7uvHT; spf=pass (google.com: domain of fjahr@protonmail.com designates 79.135.106.28 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch. [79.135.106.28]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5aa32cf2e4csi32169e87.6.2026.05.22.05.32.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 05:32:05 -0700 (PDT) Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 79.135.106.28 as permitted sender) client-ip=79.135.106.28; Date: Fri, 22 May 2026 12:32:01 +0000 To: Eric Voskuil From: "'Fabian' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing Message-ID: In-Reply-To: <20050ee8-6bd6-4372-a81e-ef51ffcc376an@googlegroups.com> 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> Feedback-ID: 5067558:user:proton X-Pm-Message-ID: 0d5d3a493f0e9eb1c7f594b07176a56f393ad2b7 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_kK7jY5mDkZDApAkMrqZLTnYszZEig3IWtKzuth3z9SY" X-Original-Sender: fjahr@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Iwo7uvHT; spf=pass (google.com: domain of fjahr@protonmail.com designates 79.135.106.28 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Fabian Reply-To: Fabian 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: -1.0 (-) --b1=_kK7jY5mDkZDApAkMrqZLTnYszZEig3IWtKzuth3z9SY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 S= PV by construction never validates UTXO state and instead trusts hashrate m= ajority for chain validity, AssumeUTXO trusts the same code-review process = that already covers the consensus rules implementation. It is a different t= rust model and I don't think one is better than the other. SPV also has many downsides which are well documented and ultimately led to= it's deactivation in Bitcoin Core: a single malicious peer can censor a cl= ient's relevant transactions, filter queries leak privacy and eclipse attac= ks can have amplified impact. BIP 157/158 resolves the privacy issues but s= till doesn't validate UTXO state. Your point about wallet-complexity in the= node goes both ways: SPV requires a wallet to implement filter matching, M= erkle-inclusion verification, and SPV-specific message handling, while Assu= meUTXO requires no wallet changes. This offsets the complexity of the Assum= eUTXO implementation in the node software. In the end both the wallet and t= he node have to be maintained by open source developers and if either don't= work correctly the user is screwed either way. I'm not sure what the user = would need inclusion proofs for, they have the full blocks and can verify i= nclusion. I also don't see how the "very costly DoS" could happen. IBD stil= l works the same, there is a full header sync and then the blocks are downl= oaded and verified as they normally would, nothing about that changes. If s= omehow 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. 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 les= s trustless with this proposal. 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 fu= ll node then they certainly have no need for AssumeUTXO. So I think your ar= guments just don't speak to the use case the BIP targets. However, I'm not dismissing SPV-during-IBD as a potentially interesting dev= elopment that someone could explore. It reminds me of how wallets like Zeus= try to graduate users from custodial ecash to actual lightning in a seamle= ss experience, something like that seems probably doable. But I prefer the = AssumeUTXO trade-offs for the reasons above. Best,Fabian On Wednesday, May 20th, 2026 at 4:04 AM, Eric Voskuil wr= ote: >> 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 s= cenario, >>>> 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 snapsho= t 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. Defendi= ng 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 s= ecurity in this period. The only way it could being doing so is SPV. So I s= aid: > > "Validating the headers is inconsequential if you are not verifying tx in= clusion." > >> 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 e= nds. > >> Headers are validated upfront and the historical chain is validated in t= he background. > > The sole purpose of the feature is to use the node without validation. Va= lidating headers is only useful for (1) SPV or (2) DoS protection while val= idating. > >> Together, that is the same work as a normal IBD, performed in a differen= t 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 mal= icious >> snapshot, the majority of mining hashpower would have to be running node= s 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 SP= V. The recipient cannot validate the tx, or the block, or even the amount o= f the prevout for non-segwit txs. But he can verify inclusion - by doing ex= actly what SPV does. The wallet follows the strong chain, verifies inclusio= n, and assumes validity of what's included. This is exactly the SPV securit= y 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 thr= ead) > (3) inclusion proofs are not available for any tx supposedly confirmed wi= thin 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 o= r forever. As you previously pointed out, this is a long-term solution to p= erformance. At some point it might take years to perform a sequential valid= ation. > >> > 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 b= oth ways here as well. > > This proposes a very poorly implementation of what is fundamentally the S= PV security model, for the period until a node can be fully validated. I do= n'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 nod= es 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/bitcoinde= v/20050ee8-6bd6-4372-a81e-ef51ffcc376an%40googlegroups.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/= GWGvdFMTFt85N06FBbO-RCCeP-MH5T3jpeOohf7hg1FwZTDng5CUeGOoj3yrtOa-ZgMZuAsHSeY= 5sgJyGtLorodlFsbHgWgZhSlfDkzfTGQ%3D%40protonmail.com. --b1=_kK7jY5mDkZDApAkMrqZLTnYszZEig3IWtKzuth3z9SY Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 validate= s UTXO state and instead trusts hashrate majority for chain validity, Assum= eUTXO 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.

SPV also ha= s many downsides which are well documented and ultimately led to it's deact= ivation in Bitcoin Core: a single malicious peer can censor a client's rele= vant transactions, filter queries leak privacy and eclipse attacks can have= amplified impact. BIP 157/158 resolves the privacy issues but still doesn'= t validate UTXO state. Your point about wallet-complexity in the node goes = both ways: SPV requires a wallet to implement filter matching, Merkle-inclu= sion verification, and SPV-specific message handling, while AssumeUTXO requ= ires no wallet changes. This offsets the complexity of the AssumeUTXO imple= mentation in the node software. In the end both the wallet and the node hav= e to be maintained by open source developers and if either don't work corre= ctly the user is screwed either way. I'm not sure what the user would need = inclusion proofs for, they have the full blocks and can verify inclusion. I= also don't see how the "very costly DoS" could happen. IBD still works the= same, there is a full header sync and then the blocks are downloaded and v= erified as they normally would, nothing about that changes. If somehow a ma= leated snapshot wouldn't match that snapshot can be replaced by the fully v= alidated UTXO set but there is no scenario where the full chain validation = is wasted. And, as I pointed out earlier, I don't see one or the other mode= l as more trusted and so I also don't see the p2p as more or less trustless= with this proposal.

Finally, you sai= d "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 the= y certainly have no need for AssumeUTXO. So I think your arguments just don= 't speak to the use case the BIP targets.

<= span>However, I'm not dismissing SPV-during-IBD as a potentially interestin= g development that someone could explore. It reminds me of how wallets like= Zeus try to graduate users from custodial ecash to actual lightning in a s= eamless experience, something like that seems probably doable. But I prefer= the AssumeUTXO trade-offs for the reasons above.

Best,
Fabian

On Wednesday, May 20th, 2026 at 4:04 AM, Eric Voskuil <eric@vosk= uil.org> wrote:
> From: Fabian

> > Validating the headers is in= consequential if you are not verifying tx
> > inclusion. That's wh= at SPV is, and people should not be misled into
> > believing that= this 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 comme= nt first):

>>> Receiving payments without having validated = is an exceedingly unwise scenario,
>>> and not worthy of protoc= ol support.
>>
>> I also need to add that an AssumeUTXO n= ode is not
>> "not validated". The header chain is fully validated= before the snapshot is
>> loaded, and the historical blocks are v= alidated in the background. The work
>> is the same, only the node= becomes usable earlier.

We are clearly talking about the period bet= ween obtaining the assumption and having validated it. This is the entire p= urpose of the feature. Defending the security of the feature by referring t= o the time *after* the feature becomes irrelevant is non-responsive.
You are referring to header validation as if it provides some aspect of se= curity in this period. The only way it could being doing so is SPV. So I sa= id:

"Validating the headers is inconsequential if you are not verify= ing 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 pu= rpose of the feature is to use the node without validation. Validating head= ers is only useful for (1) SPV or (2) DoS protection while validating.
<= br>> Together, that is the same work as a normal IBD, performed in a dif= ferent 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 exis= t only in a malicious
> snapshot, the majority of mining hashpower wo= uld have to be running nodes that
> accepted and continued to run bas= ed only on the same malicious snapshot.

It seems that it's not appar= ent to you that you are exactly describing SPV. The recipient cannot valida= te the tx, or the block, or even the amount of the prevout for non-segwit t= xs. But he can verify inclusion - by doing exactly what SPV does. The walle= t follows the strong chain, verifies inclusion, and assumes validity of wha= t's included. This is exactly the SPV security model. SPV with extra steps.=

However it has notable downsides in relation to SPV.

(1) sta= rtup cost is much higher (big download)
(2) wallet complexity is pushed = into nodes (e.g. dual chainstate, see thread)
(3) inclusion proofs are n= ot available for any tx supposedly confirmed within the assumption window (= usage gap)
(4) trust must be established in the assumption in order to p= revent very costly DoS (wasted full chain validation - same problem as swif= t sync)
(5) degrades the formerly trustless p2p network.

> The= snapshot hash itself would still have to have been
> compromised thr= ough the source code review process.

This has been covered and is no= t relevant.

> Even then, background validation would detect the i= nconsistency when it
> reaches the snapshot height.

The person= is already using the node, and this could carry on for weeks or forever. A= s 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 orac= le 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 re= view. You are trying to have it both ways here as well.

This propose= s a very poorly implementation of what is fundamentally the SPV security mo= del, for the period until a node can be fully validated. I don't see any ju= stification 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 e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/20050ee8-6bd6-4372-a81= e-ef51ffcc376an%40googlegroups.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/= GWGvdFMTFt85N06FBbO-RCCeP-MH5T3jpeOohf7hg1FwZTDng5CUeGOoj3yrtOa-ZgMZuAsHSeY= 5sgJyGtLorodlFsbHgWgZhSlfDkzfTGQ%3D%40protonmail.com.
--b1=_kK7jY5mDkZDApAkMrqZLTnYszZEig3IWtKzuth3z9SY--