BOLT 12 Offers utilities by jkczyz · Pull Request #2578 · lightningdevkit/rust-lightning

jkczyz · 2023-09-14T22:44:29Z

Add utility methods to ChannelManager for:

creating OfferBuilder such that derived keys are used for the signing pubkey,
creating RefundBuilder such that derived keys are used for the payer id, and
sending an InvoiceRequest for an Offer such that derived keys are used for the payer id

When the ChannelManager is the payer (i.e., when creating Refund and InvoiceRequest), a PaymentId is required and used for tracking the outbound payment once the Bolt12Invoice is received.

One-hop blinded paths are used throughout until multi-hop blinded paths are supported.

Offer message handling and sending a Bolt12Invoice for a Refund such that derived keys are used for the signing pubkey are in #2039, which is based on this PR.

TheBlueMatt · 2023-09-17T02:18:02Z

+	/// The message contents to send in an [`OnionMessage`].
+	///
+	/// [`OnionMessage`]: crate::ln::msgs::OnionMessage
+	pub contents: T,


Hmm, if we leave a totally unbounded type that's gonna be a problem for bindings. Can we bound this by CustomOnionMessageContents (or if we need a general bound we could create an OnionMessageContents trait that we impl for BOLT12 messages as well)?

We'll need a more general bound since OffersMessage is used, too.

TheBlueMatt · 2023-09-17T02:27:38Z

+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	/// [`InvoiceRequestBuilder`]: crate::offers::invoice_request::InvoiceRequestBuilder
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	pub fn request_invoice(


Does this need to be pub? I'm not sure what the use is for this outside of simply paying an offer, which is presumably a different method.

Ah, this is the "paying for an offer" method. I guess that I can rename it to be more user- rather than implementation-focused.

TheBlueMatt · 2023-09-18T19:36:59Z

 }

+/// A type used within a variant of [`OnionMessageContents`].
+pub trait OnionMessageContentsType {}


Rather than an empty trait, should we just rename CustomOnionMessageContents to OnionMessageContents and impl it for Bolt12/etc? Its already basically what we want - extends Write and has a tlv_type.

Hmmm... we already have an OnionMessageContents enum.

Oh, then lets use that in PendingOnionMessage instead of a generic type T?

It also seems arbitrary that a custom message handler isn't allowed to send BOLT12 messages.

But we don't want a BOLT 12 handler to be able to send arbitrary ones. A custom handler can alway have their type wrap OffersMessage in a variant.

I mean...why not? We could also drop OnionMessageContents or make it priv, and replace most usages with a trait.

Discussed offline and made the following changes:
Renamed OnionMessageContents to ParsedOnionMessageContents and gave it pub(super) visibility
Renamed CustomOnionMessageContents to OnionMessageContents and used it as a trait bound on most methods
Changed Payload to hold T instead of ParsedOnionMessageContents<T> where T: OnionMessageContents
Implemented OnionMessageContents for OffersMessage and ParsedOnionMessageContents. The latter is needed so that arbitrary Payload contents can be read and specific contents can be written

codecov-commenter · 2023-09-19T20:46:51Z

Codecov Report

Attention: 91 lines in your changes are missing coverage. Please review.

Comparison is base (0357caf) 89.04% compared to head (905028b) 88.96%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2578 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87527 87632 +105 Branches 87527 87632 +105 ==========================================
+ Hits 77942 77963 +21 - Misses 7345 7435 +90 + Partials 2240 2234 -6

Files	Coverage Δ
lightning/src/events/mod.rs	`28.97% <ø> (-4.86%)`	⬇️
lightning/src/ln/msgs.rs	`76.81% <ø> (ø)`
lightning/src/offers/offer.rs	`94.65% <100.00%> (+0.01%)`	⬆️
lightning/src/offers/parse.rs	`92.30% <ø> (ø)`
lightning/src/offers/refund.rs	`93.67% <100.00%> (+0.02%)`	⬆️
lightning/src/onion_message/functional_tests.rs	`96.95% <100.00%> (+0.07%)`	⬆️
lightning/src/routing/router.rs	`94.07% <ø> (ø)`
lightning/src/ln/outbound_payment.rs	`87.69% <90.32%> (+0.16%)`	⬆️
lightning/src/ln/peer_handler.rs	`58.79% <25.00%> (-0.10%)`	⬇️
lightning/src/blinded_path/mod.rs	`70.14% <33.33%> (-5.66%)`	⬇️
... and 4 more

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

valentinewallace

Initial look, just nits

valentinewallace · 2023-09-19T20:16:39Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


I don't mind too much, but why remove this?

Restored it but now the test needs to check against InvalidFirstHop, which I'm not sure if that is intended?

Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

Will reexamine this but want to get the other changes pushed for now.

Sure, I'd also be fine with saving this for follow-up if you want to note it in #1970.

Ok, other than the introduction node being wrong, when hardcoding a fix I'm also seeing this logging:
Received an onion message with path_id Some([]) and a reply_path
Instead of the expected:
Received an onion message with path_id None and a reply_path
But I don't understand how my change would affect the path_id. Any ideas?

Oh, nevermind on this. That was just because I had been building using some unpublished commits instead of during the rebase. 🤦‍♂️

Opened #2671

jkczyz · 2023-10-11T14:37:54Z

Rebased as there were a lot of merge conflicts from the last release.

valentinewallace · 2023-10-12T21:28:25Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

jkczyz

Need to look into addressing the fuzz test comment still.

TheBlueMatt · 2023-10-15T15:29:24Z

I think this LGTM, I guess its now based on #2662, but once that lands feel free to squash.

TheBlueMatt · 2023-10-15T19:56:37Z

There's probably gonna be some conflicts between this and #2599

jkczyz · 2023-10-18T19:47:54Z

Speaking of timeouts, we should check if the payment has timed out per the AwaitingInvoice::retry_stragety (assuming its a time-based one) in the timer tick too.

Discussed offline. It would be better to keep the retry strategy separate from when to expire waiting for an invoice.

TheBlueMatt · 2023-10-18T20:15:37Z

Only comment left form my end is #2578 (comment), which you can fix or not, but either way lets squash and I'll ack :)

TheBlueMatt · 2023-10-18T21:13:10Z

Sorry needs a small-ish rebase after #2599.

OnionMessageProvider is a super-trait of OnionMessageHandler, but they don't need to be used separately. Additionally, the former is misplaced in the events module. Remove OnionMessageProvider and add it's only method, next_onion_message_for_peer, into OnionMessageHandler.

OnionMessenger can send onion message responses from its handlers using respond_with_onion_message, which finds a path to the destination and enqueues the response for sending. Generalize this as it can be used not only for responses but for initial sends as well.

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace

LGTM after rebase

Rename CustomOnionMessageContents to OnionMessageContents and use it as a trait bound on messages passed to OnionMessenger methods. This allows using the trait in an upcoming commit as a bound on the contents of PendingOnionMessage. Also, make ParsedOnionMessageContent implement OnionMessageContents so that Payload can be bounded by OnionMessageContents directly, but used when either reading a ParsedOnionMessageContent or writing a specific type of OnionMessageContents (e.g., OffersMessage).

When constructing onion messages to send initially (opposed to replying to one from a handler), the user must construct an OnionMessagePath first before calling OnionMessener::send_onion_message. Additionally, having a reference to OnionMessener isn't always desirable. For instance, in an upcoming commit, ChannelManager will implement OffersMessageHandler, which OnionMessenger needs a reference to. If ChannelManager had a reference to OnionMessenger, too, there would be a dependency cycle. Instead, modify OffersMessageHandler and CustomOnionMessageHandler's interfaces to include a method for releasing pending onion messages. That way, ChannelManager may, for instance, construct and enqueue an InvoiceRequest for sending without needing a reference to OnionMessenger. Additionally, OnionMessenger has responsibility for path finding just as it does when replying to messages from a handler. It performs this when extracting messages from the handlers before returning the next message to send to a peer.

This allows for specifying the introduction node as the message recipient.

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is forgotten. However, this mechanism is insufficient for the Refund scenario, where the Refund's expiration should be used instead. Change AwaitingInvoice to store an absolute expiry instead. When removing stale payments, pass the `SystemTime` in `std` and the highest block time minus two hours in `no-std`.

Add utility functions to ChannelManager for creating OfferBuilder, and RefundBuilder such that derived keys are used for the signing pubkey and payer id, respectively. This allows for stateless verification of any InvoiceRequest and Invoice messages. Later, blinded paths can be included in the returned builders. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

For consistency with other functions and doc cleanliness.

jkczyz · 2023-10-18T23:39:08Z

Sorry needs a small-ish rebase after #2599.

Rebased. Needed to expose ParsedOnionMessageContents because of this.

TheBlueMatt · 2023-10-19T02:41:34Z

+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the
+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].


We need to mention the two-hour thing here, its a bit awkward its buried in the timer_tick_occurred docs. Can happen in a followup, though.

Updated in #2039.

TheBlueMatt · 2023-10-19T03:05:59Z

+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].
+	///


Oh also we should probably say something about how you can use abandon_payment to revoke a refund once issued (if it hasn't been paid). Its somewhat non-intuitive to me that that is true.

Updated in #2039.

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

jkczyz · 2023-09-14T22:44:29Z

Add utility methods to ChannelManager for:

creating OfferBuilder such that derived keys are used for the signing pubkey,
creating RefundBuilder such that derived keys are used for the payer id, and
sending an InvoiceRequest for an Offer such that derived keys are used for the payer id

When the ChannelManager is the payer (i.e., when creating Refund and InvoiceRequest), a PaymentId is required and used for tracking the outbound payment once the Bolt12Invoice is received.

One-hop blinded paths are used throughout until multi-hop blinded paths are supported.

Offer message handling and sending a Bolt12Invoice for a Refund such that derived keys are used for the signing pubkey are in #2039, which is based on this PR.

TheBlueMatt · 2023-09-17T02:18:02Z

+	/// The message contents to send in an [`OnionMessage`].
+	///
+	/// [`OnionMessage`]: crate::ln::msgs::OnionMessage
+	pub contents: T,


Hmm, if we leave a totally unbounded type that's gonna be a problem for bindings. Can we bound this by CustomOnionMessageContents (or if we need a general bound we could create an OnionMessageContents trait that we impl for BOLT12 messages as well)?

We'll need a more general bound since OffersMessage is used, too.

TheBlueMatt · 2023-09-17T02:27:38Z

+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	/// [`InvoiceRequestBuilder`]: crate::offers::invoice_request::InvoiceRequestBuilder
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	pub fn request_invoice(


Does this need to be pub? I'm not sure what the use is for this outside of simply paying an offer, which is presumably a different method.

Ah, this is the "paying for an offer" method. I guess that I can rename it to be more user- rather than implementation-focused.

TheBlueMatt · 2023-09-18T19:36:59Z

 }

+/// A type used within a variant of [`OnionMessageContents`].
+pub trait OnionMessageContentsType {}


Rather than an empty trait, should we just rename CustomOnionMessageContents to OnionMessageContents and impl it for Bolt12/etc? Its already basically what we want - extends Write and has a tlv_type.

Hmmm... we already have an OnionMessageContents enum.

Oh, then lets use that in PendingOnionMessage instead of a generic type T?

It also seems arbitrary that a custom message handler isn't allowed to send BOLT12 messages.

But we don't want a BOLT 12 handler to be able to send arbitrary ones. A custom handler can alway have their type wrap OffersMessage in a variant.

I mean...why not? We could also drop OnionMessageContents or make it priv, and replace most usages with a trait.

Discussed offline and made the following changes:
Renamed OnionMessageContents to ParsedOnionMessageContents and gave it pub(super) visibility
Renamed CustomOnionMessageContents to OnionMessageContents and used it as a trait bound on most methods
Changed Payload to hold T instead of ParsedOnionMessageContents<T> where T: OnionMessageContents
Implemented OnionMessageContents for OffersMessage and ParsedOnionMessageContents. The latter is needed so that arbitrary Payload contents can be read and specific contents can be written

codecov-commenter · 2023-09-19T20:46:51Z

Codecov Report

Attention: 91 lines in your changes are missing coverage. Please review.

Comparison is base (0357caf) 89.04% compared to head (905028b) 88.96%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2578 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87527 87632 +105 Branches 87527 87632 +105 ==========================================
+ Hits 77942 77963 +21 - Misses 7345 7435 +90 + Partials 2240 2234 -6

Files	Coverage Δ
lightning/src/events/mod.rs	`28.97% <ø> (-4.86%)`	⬇️
lightning/src/ln/msgs.rs	`76.81% <ø> (ø)`
lightning/src/offers/offer.rs	`94.65% <100.00%> (+0.01%)`	⬆️
lightning/src/offers/parse.rs	`92.30% <ø> (ø)`
lightning/src/offers/refund.rs	`93.67% <100.00%> (+0.02%)`	⬆️
lightning/src/onion_message/functional_tests.rs	`96.95% <100.00%> (+0.07%)`	⬆️
lightning/src/routing/router.rs	`94.07% <ø> (ø)`
lightning/src/ln/outbound_payment.rs	`87.69% <90.32%> (+0.16%)`	⬆️
lightning/src/ln/peer_handler.rs	`58.79% <25.00%> (-0.10%)`	⬇️
lightning/src/blinded_path/mod.rs	`70.14% <33.33%> (-5.66%)`	⬇️
... and 4 more

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

valentinewallace

Initial look, just nits

valentinewallace · 2023-09-19T20:16:39Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


I don't mind too much, but why remove this?

Restored it but now the test needs to check against InvalidFirstHop, which I'm not sure if that is intended?

Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

Will reexamine this but want to get the other changes pushed for now.

Sure, I'd also be fine with saving this for follow-up if you want to note it in #1970.

Ok, other than the introduction node being wrong, when hardcoding a fix I'm also seeing this logging:
Received an onion message with path_id Some([]) and a reply_path
Instead of the expected:
Received an onion message with path_id None and a reply_path
But I don't understand how my change would affect the path_id. Any ideas?

Oh, nevermind on this. That was just because I had been building using some unpublished commits instead of during the rebase. 🤦‍♂️

Opened #2671

jkczyz · 2023-10-11T14:37:54Z

Rebased as there were a lot of merge conflicts from the last release.

valentinewallace · 2023-10-12T21:28:25Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

jkczyz

Need to look into addressing the fuzz test comment still.

TheBlueMatt · 2023-10-15T15:29:24Z

I think this LGTM, I guess its now based on #2662, but once that lands feel free to squash.

TheBlueMatt · 2023-10-15T19:56:37Z

There's probably gonna be some conflicts between this and #2599

jkczyz · 2023-10-18T19:47:54Z

Speaking of timeouts, we should check if the payment has timed out per the AwaitingInvoice::retry_stragety (assuming its a time-based one) in the timer tick too.

Discussed offline. It would be better to keep the retry strategy separate from when to expire waiting for an invoice.

TheBlueMatt · 2023-10-18T20:15:37Z

Only comment left form my end is #2578 (comment), which you can fix or not, but either way lets squash and I'll ack :)

TheBlueMatt · 2023-10-18T21:13:10Z

Sorry needs a small-ish rebase after #2599.

OnionMessageProvider is a super-trait of OnionMessageHandler, but they don't need to be used separately. Additionally, the former is misplaced in the events module. Remove OnionMessageProvider and add it's only method, next_onion_message_for_peer, into OnionMessageHandler.

OnionMessenger can send onion message responses from its handlers using respond_with_onion_message, which finds a path to the destination and enqueues the response for sending. Generalize this as it can be used not only for responses but for initial sends as well.

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace

LGTM after rebase

Rename CustomOnionMessageContents to OnionMessageContents and use it as a trait bound on messages passed to OnionMessenger methods. This allows using the trait in an upcoming commit as a bound on the contents of PendingOnionMessage. Also, make ParsedOnionMessageContent implement OnionMessageContents so that Payload can be bounded by OnionMessageContents directly, but used when either reading a ParsedOnionMessageContent or writing a specific type of OnionMessageContents (e.g., OffersMessage).

When constructing onion messages to send initially (opposed to replying to one from a handler), the user must construct an OnionMessagePath first before calling OnionMessener::send_onion_message. Additionally, having a reference to OnionMessener isn't always desirable. For instance, in an upcoming commit, ChannelManager will implement OffersMessageHandler, which OnionMessenger needs a reference to. If ChannelManager had a reference to OnionMessenger, too, there would be a dependency cycle. Instead, modify OffersMessageHandler and CustomOnionMessageHandler's interfaces to include a method for releasing pending onion messages. That way, ChannelManager may, for instance, construct and enqueue an InvoiceRequest for sending without needing a reference to OnionMessenger. Additionally, OnionMessenger has responsibility for path finding just as it does when replying to messages from a handler. It performs this when extracting messages from the handlers before returning the next message to send to a peer.

This allows for specifying the introduction node as the message recipient.

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is forgotten. However, this mechanism is insufficient for the Refund scenario, where the Refund's expiration should be used instead. Change AwaitingInvoice to store an absolute expiry instead. When removing stale payments, pass the `SystemTime` in `std` and the highest block time minus two hours in `no-std`.

Add utility functions to ChannelManager for creating OfferBuilder, and RefundBuilder such that derived keys are used for the signing pubkey and payer id, respectively. This allows for stateless verification of any InvoiceRequest and Invoice messages. Later, blinded paths can be included in the returned builders. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

For consistency with other functions and doc cleanliness.

jkczyz · 2023-10-18T23:39:08Z

Sorry needs a small-ish rebase after #2599.

Rebased. Needed to expose ParsedOnionMessageContents because of this.

TheBlueMatt · 2023-10-19T02:41:34Z

+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the
+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].


We need to mention the two-hour thing here, its a bit awkward its buried in the timer_tick_occurred docs. Can happen in a followup, though.

Updated in #2039.

TheBlueMatt · 2023-10-19T03:05:59Z

+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].
+	///


Oh also we should probably say something about how you can use abandon_payment to revoke a refund once issued (if it hasn't been paid). Its somewhat non-intuitive to me that that is true.

Updated in #2039.

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

jkczyz · 2023-09-14T22:44:29Z

Add utility methods to ChannelManager for:

creating OfferBuilder such that derived keys are used for the signing pubkey,
creating RefundBuilder such that derived keys are used for the payer id, and
sending an InvoiceRequest for an Offer such that derived keys are used for the payer id

When the ChannelManager is the payer (i.e., when creating Refund and InvoiceRequest), a PaymentId is required and used for tracking the outbound payment once the Bolt12Invoice is received.

One-hop blinded paths are used throughout until multi-hop blinded paths are supported.

Offer message handling and sending a Bolt12Invoice for a Refund such that derived keys are used for the signing pubkey are in #2039, which is based on this PR.

TheBlueMatt · 2023-09-17T02:18:02Z

+	/// The message contents to send in an [`OnionMessage`].
+	///
+	/// [`OnionMessage`]: crate::ln::msgs::OnionMessage
+	pub contents: T,


Hmm, if we leave a totally unbounded type that's gonna be a problem for bindings. Can we bound this by CustomOnionMessageContents (or if we need a general bound we could create an OnionMessageContents trait that we impl for BOLT12 messages as well)?

We'll need a more general bound since OffersMessage is used, too.

TheBlueMatt · 2023-09-17T02:27:38Z

+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	/// [`InvoiceRequestBuilder`]: crate::offers::invoice_request::InvoiceRequestBuilder
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	pub fn request_invoice(


Does this need to be pub? I'm not sure what the use is for this outside of simply paying an offer, which is presumably a different method.

Ah, this is the "paying for an offer" method. I guess that I can rename it to be more user- rather than implementation-focused.

TheBlueMatt · 2023-09-18T19:36:59Z

 }

+/// A type used within a variant of [`OnionMessageContents`].
+pub trait OnionMessageContentsType {}


Rather than an empty trait, should we just rename CustomOnionMessageContents to OnionMessageContents and impl it for Bolt12/etc? Its already basically what we want - extends Write and has a tlv_type.

Hmmm... we already have an OnionMessageContents enum.

Oh, then lets use that in PendingOnionMessage instead of a generic type T?

It also seems arbitrary that a custom message handler isn't allowed to send BOLT12 messages.

But we don't want a BOLT 12 handler to be able to send arbitrary ones. A custom handler can alway have their type wrap OffersMessage in a variant.

I mean...why not? We could also drop OnionMessageContents or make it priv, and replace most usages with a trait.

Discussed offline and made the following changes:
Renamed OnionMessageContents to ParsedOnionMessageContents and gave it pub(super) visibility
Renamed CustomOnionMessageContents to OnionMessageContents and used it as a trait bound on most methods
Changed Payload to hold T instead of ParsedOnionMessageContents<T> where T: OnionMessageContents
Implemented OnionMessageContents for OffersMessage and ParsedOnionMessageContents. The latter is needed so that arbitrary Payload contents can be read and specific contents can be written

codecov-commenter · 2023-09-19T20:46:51Z

Codecov Report

Attention: 91 lines in your changes are missing coverage. Please review.

Comparison is base (0357caf) 89.04% compared to head (905028b) 88.96%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2578 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87527 87632 +105 Branches 87527 87632 +105 ==========================================
+ Hits 77942 77963 +21 - Misses 7345 7435 +90 + Partials 2240 2234 -6

Files	Coverage Δ
lightning/src/events/mod.rs	`28.97% <ø> (-4.86%)`	⬇️
lightning/src/ln/msgs.rs	`76.81% <ø> (ø)`
lightning/src/offers/offer.rs	`94.65% <100.00%> (+0.01%)`	⬆️
lightning/src/offers/parse.rs	`92.30% <ø> (ø)`
lightning/src/offers/refund.rs	`93.67% <100.00%> (+0.02%)`	⬆️
lightning/src/onion_message/functional_tests.rs	`96.95% <100.00%> (+0.07%)`	⬆️
lightning/src/routing/router.rs	`94.07% <ø> (ø)`
lightning/src/ln/outbound_payment.rs	`87.69% <90.32%> (+0.16%)`	⬆️
lightning/src/ln/peer_handler.rs	`58.79% <25.00%> (-0.10%)`	⬇️
lightning/src/blinded_path/mod.rs	`70.14% <33.33%> (-5.66%)`	⬇️
... and 4 more

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

valentinewallace

Initial look, just nits

valentinewallace · 2023-09-19T20:16:39Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


I don't mind too much, but why remove this?

Restored it but now the test needs to check against InvalidFirstHop, which I'm not sure if that is intended?

Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

Will reexamine this but want to get the other changes pushed for now.

Sure, I'd also be fine with saving this for follow-up if you want to note it in #1970.

Ok, other than the introduction node being wrong, when hardcoding a fix I'm also seeing this logging:
Received an onion message with path_id Some([]) and a reply_path
Instead of the expected:
Received an onion message with path_id None and a reply_path
But I don't understand how my change would affect the path_id. Any ideas?

Oh, nevermind on this. That was just because I had been building using some unpublished commits instead of during the rebase. 🤦‍♂️

Opened #2671

jkczyz · 2023-10-11T14:37:54Z

Rebased as there were a lot of merge conflicts from the last release.

valentinewallace · 2023-10-12T21:28:25Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

jkczyz

Need to look into addressing the fuzz test comment still.

TheBlueMatt · 2023-10-15T15:29:24Z

I think this LGTM, I guess its now based on #2662, but once that lands feel free to squash.

TheBlueMatt · 2023-10-15T19:56:37Z

There's probably gonna be some conflicts between this and #2599

jkczyz · 2023-10-18T19:47:54Z

Speaking of timeouts, we should check if the payment has timed out per the AwaitingInvoice::retry_stragety (assuming its a time-based one) in the timer tick too.

Discussed offline. It would be better to keep the retry strategy separate from when to expire waiting for an invoice.

TheBlueMatt · 2023-10-18T20:15:37Z

Only comment left form my end is #2578 (comment), which you can fix or not, but either way lets squash and I'll ack :)

TheBlueMatt · 2023-10-18T21:13:10Z

Sorry needs a small-ish rebase after #2599.

OnionMessageProvider is a super-trait of OnionMessageHandler, but they don't need to be used separately. Additionally, the former is misplaced in the events module. Remove OnionMessageProvider and add it's only method, next_onion_message_for_peer, into OnionMessageHandler.

OnionMessenger can send onion message responses from its handlers using respond_with_onion_message, which finds a path to the destination and enqueues the response for sending. Generalize this as it can be used not only for responses but for initial sends as well.

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace

LGTM after rebase

Rename CustomOnionMessageContents to OnionMessageContents and use it as a trait bound on messages passed to OnionMessenger methods. This allows using the trait in an upcoming commit as a bound on the contents of PendingOnionMessage. Also, make ParsedOnionMessageContent implement OnionMessageContents so that Payload can be bounded by OnionMessageContents directly, but used when either reading a ParsedOnionMessageContent or writing a specific type of OnionMessageContents (e.g., OffersMessage).

When constructing onion messages to send initially (opposed to replying to one from a handler), the user must construct an OnionMessagePath first before calling OnionMessener::send_onion_message. Additionally, having a reference to OnionMessener isn't always desirable. For instance, in an upcoming commit, ChannelManager will implement OffersMessageHandler, which OnionMessenger needs a reference to. If ChannelManager had a reference to OnionMessenger, too, there would be a dependency cycle. Instead, modify OffersMessageHandler and CustomOnionMessageHandler's interfaces to include a method for releasing pending onion messages. That way, ChannelManager may, for instance, construct and enqueue an InvoiceRequest for sending without needing a reference to OnionMessenger. Additionally, OnionMessenger has responsibility for path finding just as it does when replying to messages from a handler. It performs this when extracting messages from the handlers before returning the next message to send to a peer.

This allows for specifying the introduction node as the message recipient.

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is forgotten. However, this mechanism is insufficient for the Refund scenario, where the Refund's expiration should be used instead. Change AwaitingInvoice to store an absolute expiry instead. When removing stale payments, pass the `SystemTime` in `std` and the highest block time minus two hours in `no-std`.

Add utility functions to ChannelManager for creating OfferBuilder, and RefundBuilder such that derived keys are used for the signing pubkey and payer id, respectively. This allows for stateless verification of any InvoiceRequest and Invoice messages. Later, blinded paths can be included in the returned builders. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

For consistency with other functions and doc cleanliness.

jkczyz · 2023-10-18T23:39:08Z

Sorry needs a small-ish rebase after #2599.

Rebased. Needed to expose ParsedOnionMessageContents because of this.

TheBlueMatt · 2023-10-19T02:41:34Z

+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the
+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].


We need to mention the two-hour thing here, its a bit awkward its buried in the timer_tick_occurred docs. Can happen in a followup, though.

Updated in #2039.

TheBlueMatt · 2023-10-19T03:05:59Z

+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].
+	///


Oh also we should probably say something about how you can use abandon_payment to revoke a refund once issued (if it hasn't been paid). Its somewhat non-intuitive to me that that is true.

Updated in #2039.

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

jkczyz · 2023-09-14T22:44:29Z

Add utility methods to ChannelManager for:

creating OfferBuilder such that derived keys are used for the signing pubkey,
creating RefundBuilder such that derived keys are used for the payer id, and
sending an InvoiceRequest for an Offer such that derived keys are used for the payer id

When the ChannelManager is the payer (i.e., when creating Refund and InvoiceRequest), a PaymentId is required and used for tracking the outbound payment once the Bolt12Invoice is received.

One-hop blinded paths are used throughout until multi-hop blinded paths are supported.

Offer message handling and sending a Bolt12Invoice for a Refund such that derived keys are used for the signing pubkey are in #2039, which is based on this PR.

TheBlueMatt · 2023-09-17T02:18:02Z

+	/// The message contents to send in an [`OnionMessage`].
+	///
+	/// [`OnionMessage`]: crate::ln::msgs::OnionMessage
+	pub contents: T,


Hmm, if we leave a totally unbounded type that's gonna be a problem for bindings. Can we bound this by CustomOnionMessageContents (or if we need a general bound we could create an OnionMessageContents trait that we impl for BOLT12 messages as well)?

We'll need a more general bound since OffersMessage is used, too.

TheBlueMatt · 2023-09-17T02:27:38Z

+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	/// [`InvoiceRequestBuilder`]: crate::offers::invoice_request::InvoiceRequestBuilder
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	pub fn request_invoice(


Does this need to be pub? I'm not sure what the use is for this outside of simply paying an offer, which is presumably a different method.

Ah, this is the "paying for an offer" method. I guess that I can rename it to be more user- rather than implementation-focused.

TheBlueMatt · 2023-09-18T19:36:59Z

 }

+/// A type used within a variant of [`OnionMessageContents`].
+pub trait OnionMessageContentsType {}


Rather than an empty trait, should we just rename CustomOnionMessageContents to OnionMessageContents and impl it for Bolt12/etc? Its already basically what we want - extends Write and has a tlv_type.

Hmmm... we already have an OnionMessageContents enum.

Oh, then lets use that in PendingOnionMessage instead of a generic type T?

It also seems arbitrary that a custom message handler isn't allowed to send BOLT12 messages.

But we don't want a BOLT 12 handler to be able to send arbitrary ones. A custom handler can alway have their type wrap OffersMessage in a variant.

I mean...why not? We could also drop OnionMessageContents or make it priv, and replace most usages with a trait.

Discussed offline and made the following changes:
Renamed OnionMessageContents to ParsedOnionMessageContents and gave it pub(super) visibility
Renamed CustomOnionMessageContents to OnionMessageContents and used it as a trait bound on most methods
Changed Payload to hold T instead of ParsedOnionMessageContents<T> where T: OnionMessageContents
Implemented OnionMessageContents for OffersMessage and ParsedOnionMessageContents. The latter is needed so that arbitrary Payload contents can be read and specific contents can be written

codecov-commenter · 2023-09-19T20:46:51Z

Codecov Report

Attention: 91 lines in your changes are missing coverage. Please review.

Comparison is base (0357caf) 89.04% compared to head (905028b) 88.96%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2578 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87527 87632 +105 Branches 87527 87632 +105 ==========================================
+ Hits 77942 77963 +21 - Misses 7345 7435 +90 + Partials 2240 2234 -6

Files	Coverage Δ
lightning/src/events/mod.rs	`28.97% <ø> (-4.86%)`	⬇️
lightning/src/ln/msgs.rs	`76.81% <ø> (ø)`
lightning/src/offers/offer.rs	`94.65% <100.00%> (+0.01%)`	⬆️
lightning/src/offers/parse.rs	`92.30% <ø> (ø)`
lightning/src/offers/refund.rs	`93.67% <100.00%> (+0.02%)`	⬆️
lightning/src/onion_message/functional_tests.rs	`96.95% <100.00%> (+0.07%)`	⬆️
lightning/src/routing/router.rs	`94.07% <ø> (ø)`
lightning/src/ln/outbound_payment.rs	`87.69% <90.32%> (+0.16%)`	⬆️
lightning/src/ln/peer_handler.rs	`58.79% <25.00%> (-0.10%)`	⬇️
lightning/src/blinded_path/mod.rs	`70.14% <33.33%> (-5.66%)`	⬇️
... and 4 more

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

valentinewallace

Initial look, just nits

valentinewallace · 2023-09-19T20:16:39Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


I don't mind too much, but why remove this?

Restored it but now the test needs to check against InvalidFirstHop, which I'm not sure if that is intended?

Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

Will reexamine this but want to get the other changes pushed for now.

Sure, I'd also be fine with saving this for follow-up if you want to note it in #1970.

Ok, other than the introduction node being wrong, when hardcoding a fix I'm also seeing this logging:
Received an onion message with path_id Some([]) and a reply_path
Instead of the expected:
Received an onion message with path_id None and a reply_path
But I don't understand how my change would affect the path_id. Any ideas?

Oh, nevermind on this. That was just because I had been building using some unpublished commits instead of during the rebase. 🤦‍♂️

Opened #2671

jkczyz · 2023-10-11T14:37:54Z

Rebased as there were a lot of merge conflicts from the last release.

valentinewallace · 2023-10-12T21:28:25Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

jkczyz

Need to look into addressing the fuzz test comment still.

TheBlueMatt · 2023-10-15T15:29:24Z

I think this LGTM, I guess its now based on #2662, but once that lands feel free to squash.

TheBlueMatt · 2023-10-15T19:56:37Z

There's probably gonna be some conflicts between this and #2599

jkczyz · 2023-10-18T19:47:54Z

Speaking of timeouts, we should check if the payment has timed out per the AwaitingInvoice::retry_stragety (assuming its a time-based one) in the timer tick too.

Discussed offline. It would be better to keep the retry strategy separate from when to expire waiting for an invoice.

TheBlueMatt · 2023-10-18T20:15:37Z

Only comment left form my end is #2578 (comment), which you can fix or not, but either way lets squash and I'll ack :)

TheBlueMatt · 2023-10-18T21:13:10Z

Sorry needs a small-ish rebase after #2599.

OnionMessageProvider is a super-trait of OnionMessageHandler, but they don't need to be used separately. Additionally, the former is misplaced in the events module. Remove OnionMessageProvider and add it's only method, next_onion_message_for_peer, into OnionMessageHandler.

OnionMessenger can send onion message responses from its handlers using respond_with_onion_message, which finds a path to the destination and enqueues the response for sending. Generalize this as it can be used not only for responses but for initial sends as well.

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace

LGTM after rebase

Rename CustomOnionMessageContents to OnionMessageContents and use it as a trait bound on messages passed to OnionMessenger methods. This allows using the trait in an upcoming commit as a bound on the contents of PendingOnionMessage. Also, make ParsedOnionMessageContent implement OnionMessageContents so that Payload can be bounded by OnionMessageContents directly, but used when either reading a ParsedOnionMessageContent or writing a specific type of OnionMessageContents (e.g., OffersMessage).

When constructing onion messages to send initially (opposed to replying to one from a handler), the user must construct an OnionMessagePath first before calling OnionMessener::send_onion_message. Additionally, having a reference to OnionMessener isn't always desirable. For instance, in an upcoming commit, ChannelManager will implement OffersMessageHandler, which OnionMessenger needs a reference to. If ChannelManager had a reference to OnionMessenger, too, there would be a dependency cycle. Instead, modify OffersMessageHandler and CustomOnionMessageHandler's interfaces to include a method for releasing pending onion messages. That way, ChannelManager may, for instance, construct and enqueue an InvoiceRequest for sending without needing a reference to OnionMessenger. Additionally, OnionMessenger has responsibility for path finding just as it does when replying to messages from a handler. It performs this when extracting messages from the handlers before returning the next message to send to a peer.

This allows for specifying the introduction node as the message recipient.

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is forgotten. However, this mechanism is insufficient for the Refund scenario, where the Refund's expiration should be used instead. Change AwaitingInvoice to store an absolute expiry instead. When removing stale payments, pass the `SystemTime` in `std` and the highest block time minus two hours in `no-std`.

Add utility functions to ChannelManager for creating OfferBuilder, and RefundBuilder such that derived keys are used for the signing pubkey and payer id, respectively. This allows for stateless verification of any InvoiceRequest and Invoice messages. Later, blinded paths can be included in the returned builders. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

For consistency with other functions and doc cleanliness.

jkczyz · 2023-10-18T23:39:08Z

Sorry needs a small-ish rebase after #2599.

Rebased. Needed to expose ParsedOnionMessageContents because of this.

TheBlueMatt · 2023-10-19T02:41:34Z

+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the
+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].


We need to mention the two-hour thing here, its a bit awkward its buried in the timer_tick_occurred docs. Can happen in a followup, though.

Updated in #2039.

TheBlueMatt · 2023-10-19T03:05:59Z

+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].
+	///


Oh also we should probably say something about how you can use abandon_payment to revoke a refund once issued (if it hasn't been paid). Its somewhat non-intuitive to me that that is true.

Updated in #2039.

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

jkczyz · 2023-09-14T22:44:29Z

Add utility methods to ChannelManager for:

creating OfferBuilder such that derived keys are used for the signing pubkey,
creating RefundBuilder such that derived keys are used for the payer id, and
sending an InvoiceRequest for an Offer such that derived keys are used for the payer id

When the ChannelManager is the payer (i.e., when creating Refund and InvoiceRequest), a PaymentId is required and used for tracking the outbound payment once the Bolt12Invoice is received.

One-hop blinded paths are used throughout until multi-hop blinded paths are supported.

Offer message handling and sending a Bolt12Invoice for a Refund such that derived keys are used for the signing pubkey are in #2039, which is based on this PR.

TheBlueMatt · 2023-09-17T02:18:02Z

+	/// The message contents to send in an [`OnionMessage`].
+	///
+	/// [`OnionMessage`]: crate::ln::msgs::OnionMessage
+	pub contents: T,


Hmm, if we leave a totally unbounded type that's gonna be a problem for bindings. Can we bound this by CustomOnionMessageContents (or if we need a general bound we could create an OnionMessageContents trait that we impl for BOLT12 messages as well)?

We'll need a more general bound since OffersMessage is used, too.

TheBlueMatt · 2023-09-17T02:27:38Z

+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	/// [`InvoiceRequestBuilder`]: crate::offers::invoice_request::InvoiceRequestBuilder
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	pub fn request_invoice(


Does this need to be pub? I'm not sure what the use is for this outside of simply paying an offer, which is presumably a different method.

Ah, this is the "paying for an offer" method. I guess that I can rename it to be more user- rather than implementation-focused.

TheBlueMatt · 2023-09-18T19:36:59Z

 }

+/// A type used within a variant of [`OnionMessageContents`].
+pub trait OnionMessageContentsType {}


Rather than an empty trait, should we just rename CustomOnionMessageContents to OnionMessageContents and impl it for Bolt12/etc? Its already basically what we want - extends Write and has a tlv_type.

Hmmm... we already have an OnionMessageContents enum.

Oh, then lets use that in PendingOnionMessage instead of a generic type T?

It also seems arbitrary that a custom message handler isn't allowed to send BOLT12 messages.

But we don't want a BOLT 12 handler to be able to send arbitrary ones. A custom handler can alway have their type wrap OffersMessage in a variant.

I mean...why not? We could also drop OnionMessageContents or make it priv, and replace most usages with a trait.

Discussed offline and made the following changes:
Renamed OnionMessageContents to ParsedOnionMessageContents and gave it pub(super) visibility
Renamed CustomOnionMessageContents to OnionMessageContents and used it as a trait bound on most methods
Changed Payload to hold T instead of ParsedOnionMessageContents<T> where T: OnionMessageContents
Implemented OnionMessageContents for OffersMessage and ParsedOnionMessageContents. The latter is needed so that arbitrary Payload contents can be read and specific contents can be written

codecov-commenter · 2023-09-19T20:46:51Z

Codecov Report

Attention: 91 lines in your changes are missing coverage. Please review.

Comparison is base (0357caf) 89.04% compared to head (905028b) 88.96%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2578 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87527 87632 +105 Branches 87527 87632 +105 ==========================================
+ Hits 77942 77963 +21 - Misses 7345 7435 +90 + Partials 2240 2234 -6

Files	Coverage Δ
lightning/src/events/mod.rs	`28.97% <ø> (-4.86%)`	⬇️
lightning/src/ln/msgs.rs	`76.81% <ø> (ø)`
lightning/src/offers/offer.rs	`94.65% <100.00%> (+0.01%)`	⬆️
lightning/src/offers/parse.rs	`92.30% <ø> (ø)`
lightning/src/offers/refund.rs	`93.67% <100.00%> (+0.02%)`	⬆️
lightning/src/onion_message/functional_tests.rs	`96.95% <100.00%> (+0.07%)`	⬆️
lightning/src/routing/router.rs	`94.07% <ø> (ø)`
lightning/src/ln/outbound_payment.rs	`87.69% <90.32%> (+0.16%)`	⬆️
lightning/src/ln/peer_handler.rs	`58.79% <25.00%> (-0.10%)`	⬇️
lightning/src/blinded_path/mod.rs	`70.14% <33.33%> (-5.66%)`	⬇️
... and 4 more

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

valentinewallace

Initial look, just nits

valentinewallace · 2023-09-19T20:16:39Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


I don't mind too much, but why remove this?

Restored it but now the test needs to check against InvalidFirstHop, which I'm not sure if that is intended?

Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

Will reexamine this but want to get the other changes pushed for now.

Sure, I'd also be fine with saving this for follow-up if you want to note it in #1970.

Ok, other than the introduction node being wrong, when hardcoding a fix I'm also seeing this logging:
Received an onion message with path_id Some([]) and a reply_path
Instead of the expected:
Received an onion message with path_id None and a reply_path
But I don't understand how my change would affect the path_id. Any ideas?

Oh, nevermind on this. That was just because I had been building using some unpublished commits instead of during the rebase. 🤦‍♂️

Opened #2671

jkczyz · 2023-10-11T14:37:54Z

Rebased as there were a lot of merge conflicts from the last release.

valentinewallace · 2023-10-12T21:28:25Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

jkczyz

Need to look into addressing the fuzz test comment still.

TheBlueMatt · 2023-10-15T15:29:24Z

I think this LGTM, I guess its now based on #2662, but once that lands feel free to squash.

TheBlueMatt · 2023-10-15T19:56:37Z

There's probably gonna be some conflicts between this and #2599

jkczyz · 2023-10-18T19:47:54Z

Speaking of timeouts, we should check if the payment has timed out per the AwaitingInvoice::retry_stragety (assuming its a time-based one) in the timer tick too.

Discussed offline. It would be better to keep the retry strategy separate from when to expire waiting for an invoice.

TheBlueMatt · 2023-10-18T20:15:37Z

Only comment left form my end is #2578 (comment), which you can fix or not, but either way lets squash and I'll ack :)

TheBlueMatt · 2023-10-18T21:13:10Z

Sorry needs a small-ish rebase after #2599.

OnionMessageProvider is a super-trait of OnionMessageHandler, but they don't need to be used separately. Additionally, the former is misplaced in the events module. Remove OnionMessageProvider and add it's only method, next_onion_message_for_peer, into OnionMessageHandler.

OnionMessenger can send onion message responses from its handlers using respond_with_onion_message, which finds a path to the destination and enqueues the response for sending. Generalize this as it can be used not only for responses but for initial sends as well.

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace

LGTM after rebase

Rename CustomOnionMessageContents to OnionMessageContents and use it as a trait bound on messages passed to OnionMessenger methods. This allows using the trait in an upcoming commit as a bound on the contents of PendingOnionMessage. Also, make ParsedOnionMessageContent implement OnionMessageContents so that Payload can be bounded by OnionMessageContents directly, but used when either reading a ParsedOnionMessageContent or writing a specific type of OnionMessageContents (e.g., OffersMessage).

When constructing onion messages to send initially (opposed to replying to one from a handler), the user must construct an OnionMessagePath first before calling OnionMessener::send_onion_message. Additionally, having a reference to OnionMessener isn't always desirable. For instance, in an upcoming commit, ChannelManager will implement OffersMessageHandler, which OnionMessenger needs a reference to. If ChannelManager had a reference to OnionMessenger, too, there would be a dependency cycle. Instead, modify OffersMessageHandler and CustomOnionMessageHandler's interfaces to include a method for releasing pending onion messages. That way, ChannelManager may, for instance, construct and enqueue an InvoiceRequest for sending without needing a reference to OnionMessenger. Additionally, OnionMessenger has responsibility for path finding just as it does when replying to messages from a handler. It performs this when extracting messages from the handlers before returning the next message to send to a peer.

This allows for specifying the introduction node as the message recipient.

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is forgotten. However, this mechanism is insufficient for the Refund scenario, where the Refund's expiration should be used instead. Change AwaitingInvoice to store an absolute expiry instead. When removing stale payments, pass the `SystemTime` in `std` and the highest block time minus two hours in `no-std`.

Add utility functions to ChannelManager for creating OfferBuilder, and RefundBuilder such that derived keys are used for the signing pubkey and payer id, respectively. This allows for stateless verification of any InvoiceRequest and Invoice messages. Later, blinded paths can be included in the returned builders. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

For consistency with other functions and doc cleanliness.

jkczyz · 2023-10-18T23:39:08Z

Sorry needs a small-ish rebase after #2599.

Rebased. Needed to expose ParsedOnionMessageContents because of this.

TheBlueMatt · 2023-10-19T02:41:34Z

+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the
+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].


We need to mention the two-hour thing here, its a bit awkward its buried in the timer_tick_occurred docs. Can happen in a followup, though.

Updated in #2039.

TheBlueMatt · 2023-10-19T03:05:59Z

+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].
+	///


Oh also we should probably say something about how you can use abandon_payment to revoke a refund once issued (if it hasn't been paid). Its somewhat non-intuitive to me that that is true.

Updated in #2039.

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

jkczyz · 2023-09-14T22:44:29Z

Add utility methods to ChannelManager for:

creating OfferBuilder such that derived keys are used for the signing pubkey,
creating RefundBuilder such that derived keys are used for the payer id, and
sending an InvoiceRequest for an Offer such that derived keys are used for the payer id

When the ChannelManager is the payer (i.e., when creating Refund and InvoiceRequest), a PaymentId is required and used for tracking the outbound payment once the Bolt12Invoice is received.

One-hop blinded paths are used throughout until multi-hop blinded paths are supported.

Offer message handling and sending a Bolt12Invoice for a Refund such that derived keys are used for the signing pubkey are in #2039, which is based on this PR.

TheBlueMatt · 2023-09-17T02:18:02Z

+	/// The message contents to send in an [`OnionMessage`].
+	///
+	/// [`OnionMessage`]: crate::ln::msgs::OnionMessage
+	pub contents: T,


Hmm, if we leave a totally unbounded type that's gonna be a problem for bindings. Can we bound this by CustomOnionMessageContents (or if we need a general bound we could create an OnionMessageContents trait that we impl for BOLT12 messages as well)?

We'll need a more general bound since OffersMessage is used, too.

TheBlueMatt · 2023-09-17T02:27:38Z

+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	/// [`InvoiceRequestBuilder`]: crate::offers::invoice_request::InvoiceRequestBuilder
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	pub fn request_invoice(


Does this need to be pub? I'm not sure what the use is for this outside of simply paying an offer, which is presumably a different method.

Ah, this is the "paying for an offer" method. I guess that I can rename it to be more user- rather than implementation-focused.

TheBlueMatt · 2023-09-18T19:36:59Z

 }

+/// A type used within a variant of [`OnionMessageContents`].
+pub trait OnionMessageContentsType {}


Rather than an empty trait, should we just rename CustomOnionMessageContents to OnionMessageContents and impl it for Bolt12/etc? Its already basically what we want - extends Write and has a tlv_type.

Hmmm... we already have an OnionMessageContents enum.

Oh, then lets use that in PendingOnionMessage instead of a generic type T?

It also seems arbitrary that a custom message handler isn't allowed to send BOLT12 messages.

But we don't want a BOLT 12 handler to be able to send arbitrary ones. A custom handler can alway have their type wrap OffersMessage in a variant.

I mean...why not? We could also drop OnionMessageContents or make it priv, and replace most usages with a trait.

Discussed offline and made the following changes:
Renamed OnionMessageContents to ParsedOnionMessageContents and gave it pub(super) visibility
Renamed CustomOnionMessageContents to OnionMessageContents and used it as a trait bound on most methods
Changed Payload to hold T instead of ParsedOnionMessageContents<T> where T: OnionMessageContents
Implemented OnionMessageContents for OffersMessage and ParsedOnionMessageContents. The latter is needed so that arbitrary Payload contents can be read and specific contents can be written

codecov-commenter · 2023-09-19T20:46:51Z

Codecov Report

Attention: 91 lines in your changes are missing coverage. Please review.

Comparison is base (0357caf) 89.04% compared to head (905028b) 88.96%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2578 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87527 87632 +105 Branches 87527 87632 +105 ==========================================
+ Hits 77942 77963 +21 - Misses 7345 7435 +90 + Partials 2240 2234 -6

Files	Coverage Δ
lightning/src/events/mod.rs	`28.97% <ø> (-4.86%)`	⬇️
lightning/src/ln/msgs.rs	`76.81% <ø> (ø)`
lightning/src/offers/offer.rs	`94.65% <100.00%> (+0.01%)`	⬆️
lightning/src/offers/parse.rs	`92.30% <ø> (ø)`
lightning/src/offers/refund.rs	`93.67% <100.00%> (+0.02%)`	⬆️
lightning/src/onion_message/functional_tests.rs	`96.95% <100.00%> (+0.07%)`	⬆️
lightning/src/routing/router.rs	`94.07% <ø> (ø)`
lightning/src/ln/outbound_payment.rs	`87.69% <90.32%> (+0.16%)`	⬆️
lightning/src/ln/peer_handler.rs	`58.79% <25.00%> (-0.10%)`	⬇️
lightning/src/blinded_path/mod.rs	`70.14% <33.33%> (-5.66%)`	⬇️
... and 4 more

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

valentinewallace

Initial look, just nits

valentinewallace · 2023-09-19T20:16:39Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


I don't mind too much, but why remove this?

Restored it but now the test needs to check against InvalidFirstHop, which I'm not sure if that is intended?

Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

Will reexamine this but want to get the other changes pushed for now.

Sure, I'd also be fine with saving this for follow-up if you want to note it in #1970.

Ok, other than the introduction node being wrong, when hardcoding a fix I'm also seeing this logging:
Received an onion message with path_id Some([]) and a reply_path
Instead of the expected:
Received an onion message with path_id None and a reply_path
But I don't understand how my change would affect the path_id. Any ideas?

Oh, nevermind on this. That was just because I had been building using some unpublished commits instead of during the rebase. 🤦‍♂️

Opened #2671

jkczyz · 2023-10-11T14:37:54Z

Rebased as there were a lot of merge conflicts from the last release.

valentinewallace · 2023-10-12T21:28:25Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

jkczyz

Need to look into addressing the fuzz test comment still.

TheBlueMatt · 2023-10-15T15:29:24Z

I think this LGTM, I guess its now based on #2662, but once that lands feel free to squash.

TheBlueMatt · 2023-10-15T19:56:37Z

There's probably gonna be some conflicts between this and #2599

jkczyz · 2023-10-18T19:47:54Z

Speaking of timeouts, we should check if the payment has timed out per the AwaitingInvoice::retry_stragety (assuming its a time-based one) in the timer tick too.

Discussed offline. It would be better to keep the retry strategy separate from when to expire waiting for an invoice.

TheBlueMatt · 2023-10-18T20:15:37Z

Only comment left form my end is #2578 (comment), which you can fix or not, but either way lets squash and I'll ack :)

TheBlueMatt · 2023-10-18T21:13:10Z

Sorry needs a small-ish rebase after #2599.

OnionMessageProvider is a super-trait of OnionMessageHandler, but they don't need to be used separately. Additionally, the former is misplaced in the events module. Remove OnionMessageProvider and add it's only method, next_onion_message_for_peer, into OnionMessageHandler.

OnionMessenger can send onion message responses from its handlers using respond_with_onion_message, which finds a path to the destination and enqueues the response for sending. Generalize this as it can be used not only for responses but for initial sends as well.

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace

LGTM after rebase

Rename CustomOnionMessageContents to OnionMessageContents and use it as a trait bound on messages passed to OnionMessenger methods. This allows using the trait in an upcoming commit as a bound on the contents of PendingOnionMessage. Also, make ParsedOnionMessageContent implement OnionMessageContents so that Payload can be bounded by OnionMessageContents directly, but used when either reading a ParsedOnionMessageContent or writing a specific type of OnionMessageContents (e.g., OffersMessage).

When constructing onion messages to send initially (opposed to replying to one from a handler), the user must construct an OnionMessagePath first before calling OnionMessener::send_onion_message. Additionally, having a reference to OnionMessener isn't always desirable. For instance, in an upcoming commit, ChannelManager will implement OffersMessageHandler, which OnionMessenger needs a reference to. If ChannelManager had a reference to OnionMessenger, too, there would be a dependency cycle. Instead, modify OffersMessageHandler and CustomOnionMessageHandler's interfaces to include a method for releasing pending onion messages. That way, ChannelManager may, for instance, construct and enqueue an InvoiceRequest for sending without needing a reference to OnionMessenger. Additionally, OnionMessenger has responsibility for path finding just as it does when replying to messages from a handler. It performs this when extracting messages from the handlers before returning the next message to send to a peer.

This allows for specifying the introduction node as the message recipient.

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is forgotten. However, this mechanism is insufficient for the Refund scenario, where the Refund's expiration should be used instead. Change AwaitingInvoice to store an absolute expiry instead. When removing stale payments, pass the `SystemTime` in `std` and the highest block time minus two hours in `no-std`.

Add utility functions to ChannelManager for creating OfferBuilder, and RefundBuilder such that derived keys are used for the signing pubkey and payer id, respectively. This allows for stateless verification of any InvoiceRequest and Invoice messages. Later, blinded paths can be included in the returned builders. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

For consistency with other functions and doc cleanliness.

jkczyz · 2023-10-18T23:39:08Z

Sorry needs a small-ish rebase after #2599.

Rebased. Needed to expose ParsedOnionMessageContents because of this.

TheBlueMatt · 2023-10-19T02:41:34Z

+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the
+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].


We need to mention the two-hour thing here, its a bit awkward its buried in the timer_tick_occurred docs. Can happen in a followup, though.

Updated in #2039.

TheBlueMatt · 2023-10-19T03:05:59Z

+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].
+	///


Oh also we should probably say something about how you can use abandon_payment to revoke a refund once issued (if it hasn't been paid). Its somewhat non-intuitive to me that that is true.

Updated in #2039.

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

jkczyz · 2023-09-14T22:44:29Z

Add utility methods to ChannelManager for:

creating OfferBuilder such that derived keys are used for the signing pubkey,
creating RefundBuilder such that derived keys are used for the payer id, and
sending an InvoiceRequest for an Offer such that derived keys are used for the payer id

When the ChannelManager is the payer (i.e., when creating Refund and InvoiceRequest), a PaymentId is required and used for tracking the outbound payment once the Bolt12Invoice is received.

One-hop blinded paths are used throughout until multi-hop blinded paths are supported.

Offer message handling and sending a Bolt12Invoice for a Refund such that derived keys are used for the signing pubkey are in #2039, which is based on this PR.

TheBlueMatt · 2023-09-17T02:18:02Z

+	/// The message contents to send in an [`OnionMessage`].
+	///
+	/// [`OnionMessage`]: crate::ln::msgs::OnionMessage
+	pub contents: T,


Hmm, if we leave a totally unbounded type that's gonna be a problem for bindings. Can we bound this by CustomOnionMessageContents (or if we need a general bound we could create an OnionMessageContents trait that we impl for BOLT12 messages as well)?

We'll need a more general bound since OffersMessage is used, too.

TheBlueMatt · 2023-09-17T02:27:38Z

+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	/// [`InvoiceRequestBuilder`]: crate::offers::invoice_request::InvoiceRequestBuilder
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	pub fn request_invoice(


Does this need to be pub? I'm not sure what the use is for this outside of simply paying an offer, which is presumably a different method.

Ah, this is the "paying for an offer" method. I guess that I can rename it to be more user- rather than implementation-focused.

TheBlueMatt · 2023-09-18T19:36:59Z

 }

+/// A type used within a variant of [`OnionMessageContents`].
+pub trait OnionMessageContentsType {}


Rather than an empty trait, should we just rename CustomOnionMessageContents to OnionMessageContents and impl it for Bolt12/etc? Its already basically what we want - extends Write and has a tlv_type.

Hmmm... we already have an OnionMessageContents enum.

Oh, then lets use that in PendingOnionMessage instead of a generic type T?

It also seems arbitrary that a custom message handler isn't allowed to send BOLT12 messages.

But we don't want a BOLT 12 handler to be able to send arbitrary ones. A custom handler can alway have their type wrap OffersMessage in a variant.

I mean...why not? We could also drop OnionMessageContents or make it priv, and replace most usages with a trait.

Discussed offline and made the following changes:
Renamed OnionMessageContents to ParsedOnionMessageContents and gave it pub(super) visibility
Renamed CustomOnionMessageContents to OnionMessageContents and used it as a trait bound on most methods
Changed Payload to hold T instead of ParsedOnionMessageContents<T> where T: OnionMessageContents
Implemented OnionMessageContents for OffersMessage and ParsedOnionMessageContents. The latter is needed so that arbitrary Payload contents can be read and specific contents can be written

codecov-commenter · 2023-09-19T20:46:51Z

Codecov Report

Attention: 91 lines in your changes are missing coverage. Please review.

Comparison is base (0357caf) 89.04% compared to head (905028b) 88.96%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2578 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87527 87632 +105 Branches 87527 87632 +105 ==========================================
+ Hits 77942 77963 +21 - Misses 7345 7435 +90 + Partials 2240 2234 -6

Files	Coverage Δ
lightning/src/events/mod.rs	`28.97% <ø> (-4.86%)`	⬇️
lightning/src/ln/msgs.rs	`76.81% <ø> (ø)`
lightning/src/offers/offer.rs	`94.65% <100.00%> (+0.01%)`	⬆️
lightning/src/offers/parse.rs	`92.30% <ø> (ø)`
lightning/src/offers/refund.rs	`93.67% <100.00%> (+0.02%)`	⬆️
lightning/src/onion_message/functional_tests.rs	`96.95% <100.00%> (+0.07%)`	⬆️
lightning/src/routing/router.rs	`94.07% <ø> (ø)`
lightning/src/ln/outbound_payment.rs	`87.69% <90.32%> (+0.16%)`	⬆️
lightning/src/ln/peer_handler.rs	`58.79% <25.00%> (-0.10%)`	⬇️
lightning/src/blinded_path/mod.rs	`70.14% <33.33%> (-5.66%)`	⬇️
... and 4 more

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

valentinewallace

Initial look, just nits

valentinewallace · 2023-09-19T20:16:39Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


I don't mind too much, but why remove this?

Restored it but now the test needs to check against InvalidFirstHop, which I'm not sure if that is intended?

Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

Will reexamine this but want to get the other changes pushed for now.

Sure, I'd also be fine with saving this for follow-up if you want to note it in #1970.

Ok, other than the introduction node being wrong, when hardcoding a fix I'm also seeing this logging:
Received an onion message with path_id Some([]) and a reply_path
Instead of the expected:
Received an onion message with path_id None and a reply_path
But I don't understand how my change would affect the path_id. Any ideas?

Oh, nevermind on this. That was just because I had been building using some unpublished commits instead of during the rebase. 🤦‍♂️

Opened #2671

jkczyz · 2023-10-11T14:37:54Z

Rebased as there were a lot of merge conflicts from the last release.

valentinewallace · 2023-10-12T21:28:25Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

jkczyz

Need to look into addressing the fuzz test comment still.

TheBlueMatt · 2023-10-15T15:29:24Z

I think this LGTM, I guess its now based on #2662, but once that lands feel free to squash.

TheBlueMatt · 2023-10-15T19:56:37Z

There's probably gonna be some conflicts between this and #2599

jkczyz · 2023-10-18T19:47:54Z

Speaking of timeouts, we should check if the payment has timed out per the AwaitingInvoice::retry_stragety (assuming its a time-based one) in the timer tick too.

Discussed offline. It would be better to keep the retry strategy separate from when to expire waiting for an invoice.

TheBlueMatt · 2023-10-18T20:15:37Z

Only comment left form my end is #2578 (comment), which you can fix or not, but either way lets squash and I'll ack :)

TheBlueMatt · 2023-10-18T21:13:10Z

Sorry needs a small-ish rebase after #2599.

OnionMessageProvider is a super-trait of OnionMessageHandler, but they don't need to be used separately. Additionally, the former is misplaced in the events module. Remove OnionMessageProvider and add it's only method, next_onion_message_for_peer, into OnionMessageHandler.

OnionMessenger can send onion message responses from its handlers using respond_with_onion_message, which finds a path to the destination and enqueues the response for sending. Generalize this as it can be used not only for responses but for initial sends as well.

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace

LGTM after rebase

Rename CustomOnionMessageContents to OnionMessageContents and use it as a trait bound on messages passed to OnionMessenger methods. This allows using the trait in an upcoming commit as a bound on the contents of PendingOnionMessage. Also, make ParsedOnionMessageContent implement OnionMessageContents so that Payload can be bounded by OnionMessageContents directly, but used when either reading a ParsedOnionMessageContent or writing a specific type of OnionMessageContents (e.g., OffersMessage).

When constructing onion messages to send initially (opposed to replying to one from a handler), the user must construct an OnionMessagePath first before calling OnionMessener::send_onion_message. Additionally, having a reference to OnionMessener isn't always desirable. For instance, in an upcoming commit, ChannelManager will implement OffersMessageHandler, which OnionMessenger needs a reference to. If ChannelManager had a reference to OnionMessenger, too, there would be a dependency cycle. Instead, modify OffersMessageHandler and CustomOnionMessageHandler's interfaces to include a method for releasing pending onion messages. That way, ChannelManager may, for instance, construct and enqueue an InvoiceRequest for sending without needing a reference to OnionMessenger. Additionally, OnionMessenger has responsibility for path finding just as it does when replying to messages from a handler. It performs this when extracting messages from the handlers before returning the next message to send to a peer.

This allows for specifying the introduction node as the message recipient.

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is forgotten. However, this mechanism is insufficient for the Refund scenario, where the Refund's expiration should be used instead. Change AwaitingInvoice to store an absolute expiry instead. When removing stale payments, pass the `SystemTime` in `std` and the highest block time minus two hours in `no-std`.

Add utility functions to ChannelManager for creating OfferBuilder, and RefundBuilder such that derived keys are used for the signing pubkey and payer id, respectively. This allows for stateless verification of any InvoiceRequest and Invoice messages. Later, blinded paths can be included in the returned builders. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

For consistency with other functions and doc cleanliness.

jkczyz · 2023-10-18T23:39:08Z

Sorry needs a small-ish rebase after #2599.

Rebased. Needed to expose ParsedOnionMessageContents because of this.

TheBlueMatt · 2023-10-19T02:41:34Z

+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the
+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].


We need to mention the two-hour thing here, its a bit awkward its buried in the timer_tick_occurred docs. Can happen in a followup, though.

Updated in #2039.

TheBlueMatt · 2023-10-19T03:05:59Z

+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].
+	///


Oh also we should probably say something about how you can use abandon_payment to revoke a refund once issued (if it hasn't been paid). Its somewhat non-intuitive to me that that is true.

Updated in #2039.

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

jkczyz · 2023-09-14T22:44:29Z

Add utility methods to ChannelManager for:

creating OfferBuilder such that derived keys are used for the signing pubkey,
creating RefundBuilder such that derived keys are used for the payer id, and
sending an InvoiceRequest for an Offer such that derived keys are used for the payer id

When the ChannelManager is the payer (i.e., when creating Refund and InvoiceRequest), a PaymentId is required and used for tracking the outbound payment once the Bolt12Invoice is received.

One-hop blinded paths are used throughout until multi-hop blinded paths are supported.

Offer message handling and sending a Bolt12Invoice for a Refund such that derived keys are used for the signing pubkey are in #2039, which is based on this PR.

TheBlueMatt · 2023-09-17T02:18:02Z

+	/// The message contents to send in an [`OnionMessage`].
+	///
+	/// [`OnionMessage`]: crate::ln::msgs::OnionMessage
+	pub contents: T,


Hmm, if we leave a totally unbounded type that's gonna be a problem for bindings. Can we bound this by CustomOnionMessageContents (or if we need a general bound we could create an OnionMessageContents trait that we impl for BOLT12 messages as well)?

We'll need a more general bound since OffersMessage is used, too.

TheBlueMatt · 2023-09-17T02:27:38Z

+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	/// [`InvoiceRequestBuilder`]: crate::offers::invoice_request::InvoiceRequestBuilder
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	pub fn request_invoice(


Does this need to be pub? I'm not sure what the use is for this outside of simply paying an offer, which is presumably a different method.

Ah, this is the "paying for an offer" method. I guess that I can rename it to be more user- rather than implementation-focused.

TheBlueMatt · 2023-09-18T19:36:59Z

 }

+/// A type used within a variant of [`OnionMessageContents`].
+pub trait OnionMessageContentsType {}


Rather than an empty trait, should we just rename CustomOnionMessageContents to OnionMessageContents and impl it for Bolt12/etc? Its already basically what we want - extends Write and has a tlv_type.

Hmmm... we already have an OnionMessageContents enum.

Oh, then lets use that in PendingOnionMessage instead of a generic type T?

It also seems arbitrary that a custom message handler isn't allowed to send BOLT12 messages.

But we don't want a BOLT 12 handler to be able to send arbitrary ones. A custom handler can alway have their type wrap OffersMessage in a variant.

I mean...why not? We could also drop OnionMessageContents or make it priv, and replace most usages with a trait.

Discussed offline and made the following changes:
Renamed OnionMessageContents to ParsedOnionMessageContents and gave it pub(super) visibility
Renamed CustomOnionMessageContents to OnionMessageContents and used it as a trait bound on most methods
Changed Payload to hold T instead of ParsedOnionMessageContents<T> where T: OnionMessageContents
Implemented OnionMessageContents for OffersMessage and ParsedOnionMessageContents. The latter is needed so that arbitrary Payload contents can be read and specific contents can be written

codecov-commenter · 2023-09-19T20:46:51Z

Codecov Report

Attention: 91 lines in your changes are missing coverage. Please review.

Comparison is base (0357caf) 89.04% compared to head (905028b) 88.96%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2578 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87527 87632 +105 Branches 87527 87632 +105 ==========================================
+ Hits 77942 77963 +21 - Misses 7345 7435 +90 + Partials 2240 2234 -6

Files	Coverage Δ
lightning/src/events/mod.rs	`28.97% <ø> (-4.86%)`	⬇️
lightning/src/ln/msgs.rs	`76.81% <ø> (ø)`
lightning/src/offers/offer.rs	`94.65% <100.00%> (+0.01%)`	⬆️
lightning/src/offers/parse.rs	`92.30% <ø> (ø)`
lightning/src/offers/refund.rs	`93.67% <100.00%> (+0.02%)`	⬆️
lightning/src/onion_message/functional_tests.rs	`96.95% <100.00%> (+0.07%)`	⬆️
lightning/src/routing/router.rs	`94.07% <ø> (ø)`
lightning/src/ln/outbound_payment.rs	`87.69% <90.32%> (+0.16%)`	⬆️
lightning/src/ln/peer_handler.rs	`58.79% <25.00%> (-0.10%)`	⬇️
lightning/src/blinded_path/mod.rs	`70.14% <33.33%> (-5.66%)`	⬇️
... and 4 more

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

valentinewallace

Initial look, just nits

valentinewallace · 2023-09-19T20:16:39Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


I don't mind too much, but why remove this?

Restored it but now the test needs to check against InvalidFirstHop, which I'm not sure if that is intended?

Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

Will reexamine this but want to get the other changes pushed for now.

Sure, I'd also be fine with saving this for follow-up if you want to note it in #1970.

Ok, other than the introduction node being wrong, when hardcoding a fix I'm also seeing this logging:
Received an onion message with path_id Some([]) and a reply_path
Instead of the expected:
Received an onion message with path_id None and a reply_path
But I don't understand how my change would affect the path_id. Any ideas?

Oh, nevermind on this. That was just because I had been building using some unpublished commits instead of during the rebase. 🤦‍♂️

Opened #2671

jkczyz · 2023-10-11T14:37:54Z

Rebased as there were a lot of merge conflicts from the last release.

valentinewallace · 2023-10-12T21:28:25Z


 	#[test]
 	fn test_no_onion_message_breakage() {
- let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

jkczyz

Need to look into addressing the fuzz test comment still.

TheBlueMatt · 2023-10-15T15:29:24Z

I think this LGTM, I guess its now based on #2662, but once that lands feel free to squash.

TheBlueMatt · 2023-10-15T19:56:37Z

There's probably gonna be some conflicts between this and #2599

jkczyz · 2023-10-18T19:47:54Z

Speaking of timeouts, we should check if the payment has timed out per the AwaitingInvoice::retry_stragety (assuming its a time-based one) in the timer tick too.

Discussed offline. It would be better to keep the retry strategy separate from when to expire waiting for an invoice.

TheBlueMatt · 2023-10-18T20:15:37Z

Only comment left form my end is #2578 (comment), which you can fix or not, but either way lets squash and I'll ack :)

TheBlueMatt · 2023-10-18T21:13:10Z

Sorry needs a small-ish rebase after #2599.

OnionMessageProvider is a super-trait of OnionMessageHandler, but they don't need to be used separately. Additionally, the former is misplaced in the events module. Remove OnionMessageProvider and add it's only method, next_onion_message_for_peer, into OnionMessageHandler.

OnionMessenger can send onion message responses from its handlers using respond_with_onion_message, which finds a path to the destination and enqueues the response for sending. Generalize this as it can be used not only for responses but for initial sends as well.

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace

LGTM after rebase

Rename CustomOnionMessageContents to OnionMessageContents and use it as a trait bound on messages passed to OnionMessenger methods. This allows using the trait in an upcoming commit as a bound on the contents of PendingOnionMessage. Also, make ParsedOnionMessageContent implement OnionMessageContents so that Payload can be bounded by OnionMessageContents directly, but used when either reading a ParsedOnionMessageContent or writing a specific type of OnionMessageContents (e.g., OffersMessage).

When constructing onion messages to send initially (opposed to replying to one from a handler), the user must construct an OnionMessagePath first before calling OnionMessener::send_onion_message. Additionally, having a reference to OnionMessener isn't always desirable. For instance, in an upcoming commit, ChannelManager will implement OffersMessageHandler, which OnionMessenger needs a reference to. If ChannelManager had a reference to OnionMessenger, too, there would be a dependency cycle. Instead, modify OffersMessageHandler and CustomOnionMessageHandler's interfaces to include a method for releasing pending onion messages. That way, ChannelManager may, for instance, construct and enqueue an InvoiceRequest for sending without needing a reference to OnionMessenger. Additionally, OnionMessenger has responsibility for path finding just as it does when replying to messages from a handler. It performs this when extracting messages from the handlers before returning the next message to send to a peer.

This allows for specifying the introduction node as the message recipient.

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is forgotten. However, this mechanism is insufficient for the Refund scenario, where the Refund's expiration should be used instead. Change AwaitingInvoice to store an absolute expiry instead. When removing stale payments, pass the `SystemTime` in `std` and the highest block time minus two hours in `no-std`.

Add utility functions to ChannelManager for creating OfferBuilder, and RefundBuilder such that derived keys are used for the signing pubkey and payer id, respectively. This allows for stateless verification of any InvoiceRequest and Invoice messages. Later, blinded paths can be included in the returned builders. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

For consistency with other functions and doc cleanliness.

jkczyz · 2023-10-18T23:39:08Z

Sorry needs a small-ish rebase after #2599.

Rebased. Needed to expose ParsedOnionMessageContents because of this.

TheBlueMatt · 2023-10-19T02:41:34Z

+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the
+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].


We need to mention the two-hour thing here, its a bit awkward its buried in the timer_tick_occurred docs. Can happen in a followup, though.

Updated in #2039.

TheBlueMatt · 2023-10-19T03:05:59Z

+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].
+	///


Oh also we should probably say something about how you can use abandon_payment to revoke a refund once issued (if it hasn't been paid). Its somewhat non-intuitive to me that that is true.

Updated in #2039.

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

jkczyz marked this pull request as ready for review September 14, 2023 22:44

jkczyz requested review from TheBlueMatt and valentinewallace September 14, 2023 22:45

jkczyz force-pushed the 2023-09-offer-utilities branch from be8bf45 to 0ff5708Compare September 15, 2023 21:12

jkczyz mentioned this pull request Sep 15, 2023
BOLT 12 Offers message flow #2039
Merged

TheBlueMatt reviewed Sep 17, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 0ff5708 to ff2702cCompare September 18, 2023 19:04

TheBlueMatt reviewed Sep 18, 2023
View reviewed changes

jkczyz mentioned this pull request Sep 19, 2023
Add config option to set maximum total routing fee #2417
Merged

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 087941d to 8116d6eCompare September 19, 2023 20:33

valentinewallace reviewed Sep 19, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 8116d6e to 2508211Compare September 20, 2023 16:41

jkczyz commented Sep 20, 2023
View reviewed changes

Comment threadlightning/src/blinded_path/mod.rs Outdated

jkczyz added this to the 0.0.117 milestone Sep 20, 2023

jkczyz mentioned this pull request Sep 18, 2023
BOLT12 Offers Tracking Issue #1970
Open
60 tasks

benthecarman reviewed Sep 25, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated

TheBlueMatt modified the milestones: 0.0.117, 0.0.118 Sep 25, 2023

jkczyz force-pushed the 2023-09-offer-utilities branch from 2508211 to 7ddbd57Compare October 11, 2023 14:37

valentinewallace reviewed Oct 12, 2023
View reviewed changes

Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7ddbd57 to bd42eb0Compare October 13, 2023 22:46

jkczyz commented Oct 13, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 4f520cc to 6b96866Compare October 16, 2023 13:54

jkczyz force-pushed the 2023-09-offer-utilities branch from e4e9fd7 to 7bf0469Compare October 18, 2023 19:43

jkczyz force-pushed the 2023-09-offer-utilities branch from 7bf0469 to 7a198a8Compare October 18, 2023 21:53

jkczyz mentioned this pull request Oct 18, 2023
One-hop onion message fuzz test #2671
Closed

jkczyz added 7 commits October 18, 2023 17:00

Update OnionMessenger docs for Offers
a6cd661

Avoid overloading introduction_node_id
b78cb69

Clean up onion messenger parameters and docs
a4894bd

Import msgs::OnionMessage
cfe6b95

Rename OnionMessageContents
94573dd
In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace reviewed Oct 18, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/onion_message/messenger.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7a198a8 to bf980c9Compare October 18, 2023 23:25

jkczyz added 7 commits October 18, 2023 18:31

Allow sending onion messages to 1-hop blinded path
6dc4223
This allows for specifying the introduction node as the message recipient.

Remove outdated docs
622f7f2

Include a one-hop blinded path in Offer and Refund
80ae66a
While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

Clean up peel_onion name, parameters, and docs
905028b
For consistency with other functions and doc cleanliness.

jkczyz force-pushed the 2023-09-offer-utilities branch from bf980c9 to 905028bCompare October 18, 2023 23:33

valentinewallace approved these changes Oct 18, 2023
View reviewed changes

TheBlueMatt approved these changes Oct 19, 2023
View reviewed changes

TheBlueMatt merged commit 1852715 into lightningdevkit:mainOct 19, 2023

TheBlueMatt reviewed Oct 19, 2023
View reviewed changes

jkczyz marked this pull request as ready for review September 14, 2023 22:44

jkczyz requested review from TheBlueMatt and valentinewallace September 14, 2023 22:45

jkczyz force-pushed the 2023-09-offer-utilities branch from be8bf45 to 0ff5708Compare September 15, 2023 21:12

jkczyz mentioned this pull request Sep 15, 2023
BOLT 12 Offers message flow #2039
Merged

TheBlueMatt reviewed Sep 17, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 0ff5708 to ff2702cCompare September 18, 2023 19:04

TheBlueMatt reviewed Sep 18, 2023
View reviewed changes

jkczyz mentioned this pull request Sep 19, 2023
Add config option to set maximum total routing fee #2417
Merged

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 087941d to 8116d6eCompare September 19, 2023 20:33

valentinewallace reviewed Sep 19, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 8116d6e to 2508211Compare September 20, 2023 16:41

jkczyz commented Sep 20, 2023
View reviewed changes

Comment threadlightning/src/blinded_path/mod.rs Outdated

jkczyz added this to the 0.0.117 milestone Sep 20, 2023

jkczyz mentioned this pull request Sep 18, 2023
BOLT12 Offers Tracking Issue #1970
Open
60 tasks

benthecarman reviewed Sep 25, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated

TheBlueMatt modified the milestones: 0.0.117, 0.0.118 Sep 25, 2023

jkczyz force-pushed the 2023-09-offer-utilities branch from 2508211 to 7ddbd57Compare October 11, 2023 14:37

valentinewallace reviewed Oct 12, 2023
View reviewed changes

Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7ddbd57 to bd42eb0Compare October 13, 2023 22:46

jkczyz commented Oct 13, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 4f520cc to 6b96866Compare October 16, 2023 13:54

jkczyz force-pushed the 2023-09-offer-utilities branch from e4e9fd7 to 7bf0469Compare October 18, 2023 19:43

jkczyz force-pushed the 2023-09-offer-utilities branch from 7bf0469 to 7a198a8Compare October 18, 2023 21:53

jkczyz mentioned this pull request Oct 18, 2023
One-hop onion message fuzz test #2671
Closed

jkczyz added 7 commits October 18, 2023 17:00

Update OnionMessenger docs for Offers
a6cd661

Avoid overloading introduction_node_id
b78cb69

Clean up onion messenger parameters and docs
a4894bd

Import msgs::OnionMessage
cfe6b95

Rename OnionMessageContents
94573dd
In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace reviewed Oct 18, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/onion_message/messenger.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7a198a8 to bf980c9Compare October 18, 2023 23:25

jkczyz added 7 commits October 18, 2023 18:31

Allow sending onion messages to 1-hop blinded path
6dc4223
This allows for specifying the introduction node as the message recipient.

Remove outdated docs
622f7f2

Include a one-hop blinded path in Offer and Refund
80ae66a
While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

Clean up peel_onion name, parameters, and docs
905028b
For consistency with other functions and doc cleanliness.

jkczyz force-pushed the 2023-09-offer-utilities branch from bf980c9 to 905028bCompare October 18, 2023 23:33

valentinewallace approved these changes Oct 18, 2023
View reviewed changes

TheBlueMatt approved these changes Oct 19, 2023
View reviewed changes

TheBlueMatt merged commit 1852715 into lightningdevkit:mainOct 19, 2023

TheBlueMatt reviewed Oct 19, 2023
View reviewed changes

jkczyz marked this pull request as ready for review September 14, 2023 22:44

jkczyz requested review from TheBlueMatt and valentinewallace September 14, 2023 22:45

jkczyz force-pushed the 2023-09-offer-utilities branch from be8bf45 to 0ff5708Compare September 15, 2023 21:12

jkczyz mentioned this pull request Sep 15, 2023
BOLT 12 Offers message flow #2039
Merged

TheBlueMatt reviewed Sep 17, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 0ff5708 to ff2702cCompare September 18, 2023 19:04

TheBlueMatt reviewed Sep 18, 2023
View reviewed changes

jkczyz mentioned this pull request Sep 19, 2023
Add config option to set maximum total routing fee #2417
Merged

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 087941d to 8116d6eCompare September 19, 2023 20:33

valentinewallace reviewed Sep 19, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 8116d6e to 2508211Compare September 20, 2023 16:41

jkczyz commented Sep 20, 2023
View reviewed changes

Comment threadlightning/src/blinded_path/mod.rs Outdated

jkczyz added this to the 0.0.117 milestone Sep 20, 2023

jkczyz mentioned this pull request Sep 18, 2023
BOLT12 Offers Tracking Issue #1970
Open
60 tasks

benthecarman reviewed Sep 25, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated

TheBlueMatt modified the milestones: 0.0.117, 0.0.118 Sep 25, 2023

jkczyz force-pushed the 2023-09-offer-utilities branch from 2508211 to 7ddbd57Compare October 11, 2023 14:37

valentinewallace reviewed Oct 12, 2023
View reviewed changes

Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7ddbd57 to bd42eb0Compare October 13, 2023 22:46

jkczyz commented Oct 13, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 4f520cc to 6b96866Compare October 16, 2023 13:54

jkczyz force-pushed the 2023-09-offer-utilities branch from e4e9fd7 to 7bf0469Compare October 18, 2023 19:43

jkczyz force-pushed the 2023-09-offer-utilities branch from 7bf0469 to 7a198a8Compare October 18, 2023 21:53

jkczyz mentioned this pull request Oct 18, 2023
One-hop onion message fuzz test #2671
Closed

jkczyz added 7 commits October 18, 2023 17:00

Update OnionMessenger docs for Offers
a6cd661

Avoid overloading introduction_node_id
b78cb69

Clean up onion messenger parameters and docs
a4894bd

Import msgs::OnionMessage
cfe6b95

Rename OnionMessageContents
94573dd
In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace reviewed Oct 18, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/onion_message/messenger.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7a198a8 to bf980c9Compare October 18, 2023 23:25

jkczyz added 7 commits October 18, 2023 18:31

Allow sending onion messages to 1-hop blinded path
6dc4223
This allows for specifying the introduction node as the message recipient.

Remove outdated docs
622f7f2

Include a one-hop blinded path in Offer and Refund
80ae66a
While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

Clean up peel_onion name, parameters, and docs
905028b
For consistency with other functions and doc cleanliness.

jkczyz force-pushed the 2023-09-offer-utilities branch from bf980c9 to 905028bCompare October 18, 2023 23:33

valentinewallace approved these changes Oct 18, 2023
View reviewed changes

TheBlueMatt approved these changes Oct 19, 2023
View reviewed changes

TheBlueMatt merged commit 1852715 into lightningdevkit:mainOct 19, 2023

TheBlueMatt reviewed Oct 19, 2023
View reviewed changes

jkczyz marked this pull request as ready for review September 14, 2023 22:44

jkczyz requested review from TheBlueMatt and valentinewallace September 14, 2023 22:45

jkczyz force-pushed the 2023-09-offer-utilities branch from be8bf45 to 0ff5708Compare September 15, 2023 21:12

jkczyz mentioned this pull request Sep 15, 2023
BOLT 12 Offers message flow #2039
Merged

TheBlueMatt reviewed Sep 17, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 0ff5708 to ff2702cCompare September 18, 2023 19:04

TheBlueMatt reviewed Sep 18, 2023
View reviewed changes

jkczyz mentioned this pull request Sep 19, 2023
Add config option to set maximum total routing fee #2417
Merged

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 087941d to 8116d6eCompare September 19, 2023 20:33

valentinewallace reviewed Sep 19, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 8116d6e to 2508211Compare September 20, 2023 16:41

jkczyz commented Sep 20, 2023
View reviewed changes

Comment threadlightning/src/blinded_path/mod.rs Outdated

jkczyz added this to the 0.0.117 milestone Sep 20, 2023

jkczyz mentioned this pull request Sep 18, 2023
BOLT12 Offers Tracking Issue #1970
Open
60 tasks

benthecarman reviewed Sep 25, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated

TheBlueMatt modified the milestones: 0.0.117, 0.0.118 Sep 25, 2023

jkczyz force-pushed the 2023-09-offer-utilities branch from 2508211 to 7ddbd57Compare October 11, 2023 14:37

valentinewallace reviewed Oct 12, 2023
View reviewed changes

Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7ddbd57 to bd42eb0Compare October 13, 2023 22:46

jkczyz commented Oct 13, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 4f520cc to 6b96866Compare October 16, 2023 13:54

jkczyz force-pushed the 2023-09-offer-utilities branch from e4e9fd7 to 7bf0469Compare October 18, 2023 19:43

jkczyz force-pushed the 2023-09-offer-utilities branch from 7bf0469 to 7a198a8Compare October 18, 2023 21:53

jkczyz mentioned this pull request Oct 18, 2023
One-hop onion message fuzz test #2671
Closed

jkczyz added 7 commits October 18, 2023 17:00

Update OnionMessenger docs for Offers
a6cd661

Avoid overloading introduction_node_id
b78cb69

Clean up onion messenger parameters and docs
a4894bd

Import msgs::OnionMessage
cfe6b95

Rename OnionMessageContents
94573dd
In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace reviewed Oct 18, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/onion_message/messenger.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7a198a8 to bf980c9Compare October 18, 2023 23:25

jkczyz added 7 commits October 18, 2023 18:31

Allow sending onion messages to 1-hop blinded path
6dc4223
This allows for specifying the introduction node as the message recipient.

Remove outdated docs
622f7f2

Include a one-hop blinded path in Offer and Refund
80ae66a
While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

Clean up peel_onion name, parameters, and docs
905028b
For consistency with other functions and doc cleanliness.

jkczyz force-pushed the 2023-09-offer-utilities branch from bf980c9 to 905028bCompare October 18, 2023 23:33

valentinewallace approved these changes Oct 18, 2023
View reviewed changes

TheBlueMatt approved these changes Oct 19, 2023
View reviewed changes

TheBlueMatt merged commit 1852715 into lightningdevkit:mainOct 19, 2023

TheBlueMatt reviewed Oct 19, 2023
View reviewed changes

jkczyz marked this pull request as ready for review September 14, 2023 22:44

jkczyz requested review from TheBlueMatt and valentinewallace September 14, 2023 22:45

jkczyz force-pushed the 2023-09-offer-utilities branch from be8bf45 to 0ff5708Compare September 15, 2023 21:12

jkczyz mentioned this pull request Sep 15, 2023
BOLT 12 Offers message flow #2039
Merged

TheBlueMatt reviewed Sep 17, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 0ff5708 to ff2702cCompare September 18, 2023 19:04

TheBlueMatt reviewed Sep 18, 2023
View reviewed changes

jkczyz mentioned this pull request Sep 19, 2023
Add config option to set maximum total routing fee #2417
Merged

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 087941d to 8116d6eCompare September 19, 2023 20:33

valentinewallace reviewed Sep 19, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 8116d6e to 2508211Compare September 20, 2023 16:41

jkczyz commented Sep 20, 2023
View reviewed changes

Comment threadlightning/src/blinded_path/mod.rs Outdated

jkczyz added this to the 0.0.117 milestone Sep 20, 2023

jkczyz mentioned this pull request Sep 18, 2023
BOLT12 Offers Tracking Issue #1970
Open
60 tasks

benthecarman reviewed Sep 25, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated

TheBlueMatt modified the milestones: 0.0.117, 0.0.118 Sep 25, 2023

jkczyz force-pushed the 2023-09-offer-utilities branch from 2508211 to 7ddbd57Compare October 11, 2023 14:37

valentinewallace reviewed Oct 12, 2023
View reviewed changes

Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7ddbd57 to bd42eb0Compare October 13, 2023 22:46

jkczyz commented Oct 13, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 4f520cc to 6b96866Compare October 16, 2023 13:54

jkczyz force-pushed the 2023-09-offer-utilities branch from e4e9fd7 to 7bf0469Compare October 18, 2023 19:43

jkczyz force-pushed the 2023-09-offer-utilities branch from 7bf0469 to 7a198a8Compare October 18, 2023 21:53

jkczyz mentioned this pull request Oct 18, 2023
One-hop onion message fuzz test #2671
Closed

jkczyz added 7 commits October 18, 2023 17:00

Update OnionMessenger docs for Offers
a6cd661

Avoid overloading introduction_node_id
b78cb69

Clean up onion messenger parameters and docs
a4894bd

Import msgs::OnionMessage
cfe6b95

Rename OnionMessageContents
94573dd
In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace reviewed Oct 18, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/onion_message/messenger.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7a198a8 to bf980c9Compare October 18, 2023 23:25

jkczyz added 7 commits October 18, 2023 18:31

Allow sending onion messages to 1-hop blinded path
6dc4223
This allows for specifying the introduction node as the message recipient.

Remove outdated docs
622f7f2

Include a one-hop blinded path in Offer and Refund
80ae66a
While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

Clean up peel_onion name, parameters, and docs
905028b
For consistency with other functions and doc cleanliness.

jkczyz force-pushed the 2023-09-offer-utilities branch from bf980c9 to 905028bCompare October 18, 2023 23:33

valentinewallace approved these changes Oct 18, 2023
View reviewed changes

TheBlueMatt approved these changes Oct 19, 2023
View reviewed changes

TheBlueMatt merged commit 1852715 into lightningdevkit:mainOct 19, 2023

TheBlueMatt reviewed Oct 19, 2023
View reviewed changes

jkczyz marked this pull request as ready for review September 14, 2023 22:44

jkczyz requested review from TheBlueMatt and valentinewallace September 14, 2023 22:45

jkczyz force-pushed the 2023-09-offer-utilities branch from be8bf45 to 0ff5708Compare September 15, 2023 21:12

jkczyz mentioned this pull request Sep 15, 2023
BOLT 12 Offers message flow #2039
Merged

TheBlueMatt reviewed Sep 17, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 0ff5708 to ff2702cCompare September 18, 2023 19:04

TheBlueMatt reviewed Sep 18, 2023
View reviewed changes

jkczyz mentioned this pull request Sep 19, 2023
Add config option to set maximum total routing fee #2417
Merged

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 087941d to 8116d6eCompare September 19, 2023 20:33

valentinewallace reviewed Sep 19, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 8116d6e to 2508211Compare September 20, 2023 16:41

jkczyz commented Sep 20, 2023
View reviewed changes

Comment threadlightning/src/blinded_path/mod.rs Outdated

jkczyz added this to the 0.0.117 milestone Sep 20, 2023

jkczyz mentioned this pull request Sep 18, 2023
BOLT12 Offers Tracking Issue #1970
Open
60 tasks

benthecarman reviewed Sep 25, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated

TheBlueMatt modified the milestones: 0.0.117, 0.0.118 Sep 25, 2023

jkczyz force-pushed the 2023-09-offer-utilities branch from 2508211 to 7ddbd57Compare October 11, 2023 14:37

valentinewallace reviewed Oct 12, 2023
View reviewed changes

Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7ddbd57 to bd42eb0Compare October 13, 2023 22:46

jkczyz commented Oct 13, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 4f520cc to 6b96866Compare October 16, 2023 13:54

jkczyz force-pushed the 2023-09-offer-utilities branch from e4e9fd7 to 7bf0469Compare October 18, 2023 19:43

jkczyz force-pushed the 2023-09-offer-utilities branch from 7bf0469 to 7a198a8Compare October 18, 2023 21:53

jkczyz mentioned this pull request Oct 18, 2023
One-hop onion message fuzz test #2671
Closed

jkczyz added 7 commits October 18, 2023 17:00

Update OnionMessenger docs for Offers
a6cd661

Avoid overloading introduction_node_id
b78cb69

Clean up onion messenger parameters and docs
a4894bd

Import msgs::OnionMessage
cfe6b95

Rename OnionMessageContents
94573dd
In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace reviewed Oct 18, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/onion_message/messenger.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7a198a8 to bf980c9Compare October 18, 2023 23:25

jkczyz added 7 commits October 18, 2023 18:31

Allow sending onion messages to 1-hop blinded path
6dc4223
This allows for specifying the introduction node as the message recipient.

Remove outdated docs
622f7f2

Include a one-hop blinded path in Offer and Refund
80ae66a
While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

Clean up peel_onion name, parameters, and docs
905028b
For consistency with other functions and doc cleanliness.

jkczyz force-pushed the 2023-09-offer-utilities branch from bf980c9 to 905028bCompare October 18, 2023 23:33

valentinewallace approved these changes Oct 18, 2023
View reviewed changes

TheBlueMatt approved these changes Oct 19, 2023
View reviewed changes

TheBlueMatt merged commit 1852715 into lightningdevkit:mainOct 19, 2023

TheBlueMatt reviewed Oct 19, 2023
View reviewed changes

jkczyz marked this pull request as ready for review September 14, 2023 22:44

jkczyz requested review from TheBlueMatt and valentinewallace September 14, 2023 22:45

jkczyz force-pushed the 2023-09-offer-utilities branch from be8bf45 to 0ff5708Compare September 15, 2023 21:12

jkczyz mentioned this pull request Sep 15, 2023
BOLT 12 Offers message flow #2039
Merged

TheBlueMatt reviewed Sep 17, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 0ff5708 to ff2702cCompare September 18, 2023 19:04

TheBlueMatt reviewed Sep 18, 2023
View reviewed changes

jkczyz mentioned this pull request Sep 19, 2023
Add config option to set maximum total routing fee #2417
Merged

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 087941d to 8116d6eCompare September 19, 2023 20:33

valentinewallace reviewed Sep 19, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 8116d6e to 2508211Compare September 20, 2023 16:41

jkczyz commented Sep 20, 2023
View reviewed changes

Comment threadlightning/src/blinded_path/mod.rs Outdated

jkczyz added this to the 0.0.117 milestone Sep 20, 2023

jkczyz mentioned this pull request Sep 18, 2023
BOLT12 Offers Tracking Issue #1970
Open
60 tasks

benthecarman reviewed Sep 25, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated

TheBlueMatt modified the milestones: 0.0.117, 0.0.118 Sep 25, 2023

jkczyz force-pushed the 2023-09-offer-utilities branch from 2508211 to 7ddbd57Compare October 11, 2023 14:37

valentinewallace reviewed Oct 12, 2023
View reviewed changes

Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7ddbd57 to bd42eb0Compare October 13, 2023 22:46

jkczyz commented Oct 13, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 4f520cc to 6b96866Compare October 16, 2023 13:54

jkczyz force-pushed the 2023-09-offer-utilities branch from e4e9fd7 to 7bf0469Compare October 18, 2023 19:43

jkczyz force-pushed the 2023-09-offer-utilities branch from 7bf0469 to 7a198a8Compare October 18, 2023 21:53

jkczyz mentioned this pull request Oct 18, 2023
One-hop onion message fuzz test #2671
Closed

jkczyz added 7 commits October 18, 2023 17:00

Update OnionMessenger docs for Offers
a6cd661

Avoid overloading introduction_node_id
b78cb69

Clean up onion messenger parameters and docs
a4894bd

Import msgs::OnionMessage
cfe6b95

Rename OnionMessageContents
94573dd
In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace reviewed Oct 18, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/onion_message/messenger.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7a198a8 to bf980c9Compare October 18, 2023 23:25

jkczyz added 7 commits October 18, 2023 18:31

Allow sending onion messages to 1-hop blinded path
6dc4223
This allows for specifying the introduction node as the message recipient.

Remove outdated docs
622f7f2

Include a one-hop blinded path in Offer and Refund
80ae66a
While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

Clean up peel_onion name, parameters, and docs
905028b
For consistency with other functions and doc cleanliness.

jkczyz force-pushed the 2023-09-offer-utilities branch from bf980c9 to 905028bCompare October 18, 2023 23:33

valentinewallace approved these changes Oct 18, 2023
View reviewed changes

TheBlueMatt approved these changes Oct 19, 2023
View reviewed changes

TheBlueMatt merged commit 1852715 into lightningdevkit:mainOct 19, 2023

TheBlueMatt reviewed Oct 19, 2023
View reviewed changes

jkczyz marked this pull request as ready for review September 14, 2023 22:44

jkczyz requested review from TheBlueMatt and valentinewallace September 14, 2023 22:45

jkczyz force-pushed the 2023-09-offer-utilities branch from be8bf45 to 0ff5708Compare September 15, 2023 21:12

jkczyz mentioned this pull request Sep 15, 2023
BOLT 12 Offers message flow #2039
Merged

TheBlueMatt reviewed Sep 17, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 0ff5708 to ff2702cCompare September 18, 2023 19:04

TheBlueMatt reviewed Sep 18, 2023
View reviewed changes

jkczyz mentioned this pull request Sep 19, 2023
Add config option to set maximum total routing fee #2417
Merged

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 087941d to 8116d6eCompare September 19, 2023 20:33

valentinewallace reviewed Sep 19, 2023
View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 8116d6e to 2508211Compare September 20, 2023 16:41

jkczyz commented Sep 20, 2023
View reviewed changes

Comment threadlightning/src/blinded_path/mod.rs Outdated

jkczyz added this to the 0.0.117 milestone Sep 20, 2023

jkczyz mentioned this pull request Sep 18, 2023
BOLT12 Offers Tracking Issue #1970
Open
60 tasks

benthecarman reviewed Sep 25, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated

TheBlueMatt modified the milestones: 0.0.117, 0.0.118 Sep 25, 2023

jkczyz force-pushed the 2023-09-offer-utilities branch from 2508211 to 7ddbd57Compare October 11, 2023 14:37

valentinewallace reviewed Oct 12, 2023
View reviewed changes

Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7ddbd57 to bd42eb0Compare October 13, 2023 22:46

jkczyz commented Oct 13, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/onion_message/offers.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 4f520cc to 6b96866Compare October 16, 2023 13:54

jkczyz force-pushed the 2023-09-offer-utilities branch from e4e9fd7 to 7bf0469Compare October 18, 2023 19:43

jkczyz force-pushed the 2023-09-offer-utilities branch from 7bf0469 to 7a198a8Compare October 18, 2023 21:53

jkczyz mentioned this pull request Oct 18, 2023
One-hop onion message fuzz test #2671
Closed

jkczyz added 7 commits October 18, 2023 17:00

Update OnionMessenger docs for Offers
a6cd661

Avoid overloading introduction_node_id
b78cb69

Clean up onion messenger parameters and docs
a4894bd

Import msgs::OnionMessage
cfe6b95

Rename OnionMessageContents
94573dd
In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace reviewed Oct 18, 2023
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs
Comment threadlightning/src/onion_message/messenger.rs Outdated

jkczyz force-pushed the 2023-09-offer-utilities branch from 7a198a8 to bf980c9Compare October 18, 2023 23:25

jkczyz added 7 commits October 18, 2023 18:31

Allow sending onion messages to 1-hop blinded path
6dc4223
This allows for specifying the introduction node as the message recipient.

Remove outdated docs
622f7f2

Include a one-hop blinded path in Offer and Refund
80ae66a
While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

Clean up peel_onion name, parameters, and docs
905028b
For consistency with other functions and doc cleanliness.

jkczyz force-pushed the 2023-09-offer-utilities branch from bf980c9 to 905028bCompare October 18, 2023 23:33

valentinewallace approved these changes Oct 18, 2023
View reviewed changes

TheBlueMatt approved these changes Oct 19, 2023
View reviewed changes

TheBlueMatt merged commit 1852715 into lightningdevkit:mainOct 19, 2023

TheBlueMatt reviewed Oct 19, 2023
View reviewed changes

Uh oh!

Conversation

jkczyz commented Sep 14, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMattSep 18, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkczyzSep 19, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov-commenter commented Sep 19, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

valentinewallace left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkczyzSep 20, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jkczyz commented Oct 11, 2023

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jkczyz commented Sep 14, 2023•
edited
Loading

TheBlueMattSep 18, 2023•
edited
Loading

jkczyzSep 19, 2023•
edited
Loading

codecov-commenter commented Sep 19, 2023•
edited
Loading

jkczyzSep 20, 2023•
edited
Loading

jkczyz commented Sep 14, 2023•
edited
Loading