Disallow user-provided payer_signing_pubkey
#3264
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jkczyz
force-pushed
the
2024-08-remove-user-provided-payer-id
branch
from
ee91a75
to
0100dc4
Compare
jkczyz
force-pushed
the
2024-08-remove-user-provided-payer-id
branch
from
0100dc4
to
53ba3a9
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3264 +/- ##
==========================================
+ Coverage 89.85% 90.29% +0.44%
==========================================
Files 126 126
Lines 104145 107500 +3355
Branches 104145 107500 +3355
==========================================
+ Hits 93577 97070 +3493
+ Misses 7894 7724 -170
- Partials 2674 2706 +32 ☔ View full report in Codecov by Sentry. |
jkczyz
force-pushed
the
2024-08-remove-user-provided-payer-id
branch
3 times, most recently
from
9838435
to
174a0f4
Compare
The spec was recently changed to use offer_issuer_id instead of offer_node_id. LDK always used signing_pubkey to avoid confusion with a node_id. Rename it to issuer_signing_pubkey now as InvoiceRequest and Bolt12Invoice will have similarly named methods in upcoming commits.
Useful for determining if the signing_pubkey is the issuer_signing_pubkey or is from a blinded path.
For consistency with Offer::issuer_signing_pubkey, rename InvoiceRequest::payer_id to use "signing_pubkey" instead of "id".
For consistency with Offer::issuer_signing_pubkey, rename Refund::payer_id to use "signing_pubkey" instead of "id".
Using the tlv_stream macro without a type needing a reference results in a compilation error because of an unused lifetime parameter. To avoid this, add an optional lifetime parameter to the macro. This allows for experimental TLVs, which will be empty initially, and TLVs of entirely primitive types.
TlvRecord has a few fields, but comparing only the record_bytes is sufficient for equality since the other fields are initialized from it. Remove the Eq and PartialEq derives as they compare these other fields.
When constructing UnsignedInvoiceRequest or UnsignedBolt12Invoice, use a separate field for experimental TLV bytes. This allows for properly inserting the signature TLVs before the experimental TLVs when signing.
Add a utility function for iterating over Offer TLV records contained in any valid TLV stream bytes. Using a common function ensures th
Passing bytes directly to InvoiceContents::verify improves readability.
The BOLT12 spec defines an experimental TLV range that are allowed in offer messages. Allow this range when parsing an offer and include those bytes in any invoice requests. Also include those bytes when computing an OfferId and verifying that an InvoiceRequest is for a valid Offer.
Offer metadata is generated from the offer TLVs and should included those in the experimental range. When verifying invoice request and invoice messages, these TLVs must be included. Similarly, OfferId construction should included these TLVs as well. Modify the BOLT12 verification tests to cover these TLVs.
The BOLT12 spec defines an experimental TLV range that are allowed in invoice_request messages. Allow this range when parsing an invoice request and include those bytes in any invoice. Also include those bytes when verifying that a Bolt12Invoice is for a valid InvoiceRequest.
Payer metadata is generated from the invreq TLVs and should included those in the experimental range. When verifying invoice messages, these TLVs must be included. Modify the BOLT12 verification tests to cover them.
The BOLT12 spec defines an experimental TLV range that is allowed in offer and invoice_request messages. The remaining TLV-space is for experimental use in invoice messages. Allow this range when parsing an invoice and include it when signing one.
When creating an InvoiceRequests, users may choose to either use a transient signing pubkey generated by LDK or provide a static one. Disallow the latter as it allows users to reuse the same pubkey, which results in poor sender privacy.
Now that InvoiceRequest::payer_signing_pubkey is always a derived pubkey, there is no longer a need for PayerSigningPubkeyStrategy.
Now that invoice requests are signed using transient keys only, remove the corresponding signing method from NodeSigner since it is never used.
jkczyz
force-pushed
the
2024-08-remove-user-provided-payer-id
branch
from
174a0f4
to
4baba94
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When creating an
InvoiceRequests, users may choose to either use a transient signing pubkey generated by LDK or provide a static one. Disallow the latter as it allows users to reuse the same pubkey, which results in poor sender privacy.Based on #3237.
Fixes #3198.