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 B9343267 for ; 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 ; Wed, 11 May 2016 22:01:00 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id k142so90969438oib.1 for ; 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> <57339B02.3060806@mattcorallo.com> Date: Wed, 11 May 2016 18:00:59 -0400 Message-ID: From: James Hilliard To: Matt Corallo , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 >> > > 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 >> >> _______________________________________________ >> 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev