<blockquote>
  <p>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?</p>
</blockquote>

<p>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. </p>

<p>For that reason, lightning network specification <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc" rel="nofollow noreferrer">puts a limit of 483 HTLCs</a> for a commitment transaction, so that even if both sides send the maximum number of HTLCs, the <code>commitment_signed</code> message will still be under the maximum message size.</p>

CC BY-SA 4.0
2019-07-18T14:32:07.313Z
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
CC BY-SA 4.0
2019-11-14T14:18:13.373Z
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](https://github.com/lightningnetwork/lightning-rfc/blob/35f6376f2050191081b148fb540f604092be59e1/08-transport.md#lightning-message-specification).
Sergei Tikhomirov
CC BY-SA 4.0
2019-07-18T14:21:22.927Z
2019-08-16T12:49:58.163Z
2019-08-16T12:49:58.163Z
Ugam Kamat
<p>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 <code>R</code>? Does it mean that the HTLC contracts get simply "carried over" in the subsequent transactions between A and B?</p>

<lightning-network><hash-time-locked-contract>
Do HTLCs get "carried over" in the subsequent commitment transactions?
spacemonkey
# Do HTLCs get "carried over" in the subsequent commitment transactions?

(Asked by: username_0 on 2019-07-18)

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?

**Tags:** lightning-network, hash-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2019-07-18. Score: 2 | Accepted answer

> 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](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc) 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.

> **Comments:**
> **username_2**: 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.  
> **username_3**: 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](https://github.com/lightningnetwork/lightning-rfc/blob/35f6376f2050191081b148fb540f604092be59e1/08-transport.md#lightning-message-specification).  

---

