Authenticate `InvoiceError` messages #3192

jkczyz · 2024-07-18T16:59:49Z

Before abandoning a payment when receiving an InvoiceError, verify that the PaymentId included in the OffersContext with the included HMAC. This prevents a malicious actor sending an InvoiceError with a known payment id from abandoning our payment.

Based on #3202

Fixes #3166
Fixes #3167

codecov · 2024-07-18T17:11:14Z

Codecov Report

Attention: Patch coverage is 85.86572% with 40 lines in your changes missing coverage. Please review.

Project coverage is 89.74%. Comparing base (5ab40b2) to head (075a2e3).
Report is 20 commits behind head on main.

Files	Patch %	Lines
lightning/src/events/mod.rs	0.00%	22 Missing ⚠️
lightning/src/ln/channelmanager.rs	82.50%	4 Missing and 3 partials ⚠️
lightning/src/ln/offers_tests.rs	95.65%	5 Missing ⚠️
lightning/src/ln/outbound_payment.rs	94.23%	0 Missing and 3 partials ⚠️
lightning/src/ln/functional_test_utils.rs	0.00%	0 Missing and 2 partials ⚠️
lightning/src/util/ser.rs	85.71%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3192      +/-   ##
==========================================
- Coverage   89.75%   89.74%   -0.02%     
==========================================
  Files         123      123              
  Lines      102158   102330     +172     
  Branches   102158   102330     +172     
==========================================
+ Hits        91695    91833     +138     
- Misses       7773     7802      +29     
- Partials     2690     2695       +5

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

jkczyz · 2024-07-30T21:57:41Z

@TheBlueMatt @valentinewallace Need your opinions on Event::InvoiceRequestFailed. A payment in state AwaitingInvoice, may be abandoned for the following reasons:

Timeout waiting on the invoice
Explicitly abandoned by the user
Invoice contains unknown required features
Recipient sends back InvoiceError

Currently, the first two generate Event::InvoiceRequestFailed.

In this PR, we transition to state InvoiceReceived before checking the features, so that it will instead generate an Event::PaymentFailed. Note, we can only use Event::PaymentFailed when we have a PaymentHash.

Abandoning for the InvoiceError case requires us to give a PaymentFailureReason. But the reason in practice is ignored by PendingOutboundPayments::abandon_payment when in state AwaitingInvoice.

Do we care that reason is ignored and never finds it way to the user in Event::InvoiceRequestFailed? Should we add a reason to that event? And if so, should it be PaymentFailureReason or a dedicated type? If a dedicated type, I'm not sure how PendingOutboundPayments::abandon_payment would work when called for a payment in the wrong state. But re-using PaymentFailureReason instead means that some reasons aren't applicable for either event.

Or maybe we just add an Option<InvoiceError> to Event::InvoiceRequestFailed? Though when None that doesn't differentiate timeout from user-abandoned, which is currently the case.

Thoughts?

TheBlueMatt · 2024-08-05T19:43:07Z

Need your opinions on Event::InvoiceRequestFailed

I mean the only reason for the distinction between the two events is that we need a PaymentHash for the payment failed one, so I don't feel super strongly about making sure there's too much of a logical distinction between the two - we expect users to largely handle them the same.

Do we care that reason is ignored and never finds it way to the user in Event::InvoiceRequestFailed? Should we add a reason to that event? And if so, should it be PaymentFailureReason or a dedicated type? If a dedicated type, I'm not sure how PendingOutboundPayments::abandon_payment would work when called for a payment in the wrong state. But re-using PaymentFailureReason instead means that some reasons aren't applicable for either event.

I'm starting to think we should make the hash optional in PaymentFailed and stick with that, but absent that, it seems like we could give users the same error type so that they could delegate to some common method to handle both cases? I'm not sure its that critical, though, honestly - there's not gonna be much in the way of programatic differences in how these events are handled, its really just them giving some kind of string to the operator/log. As far as the UX cares, the payment failed, and the reason is some technical garbage that isn't really useful to a human.

jkczyz · 2024-08-06T23:38:43Z

I'm starting to think we should make the hash optional in PaymentFailed and stick with that, but absent that, it seems like we could give users the same error type so that they could delegate to some common method to handle both cases?

Ended up making the payment hash optional in PaymentFailed and removing InvoiceRequestFailed. I agree that this approach is best.

TheBlueMatt · 2024-08-07T16:25:42Z

lightning/src/events/mod.rs

@@ -882,6 +885,7 @@ pub enum Event {
 		payment_hash: PaymentHash,
 		/// The reason the payment failed. This is only `None` for events generated or serialized
 		/// by versions prior to 0.0.115.
+		/// TODO: Will downgrading cause this to be None for UnknownRequiredFeatures?


No, it'll cause reading the event to fail with DecodeError::InvalidValue :(. We should have done impl_writeable_tlv_based_enum_upgradable for PaymentFailureReason (we still should for the next added reason, but it won't help downgrades to 123).

Went ahead and changed this to impl_writeable_tlv_based_enum_upgradable.

TheBlueMatt · 2024-08-07T16:37:36Z

lightning/src/events/mod.rs

@@ -1555,7 +1557,7 @@ impl Writeable for Event {
 				write_tlv_fields!(writer, {
 					(0, payment_id, required),
 					(1, reason, option),
-					(2, payment_hash, required),
+					(2, payment_hash, option),


I'm pretty meh on breaking downgrades for payment failures here (causing DecodeError::InvalidValue). Instead, maybe we write 0s (and drop all-0s on the read end, and also then reject sending payments with all-0 payment hashes in ChannelManager/outbound_payments, or write some other "no payment_hash" flag) and document it in the release notes?

lightning/src/ln/channelmanager.rs

valentinewallace · 2024-08-07T20:29:03Z

Needs rebase

jkczyz · 2024-08-07T22:31:27Z

Feedback addressed.

Needs rebase

@TheBlueMatt Will rebase whenever you are good.

TheBlueMatt · 2024-08-08T14:59:48Z

Feel free to rebase!

TheBlueMatt · 2024-08-08T19:56:50Z

lightning/src/events/mod.rs

+	UnknownRequiredFeatures,
+	/// A [`Bolt12Invoice`] was not received in a reasonable amount of time.
+	InvoiceRequestExpired,
+	/// An [`InvoiceRequest`] for the payment was rejected by the recipient.
+	///
+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	InvoiceRequestRejected,


I'm pretty meh on the idea that users might upgrade, use bolt12, and suddenly be unable to downgrade even one version. Not entirely sure what to do about it, though - we could delay this part of the patch for a release, or we could write the PaymentFailureReason twice, once with these versions in a new TLV and once without, mapping them to UnexpectedError or whatever.

Went ahead and wrote the reason twice. UnexpectedError would be a misleading, IMO, though. Used None instead, but let me know if there was some other alternative you were thinking about.

Hmm, I suppose None is fine, but its a bit annoying to suddenly have no reason when the docs on 123 say that its "only None for events generated by versions prior to 0.0.115". I guess for InvoiceRequestRejected we could easily just say RecipientRejected, but InvoiceRequestExpired is tougher...maybe RetriesExhausted?

Hmm... UnknownRequiredFeatures also needs to map to something.

RecipientRejected, I assume - they would have rejected a payment that has unknown features in the onion so...?

Here it is us -- the payer -- rejecting an invoice for an outbound payment.

Yea but the principle is the same - we have some issue causing us to be unable to talk to the intended recipient so cannot pay. RecipientRejected makes sense imo as it's also the most final - "don't bother trying this again cause they already said they won't accept it"

Gotcha. Updated now.

valentinewallace · 2024-08-08T19:14:53Z

lightning/src/offers/signer.rs

@@ -36,6 +36,9 @@ const DERIVED_METADATA_AND_KEYS_HMAC_INPUT: &[u8; 16] = &[2; 16];
 const WITHOUT_ENCRYPTED_PAYMENT_ID_HMAC_INPUT: &[u8; 16] = &[3; 16];
 const WITH_ENCRYPTED_PAYMENT_ID_HMAC_INPUT: &[u8; 16] = &[4; 16];

+// HMAC input for a `PaymentId`. The HMAC is used in `OffersContext::OutboundPayment`.
+const PAYMENT_ID_HMAC_INPUT: &[u8; 16] = &[5; 16];


Could you help me understand why we need this input in addition to IV_BYTES in hmac_for_payment_id?

May not be necessary actually. Though, if in the future we hmac some other type of data, then we may want to differentiate it with another input. Happy to drop it if you and @TheBlueMatt don't think it is necessary.

No reason not to have it IMO 🤷

valentinewallace · 2024-08-08T19:58:10Z

lightning/src/events/mod.rs

 				write_tlv_fields!(writer, {
 					(0, payment_id, required),
 					(1, reason, option),
 					(2, payment_hash, required),
+					(3, invoice_received, required),


It looks like if someone downgraded after writing a zeroed out payment hash, then upgraded again, their event would then contain a payment_hash: Some(PaymentHash([0; 32])), IIUC. I think we could prevent that by omitting this invoice_received field and explicitly detecting a zeroed out payment hash instead.

Yeah, not sure how concerning that is but went ahead with your alternative.

@TheBlueMatt I'm not checking in ChannelManager for such a payment hash when sending. Seems in such a rare scenario it would be better to check the reason to determine whether the 0-payment_hash should be included in the event when reading. Maybe there some obscure upgrade-downgrade-upgrade scenario I'm not thinking about. But I'm not sure if it's worth adding some complex checking if the worse case is dropping the 0-payment_hash.

Maybe we keep the old code writing the extra flag but then drop 0 payment hash if its missing? While people shouldn't be paying 0 payment hashes, its a bit weird that the payment hash will dissapear on you if you try to pay one because your counterparty made one up.

Updated accordingly, IIUC.

jkczyz · 2024-08-09T15:43:58Z

lightning/src/events/mod.rs

+	UnknownRequiredFeatures,
+	/// A [`Bolt12Invoice`] was not received in a reasonable amount of time.
+	InvoiceRequestExpired,
+	/// An [`InvoiceRequest`] for the payment was rejected by the recipient.
+	///
+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	InvoiceRequestRejected,


Went ahead and wrote the reason twice. UnexpectedError would be a misleading, IMO, though. Used None instead, but let me know if there was some other alternative you were thinking about.

jkczyz · 2024-08-09T15:44:41Z

lightning/src/events/mod.rs

 				write_tlv_fields!(writer, {
 					(0, payment_id, required),
 					(1, reason, option),
 					(2, payment_hash, required),
+					(3, invoice_received, required),


Yeah, not sure how concerning that is but went ahead with your alternative.

@TheBlueMatt I'm not checking in ChannelManager for such a payment hash when sending. Seems in such a rare scenario it would be better to check the reason to determine whether the 0-payment_hash should be included in the event when reading. Maybe there some obscure upgrade-downgrade-upgrade scenario I'm not thinking about. But I'm not sure if it's worth adding some complex checking if the worse case is dropping the 0-payment_hash.

jkczyz · 2024-08-09T15:57:45Z

lightning/src/ln/channelmanager.rs

+		let hmac = signer::hmac_for_payment_id(payment_id, nonce, expanded_key);
+		let context = OffersContext::OutboundPayment { payment_id, nonce, hmac: Some(hmac) };


@TheBlueMatt This nonce is used both for the hmac and in the payer metadata. Is this ok?

I think that's okay, they both use different IVs (and different algorithms) so it should be okay.

jkczyz · 2024-08-09T16:06:37Z

lightning/src/offers/signer.rs

@@ -36,6 +36,9 @@ const DERIVED_METADATA_AND_KEYS_HMAC_INPUT: &[u8; 16] = &[2; 16];
 const WITHOUT_ENCRYPTED_PAYMENT_ID_HMAC_INPUT: &[u8; 16] = &[3; 16];
 const WITH_ENCRYPTED_PAYMENT_ID_HMAC_INPUT: &[u8; 16] = &[4; 16];

+// HMAC input for a `PaymentId`. The HMAC is used in `OffersContext::OutboundPayment`.
+const PAYMENT_ID_HMAC_INPUT: &[u8; 16] = &[5; 16];


May not be necessary actually. Though, if in the future we hmac some other type of data, then we may want to differentiate it with another input. Happy to drop it if you and @TheBlueMatt don't think it is necessary.

TheBlueMatt · 2024-08-11T22:03:09Z

lightning/src/events/mod.rs

 		/// The reason the payment failed. This is only `None` for events generated or serialized
-		/// by versions prior to 0.0.115.
+		/// by versions prior to 0.0.115, when deserializing an `Event::InvoiceRequestFailed`, which
+		/// was removed in 0.0.124, or when downgrading to 0.0.124 or later with a reason that was


technically with the current implementation if you downgrade to pre-0.0.124 with a reason that was added after you also get None.

Suggested change

/// was removed in 0.0.124, or when downgrading to 0.0.124 or later with a reason that was

/// or when downgrading with a reason that was

Yep, removed "to 0.0.124 or later".

However, the first part, "which was removed in 0.0.124", is a non-restrictive clause; that is, the sentence has the same meaning with or without it. It's simply used to note when the event was removed from the codebase. Updated to use a parenthetical to make it clearer.

TheBlueMatt · 2024-08-11T22:11:21Z

lightning/src/events/mod.rs

 				write_tlv_fields!(writer, {
 					(0, payment_id, required),
 					(1, reason, option),
 					(2, payment_hash, required),
+					(3, invoice_received, required),


Maybe we keep the old code writing the extra flag but then drop 0 payment hash if its missing? While people shouldn't be paying 0 payment hashes, its a bit weird that the payment hash will dissapear on you if you try to pay one because your counterparty made one up.

valentinewallace

LGTM

valentinewallace · 2024-08-12T20:16:56Z

lightning/src/events/mod.rs

 					(2, payment_hash, required),
+					(3, invoice_received, option),


Doesn't matter much, but it would make more sense to write this as required since we always write it

Option let's us handle the scenario described here: #3192 (comment). If it's required, then we would fail when re-upgrading.

We should def make it Optional on read, but on writing it's fine to make it required since we always write it (there's no difference between required and an option where we always write).

Ah, I see. Done.

jkczyz · 2024-08-14T04:34:20Z

Squashed

TheBlueMatt · 2024-08-14T14:28:06Z

Ugh, needs a somewhat trivial rebase cause features.rs moved (and I guess git is dumb :( )

TheBlueMatt

Okay, one more nit to just fix (+ squash) on rebase, otherwise LGTM!

TheBlueMatt · 2024-08-14T14:34:31Z

lightning/src/events/mod.rs

 						payment_id: payment_id.0.unwrap(),
+						payment_hash: None,
+						reason: None,


Couldn't we set this to Some(InvoiceRequestExpired)?

valentinewallace · 2024-08-14T15:08:54Z

LGTM after rebase

When receiving an InvoiceError in response to an InvoiceRequest, the corresponding payment should be abandoned. Add functions for constructing and verifying an HMAC over a Payment ID to allow for this.

An HMAC needs to be included in OffersContext::OutboundPayment to authenticate the included PaymentId. Implement Readable and Writeable to allow for this.

When receiving an InvoiceError in response to an InvoiceRequest, the corresponding payment should be abandoned. Add an HMAC to OffersContext::OutboundPayment such that the payment ID can be authenticated prior to abandoning the payment.

Before abandoning a payment when receiving an InvoiceError, verify that the PaymentId included in the OffersContext with the included HMAC. This prevents a malicious actor sending an InvoiceError with a known payment id from abandoning our payment.

When making an outbound BOLT12 payment, multiple invoices may be received for the same payment id. Instead of abandoning the payment when a duplicate invoice received, simply ignore it without responding with an InvoiceError. This prevents abandoning in-progress payments and sending unnecessary onion messages.

A BOLT12 payment may be abandoned when handling the invoice or when receiving an InvoiceError message. When abandoning the payment, don't use UserAbandoned as the reason since that is meant for when the user calls ChannelManager::abandon_payment.

Refunds are typically communicated via QR code, where a smaller size is desirable. Make the HMAC in OutboundPayment data optional such that it is elided from blinded paths used in refunds. This prevents abandoning refunds if the reader sends an invoice_error instead of an invoice message. However, this use case isn't necessary as the corresponding outbound payment will either timeout when the refund expires or can be explicitly abandoned by the creator.

When handling a BOLT12 invoice, and invoice error is sent if the invoice contains unknown required features. However, since the payment is still in state AwaitingInvoice, abandoning it results in losing the reason since an InvoiceRequestFailed event would be generated. Move the check to PendingOutboundPayments such that the payment is first moved to state InvoiceReceived so that a PaymentFailed event is generated instead.

When testing Bolt12Invoice unknown require feature handling, a large feature bit can cause SendError::TooBigPacket when creating an onion message. Use a smaller feature bit for UnknownFeature, which also has the added benefit of reducing test output.

In order to test handling of unknown required features in a Bolt12Invoice, add a test-only function to allow setting arbitrary feature bits.

When abandoning a BOLT12 payment before a Bolt12Invoice is received, an Event::InvoiceRequestFailed is generated and the abandonment reason is lost. Make payment_hash optional in Event::PaymentFailed so that Event::InvoiceRequestFailed can be removed in favor of it.

Now that Event::PaymentFailed has an option payment_hash, it can be used in replace of Event::InvoiceRequestFailed. This allows for including a reason when abandoning a payment before an invoice is received.

Now that Event::PaymentFailed is generated when an InvoiceRequest times out, define a new PaymentFailureReason for this situation.

Instead of re-using PaymentFailureReason::RecipientRejected, define a new InvoiceRequestRejected variant for when an InvoiceError is received instead of a Bolt12Invoice. This allows user to differentiate the cause of the failure.

This allows downgrading to version 0.0.124 or later and using None for a PaymentFailureReason that was added after.

The PaymentFailureReason variants for invoice request failures will cause downgrades to break. Instead, use a new TLV for the reason and continue to write the old TLV, only use None for the new reasons.

jkczyz · 2024-08-14T15:57:34Z

Rebased

valentinewallace mentioned this pull request Jul 19, 2024

Authenticate use of offer blinded paths #3139

Merged

jkczyz force-pushed the 2024-07-invoice-error-auth branch 2 times, most recently from fd7da7f to cde9852 Compare July 30, 2024 21:23

jkczyz force-pushed the 2024-07-invoice-error-auth branch from d68a1e0 to d6b6ae6 Compare August 2, 2024 15:00

jkczyz marked this pull request as ready for review August 2, 2024 15:01

TheBlueMatt reviewed Aug 7, 2024

View reviewed changes

jkczyz force-pushed the 2024-07-invoice-error-auth branch from d2df48a to 0552a46 Compare August 7, 2024 22:30

jkczyz force-pushed the 2024-07-invoice-error-auth branch from 0552a46 to be5d04f Compare August 8, 2024 15:45

TheBlueMatt reviewed Aug 8, 2024

View reviewed changes

valentinewallace reviewed Aug 8, 2024

View reviewed changes

jkczyz force-pushed the 2024-07-invoice-error-auth branch from be5d04f to 98dadb2 Compare August 9, 2024 16:09

jkczyz commented Aug 9, 2024

View reviewed changes

jkczyz force-pushed the 2024-07-invoice-error-auth branch from 98dadb2 to 739832e Compare August 9, 2024 16:12

TheBlueMatt reviewed Aug 11, 2024

View reviewed changes

jkczyz force-pushed the 2024-07-invoice-error-auth branch from 739832e to 1e65483 Compare August 12, 2024 18:21

valentinewallace reviewed Aug 12, 2024

View reviewed changes

jkczyz force-pushed the 2024-07-invoice-error-auth branch 2 times, most recently from 74c0ec3 to e09b191 Compare August 14, 2024 04:33

TheBlueMatt reviewed Aug 14, 2024

View reviewed changes

HMAC construction and verification for PaymentID

f52bd0b

When receiving an InvoiceError in response to an InvoiceRequest, the corresponding payment should be abandoned. Add functions for constructing and verifying an HMAC over a Payment ID to allow for this.

jkczyz added 18 commits August 14, 2024 10:42

Add Sha256 HMAC (de)serialization

8119fbf

An HMAC needs to be included in OffersContext::OutboundPayment to authenticate the included PaymentId. Implement Readable and Writeable to allow for this.

Add an HMAC to OffersContext::OutboundPayment

0ca9faf

When receiving an InvoiceError in response to an InvoiceRequest, the corresponding payment should be abandoned. Add an HMAC to OffersContext::OutboundPayment such that the payment ID can be authenticated prior to abandoning the payment.

Add InvoiceBuilder::features_unchecked

19dec4b

In order to test handling of unknown required features in a Bolt12Invoice, add a test-only function to allow setting arbitrary feature bits.

Remove unused macro param

16bbb7b

Test Bolt12Invoice with unknown required features

4567ce5

Remove Event::InvoiceRequestFailed

a9e6363

Now that Event::PaymentFailed has an option payment_hash, it can be used in replace of Event::InvoiceRequestFailed. This allows for including a reason when abandoning a payment before an invoice is received.

Add pending changelog for Event::PaymentFailed

f00b782

Add PaymentFailureReason::InvoiceRequestExpired

457ba24

Now that Event::PaymentFailed is generated when an InvoiceRequest times out, define a new PaymentFailureReason for this situation.

Add PaymentFailureReason::InvoiceRequestRejected

1563186

Instead of re-using PaymentFailureReason::RecipientRejected, define a new InvoiceRequestRejected variant for when an InvoiceError is received instead of a Bolt12Invoice. This allows user to differentiate the cause of the failure.

Make PaymentFailureReason upgradable

bb94320

This allows downgrading to version 0.0.124 or later and using None for a PaymentFailureReason that was added after.

Make PaymentFailureReason downgradable

075a2e3

The PaymentFailureReason variants for invoice request failures will cause downgrades to break. Instead, use a new TLV for the reason and continue to write the old TLV, only use None for the new reasons.

jkczyz force-pushed the 2024-07-invoice-error-auth branch from e09b191 to 075a2e3 Compare August 14, 2024 15:56

valentinewallace approved these changes Aug 14, 2024

View reviewed changes

TheBlueMatt approved these changes Aug 14, 2024

View reviewed changes

TheBlueMatt merged commit 33e6995 into lightningdevkit:main Aug 14, 2024
18 of 21 checks passed

valentinewallace mentioned this pull request Aug 21, 2024

Support paying static invoices #3140

Merged

jkczyz mentioned this pull request Sep 5, 2024

Introduce Reply Paths for BOLT12 Invoice in Offers Flow. #3163

Merged

		let hmac = signer::hmac_for_payment_id(payment_id, nonce, expanded_key);
		let context = OffersContext::OutboundPayment { payment_id, nonce, hmac: Some(hmac) };

	/// was removed in 0.0.124, or when downgrading to 0.0.124 or later with a reason that was
	/// or when downgrading with a reason that was

Authenticate InvoiceError messages #3192

Authenticate InvoiceError messages #3192

Conversation

jkczyz commented Jul 18, 2024 • edited Loading

codecov bot commented Jul 18, 2024 • edited Loading

Codecov Report

jkczyz commented Jul 30, 2024

TheBlueMatt commented Aug 5, 2024

jkczyz commented Aug 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

valentinewallace commented Aug 7, 2024

jkczyz commented Aug 7, 2024

TheBlueMatt commented Aug 8, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

valentinewallace left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkczyz commented Aug 14, 2024

TheBlueMatt commented Aug 14, 2024

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

valentinewallace commented Aug 14, 2024

jkczyz commented Aug 14, 2024

Authenticate `InvoiceError` messages #3192

Authenticate `InvoiceError` messages #3192

jkczyz commented Jul 18, 2024 •

edited

Loading

codecov bot commented Jul 18, 2024 •

edited

Loading