[Lightning-dev] Ionization Protocol: Flood Routing

Anthony Towns aj at erisian.com.au
Fri Sep 25 05:54:06 UTC 2015

On Fri, Sep 25, 2015 at 11:23:42AM +0930, Rusty Russell wrote:
> Beacons are going to get slammed, but it's not clear how bad it is.
> Getting slammed from all directions doesn't use up channels; it's only
> computational and bandwidth limits.

It does actually use up channels -- if you've got 5 channels with 100 BTC
in them collectively in total, and you own 20 BTC of that, and collect
a 0.1% fee on each transaction, you'll gain 80 BTC after 80,000 BTC are
forwarded through you, and nobody will be able to send you funds any more.

As a beacon, you'll probably be tempted to raise your fees (you're only
competing against the 11 other current beacons which you can monitor
fairly closely), so 1% or even 2% might be realistic figures, reducing
the number of transactions by a factor of 10 or 20.

Other nodes can fix that by opening up new channels to you, though.

As far as b/w goes, the number of beacons and they're bandwidth puts a
limit on the transactions per second of the lightning network: if each
of 12 beacons have 100Mb/s bandwidth available, and use 2048B to forward
an HTLC, then the number of HTLCs a beacon can forward per second is:

  100e6/8 / 2048 = ~6100

multiplying by 12 beacons to give a maximum of around ~73k lightning
transactions per second; which is about the same as the VisaNet stress
tests (56k tps), which seems too low to me if you want micropayments.

> Their neighbors will want to buff up, too (they'll take some load off
> the beacon if both parties route through them).

(In the event that someone suggests a route beacon_X -> X -> Y -> Z to
get to them, and you have a path A -> C -> X -> beacon_X, you can cut out
the middleman and not route through a beacon at all. I don't think this
gives much of an improvement though. A beacon could potentially avoid
this from being possible by partitioning its neighbours into two sets
and setting incoming fees for one set prohibitively high, and outgoing
fees to the other set as prohibitively high; managing that dynamically
would be difficult but I think possible)

> A semi-realistic simulation would be interesting.  If payments cluster
> by geography and some random channels are established by proximity
> (ie. low latency) that may take some of load off the beacons too.

I think routing by proximity cuts out some of the benefits of onion
routing; you just end up with locals conncting to their local banks,
and paying locals directly via their bank, and the bank being able to
directly correlate payments (or two banks being able to collaborate to
correlate sender and recipient).


More information about the Lightning-dev mailing list