email at yancy.lol [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-30 📝 Original message:> Whether that's terrible ...
📅 Original date posted:2022-10-30
📝 Original message:> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221030/bdc55eb9/attachment-0001.html>;
📝 Original message:> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221030/bdc55eb9/attachment-0001.html>;