1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Return-Path: <da2ce7@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BCC68B5A
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 May 2017 13:44:53 +0000 (UTC)
Received: by mail-wm0-f48.google.com with SMTP id b84so202527305wmh.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 18 May 2017 06:44:49 -0700 (PDT)
From: Cameron Garnham <da2ce7@gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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.=
|
