MIME-Version: 1.0
In-Reply-To: <20160510185728.GA1149@fedora-21-dvm>
References: <20160510185728.GA1149@fedora-21-dvm>
Date: Tue, 10 May 2016 21:27:28 +0100
Message-ID: <CAE-z3OWvLqONwaN+608jBn9=q1yUvU4ggGrMpA8rE6qmjDQHtg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c3c7daf75411053282c0aa
Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant
Precedence: list

--001a11c3c7daf75411053282c0aa
Content-Type: text/plain; charset=UTF-8

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

--001a11c3c7daf75411053282c0aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>The various chunks in the double SHA256 are=
<br><br></div><div></div>Chunk 1: 64 bytes<br></div>version<br></div><div>p=
revious_block_digest<br></div>merkle_root[31:4]<br><div><div><br></div><div=
>Chunk 2: 64 bytes<br></div><div>merkle_root[3:0]<br></div><div>nonce<br></=
div><div>timestamp<br></div><div>target<br><br></div><div>Chunk 3: 64 bytes=
<br></div><div>digest from first sha pass<br><br></div><div></div><div>Thei=
r improvement requires that all data in Chunk 2 is identical except for the=
 nonce.=C2=A0 With 4 bytes, the birthday paradox means collisions can be fo=
und reasonable easily.<br><br>If hard forks are allowed, then moving more o=
f the merkle root into the 2nd chunk would make things harder.=C2=A0 The ti=
mestamp and target could be moved into chunk 1.=C2=A0 This increases the me=
rkle root to 12 bytes in the 2nd chunk.=C2=A0 Finding collisions would be m=
ade much more difficult.<br><br></div><div>If ASIC limitations mean that th=
e nonce must stay where it is, this would mean that the merkle root would b=
e split into two pieces.<br></div></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Tue, May 10, 2016 at 7:57 PM, Peter Todd vi=
a bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As part of the hard-=
fork proposed in the HK agreement(1) we&#39;d like to make the<br>
patented AsicBoost optimisation useless, and hopefully make further similar=
<br>
optimizations useless as well.<br>
<br>
What&#39;s the best way to do this? Ideally this would be SPV compatible, b=
ut if it<br>
requires changes from SPV clients that&#39;s ok too. Also the fix this shou=
ld be<br>
compatible with existing mining hardware.<br>
<br>
<br>
1) <a href=3D"https://medium.com/@bitcoinroundtable/bitcoin-roundtable-cons=
ensus-266d475a61ff" rel=3D"noreferrer" target=3D"_blank">https://medium.com=
/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff</a><br>
<br>
2) <a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-A=
pril/012596.html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2016-April/012596.html</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</font></span><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a11c3c7daf75411053282c0aa--