📅 Original date posted:2015-09-20
📝 Original message:
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
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:44:28
in reply to nevent1q…rk4p
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:44:28Event JSON
{
"id": "ef363b3b9581be9dddd7fe6299150350471ac9a98e0a3f573bba3b00904ee623",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314668,
"kind": 1,
"tags": [
[
"e",
"d508e26ae44d949f7c534399c4b1e4f82df043bc5ea4ea4a1d4d81571bfaec45",
"",
"root"
],
[
"e",
"9e20fa9146588bcdd85a5754a148463bcce3fed3d1df7891907a6ea7396ddb23",
"",
"reply"
],
[
"p",
"7b06ddce9de13e721393b0cddfafb893cf328773dd66f6f74ba14cd0cf183749"
]
],
"content": "📅 Original date posted:2015-09-20\n📝 Original message:\nHi Amos,\n\n I'm delighted that someone else is thinking about routing!\n\nI like the information hiding features, but I don't think this will\nscale if everyone floods the network before sending a transaction.\n\nI do, however, have an alternate scheme which is something of a\nmiddleman, which I'd appreciate your feedback on.\n\nWe regularly choose a dozen \"beacon\" nodes at random (using proximity to\nthe SHA of latest block hash or something). Everyone propagates the\ncheapest route to \u0026 from those nodes (which is pretty efficient, similar\nto your scheme).\n\nTo receive a payment, B picks a few beacon nodes at random and sends\nthose routes (beacons -\u003e B) to A. Presumably A knows its route to all\nthe beacon nodes and thus can choose the best.\n\nThere are some twisty details here:\n\n1) How many beacon nodes?\n 12, and increase on a log scale with network size. That size can\n be derived from previous beacons.\n\n2) How long between selection and a beacon becoming active?\n 10 blocks. That gives time for others to connect to beacon node.\n\n3) How long before a beacon node is invalid?\n No idea. Let's keep a day's worth for the moment?\n\n4) How to avoid fake beacons?\n Require a signature attached to an unspent bitcoin TX from before\n beacon selection? That TXID is actually what competes to be close\n to the beacon selector.\n\n5) How to update beacon routing?\n Particularly for fee changes, this is important. Best effort,\n with ratelimiting. I hope eventually we'll have reasonable traffic\n models so a node can say \"I'm going to ramp up/down my fees for\n this long at this rate\" and have a reasonable chance that it's true.\n\nCheers,\nRusty.\nPS. For the immediate term, we'll use a global comms mechanism like\n IRC, but that's just a prototype hack.\n\nAmos Bairn \u003ceylrid at gmail.com\u003e writes:\n\u003e Here is a scheme I thought of for flood based route finding. If it can be\n\u003e pulled off it would allow efficient route finding while keeping the shape\n\u003e of the network hidden, as well as giving onion like anonymity.\n\u003e\n\u003e After writing it up a realized that it has a trivial denial of service\n\u003e attack, that could render it a non-starter.\n\u003e\n\u003e I'm throwing it out there anyway, because this could have significant\n\u003e potential if the DoS problem can be solved.\n\u003e\n\u003e https://github.com/Eylrid/ionization/blob/master/ionization.mediawiki\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "aa0180ef9e0a40e77319fddb00f19ff5ecd5ddef0673188d319f15a674aa1a3a357f8f33faec505dc9d2110cc1521552da54cba29b0bba0186d1bb8db59c3f30"
}