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?
1 Answer
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.
-
Thanks, I just got myself added to the mailing list (few days back) so I was oblivious that this issue was raised earlier. Commented May 17, 2019 at 19:38
-
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 Commented May 17, 2019 at 19:42
-
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 Commented May 17, 2019 at 20:06
-
That is helpful. My question was based on the premise that implementations just use one or two block deltas per hop. Commented May 17, 2019 at 20:25