<p>Your question seems very similar to the <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001085.html" rel="nofollow noreferrer">51% attack vector on the lightning network which I described on the lightning dev mailing list</a>. I am not aware of any protocol to prevent this nor do I see any way of preventing what you and what the mailinglist post describe. The timeouts depend on blockheight and the Bitcoin protocol has the consensus rules that the longest proof of work chain wins. </p>

<p>I think it is a generally accepted assumption that Bitcoin will only operate in a secure way if at least 51% of the mining power comes from honest nodes (which are following the rules) on the plus side any secrete mining operation would statistically speaking only be harmful if the operation has at least 51 percent which is hard to achieve and probably also more expensive than the gains from winning such an attack. </p>

CC BY-SA 4.0
2019-05-17T19:38:58.553Z
Thanks, I just got myself added to the mailing list (few days back) so I was oblivious that this issue was raised earlier.
Ugam Kamat
CC BY-SA 4.0
2019-05-17T19:42:21.067Z
But considering it, over the long term I'm not saying that the blockchain will face a 51% attack, but on short term even say couple of blocks, nodes can get vulnerable
Ugam Kamat
CC BY-SA 4.0
2019-05-17T20:06:33.240Z
Yeah but timelock are usually more than a couple of blocks. I think the recommendation is 144 blocks per node / hop on a path. Even 9 blocks which is the standard in some implementations is already very unlikely. For example a pool having 40%mining power will statistically only with every 10,000 blocks achieve to secretely mine the largest pow chain of 10 blocks. Compare that with all the list mining rewards. I guess noone has an incentive to do that
Rene Pickhardt
CC BY-SA 4.0
2019-05-17T20:25:11.480Z
That is helpful. My question was based on the premise that implementations just use one or two block deltas per hop.
Ugam Kamat
CC BY-SA 4.0
2019-05-17T19:30:22.327Z
2019-05-17T19:30:22.327Z
Rene Pickhardt
<p>It is a well accepted fact that mining pools do engage in '<a href="https://www.cryptocompare.com/coins/guides/what-is-bitcoin-selfish-mining/" rel="nofollow noreferrer">selfish mining</a>' by not broadcasting a block to the network when they find a PoW solution, but building on top of that block so as to maximize revenue. Now from the point of view of lightning nodes that are creating a HTLC, assume that the blockchain height is 'h'. A HTLC is forwarded by the <code>origin node</code> and each node on the way uses 1 block of <code>CLTV_expiry_delta</code> (say there are 5 intermediary nodes). But soon after the <code>final node</code> reveals the pre-image to its peer, 3 blocks gets relayed simultaneously. Now, it may be the case that even after including a buffer, some nodes along the path can get exposed as its peer can relay the transaction to the blockchain due to timeout. Is there a protocol in place to stop intermediary nodes from getting vulnerable due to selfish mining?</p>

<lightning-network><lightning-routing><selfish-mining>
How Lightning Networks protect itself from 'Selfish Mining'?
Ugam Kamat
# How Lightning Networks protect itself from 'Selfish Mining'?

(Asked by: username_0 on 2019-05-17)

It is a well accepted fact that mining pools do engage in '[selfish mining](https://www.cryptocompare.com/coins/guides/what-is-bitcoin-selfish-mining/)' by not broadcasting a block to the network when they find a PoW solution, but building on top of that block so as to maximize revenue. Now from the point of view of lightning nodes that are creating a HTLC, assume that the blockchain height is 'h'. A HTLC is forwarded by the `origin node` and each node on the way uses 1 block of `CLTV_expiry_delta` (say there are 5 intermediary nodes). But soon after the `final node` reveals the pre-image to its peer, 3 blocks gets relayed simultaneously. Now, it may be the case that even after including a buffer, some nodes along the path can get exposed as its peer can relay the transaction to the blockchain due to timeout. Is there a protocol in place to stop intermediary nodes from getting vulnerable due to selfish mining?

**Tags:** lightning-network, lightning-routing, selfish-mining


---

## 1 answers

### Answer by username_1 on 2019-05-17. Score: 1 | Accepted answer

Your question seems very similar to the [51% attack vector on the lightning network which I described on the lightning dev mailing list](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001085.html). I am not aware of any protocol to prevent this nor do I see any way of preventing what you and what the mailinglist post describe. The timeouts depend on blockheight and the Bitcoin protocol has the consensus rules that the longest proof of work chain wins.

I think it is a generally accepted assumption that Bitcoin will only operate in a secure way if at least 51% of the mining power comes from honest nodes (which are following the rules) on the plus side any secrete mining operation would statistically speaking only be harmful if the operation has at least 51 percent which is hard to achieve and probably also more expensive than the gains from winning such an attack.

> **Comments:**
> **username_0**: Thanks, I just got myself added to the mailing list (few days back) so I was oblivious that this issue was raised earlier.  
> **username_0**: But considering it, over the long term I'm not saying that the blockchain will face a 51% attack, but on short term even say couple of blocks, nodes can get vulnerable  
> **username_1**: Yeah but timelock are usually more than a couple of blocks. I think the recommendation is 144 blocks per node / hop on a path. Even 9 blocks which is the standard in some implementations is already very unlikely. For example a pool having 40%mining power will statistically only with every 10,000 blocks achieve to secretely mine the largest pow chain of 10 blocks. Compare that with all the list mining rewards. I guess noone has an incentive to do that  
> **username_0**: That is helpful. My question was based on the premise that implementations just use one or two block deltas per hop.  

---

