TL;DR: We have verified that Antminer S9 is actually capable of supporting overt AsicBoost, potentially allowing miners to save about 13 % of energy costs. We are dedicated to enable this in Braiins OS and make it available to everyone.

About two months ago we have started researching a rather old news about support for AsicBoost in S9 mining hardware. This Reddit thread was a good starting point to find the level of knowledge about this aspect throughout the general public.

Unfortunately, most of the comments were lacking a thorough engineering insight into what the real problem is to make it work on mainnet. People were able to find traces of a feature called ‘multi-version’ support in bmminer sources. Therefore, we have decided to take a deeper look into this.

Our Findings

The current bmminer code (as published on GitHub) implements a featured called multi-version. What that means is that the miner could theoretically ask the pool via a further undocumented stratum extension (multi-version) for version bits that can be rolled in the bitcoin blockheader. This extension is incompatible with BIP310. However, tries to achieve a similar goal.

The problem is that the bmminer software doesn’t further instruct the FPGA backend as of which bits in the version field could be touched…

Nevertheless, we have ignored this little inconsistency in the software and tried forcing the multiversion (setting multi version to 1, 2, and 4) support in the bmminer to see what it can do. The software would try to enforce an MMEN (multi-midstate enable) mode in the mining chips for values 2 and 4. It would also make the proprietary FPGA bitstream to generate jobs for the mining chips with up to 4 midstates per mining job.

Now, the catch: the software doesn’t communicate to the FPGA which bits are to be modified in the version field of the blockheader. The FPGA emits mining jobs with up to 4 midstates for a chip with incorrectly rolled version bits. The version field of the blocks, for multi-version set to 4, was thus: 0x2000.0000, 0x6000.0000, 0xa000.0000, 0xe000.0000. The latter 3 version fields are invalid, therefore a miner with enabled multi-midstate would have ¾ of its shares rejected by any pool. Currently, the standard that specifies which bits in the version field are available for the ‘version-rolling’/’mult-version’ feature is specified in BIP320.

Unfortunately, even though the fix seems trivial, the only reasonable way to do it is to implement the FPGA bitstream from scratch. Such a bitstream would generate midstates from correctly specified first 64 bytes of the bitcoin blockheader (including the 4 distinct and BIP320 compliant version fields).

Power consumption

Even with the above setup, we have performed some basic measurements with regards to power consumption and our results confirmed roughly the following numbers:

As we can see the power consumption is reduced by almost 13.1 % when 4 midstates for each mining job are enabled. We have also verified that the results (even though invalid from mainnet prospective) are correct from PoW prospective. That is the blockheader when double sha256 hashed meets the assigned ASIC target.

S9 + AB + bOS

Braiins OS (baseline released a month ago) serves very well as a platform that could accomplish this task of running a new/fixed FPGA bitstream. Currently, we have a prototype FPGA bitstream that can do basic operations with the mining chips and is thus suitable for running the chips in multi-midstate mode.

It is important to note that unlike regular software, it is very difficult if impossible to fix anything in the present FPGA bitstream without having the source for it. Therefore, the only way seems to write one from scratch as stated above.

If Bitmain fixed this little “problem” in the FPGA bitstream, we could immediately integrate the new FPGA bitstream into bOS making it available to the general public. For the time being, we will keep working on our own open source FPGA bitstream.