From rusty at rustcorp.com.au Sun Sep 27 05:42:56 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Sun, 27 Sep 2015 15:12:56 +0930 Subject: [Lightning-dev] Ionization Protocol: Flood Routing In-Reply-To: <20150925055406.GB11549@navy> References: <874mioecuq.fsf@rustcorp.com.au> <87y4fvqn6h.fsf@rustcorp.com.au> <20150925055406.GB11549@navy> Message-ID: <87612wquxr.fsf@rustcorp.com.au> Anthony Towns 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.