📅 Original date posted:2019-08-05
📝 Original message:
Thank you very much. These were very clarifying answers and ramblings.
On Monday, August 5, 2019, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning fiatjaf,
>
>> No. My question was more like why does Alice decide to build a route
that for through T1 and RT2 and not only through one trampoline router she
knows.
>
> If Alice only always used one trampoline node, then the trampoline node
can assume the next hop is always the payee, and thus record who the payee
is (eroding privacy).
> If Alice uses two, then a trampoline node would have a 50/50 chance of
knowing who the final payee is, reducing the privacy erosion.
>
> Similarly, onion routing over Tor typically passes through 3 "trampoline"
nodes before going to the actual site being accessed.
>
>>
>> That makes sense you me in the context of ZmnSCPxj's virtual space idea,
but not necessarily in the current network conditions. You also said we're
going to need some hierarchy, but what it's that? Is it required?
>
> I believe in the future we will see a public network that is too large to
fit on most devices available to most people.
> We may or may not want to have such an enormous network, but the cost of
advertising a public channel is the same as the cost of creating a
non-public channel, thus there is no incentive for random end-user nodes to
*not* publish their channels, and incentive to publish (there is a tiny but
non-zero chance of being routed through, especially as local-area
specializations like JIT-Routing get implemented).
>
> Thus, I believe it is eventually required that we hierarchicalize how we
store information, with a "myopic" detailed channel map and a "rough"
global map with just trampoline-payee association mappings.
> I think it is best for each payer to define its own hierarchy or split,
preferentially with some random component.
>
> One might consider, however, that my ramblings are too indefinite and it
would be better to see the network as it evolves.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190805/85da457a/attachment.html>;
fiatjaf [ARCHIVE] /
npub1v2…pmakl
2023-06-09 12:55:49
in reply to nevent1q…a66k
Author Public Key
npub1v2xa40strmvauf2gr5gjj5c3yqlytar7p3v64nfg0ke6e0vkvvkqxpmaklPublished at
2023-06-09 12:55:49Event JSON
{
"id": "5efe279b53caef2240d2b569ad74a1ed89dae1206704af6a994b1fa736c62ee9",
"pubkey": "628ddabe0b1ed9de25481d11295311203e45f47e0c59aacd287db3acbd96632c",
"created_at": 1686315349,
"kind": 1,
"tags": [
[
"e",
"b1a85a64854de122540c55990bd6eed42499043134bdfb485c2e08bb0baa1471",
"",
"root"
],
[
"e",
"59fdb5201bb9450a7e393490b97d677a3c11f638f737db1bab2fd76b8122de9d",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-08-05\n📝 Original message:\nThank you very much. These were very clarifying answers and ramblings.\n\nOn Monday, August 5, 2019, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e Good morning fiatjaf,\n\u003e\n\u003e\u003e No. My question was more like why does Alice decide to build a route\nthat for through T1 and RT2 and not only through one trampoline router she\nknows.\n\u003e\n\u003e If Alice only always used one trampoline node, then the trampoline node\ncan assume the next hop is always the payee, and thus record who the payee\nis (eroding privacy).\n\u003e If Alice uses two, then a trampoline node would have a 50/50 chance of\nknowing who the final payee is, reducing the privacy erosion.\n\u003e\n\u003e Similarly, onion routing over Tor typically passes through 3 \"trampoline\"\nnodes before going to the actual site being accessed.\n\u003e\n\u003e\u003e\n\u003e\u003e That makes sense you me in the context of ZmnSCPxj's virtual space idea,\nbut not necessarily in the current network conditions. You also said we're\ngoing to need some hierarchy, but what it's that? Is it required?\n\u003e\n\u003e I believe in the future we will see a public network that is too large to\nfit on most devices available to most people.\n\u003e We may or may not want to have such an enormous network, but the cost of\nadvertising a public channel is the same as the cost of creating a\nnon-public channel, thus there is no incentive for random end-user nodes to\n*not* publish their channels, and incentive to publish (there is a tiny but\nnon-zero chance of being routed through, especially as local-area\nspecializations like JIT-Routing get implemented).\n\u003e\n\u003e Thus, I believe it is eventually required that we hierarchicalize how we\nstore information, with a \"myopic\" detailed channel map and a \"rough\"\nglobal map with just trampoline-payee association mappings.\n\u003e I think it is best for each payer to define its own hierarchy or split,\npreferentially with some random component.\n\u003e\n\u003e One might consider, however, that my ramblings are too indefinite and it\nwould be better to see the network as it evolves.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190805/85da457a/attachment.html\u003e",
"sig": "c9069b2604f5566e3848b8dcc96c75b999145d11e78fa8347f01497f4a6ede3d0b000801f3edd413d985bf317c8eb21e46c29724df6fe95c9414e69ddc47f3c3"
}