6

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?

5

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.

  • 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 Oct 21 at 17:16
  • 1
    @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 Oct 21 at 17:53
  • 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. – Ugam Kamat Oct 21 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.