<p>As explained in my June 2020 Lightning dev mailing list <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html" rel="nofollow noreferrer">post</a> &quot;Pinning: The Good, The Bad, The Ugly&quot;, pinning at the commitment level is concerning in the case of a Lightning routing hub, not being able to confirm a HTLC-Success on the upstream link. This is a third case of a time sensitive issue, beyond receiving the preimage and getting your justice confirmed.</p>
<p>The attack scenario works like this. Malicia and Mallory open two channels to Bob, a honest routing hub. Malicia draws a payment path for a 1 BTC HTLC through Bob to Mallory. This payment path enforces Bob's <code>cltv_delta</code> policy of 40 blocks. Assuming N the chain tip during the setup phase, the HTLC timelock expires at N + 60 on the first hop, N + 40 on the second hop. Once the payment path is locked down, Mallory broadcasts her commitment transaction and a HTLC-Success transaction, and Bob will discover onchain the HTLC preimage.</p>
<p>Simultaneously, Malicia broadcasts a low feerate commitment transaction among the network mempools bottom feerate groups <em>and</em> a low feerate, high absolute fee CPFP transaction. This malicious CPFP transaction's absolute fee must be higher than Bob's honest commitment transaction on the latest
valid state of the Malicia-Bob link. This higher fee CPFP will block the replacement of Malicia low feerate commitment transaction by Bob's honest one under BIP125 rule 3. As Bob doesn't know which of Malicia's commitment transaction is propagated on the network, he won't be able to CPFP on his
own anchor slot (Remember per protocol rules a LN counterparty might own two valid commitment transactions between receiving a <code>commitment_signed</code> and replying back with a <code>revoke_and_ack</code>).</p>
<p>This pinning attack is successful if Malicia's commitment transaction doesn't confirm until N + 60. At which height, she can replace her CPFP with a higher fee rate proposal to confirm the commitment and spend the offered HTLC with her HTLC-timeout transaction. Bob has paid forward a HTLC to Mallory without being able to fetch backward this same HTLC from Malicia.</p>
<p>Pinnings at the commitment-level are more worrying than ones at the HTLC-level, which are solved by the upgrade to the anchor channel type. Indeed, a LN node isn't able today to unilaterally fee bump a commitment transaction such as increasing its feerate during mempool acceptance evaluation to evict any malicious remote commitment.</p>

CC BY-SA 4.0
2021-06-30T22:23:56.750Z
2021-07-06T11:03:47.897Z
2021-07-06T11:03:47.897Z
ariard
<p>In this week's IRC  <a href="https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4" rel="nofollow noreferrer">workshop</a> on L2 onchain support t-bast and ariard agreed that transaction pinning is more of a concern at the commitment level (e.g. delaying the parent of a child CLTV transaction) rather than the HTLC level.</p>
<p>It wasn't immediately obvious to me why or how this works. I was under the impression that the confirmation of commitment transactions aren't time sensitive. There are two time sensitive concerns; not receiving the preimage of a HTLC in a timely fashion and getting your justice transaction confirmed in the case of your counterparty broadcasting an expired state. What am I missing?</p>

<security><lightning-network>
Why is transaction pinning more of a concern at the commitment level rather than the HTLC level of Lightning?
Michael Folkson
# Why is transaction pinning more of a concern at the commitment level rather than the HTLC level of Lightning?

(Asked by: username_0 on 2021-06-17)

In this week's IRC [workshop](https://gist.github.com/username_1/5f28dffe82ddad763b346a2344092ba4) on L2 onchain support t-bast and username_1 agreed that transaction pinning is more of a concern at the commitment level (e.g. delaying the parent of a child CLTV transaction) rather than the HTLC level.

It wasn't immediately obvious to me why or how this works. I was under the impression that the confirmation of commitment transactions aren't time sensitive. There are two time sensitive concerns; not receiving the preimage of a HTLC in a timely fashion and getting your justice transaction confirmed in the case of your counterparty broadcasting an expired state. What am I missing?

**Tags:** security, lightning-network


---

## 1 answers

### Answer by username_1 on 2021-06-30. Score: 2 | Accepted answer

As explained in my June 2020 Lightning dev mailing list [post](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html) "Pinning: The Good, The Bad, The Ugly", pinning at the commitment level is concerning in the case of a Lightning routing hub, not being able to confirm a HTLC-Success on the upstream link. This is a third case of a time sensitive issue, beyond receiving the preimage and getting your justice confirmed.

The attack scenario works like this. Malicia and Mallory open two channels to Bob, a honest routing hub. Malicia draws a payment path for a 1 BTC HTLC through Bob to Mallory. This payment path enforces Bob's `cltv_delta` policy of 40 blocks. Assuming N the chain tip during the setup phase, the HTLC timelock expires at N + 60 on the first hop, N + 40 on the second hop. Once the payment path is locked down, Mallory broadcasts her commitment transaction and a HTLC-Success transaction, and Bob will discover onchain the HTLC preimage.

Simultaneously, Malicia broadcasts a low feerate commitment transaction among the network mempools bottom feerate groups *and* a low feerate, high absolute fee CPFP transaction. This malicious CPFP transaction's absolute fee must be higher than Bob's honest commitment transaction on the latest
valid state of the Malicia-Bob link. This higher fee CPFP will block the replacement of Malicia low feerate commitment transaction by Bob's honest one under BIP125 rule 3. As Bob doesn't know which of Malicia's commitment transaction is propagated on the network, he won't be able to CPFP on his
own anchor slot (Remember per protocol rules a LN counterparty might own two valid commitment transactions between receiving a `commitment_signed` and replying back with a `revoke_and_ack`).

This pinning attack is successful if Malicia's commitment transaction doesn't confirm until N + 60. At which height, she can replace her CPFP with a higher fee rate proposal to confirm the commitment and spend the offered HTLC with her HTLC-timeout transaction. Bob has paid forward a HTLC to Mallory without being able to fetch backward this same HTLC from Malicia.

Pinnings at the commitment-level are more worrying than ones at the HTLC-level, which are solved by the upgrade to the anchor channel type. Indeed, a LN node isn't able today to unilaterally fee bump a commitment transaction such as increasing its feerate during mempool acceptance evaluation to evict any malicious remote commitment.


---

