Re: [Ledger] Forming a Routing Working Group

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.

On Fri, Jul 7, 2017 at 10:40 AM, Geoffrey Goodell <goodell@oxonia.net>
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
>
> On Sat, Jul 01, 2017 at 11:51:54AM -0700, Jehan Tremback wrote:
> > 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 <evan@ripple.com> 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 <tony@chain.com> wrote:
> > >
> > >> On Thu, Jun 22, 2017 at 4:22 PM, Ryan Fugger <arv@ryanfugger.com>
> 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
> > >
>
> > _______________________________________________
> > Ledger mailing list
> > Ledger@ietf.org
> > https://www.ietf.org/mailman/listinfo/ledger
>
>