[Lightning-dev] Ionization Protocol: Flood Routing

Amos Bairn eylrid at gmail.com
Wed Sep 23 04:28:06 UTC 2015

The obvious problem with having the whole network use the same set of
beacons at the same time is that those nodes will get slammed. A possible
solution is to have each user pick their own set of beacons (at random),
but make the beacon set large enough so that any two users are likely to
share a few. That way the all of nodes would share the load roughly evenly.

The size needed should be something on the order of the square root of the
number of nodes. Some math could be done to see what set size would be
needed to have a given probability of two users having an intersection of
at least a given size.

If you went with that you wouldn't have to worry about the extra mess of
making sure everyone has consensus on the official beacon set.

On Sun, Sep 20, 2015 at 7:16 PM, Rusty Russell <rusty at rustcorp.com.au>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150922/b759a3fd/attachment-0001.html>

More information about the Lightning-dev mailing list