[Lightning-dev] Ionization Protocol: Flood Routing

[Rusty Russell]

Hi Amos,

   I'm delighted that someone else is thinking about routing!

I like the information hiding features, but I don't think this will
scale if everyone floods the network before sending a transaction.

I do, however, have an alternate scheme which is something of a
middleman, which I'd appreciate your feedback on.

We regularly choose a dozen "beacon" nodes at random (using proximity to
the SHA of latest block hash or something).  Everyone propagates the
cheapest route to & from those nodes (which is pretty efficient, similar
to your scheme).

To receive a payment, B picks a few beacon nodes at random and sends
those routes (beacons -> B) to A.  Presumably A knows its route to all
the beacon nodes and thus can choose the best.

There are some twisty details here:

1) How many beacon nodes?
   12, and increase on a log scale with network size.  That size can
   be derived from previous beacons.

2) How long between selection and a beacon becoming active?
   10 blocks.  That gives time for others to connect to beacon node.

3) How long before a beacon node is invalid?
   No idea.  Let's keep a day's worth for the moment?

4) How to avoid fake beacons?
   Require a signature attached to an unspent bitcoin TX from before
   beacon selection?  That TXID is actually what competes to be close
   to the beacon selector.

5) How to update beacon routing?
   Particularly for fee changes, this is important.  Best effort,
   with ratelimiting.  I hope eventually we'll have reasonable traffic
   models so a node can say "I'm going to ramp up/down my fees for
   this long at this rate" and have a reasonable chance that it's true.

Cheers,
Rusty.
PS.  For the immediate term, we'll use a global comms mechanism like
     IRC, but that's just a prototype hack.

Amos Bairn <eylrid at gmail.com> writes:
> Here is a scheme I thought of for flood based route finding. If it can be
> pulled off it would allow efficient route finding while keeping the shape
> of the network hidden, as well as giving onion like anonymity.
>
> After writing it up a realized that it has a trivial denial of service
> attack, that could render it a non-starter.
>
> I'm throwing it out there anyway, because this could have significant
> potential if the DoS problem can be solved.
>
> https://github.com/Eylrid/ionization/blob/master/ionization.mediawiki
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev