Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 74034C002D for ; Sun, 30 Oct 2022 11:06:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4842B403A7 for ; Sun, 30 Oct 2022 11:06:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4842B403A7 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip5prqQtINO9 for ; Sun, 30 Oct 2022 11:06:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 52DC14035A Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by smtp4.osuosl.org (Postfix) with ESMTPS id 52DC14035A for ; Sun, 30 Oct 2022 11:06:38 +0000 (UTC) Received: (Authenticated sender: email@yancy.lol) by mail.gandi.net (Postfix) with ESMTPA id 6966B1BF206; Sun, 30 Oct 2022 11:06:34 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 30 Oct 2022 12:06:32 +0100 From: email@yancy.lol To: Anthony Towns , Bitcoin Protocol Discussion In-Reply-To: References: <194063b733e539e8e24cfd83fa879ed0@dtrt.org> Message-ID: <41aec8aec49c5ca8e21f0641f5bb65fc@yancy.lol> X-Sender: email@yancy.lol Content-Type: multipart/alternative; boundary="=_1eaf4296ec9b9f875f040b16e38db12f" X-Mailman-Approved-At: Sun, 30 Oct 2022 11:23:39 +0000 Subject: Re: [bitcoin-dev] On mempool policy consistency X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2022 11:06:40 -0000 --=_1eaf4296ec9b9f875f040b16e38db12f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed > Whether that's terrible or not depends on how easy it is to retry (and > how > likely the retry is to succeed) after a failure -- if a TCP packet > fails, > it just gets automatically resent, and if that succeeds, there's a > little > lag, but your connection is still usable I'm not sure if that analogy fits here. A TCP packet will be retried (as opposed to UDP), although usually the retry strategy is because of an underlying connection issue, not a protocol mismatch or in this case "policy" mismatch, right? If network propagation and node discovery becomes an issue, and as Antoine mentions, there becomes a need for competing services as I understand it, could that give rise to indexes and trackers who spider the network to create world view? Perhaps it's a bad idea since "third party" trackers are security holes, however, to my knowledge, we already have "trusted" nodes during the initial bootstrap process. Even so, I don't think we could preclude such solutions from occurring organically if the need is arises. Cheers, -Yancy On 2022-10-30 02:02, Anthony Towns via bitcoin-dev wrote: > On Fri, Oct 28, 2022 at 09:45:09PM -1000, David A. Harding via > bitcoin-dev wrote: > >> I think this might be understating the problem. A 95% chance of >> having >> an outbound peer accept your tx conversely implies 1 in 20 payments >> will >> fail to propagate on their initial broadcast. > > Whether that's terrible or not depends on how easy it is to retry (and > how > likely the retry is to succeed) after a failure -- if a TCP packet > fails, > it just gets automatically resent, and if that succeeds, there's a > little > lag, but your connection is still usable. I think it's *conceivable* > that > a 5% failure rate could be detectable and automatically rectified. Not > that I have a good idea how you'd actually do that, in a way that's > efficient/private/decentralised... > >> Some napkin math: there are about 250,000 transactions a day; if >> we round that up to 100 million a year and assume we only want one >> transaction per year to fail to initially propagate on a network where >> 30% of nodes have adopted a more permissive policy, lightweight >> clients >> will need to connect to over 50 randomly selected nodes.[1] > > A target failure probability of 1-in-1e8 means: > > * with 8 connections, you need 90% of the network to support your txs > * with 12 connections, you need ~79% > * with 24 connections (eg everyone running a long-lived node is > listening, so long lived nodes make 12 outbound and receive about > ~12 inbound; shortlived nodes just do 24 outbound), you need ~54% > > So with that success target, and no preferential peering, you need > a majority of listening nodes to support your tx's features in most > reasonable scenarios, I think. > >> For a more >> permissive policy only adopted by 10% of nodes, the lightweight client >> needs to connect to almost 150 nodes. > > I get 175 connections needed for that scenario; or 153 with a target > failure rate of 1-in-10-million. > > Cheers, > aj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --=_1eaf4296ec9b9f875f040b16e38db12f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
= Whether that's terrible or not depends on how easy it is to retry (and how<= br />likely the retry is to succeed) after a failure -- if a TCP packet fai= ls,
it just gets automatically resent, and if that succeeds, there's a= little
lag, but your connection is still usable
=  
= I'm not sure if that analogy fits here.  A TCP packet will be retried = (as opposed to UDP), although usually the retry strategy is because of an u= nderlying connection issue, not a protocol mismatch or in this case "policy= " mismatch, right?
=  
= If network propagation and node discovery becomes an issue, and as Antoine mentions, there becomes a n= eed for competing services as I understand it, could that give rise to inde= xes and trackers who spider the network to create world view?  Perhaps= it's a bad idea since "third party" trackers are security holes, however, = to my knowledge, we already have "trusted" nodes during the initial bootstr= ap process.  Even so, I don't think we could preclude such solutions f= rom occurring organically if the need is arises.
=  
= Cheers,
= -Yancy
=  
= On 2022-10-30 02:02, Anthony Towns via bitcoin-dev wrote:
On Fri, Oct 28, 2022 at 09:45:09PM -1000, David A. Har= ding via
bitcoin-dev wrote:
I think this might be understating the problem.  = A 95% chance of having
an outbound peer accept your tx conversely impl= ies 1 in 20 payments will
fail to propagate on their initial broadcast= =2E

Whether that's terrible or not depends on how easy it is to retry (an= d how
likely the retry is to succeed) after a failure -- if a TCP pack= et fails,
it just gets automatically resent, and if that succeeds, the= re's a little
lag, but your connection is still usable. I think it's *= conceivable* that
a 5% failure rate could be detectable and automatica= lly rectified. Not
that I have a good idea how you'd actually do that,= in a way that's
efficient/private/decentralised...

Some napkin math: there are about 250,000 transactions= a day; if
we round that up to 100 million a year and assume we only w= ant one
transaction per year to fail to initially propagate on a netwo= rk where
30% of nodes have adopted a more permissive policy, lightweig= ht clients
will need to connect to over 50 randomly selected nodes.[1]=

A target failure probability of 1-in-1e8 means:

 * wi= th 8 connections, you need 90% of the network to support your txs
&nbs= p;* with 12 connections, you need ~79%
 * with 24 connections (eg= everyone running a long-lived node is
   listening, so= long lived nodes make 12 outbound and receive about
   = ;~12 inbound; shortlived nodes just do 24 outbound), you need ~54%
So with that success target, and no preferential peering, you need
= a majority of listening nodes to support your tx's features in most
re= asonable scenarios, I think.

For a more
permissive policy only adopted by 10% = of nodes, the lightweight client
needs to connect to almost 150 nodes.=

I get 175 connections needed for that scenario; or 153 with a target<= br />failure rate of 1-in-10-million.

Cheers,
aj
_____= __________________________________________
bitcoin-dev mailing listbitcoin-dev@lis= ts.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=_1eaf4296ec9b9f875f040b16e38db12f--