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

[Ryan Grant via bitcoin-dev]

On Thu, May 18, 2017 at 9:44 AM, Cameron Garnham via bitcoin-dev
 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
 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

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

[Tier Nolan via bitcoin-dev]

On Thu, May 18, 2017 at 2:44 PM, Cameron Garnham via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>

This isn't really that clear.

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.

A quantum computer, for example, could find a block with effort
proportional to the square root of the difficulty parameter, so that would
count as an attack.  Though in that case, the fix would likely be to tweak
the difficulty parameter update calculation.

A better definition would be something like "when performing work, each
hash should be independent".

ASICBOOST does multiple checks in parallel, so would violate that.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[James Hilliard via bitcoin-dev]

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
 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Cameron Garnham via bitcoin-dev]

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