BOLT 12 Offers message flow #2039
Merged
Conversation
This file contains 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
jkczyz
force-pushed
the
2023-02-offer-flow
branch
2 times, most recently
from
07a2742
to
6ab6525
Compare
jkczyz
force-pushed
the
2023-02-offer-flow
branch
2 times, most recently
from
840d4a5
to
f167b0b
Compare
|
Mind rebasing this? 🙏 |
jkczyz
force-pushed
the
2023-02-offer-flow
branch
from
f167b0b
to
7f67ee5
Compare
Rebased and included recent changes from #1989. |
jkczyz
force-pushed
the
2023-02-offer-flow
branch
from
7f67ee5
to
ebc0436
Compare
jkczyz
force-pushed
the
2023-02-offer-flow
branch
from
ebc0436
to
45181c9
Compare
jkczyz
force-pushed
the
2023-02-offer-flow
branch
from
45181c9
to
e3fec6e
Compare
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2039 +/- ##
==========================================
- Coverage 88.93% 88.76% -0.17%
==========================================
Files 112 112
Lines 87850 88258 +408
Branches 87850 88258 +408
==========================================
+ Hits 78129 78346 +217
- Misses 7473 7667 +194
+ Partials 2248 2245 -3
☔ View full report in Codecov by Sentry. |
jkczyz
force-pushed
the
2023-02-offer-flow
branch
from
e3fec6e
to
f962dfb
Compare
jkczyz
force-pushed
the
2023-02-offer-flow
branch
from
f962dfb
to
05d2755
Compare
jkczyz
force-pushed
the
2023-02-offer-flow
branch
2 times, most recently
from
acb28b9
to
082f6e9
Compare
jkczyz
force-pushed
the
2023-02-offer-flow
branch
from
082f6e9
to
736fe4a
Compare
TheBlueMatt
reviewed
Sep 8, 2023
jkczyz
force-pushed
the
2023-02-offer-flow
branch
from
736fe4a
to
37c2492
Compare
jkczyz
force-pushed
the
2023-02-offer-flow
branch
2 times, most recently
from
4aa8fa1
to
3395bce
Compare
|
Oh, also had to trivially update |
jkczyz
force-pushed
the
2023-02-offer-flow
branch
2 times, most recently
from
9658805
to
a06cea3
Compare
|
Looks like this needs rebase now. |
Upcoming commits will add utilities for sending an InvoiceRequest for an Offer and an Invoice for a Refund. These messages need to be enqueued so that they can be released in ChannelManager's implementation of OffersMessageHandler to OnionMessenger for sending. These messages do not need to be serialized as they must be resent upon restart.
Pending outbound payments use an absolute expiry to determine when they are considered stale and should be fail. In `no-std`, this may result in long timeouts as the highest seen block time is used. Instead, allow for expiration based on timer ticks. This will be use in an upcoming commit for invoice request expiration.
Add a utility to ChannelManager for sending an InvoiceRequest for an Offer such that derived keys are used for the payer id. This allows for stateless verification of any Invoice messages before it is paid. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.
Add a utility to ChannelManager for creating a Bolt12Invoice for a Refund such that the ChannelManager can recognize the PaymentHash and reconstruct the PaymentPreimage from the PaymentSecret, the latter of which is contained in a BlindedPath within the invoice.
Building an invoice will fail if the underlying offer or refund has already expired. The check was skipped in no-std since there is no system clock. However, the invoice creation time can be used instead. This prevents responding to an invoice request if the offer has already expired.
Define the BOLT 12 message flow in ChannelManager's OffersMessageHandler implementation. - An invoice_request message results in responding with an invoice message if it can be verified that the request is for a valid offer. - An invoice is paid if it can be verified to have originated from a sent invoice_request or a refund. - An invoice_error is sent in some failure cases. - Initial messages enqueued for sending are released to OnionMessenger
This reverts commit c7219e4.
DefaultMessageRouter always fails. Update it so that it can route to a directly connected peer. This is needed for an Offers minimum viable product.
jkczyz
force-pushed
the
2023-02-offer-flow
branch
from
a06cea3
to
fe90448
Compare
|
Rebased |
TheBlueMatt
approved these changes
Oct 20, 2023
There was a problem hiding this comment.
In a followup, I'd like to see the default max_total_routing_fee_msat in send_payment_for_bolt12_invoice not be None, but the default set in RouteParameters::from_payment_params_and_value. Users should have to opt out of a fee ceiling (by setting a max of infinite) rather than opt-in to one (by setting one), I think. We can also drop the allow(unused) on send_payment_for_bolt12_invoice.
A few other nits here but nothing worth fixing in this PR.
| let route_params = RouteParameters::from_payment_params_and_value(payment_params, amt_msat); | ||
| let route = get_route( | ||
| &nodes[0].node.get_our_node_id(), &route_params, &nodes[0].network_graph.read_only(), None, | ||
| nodes[0].logger, &scorer, &(), &random_seed_bytes |
There was a problem hiding this comment.
nit: Please leave the Default::default in place.
| @@ -48,6 +48,16 @@ pub struct ErroneousField { | |||
| pub suggested_value: Option<Vec<u8>>, | |||
| } | |||
|
|
|||
| impl InvoiceError { | |||
| /// Creates an [`InvoiceError`] with the given message. | |||
| pub fn from_str(s: &str) -> Self { | |||
There was a problem hiding this comment.
Should just take the String - in one call we format!() create a String, then pass by reference here, and end up cloning it.
valentinewallace
approved these changes
Oct 20, 2023
k0k0ne
pushed a commit
to bitlightlabs/rust-lightning
that referenced
this pull request
Sep 30, 2024
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks" API Updates =========== * BOLT12 sending and receiving is now supported as an alpha feature. You may run into unexpected issues and will need to have a direct connection with the offer's blinded path introduction points as messages are not yet routed. We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039). * `ConfirmationTarget` has been rewritten to provide information about the specific use LDK needs the feerate estimate for, rather than the generic low-, medium-, and high-priority estimates. This allows LDK users to more accurately target their feerate estimates (lightningdevkit#2660). For those wishing to retain their existing behavior, see the table below for conversion. * `ChainHash` is now used in place of `BlockHash` where it represents the genesis block (lightningdevkit#2662). * `lightning-invoice` payment utilities now take a `Deref` to `AChannelManager` (lightningdevkit#2652). * `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599). * `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670) * `Display` is now implemented for `OutPoint` (lightningdevkit#2649). * `Features::from_be_bytes` is now provided (lightningdevkit#2640). For those moving to the new `ConfirmationTarget`, the new variants in terms of the old mempool/low/medium/high priorities are as follows: * `OnChainSweep` = `HighPriority` * `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)` * `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum` * `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250` * `AnchorChannelFee` = `Background` * `NonAnchorChannelFee` = `Normal` * `ChannelCloseMinimum` = `Background` Bug Fixes ========= * Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a channel which did not exist would immediately hang holding several key `ChannelManager`-internal locks (lightningdevkit#2657). * Channel information updates received from a failing HTLC are no longer applied to our `NetworkGraph`. This prevents a node which we attempted to route a payment through from being able to learn the sender of the payment. In some rare cases, this may result in marginally reduced payment success rates (lightningdevkit#2666). * Anchor outputs are now properly considered when calculating the amount available to send in HTLCs. This can prevent force-closes in anchor channels when sending payments which overflow the available balance (lightningdevkit#2674). * A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC, then reconnects prior to sending a `commitment_signed` (thus retransmitting their `update_fulfill_htlc`) may result in the channel stalling and being unable to make progress (lightningdevkit#2661). * In exceedingly rare circumstances, messages intended to be sent to a peer prior to reconnection can be sent after reconnection. This could result in undefined channel state and force-closes (lightningdevkit#2663). Backwards Compatibility ======================= * Creating a blinded path to receive a payment then downgrading to LDK prior to 0.0.117 may result in failure to receive the payment (lightningdevkit#2413). * Calling `ChannelManager::pay_for_offer` or `ChannelManager::create_refund_builder` may prevent downgrading to LDK prior to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039). Node Compatibility ================== * LDK now sends a bogus `channel_reestablish` message to peers when they ask to resume an unknown channel. This should cause LND nodes to force-close and broadcast the latest channel state to the chain. In order to trigger this when we wish to force-close a channel, LDK now disconnects immediately after sending a channel-closing `error` message. This should result in cooperative peers also working to confirm the latest commitment transaction when we wish to force-close (lightningdevkit#2658). Security ======== 0.0.118 expands mitigations against transaction cycling attacks to non-anchor channels, though note that no mitigations which exist today are considered robust to prevent the class of attacks. * In order to mitigate against transaction cycling attacks, non-anchor HTLC transactions are now properly re-signed before broadcasting (lightningdevkit#2667). In total, this release features 61 files changed, 3470 insertions, 1503 deletions in 85 commits from 12 authors, in alphabetical order: * Antonio Yang * Elias Rohrer * Evan Feenstra * Fedeparma74 * Gursharan Singh * Jeffrey Czyz * Matt Corallo * Sergi Delgado Segura * Vladimir Fomene * Wilmer Paulino * benthecarman * slanesuke
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.
Define the BOLT 12 message flow in
ChannelManager'sOffersMessageHandlerimplementation.invoice_requestmessage results in responding with aninvoicemessage if it can be verified that the request is for a valid offer.invoiceis paid if it can be verified to have originated from a sentinvoice_requestor arefund.invoice_erroris sent in some failure cases.Further, adds a utility for constructing a
Bolt12Invoicefor aRefundthat can be used withChannelManager.Based on #2578