public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: James Hilliard <james.hilliard1@gmail.com>
To: Cameron Garnham <da2ce7@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability
Date: Thu, 18 May 2017 08:57:08 -0500	[thread overview]
Message-ID: <CADvTj4rdQVCYu=m9ymi4OP-Q0NaVmfaJS8eSBhuER=uKBzXpqA@mail.gmail.com> (raw)
In-Reply-To: <4BA0FA5D-7B29-4A7F-BC5B-361ED00D5CB2@gmail.com>

Locking the lower bits on the timestamp will likely break existing
hardware that relies on being able to roll ntime.

On Thu, May 18, 2017 at 8:44 AM, Cameron Garnham via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello Bitcoin Development Mailing List,
>
> I wish to explain why the current approach to ‘ASICBOOST’ dose not comply with our established best practices for security vulnerabilities and suggest what I consider to be an approach closer matching established industry best practices.
>
>
> 1.     Significant deviations from the Bitcoin Security Model have been acknowledged as security vulnerabilities.
>
> The Bitcoin Security Model assumes that every input into the Proof-of-Work function should have the same difficulty of producing a desired output.
>
>
> 2.     General ASIC optimisation cannot be considered a Security Vulnerabilities.
>
> Quickly being able to check inputs is not a vulnerability. However, being able to craft inputs that are significantly easier to check than alternative inputs is a vulnerability.
>
>
> 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.
>
> For a more detailed look at ‘ASICBOOST’, please have a look at this excellent document by Jeremy Rubin:
> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>
> The Bitcoin Community should be able to track the progress of restoring the quality of the Bitcoin Proof-of-Work function to its original assumptions.
>
>
> 4.     Work should be taken to prudently and swiftly restore Bitcoins Security Properties.
>
> I recommend the Bitcoin Community fix this vulnerability with expediency.
>
>
>
> Cameron.
>
> PS:
>
> With a soft-fork it probably is possible to completely fix this Proof-of-Work vulnerability.
>
> (Here is my working list of things to do):
>
> 1.     Include extra data in the Coinbase Transaction, such as the Witness Root.
>
> 2.     Lock the Version. (Use a space in the Coinbase Transaction for signalling future upgrades).
>
> 3.     Lock the lower-bits on the Timestamp: Block timestamps only need ~1minute granularity.
>
> 4.      Make a deterministic ordering of transaction chains within a block. (However, I believe this option is more difficult).
>
> Of course, if we have a hard-fork, we should consider the Proof-of-Work internal merkle structure directly.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  reply	other threads:[~2017-05-18 13:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 13:44 [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability Cameron Garnham
2017-05-18 13:57 ` James Hilliard [this message]
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
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='CADvTj4rdQVCYu=m9ymi4OP-Q0NaVmfaJS8eSBhuER=uKBzXpqA@mail.gmail.com' \
    --to=james.hilliard1@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=da2ce7@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