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
144
145
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B8CF3279
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 00:17:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
[209.85.213.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32062140
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 00:17:19 +0000 (UTC)
Received: by mail-vk0-f43.google.com with SMTP id r69so24119279vke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Apr 2017 17:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=jS8e1RuF66tE0Hi8VHtyS8IIWA8ZQvLaYjXqrL/Ut3k=;
b=OgJWsD0Fq0BJq0RgFGkKvHvoDlb77xtWfnTbtgzskqTC9JmJ/KUKYpn8zoR0QbH6Pp
tPHK+PQX2XIEvLFZSDShQqJMo1HgCxjDR/pQL8dgDJ2RAebnqqQ8559Tx1hicHddvI44
JDTxmx6P/SIHoEgzGeGI+X/C3/h5OtGzAgjXzaR4kykmfjP28+1807G6GkKTl2qBsLEI
uyOpd3vfGLtZzevUGQaHRe/qAjyyvOiVXEJtkhkU26kzA7LV4X9WYvLls5zyEWOMwKb9
2gLKhTcDKva0CpNBrekFzt0CYoJcHd5a5HJAgcF0dEwixeIjyeP+1cu6/Q910A0PkjoI
x09Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=jS8e1RuF66tE0Hi8VHtyS8IIWA8ZQvLaYjXqrL/Ut3k=;
b=BbdOSNpVjmIh60SlpaFEhpY7dUTPD26/6ZP9WvDdOPorkeOCSOls+rFTvj3gwJC7nM
wz9qZmk+wjoIRDBvd/5OvIlzteefNyT09U7YfLLLKz28iD1WDBQtKDQK+X+gNOAkRURL
jj/m6j096jY+PHAQsU0myU5FJZOAuRHjemZkAwK/Rm//HIVfPG8h3u+8P+W8cVF/f2zT
ufwQHDBdmwmI/sWJSvJXBHkJvwIKE3rshC6A5Giq93Mhrgx0FwAv2ud315ONwQatsZNP
JffagmKEydcS0DuUC++zOkGWoECiGNRR7GiBNiT/pqodbl9U87kakRUxL1MFKVSDRp2B
8EXw==
X-Gm-Message-State: AFeK/H3fM90//Mjbt1IPanKHJ0oKfeecCSshhKAkn03HEWq9u/wCeBn03ukjPddbfbAFzG2CbZKu2yG+Cfm18Q==
X-Received: by 10.176.4.68 with SMTP id 62mr2737625uav.134.1491437838270; Wed,
05 Apr 2017 17:17:18 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.152.203 with HTTP; Wed, 5 Apr 2017 17:17:17 -0700 (PDT)
In-Reply-To: <1491433518.2765667.935644008.2B153D86@webmail.messagingengine.com>
References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com>
<1491433518.2765667.935644008.2B153D86@webmail.messagingengine.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Thu, 6 Apr 2017 00:17:17 +0000
X-Google-Sender-Auth: _6YWy7X7TT81Hs0XbwrKJd8wuLs
Message-ID: <CAAS2fgS9dOxJDU0WU87aSJhvYbYu60kVnO6acE0G7QJFw4AQLQ@mail.gmail.com>
To: theymos <theymos@mm.st>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the
Bitcoin POW function
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, 06 Apr 2017 00:17:19 -0000
On Wed, Apr 5, 2017 at 11:05 PM, theymos via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> This seems to be a serious security problem. Would it be possible to have
> a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think that a trigger
> 3-6 months from release should be sufficient for enough of the economy to upgrade,
> given the severity of the issue.
Not 0.14.1 because that is in RC already and will hopefully be out in a week.
I think the speed of adoption depends a lot of the level of support
from the community. I don't believe there are any technical hurdles to
implementing this relatively quickly (and I specifically propose using
the users choice of the segwit commitment or a modified form in order
to lower the technical complexity and risk).
> BIP 141 says that the the commitment is optional if there are no SegWit transactions in
> the block, so will today's SegWit-ready miners always produce it even when optional
> according to BIP 141, as required by this softfork?
This is the default behavior as of 0.13.2, but I haven't gone out to
measure this which is why the backwards compatibility section of the
BIP isn't written yet.
While I'm posting, I've had a dozen off-list emails that presented me
with some FAQ:
Many people asked what other protocol upgrades beyond segwit could run
into the same incompatibility.
Many proposed improvements to Bitcoin require additional
transaction-dependent commitment data.
Examples include:
(1) Segwit.
(2) UTXO commitments. (non-delayed, at least)
(3) Committed Bloom filters
(4) Committed address indexes
(5) STXO commitments (non-delayed).
(6) Weak blocks
(7) Most kinds of fraud proofs
-- to state a few.
Unfortunately, putting *any* commitment to data dependent on the right
hand side of the hash tree in the left hand side (e.g. coinbase) means
a massive increase in the computation required for covert boosting,
because it means you can't use the left+right side combinations to
eliminate most of the hashing.
It's plausible, in fact, that this extra computation could completely
nullify the ASICBOOST advantage-- though this depends a lot on the
fine details of the implementation.
This proposal does not itself propose nullifying ASICBOOST entirely,
it proposes severely handicapping the covert form of it, and
eliminating the differential advantage for boosting miners related to
the use of transaction-dependent commitments.
Basically there are two completely separate concerns: that boosting
can produce a monopoly advantage which could be severely harmful to
the ecosystem, and that the efficient implementation of _covert_
boosting can severely harm many useful protocol improvements. My
proposal only addresses the second concern, by (I believe) completely
leveling the playing field so that opposing commitments will not break
boosting any worse, and by making covert boosting less appealing in
general.
Use of the segwit-style commitment even in non-segwit blocks is sufficient
because the segwit commitment commits to all transactions (except
the coinbase) and not just segwit ones.
(It was designed this way so that lite clients that needed witness
data could work with just one tree).
|
