Asicboost: several questions.

[stdset]

1) Is asicboost a hardware or software optimisation?
According to my current understanding, asicboost optimizes mining through forming a merkle root of special kind. That sounds like it should be implemented in software? Does hardware need to be designed in special way to take advantage of optimized merkle roots? If so, can such special hardware be used to mine regular, unoptimized blocks?

2) Is asicboost (as the name suggests) applicable only to ASICs (not to GPUs, FPGAs)? If so - why?

3) Does observing of empty blocks from a miner increase our suspicions of asicboost being used?
I guess, that since they need a special merkle root, it may happen, that an empty or almost-empty block provides a necessary merkle root, so they just keep mining such an empty block until it is mined or an optimized merkle root found for a filled block, whichever happens first?

4) If it's all about special merkle roots, why couldn't we detect asicboost optimized blocks just by analysing the blocks and their merkle roots?

I suggest staying purely technical, apolitical. Therefore I made this thread self-moderated.

[1714025521]

1714025521

[1714025521]

1714025521

[1714025521]

1714025521

[achow101]

1) Is asicboost a hardware or software optimisation?

As I understand it, both, but the effect is more greatly seen in hardware optimization. With hardware optimization for asicboost, you will still need corresponding software to perform the preprocessing.

According to my current understanding, asicboost optimizes mining through forming a merkle root of special kind. That sounds like it should be implemented in software? Does hardware need to be designed in special way to take advantage of optimized merkle roots? If so, can such special hardware be used to mine regular, unoptimized blocks?

There are two forms of asicboost, overt and covert. The overt form involves changing the bits in the version number and that is pretty obvious to see once the block is found, hence it is overt. The covert form involves finding multiple merkle roots which collide in the last 32 bits.

The way that asicboost works is that it takes advantage of the way that sha256 processes data in order to use the partial hashes of previous block headers when calculating the hashes of multiple block headers so it reduces the number of calculations that need to be made, which in turn makes the mining more efficient.

2) Is asicboost (as the name suggests) applicable only to ASICs (not to GPUs, FPGAs)? If so - why?

The most gains can be found in ASICs because the mining circuitry can be changed to be asicboost circuitry which has less logic gates and is thus more efficient.

3) Does observing of empty blocks from a miner increase our suspicions of asicboost being used?
I guess, that since they need a special merkle root, it may happen, that an empty or almost-empty block provides a necessary merkle root, so they just keep mining such an empty block until it is mined or an optimized merkle root found for a filled block, whichever happens first?

Possibly, but given that empty blocks still happen without asicboost, it isn't really an indicator of much.

4) If it's all about special merkle roots, why couldn't we detect asicboost optimized blocks just by analysing the blocks and their merkle roots?

The covert form of asicboost involves merkle roots. It involves finding and having multiple merkle roots which collide in the last 32 bits. However, because miners only broadcast their final block, outside observers cannot know what the other merkle roots that they have tried and whether those collide. Since we don't know anything about the other merkle roots, we don't know if they are using covert asicboost.

If they use overt asicboost, it is very obvious; the block version number will be all messed up.

[stdset]

Thank you for the answers. It became clearer now.

The covert form involves finding multiple merkle roots which collide in the last 32 bits.

This actually answers question 4.

I guess, that since they need a special merkle root, it may happen, that an empty or almost-empty block provides a necessary merkle root, so they just keep mining such an empty block until it is mined or an optimized merkle root found for a filled block, whichever happens first?

Provided with the answers, I would rephrase the sentence, that asicboost optimized miners mine several blocks at once. Some of them may happen to be empty or half-empty. They don't exclude underfilled blocks from the set because it would decrease efficiency of their optimisation. Once they found a set of colliding merkle roots, they mine corresponding blocks, until one of the blocks is mined or another set of colliding roots (for better blocks) is found.

Possibly, but given that empty blocks still happen without asicboost, it isn't really an indicator of much.

So, in my opinion, increased rate of empty blocks does increase our suspicions. Although it isn't a proof of course.

[Carlton Banks]

Possibly, but given that empty blocks still happen without asicboost, it isn't really an indicator of much.

So, in my opinion, increased rate of empty blocks does increase our suspicions. Although it isn't a proof of course.

Indeed, we have no direct proof that Bitmain were using their ASIC Boost mining, despite all the implications. I guess that's why this technique is labelled covert.


The closest to actual proof we can attain is more correlation without causation type of evidence: will Antpool empty & near-empty blocks suddenly stop happening once the flag day for the ASIC boost BIP becomes activated? That would increase the suspicion, and nothing more. Antpool's hashrate may drop by the vaunted 20-30%, but they could easily mask that by carefully staging future hashrate rollout that was already planned to make their hashrate appear unchanged. If that were the case, I hope they work hard on this camouflaging job

[-ck]

The number of empty blocks by antpool and the timing of those blocks found in relation to the previous blocks is consistent with SPV/SPY header only mining that almost every Chinese pool does (and I'm against.) In light of that, it's hard to believe that antpool only were using covert asicboost mining to their advantage unless every single Chinese pool was also doing it (but the timing again is consistent with quick blocks built on headers.) At this stage in my opinion I'd have to say they haven't been using it. Additionally looking at whatever code they have released in the past suggests they barely know what they're doing most of the time in software so while they know hardware, for some reason they're hopeless with software, rushing anything that 'just works' and not caring beyond that. I've never seen overt asicboost working anywhere and the evidence isn't there for covert.
In the first release of their branded fork of my software they called bmminer for the S9 miner they had an extra field in their stratum subscribe message which I suspect was a planned deployment of asicboost but that then went away in their next firmware onwards.

[gmaxwell]

The number of empty blocks by

Personally, I didn't expect empty blocks to be involved.  (Though, antpool has produced significantly more empty blocks historically, e.g. between 390750 and 408052 there were 652 empties, 399 of them were antpool tagged).

I've never seen overt asicboost working anywhere

Several people have it working now, and if you have a S9 or R4 they can point you to a stratum endpoint that will get you mining with it.

Strangely one problem they've run into is that if you have it use 4 versions (which would be better for efficiency) it produces otherwise valid headers with the most significant bit set... which are invalid per (IIRC) BIP 30. So far, no one has figured out what command to send the FPGA to use different version numbers.

(As an aside, dontcha think it's odd that R4's FPGA has 16 MB of dual-channel 2133MB/s memory  mapped to it?)

[-ck]

I've never seen overt asicboost working anywhere

Several people have it working now, and if you have a S9 or R4 they can point you to a stratum endpoint that will get you mining with it.

Thanks. What I'm referring to is any pool producing blocks with rolling version numbers.

[-ck]

The number of empty blocks by

Personally, I didn't expect empty blocks to be involved.  (Though, antpool has produced significantly more empty blocks historically, e.g. between 390750 and 408052 there were 652 empties, 399 of them were antpool tagged).

We went on the warpath around that time and made lots of noise about the Chinese pools producing so many empty blocks. F2pool were the first to respond who made big inroads in making it happen far less frequently - they then handed off their technique to the other Chinese pools who followed suit, since f2pool more or less were the first to implement header mining and gave it to the others. Antpool being the worst offender back then doesn't surprise me - their pool admins are morons. I don't think that was related to asicboost either, just plain stupidity vs malice Hanlon's razor style.

[johoe]

1) Is asicboost a hardware or software optimisation?
According to my current understanding, asicboost optimizes mining through forming a merkle root of special kind. That sounds like it should be implemented in software? Does hardware need to be designed in special way to take advantage of optimized merkle roots? If so, can such special hardware be used to mine regular, unoptimized blocks?

It requires both hard- and software support.  The software needs to feed the hardware with different first half headers for which the same second half of the header can be used.  The hardware must be designed to make use of the fact the second half of the header is used with different first halfs and leave out some calculations.  If I understand the antminer design correctly, their hardware can turn off the circuit that recomputes the very first step of the second header.  This saves some energy, but not make it faster.

2) Is asicboost (as the name suggests) applicable only to ASICs (not to GPUs, FPGAs)? If so - why?

it should apply the same way to GPUs, FPGAs or CPU miners.   However, I think it is more useful if you have several THash/s.

3) Does observing of empty blocks from a miner increase our suspicions of asicboost being used?
I guess, that since they need a special merkle root, it may happen, that an empty or almost-empty block provides a necessary merkle root, so they just keep mining such an empty block until it is mined or an optimized merkle root found for a filled block, whichever happens first?

Empty blocks can have several different reasons.  They may indicate asicboost (which may add an additional delay for computing colliding hashes), but it can also be a slow block verifier, or the network has high delays, or just an inefficient design of the pool.

I think you can compute collisions for an empty blocks in advance before the previous block was found (is there any reason why not?).  So while you search for Merkle Tree collisions, you can still use the precomputed collisions to mine empty blocks with Asicboost.  But this all is pure speculation on my part.

4) If it's all about special merkle roots, why couldn't we detect asicboost optimized blocks just by analysing the blocks and their merkle roots?

You can make them completely invisible.  Randomize the payout address, swap transactions that are exactly at the same fee level, insert your own transactions that you send to the network to hide the fact that it is an artficial transaction, etc.
You only publish the block if you have a solution, the colliding Merkle Roots are never published (they cannot be used for other blocks).
But you can't hide using asicboost from someone who has access to the hardware or the communications between server and hardware, so it is possible to verify whether the antminer you have in your home uses Asicboost.