How Lightning Networks protect itself from 'Selfish Mining'?

1

1

It is a well accepted fact that mining pools do engage in '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?

Ugam Kamat

Posted 2019-05-17T18:35:52.223

Reputation: 5 180

Answers

1

Your question seems very similar to the 51% attack vector on the lightning network which I described on the lightning dev mailing list. 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.

Rene Pickhardt

Posted 2019-05-17T18:35:52.223

Reputation: 6 565

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 – 2019-05-17T19:38:58.553

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 – 2019-05-17T19:42:21.067

1Yeah 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 – 2019-05-17T20:06:33.240

That is helpful. My question was based on the premise that implementations just use one or two block deltas per hop. – Ugam Kamat – 2019-05-17T20:25:11.480

Asked: 2019-05-17T18:35:52.223

Viewed: 33 times

Active: 2019-05-17T19:30:22.327