Bitcoin Low Latency Incentive

[kiba]

A conversation between me and Ethereael about the idea of incentivizing users for providing good latency:

Ok so here's my idea, see if you can sanity check it for me,
      basically think peer to peer service for lowering latency between
      two given endpoints, the problem with this though is it's harder to
      guarantee low latency than it is to guarantee high bandwidth, cause
      even if you're pushing over choked pipes if there's 10,000 people
      doing it the sheer volume is enough to contribute positively to the
      speed of the download, which is why bittorrent

 So think that, except instead of sucking down pieces of a
      file from disparate sources, you're trading endpoint contacts with
      disparate sources.

 You then take your contact latency to the endpoint in
      question + the latency they have to your target endpoint to get
      your theoretical latency to your endpoint, and you pick the lowest
      latency.

 Latency guarantees are harder to make than bandwidth
      guarantees, people will likely want incentive to participate, the
      more incentive, the more participants, the more value the entire
      network has.

 Right, so if you could earn say bitcoins by providing routes
      on the peer to peer network, and spend bitcoins to buy routes on
      the peer to peer network... would that make sense?

[1714000412]

1714000412

[1714000412]

1714000412

[MoonShadow]

I don't get it.  Latency is certainly an issue, but isn't it a bit of a physical hardware issue?  How could a p2p network of any kind improve latency?  Are my ping times going to improve to my favorite game server?

[Etherael]

I don't get it.  Latency is certainly an issue, but isn't it a bit of a physical hardware issue?  How could a p2p network of any kind improve latency?  Are my ping times going to improve to my favorite game server?

Hi there, this is the originally quoted person.

If you're familiar with gaming you might be familiar with this idea in practice already for certain game server endpoints such as world of warcraft, I believe they have a service called fasterping there and a few competitors, but generally the idea is based around a circumvention of the inefficient midpoints in a route between two endpoints via proxying to a host with a more efficient route to the endpoint in question.

As an example; you're in Sydney and you want to contact a server in Melbourne but your ISP has no routes for that particular ISP and it gets caught by its default routes and passed out to the San Francisco endpoint adding a large whack of latency to the run, you circumvent this by using this peer to peer network to find a low latency endpoint like so;

You: (broadcast) I need to contact server @ melbourne, I have latency of 900ms to this endpoint, anyone have better?
Response point A: I have this destination in 80ms (your ping to me is 80ms)
Response point B: I have this destination in 400ms (your ping to me is 100ms)
Response point C: I have this destination in 320ms (your ping to me is 50ms)

The software automatically proxies packets bound for endpoint in melbourne via response point A cutting your latency from 900ms to 160ms.

The trick is I don't expect people would do this out of the goodness of their hearts, leaving a passive unloaded link open for public traffic proxying requires incentives for the owners of said links. If for example by routing packets through point A you paid X bitcoins to the proxy, and in turn they were able to use these bitcoins to pay for their own routing in future, this would add incentive to be good nodes in the network, thus increasing the value of said network.

[MoonShadow]

If a faster path is available, what would prevent one from using a bang-path?  Are you just recommending an incentive for providers to provide for said low-latency paths?

[Etherael]

If a faster path is available, what would prevent one from using a bang-path?  Are you just recommending an incentive for providers to provide for said low-latency paths?

I'm not sure what you mean by bang path, I haven't heard that since UUCP days, how does it relate to ad hoc routing? What prevents people from using a faster available path is a few different issues;

A) They do not know such a path is available
B) Even if they did know such a path was available, they would be unable to setup an ad hoc route using said path
C) Even then if they knew such a path was available and had the capacity to use such a path, incentives for the potential providers of said paths would make them more numerous and thus contribute to reducing cases of A & B all things being equal

[MoonShadow]

If a faster path is available, what would prevent one from using a bang-path?  Are you just recommending an incentive for providers to provide for said low-latency paths?

I'm not sure what you mean by bang path, I haven't heard that since UUCP days, how does it relate to ad hoc routing?

I mean like isp.com!near.router.backbone.org!far.router.backbone.org!otherisp.org

It's not automatic by any means, but it is certainly ad hoc routing.  At least by any definition that I've ever heard.

[MoonShadow]

This makes me wonder if bang-paths are still a supported routing method, since I haven't done it myself in over a decade, but Wikipedia implies that it is still so...

"Current use and legacy

<snip>

"Bang path" is also used as an expression for any explicitly specified routing path between network hosts. That usage is not necessarly limited to uucp, IP routing, email messaging, or Usenet."


http://en.wikipedia.org/wiki/UUCP#Current_use_and_legacy

[Etherael]

This makes me wonder if bang-paths are still a supported routing method, since I haven't done it myself in over a decade, but Wikipedia implies that it is still so...

"Current use and legacy

<snip>

"Bang path" is also used as an expression for any explicitly specified routing path between network hosts. That usage is not necessarly limited to uucp, IP routing, email messaging, or Usenet."


http://en.wikipedia.org/wiki/UUCP#Current_use_and_legacy

I have not seen this actually used for IP networks ever, the only time I've seen it used is back in the UUCP days for routing mail along a specific path.

Does anyone know if this is actually used anymore, or indeed can actually be used anymore? I suspect it is entirely defunct.

[theymos]

I have not seen this actually used for IP networks ever, the only time I've seen it used is back in the UUCP days for routing mail along a specific path.

Does anyone know if this is actually used anymore, or indeed can actually be used anymore? I suspect it is entirely defunct.

Loose and strict source routing are part of the IP specification. The IP header only has room for nine source routing addresses, though, which limits its usefulness. My man page for traceroute says (-g does loose source routing - no option for strict in my version):

-g gateway
Tells traceroute to add an IP source routing option to the out-going packet that tells the network to route the packet through the specified gateway. Not very useful, because most routers have disabled source routing for security reasons.

IPv6 used to have a similar feature, but it was removed.

[Etherael]

I have not seen this actually used for IP networks ever, the only time I've seen it used is back in the UUCP days for routing mail along a specific path.

Does anyone know if this is actually used anymore, or indeed can actually be used anymore? I suspect it is entirely defunct.

Loose and strict source routing are part of the IP specification. The IP header only has room for nine source routing addresses, though, which limits its usefulness. My man page for traceroute says (-g does loose source routing - no option for strict in my version):

-g gateway
Tells traceroute to add an IP source routing option to the out-going packet that tells the network to route the packet through the specified gateway. Not very useful, because most routers have disabled source routing for security reasons.

IPv6 used to have a similar feature, but it was removed.

I have heard of source routing and usually in the context of it being disabled in a given stack for security reasons, this is less a routing thing though and more a latency reduction thing, for services for which low latency would be an enabler, think voip or video conferencing or any kind of real time service. Think of it like Guerilla QoS.

Assuming it does work as intended, is there any catch to using bitcoin as an incentive / payment method for proxying traffic on the network? The reason I originally asked Kiba this is that I had seen him talking about bc but I don't fully understand the inner workings of it myself.

[sandos]

I strongly suspect that physically routing through bitcoin (am I misunderstanding here?) would negate any potential benefits with better routing paths.

Really, is routing ever really a problem or am I just spoiled? I would love to see a real-world example where an inefficient route adds a significant delay to your packets.

[Etherael]

I strongly suspect that physically routing through bitcoin (am I misunderstanding here?) would negate any potential benefits with better routing paths.

Really, is routing ever really a problem or am I just spoiled? I would love to see a real-world example where an inefficient route adds a significant delay to your packets.

http://pingfaster.com/

This is a single real world example of course, where in this application the idea is to do it on an ad hoc basis to any given destination as required, but the concept is well known and already used in practice.

The plan has nothing to do with routing through bitcoin, I was only thinking of using bitcoins as tokens for routing traffic on the network itself, for example if you provide a link for n time with latency below x for endpoint y they pay you in bitcoins for the usage of that link, and in turn when you want to get access to another endpoint you can use those earned bitcoins to pay for the link to do so.

Make sense?

[Anonymous]

I strongly suspect that physically routing through bitcoin (am I misunderstanding here?) would negate any potential benefits with better routing paths.

Really, is routing ever really a problem or am I just spoiled? I would love to see a real-world example where an inefficient route adds a significant delay to your packets.

http://pingfaster.com/

This is a single real world example of course, where in this application the idea is to do it on an ad hoc basis to any given destination as required, but the concept is well known and already used in practice.

The plan has nothing to do with routing through bitcoin, I was only thinking of using bitcoins as tokens for routing traffic on the network itself, for example if you provide a link for n time with latency below x for endpoint y they pay you in bitcoins for the usage of that link, and in turn when you want to get access to another endpoint you can use those earned bitcoins to pay for the link to do so.

Make sense?

Makes sense to me.  It would also be nice if people could earn btc for providing faster seeding on bittorrent.