Tier Nolan [ARCHIVE] on Nostr: š Original date posted:2016-05-10 š Original message:The various chunks in the ...
š
Original date posted:2016-05-10
š Original message: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 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>;
š Original message: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 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>;