MIME-Version: 1.0
In-Reply-To: <4BA0FA5D-7B29-4A7F-BC5B-361ED00D5CB2@gmail.com>
References: <4BA0FA5D-7B29-4A7F-BC5B-361ED00D5CB2@gmail.com>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Thu, 18 May 2017 08:57:08 -0500
Message-ID: <CADvTj4rdQVCYu=m9ymi4OP-Q0NaVmfaJS8eSBhuER=uKBzXpqA@mail.gmail.com>
To: Cameron Garnham <da2ce7@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev]
	=?utf-8?b?VHJlYXRpbmcg4oCYQVNJQ0JPT1NU4oCZIGFzIGEg?=
	=?utf-8?q?Security_Vulnerability?=
Precedence: list

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 =E2=80=98ASICBOOST=E2=80=99=
 dose not comply with our established best practices for security vulnerabi=
lities and suggest what I consider to be an approach closer matching establ=
ished industry best practices.
>
>
> 1.     Significant deviations from the Bitcoin Security Model have been a=
cknowledged as security vulnerabilities.
>
> The Bitcoin Security Model assumes that every input into the Proof-of-Wor=
k function should have the same difficulty of producing a desired output.
>
>
> 2.     General ASIC optimisation cannot be considered a Security Vulnerab=
ilities.
>
> Quickly being able to check inputs is not a vulnerability. However, being=
 able to craft inputs that are significantly easier to check than alternati=
ve inputs is a vulnerability.
>
>
> 3.     We should assign a CVE to the vulnerability exploited by =E2=80=98=
ASICBOOST=E2=80=99.
>
> =E2=80=98ASICBOOST=E2=80=99 is an attack on this Bitcoin=E2=80=99s securi=
ty 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 lo=
ok 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 t=
he quality of the Bitcoin Proof-of-Work function to its original assumption=
s.
>
>
> 4.     Work should be taken to prudently and swiftly restore Bitcoins Sec=
urity 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 Witnes=
s Root.
>
> 2.     Lock the Version. (Use a space in the Coinbase Transaction for sig=
nalling 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 bloc=
k. (However, I believe this option is more difficult).
>
> Of course, if we have a hard-fork, we should consider the Proof-of-Work i=
nternal merkle structure directly.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev