Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature]: invoice interceptor #7923

Open
arshbot opened this issue Aug 24, 2023 · 1 comment
Open

[feature]: invoice interceptor #7923

arshbot opened this issue Aug 24, 2023 · 1 comment
Labels
enhancement Improvements to existing features / behaviour invoices P2 should be fixed if one has time

Comments

@arshbot
Copy link
Contributor

arshbot commented Aug 24, 2023

Is your feature request related to a problem? Please describe.
For our JIT channel implementation, Flow2.0 we require the use of wrapped invoices. Wrapped invoices are modified invoices that route the initial payment to the LSP (trustlessly) so the final hop can be made to the final recipient via zero-conf channel.

Unfortunately, there isn't a method to modify the invoice while updating LND. This means the wrapped invoice can only be distributed via explicit integrations with the LSP, making usage of JIT channels highly impractical.

Describe the solution you'd like
An invoice interceptor which behaves very much like the channel acceptor api. A simple high level flow might be:

  1. Sender requests an invoice to send funds via btcpay server
  2. Btcpay server requests invoice from Recipient node
  3. Recipient node creates a classic bolt11 invoice
  4. Recipient node submits the invoice to the invoice modifier (could be LSP)
  5. Invoice modifier makes changes to invoice. For example changing the destination pubkey
  6. Recipient node validates invoice (for example ensuring preimage hash has not been modified)
  7. Recipient node stores invoice and issues response to Btcpay server

Sequence Diagram:

sequenceDiagram
    participant Sender
    participant BtcpayServer as Btcpay server
    participant RecipientNode as Recipient node (LND)
    participant InvoiceModifier as Invoice modifier (LSP)

    Sender->>BtcpayServer: Request invoice to send funds
    BtcpayServer->>RecipientNode: Request invoice
    RecipientNode->>RecipientNode: Create classic bolt11 invoice
    RecipientNode->>InvoiceModifier: Submit invoice for modification
    InvoiceModifier->>RecipientNode: Return modified invoice (e.g., changed destination pubkey)
    RecipientNode->>RecipientNode: Validate invoice (e.g., check preimage hash)
    RecipientNode->>BtcpayServer: Store invoice and issue response
    BtcpayServer->>Sender: Show Sender the modified invoice that supports the LSP function

Describe alternatives you've considered

  1. Static config variables for every invoice created, defined in conf
  2. Direct LSP integrations with every service atop LND

Additional context
This feature request is for our JIT channels LSP, but could be very useful to any system that wants to fiddle with how the recipient system routes payments. This feature would be very useful for 3rd party logic for hop-hints or virtual nodes. It allows for flexibility in implementing alternative solutions to complex payment acceptance needs.

@arshbot arshbot added the enhancement Improvements to existing features / behaviour label Aug 24, 2023
@saubyk saubyk added P2 should be fixed if one has time invoices labels Aug 25, 2023
@Roasbeef
Copy link
Member

Reborn here: #8616

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvements to existing features / behaviour invoices P2 should be fixed if one has time
Projects
None yet
Development

No branches or pull requests

3 participants