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 

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).

Lightning-dev mailing list

Reply via email to