path: root/9f/b7549b75236ceb6b9b34fdd24c655cb50a954b

Return-Path: <jaejoon@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0BF59AB9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Apr 2017 22:26:28 +0000 (UTC)
Received: by mail-wr0-f196.google.com with SMTP id u18so16474640wrc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CABm2gDoEBzoyjVVhxJXgzW6dBF=+hN-oo+jP1AWYznaGKA4HKA@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
	<Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
	<CAJR7vkoq8Y_-fbdxN=--gF5wrGByr5oODc4FkTaCEvDSuP0whQ@mail.gmail.com>
	<CABm2gDo+XreV1va2rrHrBCf9x-pcGWqjaQcn7ptRJ4jRE=N79g@mail.gmail.com>
	<CABm2gDoEBzoyjVVhxJXgzW6dBF=+hN-oo+jP1AWYznaGKA4HKA@mail.gmail.com>
From: Jimmy Song <jaejoon@gmail.com>
Date: Sat, 8 Apr 2017 17:26:25 -0500
Message-ID: <CAJR7vkqnRNLv6xpg04Uh2ybu5DQnBSqc5rdBBJ77Dy=EsEAK2Q@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <jtimon@jtimon.cc> 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 <jtimon@jtimon.cc> wrote=
:
> >
> >
> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
> > <bitcoin-dev@lists.linuxfoundation.org> 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

<div dir=3D"ltr">Jorge,<div><br></div><div>Suppose someone figures out an A=
SIC optimization that&#39;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.</div><div><br></div><div>Jimmy</div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Ap=
r 8, 2017 at 12:22 PM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">To be more specific, why &quot;being=
 higher will secure the Bitcoin network<br>
better against newer optimizations&quot;?<br>
Or, to be more clear, let&#39;s forget about future &quot;optimizations&quo=
t;, let&#39;s<br>
just think of an attacker. Does asicboost being used by all miners<br>
make the system more secure against an attacker? No, for the attacker<br>
can use asicboost too.<br>
What about the case when not all the miners are using asicboost? Then<br>
the attacker can actually get an advantage by suing asicboost.<br>
<br>
Sometimes people compare asicboost with the use of asics in general as<br>
both providing more security for the network and users. But I don&#39;t<br>
think this is accurate. The existence of sha256d asics makes an attack<br>
with general purpose computing hardware (or even more specialized<br>
architectures like gpgpu) much more expensive and unlikely. As an<br>
alternative the attacker can spend additional resources investing in<br>
asics himself (again, making many attacks more expensive and<br>
unlikely).<br>
<br>
But as far as I know, asicboost can be implemented with software<br>
running on general purpose hardware that integrates with regular<br>
sha256d asics. There is probably an advantage on having the asicboost<br>
implementation &quot;in the same box&quot; as the sha256d, yet again the<br=
>
attacker can invest in hardware with the competitive advantage from<br>
having asicboost more intergrated with the sha256d asics too.<br>
<br>
To reiterate, whether all miners use asicboost or only a subset of<br>
them, I remain unconvinced that provides any additional security to<br>
the network (to be more precise whether that makes &quot;tx history harder<=
br>
to rewrite&quot;), even if it results on the hashrate charts looking &quot;=
more<br>
secure&quot;.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On Sat, Apr 8, 2017 at 6:27 PM, Jorge Tim=C3=B3n &lt;jtimon@jtimon.cc&gt; w=
rote:<br>
&gt;<br>
&gt;<br>
&gt; On 8 Apr 2017 5:06 am, &quot;Jimmy Song via bitcoin-dev&quot;<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Praxeology Guy,<br>
&gt;<br>
&gt;&gt; Why would the actual end users of Bitcoin (the long term and short=
 term<br>
&gt;&gt; owners of bitcoins) who run fully verifying nodes want to change B=
itcoin<br>
&gt;&gt; policy in order to make their money more vulnerable to 51% attack?=
<br>
&gt;<br>
&gt;<br>
&gt; Certainly, if only one company made use of the extra nonce space, they=
 would<br>
&gt; have an advantage. But think of it this way, if some newer ASIC optimi=
zation<br>
&gt; comes up, would you rather have a non-ASICBoosted hash rate to defend =
with<br>
&gt; or an ASICBoosted hash rate? Certainly, the latter, being higher will =
secure<br>
&gt; the Bitcoin network better against newer optimizations.<br>
&gt;<br>
&gt;<br>
&gt; Why?<br>
</div></div></blockquote></div><br></div>

--94eb2c1b45dc9e7304054caf3bd1--