summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTimo Hanke <timo.hanke@web.de>2016-05-11 15:49:25 -0700
committerbitcoindev <bitcoindev@gnusha.org>2016-05-11 22:49:30 +0000
commit9cdc62ed8be5ef9829e890f65305b00b64f172d8 (patch)
treebe47d994a82c8977b6e5d14eb09f28ee2930c9e4
parentf284ca1f414557802c8e51e3ba5cf024a5af04e7 (diff)
downloadpi-bitcoindev-9cdc62ed8be5ef9829e890f65305b00b64f172d8.tar.gz
pi-bitcoindev-9cdc62ed8be5ef9829e890f65305b00b64f172d8.zip
Re: [bitcoin-dev] Making AsicBoost irrelevant
-rw-r--r--c5/7e23d1915fd2395023f105b19ad429c8ec95c2221
1 files changed, 221 insertions, 0 deletions
diff --git a/c5/7e23d1915fd2395023f105b19ad429c8ec95c2 b/c5/7e23d1915fd2395023f105b19ad429c8ec95c2
new file mode 100644
index 000000000..0349b4a84
--- /dev/null
+++ b/c5/7e23d1915fd2395023f105b19ad429c8ec95c2
@@ -0,0 +1,221 @@
+Return-Path: <timo.t.hanke@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 14EC95AE
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 11 May 2016 22:49:30 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com
+ [209.85.215.54])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 01F79123
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 11 May 2016 22:49:28 +0000 (UTC)
+Received: by mail-lf0-f54.google.com with SMTP id u64so62551437lff.3
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 11 May 2016 15:49:28 -0700 (PDT)
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20130820;
+ h=x-gm-message-state:mime-version:in-reply-to:references:date
+ :message-id:subject:from:to:cc;
+ bh=dKh5Q17slN8XLe6H/TnWgtZykEo672WPbVgv5NU0euw=;
+ b=FZjP/XLCteQy7Amd3C6KbkbvKEm51N0vvTpbJDSs4F9TeNtuZV8TmqXFGF6R1MSW+X
+ ++epzO03y7BdUsycdbyYmBd1w/6uBu/kcbjnY9gkwwoWXwssb717VOsir8ZuR4A81uWN
+ iT9dcBPhmj/B2quV6tjqlb7fRueG7lVXVjAX467FyUmL6MTYjc7Bh6Hd6uKuWaGJQFTI
+ LC8aE3u9WCZsRN9mlPNDXMFYR3UpK457ACHJIAIdYsentcoMpiqGiC/w+hpwu13hs2aQ
+ 0VYyAXQ3O7TVQUT30Uz9VjnSgBGb7rJFFJHkq/5q/Qiufzx5g5aY0kr2dDOZp7+FwAvY
+ cFjw==
+X-Gm-Message-State: AOPr4FVG9YO0tDMc4Ahe0eh18FUxFr4A2cdGJ1194MW9/h1NifjmxTiaGofFbzS8IdR0sw==
+X-Received: by 10.25.161.141 with SMTP id k135mr2791511lfe.101.1463006967459;
+ Wed, 11 May 2016 15:49:27 -0700 (PDT)
+Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com.
+ [209.85.217.174])
+ by smtp.gmail.com with ESMTPSA id oq7sm777190lbb.47.2016.05.11.15.49.26
+ for <bitcoin-dev@lists.linuxfoundation.org>
+ (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
+ Wed, 11 May 2016 15:49:27 -0700 (PDT)
+Received: by mail-lb0-f174.google.com with SMTP id h1so2626106lbj.3
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 11 May 2016 15:49:26 -0700 (PDT)
+MIME-Version: 1.0
+X-Received: by 10.112.10.9 with SMTP id e9mr2761333lbb.142.1463006965913; Wed,
+ 11 May 2016 15:49:25 -0700 (PDT)
+Received: by 10.25.144.8 with HTTP; Wed, 11 May 2016 15:49:25 -0700 (PDT)
+In-Reply-To: <CAH6h1LsRgZEar8JDR2m-hsTc-DE+=A6BzOq_X2CHSya=bxFRQQ@mail.gmail.com>
+References: <20160510185728.GA1149@fedora-21-dvm>
+ <CAKzdR-ou2FYjjxmRBLARhvfhHO-46weiMc2Q2f+GZf1E_JUEAg@mail.gmail.com>
+ <CAKzdR-pFZGsQZPrHRbJhviFemSLPf8Bo6UWSaaQ-BurCsnAAWw@mail.gmail.com>
+ <201605111428.25918.luke@dashjr.org>
+ <CAH6h1LuVSSxZtOFNGP-Etx-UQGnWMxp1FL0E137yo7D+Wtcs7A@mail.gmail.com>
+ <CAH6h1LsRgZEar8JDR2m-hsTc-DE+=A6BzOq_X2CHSya=bxFRQQ@mail.gmail.com>
+Date: Wed, 11 May 2016 15:49:25 -0700
+X-Gmail-Original-Message-ID: <CAH6h1Lvao0CXCdGoutEskdtM0gOS0S1bkK_ovGtD523wyab6Zw@mail.gmail.com>
+Message-ID: <CAH6h1Lvao0CXCdGoutEskdtM0gOS0S1bkK_ovGtD523wyab6Zw@mail.gmail.com>
+From: Timo Hanke <timo.hanke@web.de>
+To: Luke Dashjr <luke@dashjr.org>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Content-Type: multipart/alternative; boundary=001a1136069c81e2e9053298da52
+X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
+ HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Wed, 11 May 2016 22:49:30 -0000
+
+--001a1136069c81e2e9053298da52
+Content-Type: text/plain; charset=UTF-8
+
+Ups, I forgot that you take the midstate which of course depends on the
+version number. So forget everything I said about the version bits. You are
+right. But why take the midstate? It can be any hash of the first chunk. So
+you probably want to take a hash function that's available in standard
+software libraries. And I suppose midstate() is not.
+
+
+On Wed, May 11, 2016 at 11:28 AM, Timo Hanke <timo.hanke@web.de> wrote:
+
+> Sorry, you must have meant all 12 bytes. That makes finding a collision
+> substantially harder. However, you may have to restrict yourself to 10
+> bytes because you don't know if any hardware does timestamp rolling
+> on-chip. Also you create an incentive to mess around with the version bits
+> instead, so you would have to fix that as well. So it basically means a new
+> mining header with the real blockheader as a child header.
+>
+> On Wed, May 11, 2016 at 9:24 AM, Timo Hanke <timo.hanke@web.de> wrote:
+>
+>> Luke, do you mean to replace the first 4 bytes of the second chunk (bytes
+>> 64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4
+>> bytes of the midstate? (I assume you don't care about 12 bytes but rather
+>> those 4 bytes.)
+>>
+>> This does not work. All it does is adding another computational step
+>> before you can check for a collision in those 4 bytes. It makes finding a
+>> collision only marginally harder.
+>>
+>> On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev <
+>> bitcoin-dev@lists.linuxfoundation.org> wrote:
+>>
+>>> On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via
+>>> bitcoin-dev
+>>> wrote:
+>>> > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
+>>> > sergio.d.lerner@gmail.com> wrote:
+>>> > > You can find it here:
+>>> > >
+>>> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo
+>>> > > ck-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.
+>>> >
+>>> > My mistake here. I didn't recalled correctly my own idea. The idea is
+>>> to
+>>> > include in the second 64-byte chunk a 4-byte hash of the first chunk,
+>>> not
+>>> > the opposite.
+>>>
+>>> What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?
+>>> Would that work?
+>>>
+>>> Luke
+>>> _______________________________________________
+>>> bitcoin-dev mailing list
+>>> bitcoin-dev@lists.linuxfoundation.org
+>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>>>
+>>
+>>
+>
+
+--001a1136069c81e2e9053298da52
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">Ups, I forgot that you take the midstate which of course d=
+epends on the version number. So forget everything I said about the version=
+ bits. You are right. But why take the midstate? It can be any hash of the =
+first chunk. So you probably want to take a hash function that&#39;s availa=
+ble in standard software libraries. And I suppose midstate() is not.<div><b=
+r></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
+Wed, May 11, 2016 at 11:28 AM, Timo Hanke <span dir=3D"ltr">&lt;<a href=3D"=
+mailto:timo.hanke@web.de" target=3D"_blank">timo.hanke@web.de</a>&gt;</span=
+> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
+rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Sorry, you must=
+ have meant all 12 bytes. That makes finding a collision substantially hard=
+er. However, you may have to restrict yourself to 10 bytes because you don&=
+#39;t know if any hardware does timestamp rolling on-chip. Also you create =
+an incentive to mess around with the version bits instead, so you would hav=
+e to fix that as well. So it basically means a new mining header with the r=
+eal blockheader as a child header.=C2=A0</div><div class=3D"HOEnZb"><div cl=
+ass=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed=
+, May 11, 2016 at 9:24 AM, Timo Hanke <span dir=3D"ltr">&lt;<a href=3D"mail=
+to:timo.hanke@web.de" target=3D"_blank">timo.hanke@web.de</a>&gt;</span> wr=
+ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
+-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Luke, do you mean t=
+o replace the first 4 bytes of the second chunk (bytes 64..67 in 0-based co=
+unting) by the XOR of those 4 bytes with the first 4 bytes of the midstate?=
+ (I assume you don&#39;t care about 12 bytes but rather those 4 bytes.)<div=
+><br></div><div>This does not work. All it does is adding another computati=
+onal step before you can check for a collision in those 4 bytes. It makes f=
+inding a collision only marginally harder.</div></div><div><div><div class=
+=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, May 11, 2016 at 7:2=
+8 AM, Luke Dashjr via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:b=
+itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
+inuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
+e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
+On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev=
+<br>
+wrote:<br>
+<div><div>&gt; On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner &lt;<b=
+r>
+&gt; <a href=3D"mailto:sergio.d.lerner@gmail.com" target=3D"_blank">sergio.=
+d.lerner@gmail.com</a>&gt; wrote:<br>
+&gt; &gt; You can find it here:<br>
+&gt; &gt; <a href=3D"https://bitslog.wordpress.com/2014/03/18/the-re-design=
+-of-the-bitcoin-blo" rel=3D"noreferrer" target=3D"_blank">https://bitslog.w=
+ordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo</a><br>
+&gt; &gt; ck-header/<br>
+&gt; &gt;<br>
+&gt; &gt; Basically, the idea is to put in the first 64 bytes a 4 byte hash=
+ of the<br>
+&gt; &gt; second 64-byte chunk. That design also allows increased nonce spa=
+ce in<br>
+&gt; &gt; the first 64 bytes.<br>
+&gt;<br>
+&gt; My mistake here. I didn&#39;t recalled correctly my own idea. The idea=
+ is to<br>
+&gt; include in the second 64-byte chunk a 4-byte hash of the first chunk, =
+not<br>
+&gt; the opposite.<br>
+<br>
+</div></div>What if we XOR bytes 64..76 with the first 12 bytes of the SHA2=
+ midstate?<br>
+Would that work?<br>
+<br>
+Luke<br>
+<div><div>_______________________________________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+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>
+</div></div></blockquote></div><br></div>
+</div></div></blockquote></div><br></div>
+</div></div></blockquote></div><br></div>
+
+--001a1136069c81e2e9053298da52--
+