Add explaination why evey htlc has to be signed in `commitment_signed` message

[lnbook]

Add explaination why evey htlc has to be signed in `commitment_signed` message

[Roasbeef]

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.

[Roasbeef]

@renepickhardt I don't have a stack exchange account, but if you feel this answers the question, then feel free to copy it over.

I provided more details that necessary, but we can use this in the book elsewhere to pain a complete picture.

The more succinct response is something like: "It allows us to have short CLTV delta values (shorter time locks), but longer CSV values (more time for watch towers and justice transactions). We achieve this by making HTLC claims take two phases for broadcasted commitments. The first phase requires a multi-sig spend, so we need to send them a signature for this HTLC multi-sig spend in addition to the commitment multi-sig spend".

[darosior]

@renepickhardt I don't have a stack exchange account, but if you feel this answers the question, then feel free to copy it over.

@Roasbeef I answered this SE question two days ago (and it was accepted), so I edited my answer to include your great high-level explanation of why two-stage HTLCs.

[Roasbeef]

The anchor output commitment format build upon this, and lets you update the fee for these HTLC claim transaction (sighash single+anyonecanpay), as well as aggregate them if they have the same absolute time lock value.

[Roasbeef]

@darosior dope! Yeah it's one of those things that may not be immediacy obvious if you haven't been following LN since the (pre-spec) early days.

[calvinrzachman]

@Roasbeef you just put an end to my multi-hour search for the rationale behind the two stage, multisig HTLC structure. Thank you, sir 🙌 Question: Does this mean the worst case commitment TX would have 967 in-flight HLTCs each requiring a sweeping spend from an individual HTLC-Success/Timeout transaction?

[renepickhardt]

I believe this is in channel operation and can be closed. I will assign to @aantonop for editorial for now