Hold Invoices
A hodl invoice (or hold invoice) is an implementation extension to a Lightning Invoice where the final step of an HTLC resolution is withheld by the payment receiver, such that the payment sender is fully committed, and cancelled or executed conditionally at a later time.
A hodl invoice is not distinguishable from a normal one to a payment sender other than it will have a longer-than-normal expiry parameter.
Successful HTLC resolution in a payment channel is complete when a payment receiver exposes a preimage that hashes to a payment_hash of an Invoice and withdrawing the locked funds. When a sender's funds are committed there is no option but to wait until hashlock resolution (completing the payment) or timelock tl expiration (canceling the payment). By setting a long enough tl, a payment receiver has the option to withhold (or cancel) resolution after funds have been committed until a time t such that t < tl, otherwise tl expires (t >= tl) and funds are returned back to the sender. The conditions by which the receiver settles or cancels the invoice can be arbitrary or cryptographically conditional (ie. the receiver does not know the preimage and must obtain it to settle the payment).
Return processes for settled purchases of out-of-stock inventory can be cumbersome. A merchant could use a hodl invoice to only accept payment after it has verified the inventory is in stock, or instantly refund the purchaser otherwise.
A user gains access to a service by paying a hodl invoice. If the user is malicious the service settles the invoice, otherwise it is canceled when the user is finished and funds return to the user.
Consider an item delivery Shop, a Customer could generate a hash of a preimage and send it to the Shop. The Shop generates an invoice with payment_hash equal to hash and Customer pays it, however the Shop cannot settle it without preimage. Upon item delivery the Customer reveals the preimage to the Shop Courier who then settles the invoice.
Consider an item Shop, an independent Courier, and a shop Customer:
Customer generates a
preimageand sendshashofpreimageto the ShopShop creates hodl invoice
invoice0and Customer pays itShop sends
hashto the Courier who creates another hodl invoiceinvoice1(for delivery costs) with the samepayment_hashand Shop pays itUpon delivery the Customer gives the
preimageto the Courier who settlesinvoice1revealing the preimage to Shop who then settlesinvoice0.
Submarine Swap Variation
Alice creates a
preimageand sendshashto BobBob creates a hodl invoice with
payment_hashequal tohashAlice pays the hodl invoice
Bob creates an on-chain HTLC with
hashlockequal tohashand funds itAlice uses
preimageto sweep funds from the on-chain HTLCBob uses revealed
preimageto settle the hodl invoice
Reusing a payment_hash across multiple invoices to create conditional payment chains incurs risk for all parties receiving the preimage after it has been revealed once as intermediate nodes on mutual payment paths will access the preimage that can be used to claim funds before the respective HTLC resolution is complete, thereby potentially blocking settlement by the hodl invoice holder.
The Lite Podcast with Joost Jager.
