Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trampoline Routing #654

Open
wants to merge 1 commit into
base: master
from

Conversation

@t-bast
Copy link
Collaborator

commented Aug 2, 2019

This proposal allows nodes running on constrained devices to sync only a small portion of the network
and leverage trampoline nodes to calculate the missing parts of the payment route.

The main idea is to use layered onions: a normal onion contains a smaller onion for the last hop of the route, and that smaller onion contains routing information to reach the next trampoline hop.

Note that this PR contains more information than what we will eventually add to the spec: this is to help readers understand the motivation more clearly, see the big picture and understand the algorithm more easily.

Once (if?) we have a concept ACK, this PR could be split into several PRs that can be implemented one at a time:

  • The onion construction and payment relaying (first section of this PR) can be done independently: it will provide a storage and computation improvement for nodes running on phones (but won't provide any improvement to bandwidth usage)
  • The network pruning / gossip filters part can be added afterwards and will provide bandwidth improvements (faster sync time and faster time-to-first-payment for mobile apps)
  • Then we can add trampoline routing hints to invoices and node_update messages in a third PR
Trampoline Routing
This proposal allows nodes running on constrained devices to sync only a small portion of the network
and leverage trampoline nodes to calculate the missing parts of the payment route.
@t-bast t-bast referenced this pull request Aug 2, 2019

@t-bast t-bast requested review from cdecker, ZmnSCPxj and Roasbeef Aug 2, 2019

payments. This proposal still uses an onion created by the payer so it doesn't sacrifice privacy (in most cases it
will even provide a bigger anonymity set).

Nodes that keep track of the whole network should advertise support for `trampoline_routing`. This is an opportunity

This comment has been minimized.

Copy link
@ZmnSCPxj

ZmnSCPxj Aug 2, 2019

Collaborator

Some day the whole public network will be big enough that very few nodes will be able to keep track of the whole network. My thought is that it is better if every node were able to advertise support for trampoline_routing, by allowing trampoline nodes to delegate routing by prepending a short trampoline sequence to the existing trampoline route. I imagine modifications to how the onion is encrypted and validated by HMAC can be done to allow prepending trampoline sequences.

I want you to imagine a world with 10 billion published channels. Yes, we might not want to live in that world. But that world may very well exist in our future light cone (I would like to specifically deny that I am any kind of machine intelligence working towards such a goal, and specifically deny that I intend to use this to take control of the Earth): we cannot really prevent people from publishing their channels if they insist, we can only selectively ignore them. Yet it should still be possible to route to them, at least if we manage to reach some trampoline-supporting node that is near enough that their limited, myopic view of the network can find them.

I imagine having the HMAC cover enough of the next hop to validate the (encrypted) HMAC of the next hop is enough, rather than covering the entire onion buffer including filler. (It is also entirely possible that I understood too little of the math for this to work, so---)

This comment has been minimized.

Copy link
@t-bast

t-bast Aug 2, 2019

Author Collaborator

I was pretty sure you would comment something like that, especially after reading your last email on routing ;)

I totally agree that in the long run, we don't want/need to ask trampoline nodes to sync the whole network and accurately estimate fees (we have retries to make up for inaccuracy and failures). But we must take this problem one step at a time, and I think this goes in the right direction. This proposal doesn't force trampoline nodes to sync the whole network and I think it slowly goes towards a packet-switched, internet-like network where trampoline nodes would act as AS routers.

I'm not afraid of the cryptographic/mac part: we will find a way to make it work. So bottom line is: I agree with you on the long-term goals and I think this is a first step towards that.

This comment has been minimized.

Copy link
@ZmnSCPxj

ZmnSCPxj Aug 2, 2019

Collaborator

Okay. I am afraid I am skimming the details for now. It seems fine for a first cut.

Note that it reveals the identity of the recipient and the amount paid to the last trampoline node (but it doesn't
reveal the identity of the payer). This can be avoided if the recipient uses rendez-vous routing to hide its identity.
Otherwise recipients should support `trampoline_routing` to preserve their anonymity (and can advertise a high `fee`
if they don't want to be chosen to route too many payments, or never send a `node_update` if they don't want to route

This comment has been minimized.

Copy link
@ZmnSCPxj

ZmnSCPxj Aug 2, 2019

Collaborator

If they never send a node_update then it is rather obvious that they are still the payee (else how did the payer know to include them on the trampoline route), and that is what you want to avoid by signalling trampoline_routing also, so...

Anonymity loves company, and it is the anonymity of being part of the crowd that is an important reason why I believe we will eventually have a public network with 10 billiion channels, with every node acting similarly to every other node, as per Risk-Sharing Principle.

This comment has been minimized.

Copy link
@t-bast

t-bast Aug 2, 2019

Author Collaborator

I agree. As always in lightning payments, the trade-offs you make are privacy vs cost-efficiency. Privacy-concerned nodes should support trampoline. In my ideal world everyone is privacy-concerned and does that.

I included this statement mainly to show that payers can use trampoline payments even if payees don't want to fully support it (same for the section on sending to non-trampoline-aware nodes). But I expect this statement to be removed before we merge to the spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.