ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-01 📝 Original message: Good morning Pierre, ...
📅 Original date posted:2019-04-01
📝 Original message:
Good morning Pierre, Rene, and list,
I would also like to point out that even if the trampoline point does not know the next trampoline point, then it need not fail the routing.
(this may occur if we start pruning the routemap as the LN size grows)
As long as we can fix the issues regarding HMAC, then the trampoline point may itself delegate the routing to the next trampoline point to another trampoline point it inserts into the onion.
So what we need to somehow support, is to be able to "left shift" and "right shift" arbitrarily in the onion packet.
If we can handle this, then trampolining is possible and trampoline routing is feasible to delegate routing elsewhere.
This also ties with deterministic methods of pruning routemaps.
For instance, somebody proposed to create a false "geographic location" for each node, possibly derived only from the node public key being projected into some spatial volume.
(To be clear, this does *not* mean that every node needs to register some merely-Earth-based location, which can be easily falsified anyway; instead we project the node public key to some notion of "nearness")
Then a node might be expected to keep at least the nearest nodes to its "geographic location" in its routemap.
Then if I happen to be a trampoline point, and I am unable to locate the next trampoline point in my local routemap, I could instead locate the node on my routemap that is "nearest" to the next trampoline point, and forward the payment there.
Now, to an extent, privacy is reduced here since it is likelier than before that the "next trampoline" is actually the payee.
However, as a source node, I only need to know the actual route to my first trampoline point, and let the trampoline point worry about how to get it to the next trampoline.
So I can even just prune only the channels and channel relationships (endpoints of channels), and retain only the node public keys (a cheap 32 bytes), probably pruning the node public keys in some deterministically probabilistic fashion.
In this case, I might still be interested in gossip about faraway channels --- I would still want to check that the channel exists (by blockchain lookup), but after I know the channel exists I can throw it away, only considering it as a proof-of-existence of a faraway node that I might use as a trampoline to improve my privacy.
In effect, this lets us give a continuum:
1. At one end, the full route and every intermediate hop to the destination is known only by the source.
2. At the other end, the source only knows its direct channels, and sends to some adjacent trampoline node, and asks the trampoline node to route to the destination.
The above gives a nice continuum where the amount of space dedicated to your own local routemap improves your privacy, and you can prune your routemap at the cost of privacy reduction (and probably hedging your fees by always overpaying fees).
Regards,
ZmnSCPxj
📝 Original message:
Good morning Pierre, Rene, and list,
I would also like to point out that even if the trampoline point does not know the next trampoline point, then it need not fail the routing.
(this may occur if we start pruning the routemap as the LN size grows)
As long as we can fix the issues regarding HMAC, then the trampoline point may itself delegate the routing to the next trampoline point to another trampoline point it inserts into the onion.
So what we need to somehow support, is to be able to "left shift" and "right shift" arbitrarily in the onion packet.
If we can handle this, then trampolining is possible and trampoline routing is feasible to delegate routing elsewhere.
This also ties with deterministic methods of pruning routemaps.
For instance, somebody proposed to create a false "geographic location" for each node, possibly derived only from the node public key being projected into some spatial volume.
(To be clear, this does *not* mean that every node needs to register some merely-Earth-based location, which can be easily falsified anyway; instead we project the node public key to some notion of "nearness")
Then a node might be expected to keep at least the nearest nodes to its "geographic location" in its routemap.
Then if I happen to be a trampoline point, and I am unable to locate the next trampoline point in my local routemap, I could instead locate the node on my routemap that is "nearest" to the next trampoline point, and forward the payment there.
Now, to an extent, privacy is reduced here since it is likelier than before that the "next trampoline" is actually the payee.
However, as a source node, I only need to know the actual route to my first trampoline point, and let the trampoline point worry about how to get it to the next trampoline.
So I can even just prune only the channels and channel relationships (endpoints of channels), and retain only the node public keys (a cheap 32 bytes), probably pruning the node public keys in some deterministically probabilistic fashion.
In this case, I might still be interested in gossip about faraway channels --- I would still want to check that the channel exists (by blockchain lookup), but after I know the channel exists I can throw it away, only considering it as a proof-of-existence of a faraway node that I might use as a trampoline to improve my privacy.
In effect, this lets us give a continuum:
1. At one end, the full route and every intermediate hop to the destination is known only by the source.
2. At the other end, the source only knows its direct channels, and sends to some adjacent trampoline node, and asks the trampoline node to route to the destination.
The above gives a nice continuum where the amount of space dedicated to your own local routemap improves your privacy, and you can prune your routemap at the cost of privacy reduction (and probably hedging your fees by always overpaying fees).
Regards,
ZmnSCPxj