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 696BA516 for ; Mon, 10 Apr 2017 09:16:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 886C5F1 for ; Mon, 10 Apr 2017 09:16:52 +0000 (UTC) Received: by mail-ua0-f169.google.com with SMTP id u103so30181553uau.1 for ; Mon, 10 Apr 2017 02:16:52 -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:from:date:message-id:subject:to :cc; bh=mMcfUqahPfgH7rDFLJCclbvTqA6nVyNmqB24/d1tCUo=; b=HXKJY254Qn4CKUj1lx97WgDW6GiHAOjX973+aodcli8qykcD1AG+bOIjvGGnimKX48 y82e5giOZnmLpUucUpYS1zpIsOPPra8eE2P4ZcOQGQ/Dz8LDC2t/21cHtgFNp/hbdYlm rplJcmT3b9HxcblgZWpI3Lw8rZ4XbQQRaNn7m0ziAZ96grCZJnpHUQX+v1w/KvNJakd1 PmBt2K54MFSdPfJ32kIWvBV18bHLL4jvufR34kKD/VasXRmNk/DAUVsPekMVWFb6s9nj 1GfV5AJ8uEwl4rU0W05JcS1NGLsSDUlQLsmtwheJQyMdwT6v5L/jSwrc0usnGuyNQZ4x ehfw== 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=mMcfUqahPfgH7rDFLJCclbvTqA6nVyNmqB24/d1tCUo=; b=HisgPD5AjIN7kKt+W7gGfKG4P9HRWpC3xA8O2FWQ0e9jA49OgsJiwWYv+8uJ+Glb8f pIoXBQRvBw5raY8+iuninRaG2vvQoQGuQvkG2lYCMdd5+pRTTbZ3Bi1wvbn7MS+oA+gS CmtieQ+aduzBEXsReAPt5j8HiukeI1GJKG+m4CfhBjbWx3wq1sJihzF8B1gUjxwM9KgR BuavuF9Z8+5vyj4y45R95WcXuFzNX7lhyPSw9/NjHzyrdPbzVb81GHYG2rV6k/vemCMi i/4M45SMb7uTLZeDofM6GZjHsX45DUrQBzRwnfA7K+kPyS/s2rlsQlKywDCsfJsKlXuE /0HA== X-Gm-Message-State: AN3rC/5TNn+g0nJCCvU63TR0sFjIv+QGOiVGyWBTNtlupnAnntu334xCHFto1wGk93OxPI+XLkAQqGBQFb4blw== X-Received: by 10.159.37.133 with SMTP id 5mr2145846uaf.10.1491815811470; Mon, 10 Apr 2017 02:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.151.136 with HTTP; Mon, 10 Apr 2017 02:16:50 -0700 (PDT) Received: by 10.31.151.136 with HTTP; Mon, 10 Apr 2017 02:16:50 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Mon, 10 Apr 2017 11:16:50 +0200 Message-ID: To: Jimmy Song Content-Type: multipart/alternative; boundary=001a1142966c836edb054ccc6f97 X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 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: Mon, 10 Apr 2017 09:16:53 -0000 --001a1142966c836edb054ccc6f97 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9 Apr 2017 4:01 pm, "Jimmy Song" wrote: 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. Only if all honest miners use asicboost, otherwise the situation for an attack is not equivalent but worse with asicboost. 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. Doesn't greg's proposal of disabling covert asicboost "bring asicboost usage into the open vs hiding it" too? It also does it without making any assumptions on whether we want to completely disable it later (I want) while your proposal assumes we do not. Jimmy > On 9 Apr 2017 12:26 am, "Jimmy Song" 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 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 wro= te: >>> > >>> > >>> > 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 >>> 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? >>> >> >> --001a1142966c836edb054ccc6f97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 9 Apr 2017 4:01 pm, "Jimmy Song" <jaejoon@gmail.com> wrote:
Jorge,

Why won't the attacker use asic= boost too? (Please don't say because of patents)


We're assuming the ASIC optimization in my example is incompatible w= ith ASICBoost. But if the new optimization were compatible with ASICBoost, = you're right, the network would be in an equivalent situation whether A= SICBoost was banned or not.

Only if all honest min= ers use asicboost, otherwise the situation for an attack is not equivalent = but worse with asicboost.

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 complet= ely.

Doesn't greg's proposal of disabling = covert asicboost "bring asicboost usage into the open vs hiding it&quo= t; too? It also does it without making any assumptions on whether we want t= o completely disable it later (I want) while your proposal assumes we do no= t.

=
Jimmy
=C2=A0
On 9 Apr 2017 12:26 am, "Jimmy Song" <jaejoon@gmail.com> wrote:=
Jo= rge,

Suppose someone figures out an ASIC optimization th= at's completely unrelated that gives X% speed boost over your non-ASICB= oosted implementation. If you ban ASICBoost, someone with this optimization= can get 51% of the network by adding N machines with their new optimizatio= n. If you allow ASICBoost and assuming this gets a 20% speed boost over non= -ASICBoosted hardware, someone with this optimization would need 1.2N machi= nes to get 51%. The network in that sense is 20% stronger against this atta= ck in terms of cost.

Jimmy

On Sat, Apr 8, 2017 at 12:2= 2 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
To be more specific, why "being higher will secu= re 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-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 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?



--001a1142966c836edb054ccc6f97--