From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 17 May 2026 14:32:47 -0700 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wOj6N-00041U-5I for bitcoindev@gnusha.org; Sun, 17 May 2026 14:32:47 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-6961e8fa90bsf3546935eaf.0 for ; Sun, 17 May 2026 14:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779053561; x=1779658361; 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=eDe3q99F0afHtyB4FK3BIfg0NWVHuM6Qiik6Ro2oeJM=; b=W40Qicr+heT2mXGcDWpqUE7FCAVNopsibdV6QIBKv5B2b11s3z+xS66Vqs5nrO5Pn1 Ck8HywQK8nMkYibxVA/+iQfNKqM2CLp27gOXWx99/UqC4GbEX/VoKbx/lyKXyBPQ4/Jk 0mVjSJwyublm5gysoO8EfFp4o6I11dLPUtlXRg1HsneIQmCHKqVN5Sank8X0rQ3dS9hh pdLEqXKigc3RbAY97xiykMHFEwdMDI4LLg4QCsSUHoUrqUscXmAnMAYEtqfnHDlVpHt6 ZXW8AcqoUd8uOHDICaJ/KZcwNj6hZqZgb8PaFuqd2BKMqwxk3o60Y9q9x0cpJGFyiiC6 /YoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil.org; s=google; t=1779053561; x=1779658361; 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=eDe3q99F0afHtyB4FK3BIfg0NWVHuM6Qiik6Ro2oeJM=; b=BZRY6/iAnW/S6uLILRmvxsxe6EBrOGPsLJGLALRC6HvSrj++rd4AOyzyLuvRnoVHPi u3qdH8qK9S0aZ6ITXD6RbgSisc7Y+iY2GhBjEQxsZMes+GoJ87AiKsG/agf3WinO4lD+ 3DHp+k51UwjCWmJid3m6cyAQlM7HS4rw6ieWrnKDYzhqvHJNcuyJRlDOQzDALwpHZRoq n8lNiuUqBSuY5TQBo6cxxMcRJs6ydolunHZ9h3Xv8l4/N40j1bpZxrB31c64SZNAia84 IcGgpQ/Z2t3ILXVCdLBJXxh3oyDnWPAq1K1np9gLFxLKs2WdM3qg9QLBEdZIzLKSvLN2 Rlpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779053561; x=1779658361; 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=eDe3q99F0afHtyB4FK3BIfg0NWVHuM6Qiik6Ro2oeJM=; b=MjVFi8i/YSdu/Tbw874Sol0Za0PnXv6Vqhth4tv9+lzGTHBNJ351gWxjTg/BFWgcJf 63b8qaMEACu7ZJnghGPkI8kxlLw4SgLGtILAsMzZmWsBnuazrhTmoodK0mslMtRYO3MB ddgFCl/doaI9A95sjcBF122lPNQKumSRTEKzs9u+3GTyfEvzq0bQ/ZfxKC1KKkvKht76 Lpt+ehHgJHlWq3MejissWvbxrvoMH3vL6f2eefbOWVZbrGmdGj2TFp3+lMY7wwjXDcfc 5OVWoHuRrbUjKw3kD5wjyfLt8F1WIozxCqqjPJxlpW8NzRFiUVUMJbzAf/wp4IeVyYu5 OpdQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/DJIqQryHXpx630Ekrn46r8FOR04Hi6HYawScXDEojFimDEsHZlmFasFRVSkzBC93Sx3uwTPv7Ydis@gnusha.org X-Gm-Message-State: AOJu0Yz/tWJwG+/myeABlGXkBeC7QNXA/eKbOyx/3KWnKUNv7qb4O2Qt uirJt1bctOqGEoX3FSa88qoobMOdojg2jAeu5WR23sDySeXIzrGdsi2X X-Received: by 2002:a05:6820:2908:b0:696:7f04:eca2 with SMTP id 006d021491bc7-69c9429517emr8467755eaf.9.1779053560856; Sun, 17 May 2026 14:32:40 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMllGH2aj8TL4tapv0OKNluTWqUkscp8/+zn/WL7xbX7Q==" Received: by 2002:a05:6820:61e:b0:67b:f5b9:99d8 with SMTP id 006d021491bc7-69b8c001ccals2145193eaf.0.-pod-prod-02-us; Sun, 17 May 2026 14:32:35 -0700 (PDT) X-Received: by 2002:a05:6808:c3ec:b0:45f:8be:d983 with SMTP id 5614622812f47-482e5615192mr8053613b6e.12.1779053555804; Sun, 17 May 2026 14:32:35 -0700 (PDT) Received: by 2002:a05:690c:6202:b0:7ba:f1b3:9504 with SMTP id 00721157ae682-7c6993cf1f6ms7b3; Sun, 17 May 2026 14:29:59 -0700 (PDT) X-Received: by 2002:a05:690c:dd3:b0:7b8:926e:3f0d with SMTP id 00721157ae682-7c95c6f6efbmr134577467b3.26.1779053398379; Sun, 17 May 2026 14:29:58 -0700 (PDT) Date: Sun, 17 May 2026 14:29:57 -0700 (PDT) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <19616822-8a03-4de1-99be-72d50479208fn@googlegroups.com> <02c201dce227$e808e050$b81aa0f0$@voskuil.org> <002301dce4cf$27bc3040$773490c0$@voskuil.org> <26c7fd2e-d35d-4ed4-9638-18c95efc75dfn@googlegroups.com> Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1092810_722720878.1779053397727" 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_1092810_722720878.1779053397727 Content-Type: multipart/alternative; boundary="----=_Part_1092811_173508816.1779053397727" ------=_Part_1092811_173508816.1779053397727 Content-Type: text/plain; charset="UTF-8" > From: sadiq Ismail Hi sadiq, > I am from a place with metered and slow bandwidth, so assuming U.S. > internet bandwidth and speed specifications for IBD is incorrect and ignores > that not everyone shares the same reality. No such assumption has been made. My post specifically addressed the performance *trend*, which contrary to common assumptions, is improving (everywhere) and will eventually render this question moot. > I will share mine. No number of performance anecdotes can address the outstanding critiques, but I'm happy to cover the other issues. > I can use wallets to receive Bitcoin as an SPV Okay, which is far better than a trusting wallet. > but once you want to sync the and have a node synced to the tip, > I face a significant bottleneck. Why are you syncing the node? Presumably you want a fully validated node - for better than SPV security. You cannot get that from assuming it. You should sync and validate a node and then just connect your SPV wallet to it. This transitions you to actual full node security from SPV security, once that full node security actually exists. > I think if a less-trusted setup were provided, like assumeutxo Assuming is not "less trusted", it's fully trusted. I think you meant "less trustworthy". > with p2p sharing, Since my use case is data analysis, not receiving payments, > I would not face this bottleneck and would definitely use it. It's not clear why you would want a less trustworthy (fully trusted) wallet when you can use a far more trustworthy SPV wallet. And you can transition that same wallet to zero trust once your node is validated, by just pointing your SPV wallet to the node. Furthermore you are not providing any justification for moving this into P2P, the trusted node feature you want already exists. > As a real example of the point Fabian made about using worse alternatives: I > also travelled hundreds of kilometres to a different city to assumeDatadir by > copying the datadir from a trusted friend. Incorporating Core's trusted utxo system into the P2P network does not change this at all. You could have just downloaded it from your friend, or anyone else you trust to provided it. Certainly that's better than downloading it from randos on the P2P network. And you would have the same download cost either way. > The risk of the chain growing so large that syncing takes a long time is real The opposite is happening. This is why I pointed out the declining cost trend. That applies everywhere, not just in the US. And in any case, trust would not be a solution. That's the problem Bitcoin exists to eliminate. > AssumeUTXO helps eliminate that, because at least you are not trusting one > person but a group of contributors committing to a hash Who is the "group of contributors" that we are assuming has become the central authority on what is valid? I do not see this listed in the BIP. Is there to be a public key provided somehow so that we can all be assured that we are trusting the right authority? If only someone could devise a solution to this problem. > with headers-first sync and other safeguards assumeUTXO provides. There are no such other "safeguards". Headers first is DoS protection. This is not an SPV implementation. > AssumeUTXO is, in my opinion, a lesser evil than, for example, assumeDatadir. This is a false dichotomy. Using an SPV wallet while syncing your node is a far more secure and more efficient existing alternative. And it has the actual security that people seem to be assuming this has (see your headers comment above). There is no reason to choose any evil, and certainly no reason to impose it on the P2P network. 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/c92abfec-e3af-42bc-b371-36e209f1727en%40googlegroups.com. ------=_Part_1092811_173508816.1779053397727 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > From: sadiq Ismail

Hi sadiq,

> I am from a pl= ace with metered and slow bandwidth, so assuming U.S.
> internet ba= ndwidth and speed specifications for IBD is incorrect and ignores
>= that not everyone shares the same reality.

No such assumption h= as been made. My post specifically addressed the performance *trend*, which= contrary to common assumptions, is improving (everywhere) and will eventua= lly render this question moot.

> I will share mine.

No number of performance anecdotes can address the outstanding critiques,= but I'm happy to cover the other issues.

> I can use wallets= to receive Bitcoin as an SPV

Okay, which is far better than a t= rusting wallet.

> but once you want to sync the and have a no= de synced to the tip,
> I face a significant bottleneck.

Why are you syncing the node? Presumably you want a fully validated node -= for better than SPV security. You cannot get that from assuming it. You sh= ould sync and validate a node and then just connect your SPV wallet to it. = This transitions you to actual full node security from SPV security, once t= hat full node security actually exists.

> I think if a less-t= rusted setup were provided, like assumeutxo

Assuming is not "les= s trusted", it's fully trusted. I think you meant "less trustworthy".
=
> with p2p sharing, Since my use case is data analysis, not receiv= ing payments,
> I would not face this bottleneck and would definite= ly use it.

It's not clear why you would want a less trustworthy = (fully trusted) wallet when you can use a far more trustworthy SPV wallet. = And you can transition that same wallet to zero trust once your node is val= idated, by just pointing your SPV wallet to the node. Furthermore you are n= ot providing any justification for moving this into P2P, the trusted node f= eature you want already exists.

> As a real example of the po= int Fabian made about using worse alternatives: I
> also travelled = hundreds of kilometres to a different city to assumeDatadir by
> co= pying the datadir from a trusted friend.

Incorporating Core's tr= usted utxo system into the P2P network does not change this at all. You cou= ld have just downloaded it from your friend, or anyone else you trust to pr= ovided it. Certainly that's better than downloading it from randos on the P= 2P network. And you would have the same download cost either way.

> The risk of the chain growing so large that syncing takes a long tim= e is real

The opposite is happening. This is why I pointed out t= he declining cost trend. That applies everywhere, not just in the US. And i= n any case, trust would not be a solution. That's the problem Bitcoin exist= s to eliminate.

> AssumeUTXO helps eliminate that, because at= least you are not trusting one
> person but a group of contributor= s committing to a hash

Who is the "group of contributors" that w= e are assuming has become the central authority on what is valid? I do not = see this listed in the BIP. Is there to be a public key provided somehow so= that we can all be assured that we are trusting the right authority? If on= ly someone could devise a solution to this problem.

> with he= aders-first sync and other safeguards assumeUTXO provides.

There= are no such other "safeguards". Headers first is DoS protection. This is n= ot an SPV implementation.

> AssumeUTXO is, in my opinion, a l= esser evil than, for example, assumeDatadir.

This is a false dic= hotomy. Using an SPV wallet while syncing your node is a far more secure an= d more efficient existing alternative. And it has the actual security that = people seem to be assuming this has (see your headers comment above). There= is no reason to choose any evil, and certainly no reason to impose it on t= he P2P network.

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/c92abfec-e3af-42bc-b371-36e209f1727en%40googlegroups.com.
------=_Part_1092811_173508816.1779053397727-- ------=_Part_1092810_722720878.1779053397727--