Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability

[James Hilliard <james.hilliard1@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