Thank-you for your insightful reply,

Am I correct that this suggest is that you think it is an optimisation to find some nonces having lower difficulty than other nonces?

I would agree with you if this was limited to a dedicated nonce area of the Bitcoin System.

However, in the case of Bitcoin it is a layer violation that the PoW function difficulty could be affected by the choice the transaction ordering, or the content of the Coinbase Transaction, etc. Possibly giving unnatural and unintended incentives to other parts of the Bitcoin System.

I can see two issues at play here:

1. The choice of input, outside of the dedicated nonce area, fed the PoW function should not change it’s difficulty to evaluate.
2. Every PoW function execution should be independent.

I think that both of these are security assumptions of the Bitcoin PoW function.

I consider ASICBOOST as an attack upon both accounts.

Cameron.

On 18 May 2017, at 17:59 , Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

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.