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 0BF59AB9 for ; Sat, 8 Apr 2017 22:26:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f196.google.com (mail-wr0-f196.google.com [209.85.128.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26C1790 for ; Sat, 8 Apr 2017 22:26:28 +0000 (UTC) Received: by mail-wr0-f196.google.com with SMTP id u18so16474640wrc.1 for ; Sat, 08 Apr 2017 15:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5k0dBcFH6VLheu7k30c0jxc8+Z0A0+aOwQC8ARuRBhU=; b=vLNwg5wCHdh8hsQAGzxAKb2ou2vDQC2MMyi93W3ndLnJydaEsB8CJyR2fWUionL7GF Vzb6tjAyhLQYrpoOd2sbcNvgTcy2HEn1PjNS2tvPlG3gZXejrqu7flXmxUzHPxuZBXz/ 853Xli4SRamrIm7Y3sQiCgGhTSyCLPdbAAbR8JMYWI7SMIDPsUwsLfUhSueSaUpKsoDk YHMjpGz0Na/vT+pNI3uz1nt5UTfv4l/uoGNYpmnR0m40nADXamGpTmdrIzwmlap2Cyk/ b3VKbehy1Rl4Bz2iVp417xB5+APHHFGDMV7Z6BQ57R91Uw6mFMAy0GzdPgTjb8BOlqhq zm4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5k0dBcFH6VLheu7k30c0jxc8+Z0A0+aOwQC8ARuRBhU=; b=tlZl+2feDlelIzJseyLLiCQ1Ew9BWMtfDIWc+8FDtx1fzk5JcC/ID/ehhPeRrBQQYy ioeWlM4jpHlHYaWVC2csjoSpMaii1IdpOfRMfvR+uAbzSHXJHAfOXih3PsxQL+YV+j0b yUP/siGvW2Mwfbpv+8cYrVRM6wRAcHm/Zp+4i6RStrRzWdBlr8qG9phO8gQz9PVEOhns WBdw9dPJBtq0rplLVwj2vV+odBpW2Ukt2R71qeYMbOeFl6FwB6J3UVMdLD9A57Lub9af BXaFtYiB1WrJA0rVJv/gJHXan3EVIbX1jNTUiG+nRpuz2AcR0DpybHdytoDsa0H0606b /XxA== X-Gm-Message-State: AFeK/H1LH0IDmcm0wMFPZhHn3w+3ZE5fmE9Iom06Ra8tiDmwyNPkh86MukGK09nm8S/ybF/C4qx03Kn89E7gNg== X-Received: by 10.223.151.217 with SMTP id t25mr41720457wrb.105.1491690386779; Sat, 08 Apr 2017 15:26:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.134.243 with HTTP; Sat, 8 Apr 2017 15:26:25 -0700 (PDT) In-Reply-To: References: From: Jimmy Song Date: Sat, 8 Apr 2017 17:26:25 -0500 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=94eb2c1b45dc9e7304054caf3bd1 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 08 Apr 2017 22:30:23 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] A Small Modification to Segwit 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: Sat, 08 Apr 2017 22:26:29 -0000 --94eb2c1b45dc9e7304054caf3bd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jorge, Suppose someone figures out an ASIC optimization that's completely unrelated that gives X% speed boost over your non-ASICBoosted implementation. If you ban ASICBoost, someone with this optimization can get 51% of the network by adding N machines with their new optimization. If you allow ASICBoost and assuming this gets a 20% speed boost over non-ASICBoosted hardware, someone with this optimization would need 1.2N machines to get 51%. The network in that sense is 20% stronger against this attack in terms of cost. Jimmy On Sat, Apr 8, 2017 at 12:22 PM, Jorge Tim=C3=B3n wrote: > To be more specific, why "being higher will secure the Bitcoin network > better against newer optimizations"? > Or, to be more clear, let's forget about future "optimizations", let's > just think of an attacker. Does asicboost being used by all miners > make the system more secure against an attacker? No, for the attacker > can use asicboost too. > What about the case when not all the miners are using asicboost? Then > the attacker can actually get an advantage by suing asicboost. > > Sometimes people compare asicboost with the use of asics in general as > both providing more security for the network and users. But I don't > think this is accurate. The existence of sha256d asics makes an attack > with general purpose computing hardware (or even more specialized > architectures like gpgpu) much more expensive and unlikely. As an > alternative the attacker can spend additional resources investing in > asics himself (again, making many attacks more expensive and > unlikely). > > But as far as I know, asicboost can be implemented with software > running on general purpose hardware that integrates with regular > sha256d asics. There is probably an advantage on having the asicboost > implementation "in the same box" as the sha256d, yet again the > attacker can invest in hardware with the competitive advantage from > having asicboost more intergrated with the sha256d asics too. > > To reiterate, whether all miners use asicboost or only a subset of > them, I remain unconvinced that provides any additional security to > the network (to be more precise whether that makes "tx history harder > to rewrite"), even if it results on the hashrate charts looking "more > secure". > > > On Sat, Apr 8, 2017 at 6:27 PM, Jorge Tim=C3=B3n wrote= : > > > > > > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev" > > wrote: > > > > Praxeology Guy, > > > >> Why would the actual end users of Bitcoin (the long term and short ter= m > >> owners of bitcoins) who run fully verifying nodes want to change Bitco= in > >> policy in order to make their money more vulnerable to 51% attack? > > > > > > Certainly, if only one company made use of the extra nonce space, they > would > > have an advantage. But think of it this way, if some newer ASIC > optimization > > comes up, would you rather have a non-ASICBoosted hash rate to defend > with > > or an ASICBoosted hash rate? Certainly, the latter, being higher will > secure > > the Bitcoin network better against newer optimizations. > > > > > > Why? > --94eb2c1b45dc9e7304054caf3bd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jorge,

Suppose someone figures out an A= SIC optimization that's completely unrelated that gives X% speed boost = over your non-ASICBoosted implementation. If you ban ASICBoost, someone wit= h this optimization can get 51% of the network by adding N machines with th= eir new optimization. If you allow ASICBoost and assuming this gets a 20% s= peed boost over non-ASICBoosted hardware, someone with this optimization wo= uld need 1.2N machines to get 51%. The network in that sense is 20% stronge= r against this attack in terms of cost.

Jimmy

On Sat, Ap= r 8, 2017 at 12:22 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wr= ote:
To be more specific, why "being= higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations&quo= t;, let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.

Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).

But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.

To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder<= br> to rewrite"), even if it results on the hashrate charts looking "= more
secure".


On Sat, Apr 8, 2017 at 6:27 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> w= rote:
>
>
> On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
> <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
>
> Praxeology Guy,
>
>> Why would the actual end users of Bitcoin (the long term and short= term
>> owners of bitcoins) who run fully verifying nodes want to change B= itcoin
>> policy in order to make their money more vulnerable to 51% attack?=
>
>
> Certainly, if only one company made use of the extra nonce space, they= would
> have an advantage. But think of it this way, if some newer ASIC optimi= zation
> comes up, would you rather have a non-ASICBoosted hash rate to defend = with
> or an ASICBoosted hash rate? Certainly, the latter, being higher will = secure
> the Bitcoin network better against newer optimizations.
>
>
> Why?

--94eb2c1b45dc9e7304054caf3bd1--