<p>When a channel is closed unilaterally, it requires two transactions by the closing party to move funds from a channel back into unilateral control.</p>
<p>The closing party publishes their version of the commitment transaction to the network. The commitment transaction has a special condition for the closer's output.  After the commitment transaction is included in a block, the closing party's funds are locked for a period of time in which only the counterparty is able to issue their penalty transaction. The closing party can only spend their output after the lock expires. Since the two spending conditions are encoded in the output's locking script, the funds remain subject to potential penalty spending until the closing party moves the funds to a different output.</p>
<p>To prevent a penalty transaction from occurring during the wait period, the attacker would need to be able to censor the penalty transaction from being included in any block between the commitment transaction being confirmed and the lock expiring. Censorship of such level would require sufficient hashrate to reorganize any block that includes it.</p>

CC BY-SA 4.0
2021-01-23T15:57:11.897Z
2021-01-23T17:29:09.390Z
2021-01-23T17:29:09.390Z
Murch
<p>It's named &quot;penalty transaction&quot; by the specs :).</p>
<p>What you say is true but far from sufficient. It also requires this miner be able to heal this block chain without a censored (the penalty) transaction. It therefore assumes that a single miner controls more hashpower than the rest of the network combined.</p>
<p>Thus it can be stated as such:</p>
<blockquote>
<p>The Lightning Network core security assumption relies on the fact that nobody can &quot;51% attack&quot; the network.</p>
</blockquote>
<p>But it is arguably already an assumption made by Bitcoin itself.</p>

CC BY-SA 4.0
2021-01-23T12:07:25.600Z
You don't need a majority hashpower since a minority hashrate can also mine an old state if channel lock time is long enough. I understand your “healing” argument, but in order to “heal” the chain you should be able to differentiate fraudulent blocks from honest blocks. So the new question is, how honest miners can identify those fraudulent blocks that include old states. PTLCs are now making this differentiation even harder.
Brqoo
CC BY-SA 4.0
2021-01-23T12:44:03.610Z
You do need a majority of hashpower as we assume the miners to be economically rationale. ie they will mine the transaction that pays more fee. So what happens is: with a funding tx `A` an old state tx `B` gets broadcast, the penalty tx `C` gets as well. Most of the network will include `C` which pays more fees, unless the miner you colluded with *is* most of the network itself and will likely get paid through a bribe. If the colluding miner does not have enough hashpower, even if it finds a block it will get reorged out as the rest of the network just mined the high-fee tx `C`, which
Antoine Poinsot
CC BY-SA 4.0
2021-01-23T12:45:38.280Z
conflicts with the stealing transaction `B`. In addition the rationale miners have a huge delay to mine the penalty tx `C` before `B` even gets valid. This is the reason why you need to have >50% of the network hashrate in order to censor the transaction long enough AND then not even getting reorg'ed out by economically rationale miners: you need to heal a chain which censors a transaction.
Antoine Poinsot
CC BY-SA 4.0
2021-01-23T12:52:07.587Z
Your argument is true for pre-mining, but I'm talking about post-mining of an old state. I don’t think reorg is practical (at least today) since all these miners must consolidate and agree on whether to reorg a particular block. Miners are all independent organisations and they have no clue what strategy the rest of miners are following.
Brqoo
CC BY-SA 4.0
2021-01-23T13:01:47.940Z
Also a miner can be the fraudster himself, so no bribe involved.
Brqoo
CC BY-SA 4.0
2021-01-23T13:09:03.847Z
Ah also, you can consider reorgs as an attack vector to the network since it increases mempool congestion.
Brqoo
CC BY-SA 4.0
2021-01-23T13:52:23.423Z
You are confused. As detailed above, the transaction representing the old state is timelocked and conflicting with the penalty transaction. Therefore the penalty transaction will be included in the block chain before the old state transaction (as it can pay any feerate). What an attacker can do -which requires >50% network hashrate- is replace the block that included the penalty transaction and all blocks that were created on top of it. This is a block chain fork and will only heal if you have more hashrate than the rest of the network combined.
Antoine Poinsot
CC BY-SA 4.0
2021-01-23T13:54:12.157Z
Yes the miner can be the fraudster, it is recommended to set a big timelock for a channel with an entity that control a significant portion of hashing power.
Antoine Poinsot
CC BY-SA 4.0
2021-01-23T13:56:58.167Z
"you can consider reorgs as an attack vector to the network since it increases mempool congestion." => This is wrong and completely unrelated.
Antoine Poinsot
CC BY-SA 4.0
2021-01-23T14:00:35.383Z
The point is, old state tx "B" is not broadcasted at all, its injected to fraudulent miners' isolated mempool and eventually end up in a block without the rest of the network realising it pre-mining. Penalty tx "C" cannot be broadcasted/relayed from that point.
Brqoo
CC BY-SA 4.0
2021-01-23T14:08:05.000Z
Ok, spotted the confusion: in order to effectively steal from an old state you have to 1. broadcast an old commitment transaction 2. wait `to_self_delay` (as per spec wording) 3. Get a transaction (`B` in my wording) that spends the commitment transaction to an output you control. But point is, the delay you have to wait is more than enough to get the penalty transaction (`C`) confirmed before `B` is even valid :-)
Antoine Poinsot
CC BY-SA 4.0
2021-01-23T14:09:04.663Z
Then i went further and detailed a race condition, but there is no window for a race condition in the first place.
Antoine Poinsot
CC BY-SA 4.0
2021-01-23T14:17:41.007Z
I don't think you get my point. TX B is not broadcasted at all, but surprisingly end-up in a valid block. Also there couldn't be a race condition anyways since LN transactions are not considered first-seen first safe (non-max sequence).
Brqoo
CC BY-SA 4.0
2021-01-23T14:37:18.273Z
I don't think you read carefully and try to understand my explanation.. Ping me on IRC if you'd like as it's becoming too long for this medium. As for your last comment: tx `B` **cannot** end up from nowhere in a valid block as it is **not valid** by the time the peer remarks the tentative of theft and broadcast tx `C` (penalty). first-seen safe is brittle and completely unrelated.
Antoine Poinsot
CC BY-SA 4.0
2021-01-23T15:25:22.607Z
Aren’t tx B and tx C spending from the same inputs? If so, tx C cannot be relayed when tx B is mined (with no reorgs) Also what is the best to reach you on IRC?
Brqoo
CC BY-SA 4.0
2021-01-24T11:31:00.813Z
They are but `B` **is invalid** so it's the other way around. I'm darosior on any bitcoin-related channel on freenode. Probably #bitcoin for this matter.
Antoine Poinsot
CC BY-SA 4.0
2021-01-23T11:48:54.927Z
2023-04-19T08:26:58.207Z
2023-04-19T08:26:58.207Z
Antoine Poinsot
<p>This is a special case of 51% attack.</p>
<p>The lock of the funds in a force-close is at a minimum 144 blocks for the person who submit the old state, but the other party can claim their share at once. They can also submit a penalty transaction at once, and have <em>all</em> the funds in a channel to spend from.</p>
<p>So 144 is how many blocks that had to be mined in secret to pull this off.</p>
<p>And yes, it would have to be a majority, because the chain with the most PoW wins.</p>
<p>In <em>theory</em> it is possible, but it's impossible in the same way that 6 blocks is seen as immutable - it is not likely to yield gains worth the expenditure, to pull it off.</p>
<p>If they had that hash rate and the willigness to steal, they'd be more likely doublespend a transaction to an exchange, because that is easier.</p>

CC BY-SA 4.0
2021-01-23T14:03:52.537Z
No it's not a special case of 51% attack. Anyone with %1 hashrate can mine such block and the rest of the miners will continue to mine from that outpoint.
Brqoo
CC BY-SA 4.0
2021-01-23T15:46:39.103Z
You have not done your research.

I read your post on r/btc, and it is pretty clear you have no idea how any of this works. Now, it's fair not to, but you should try to listen to those who do.

Any commitment transaction that a channel partner can spend unilaterally is a smart contract that is formed like this:

1 output is the counterpartys money. He can spend those immediately.

1 output is what you claim is your money. This output has this contract:

1) After a timelock (minimum 144 blocks), you can spend them.

2) Your counterparty can spend them immediately with revocation key
Vegard Engen
CC BY-SA 4.0
2021-01-23T15:49:16.007Z
The revocation key, he will have, because that is part of the protocol.

And when I say "the counterparty", I mean the counterpartys node - or someone who he have delegated to watch for him (populary called a watchtower).

Now, this is part of the standard functionality of lightning network. Mobile nodes will typically enforce longer timelocks, though, I have seen two weeks.
Vegard Engen
CC BY-SA 4.0
2021-01-25T11:39:07.553Z
Having read the other comments here, I sense the grand misunderstanding here.

It's really very simple: The penalty TX C spends from the output of the channel closure B. It can't be mined before a faulty channel closure has been mined.

There is a time lock that says how many blocks the penalty transaction has to claim the attackers money. The minimum is 144 blocks, the maximum will usually be substantially higher for mobile wallets.

The attacker will not be able to move those funds during this period. This is coded into smart bitcoin contracts and is part of what makes LN safe enough.
Vegard Engen
CC BY-SA 4.0
2021-01-23T13:45:14.137Z
2021-01-23T13:45:14.137Z
Vegard Engen
<p>You can't as described here:</p>
<p><a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001080.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001080.html</a></p>
<p>Tl,dr: if one controlls more than 50% of hashrate and secretly mines the longest chain with old state one can steal the entire capacity of all channels one is connected to. Reward is much higher than regular Bitcoin double spent through reorg but execution is also more expensive</p>

CC BY-SA 4.0
2021-01-23T12:20:33.133Z
A %1 hashrate can mine an old state without others realizing it. Your approach could be true if the rest %99 reorgs (aka heals) the fraudulent block. However I don’t think this is practical since all these miners must consolidate and agree on what to mine. Miners are today not even in agreement what method to use to activate a soft fork.
Brqoo
CC BY-SA 4.0
2021-01-23T11:50:36.183Z
2021-01-23T11:50:36.183Z
Rene Pickhardt
<p>The core lightning security assumption relies on a punishment mechanism called “Justice Transaction”. However, how can you prevent a malicious user from colluding with a miner, and producing a block with old state transactions without the rest of the network (watchtowers/honest nodes) realising it pre-mining?</p>

<mining-theory><lightning-network><mining-profitability><ln-penalty-transaction>
Can miners collude to bypass the penalty based revocation system of the lightning network?
Brqoo
# Can miners collude to bypass the penalty based revocation system of the lightning network?

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

The core lightning security assumption relies on a punishment mechanism called “Justice Transaction”. However, how can you prevent a malicious user from colluding with a miner, and producing a block with old state transactions without the rest of the network (watchtowers/honest nodes) realising it pre-mining?

**Tags:** mining-theory, lightning-network, mining-profitability, ln-penalty-transaction


---

## 4 answers

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

When a channel is closed unilaterally, it requires two transactions by the closing party to move funds from a channel back into unilateral control.

The closing party publishes their version of the commitment transaction to the network. The commitment transaction has a special condition for the closer's output. After the commitment transaction is included in a block, the closing party's funds are locked for a period of time in which only the counterparty is able to issue their penalty transaction. The closing party can only spend their output after the lock expires. Since the two spending conditions are encoded in the output's locking script, the funds remain subject to potential penalty spending until the closing party moves the funds to a different output.

To prevent a penalty transaction from occurring during the wait period, the attacker would need to be able to censor the penalty transaction from being included in any block between the commitment transaction being confirmed and the lock expiring. Censorship of such level would require sufficient hashrate to reorganize any block that includes it.


---

### Answer by username_2 on 2021-01-23. Score: 2

It's named "penalty transaction" by the specs :).

What you say is true but far from sufficient. It also requires this miner be able to heal this block chain without a censored (the penalty) transaction. It therefore assumes that a single miner controls more hashpower than the rest of the network combined.

Thus it can be stated as such:

> The Lightning Network core security assumption relies on the fact that nobody can "51% attack" the network.

But it is arguably already an assumption made by Bitcoin itself.

> **Comments:**
> **username_0**: You don't need a majority hashpower since a minority hashrate can also mine an old state if channel lock time is long enough. I understand your “healing” argument, but in order to “heal” the chain you should be able to differentiate fraudulent blocks from honest blocks. So the new question is, how honest miners can identify those fraudulent blocks that include old states. PTLCs are now making this differentiation even harder.  
> **username_2**: You do need a majority of hashpower as we assume the miners to be economically rationale. ie they will mine the transaction that pays more fee. So what happens is: with a funding tx `A` an old state tx `B` gets broadcast, the penalty tx `C` gets as well. Most of the network will include `C` which pays more fees, unless the miner you colluded with *is* most of the network itself and will likely get paid through a bribe. If the colluding miner does not have enough hashpower, even if it finds a block it will get reorged out as the rest of the network just mined the high-fee tx `C`, which  
> **username_2**: conflicts with the stealing transaction `B`. In addition the rationale miners have a huge delay to mine the penalty tx `C` before `B` even gets valid. This is the reason why you need to have >50% of the network hashrate in order to censor the transaction long enough AND then not even getting reorg'ed out by economically rationale miners: you need to heal a chain which censors a transaction.  
> **username_0**: Your argument is true for pre-mining, but I'm talking about post-mining of an old state. I don’t think reorg is practical (at least today) since all these miners must consolidate and agree on whether to reorg a particular block. Miners are all independent organisations and they have no clue what strategy the rest of miners are following.  
> **username_0**: Also a miner can be the fraudster himself, so no bribe involved.  
> **username_0**: Ah also, you can consider reorgs as an attack vector to the network since it increases mempool congestion.  
> **username_2**: You are confused. As detailed above, the transaction representing the old state is timelocked and conflicting with the penalty transaction. Therefore the penalty transaction will be included in the block chain before the old state transaction (as it can pay any feerate). What an attacker can do -which requires >50% network hashrate- is replace the block that included the penalty transaction and all blocks that were created on top of it. This is a block chain fork and will only heal if you have more hashrate than the rest of the network combined.  
> **username_2**: Yes the miner can be the fraudster, it is recommended to set a big timelock for a channel with an entity that control a significant portion of hashing power.  
> **username_2**: "you can consider reorgs as an attack vector to the network since it increases mempool congestion." => This is wrong and completely unrelated.  
> **username_0**: The point is, old state tx "B" is not broadcasted at all, its injected to fraudulent miners' isolated mempool and eventually end up in a block without the rest of the network realising it pre-mining. Penalty tx "C" cannot be broadcasted/relayed from that point.  
> **username_2**: Ok, spotted the confusion: in order to effectively steal from an old state you have to 1. broadcast an old commitment transaction 2. wait `to_self_delay` (as per spec wording) 3. Get a transaction (`B` in my wording) that spends the commitment transaction to an output you control. But point is, the delay you have to wait is more than enough to get the penalty transaction (`C`) confirmed before `B` is even valid :-)  
> **username_2**: Then i went further and detailed a race condition, but there is no window for a race condition in the first place.  
> **username_0**: I don't think you get my point. TX B is not broadcasted at all, but surprisingly end-up in a valid block. Also there couldn't be a race condition anyways since LN transactions are not considered first-seen first safe (non-max sequence).  
> **username_2**: I don't think you read carefully and try to understand my explanation.. Ping me on IRC if you'd like as it's becoming too long for this medium. As for your last comment: tx `B` **cannot** end up from nowhere in a valid block as it is **not valid** by the time the peer remarks the tentative of theft and broadcast tx `C` (penalty). first-seen safe is brittle and completely unrelated.  
> **username_0**: Aren’t tx B and tx C spending from the same inputs? If so, tx C cannot be relayed when tx B is mined (with no reorgs) Also what is the best to reach you on IRC?  
> **username_2**: They are but `B` **is invalid** so it's the other way around. I'm darosior on any bitcoin-related channel on freenode. Probably #bitcoin for this matter.  

---

### Answer by username_3 on 2021-01-23. Score: 0

This is a special case of 51% attack.

The lock of the funds in a force-close is at a minimum 144 blocks for the person who submit the old state, but the other party can claim their share at once. They can also submit a penalty transaction at once, and have *all* the funds in a channel to spend from.

So 144 is how many blocks that had to be mined in secret to pull this off.

And yes, it would have to be a majority, because the chain with the most PoW wins.

In *theory* it is possible, but it's impossible in the same way that 6 blocks is seen as immutable - it is not likely to yield gains worth the expenditure, to pull it off.

If they had that hash rate and the willigness to steal, they'd be more likely doublespend a transaction to an exchange, because that is easier.

> **Comments:**
> **username_0**: No it's not a special case of 51% attack. Anyone with %1 hashrate can mine such block and the rest of the miners will continue to mine from that outpoint.  
> **username_3**: You have not done your research.  I read your post on r/btc, and it is pretty clear you have no idea how any of this works. Now, it's fair not to, but you should try to listen to those who do.  Any commitment transaction that a channel partner can spend unilaterally is a smart contract that is formed like this:  1 output is the counterpartys money. He can spend those immediately.  1 output is what you claim is your money. This output has this contract:  1) After a timelock (minimum 144 blocks), you can spend them.  2) Your counterparty can spend them immediately with revocation key  
> **username_3**: The revocation key, he will have, because that is part of the protocol.  And when I say "the counterparty", I mean the counterpartys node - or someone who he have delegated to watch for him (populary called a watchtower).  Now, this is part of the standard functionality of lightning network. Mobile nodes will typically enforce longer timelocks, though, I have seen two weeks.  
> **username_3**: Having read the other comments here, I sense the grand misunderstanding here.  It's really very simple: The penalty TX C spends from the output of the channel closure B. It can't be mined before a faulty channel closure has been mined.  There is a time lock that says how many blocks the penalty transaction has to claim the attackers money. The minimum is 144 blocks, the maximum will usually be substantially higher for mobile wallets.  The attacker will not be able to move those funds during this period. This is coded into smart bitcoin contracts and is part of what makes LN safe enough.  

---

### Answer by username_4 on 2021-01-23. Score: -1

You can't as described here:

<https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001080.html>

Tl,dr: if one controlls more than 50% of hashrate and secretly mines the longest chain with old state one can steal the entire capacity of all channels one is connected to. Reward is much higher than regular Bitcoin double spent through reorg but execution is also more expensive

> **Comments:**
> **username_0**: A %1 hashrate can mine an old state without others realizing it. Your approach could be true if the rest %99 reorgs (aka heals) the fraudulent block. However I don’t think this is practical since all these miners must consolidate and agree on what to mine. Miners are today not even in agreement what method to use to activate a soft fork.  

---

