Subject: Re: [Ledger] Forming a Routing Working Group

From: Jehan Tremback <[email-masked]>
Date: Sat, 1 Jul 2017 11:51:54 -0700

I missed the call as well. I once designed a reactive payment routing
protocol based on AODV. It floods the network, and reveals the existence,
but not the source or destination of payments. It does not require any
central or on-chain registries of open channels, so it can be used across
different underlying payment techniques. Some of you have seen it already,
should I post it here again? I'd also be interested in learning of new
developments in the space.

-Jehan

On Fri, Jun 30, 2017 at 12:13 PM, Evan Schwartz <[email-masked]> wrote:

> Sounds good. I would propose that this type of group should start and work
> on a shared set of docs that describes options, ongoing research, etc so
> that others can participate and follow along.
>
> On Fri, Jun 30, 2017 at 9:10 PM Tony Arcieri <[email-masked]> wrote:
>
>> On Thu, Jun 22, 2017 at 4:22 PM, Ryan Fugger <[email-masked]> wrote:
>>
>>> This is a great idea Evan.  I am very interested in routing.  I don't
>>> manage calls well, but I would appreciate being able to observe and
>>> hopefully participate a bit over email.  Please let us know if/when any new
>>> mailing list gets set up for this.  Thanks!
>>>
>>
>> I'm in a similar boat to Ryan: a big fan of things like BGP and layer 3
>> routing as well as proprietary payment network routing, but would prefer to
>> participate in something like this a bit more asynchronously as opposed to
>> a call.
>>
> --
>
> Evan Schwartz
> Software Engineer
> Managing Director of Ripple Luxembourg
>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 10 Jul 2017 11:59:58 +0000

Hi,

Please share if there is any usecase/requirement document. I am interested in learning more on this space.

Thanks,
Nagendra

On 7/7/17, 1:40 PM, "Geoffrey Goodell" <[email-masked]> wrote:

    Curious why you are not just doing onion routing if you need anonymity or DHT
    if you don't.  In particular I would surmise that a protocol that floods the
    network will not scale.  Is there reason to assume an underlying structure in
    the network such that some nodes cannot reach each other directly, and if so,
    then why?  Have the requirements been documented?
    
    Geoff

    > _______________________________________________
    > Ledger mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/ledger

---

From: Geoffrey Goodell <[email-masked]>
Date: Fri, 7 Jul 2017 13:40:55 -0400

Geoff

---

From: Jehan Tremback <[email-masked]>
Date: Fri, 7 Jul 2017 13:00:52 -0700

AFAIK onion routing is just source routing with encryption. Nodes put
together a path maybe using Djikstra's or another path finding algorithm,
but they must have the information to do this. Some projects like Raiden
get the list of open channels from the blockchain. I think Lightning is
doing this too. The problem with this is that the fact that a channel
exists does not mean that it has enough of a balance in the direction you
need. Also, information about different fees charged is likely to be out of
date. The more up to date you want this information to be, the more routing
messages every node will have to propagate.

If you instead flood route request messages, this is a lot of traffic, but
routes will always be informed by the most up to date information. Let's
say each route request message takes 64 bytes. I read online that Visa
handles an average of 2,000 transactions per second. 2000 * 64 * 8 =
1,024,000. Each full node needs to receive and route about 1Mbit/s of route
request messages. They will also have to recognize and drop route request
messages they have seen before, so the total amount will be somewhat higher
and will be affected by how densely connected the network is. I'm biased
towards flooding though, here's my design:
https://github.com/jtremback/reactive-payment-routing.

DHT routing is a very interesting concept, but most implementations are not
able to find optimal routes. CJDNS, the only active DHT routing (not DHT
storage) project I am aware of just switched to
<https://cryptpad.fr/pad/#/1/view/XnDofWIIasrwcpgQUcFWKg/Vh1pZR0tVZgUT2I9Lec4coqTdn0mwRuA+lWH5klSSfw/>
centralized routing because DHT wasn't working.

---

From: Daniel Bateman <[email-masked]>
Date: Fri, 7 Jul 2017 13:07:22 -0700

This approach sounds perfect to me Evan.

Does this sound good to everyone else?

Any other suggestions re efficient/effective collaboration tools?

Evan, will you be sending links to the shared docs etc.?

Daniel

On Jun 30, 2017 12:14 PM, "Evan Schwartz" <[email-masked]> wrote:

-- 

Evan Schwartz
Software Engineer