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 > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
