Sending to Offer without signing_pubkey
#3017
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #3017 +/- ##
==========================================
+ Coverage 89.13% 89.49% +0.35%
==========================================
Files 118 118
Lines 97492 100077 +2585
Branches 97492 100077 +2585
==========================================
+ Hits 86903 89564 +2661
+ Misses 8349 8261 -88
- Partials 2240 2252 +12 ☔ View full report in Codecov by Sentry. |
jkczyz
force-pushed
the
2024-04-optional-pubkey
branch
from
94d12f9
to
825eb2f
Compare
jkczyz
force-pushed
the
2024-04-optional-pubkey
branch
from
825eb2f
to
a70af2b
Compare
|
Feel free to squash imo |
If an Offer contains a path, the blinded_node_id of the path's final hop can be used as the signing pubkey. Make Offer::signing_pubkey and OfferContents::signing_pubkey return an Option to support this. Upcoming commits will implement this behavior.
If an offer has at least one path, it may omit the signing pubkey and use the blinded node id of the last hop of a path to sign an invoice. Allow parsing such offers but not yet creating them.
Instead of reusing OfferTlvStream::paths, add a dedicated paths TLV to InvoiceRequestTlvStream such that it can be used in Refund. This allows for an Offer without a signing_pubkey and still be able to differentiate whether an invoice is for an offer or a refund.
When parsing a Bolt12Invoice use both the Offer's signing_pubkey and paths to determine if it is for an Offer or a Refund. Previously, an Offer was required to have a signing_pubkey. But now that it is optional, the Offers paths can be used to make the determination. Additionally, check that the invoice matches one of the blinded node ids from the paths' last hops.
jkczyz
force-pushed
the
2024-04-optional-pubkey
branch
from
a70af2b
to
b7635c4
Compare
| .iter() | ||
| .filter_map(|path| path.blinded_hops.last()) | ||
| .any(|last_hop| fields.signing_pubkey == last_hop.blinded_node_id) |
There was a problem hiding this comment.
In the spec, it looks like we MUST verify that the signing pubkey matches a path we sent an invoice request to. I'm not certain it matters or if the spec should change but it looks like we don't specifically check that at the moment.
There was a problem hiding this comment.
Yeah, this is a slight deviation as we don't have the blinded node id for the path that the invoice was sent over when parsing. We could do some sort of check at the handler level, but even that would require piping that data through.
| ); | ||
| pending_offers_messages.push(message); | ||
| } else { | ||
| debug_assert!(false); |
There was a problem hiding this comment.
Its usually worth having a comment on these kinds of assertions as to why we think its not reachable.
…pubkey Sending to `Offer` without `signing_pubkey`
If an
Offercontains apath, theblinded_node_idof the path's final hop can be used when signing an invoice. This helps to further reduce offer QR code size by makingoffer_node_idoptional whenoffer_pathsis set. Allow parsing (and thus sending to) such offers. Also replacesRefund's use ofoffer_pathswith a newinvreq_pathsTLV in order to differentiate aBolt12Invoicefor anOfferfrom one for aRefund.Receiving to an
Offerwithout asigning_pubkeyis not supported yet.