Trampoline routing proposal #611
Conversation
|
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 👍 |
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Thanks for all the feedback @cdecker, really appreciate it (especially since this is a somewhat dense early draft).
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). |
Specify an onion TLV that allows using trampoline nodes to route payments. Initial draft of network pruning heuristics and filters for bandwidth efficiency.
| * [`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: |
There was a problem hiding this comment.
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.
|
Closing in favor of #654 |
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).