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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
Return-Path: <joseph@lightning.network>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 14BB7279
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 00:37:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com [74.125.83.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7F4A015E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 00:37:49 +0000 (UTC)
Received: by mail-pg0-f47.google.com with SMTP id g2so19386385pge.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Apr 2017 17:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=lightning.network; s=google;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-disposition:in-reply-to;
bh=kg32SspRjG2MQJKEv7dePyEqUmlFzPs8FhOcLjyAeHQ=;
b=YnEe/GaQI5Dr1rgWu71uYpX+LMCasvZV11dDz6AJdeGNkPMNqBGe8qwEgLexyCDuss
OIy9EJ8J0ExwCFyTDGQKkq2VniiIW0HicYN3wDpCqGMPETVoD5X81lxCi193Q9yTXbY2
EE63cVcyygHRl4cyO3nZQWBLoP2jSmyb9PKCY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-disposition:in-reply-to;
bh=kg32SspRjG2MQJKEv7dePyEqUmlFzPs8FhOcLjyAeHQ=;
b=qwDjgKwmf8uer9p2pJoJlq8YjK5dIqqO2UOf/TG6QOfkM4sogTLFd+3XQoZGYOxNlC
i7hx5nltYhvioIGhBo5tXfinM/NJolPkOVYt4IRIQmSzyMDTbJgocwR5+1gNH0bCQPqw
hSO2XhQBjqGLRapshX4rIBHto8yWfA7wOyf0dcURhc5tCZT0EnJWR+UWUXgUgR82dowh
4+sPv2QDCVMX9DhfFRAaeSKCDrUlmrHiVGwWAtAPeKkHECcMM7cVk3h6uGgvoPHlHSkf
+2BjSiIHtK6zrLDN7L2/o2mmp9ilyZbmzjjxfkXzIhkiUZiHcuCE/Mu1TDWNQsvZZuhv
5NJQ==
X-Gm-Message-State: AFeK/H0efC922W08HGikObMHH7awCRWerrA7Ur4ou9uK4QjsVQX1S0Vi96XFIyioPvjsZw==
X-Received: by 10.99.181.86 with SMTP id u22mr33480227pgo.102.1491439068876;
Wed, 05 Apr 2017 17:37:48 -0700 (PDT)
Received: from localhost ([205.185.122.187]) by smtp.gmail.com with ESMTPSA id
q86sm11379538pfk.43.2017.04.05.17.37.47
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 05 Apr 2017 17:37:48 -0700 (PDT)
Date: Wed, 5 Apr 2017 17:39:00 -0700
From: Joseph Poon <joseph@lightning.network>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170406003900.GB8379@lightning.network>
References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com>
<1491433518.2765667.935644008.2B153D86@webmail.messagingengine.com>
<CAAS2fgS9dOxJDU0WU87aSJhvYbYu60kVnO6acE0G7QJFw4AQLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAS2fgS9dOxJDU0WU87aSJhvYbYu60kVnO6acE0G7QJFw4AQLQ@mail.gmail.com>
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU,
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:37:50 -0000
#bitcoin@freenode:
00:04 gmaxwell| lol poon pretending that he isn't complicit in all this stuff.
Are you *fucking* serious? Is this how you resolve all problems? I'm
taking you seriously and having second thoughts and want to make public
commitments to do the right thing without any evidence and you come out
and say *this*?
On Thu, Apr 06, 2017 at 12:17:17AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> 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).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Joseph Poon
|
