Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-27 📝 Original message: Anthony Towns <aj at ...

📅 Original date posted:2015-09-27
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> 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.

That's a great insight! Fees *do* erode channels. I had totally missed
that.

> 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.

It is. You definitely want to increase the number of beacons with
network size.

>> 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)

But you'd risk not being used as a beacon if your fees are too high. It
seems to me that a beacon wants many connections, to avoid the
"short-circuit" case. At 100 connections, it's only 1%, though
that's the best case which assumes they're all equally likely.

>> 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).

Good points. If we reject all routes less than (say) 3 hops by default
it might mean that local payments are *less* efficient. Oops.

I'll think harder on this...

Cheers,
Rusty.