<p>The  <code>commitment_signed</code> message is also used at other places to move forward channel state. The entire process is not only described in BOLT02 but also in Mastering lightning</p>
<p><a href="https://github.com/lnbook/lnbook/blob/366a65b33045cbb9e95a3d4060005c240f1f1778/channel-operation.asciidoc" rel="nofollow noreferrer">https://github.com/lnbook/lnbook/blob/366a65b33045cbb9e95a3d4060005c240f1f1778/channel-operation.asciidoc</a></p>
<p>There you can see that after Alice sends and <code>update_add_htlc</code> message and a <code>commitment_signed</code> message Bob will later in the protocol also send a <code>commitment_signed</code> message so that Alice can also move forward her state. Remember Bob and Alice both have an asymmetrical version of the commitment transaction for each state and both need a signature from the other side. It would be strange if Bob replied with an <code>update_add_htlc</code> message to send over signatures even though he does not want to add an htlc.</p>
<p>So yes while signatures could have been included in the <code>update_add_htlc</code> message we still would have needed the  <code>commitment_signed</code> for Bob to reply. Also when stetteling htlcs the <code>commitment_signed</code> messages are needed again. I guess in that way it seems more reasonable to make the exchange of signatures explicit with its own message instead an reusing it. But of course that was a choice that could have been taken differently.</p>

CC BY-SA 4.0
2021-01-05T06:32:00.900Z
2021-01-05T06:32:00.900Z
Rene Pickhardt
<p><a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#normal-operation" rel="nofollow noreferrer">BOLT #2</a> indicates that a node will send one or more <code>update_</code> messages before a subsequent <code>commitment_signed</code>.</p>
<p>Since it seems like sending a payment over a channel involves <code>update_add_htlc</code> followed by <code>commitment_signed</code> (without needing a response from the peer in between), why do these need to be two separate messages?</p>

<lightning-network>
Why are `update_add_htlc` and `commitment_signed` separate messages?
Elliott
# Why are `update_add_htlc` and `commitment_signed` separate messages?

(Asked by: username_0 on 2021-01-05)

[BOLT #2](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#normal-operation) indicates that a node will send one or more `update_` messages before a subsequent `commitment_signed`.

Since it seems like sending a payment over a channel involves `update_add_htlc` followed by `commitment_signed` (without needing a response from the peer in between), why do these need to be two separate messages?

**Tags:** lightning-network


---

## 1 answers

### Answer by username_1 on 2021-01-05. Score: 2 | Accepted answer

The `commitment_signed` message is also used at other places to move forward channel state. The entire process is not only described in BOLT02 but also in Mastering lightning

<https://github.com/lnbook/lnbook/blob/366a65b33045cbb9e95a3d4060005c240f1f1778/channel-operation.asciidoc>

There you can see that after Alice sends and `update_add_htlc` message and a `commitment_signed` message Bob will later in the protocol also send a `commitment_signed` message so that Alice can also move forward her state. Remember Bob and Alice both have an asymmetrical version of the commitment transaction for each state and both need a signature from the other side. It would be strange if Bob replied with an `update_add_htlc` message to send over signatures even though he does not want to add an htlc.

So yes while signatures could have been included in the `update_add_htlc` message we still would have needed the `commitment_signed` for Bob to reply. Also when stetteling htlcs the `commitment_signed` messages are needed again. I guess in that way it seems more reasonable to make the exchange of signatures explicit with its own message instead an reusing it. But of course that was a choice that could have been taken differently.


---

