Published on: 2012-06-05T01:05:18+00:00
In an email exchange between Mike Koss and Luke-Jr in 2012, Koss seeks clarification on how Luke-Jr's proposal would work for decentralized pools and what the new block header would look like. The proposed block header includes various components such as the block version number, hash of the previous block, share difficulty, timestamp, current target in compact format, and nonce. To earn a share, the final bits of the block header must be zero. For a block to be valid and added to the blockchain, the hash of the block header, concatenated with a valid share candidate for the next block header, must hash to a value less than the current target offset against the share difficulty. Koss also asks about the meaning of "NextBlockCandidate," which refers to the fact that a share becomes a block only after a subsequent share is found that combined hashes to meet the real difficulty.Koss expresses his understanding that in a mining pool attack, the attacker gets compensated for the shares they earn, but the pool will be denied any valid blocks found. However, the attacker does not have access to the Bitcoins earned in the unreported block. With decentralized pools, the attacker has access to the block and can potentially submit it to the Bitcoin network directly bypassing the pool if it benefits them to do so. This raises concerns about potential profit for the attacker. Koss believes that the only way to detect such an attack now is to look for "unlucky" miners, but this is not foolproof as attackers can create multiple fake identities. Koss suggests a solution where a secret part of a block is shared with the pool, which is used in a secondary hash. However, this solution only works for centralized pools and is not suitable for decentralized ones.The email thread discusses the possibility of an attack on a mining pool, where the attacker earns shares but denies the pool any valid blocks found. Detecting such an attack is challenging, and the proposal for fixing this issue involves creating a scheme where miners can detect a qualifying hash to earn a share but cannot determine if the hash is for a valid block. However, implementing this solution would require a major change to the block structure, which may not be justified since attackers do not have direct monetary gain from this attack. The asymmetric payoff for an attacker depends on the pool's reward scheme, and they can potentially use this attack to harm the pool's "luck factor" and bribe users away. It is suggested that planning for a solution should be done 1-2 years in advance to allow users to upgrade before any severe problems arise.In another discussion, Peter Vessenes suggests that the worthiness of attacking a blockchain pool depends on the pool's reward scheme. While attackers may receive bonus earnings or benefit from harming the pool, waiting until there is real pain caused by these attacks could result in a painful fork of the blockchain. Vessenes recommends planning for a solution well in advance to avoid such issues. Additionally, attackers could hurt the pool's "luck factor" and spend the bitcoins earned to bribe users away from the targeted pool.The potential attack on mining pools involves withholding valid blocks that could harm a pool's profitability. The effectiveness of this attack depends on the ratio of the attacker's hashrate to the rest of the pool. However, there is uncertainty regarding the economics of this attack and whether it would be more profitable for an attacker to spend their hashes attacking rather than just mining. It is suggested that forking the blockchain should only be considered if there is evidence of real pain caused by these attacks. The attack signature mentioned by one member is not a significant factor since only the pool that controls the merkle will benefit from block submission. Actual estimates of the potential impact of this attack are requested.A proposed solution to address the vulnerability of all pools to an attacker withholding shares is to accept blocks at a lower difficulty if they are submitted with a candidate for the next block and meet specific hashing requirements. This solution would create a hard-fork in the blockchain, but existing miners should work unmodified. Poolservers would need to adapt significantly. However, it is unlikely that rule changes would gain sufficient acceptance among the Bitcoin community due to centralized pools' potential harm to network security.
Updated on: 2023-08-01T03:34:04.944188+00:00