Re: [bitcoin-dev] On mempool policy consistency

From: email@yancy•lol
To: Anthony Towns <aj@erisian•com.au>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Sun, 30 Oct 2022 12:06:32 +0100	[thread overview]
Message-ID: <41aec8aec49c5ca8e21f0641f5bb65fc@yancy.lol> (raw)
In-Reply-To: <Y13NM4dyuD6ktvlf@erisian.com.au>

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 5213 bytes --]