[bitcoin-dev] Making AsicBoost irrelevant

Tier Nolan tier.nolan at gmail.com
Tue May 10 20:27:28 UTC 2016

The various chunks in the double SHA256 are

Chunk 1: 64 bytes

Chunk 2: 64 bytes

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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/cb6a2690/attachment.html>

More information about the bitcoin-dev mailing list