From: Cameron Garnham <da2ce7@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <4BA0FA5D-7B29-4A7F-BC5B-361ED00D5CB2@gmail.com>
Date: Thu, 18 May 2017 16:44:47 +0300
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] =?utf-8?b?VHJlYXRpbmcg4oCYQVNJQ0JPT1NU4oCZIGFzIGEg?=
 =?utf-8?q?Security_Vulnerability?=
Precedence: list

Hello Bitcoin Development Mailing List,

I wish to explain why the current approach to =E2=80=98ASICBOOST=E2=80=99 =
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 =
=E2=80=98ASICBOOST=E2=80=99.

=E2=80=98ASICBOOST=E2=80=99 is an attack on this Bitcoin=E2=80=99s =
security assumptions and should be considered an exploit of the Bitcoin =
Proof-of-Work Function.

For a more detailed look at =E2=80=98ASICBOOST=E2=80=99, 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.=