First-ever block mined using Overt-AsicBoost: Slush Pool plans Stratum Protocol Extensions as a BIP
On March 24th, 2018, the first Overt-AsicBoost block was mined by Slush Pool at block #514882.
But.. What is it the AsicBoost?
On the official website, that’s the meaning:
“AsicBoost is an innovation that allows more energy efficiency when grinding SHA256 based Proof-of-Work used in Bitcoin mining. There are two forms of AsicBoost, one that provides optimizations by manipulating the merkle tree, and the other way which ultimately uses two bits from the nVersion field.”
Let’s try to explain what the AsicBoost innovation consists of in its Overt and Covert versions.
AsicBoost, unlike the standard design, fixes the last 64 bytes of the first application of SHA256 (the tail of the block header), and change the mid-state (the head of the block header), instead of the opposite. This requires fixing and repeatedly using the tail of the header. Or it allows several methods to modify the first 64 bytes (head) of the block header, while keeping the tail constant.
How it is possible to modify the block header head (64 byte)?
- Overt AsicBoost : Changing the nVersion field of the block header
With Overt-AsicBoost, all users can inspect the nVersion field of a block. By rolling the nVersion field, several random bits are activated, and they are different from the BIP9 basic semantics, so they are interpreted by Bitcoin Core nodes as signals of non-existent soft-fork proposals.
2. Covert AsicBoost: Changing 28-bytes of the transaction Merkle root in the block header
With Covert AsicBoost, it’s not easy to identify miners who use it unless they declare it, precisely because it’s very difficult to distinguish a block whose Merkle tree has been “rolled”.
Furthermore, Covert AsicBoost require the miners to find “collisions” of the last 4 bytes of the Merkle root field, stored in the tail of the block header, rather than in the head.
To find collisions, there are several algorithmic methods, depending on number and size of collisions and collisions group and, above of all, on how SHA-256 core was designed.
In this logic, collisions are found by changing the content of transaction (T1) or by changing the order of transaction.
The number of SHA256 operations required to find collisions establishes a fixed delay for starting AsicBoost mining. During this time, there is no restriction that the blocks mined are empty. So, if the mining hardware only supports AsicBoost but not the standard one, miners cannot generate any blocks during this time, on the contrary if it is in dual mode (supports both chips), a delay of up to 1 minute may be tolerated (example a 2% gain loss).
That said, it is only natural that the AsicBoost method has a high incentive to reduce collision detection costs only if the chip is compatible AsicBoost-only capable (not dual-mode).
Obviously, it should be noted that the overt method is faster than covert method: it doesn’t require to find any collision at all
Finally, when a SegWit-enabled blockchain (BIP141) receives a block that contains a single segwit transaction, it accepts the block only if the block has a Merkle root of the wtxid tree that is stored in the coinbase transaction.
The wtxid tree contains wtxid transactions. A wtxid includes both transaction data and SegWit data, because if you change the transaction order (but not the wtxid commitments), this mismatch makes the block invalid.
This is why SegWit makes it more difficult to use transaction reordering. Transaction reordering is the most efficient covert method for AsicBoost and the most suitable for FPGA implementation. It forces the secret miner of AsicBoost to extract only blocks that do not contain Segwit transactions.
Stratum Protocol Extensions: Slush Pool plans its own implementation as BIP
As to use Overt-AsicBoost, Slush Pool published a BIP (Bitcoin Improvement Proposal) to standardize Stratum Protocol Extension, in particular this BIP is a configuration of bits “version-rolling” in nVersion field of bitcoin block header.
To implement “version-rolling” it is necessary to extend stratum protocol simply because is backwards incompatible change. In fact, with the stratum protocol original version, miner couldn’t communicate different block version value to the server and a server couldn’t communicate safe bits for rolling to a miner.
The introduction of one new message to the stratum protocol (“mining.configure”) which handles the initial configuration/negotiation of features in a generic way. So that adding features in the future can be done without a necessity to add new messages to stratum protocol.
That’s mean that every miner can advertise its capabilities and at the same time it can request some needed features from the server, without fear if his message is an unknown message which usually produce a close of connection by the server.
Kind of extension proposed:
- version rolling: Allows the miner to change the value of some bits in the version field in the block header. Currently there are no standard bits used for version rolling so they need to be negotiated between a miner and a server.
- minimum-difficulty: Allows miner to request a minimum difficulty for the connected machine. It solves a problem in the original stratum protocol where there is no way how to communicate hard limit of the connected device.
- subscribe-extranonce: Parameter-less extension. Miner advertises its capability of receiving message “mining.set_extranonce” message (useful for hash rate routing scenarios).
- info: Miner provides additional text-based information, such as exact URL used by the mining software to connect to the stratum server “info.connection-url” (optional, String)