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?
1
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.
1Well said! Just for completeness. The htlcs themselves are "carried over" via
update_add_htlcmessages defined in BOLT 02 and revoked viarevoke_and_ackmessage. – Rene Pickhardt – 2019-07-18T14:32:07.313Where 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 – 2019-11-14T14:18:13.373