Merge PR 'offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice' (#4942)
What changed, and why it matters
This commit is a simple rename of a public function from `matches_invoice_signing_pubkey` to `key_can_sign_invoice`, plus matching updates to its documentation, callers, tests, and changelog. No behavior changed. It is not a security fix.
No security action needed. Treat as a routine API naming/documentation change.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The change is a pure API rename in rust-lightning’s BOLT 12 offers module. The function body, logic, and semantics remain identical; only the identifier and descriptive comments are updated to clarify that the method checks whether a given key is authorized to sign an invoice for the offer. A pending changelog entry is also updated to reflect the new name.
Changed components
lightning/src/offers/offer.rslightning-payer-proof/src/lib.rspending_changelog/offer-key-can-sign-invoice.txtInspect captured patch +13 / −13
### lightning-payer-proof/src/lib.rs
@@ -208,7 +208,7 @@ impl VerifiedPayerProof {
/// are indistinguishable here, so a `true` answers "this was paid to whoever `offer` names"
/// rather than "this paid `offer`".
pub fn pays_offers_recipient(&self, offer: &Offer) -> bool {
- offer.matches_invoice_signing_pubkey(&self.0.issuer_signing_pubkey())
+ offer.key_can_sign_invoice(&self.0.issuer_signing_pubkey())
}
/// Whether the invoice this proof covers was issued by the recipient of the offer encoded as
### lightning/src/offers/offer.rs
@@ -750,11 +750,11 @@ impl Offer {
self.contents.expects_quantity()
}
- /// Returns whether `invoice_signing_pubkey` is the recipient of this offer.
+ /// Returns whether `invoice_signing_pubkey` can sign an invoice for this offer.
///
/// Per BOLT 12 that is [`Self::issuer_signing_pubkey`] when the offer has one, and otherwise
/// the final blinded node id of one of [`Self::paths`].
- pub fn matches_invoice_signing_pubkey(
+ pub fn key_can_sign_invoice(
&self, invoice_signing_pubkey: &bitcoin::secp256k1::PublicKey,
) -> bool {
super::invoice::check_invoice_signing_pubkey(
@@ -2091,11 +2091,11 @@ mod tests {
}
#[test]
- fn matches_invoice_signing_pubkey_issuer_id_or_path_last_hop() {
+ fn key_can_sign_invoice_issuer_id_or_path_last_hop() {
let issuer = pubkey(42);
let with_issuer = OfferBuilder::new(issuer).build().unwrap();
- assert!(with_issuer.matches_invoice_signing_pubkey(&issuer));
- assert!(!with_issuer.matches_invoice_signing_pubkey(&pubkey(43)));
+ assert!(with_issuer.key_can_sign_invoice(&issuer));
+ assert!(!with_issuer.key_can_sign_invoice(&pubkey(43)));
// An issuer id wins even when paths are present.
let with_both = OfferBuilder::new(issuer)
@@ -2109,8 +2109,8 @@ mod tests {
))
.build()
.unwrap();
- assert!(with_both.matches_invoice_signing_pubkey(&issuer));
- assert!(!with_both.matches_invoice_signing_pubkey(&pubkey(44)));
+ assert!(with_both.key_can_sign_invoice(&issuer));
+ assert!(!with_both.key_can_sign_invoice(&pubkey(44)));
let paths_only = OfferBuilder::new(issuer)
.path(BlindedMessagePath::from_blinded_path(
@@ -2132,10 +2132,10 @@ mod tests {
.clear_issuer_signing_pubkey()
.build()
.unwrap();
- assert!(paths_only.matches_invoice_signing_pubkey(&pubkey(44)));
- assert!(paths_only.matches_invoice_signing_pubkey(&pubkey(46)));
- assert!(!paths_only.matches_invoice_signing_pubkey(&pubkey(43)));
- assert!(!paths_only.matches_invoice_signing_pubkey(&issuer));
+ assert!(paths_only.key_can_sign_invoice(&pubkey(44)));
+ assert!(paths_only.key_can_sign_invoice(&pubkey(46)));
+ assert!(!paths_only.key_can_sign_invoice(&pubkey(43)));
+ assert!(!paths_only.key_can_sign_invoice(&issuer));
}
#[test]
### pending_changelog/offer-key-can-sign-invoice.txt
@@ -1,4 +1,4 @@
# API Updates
- * `Offer::matches_invoice_signing_pubkey` answers whether an invoice signing key is the offer's
+ * `Offer::key_can_sign_invoice` answers whether an invoice signing key can sign for the offer's
recipient, binding an invoice it signed to the offer: the issuer id when the offer has one,
otherwise a path's final blinded node id.Why this scored 20/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.