So, this kind of attack happens when a miner in a pool discovers a block but decides to keep it to themselves instead of sharing it with the rest of the pool. What are your thoughts or insights on this?
Block withholding attacks explained
4 replies 147 views
It's like an employee comes to the cashier's office to get his salary and says that my last name is TOTAL
just_oracleMember
Posts: 9 · Reputation: 134
#3Jan 19, 2017, 06:06 PM
It's like stabbing a knife into your own stomach.
(Of course they share, that's how they earn bitcoins)
Block withholding attacks are real, hard to detect and impossible to stop unless the pool controls the mining gear and software 100%.
Your miner knows before anyone else if they hashed a valid block, and thus, they can chose to not sumbit it, however, there is no direct gain for the attacker to do so, in fact, the attacker will lose money along side the pool and everyone else.
If it is a PPLNS pool, you and your fellow miners lose btc, if its a PPS, you, other miners and the pool lose btc. in fact, even if it was FPPS you will still lose money because then the entire network has found less blocks (this will be the smallest loss to the attacker and the greatest loss to the pool).
The issue with this kind of attac is that you can't really tell if it is happening or not.
The one exception to that is hash rental companies such as NiceHash and MRR et al. They have in the past (several years ago) been accused of withholding blocks pointed at specific pools. Reasons were never hashed out (pun) but general opinion was to try and break the target pools as favors to some large players. Rental companies get paid no matter what so it did not hurt them.
Then maybe 8 years ago there was the unintentional block withholding by Genesis mining who were using Slush. They had a massive hashrate and when other Slush users hit a block Genesis got paid per their hash rate. One problem: Genesis was using a proxy to combine all their miners into one connection and after a faulty update that proxy had a bug in it which caused it to ignore all blocks found and not report them. This went on for several weeks. Somewhere in the SlushPool thread there is a long series of posts about it dealing with Slush's apparent incredibly long streak of "Bad Luck".
Methinks it was Kano that pointed out the problem to Slush who then did some digging through their logs to reveal that yes, during that time even when taking variance into account, statistically Genesis should have found many blocks and yet had found zero. Timing of Slush's drop in Luck matched to when Genesis's proxy was updated. Slush bitched at Genesis (who fixed the bug) but never returned any of the BTC to the Slush users who lost out on earnings that Genesis got for doing useless work. With Genesis at the time being something like 1/4 of Slush's hash rate that was a rather large amount.
Related topics
- Here we go again! ANTPOOL mined an empty block 19
- The Future of Bitcoin: What If Block Rewards Fall Below Transaction Fees? 19
- Bitcoin Block Party || Group Run A 19
- using miner exhaust to power a small wind turbine 19
- Check Out Our Unique VR Tour of a Bitcoin Mine | Meet Verakari Mining 0
- SAMA X 380 ASIC Miner Overview 2