Feature Request: Support for HODL Invoices and Proxy Invoices

[bitwalt]

We would like to open a discussion and propose the addition of HODL invoices and Proxy invoices support in the RGB Lightning Node (RLN). These features would enable better coordination for atomic swaps and advanced cross-protocol HTLC-based interactions (e.g. RGB <> Taproot Assets swaps).

---

Draft API Design proposal

1. HODL Invoice

• POST /hodlinvoice: Create a HODL invoice. It will not be automatically settled when paid.
• POST /settleinvoice: Manually settle a previously created HODL invoice (if paid).
• POST /cancelinvoice: Cancel a HODL invoice, even if it's been paid.

2. Proxy Invoice

• POST /proxyinvoice: Takes a Lightning invoice as input and returns a new proxy HODL invoice with the same payment hash.
  • When the proxy is paid, RLN should pay the original invoice.
  • When the original invoice is settled and the preimage is known, the proxy invoice is then settled using the same preimage.

---

🔗 References

• Bitcoin Ops: [Hold Invoices]
• LND API: [addHoldInvoice]
• LN Proxy Specification: [lnproxy/spec]
• Related use case in RGB swaps: [RGB TaprootAssets Atomic Swaps]

[zoedberg]

Thanks for opening this.

HODL invoices are very interesting, some time ago we also considered to use them to improve the current RGB assets swap system (as kindly suggested by @adambor).
LDK doesn't have this as an out-of-the-box feature, but it should be possible to add them using some low-level methods.

There's no ETA for this task at the moment, since we're still handling more important stuff, but we are certaintly interested in this.

[adambor]

I would just further add:

• the POST /hodlinvoice could take the payment hash as a parameter
• the payment pre-image can be revealed through POST /settleinvoice (same as in LND)

This makes the whole construction more powerful and completely removes the need for POST /proxyinvoice, as this can then be handled at the application level.