public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Jimmy Song <jaejoon@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
Date: Sat, 8 Apr 2017 19:22:22 +0200	[thread overview]
Message-ID: <CABm2gDoEBzoyjVVhxJXgzW6dBF=+hN-oo+jP1AWYznaGKA4HKA@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDo+XreV1va2rrHrBCf9x-pcGWqjaQcn7ptRJ4jRE=N79g@mail.gmail.com>

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?


  reply	other threads:[~2017-04-08 17:22 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07 20:06 [bitcoin-dev] A Small Modification to Segwit Jimmy Song
2017-04-08  0:05 ` Jimmy Song
2017-04-08 14:59   ` Luke Dashjr
2017-04-08 15:17     ` Jimmy Song
2017-04-08 16:05       ` Luke Dashjr
2017-04-08 16:16         ` Jimmy Song
2017-04-08 16:19   ` Timo Hanke
2017-04-08  1:48 ` praxeology_guy
2017-04-08  2:46   ` Jimmy Song
2017-04-08  8:33     ` Pavel Moravec
2017-04-08 14:35       ` Jimmy Song
2017-04-08 16:38         ` Pavel Moravec
2017-04-08 22:19           ` Jimmy Song
2017-04-08 18:15         ` praxeology_guy
2017-04-08 18:51           ` Eric Voskuil
2017-04-08 20:38             ` praxeology_guy
2017-04-09 11:46           ` Jorge Timón
2017-04-08 16:27     ` Jorge Timón
2017-04-08 17:22       ` Jorge Timón [this message]
2017-04-08 22:26         ` Jimmy Song
2017-04-09 11:48           ` Jorge Timón
2017-04-09 14:01             ` Jimmy Song
     [not found]               ` <CABm2gDqfsBREj2x5Uz9hxwt-Y6m=KHd2-hRw4gV0CbO+-8B0dg@mail.gmail.com>
2017-04-10  9:16                 ` Jorge Timón
2017-04-09 18:44   ` Erik Aronesty
2017-04-09 21:16     ` Jared Lee Richardson
2017-04-09 23:51       ` David Vorick
2017-04-10  0:20         ` Erik Aronesty
2017-04-10  1:45           ` Thomas Daede
2017-04-10 14:34     ` Bram Cohen
2017-04-10 14:46     ` Bram Cohen
2017-04-10 15:25     ` g
2017-04-10 18:17       ` Erik Aronesty
2017-04-11  2:39         ` g
2017-04-11 18:39           ` Staf Verhaegen
2017-04-11  9:31       ` Sancho Panza
2017-04-11 13:00         ` Jorge Timón
2017-04-11  7:59 ` Tom Zander
2017-04-11 13:25   ` Sancho Panza
2017-04-11 14:40     ` Jimmy Song
2017-04-11 21:25       ` Jorge Timón
2017-04-11 23:42         ` Jimmy Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABm2gDoEBzoyjVVhxJXgzW6dBF=+hN-oo+jP1AWYznaGKA4HKA@mail.gmail.com' \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jaejoon@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox