From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BCC68B5A for ; Thu, 18 May 2017 13:44:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 427121DE for ; Thu, 18 May 2017 13:44:53 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id b84so202527305wmh.0 for ; Thu, 18 May 2017 06:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=W7xWV2Xr6tu3rWaVXR0SQSj6C4IS4DO9DcKuN+Zaa1A=; b=o2tvD7JoabhOiwiuxxmTaNNC8vscoVsKEPvlNtVcsMKWjp59TVAhnkKfJlrrqWM67k 3TDc6hISH1xpf759A0qKBnf+oDNvIoDpgyVU18FtybPNaCr0cZmKx+LKyRgOL97fJhBk lUQW/baZqAbwSSf6FjqsbmRluFNRGzR3SOAOh191c4PkSM1eo0/jc97RI+30GY1RYW5G 780PG6yekpZdZGJBQHodyjnhmwOaxxxNkp109amh+qz/KncxWuVe60huUORZt45RFmUn n3ph1aQXEHHN5yUFlFhqAjRR7hEiQRq7JPrzDpxCITrjSf1tL65E4G7xosw+jtAWTW00 +VLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=W7xWV2Xr6tu3rWaVXR0SQSj6C4IS4DO9DcKuN+Zaa1A=; b=B9zJYot1s7IhGzRfw1PFLg+cR+wLwbhR/2uFaOjStEpTQL4JD2Leev8OFQRr6hMv1l VQzw5cxUwETLxbp485Apfa4u3roW/Rx4d7sCPoHdMGrwzCI/q3qeM33Y6s/b+bsxf7bT v2H5WO7ZJNqNruNQ0x3jqg6hEZiLmtA4QO3UHe5UO89EWugKi94EaSdnAshoPfV/i6uC HPkTDueZt0olqbq9Fpog7FJAuP+r/pn/rB6VoJdXWBAp55VtziK0crg3OGWMTWwKjkkD l7DSjoBaLbYJEahO33aoCv3Z+1WA9Lr+8qOXupkCkzu/P8Wycj2XeVB3PSZrkqAQJQ2o UsAA== X-Gm-Message-State: AODbwcBuNHQAkIojdHwEL/333grYPWwM/78iNjkcqxCufnC1gT7dXPiN IVQWd8A3xygdSZCCB3M= X-Received: by 10.25.44.208 with SMTP id s199mr984499lfs.180.1495115091402; Thu, 18 May 2017 06:44:51 -0700 (PDT) Received: from [172.20.10.2] ([213.87.146.12]) by smtp.gmail.com with ESMTPSA id a22sm383935lfk.62.2017.05.18.06.44.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 06:44:49 -0700 (PDT) From: Cameron Garnham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <4BA0FA5D-7B29-4A7F-BC5B-361ED00D5CB2@gmail.com> Date: Thu, 18 May 2017 16:44:47 +0300 To: Bitcoin Dev 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, 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 Subject: [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: Thu, 18 May 2017 13:44:53 -0000 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 = 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 = =E2=80=98ASICBOOST=E2=80=99. =E2=80=98ASICBOOST=E2=80=99 is an attack on this Bitcoin=E2=80=99s = security 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 = 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.=