Feature: Ability to Pay Offers

[carlaKC]

Feature Description

Add payment of offers (with blinded paths) to LNDK.

Design

If applicable, include a design proposal for how the feature will be added to the project.

Dependencies

Blinded Routes in LND
lightningnetwork/lnd/issues/7201

Bolt 12 invoices always use blinded paths, so we need to be able to pay them via LND. We can't use something like SendToRouteV2 because the route for blinded paths will appear invalid to LND (no amount / expiry set in some places) and we need to add TLV records in the protocol range (CustomRecords wouldn't cut it).

BOLT 12 in LDK
lightningdevkit/rust-lightning/issues/1970

To be able to shamelessly piggyback on the hard work of the LDK team, we'll need offers fully impemented (albeit, only the sending direction). Note: we don't need the miscelaneous category on that checklist completed.

Subtasks

• Payment to blinded paths via LND.
• Add offers messaging exchange in existing OnionMessenger (plugging in LND components like pathfinding for OM replies)
• User-facing payoffer command.

[carlaKC]

I'll fill this out a bit more + add subtasks with more detail as we close in on design.

[carlaKC]

Rough outline of what this will look like:

Aside from the offer parsing + creation of an invoice request, the main thing that we'll need to do is create our own implementation of the OffersMessageHandler that will handle incoming offers related onion messages.

[carlaKC]

Pretty much every line in this diagram can be a separate PR so that we can eat the elephant one bite at a time.

Eg:

• Add offer parsing (+ a way for the user to provide that offer string)
• Add invoice request creation from the parsed offer
• Add state machine for the invoice request etc etc

With the goal of keeping it as simple as possible, ie:

• On restarts forget all offers and reject any unknown invoice requests
• Only fire an invoice request once (to start with at least)
• Just send the payment in one shot (no MPP)
  and anything else that makes life easier.

[orbitalturtle]

🐘

(+ a way for the user to provide that offer string)

@carlaKC Starting to take a look at this - for this first task, I'm thinking through the "+ a way for the user to provide that offer string" part. We discussed eventually having a grpc api or something similar that users can interact with. But maybe a CLI for passing in the offer would be easier for starters? What do you think of a little lndk-cli binary that takes in the offer? Longterm goal would be to have a lndk-cli pay. But we could start with just a lndk-cli decodeoffer command

[carlaKC]

We discussed eventually having a grpc api or something similar that users can interact with. But maybe a CLI for passing in the offer would be easier for starters?

Yeah def, grpc feels like too much of a commitment to start with.

One thing to consider here is that forwarding of onion messages is a "long lived" task (ie, we want to run forever) and I think that we can only have one custom message stream with LND (worth confirming that) so we wouldn't be able to run a payoffer cli and forward onion messages at the same time.

For starters how about a CLI where one of the options is forward-messages? It's kinda clankey to forward messages, kill that, pay an offer but if we can only have one custom message stream that's how it's gonna be.

[orbitalturtle]

Ah interesting. I'll keep that in mind + try to confirm the one custom message stream limitation. Any idea if there's any hope/chance we can change the one stream at a time limitation on LND's side?

[carlaKC]

Ah interesting. I'll keep that in mind + try to confirm the one custom message stream limitation. Any idea if there's any hope/chance we can change the one stream at a time limitation on LND's side?

Not quickly / easily (their releases are scoped out till 2024). Def confirm that it exists (I could be wrong) but I think that's the sitch.

[orbitalturtle]

Closing this since have an MVP working: https://github.com/lndk-org/lndk/blob/master/docs/test_pay_offer.md