public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jared Lee Richardson <jaredr26@gmail•com>
To: David Vorick <david.vorick@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function
Date: Thu, 6 Apr 2017 10:26:52 -0700	[thread overview]
Message-ID: <CAD1TkXvqjKy7YaAhbuS7kaHKa77YhtFmRsrZOt71CJqFbrqWAg@mail.gmail.com> (raw)
In-Reply-To: <CAFVRnyrqiNY_JOqhv2ysm2WsBMYsU3tTAASAtHzMbA68_9Yx8g@mail.gmail.com>

> We are not going to invalidate covert asicboost without a fight. And we are working with a system that actively (and is demonstrably very effective at doing it) resists changes which are contentious. This is definitely a contentious change, because an important part of the community (the miners) is going to be actively resisting it.

I'd just like to point out, invalidating asicboost has only a very
limited number of potential detractors.  Only a mining farm that
self-mined and used custom software would be able to exploit this.
Every other mining farm on the planet, plus any users wishing for more
transactions to be included in blocks would be in favor of this,
assuming the theory that it favors fewer transactions is correct.
That makes it less contentious than many other alternatives.  It might
even force the mining operation(s) in question to flip and support SW
in order to avoid losing face and/or appearing guilty.

As an additional plus, nearly all of the BU crowd and most BU
supporting miners would have little reason to object to Asicboost -
Based on philosophy alone, but not based on any practical
considerations.

Jared

On Wed, Apr 5, 2017 at 8:23 PM, David Vorick via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I have a practical concern related to the amount of activation energy
> required to get something like this through. We are talking about
> implementing something that would remove tens to hundreds of millions of
> dollars of mining revenue for miners who have already gambled that this
> income would be available to them.
>
> That's not something they are going to let go of without a fight, and we've
> already seen this with the segwit resistance. Further, my understanding is
> that this makes a UASF a lot more difficult. Mining hardware that has unique
> optimizations on one chain only can resist a UASF beyond a simple economic
> majority, because they can do more hashes on the same amount of revenue.
> Threshold for success is no longer 51%, especially if you are expecting the
> miners to struggle (and this is a case where they have a very good reason to
> struggle). Any resistance from the hashrate during the early days of a UASF
> will inevitably cause large reorgs for older nodes, and is not much better
> than a hardfork.
>
> I don't know what the right answer is. But I know that we are not going to
> get segwit without a fight. We are not going to invalidate covert asicboost
> without a fight. And we are working with a system that actively (and is
> demonstrably very effective at doing it) resists changes which are
> contentious. This is definitely a contentious change, because an important
> part of the community (the miners) is going to be actively resisting it.
>
> I urge everybody to realize how difficult something like this is going to be
> to pull off. We are literally talking about invalidating hardware (or at
> least the optimized bits). It's only going to succeed if everybody is
> conclusively on board. As you consider proposals, realize that anything
> which is not the simplest and least contentious is already dead.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


  parent reply	other threads:[~2017-04-06 17:26 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05 21:37 Gregory Maxwell
2017-04-05 23:05 ` theymos
2017-04-06  0:17   ` Gregory Maxwell
2017-04-06  0:39     ` Joseph Poon
2017-04-06  0:40       ` Joseph Poon
2017-04-06  1:32       ` Gregory Maxwell
2017-04-06  2:09         ` Joseph Poon
2017-04-05 23:25 ` Anthony Towns
2017-04-05 23:42 ` Joseph Poon
2017-04-06  2:10 ` Jonathan Toomim
2017-04-06 20:21   ` Jared Lee Richardson
2017-04-06  2:31 ` Peter Todd
2017-04-06  2:39   ` Bram Cohen
2017-04-06  2:49     ` Peter Todd
2017-04-06  3:11       ` Erik Aronesty
2017-04-06  3:23         ` Peter Todd
2017-04-06  3:23       ` David Vorick
2017-04-06  3:42         ` Peter Todd
2017-04-06  5:46         ` Thomas Daede
2017-04-06  6:24         ` Jonathan Toomim
2017-04-06 12:04           ` David Vorick
     [not found]           ` <CAMZUoK=oDAD9nhFAHkgncWtYxjBNh3qXbUffOH57QMnqjhmN6g@mail.gmail.com>
     [not found]             ` <CAMZUoKn8tr3LGbks0TnaCx9NTP6MZUzQ8PE6jDq1xiqpYyYwow@mail.gmail.com>
2017-04-06 13:55               ` Russell O'Connor
2017-04-06 16:49           ` Marco
2017-04-06 17:04           ` Alex Mizrahi
2017-04-06 17:13           ` Alex Mizrahi
2017-04-07 12:59             ` Jannes Faber
2017-04-07 13:28               ` Erik Aronesty
2017-04-06 17:31           ` Jared Lee Richardson
2017-04-06 17:26         ` Jared Lee Richardson [this message]
2017-04-06 15:36       ` Alex Mizrahi
2017-04-06 17:51     ` Jorge Timón
2017-04-06  7:24 ` bfd
2017-04-06  9:17 ` Luke Dashjr
2017-04-06 12:02 ` Luv Khemani
2017-04-06 12:11   ` Bryan Bishop
2017-04-06 17:43     ` Timo Hanke
2017-04-06 12:30   ` Luv Khemani
2017-04-06 15:15     ` Jorge Timón
2017-04-06 15:41       ` Daniel Robinson
2017-04-06 16:13 ` Andreas Schildbach
2017-04-06 21:38 ` Gregory Maxwell
2017-04-06  4:47 Oliver Petruzel
2017-04-06  4:49 Raystonn .
2017-04-06  7:47 ` praxeology_guy
2017-04-06 12:13   ` David Vorick
2017-04-07  1:34 Daniele Pinna
2017-04-07  6:46 ` Emilian Ursu
2017-04-07  7:44 ` Alex Mizrahi
2017-04-07  8:08 ` praxeology_guy

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=CAD1TkXvqjKy7YaAhbuS7kaHKa77YhtFmRsrZOt71CJqFbrqWAg@mail.gmail.com \
    --to=jaredr26@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=david.vorick@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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