Uh oh!
There was an error while loading. Please reload this page.
Implement route blinding test vectors - #3204
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@## main #3204 +/- ##
==========================================
+ Coverage 89.73% 90.21% +0.48%
==========================================
Files 123 124 +1 Lines 102287 106656 +4369 Branches 102287 106656 +4369 ==========================================
+ Hits 91784 96223 +4439 + Misses 7807 7759 -48 + Partials 2696 2674 -22 ☔ View full report in Codecov by Sentry. |
9c228eb to
1f7d3faCompare
TheBlueMatt
left a comment
There was a problem hiding this comment.
Needs to go in a release soon for the features thing, right?
| pub features: BlindedHopFeatures, | ||
| /// Set if this [`BlindedPath`] is concatenated to another, to indicate the | ||
| /// [`BlindedPath::blinding_point`] of the appended blinded path. | ||
| pub next_blinding_override: Option<PublicKey>, |
There was a problem hiding this comment.
Why didn't we support this to begin with?
There was a problem hiding this comment.
IIRC I was under the impression that this field only applies to onion messages (it's required for OMs), not payments. And no one actually sets it for payments, so it never popped up in interop testing. :/
There was a problem hiding this comment.
I imagine no one set it ever, because its only useful for some kind of weird frankenstein trampoline afaict? What's the intended usecase for concatenating blinded paths? I mean I suppose we should just do it, but I'm curious why its there.
There was a problem hiding this comment.
I think Rusty pointed out here that it can help prevent the intro node from being aware that it's the intro node: lightning/bolts#1182 (comment)? I think this is clarified in lightning/bolts#1182 but still need to review that.
Edit: it is clarified quite a bit in that PR:
There was a problem hiding this comment.
Ah, so basically its saying we should send onion messages as a blinded path from us to the intro node, prepended to the real blinded path? Do we do that?
There was a problem hiding this comment.
Yes, using next_blinding_override in OMs has always been required to prepend the unblinded path to the intro node.
There was a problem hiding this comment.
Oops, I think I misread your message. I'm not sure I follow Rusty's logic, actually. It seems like creating a blinded path from us to the intro node trades off the intro node knowing that they're the intro node for the node prior to the intro node knowing that the next hop is the intro node(?). Unless we set next_blinding_override for every hop in our prepended blinded path, which I suppose is possible.
There was a problem hiding this comment.
Ah, I guess I'm still not really understanding why this is here, but its not much complexity to support, sooooo
76d0d8d1f7d3fa to
76d0d8dComparevalentinewallace
commented
Aug 16, 2024
Rebased due to conflicts. |
| impl_feature_write_without_length!(ChannelTypeFeatures); | ||
| impl_feature_write_without_length!(InvoiceRequestFeatures); | ||
| impl_feature_write_without_length!(OfferFeatures); | ||
| impl_feature_write_without_length!(BlindedHopFeatures); |
There was a problem hiding this comment.
Had to add this line to the feature ser fix due to changes in commit 0c5922e92a3ec3fdf9226cceeb9057ad9aa9dc19.
TheBlueMatt
commented
Aug 19, 2024
|
76d0d8d to
f6ef1aaComparevalentinewallace
commented
Aug 19, 2024
Had a rebase error, squashed change with the following diff: diff --git a/lightning/src/blinded_path/payment.rs b/lightning/src/blinded_path/payment.rs
index 10d5d8de0..ca937c57d 100644
--- a/lightning/src/blinded_path/payment.rs+++ b/lightning/src/blinded_path/payment.rs@@ -201,8 +201,8 @@ pub struct ForwardTlvs {
///
/// [`BlindedHop::encrypted_payload`]: crate::blinded_path::BlindedHop::encrypted_payload
pub features: BlindedHopFeatures,
- /// Set if this [`BlindedPath`] is concatenated to another, to indicate the- /// [`BlindedPath::blinding_point`] of the appended blinded path.+ /// Set if this [`BlindedPaymentPath`] is concatenated to another, to indicate the+ /// [`BlindedPaymentPath::blinding_point`] of the appended blinded path.
pub next_blinding_override: Option<PublicKey>,
}
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 2054e4e8e..e08b45558 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -227,8 +227,8 @@ pub struct BlindedForward {
/// the introduction node.
pub failure: BlindedFailure,
/// Overrides the next hop's [`msgs::UpdateAddHTLC::blinding_point`]. Set if this HTLC is being
- /// forwarded within a [`BlindedPath`] that was concatenated to another blinded path that starts- /// at the next hop.+ /// forwarded within a [`BlindedPaymentPath`] that was concatenated to another blinded path that+ /// starts at the next hop.
pub next_blinding_override: Option<PublicKey>,
} |
TheBlueMatt
commented
Aug 19, 2024
|
This allow us to forward blinded payments where the blinded path that we are forwarding within was concatenated to another blinded path that starts at the next hop. Also allows constructing blinded paths using this override.
We were writing a length redundantly...
No reason to take a reference to a Deref.
f6ef1aa to
6f6115fComparevalentinewallace
commented
Aug 19, 2024
diff --git a/fuzz/src/invoice_request_deser.rs b/fuzz/src/invoice_request_deser.rs
index a5db1c4be..3abb0974e 100644
--- a/fuzz/src/invoice_request_deser.rs+++ b/fuzz/src/invoice_request_deser.rs@@ -113,6 +113,7 @@ fn build_response<T: secp256k1::Signing + secp256k1::Verification>(
htlc_minimum_msat: 100,
},
features: BlindedHopFeatures::empty(),
+ next_blinding_override: None,
},
node_id: pubkey(43),
htlc_maximum_msat: 1_000_000_000_000,
diff --git a/fuzz/src/refund_deser.rs b/fuzz/src/refund_deser.rs
index 58dc68eed..17f255081 100644
--- a/fuzz/src/refund_deser.rs+++ b/fuzz/src/refund_deser.rs@@ -91,6 +91,7 @@ fn build_response<T: secp256k1::Signing + secp256k1::Verification>(
htlc_minimum_msat: 100,
},
features: BlindedHopFeatures::empty(),
+ next_blinding_override: None,
},
node_id: pubkey(43),
htlc_maximum_msat: 1_000_000_000_000, |
See https://github.com/lightning/bolts/blob/3fffab3b889c9a6818130b56fb6dcfdf6906f90e/bolt04/route-blinding-test.json for test vectors.
This also adds support for
next_blinding_overridein blinded payment paths, and fixes a ser bug for blinded hop features.