Mark Friedenbach [ARCHIVE] on Nostr: š Original date posted:2015-12-16 š Original message: It should be noted that ...
š
Original date posted:2015-12-16
š Original message:
It should be noted that this estimation is biasing towards
worst-case-latency/best-case-decentralization. Even though we will make
conscious efforts to keep lightning networks as decentralized as possible,
it is still the case that we will see some centralization pressure due to
the desire for low latency transactions. I expect that the average user's
experience of a 10-hop payment would be on the order of 1-2 seconds, with
the inner-hops being between Tier-1 datacenter nodes primarily with payment
channels chosen based on network proximity. A 'near' payment to someone
closer to them would be under a second. But it is very good to know that a
network consisting entirely of last-mile endpoints geographically
distributed around the world would only have a worst-case transaction time
of only about 10s or so. Even that is doable for PoS.
On Wed, Dec 16, 2015 at 8:04 AM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Denis Gorbachev <denis.d.gorbachev at gmail.com> writes:
> > Assuming a simple case of "Consumer - Relay - Provider" (2 hops), how
> long
> > should it take for provider to receive the payment?
>
> Assuming established channels already (assuming CPU is instant, so we're
> just paying for network latency):
>
> Consumer offers Relay a contract:
> C -> R: update_add_htlc
> R -> C: update_accept
> C -> R: update_signature
> R -> C: update_complete*
>
> Relay offers Provider a contract:
> R -> P: update_add_htlc
> P -> R: update_accept
> R -> P: update_signature
> P -> R: update_complete*
>
> Provider closes contract with relay:
> P -> R: update_fulfill_htlc
> R -> P: update_accept
> P -> R: update_signature
> R -> P: update_complete*
>
> Relay closes contract with Client:
> R -> C: update_fulfill_htlc
> C -> R: update_accept
> R -> C: update_signature
> C -> R: update_complete*
>
> You don't need to wait for the update_complete packets to arrive, so
> that works out to 3 RTTs per hop. You might expect up to 10 hops in a
> large lightning network, so 30 RTTs.
>
> I'm in Australia, and my bitcoin node latency averages 330ms (ouch!).
> So that would be 10 seconds.
>
> Hope that helps!
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151216/e4decfa4/attachment.html>
š Original message:
It should be noted that this estimation is biasing towards
worst-case-latency/best-case-decentralization. Even though we will make
conscious efforts to keep lightning networks as decentralized as possible,
it is still the case that we will see some centralization pressure due to
the desire for low latency transactions. I expect that the average user's
experience of a 10-hop payment would be on the order of 1-2 seconds, with
the inner-hops being between Tier-1 datacenter nodes primarily with payment
channels chosen based on network proximity. A 'near' payment to someone
closer to them would be under a second. But it is very good to know that a
network consisting entirely of last-mile endpoints geographically
distributed around the world would only have a worst-case transaction time
of only about 10s or so. Even that is doable for PoS.
On Wed, Dec 16, 2015 at 8:04 AM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Denis Gorbachev <denis.d.gorbachev at gmail.com> writes:
> > Assuming a simple case of "Consumer - Relay - Provider" (2 hops), how
> long
> > should it take for provider to receive the payment?
>
> Assuming established channels already (assuming CPU is instant, so we're
> just paying for network latency):
>
> Consumer offers Relay a contract:
> C -> R: update_add_htlc
> R -> C: update_accept
> C -> R: update_signature
> R -> C: update_complete*
>
> Relay offers Provider a contract:
> R -> P: update_add_htlc
> P -> R: update_accept
> R -> P: update_signature
> P -> R: update_complete*
>
> Provider closes contract with relay:
> P -> R: update_fulfill_htlc
> R -> P: update_accept
> P -> R: update_signature
> R -> P: update_complete*
>
> Relay closes contract with Client:
> R -> C: update_fulfill_htlc
> C -> R: update_accept
> R -> C: update_signature
> C -> R: update_complete*
>
> You don't need to wait for the update_complete packets to arrive, so
> that works out to 3 RTTs per hop. You might expect up to 10 hops in a
> large lightning network, so 30 RTTs.
>
> I'm in Australia, and my bitcoin node latency averages 330ms (ouch!).
> So that would be 10 seconds.
>
> Hope that helps!
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151216/e4decfa4/attachment.html>