Add a new RecipientOnionFields and replace PaymentSecret with it
#2139
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TheBlueMatt
force-pushed
the
2023-03-metadata-prefactors
branch
from
855e240 to
3323137
Compare
lightning/src/ln/channelmanager.rs
Outdated
Comment on lines
240
to
241
| /// If you do not have one, the [`Route`] you pay over must not contain multiple paths as | ||
| /// multi-path payments require a recipient-provided secret. |
There was a problem hiding this comment.
Just checking, do we still plan to do #1222? I may have recently suggested it to a new contributor
There was a problem hiding this comment.
I do not, but someone totally should!
|
Oops, broke bench like always lol. The other issues are upstream cause futures broke us. |
TheBlueMatt
force-pushed
the
2023-03-metadata-prefactors
branch
3 times, most recently
from
9ee94f2 to
c86099c
Compare
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #2139 +/- ##
==========================================
+ Coverage 91.35% 91.60% +0.25%
==========================================
Files 102 102
Lines 49909 52715 +2806
Branches 49909 52715 +2806
==========================================
+ Hits 45592 48289 +2697
- Misses 4317 4426 +109
... and 11 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
TheBlueMatt
force-pushed
the
2023-03-metadata-prefactors
branch
from
c86099c to
c77a59d
Compare
|
Rebased. |
tnull
reviewed
Apr 4, 2023
lightning/src/ln/channelmanager.rs
Outdated
| @@ -226,6 +226,38 @@ impl Readable for PaymentId { | |||
| } | |||
| } | |||
|
|
|||
| /// Information which is provided, encrypted, to the payment recipient when sending HTLCs. | |||
| /// | |||
| /// This should generally be constructed with data communicated to us from the recipient (via some | |||
There was a problem hiding this comment.
This sentence is very vague and I'm actually not sure what it tries to tell me. How is which data communicated to us? What forms of invoices are there and which should I expect..?
There was a problem hiding this comment.
BOLT11 or BOLT12?
There was a problem hiding this comment.
I don't know. Maybe the sentence can even be dropped, but in its current form I don't find it to add any value: "something might happen sometimes in a variety of ways, possibly".
There was a problem hiding this comment.
We could make it stronger, I mean the point is that you're definitely getting the info from an invoice unless you're doing something super custom (or some "extension" protocol).
lightning/src/ln/channelmanager.rs
Outdated
| /// form of invoice). | ||
| #[derive(Clone)] | ||
| pub struct RecipientOnionFields { | ||
| /// The [`PaymentSecret`] which is an arbitrary 32 bytes provided by the recipient for us to |
There was a problem hiding this comment.
nit: "(..) which consists of 32 random bytes that were provided by the recipient and should be included in the onion."
There was a problem hiding this comment.
There's nothing that says it has to be random? In fact its not in LDK.
There was a problem hiding this comment.
Fair enough, still the sentence could use some restructuring and "an 32 bytes provided" is simply missing a word, no?
There was a problem hiding this comment.
Ah, right, needed to drop which.
TheBlueMatt
force-pushed
the
2023-03-metadata-prefactors
branch
2 times, most recently
from
fb26548 to
f129e9a
Compare
|
Oops, realized there were some small fixups from the parent PR that didnt end up here, pushed those. CI should fail on the each-commit-builds test but should pass after squash. |
TheBlueMatt
force-pushed
the
2023-03-metadata-prefactors
branch
2 times, most recently
from
fa3c946 to
f368f80
Compare
|
LGTM, will give it a final round after squash. |
Many of the fields in `HTLCSource::OutboundRoute` are used to rebuild the pending-outbound-payment map on reload if the `ChannelManager` was not serialized though `ChannelMonitor`(s) were after an HTLC was sent. As of 0.0.114, however, such payments are not retryable without allowing them to fail and doing a full, fresh, send. Thus, some of the fields can be safely removed - we only really care about having enough information to provide the user a failure event, not being able to retry. Here we drop one such field - the `payment_secret`, making our `ChannelMonitorUpdate`s another handful of bytes smaller.
This moves the public payment sending API from passing an explicit `PaymentSecret` to a new `RecipientOnionFields` struct (which currently only contains the `PaymentSecret`). This gives us substantial additional flexibility as we look at add both `PaymentMetadata`, a new (well, year-or-two-old) BOLT11 invoice extension to provide additional data sent to the recipient. In the future, we should also add the ability to add custom TLV entries in the `RecipientOnionFields` struct.
While most lightning nodes don't (currently) support providing a payment secret or payment metadata for spontaneous payments, there's no specific technical reason why we shouldn't support sending those fields to a recipient. Further, when we eventually move to allowing custom TLV entries in the recipient's onion TLV stream, we'll want to support it for spontaneous payments as well. Here we simply add the new `RecipientOnionFields` struct as an argument to the spontaneous payment send methods. We don't yet plumb it through the payment sending logic, which will come when we plumb the new struct through the sending logic to replace the existing payment secret arguments.
This passes the new `RecipientOnionFields` through the internal sending APIs, ensuring we have access to the full struct when we go to construct the sending onion so that we can include any new fields added there.
TheBlueMatt
force-pushed
the
2023-03-metadata-prefactors
branch
from
f368f80 to
36235c3
Compare
|
Squashed and added one commit to correct events docs. |
tnull
approved these changes
Apr 7, 2023
valentinewallace
approved these changes
Apr 7, 2023
k0k0ne
pushed a commit
to bitlightlabs/rust-lightning
that referenced
this pull request
Sep 30, 2024
0.0.115 - Apr 24, 2023 - "Rebroadcast the Bugfixes" API Updates =========== * The MSRV of the main LDK crates has been increased to 1.48 (lightningdevkit#2107). * Attempting to claim an un-expired payment on a channel which has closed no longer fails. The expiry time of payments is exposed via `PaymentClaimable::claim_deadline` (lightningdevkit#2148). * `payment_metadata` is now supported in `Invoice` deserialization, sending, and receiving (via a new `RecipientOnionFields` struct) (lightningdevkit#2139, lightningdevkit#2127). * `Event::PaymentFailed` now exposes a failure reason (lightningdevkit#2142). * BOLT12 messages now support stateless generation and validation (lightningdevkit#1989). * The `NetworkGraph` is now pruned of stale data after RGS processing (lightningdevkit#2161). * Max inbound HTLCs in-flight can be changed in the handshake config (lightningdevkit#2138). * `lightning-transaction-sync` feature `esplora-async-https` was added (lightningdevkit#2085). * A `ChannelPending` event is now emitted after the initial handshake (lightningdevkit#2098). * `PaymentForwarded::outbound_amount_forwarded_msat` was added (lightningdevkit#2136). * `ChannelManager::list_channels_by_counterparty` was added (lightningdevkit#2079). * `ChannelDetails::feerate_sat_per_1000_weight` was added (lightningdevkit#2094). * `Invoice::fallback_addresses` was added to fetch `bitcoin` types (lightningdevkit#2023). * The offer/refund description is now exposed in `Invoice{,Request}` (lightningdevkit#2206). Backwards Compatibility ======================= * Payments sent with the legacy `*_with_route` methods on LDK 0.0.115+ will no longer be retryable via the LDK 0.0.114- `retry_payment` method (lightningdevkit#2139). * `Event::PaymentPathFailed::retry` was removed and will always be `None` for payments initiated on 0.0.115 which fail on an earlier version (lightningdevkit#2063). * `Route`s and `PaymentParameters` with blinded path information will not be readable on prior versions of LDK. Such objects are not currently constructed by LDK, but may be when processing BOLT12 data in a coming release (lightningdevkit#2146). * Providing `ChannelMonitorUpdate`s generated by LDK 0.0.115 to a `ChannelMonitor` on 0.0.114 or before may panic (lightningdevkit#2059). Note that this is in general unsupported, and included here only for completeness. Bug Fixes ========= * Fixed a case where `process_events_async` may `poll` a `Future` which has already completed (lightningdevkit#2081). * Fixed deserialization of `u16` arrays. This bug may have previously corrupted the historical buckets in a `ProbabilisticScorer`. Users relying on the historical buckets may wish to wipe their scorer on upgrade to remove corrupt data rather than waiting on it to decay (lightningdevkit#2191). * The `process_events_async` task is now `Send` and can thus be polled on a multi-threaded runtime (lightningdevkit#2199). * Fixed a missing macro export causing `impl_writeable_tlv_based_enum{,_upgradable}` calls to not compile (lightningdevkit#2091). * Fixed compilation of `lightning-invoice` with both `no-std` and serde (lightningdevkit#2187) * Fix an issue where the `background-processor` would not wake when a `ChannelMonitorUpdate` completed asynchronously, causing delays (lightningdevkit#2090). * Fix an issue where `process_events_async` would exit immediately (lightningdevkit#2145). * `Router` calls from the `ChannelManager` now call `find_route_with_id` rather than `find_route`, as was intended and described in the API (lightningdevkit#2092). * Ensure `process_events_async` always exits if any sleep future returns true, not just if all sleep futures repeatedly return true (lightningdevkit#2145). * `channel_update` messages no longer set the disable bit unless the peer has been disconnected for some time. This should resolve cases where channels are disabled for extended periods of time (lightningdevkit#2198). * We no longer remove CLN nodes from the network graph for violating the BOLT spec in some cases after failing to pay through them (lightningdevkit#2220). * Fixed a debug assertion which may panic under heavy load (lightningdevkit#2172). * `CounterpartyForceClosed::peer_msg` is now wrapped in UntrustedString (lightningdevkit#2114) * Fixed a potential deadlock in `funding_transaction_generated` (lightningdevkit#2158). Security ======== * Transaction re-broadcasting is now substantially more aggressive, including a new regular rebroadcast feature called on a timer from the `background-processor` or from `ChainMonitor::rebroadcast_pending_claims`. This should substantially increase transaction confirmation reliability without relying on downstream `TransactionBroadcaster` implementations for rebroadcasting (lightningdevkit#2203, lightningdevkit#2205, lightningdevkit#2208). * Implemented the changes from BOLT PRs lightningdevkit#1031, lightningdevkit#1032, and lightningdevkit#1040 which resolve a privacy vulnerability which allows an intermediate node on the path to discover the final destination for a payment (lightningdevkit#2062). In total, this release features 110 files changed, 11928 insertions, 6368 deletions in 215 commits from 21 authors, in alphabetical order: * Advait * Alan Cohen * Alec Chen * Allan Douglas R. de Oliveira * Arik Sosman * Elias Rohrer * Evan Feenstra * Jeffrey Czyz * John Cantrell * Lucas Soriano del Pino * Marc Tyndel * Matt Corallo * Paul Miller * Steven * Steven Williamson * Steven Zhao * Tony Giorgio * Valentine Wallace * Wilmer Paulino * benthecarman * munjesi
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the bulk of #2127 by LoC changes, but none of the actual work - it imply adds the
RecipientOnionFieldsstruct and pipes it through all the send calls. #2127 will then be relatively simple in just adding the metadata feature/field and putting it in the onion.