diff options
| author | James Hilliard <james.hilliard1@gmail.com> | 2016-05-11 18:00:59 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-05-11 22:01:01 +0000 |
| commit | 9dff5560a240f06a1fe5b6b9805c6d1b78cc51eb (patch) | |
| tree | 908c04640f72aac44cddff6c0ce2dc604c011574 | |
| parent | 6c3ffe81cea90fcd86a35b31064f3944b0ef5c75 (diff) | |
| download | pi-bitcoindev-9dff5560a240f06a1fe5b6b9805c6d1b78cc51eb.tar.gz pi-bitcoindev-9dff5560a240f06a1fe5b6b9805c6d1b78cc51eb.zip | |
Re: [bitcoin-dev] Making AsicBoost irrelevant
| -rw-r--r-- | 49/9ff63d65021de91a7a41b939e5a90a9b7e706f | 188 |
1 files changed, 188 insertions, 0 deletions
diff --git a/49/9ff63d65021de91a7a41b939e5a90a9b7e706f b/49/9ff63d65021de91a7a41b939e5a90a9b7e706f new file mode 100644 index 000000000..f3ffaf6c4 --- /dev/null +++ b/49/9ff63d65021de91a7a41b939e5a90a9b7e706f @@ -0,0 +1,188 @@ +Return-Path: <james.hilliard1@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id B9343267 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 11 May 2016 22:01:01 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com + [209.85.218.45]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8607C12F + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 11 May 2016 22:01:00 +0000 (UTC) +Received: by mail-oi0-f45.google.com with SMTP id k142so90969438oib.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 11 May 2016 15:01:00 -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 + :content-transfer-encoding; + bh=X1Iac2kp2ZtTptAE0fpNrvInyTHuSfVknuJIbJWAFp0=; + b=yv68iYsN5mXnezacOZLkpQUTwU7j1bjNK4KEoaQ7GXUJt+6zKIbt0Sd6xFe9HnPAmq + 1RQSg9X0FxRAYipaiiayN33x5jk6kNvvq1krxV8JdVxtH7Oebm6ThSKRZ5lyI0KB37ep + 3n53iu9Jbjnsewr2H/xTxvGhCOxBy6HaYWWi8zQa4pVfb8dpf3SC/SVz+1ASPL+wYIbe + 9Om9B8JK4CW3DHBBM/Ttz8on6x+D824/jNV8/j+CDcbijDcCaGnDBxe2HMWQNJ3sk9aj + f3Q3pJSGCj0393XW+BsOzw0J/K0hiZJ6GVf6Jf3ilTI0X8wIfSiWycLviNxHeMcSJNJV + qfLA== +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:content-transfer-encoding; + bh=X1Iac2kp2ZtTptAE0fpNrvInyTHuSfVknuJIbJWAFp0=; + b=ja6mY64sHv3uLnXXfwhIGxFVGAknr/PIbsu8ukKSGbRl1QiW+2Mm7aVKoQA407LkyH + hMZNGIFQj9vT5GcjcZZdmWFQAbVDf1OKlfP7MxxdRckO0Grpwhs43BLWOC163zQXou4t + kq98SKnN4CWlqRu2Lf/dpXqdf3GCl+E9qoCV2CwhApiPzIfh9kRlR124/q0TaQCqo7+i + KK1xtJR/k/NcHloXRm88YZiJZ/2cHHQ9RGr6EiaOTYKqyTgXt/9V2OwiFhgZSbHq4EDy + +9Lmtd6mM6FLH3qwN1Ht7XBnNbZtGkJlat/T0QUee13MdK8fCZiaAlK8cErKwmiWWROv + lf2w== +X-Gm-Message-State: AOPr4FUY8PLRqZCrTGW9kxyC10jG8UC3Dj7IPDLjgo1iC8zBSmD6C0TCTC4xFvcEpTTUURhYSWUPLl9hc9kxEQ== +MIME-Version: 1.0 +X-Received: by 10.202.204.21 with SMTP id c21mr3022667oig.188.1463004059804; + Wed, 11 May 2016 15:00:59 -0700 (PDT) +Received: by 10.182.115.138 with HTTP; Wed, 11 May 2016 15:00:59 -0700 (PDT) +In-Reply-To: <57339B02.3060806@mattcorallo.com> +References: <20160510185728.GA1149@fedora-21-dvm> + <CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com> + <57339B02.3060806@mattcorallo.com> +Date: Wed, 11 May 2016 18:00:59 -0400 +Message-ID: <CADvTj4pmH2+TE4hdfr3Yo9CMxuDBjzAXj2j-gmpGkmrOMH6Pjg@mail.gmail.com> +From: James Hilliard <james.hilliard1@gmail.com> +To: Matt Corallo <lf-lists@mattcorallo.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, + 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:01:01 -0000 + +I was told that the patent appears to be owned exclusively by Bitmain +in China https://www.google.com/patents/CN105245327A?cl=3Den + +On Wed, May 11, 2016 at 4:50 PM, Matt Corallo via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> That's the reason for this post! All current major ASIC manufacturers +> have made warrants that they are not using AsicBoost (with the exception +> of the 21 Inc Bitcoin computer). +> +> The fact that the optimization was patented is what has required that we +> work to hardfork it out, not that people might have such private +> optimizations. The fact that AsicBoost was independently discovered by +> at least two (if not three) organizations seems to lend credence to the +> idea that private optimizations will only provide a temporary win over +> competitors. +> +> Matt +> +> On 05/11/16 03:14, Timo Hanke via bitcoin-dev wrote: +>> There is no way to tell from a block if it was mined with AsicBoost or +>> not. So you don=E2=80=99t know what percentage of the hashrate uses Asic= +Boost at +>> any point in time. How can you risk forking that percentage out? Note +>> that this would be a GUARANTEED chain fork. Meaning that after you +>> change the block mining algorithm some percentage of hardware will no +>> longer be able to produce valid blocks. That hardware cannot =E2=80=9Csw= +itch +>> over=E2=80=9D to the majority chain even if it wanted to. Hence you are +>> guaranteed to have two co-existing bitcoin blockchains afterwards. +>> +>> Again: this is unlike the hypothetical persistence of two chains after a +>> hardfork that is only contentious but doesn=E2=80=99t change the mining +>> algorithm, the kind of hardfork you are proposing would guarantee the +>> persistence of two chains. +>> +>> Note that =E2=80=9CAsicBoost=E2=80=9D above is replaceable with =E2=80= +=9Coptimization X=E2=80=9D. It=E2=80=99s +>> simply a logical argument: If you want to make optimization X impossible +>> and someone is already using optimization X you end up with two chains. +>> So unless you know exactly which optimizations are in use (and therefore +>> also know which ones are not in use) you can=E2=80=99t make these kind o= +f +>> changes. AsicBoost is known at least since middle of 2013. +>> +>> To be more precise, if you change the block validation ruleset R to +>> block validation ruleset S you have to make sure that every hardware +>> that was capable of mining R-valid blocks is also capable of mining +>> S-valid blocks. +>> +>> The problem is that chip manufacturers will not tell you which +>> optimizations they use. You would have to threaten to irreversibly fork +>> their hardware out by a rule change, only then would they start shouting +>> and reveal their optimization. It seems extremely dangerous to set the +>> precedence of a hardfork that irreversibly forks out a certain type of +>> mining hardware. +>> +>> The part "Also the fix should be compatible with existing mining +>> hardware." is impossible to achieve because it's unclear what "existing +>> mining hardware" is. There has never been a specification of what mining +>> hardware should do. There are only acceptance rules. +>> +>> The only way out is to go the exact opposite way and to embrace as many +>> optimizations as possible to the point where there are no more +>> optimizations left to do, or hopefully getting very close to that point. +>> +>> Timo +>> +>> +>> +>> On Tue, May 10, 2016 at 11:57 AM, Peter Todd via bitcoin-dev +>> <bitcoin-dev@lists.linuxfoundation.org +>> <mailto: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-2= +66d475a61ff +>> +>> 2) +>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/01= +2596.html +>> +>> -- +>> https://petertodd.org 'peter'[:-1]@petertodd.org <http://petertodd.o= +rg> +>> +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> <mailto: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 +>> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + |