path: root/9b/84265b13e95281ed9e09a64ff30fc248bd3c79

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 3885040F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  9 Apr 2017 14:01:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2203B14F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  9 Apr 2017 14:01:03 +0000 (UTC)
Received: by mail-wm0-f45.google.com with SMTP id u2so20421146wmu.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 09 Apr 2017 07:01:02 -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=Yt+uqItP2KNuSq8r29zrq48w+o42EMKIfP1jZp0TkXQ=;
	b=ewmriYuZykjnWWUn07CCba8tIZIZUkjdLgteMZCW4wIuZPzxVyhTTQEv8HqDVKulz5
	1Cm/7Tl+L/h8tAGh28hIZ83o5JeGaCG9ExcJ2p2ufv2EP89nOzjCksvNPLa7Mxd5Apax
	/X+HeFhX/AkfD6j35Gt1AXZ7vH+T1fj+XxdqnkxGpPANMRS22cxcIJaLZy2MHHruMva1
	OR4oqZZJiDx0yQnJnWU6LKoRZS9c5UbxOuGkU5NISyGxIMHwC0RzExIHt23HvwOoLM8j
	PJOEmKCm5nFvES4zOPOLLLeJlmXdHmr4enFAGGuWBEDf/E1vDg/QltUxpSfHe77X57s9
	fw6Q==
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=Yt+uqItP2KNuSq8r29zrq48w+o42EMKIfP1jZp0TkXQ=;
	b=lFcI1he5n5wYPfzC+TrSaNvOBpTxGsLLpRmTu4CbJYgekQ1nf0KkGtBMt4p6bwBHoG
	TRm0ew2xTPDUnBvcrx3dvAFmitNhXnAu3nQc56fW0SwYz3u1NrhFVgzvQuZgcbZwJr19
	obQqNnjp/H7xC4fwNDdr2x9LWGHpQvTW+wPHNFhFxgn2s+ckorZGbDv7O/WX6UTsSJHV
	mPDd6mr9+oJCeiLOxWDAUSZSva6xRj9vg5ZgMPzDhfj76Z8XqtQPdzocnjxKH0A2qcCN
	QOZ1s2rmE1zMEQiPsaSrjAyIsWuT0x4Bo0xl3bWk+CtEwlxF7v1JW9oCgSa9y09KQ5Vf
	3eHg==
X-Gm-Message-State: AN3rC/7KVUjf1OGe8nom8BZMHIL4Q6+V0MrNMwBttYSKByIILruryewKcX574Cx9YDapKcMklXKirSdndOnYZw==
X-Received: by 10.28.111.3 with SMTP id k3mr6326767wmc.39.1491746461764; Sun,
	09 Apr 2017 07:01:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.134.243 with HTTP; Sun, 9 Apr 2017 07:01:01 -0700 (PDT)
In-Reply-To: <CABm2gDpaPeYXnPq0k6QMdz4t3PYXaSTqay2PJz-7gVcD3ixiRw@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>
	<CAJR7vkqnRNLv6xpg04Uh2ybu5DQnBSqc5rdBBJ77Dy=EsEAK2Q@mail.gmail.com>
	<CABm2gDpaPeYXnPq0k6QMdz4t3PYXaSTqay2PJz-7gVcD3ixiRw@mail.gmail.com>
From: Jimmy Song <jaejoon@gmail.com>
Date: Sun, 9 Apr 2017 09:01:01 -0500
Message-ID: <CAJR7vkpMxfDwjQdimicRuR+SAdpF9dn-T7j+dact=u9wcGO7+w@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a1147cae4f2d3f1054cbc49ec
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, URIBL_BLACK 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: Sun, 09 Apr 2017 14:25:13 +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: Sun, 09 Apr 2017 14:01:04 -0000

--001a1147cae4f2d3f1054cbc49ec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Jorge,

Why won't the attacker use asicboost too? (Please don't say because of
> patents)
>
>
We're assuming the ASIC optimization in my example is incompatible with
ASICBoost. But if the new optimization were compatible with ASICBoost,
you're right, the network would be in an equivalent situation whether
ASICBoost was banned or not.

I want to point out again that overt ASICBoost can be used on the network
today. My proposal is to bring ASICBoost usage out into the open vs hiding
it. Banning ASICBoost via protocol changes is another issue completely.

Jimmy


> On 9 Apr 2017 12:26 am, "Jimmy Song" <jaejoon@gmail.com> wrote:
>
>> 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 t=
his
>> attack in terms of cost.
>>
>> Jimmy
>>
>> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro=
te:
>>
>>> 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> wro=
te:
>>> >
>>> >
>>> > 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
>>> term
>>> >> owners of bitcoins) who run fully verifying nodes want to change
>>> Bitcoin
>>> >> policy in order to make their money more vulnerable to 51% attack?
>>> >
>>> >
>>> > Certainly, if only one company made use of the extra nonce space, the=
y
>>> 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?
>>>
>>
>>

--001a1147cae4f2d3f1054cbc49ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Jorge,<br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Why won&#39;t th=
e attacker use asicboost too? (Please don&#39;t say because of patents)</di=
v><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br></=
div></div></div></blockquote><div><br></div><div>We&#39;re assuming the ASI=
C optimization in my example is incompatible with ASICBoost. But if the new=
 optimization were compatible with ASICBoost, you&#39;re right, the network=
 would be in an equivalent situation whether ASICBoost was banned or not.</=
div><div><br></div><div>I want to point out again that overt ASICBoost can =
be used on the network today. My proposal is to bring ASICBoost usage out i=
nto the open vs hiding it. Banning ASICBoost via protocol changes is anothe=
r issue completely.</div><div><br></div><div>Jimmy</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote">On 9 Apr 2017 12:26 am, &qu=
ot;Jimmy Song&quot; &lt;<a href=3D"mailto:jaejoon@gmail.com" target=3D"_bla=
nk">jaejoon@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">Jorge,<div><br></div><div>Suppose someone=
 figures out an ASIC optimization that&#39;s completely unrelated that give=
s X% speed boost over your non-ASICBoosted implementation. If you ban ASICB=
oost, 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 thi=
s optimization would need 1.2N machines to get 51%. The network in that sen=
se is 20% stronger against this attack in terms of cost.</div><div><br></di=
v><div>Jimmy</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Sat, Apr 8, 2017 at 12:22 PM, Jorge Tim=C3=B3n <span dir=3D"ltr">=
&lt;<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc<=
/a>&gt;</span> wrote:<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"m_-1831515277159669576m_-6497736858983536379HOEnZb"><div clas=
s=3D"m_-1831515277159669576m_-6497736858983536379h5"><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" target=3D=
"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.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>
</blockquote></div></div>
</div></div></blockquote></div><br></div></div>

--001a1147cae4f2d3f1054cbc49ec--