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