Introduce Padding for Payment and Message Blinded Tlvs#3177
Introduce Padding for Payment and Message Blinded Tlvs#3177TheBlueMatt merged 7 commits intolightningdevkit:mainfrom
Conversation
Notes:
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3177 +/- ##
==========================================
- Coverage 88.54% 88.53% -0.01%
==========================================
Files 149 149
Lines 114579 114704 +125
Branches 114579 114704 +125
==========================================
+ Hits 101457 101558 +101
- Misses 10633 10650 +17
- Partials 2489 2496 +7 ☔ View full report in Codecov by Sentry. |
|
Updated from pr3177.01 to pr3177.02 (diff): Changes:
|
|
Updated from pr3177.02 to pr3177.03 (diff): Changes:
Diff post rebase: --- a/lightning/src/ln/offers_tests.rs
+++ b/lightning/src/ln/offers_tests.rs
@@ -1789,7 +1789,7 @@ fn test_blinded_path_padding() {
let onion_message = charlie.onion_messenger.next_onion_message_for_peer(david_id).unwrap();
david.onion_messenger.handle_onion_message(&charlie_id, &onion_message);
- let invoice = extract_invoice(david, &onion_message);
+ let (invoice, _) = extract_invoice(david, &onion_message);
assert_eq!(invoice, expected_invoice); |
|
Updated from pr3177.03 to pr3177.04 (diff):
|
|
Update: From pr3177.08 to pr3177.09 (diff): Changes based on @jkczyz's feedback:
|
| if let Some(ss) = prev_control_tlvs_ss.take() { | ||
| payloads.push((Payload::Forward(ForwardControlTlvs::Unblinded( | ||
| ForwardTlvs { | ||
| padding: None, |
There was a problem hiding this comment.
@TheBlueMatt One thing that I'm unsure of is whether we only need to pad the blinded path or if we should also pad the unblinded portion of the onion.
TheBlueMatt
left a comment
There was a problem hiding this comment.
LGTM, @jkczyz you wanna take another look?
jkczyz
left a comment
There was a problem hiding this comment.
Looks like rustfmt CI checks are failing. Otherwise, just one nit and LGTM.
Renaming the struct to `BlindedPathPadding` makes its purpose explicit,
clarifying that it is specifically used for `Blinded{Message/Payment}Paths`.
Padding serves as filler data with no explicit use case, making it more efficient to ignore it rather than read and discard it. This change simplifies the code by removing unnecessary `Readable` implementation for padding.
1. This allows setting the length of padding at the time of writing. 2. This will be used in the following commit to allow setting the padding for blinded message paths, and blinded payment paths.
Add a generic `BlindedPathWithPadding` struct to handle padding for `ForwardTlvs` and `ReceiveTlvs` used in `BlindedMessagePath` and `BlindedPaymentPath`. This struct applies padding to the contained TLVs, rounding them off to a specified value. This design provides flexibility in padding TLVs of varying sizes. The `PADDING_ROUND_OFF` value is chosen to be sufficiently large to properly mask the data type of the contained TLVs.
A note of Compact Blinded Paths: Compact Blinded paths are intended to be as short as possible. So to maintain there compactness, we don't apply padding to them.
Add test to verify blinded message and payment path padding.
Description
This PR introduces padding for
PaymentandMessageBlinded TLVs to ensure that the size of each packet in the path is uniform.