1

With regular commitment transactions, current transaction invalidates the previous one. This is fine, since TXs between A and B in their channel happen one after another. However, HTLCs are sort of delayed transactions. How then further transactions can happen without waiting for the secret R? Does it mean that the HTLC contracts get simply "carried over" in the subsequent transactions between A and B?

Improve this question

1 Answer 1

Reset to default
2

How then further transactions can happen without waiting for the secret R? Does it mean that the HTLC contracts get simply "carried over" in the subsequent transactions between A and B?

Yes, that is correct. You go on adding HLTC outputs in the commitment transactions as more and more HTLCs are added, and delete those HTLCs that are either fullfiled with a successful pre-image or those that are failed. Every time, you add/delete an HTLC, a new commitment transaction has to be signed and the previous commitment transactions have to be revoked.

For that reason, lightning network specification puts a limit of 483 HTLCs for a commitment transaction, so that even if both sides send the maximum number of HTLCs, the commitment_signed message will still be under the maximum message size.

Improve this answer
2
  • 1
    Well said! Just for completeness. The htlcs themselves are "carried over" via update_add_htlc messages defined in BOLT 02 and revoked via revoke_and_ack message.
    – Rene Pickhardt
    Jul 18, 2019 at 14:32
  • Where is the "maximum message size" defined and what happens if it is increased? Would it simply result in a heavier P2P protocol? -- Let me answer my own question: 65535 bytes, rationale.
    – Sergei Tikhomirov
    Nov 14, 2019 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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