In another topic regarding Taproot proposal, one contributor said something about the type of the fork required and someone else told things about how UASF that implemented SegWit was good because of the so-called Covert AsicBoost conspiracy that allegedly Bitmain was involved in and finally the legendary Gregory Maxwell intervened by confirming the above conspiracy theory, ...
I've been following this AsicBoost thing since the beginning and as far as my research shows this is one of the most stupid conspiracy theories in cryptocurrency ever:
According to this theory, Ahead of SegWit fork, Bitmain had developed AsicBoost friendly miners which enjoy a special ASIC circuitry that is supposed to have like 25% performance edge over conventional ASICs in the market.
The conspiracy requires the machine to change the block header
* specifically something in the first 64 bytes of the header should be altered this first 64 bytes (chunk1) is consisted of:
nVersion (4 byte)
PrevHash(32 bytes)
MerkleRoot Head(28 bytes)
MerkleRootTail(4bytes)
*There is an alternative approach which is not relevant here, tho
Obviously there are 2 candidates for the conspiracy to work: the first and the last fields. In practice playing with nVersion field is both 'not-covert' (actually it is called
overt method) and since a long time ago (after BIP 9) 'not-legal' because the field is now used as a means of signaling protocol in Bitcoin Core. So, you are left with MerkleRoot.
For the hypothetical evil AB device to be able to play with MerkleRoot there are two options available:
1- Altering the content of a transaction (preferably in higher levels of the Merkle Tree)
2- Re-ordering the transactions in the Merkle Tree
Shuffling the transactions (the second method) is possible by employing different algorithms among them an algorithm which has a small footprint is proposed which is more adequate for an ASIC device rather than a cpu or a gpu, it is called on-the-fly reordering.
Here is how SegWitis related to this issue, SegWit embeds a wtxid tree Merkle root hash in the coinbase transaction. Re-ordering the transactions in a reckless manner makes this hash void and the verification process fails!
This is it! A covert AsicBoost attempt is made
harder because some algorithms for the second method can't fix the problem with SegWit root hash. But wait, don't we have the first method still working? Tampering the contents of a transaction? adding new transactions? Removing one transaction? Sure we have! Lots of possibilities out there to remain covert.
You are free to check
this comprehensive summary that requires little prerequisites in terms of being familiar with the subject. The bottom line is:
SegWit is not a destructive challenge for AsicBoost. End of the story.
Now, I'm adding one more important point here:
The whole conspiracy theory was about how the hypothetical Bitmain's AB miner is compromised by SegWit because it is no longer able to alter Merkle root of the block header, yes? But is an ASIC miner able to do such thing ever? Altering the Merkle Root? Of course not! It violates the contract between the miner and the pool, remember? Only a gigantic solo miner is able to think about such an attack and he or she should do it by using a cpu centrally and dispatching the collided headers afterward.
I conclude that the whole conspiracy theory about such a machine that attempts to find collisions for itself locally is superficial.
