From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B4E2671E for ; Tue, 10 May 2016 20:27:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03D9A145 for ; Tue, 10 May 2016 20:27:29 +0000 (UTC) Received: by mail-lf0-f44.google.com with SMTP id y84so28107971lfc.0 for ; Tue, 10 May 2016 13:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=/Nx420WGAUHLr9gu9V3wuJubx00p+MZ7K0AKQzO6K2U=; b=GFgp7IOIjwaYWVyqCzgYWGfSOhVyLQejkGMCu22EEA8i9LE6iMl4mH5dn22ilneHTf qGKlx0i0+QXetYTu0RWIOg+NlbY98CbzjRP7AdaUNat92LFdrYqROn6UwtVLxTBv8C9k D3n32XDr/p6fD41N+D5Pr7OfUbE5zUr4twsndLhB+KhrIsfqpY55cVfQ31lBmtz7mW3S JVrFYcJ295gkykPZEoFs35G6k7Li3vOnWlyx20WKle7pQo1Pt19/DMg6QX4EgGgr/eD1 8FWvCpQk29+fNX3mbFuxJXvdeKG6gvrd93ajHsR2YXEJp4hiYtdy2eOWHekrcsnzD8wl mX1w== 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; bh=/Nx420WGAUHLr9gu9V3wuJubx00p+MZ7K0AKQzO6K2U=; b=MxdXKeldAH00AkL4YeJlx+8WU/w2xAv2SJx47LGsrSXMA4Mxob/o4WHvfiaqCZDJNc h4uuGgEL2nR64kay2l4Fg8QVoGYYraY0lyL/ziY2MMVFmR0UeAQkauxt5slI5Y7T3DrR 5E0boGKFBaWLzYk8o/WbtfjeoylPGIaEzR5E1Pwo0le/7qUbkOTX0LOwtgL+2Cg7GhJK iYgKXcpmFGQnLJLLY56uSzZWI1YeRWLv+UZx2lQvDpFOUxO/uj2SjTM46wG1NO4X6vSB m9EdJ/U2zRUhFk5DP3EaslQ3RT7ul/4QeEp0YRuhsewGz7WPCtZDYO2gqxAQnN/SYV7M Bm7g== X-Gm-Message-State: AOPr4FXrJzKhehcBozZ+XhUf0v8YZKoEv5rYp0t9gUgiXcH76NiHGwyyn1ch1nzKlcFLIohGWtmFplLqugoEAA== MIME-Version: 1.0 X-Received: by 10.112.62.193 with SMTP id a1mr15537584lbs.22.1462912048122; Tue, 10 May 2016 13:27:28 -0700 (PDT) Received: by 10.112.31.133 with HTTP; Tue, 10 May 2016 13:27:28 -0700 (PDT) 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: From: Tier Nolan To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a11c3c7daf75411053282c0aa X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 20:27:30 -0000 --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
The various chunks in the double SHA256 are=

Chunk 1: 64 bytes
version
p= revious_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

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.

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.

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.
On Tue, May 10, 2016 at 7:57 PM, Peter Todd vi= a 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, b= ut if it
requires changes from SPV clients that's ok too. Also the fix this shou= ld be
compatible with existing mining hardware.


1) https://medium.com= /@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff

2) http://lists.linuxfo= undation.org/pipermail/bitcoin-dev/2016-April/012596.html

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a11c3c7daf75411053282c0aa--