Why does every HTLC in a commitment transaction require its own signature?

Question

From BOLT 02 we can learn

When a node has changes for the remote commitment, it can apply them, sign the resulting transaction (as defined in BOLT #3), and send a commitment_signed message.

1. type: 132 (`commitment_signed`)
2. data:
   * [`channel_id`:`channel_id`]
   * [`signature`:`signature`]
   * [`u16`:`num_htlcs`]
   * [`num_htlcs*signature`:`htlc_signature`]

Why isn't the signature for the entire commitment transaction enough? I understand that every HTLC has its own htlc_pubkey and thus also htlc_secret and thus needs a signature in the HTLC success transaction but what was the rationale behind this design?

Answer 1

Why isn't the signature for the entire commitment transaction enough?

Because the htlc_signature field contains the signature for the HTLC transactions spending from the htlc output(s) (either received or offered) of the commitment transaction.

To expand a bit, some paths of the HTLCs scripts (timeout for an offered htlc output and success for a received HTLC output) pays to a 2of2, thus you need the right transaction which spends from this output to be signed before comiting to this (otherwise unspendable by using this script path) output.

---

EDIT: This question originates from this Github issue, to which Olaoluwa Osuntokun (@Roasbeef) gave today a detailed high-level explanation of why second-stage HTLCs are used in Lightning Network.

The following is the copy paste of his answer that might be of interest to anyone passing by.

Here's my attempt at a high level explanation:

We use something called two-stage HTLCs in the system. This allows us to decouple the CLTV (absolute timelock for HTLCs) from the CSV (commitment delay to allow for breach retribution). To see why this is an issue, consider if we had both of these in the top-level HTLC script. From here, one can imagine a scenario where we have an HTLC that can be timed out (absolute block height passed), but we can't spend it (timing it out) until our CSV period has also expired. Therefore, one needs to set their CSV values taking into account the absolute timelock (CLTV) value as well. Critically, before a user can cancel their incoming off-chain HTLC (timing out the outgoing on-chain), they need to wait for this CSV period. However, if the CSV is greater than the time lock delta (diff between incoming and outgoing HTLCs), they've created a race and could possibly lose money.

Without HTLCs, the dependency between the CLTV delta value and the CSV value means that if one wants to have a higher CSV value (more time to punish malicious channel peers), then they also need to have a longer CLTV delta value. As an example, a common set up with lnd is that for super higher value channels we have a CSV value of 2016 blocks (two weeks). Without second-level HTLCs, we would need to also make our CTLV delta value (40 blocks default atm), greater than 2016 blocks. This change would then propagate through the entire network, resulting in very long time lock values. The sender of an HTLC eats the full time lock delay, meaning that know their absolute worst case is much higher, trading off for better multi-hop HTLC security.

Thankfully, we figured out a solution to this: two-stage HTLCs. Note that the HTLC scripts I described above were never actually deployed. Two-stage HTLCs are actually used in the original LN white paper for a similar reason. The defective design described above was created when developers were trying to compress down the scripts and on-chain footprint a bit.

A two-stage HTLC decouples the CSV period from one's CTLV time-lock delta. To do this, we now require the party that forced closed to spend their HTLC with a special transaction. This transaction spends a CLTV clause in the script, and itself includes a nLocktime value as well. The output of this special transaction then pays to the party timing our or redeeming the HTLC, but then enforces a CSV period. We call them two stage as we enforce two states in the claim: wait for absolute timeout value, then wait for CSV value. Note that once the absolute timeout value passes, the party can spend the original HTLC output, transitioning the HTLC claim state machine to the CSV waiting period. At this point, they can safely cancel back any off-chain HTLCs, as the other party isn't able to settle it with a pre-image at this point.

The way we enforce this spend, is that we make any HTLC spends from one's commitment transaction (which you broadcast during a force close) actually be a multi-sig output. We use this output to create what's essentially an "off-chain multi-sig covenant". Since they require our signature to spend this output, we force them into a particular type of spend using pre-signed transactions. As a result, each time we want to give them a new commitment, in addition to the commitment signature (multi-sig spending teh funding output), we also send a series of signatures, one for each HTLC, that blesses their spend of the HTLC output.