Trampoline Payload Construction Method #3386
Conversation
| /// amended to match the features present in the invoice this node generated. | ||
| pub node_features: NodeFeatures, | ||
| /// The channel_announcement features of the channel that should be used from the previous hop | ||
| /// to reach this node. |
There was a problem hiding this comment.
I'm really confused, there's no explicit way that I see in OutboundOnionPayload::BlindedForward to specify the channel used. The previous trampoline hop can pick any channel they want, AFAIU...
| @@ -454,6 +454,9 @@ impl_writeable_tlv_based!(BlindedTail, { | |||
| pub struct Path { | |||
| /// The list of unblinded hops in this [`Path`]. Must be at least length one. | |||
| pub hops: Vec<RouteHop>, | |||
| /// The list of unblinded Trampoline hops. If present, must be at least one. | |||
There was a problem hiding this comment.
Vacuous statement is vacuous.
There was a problem hiding this comment.
"If present, must be at least one".
| @@ -454,6 +454,9 @@ impl_writeable_tlv_based!(BlindedTail, { | |||
| pub struct Path { | |||
| /// The list of unblinded hops in this [`Path`]. Must be at least length one. | |||
| pub hops: Vec<RouteHop>, | |||
| /// The list of unblinded Trampoline hops. If present, must be at least one. | |||
| /// The public key of the first Trampoline hop must match the public key of the last regular hop. | |||
There was a problem hiding this comment.
I don't see why this needs to be true. Can we just have each trampoline hop be next hops starting after the last unblinded node.
| @@ -454,6 +454,9 @@ impl_writeable_tlv_based!(BlindedTail, { | |||
| pub struct Path { | |||
| /// The list of unblinded hops in this [`Path`]. Must be at least length one. | |||
| pub hops: Vec<RouteHop>, | |||
| /// The list of unblinded Trampoline hops. If present, must be at least one. | |||
| /// The public key of the first Trampoline hop must match the public key of the last regular hop. | |||
| pub trampoline_hops: Vec<TrampolineHop>, | |||
There was a problem hiding this comment.
Seems weird to add this to the public API in a PR that doesn't use it. Can you go ahead and wire up build_trampoline_onion_payloads to build the valid onion in the same PR?
arik-so
force-pushed
the
arik/trampoline/payload-construction
branch
2 times, most recently
from
7cad33e
to
856ce97
Compare
arik-so
force-pushed
the
arik/trampoline/payload-construction
branch
from
856ce97
to
5ea3ada
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3386 +/- ##
==========================================
+ Coverage 89.61% 90.36% +0.75%
==========================================
Files 129 130 +1
Lines 105506 113544 +8038
Branches 105506 113544 +8038
==========================================
+ Hits 94544 102604 +8060
- Misses 8208 8214 +6
+ Partials 2754 2726 -28 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
| @@ -404,13 +404,16 @@ pub struct BlindedTail { | |||
| pub excess_final_cltv_expiry_delta: u32, | |||
| /// The total amount paid on this [`Path`], excluding the fees. | |||
| pub final_value_msat: u64, | |||
| /// Used for determining the type of Trampoline path to construct | |||
| pub final_hop_supports_trampoline: bool | |||
There was a problem hiding this comment.
Should we instead consider storing a *Features of some form?
| @@ -454,6 +454,9 @@ impl_writeable_tlv_based!(BlindedTail, { | |||
| pub struct Path { | |||
| /// The list of unblinded hops in this [`Path`]. Must be at least length one. | |||
| pub hops: Vec<RouteHop>, | |||
| /// The list of unblinded Trampoline hops. If present, must be at least one. | |||
There was a problem hiding this comment.
"If present, must be at least one".
Introduce a method for constructing Trampoline payloads.
This will allow the non-Trampoline method to be modified to generate a Trampoline onion and finish its own regular payload construction.