Author: Sergio Demian Lerner 2016-05-10 21:43:01
Published on: 2016-05-10T21:43:01+00:00
The proposed AsicBoost optimization in the double SHA256 hash requires finding collisions, which can be easily accomplished with 4 bytes of nonce. Moving more of the Merkle root into the second chunk would make it harder to find collisions, thus making the optimization useless. One solution is to increase the size of the Merkle root in the second chunk to 12 bytes by moving the timestamp and target to the first chunk. Another idea is to use a redesigned ASIC-compatible block header that prevents AsicBoost by putting a 4 byte hash of the second 64-byte chunk in the first 64 bytes. This design also allows increased nonce space in the first 64 bytes. However, some ASIC companies already have cores that are better than competing companies' ASICs, so a 10% improvement from AsicBoost may not be different from many other improvements they have secretly added. The message to the ecosystem if the protocol is changed is that ASIC optimizations should be kept secret, and it is unfair to change the protocol because of a certain manufacturer having better chips if the chips are sold in the market and anyone can buy them. There are also other optimization methods such as using approximate adders or dual rail asynchronous adders that provide more than 10% improvement. As part of the hard-fork proposed in the HK agreement, there is a desire to make patented AsicBoost optimization useless and hopefully make further similar optimizations useless as well. The best way to do this is by making it harder to find collisions, but the solution needs to be SPV compatible and compatible with existing mining hardware.
Updated on: 2023-06-11T05:14:42.044719+00:00