Re: [bitcoin-dev] Making AsicBoost irrelevant

[Sergio Demian Lerner <sergio.d.lerner@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3934 bytes --]

Your idea of moving the Merkle root to the second chunk does not work.

The AsicBoost can change the version bits and it does not need to find a
collision.
(However *Spondoolies patent *only mentions Merkle collisions:
https://patentscope.wipo.int/search/docservicepdf_pct/id00000032873338/PAMPH/WO2016046820.pdf
)

Back in 2014 I designed a ASIC-compatible block header that prevents
AsicBoost in all its forms.

You can find it here:
https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/

Basically, the idea is to put in the first 64 bytes a 4 byte hash of the
second 64-byte chunk. That design also allows increased nonce space in the
first 64 bytes.

But it you want to do a simpler change, you can more easily use the first
32 bits of the Parent Block Hash (now currently zero) to store the first 4
bytes of the SHA256 of the last 16 bytes of the header. That way to "tie"
the two header chunks. It's a minimal change (but a hard-fork)

But some ASIC companies already have cores that are better (on power, cost,
rate, temperature, etc.) than competing companies ASICs. Why do you think a
10% improvement from AsicBoost is different from many of other improvements
they already have (secretly) added? Maybe we (?) should only allow ASICs
that have a 100% open source designs?

If we change the protocol then the message to the ecosystem is that ASIC
optimizations should be kept secret. It is fair to change the protocol
because we don't like that certain ASIC manufacturer has better chips, if
the chips are sold in the market and anyone can buy them? And what about
using approximate adders (30% improvement), or dual rail asynchronous
adders (also more than 10% improvement) ? How do we repair those?

Disclaimer: I have stake in AsicBoost, but I'm not sure about this.


On Tue, May 10, 2016 at 5:27 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 6163 bytes --]