Feature Request: Support for HODL Invoices and Proxy Invoices

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]

Start by reviewing the proposed /hodlinvoice, /settleinvoice, /cancelinvoice, and /proxyinvoice entry points alongside the linked HODL invoice and LN Proxy references. Define the API and payment-flow requirements first; the work is done when the project has an agreed design and both invoice types' stated settlement, cancellation, and forwarding behavior are implemented and verified.