Open TheBlueMatt opened 1 year ago
We also need to do spontaneous/unsolicited invoices, i.e., BOLT11-style invoices not in response to an InvoiceRequest
but rather scanned directly by the user. This was a late addition to the spec. https://github.com/lightning/bolts/pull/798/commits/7b0c0fc2b846ec30a2a729d733f4880599734269
I think we can punt on this for now similar to non-Bitcoin-denominated offers. Or a volunteer can work on it in parallel. It would be similar to Refund
in that it will have its own struct (probably named SpontaneousInvoice
) and share the underlying TLV streams. Like Refund
it has it's own bech32 prefix (lni
instead of lnr
).
For bindings, we probably only need non-builder constructors for Offer
and Refund
as LDK would handle constructing the others. Though it would still be nice to expose them directly if someone wants to use them without a ChannelManager
. Just may be a lower priority.
Right, like BOLT11 we'll eventually have folks who want to use them, so we definitely need to support it, but it won't be the "common case". I'm not convinced we shouldn't drop the builders and replace them entirely or at least have a simple util method that calls the builder as appropriate, should be pretty trivial if we go the util method route.
We may also eventually want utilities similar to lightning-invoice::utils::create_invoice_from_channelmanager
that will automatically supply the payment hash and blinded payment paths
FYI, I repurposed this issue to track all work for BOLT 12 Offers. @valentinewallace Could you update the route blinding portion as needed (i.e., split into more tasks and add PRs)?
Also on the blinded path flow - https://github.com/lightningdevkit/rust-lightning/pull/2534#discussion_r1328985888
The following tasks are required to implement BOLT 12 Offers in LDK:
Offer
encoding and building #1719, #1972InvoiceRequest
encoding, parsing, and building #1738Refund
encoding, parsing, and building #1908, #1972Invoice
encoding, parsing, and building #1926, #1927, #2162, #2206BlindedPath
construction #1503BlindedPath
construction #2412, #2514PaymentConstraint::htlc_minimum_msat
to the max min_htlc for the other nodes in its anonymity set (e.g. for a blinded route A>B>C, set B's min_htlc to the max min_htlc for A's peers)BlindedRoute
pathfinding #2146, #2239, #2258, #2305, #2120PaymentParameters
similar to the existingpreviously_failed_channels
field: #2818BlindedRoute
paymentsSHOULD
in the spec)PaymentParameters
(i.e. strip the blinded path off before sending the probe)InvoiceRequest
andInvoice
message handling interface #2294ChannelManager
implementation of message handling #2468, #2371, #2039Offer
andRefund
builder utilities #2578Offer
andRefund
messages #2690InvoiceRequest
onion message reply paths #2690Bolt12Invoice
messages #2690InvoiceError
with outbound payment using reply paths #2837InvoiceRequest
retries #2836Offer
path_id
#3139The things left for us to ship BOLT12, in an issue so we don't lose track of things:unsolicited invoicesstruct deserialization fuzzersfuzzers for the builders, if its doableonion message handler for BOLT12 messagesMetadata storage in Offers which can be used to check the correctness of invoice requestsnon-builder offer/invoice_request/invoice constructor for bindings - cc #1868Blinded path paymentBlinded path receivingBlinded path forwarding (not strictly required but probably required to test the above and we need it eventually)After we go public, we should also:Support for non-Bitcoin offers (my fault, I thought the sender had to convert, vs passing no amount in the invoice_request)Anything I'm missing here @jkczyz?