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ón <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ón <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 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, 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?
>