Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E424EB2F for ; Fri, 19 May 2017 07:32:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35BC0151 for ; Fri, 19 May 2017 07:32:45 +0000 (UTC) Received: by mail-wr0-f170.google.com with SMTP id z52so11019211wrc.2 for ; Fri, 19 May 2017 00:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gwFSPkL/IEvTHVJwh5XGf2/ElLEu4N5QoUDy+7SDGXU=; b=p9WiUo5VykOI7fRB4zcDF9BxWHlsP4ejylBna9NPMvYHV+GgYJatTPRRoZOwAPaGbz 28zDvC2lSycSlhHlqJV9FKoDooKvAn5/yQc+oF1kcMoLARVDSWPsFa4JYTBq6sOWSvZz iRwX3JwfTZlCgvFc8ejYFkFXpLUxku9b6PMYbmWT4q+HDDTIOAkAl/25gX8KBvEsYTLE d/VO61pPFxRiAm1vq/2vrrMJQyeXBeWbgz87LDGWMeuR3frikmESuBehQgOrpFPIGfBz E0sjMYKm7efvp9jVwFYUhZuKIsUtdj9CxiPKE2ci5w4GSgw8AfIz2F+zR9fBkGSux7Di y+UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gwFSPkL/IEvTHVJwh5XGf2/ElLEu4N5QoUDy+7SDGXU=; b=Bvi8f3jl+VewBYGVebZAsq5FYymhPC0vdrANUNnabaXBY2xeOLpmISiPqbj9M4O9sC UvB+n5JK4wUO+YFs64cjG3/eSdqjJ46rsLfVDQNGKInNAWnbJfXqh7HIFRmmhNrCz9Zn 5kfXn1Muv+1SuvuzNPAtrza2CgUGCuBTHsimcnqb7YpqY9V4ejzxiQnxOGQnwMdl9T/1 PkmsodVsek5ZPL7lfPh/w7MRQNGUXnCU/SzZ6lMN6ApPBnM6S2rTfxnYmkA8hJC33ObS 2hksqc2r6qh1XLaoJqn/+mrwR3Jit811YZS3yaaUa8S4YHZXivS8hHLrJWUTTa/tvMTb WPlw== X-Gm-Message-State: AODbwcCAffaYCvCyIAYqZn1cjYu6sF2ACsb2T1+//fWYH6j0+hfGPPEa 3SLHDqPXK1Hd6Q== X-Received: by 10.46.82.144 with SMTP id n16mr1948047lje.0.1495179163765; Fri, 19 May 2017 00:32:43 -0700 (PDT) Received: from [172.20.10.2] ([213.87.145.226]) by smtp.gmail.com with ESMTPSA id l135sm792179lfb.43.2017.05.19.00.32.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 May 2017 00:32:42 -0700 (PDT) From: Cameron Garnham Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AF54D3AA-121C-4FFE-A42F-37EA69BF0C7D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 19 May 2017 10:32:36 +0300 In-Reply-To: To: Tier Nolan References: <4BA0FA5D-7B29-4A7F-BC5B-361ED00D5CB2@gmail.com> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] =?utf-8?b?VHJlYXRpbmcg4oCYQVNJQ0JPT1NU4oCZIGFzIGEg?= =?utf-8?q?Security_Vulnerability?= X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 07:32:46 -0000 --Apple-Mail=_AF54D3AA-121C-4FFE-A42F-37EA69BF0C7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (message was originally sent off-list by mistake). Hello Tier, 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=E2=80=99s 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. >=20 > On 18 May 2017, at 17:59 , Tier Nolan via bitcoin-dev = wrote: >=20 > On Thu, May 18, 2017 at 2:44 PM, Cameron Garnham via bitcoin-dev = wrote: > 1. Significant deviations from the Bitcoin Security Model have = been acknowledged as security vulnerabilities. >=20 > The Bitcoin Security Model assumes that every input into the = Proof-of-Work function should have the same difficulty of producing a = desired output. >=20 > This isn't really that clear. >=20 > 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. >=20 > 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. >=20 > A better definition would be something like "when performing work, = each hash should be independent". =20 >=20 > ASICBOOST does multiple checks in parallel, so would violate that. --Apple-Mail=_AF54D3AA-121C-4FFE-A42F-37EA69BF0C7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
(message was originally sent off-list by = mistake).

Hello Tier,

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=E2=80=99s 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.

= --Apple-Mail=_AF54D3AA-121C-4FFE-A42F-37EA69BF0C7D--