<p>I didn't attend the conference but here is my take on Hodl invoices. In a normal Lightning payment, the sender pays an invoice which contains the payment hash and the payee releases the pre-image to that payment hash for the successful resolution of the payment. In a hodl invoice the sender pays an invoice to the receiver, but the receiver does not release the pre-image instantly. Instead it waits for other conditions to be satisfied for the payment to be released. To cite an example, let us say you are in an apparel shop and you did not find a T-shirt of your size. The owner tells you that they need to check in their inventory to see if the item is available and they will courier it to you if it is available. But for they ask you to pay in advance. In this case, you pay the invoice, but the shop owner will only release the pre-image if the item is available.</p>

<p>This can possibly create some routing issues. Since hodl payments are identical to normal payments, intermediate nodes cannot tell the difference. So, by forwarding hodl payments the intermediate nodes are locking in their liquidity in invoices that will take long time to settle, thus hindering their ability to route more payments. Even if the amount is small, Lightning implementation allows only 483 concurrent HTLC payments to conform with the standard transaction size, which will take up the transaction number space. Although this might not be an issue now, but as Lightning gets more adoption it might have he potential to squeeze the liquidity out of the network.</p>

<p>Another issue that I see is that if the receiver does not cancel the payment or send the pre-image within the <code>min_final_cltv_expiry</code>, than the penultimate node will force close the channel with the receiver through an on-chain settlement. If the penultimate node had opened the channel, then under the current specs, it is liable to pay the fees associated with it (including the HTLCs). Moreover, with hodl invoices you are trusting the receiver to do the right thing in terms of releasing the pre-image or not, based on other physical/virtual conditions. </p>

CC BY-SA 4.0
2019-10-21T17:16:45.313Z
Thanks. Just to clarify, when you said that "intermediate nodes cannot tell the difference" I was first thinking that they should be distinguishable based on the ctlv_expiry. But apparently the default is on the order of hours, which is already way further down on the HODL scale than a normal lightning payment.
nickler
CC BY-SA 4.0
2019-10-21T17:53:59.893Z
@nickler (1/2) What you are saying is the `min_final_cltv_expiry` which is specified by the recipient. Intermediate nodes are not aware of that when adding the HTLC. What they know is the `cltv_expiry` which is calculated by summing the `cltv_expiry_delta` of each intermediate node and `min_final_ctlv_expiry` of the recipient. Now, in a normal operation, if there are 19 intermediate nodes (max) in the path, then using 12 blocks (default suggested by the specs) that is equal to 228 blocks (1.5 days) + 9 (default for final node) = 237 blocks.
Ugam Kamat
CC BY-SA 4.0
2019-10-21T17:56:39.977Z
(2/2) Compare that to a hodl invoice add where the final node wants 1 day of time (144 blocks) and there is only one intermediate node that uses 12 blocks of `cltv_expiry_delta`. That comes to 156 blocks. Now, since the intermediate node does not know where it lies in the routing path, it does not know if the first case (237 blocks) is the normal invoice vs second case (156 blocks) which is a hodl invoice. So you cannot actually justify just based on the `cltv_expiry`.
Ugam Kamat
CC BY-SA 4.0
2023-04-23T13:17:37.747Z
HODL Invoices wld be a great way to get non-custodial escrow services onto ln. Is this still bad practice? There a better way to do it? 
Any idea if PTLCs would enable more than 483 concurrent HODL invoices?
I'm imagining that a lot of apps on Nostr will require escrow (marketplaces, Amazon, etc..) and would be best to keep it non-custodial escrow for least amount of screw-ability. And best to keep it on L2 to keep it near free.
I'm just assuming 'escrow' lightning node services will spring up and will over time have to pay more for channels due to the illiquidity they cause
Patrick Geyer
CC BY-SA 4.0
2019-10-21T15:30:58.600Z
2019-10-21T18:00:10.043Z
2019-10-21T18:00:10.043Z
Ugam Kamat
<p>As far as I understand hodl invoices enable some interesting use cases. However, I heard that they can be detrimental to the network. Is that correct and in what way? Additionally, at a talk at the Lightning Conference 2019 it was mentioned that people should avoid relying on them in the future. Why?</p>

<lightning-network><lightning-network-daemon><lightning-routing>
What are the downsides of Hodl Invoices?
nickler
# What are the downsides of Hodl Invoices?

(Asked by: username_0 on 2019-10-21)

As far as I understand hodl invoices enable some interesting use cases. However, I heard that they can be detrimental to the network. Is that correct and in what way? Additionally, at a talk at the Lightning Conference 2019 it was mentioned that people should avoid relying on them in the future. Why?

**Tags:** lightning-network, lightning-network-daemon, lightning-routing


---

## 1 answers

### Answer by username_1 on 2019-10-21. Score: 9

I didn't attend the conference but here is my take on Hodl invoices. In a normal Lightning payment, the sender pays an invoice which contains the payment hash and the payee releases the pre-image to that payment hash for the successful resolution of the payment. In a hodl invoice the sender pays an invoice to the receiver, but the receiver does not release the pre-image instantly. Instead it waits for other conditions to be satisfied for the payment to be released. To cite an example, let us say you are in an apparel shop and you did not find a T-shirt of your size. The owner tells you that they need to check in their inventory to see if the item is available and they will courier it to you if it is available. But for they ask you to pay in advance. In this case, you pay the invoice, but the shop owner will only release the pre-image if the item is available.

This can possibly create some routing issues. Since hodl payments are identical to normal payments, intermediate nodes cannot tell the difference. So, by forwarding hodl payments the intermediate nodes are locking in their liquidity in invoices that will take long time to settle, thus hindering their ability to route more payments. Even if the amount is small, Lightning implementation allows only 483 concurrent HTLC payments to conform with the standard transaction size, which will take up the transaction number space. Although this might not be an issue now, but as Lightning gets more adoption it might have he potential to squeeze the liquidity out of the network.

Another issue that I see is that if the receiver does not cancel the payment or send the pre-image within the `min_final_cltv_expiry`, than the penultimate node will force close the channel with the receiver through an on-chain settlement. If the penultimate node had opened the channel, then under the current specs, it is liable to pay the fees associated with it (including the HTLCs). Moreover, with hodl invoices you are trusting the receiver to do the right thing in terms of releasing the pre-image or not, based on other physical/virtual conditions.

> **Comments:**
> **username_0**: Thanks. Just to clarify, when you said that "intermediate nodes cannot tell the difference" I was first thinking that they should be distinguishable based on the ctlv_expiry. But apparently the default is on the order of hours, which is already way further down on the HODL scale than a normal lightning payment.  
> **username_1**: @username_0 (1/2) What you are saying is the `min_final_cltv_expiry` which is specified by the recipient. Intermediate nodes are not aware of that when adding the HTLC. What they know is the `cltv_expiry` which is calculated by summing the `cltv_expiry_delta` of each intermediate node and `min_final_ctlv_expiry` of the recipient. Now, in a normal operation, if there are 19 intermediate nodes (max) in the path, then using 12 blocks (default suggested by the specs) that is equal to 228 blocks (1.5 days) + 9 (default for final node) = 237 blocks.  
> **username_1**: (2/2) Compare that to a hodl invoice add where the final node wants 1 day of time (144 blocks) and there is only one intermediate node that uses 12 blocks of `cltv_expiry_delta`. That comes to 156 blocks. Now, since the intermediate node does not know where it lies in the routing path, it does not know if the first case (237 blocks) is the normal invoice vs second case (156 blocks) which is a hodl invoice. So you cannot actually justify just based on the `cltv_expiry`.  
> **username_2**: HODL Invoices wld be a great way to get non-custodial escrow services onto ln. Is this still bad practice? There a better way to do it?  Any idea if PTLCs would enable more than 483 concurrent HODL invoices? I'm imagining that a lot of apps on Nostr will require escrow (marketplaces, Amazon, etc..) and would be best to keep it non-custodial escrow for least amount of screw-ability. And best to keep it on L2 to keep it near free. I'm just assuming 'escrow' lightning node services will spring up and will over time have to pay more for channels due to the illiquidity they cause  

---

