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 proposal #611

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@t-bast
Copy link
Collaborator

commented May 23, 2019

This PR highlights proposed changes to enable trampoline routing (once #593 and #603 are accepted).

Everything is currently grouped in a single file to make the initial review process easier. Once we start converging on the proposal, the final changes should probably be split between bolts 2, 4 and 7 (unless you feel this should be a new bolt) and the wording should be in formal spec format (with more details on some sections).

@cdecker cdecker requested review from cdecker, Roasbeef and sstone May 23, 2019

@cdecker

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2019

FWIW I think it is a great idea to have an overall design doc like this that collects all the details of the incremental change in one place. We agreed on having a "living" spec, but I still like having a well-written and easy to follow bundle that explains the rationale more in depth 👍

Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md Outdated
Show resolved Hide resolved wip-trampoline.md
other nodes. This is a great opportunity to incentivize nodes to open channels
between each other to minimize the cost of trampoline hops. This is also a
great opportunity for nodes to implement smart fee estimation algorithms as
a competitive advantage.

This comment has been minimized.

Copy link
@cdecker

cdecker May 27, 2019

Collaborator

Is it? I would expect the trampoline to just do trial-and-error with the maximum fee allocated to themselves just like the original sender would. That's not really estimating fees at all. They even get told how much funds MUST arrive at the next trampoline.

This comment has been minimized.

Copy link
@t-bast

t-bast May 28, 2019

Author Collaborator

They even get told how much funds MUST arrive at the next trampoline.

But that will often be based on the fee they advertised (via their estimation algorithm) ;)

I would expect the trampoline to just do trial-and-error

They could, but there's a risk they will end up locking up funds if one of the nodes in the route is unresponsive and they have to wait until the timeout. It's hard to predict because I think the heuristics will depend on the reliability of the overall network, but I think both options could make sense.

@t-bast

This comment has been minimized.

Copy link
Collaborator Author

commented May 28, 2019

Thanks for all the feedback @cdecker, really appreciate it (especially since this is a somewhat dense early draft).

We agreed on having a "living" spec, but I still like having a well-written and easy to follow bundle that explains the rationale more in depth

I think we could use the wiki for that (like what you did for rendezvous). Once the trampoline proposal is integrated to the spec (in spec format, probably split between multiple bolt pages), a wiki page to explain the rationale and give an overall view of how all pieces come together is going to be useful. What do you think?

I think all of your comments from the first review are now addressed, feel free to have another look whenever you have time. The PR looks really big but it's mainly because I added detailed example that hopefully help understand how it would work in details. These examples will be converted to test vectors once we start converging and have tested implementations.

This PR depends on the variable-size onion payloads that you're working on and on TLVs (the formats might thus change slightly depending on changes to those PRs).

trampoline: offloading payment route calculation
Specify an onion TLV that allows using trampoline nodes to route payments.
Initial draft of network pruning heuristics and filters for bandwidth efficiency.

@t-bast t-bast force-pushed the t-bast:b4-trampoline-onion branch from 62b35b4 to f2d0ece Jun 3, 2019

* [`32`:`hmac`]

The `tlv_stream` contains data necessary to route to the next trampoline hop.
The following types MAY be used to encode that data:

This comment has been minimized.

Copy link
@t-bast

t-bast Jun 3, 2019

Author Collaborator

It feels like many TLV types will be useful accross many message types.
I'd like to have a centralized place where we could register known TLVs and their assigned type (like what we have in bolt9). I think that all the TLVs I'm using here (except the trampoline_onion) will be useful to other messages and should be specified outside of this PR.

@t-bast t-bast requested a review from cdecker Jun 3, 2019

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