From: Erik Aronesty <earonesty@gmail•com>
To: Ryan Grant <bitcoin-dev@rgrant•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability
Date: Fri, 19 May 2017 03:16:20 -0400 [thread overview]
Message-ID: <CAJowKg+MZfdfSkZQQutKsFY=rcQSAhLtpRT7dAEH=qyYPNN67A@mail.gmail.com> (raw)
In-Reply-To: <CAJowKg+LAcVCsH7gbuZhKnnv8p5=WXqNCs5oqub3bacRpQ7n9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
ASIC boost is definitely a protocol vulnerability.
It makes Bitcoin resistant to current and future modifications which are
necessary to preserve decentralization.
That alone should be enough to prioritize a swift preventative measure.
On May 18, 2017 3:29 PM, "Ryan Grant via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
On Thu, May 18, 2017 at 9:44 AM, Cameron Garnham via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 3. We should assign a CVE to the vulnerability exploited by
‘ASICBOOST’.
>
> ‘ASICBOOST’ is an attack on this Bitcoin’s security assumptions and
> should be considered an exploit of the Bitcoin Proof-of-Work
> Function.
On Thu, May 18, 2017 at 10:59 AM, Tier Nolan via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Arguably as long as the effort to find a block is proportional to the
block
> difficulty parameter, then it isn't an exploit. It is just an
optimisation.
One principled way to proceed would be to fault not the exploit, but
the protocol design.
Bits in the block header have been discovered which could be used for
dual meanings, and at least one meaning does not preserve the
incentive balances intended and assumed by others. This unexpectedly
creates an incentive to block protocol improvements. The protocol
must be repaired.
In this view, which focuses on covert-ASICBOOST, how work is done is
up to the implementation. But if the hashing work specified possibly
could gain from blocking development work, then we have a
vulnerability.
I believe this is clear grounds for taking action without any delay.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 2797 bytes --]
next prev parent reply other threads:[~2017-05-19 7:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 13:44 Cameron Garnham
2017-05-18 13:57 ` James Hilliard
2017-05-18 14:59 ` Tier Nolan
2017-05-19 7:32 ` Cameron Garnham
2017-05-18 19:28 ` Ryan Grant
[not found] ` <CAJowKgLurok+bTKrt8EAAF0Q7u=cEDwfxOuQJkYNKieFpCPErQ@mail.gmail.com>
[not found] ` <CAJowKg+r3XKaoN3ys3o3FWhpJ3w8An1q0oYMmu_KzDfNdzF8Vg@mail.gmail.com>
[not found] ` <CAJowKgKf22b2jjRbmG+k53g4bOzXrk7AHVcR02xqXPU8ZLJhaQ@mail.gmail.com>
[not found] ` <CAJowKg+LAcVCsH7gbuZhKnnv8p5=WXqNCs5oqub3bacRpQ7n9w@mail.gmail.com>
2017-05-19 7:16 ` Erik Aronesty [this message]
2017-05-24 17:59 ` Cameron Garnham
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='CAJowKg+MZfdfSkZQQutKsFY=rcQSAhLtpRT7dAEH=qyYPNN67A@mail.gmail.com' \
--to=earonesty@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@rgrant$(echo .)org \
--cc=erik@q32$(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