public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream•io>
To: Jonathan Toomim <j@toom•im>,
	 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 09:55:31 -0400	[thread overview]
Message-ID: <CAMZUoKkXMffG1RFT3398zcBN3EmwgPLXm2egeUTqO7ELn7BnsA@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKn8tr3LGbks0TnaCx9NTP6MZUzQ8PE6jDq1xiqpYyYwow@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

Hi Jonathan,

The proposal raised here does not deny miners the ability to use ASICBOOST.
Miners can still use overt ASICBOOST by version bit fiddling and get the
same power savings.  In fact, overt ASICBOOST is much easier to implement
than covert ASICBOOST, so I don't really understand what the objection is.


On Apr 6, 2017 13:44, "Jonathan Toomim via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:

Ethically, this situation has some similarities to the DAO fork. We have an
entity who closely examined the code, found an unintended characteristic of
that code, and made use of that characteristic in order to gain tens of
millions of dollars. Now that developers are aware of it, they want to
modify the code in order to negate as much of the gains as possible.

There are differences, too, of course: the DAO attacker was explicitly
malicious and stole Ether from others, whereas Bitmain is just optimizing
their hardware better than anyone else and better than some of us think
they should be allowed to.

In both cases, developers are proposing that the developers and a majority
of users collude to reduce the wealth of a single entity by altering the
blockchain rules.

In the case of the DAO fork, users were stealing back stolen funds, but
that justification doesn't apply in this case. On the other hand, in this
case we're talking about causing someone a loss by reducing the value of
hardware investments rather than forcibly taking back their coins, which is
less direct and maybe more justifiable.

While I don't like patented mining algorithms, I also don't like the idea
of playing Calvin Ball on the blockchain. Rule changes should not be
employed as a means of disempowering and empoverishing particular entities
without very good reason. Whether patenting a mining optimization qualifies
as good reason is questionable.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 2671 bytes --]

  parent reply	other threads:[~2017-04-06 13:55 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 [this message]
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
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=CAMZUoKkXMffG1RFT3398zcBN3EmwgPLXm2egeUTqO7ELn7BnsA@mail.gmail.com \
    --to=roconnor@blockstream$(echo .)io \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=j@toom$(echo .)im \
    /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