Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-25 📝 Original message: On Fri, Sep 25, 2015 at ...
📅 Original date posted:2015-09-25
📝 Original message:
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).
Cheers,
aj
Published at
2023-06-09 12:44:33Event JSON
{
"id": "7a93abb92a09a314e8f56c3ec61ed8c0a0e2923cccaa18be40cfbf5eca8ac344",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314673,
"kind": 1,
"tags": [
[
"e",
"d508e26ae44d949f7c534399c4b1e4f82df043bc5ea4ea4a1d4d81571bfaec45",
"",
"root"
],
[
"e",
"3cc97b56910d1e65a19e11b991236a6682727b13e9f80b5eb972287c7fcb98b4",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-25\n📝 Original message:\nOn Fri, Sep 25, 2015 at 11:23:42AM +0930, Rusty Russell wrote:\n\u003e Beacons are going to get slammed, but it's not clear how bad it is.\n\u003e Getting slammed from all directions doesn't use up channels; it's only\n\u003e computational and bandwidth limits.\n\nIt does actually use up channels -- if you've got 5 channels with 100 BTC\nin them collectively in total, and you own 20 BTC of that, and collect\na 0.1% fee on each transaction, you'll gain 80 BTC after 80,000 BTC are\nforwarded through you, and nobody will be able to send you funds any more.\n\nAs a beacon, you'll probably be tempted to raise your fees (you're only\ncompeting against the 11 other current beacons which you can monitor\nfairly closely), so 1% or even 2% might be realistic figures, reducing\nthe number of transactions by a factor of 10 or 20.\n\nOther nodes can fix that by opening up new channels to you, though.\n\nAs far as b/w goes, the number of beacons and they're bandwidth puts a\nlimit on the transactions per second of the lightning network: if each\nof 12 beacons have 100Mb/s bandwidth available, and use 2048B to forward\nan HTLC, then the number of HTLCs a beacon can forward per second is:\n\n 100e6/8 / 2048 = ~6100\n\nmultiplying by 12 beacons to give a maximum of around ~73k lightning\ntransactions per second; which is about the same as the VisaNet stress\ntests (56k tps), which seems too low to me if you want micropayments.\n\n\u003e Their neighbors will want to buff up, too (they'll take some load off\n\u003e the beacon if both parties route through them).\n\n(In the event that someone suggests a route beacon_X -\u003e X -\u003e Y -\u003e Z to\nget to them, and you have a path A -\u003e C -\u003e X -\u003e beacon_X, you can cut out\nthe middleman and not route through a beacon at all. I don't think this\ngives much of an improvement though. A beacon could potentially avoid\nthis from being possible by partitioning its neighbours into two sets\nand setting incoming fees for one set prohibitively high, and outgoing\nfees to the other set as prohibitively high; managing that dynamically\nwould be difficult but I think possible)\n\n\u003e A semi-realistic simulation would be interesting. If payments cluster\n\u003e by geography and some random channels are established by proximity\n\u003e (ie. low latency) that may take some of load off the beacons too.\n\nI think routing by proximity cuts out some of the benefits of onion\nrouting; you just end up with locals conncting to their local banks,\nand paying locals directly via their bank, and the bank being able to\ndirectly correlate payments (or two banks being able to collaborate to\ncorrelate sender and recipient).\n\nCheers,\naj",
"sig": "05abcb75bca846c74d90d7eb08719fb870f9b0b146a05db92a7c867a2c594d7977f0d6f03d20e1f4d7e7335903f88b5e0f2757c7eca4049eb8fe4f6de510a2f7"
}