📅 Original date posted:2015-09-23
📝 Original message:
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>
wrote:
> 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>;
Amos Bairn [ARCHIVE] /
npub10v…zekuc
2023-06-09 12:44:32
in reply to nevent1q…kjjg
Author Public Key
npub10vrdmn5auyl8yyunkrxaltacj08n9pmnm4n0da6t59xdpnccxayshzekucPublished at
2023-06-09 12:44:32Event JSON
{
"id": "ad2fee09745921adee1ba4c1fbcdb324ec2f59104d941882be820fd861eae5a7",
"pubkey": "7b06ddce9de13e721393b0cddfafb893cf328773dd66f6f74ba14cd0cf183749",
"created_at": 1686314672,
"kind": 1,
"tags": [
[
"e",
"d508e26ae44d949f7c534399c4b1e4f82df043bc5ea4ea4a1d4d81571bfaec45",
"",
"root"
],
[
"e",
"f5a833fe18ecb9397568d6d19c2a054cceedb44343879c0444f1fc1455886007",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-23\n📝 Original message:\nThe obvious problem with having the whole network use the same set of\nbeacons at the same time is that those nodes will get slammed. A possible\nsolution is to have each user pick their own set of beacons (at random),\nbut make the beacon set large enough so that any two users are likely to\nshare a few. That way the all of nodes would share the load roughly evenly.\n\nThe size needed should be something on the order of the square root of the\nnumber of nodes. Some math could be done to see what set size would be\nneeded to have a given probability of two users having an intersection of\nat least a given size.\n\nIf you went with that you wouldn't have to worry about the extra mess of\nmaking sure everyone has consensus on the official beacon set.\n\nOn Sun, Sep 20, 2015 at 7:16 PM, Rusty Russell \u003crusty at rustcorp.com.au\u003e\nwrote:\n\n\u003e Hi Amos,\n\u003e\n\u003e I'm delighted that someone else is thinking about routing!\n\u003e\n\u003e I like the information hiding features, but I don't think this will\n\u003e scale if everyone floods the network before sending a transaction.\n\u003e\n\u003e I do, however, have an alternate scheme which is something of a\n\u003e middleman, which I'd appreciate your feedback on.\n\u003e\n\u003e We regularly choose a dozen \"beacon\" nodes at random (using proximity to\n\u003e the SHA of latest block hash or something). Everyone propagates the\n\u003e cheapest route to \u0026 from those nodes (which is pretty efficient, similar\n\u003e to your scheme).\n\u003e\n\u003e To receive a payment, B picks a few beacon nodes at random and sends\n\u003e those routes (beacons -\u003e B) to A. Presumably A knows its route to all\n\u003e the beacon nodes and thus can choose the best.\n\u003e\n\u003e There are some twisty details here:\n\u003e\n\u003e 1) How many beacon nodes?\n\u003e 12, and increase on a log scale with network size. That size can\n\u003e be derived from previous beacons.\n\u003e\n\u003e 2) How long between selection and a beacon becoming active?\n\u003e 10 blocks. That gives time for others to connect to beacon node.\n\u003e\n\u003e 3) How long before a beacon node is invalid?\n\u003e No idea. Let's keep a day's worth for the moment?\n\u003e\n\u003e 4) How to avoid fake beacons?\n\u003e Require a signature attached to an unspent bitcoin TX from before\n\u003e beacon selection? That TXID is actually what competes to be close\n\u003e to the beacon selector.\n\u003e\n\u003e 5) How to update beacon routing?\n\u003e Particularly for fee changes, this is important. Best effort,\n\u003e with ratelimiting. I hope eventually we'll have reasonable traffic\n\u003e models so a node can say \"I'm going to ramp up/down my fees for\n\u003e this long at this rate\" and have a reasonable chance that it's true.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e PS. For the immediate term, we'll use a global comms mechanism like\n\u003e IRC, but that's just a prototype hack.\n\u003e\n\u003e Amos Bairn \u003ceylrid at gmail.com\u003e writes:\n\u003e \u003e Here is a scheme I thought of for flood based route finding. If it can be\n\u003e \u003e pulled off it would allow efficient route finding while keeping the shape\n\u003e \u003e of the network hidden, as well as giving onion like anonymity.\n\u003e \u003e\n\u003e \u003e After writing it up a realized that it has a trivial denial of service\n\u003e \u003e attack, that could render it a non-starter.\n\u003e \u003e\n\u003e \u003e I'm throwing it out there anyway, because this could have significant\n\u003e \u003e potential if the DoS problem can be solved.\n\u003e \u003e\n\u003e \u003e https://github.com/Eylrid/ionization/blob/master/ionization.mediawiki\n\u003e \u003e _______________________________________________\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150922/b759a3fd/attachment-0001.html\u003e",
"sig": "6283d76fa5e92e530884354a19751866da40dc4b7bad434dbb917bb4d3693194f10ec7a516bb979670bcad1ab45c54caaf14f6add7ddd8b4512ea1f63c08e6b7"
}