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 59A9571E for ; Wed, 11 May 2016 14:07:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF69117B for ; Wed, 11 May 2016 14:07:27 +0000 (UTC) Received: by mail-vk0-f54.google.com with SMTP id o133so58243155vka.0 for ; Wed, 11 May 2016 07:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=CtMVKhwLK9gfB4fCxZ1/hAAqr1sL9aE2b3PUp/NCsDw=; b=duDLeFQEJIPTmrTdGpO6X7SfTLgflxFAFGCS+rmpBhIvPQ3AX8KQX3zwicSFhFzQXs WFpcmdq6zLT3waL4U9uSoTRVJaY6fkNWEuIjdsECUMQxoG6TXu2T/BiOktL0Zv13VkGB jPZYCbFfJQL3mUelpGwy9cW/F97FFJ0XVNXene3RfBKFMLksi45x/dKRWHf3aPEK6o7Q rrvto89MfWSx0MMUcQEBOe7KCXGkIMlmjdRI63dPf2+md6bMxM3TeCYYQF6+n3unO931 pSnrrbQqNA4H5PlYNqefZlp/Lj8gTOXMPmSbtMW7W405sfkBYmCvNf32X8dgocFI7i21 5ygg== 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=CtMVKhwLK9gfB4fCxZ1/hAAqr1sL9aE2b3PUp/NCsDw=; b=OQVF5rvLzhwYHRswW6efUbvtCABt5mCx5xAOsR8I7y7Oys7x5sFM9EAXHCUAa128xd iy32rglZWpQbV/zJ0+wCknoCt2L8pCW4wTpERUOwGjI58kWtMBjMgxGxg38YF5Xd4rFs tPicGoGM5dl1pBo9KPi4b+NKaBybVTAfx+4ipcta2SH/bzzh0zGHynn0Ny2isr1f2ffR NLb7O8e/mbSe0z61FVqcaFaNa7ilSJtvbewR+FNgsZmOwYWj6nYXsjhNo66oRhtUeWLm 0QdKdUnfRvUk9EPnuCbz0+EU+WczwS0U0hNCzssPQAgmbNE/wJjD0GN2ACsTRGsZBsfx 1Otw== X-Gm-Message-State: AOPr4FW8zF4iu6VRbznfNCFio0zRsPTXQHdr6rcc924ySLIzp1VRIGvKUeiH87S2bROp9s/v5Z0wVV2mp5TmnA== MIME-Version: 1.0 X-Received: by 10.176.6.38 with SMTP id f35mr1859982uaf.36.1462975646826; Wed, 11 May 2016 07:07:26 -0700 (PDT) Received: by 10.31.141.73 with HTTP; Wed, 11 May 2016 07:07:26 -0700 (PDT) Received: by 10.31.141.73 with HTTP; Wed, 11 May 2016 07:07:26 -0700 (PDT) In-Reply-To: References: <20160510185728.GA1149@fedora-21-dvm> Date: Wed, 11 May 2016 16:07:26 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Timo Hanke , Bitcoin Dev Content-Type: multipart/alternative; boundary=94eb2c04796ebfb9d90532918f3e X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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: Wed, 11 May 2016 14:07:28 -0000 --94eb2c04796ebfb9d90532918f3e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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 alg= orithm, the kind of hardfork you are proposing would guarantee the persistence of two chains. If all users abandon the old rules, why would asicboost miners continue to spend energy on a chain that everybody else is ignoring? > 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. Why? No, this proposal, for example, may make patented asicboost hardware obsolete. I don't accept this claim as true, this is just your opinion. > > 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. What do you mean by "embrace" in the context of a patented optimization that one miner can prevent the rest from using? --94eb2c04796ebfb9d90532918f3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" <bitcoin-dev@lists.linuxfo= undation.org> wrote:
>
> 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 persi= stence of two chains.

If all users abandon the old rules, why would asicboost mine= rs continue to spend energy on a chain that everybody else is ignoring?

> To be more precise, if you change the block validation = ruleset R to block validation ruleset S you have to make sure that every ha= rdware that was capable of mining R-valid blocks is also capable of mining = S-valid blocks.=C2=A0

Why?
No, this proposal, for example, may make patented asicboost hardware obsole= te.
I don't accept this claim as true, this is just your opinion.

>
> The only way out is to go the exact opposite way and to embrace as man= y optimizations as possible to the point where there are no more optimizati= ons left to do, or hopefully getting very close to that point.=C2=A0

What do you mean by "embrace" in the context of a = patented optimization that one miner can prevent the rest from using?

--94eb2c04796ebfb9d90532918f3e--