The various chunks in the double SHA256 are

Chunk 1: 64 bytes
version
previous_block_digest
merkle_root[31:4]

Chunk 2: 64 bytes
merkle_root[3:0]
nonce
timestamp
target

Chunk 3: 64 bytes
digest from first sha pass

Their improvement requires that all data in Chunk 2 is identical except for the nonce.  With 4 bytes, the birthday paradox means collisions can be found reasonable easily.

If hard forks are allowed, then moving more of the merkle root into the 2nd chunk would make things harder.  The timestamp and target could be moved into chunk 1.  This increases the merkle root to 12 bytes in the 2nd chunk.  Finding collisions would be made much more difficult.

If ASIC limitations mean that the nonce must stay where it is, this would mean that the merkle root would be split into two pieces.

On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
As part of the hard-fork proposed in the HK agreement(1) we'd like to make the
patented AsicBoost optimisation useless, and hopefully make further similar
optimizations useless as well.

What's the best way to do this? Ideally this would be SPV compatible, but if it
requires changes from SPV clients that's ok too. Also the fix this should be
compatible with existing mining hardware.


1) https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff

2) http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html

--
https://petertodd.org 'peter'[:-1]@petertodd.org

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev