ASIC flexibility

[TierNolan]

I asked this in another thread, but figured the question could do with its own.

How flexible are ASIC miners?  For example, if an extra field was added to the header would they be able to handle it.

The current header is 80 bytes and then nonce is in then 2nd block of the first sha calculation.  This means they almost certainly can't handle moving the nonce to the first round.

SHA requires an 8 byte length field to be appended to the data.  Also, it requires a 1 to be appended.  This effectively clips 9 bytes off the total.

Currently, the first round is 64 bytes and then second round is 16 bytes (and the nonce is included).  This leaves 64 - 9 - 16 = 39 bytes free in block 2.

Does anyone have a datasheet for the ASIC chips.  Can they set the entire 2nd block to any initial value, or does it have to be <12 bytes><counter><39 zeros><0x80><8 byte length (640)>?

It doesn't seem like a big deal to make the 2nd block fully flexible.  It eliminates some optimizations that can be gained by setting the last 48 bytes to zero.  However, sha inherently scrambles everything, so it would only help for the first few rounds.  This small area reduction is at the expense of flexibility.

SHA has 64 rounds and it shifts the internal 256 bits by 32 bits per round.  This means that after 7 rounds the zeros will have been shifted and replaced by "random" data.  That creates a triangle of base 8 and height 7 and area 28.  The total hash is a rectangle of base 8 and height 64 giving an area of 320.  Therefore the saving in making the input non-flexible is 28/320 = 9%.  This is not "nothing", but it is a small price to have flexibility.  If there is more than 9% chance that the header will change, then it is a good investment.

Ofc, if ASICs are the main source of hashing, then they could block a header change.

[piotr_n]

I think you'd have a better chance of getting this answered, asking it in one of the mining sections.

[TierNolan]

I found this, which is the datasheet for the avalon chip.  (See section 4)

It isn't 100% clear and they have no controller code to check against.

It looks like they support any setting for the 2nd block.

You send the midstate (result from the first block), some additional precomputed values and then the data for the 2nd block.  It looks like the nonce is fixed though, and is handled separately.  It is 4 bytes, and there is no way to specify location.

Having said that, even if the chips are flexible, the full ASIC devices might not be.  Some kind of firmware upgrade would probably be needed.

[Silverpike]

I can answer this question for the ASIC implementations.

I believe that many existing ASIC implementations assume the rest of the bitcoin header after the nonce to be a fixed constant. I cannot speak for Avalon specifically, but I'm aware of several ASIC designs that will fail to work if the header is extended with non-constant data after the "2nd round" 16 bytes.

Is this proposal being seriously considered, or is this a what-if question?

[TierNolan]

I believe that many existing ASIC implementations assume the rest of the bitcoin header after the nonce to be a fixed constant. I cannot speak for Avalon specifically, but I'm aware of several ASIC designs that will fail to work if the header is extended with non-constant data after the "2nd round" 16 bytes.

It would still be mostly "constant".  The ASIC would still just vary the 32-bits of the nonce (so 4 billion hash checks).  The question was if the data after the nonce has to be all zeros, i.e. is it hard coded into the ASIC that the header is 80 bytes long.

Is this proposal being seriously considered, or is this a what-if question?

It is a what-if mainly.  I was just wondering if there was any point in even considering a header size change. 

If ASICs require an 80 byte header, then that pretty much brings the discussion to an end.

The fact that old clients also require an 80 byte header also acts against it.