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
|
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 9F7355A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Apr 2017 23:41:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 172B418B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Apr 2017 23:41:30 +0000 (UTC)
Received: by mail-pg0-f41.google.com with SMTP id g2so18354528pge.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Apr 2017 16:41:30 -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=dUHbvfszkV22WtZcNp2MayVuE4vSB2t4x8SI4/R6ATw=;
b=TiO7KCb2MCrVFZxbDGivFftDwR6/2AQekU627lwf1BKHj4Ji3XHq3mIUj3xjWSE8wg
ox1aqmGCgDYtmCOpoLzdCtprd5Xh5Go9ch5Jurz+j9J7Fi90pwACEEb9V5qv6h9iMC8y
OzZW+sM/6rBBJWjUbwaOrEaHON+VL1E/wuzv0=
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=dUHbvfszkV22WtZcNp2MayVuE4vSB2t4x8SI4/R6ATw=;
b=gO48UI8IBuQu3umVR6mFbGibgeqlrj9aAwHk6yq3g/x3EZt70Ko7GBx+98kmqMmJt+
66kO6dEuwYJ6UBtOwyfVphWp7S+N6Pmzs2OnxfUYV/7o1DZN6MVh3eltddiq8jZ9GFI5
vbp5zUbIJazZOGMEjNPdGiZD+HZ91DyVd1jo0S0v1mUSPIJQohZH03p6YCxESwg8g6aZ
UimD40InY+f40nGeQoo4KphZgTKZUEoYbrf/M+az5MQdOjVRhqbU0a4XHzeRieoIJkO8
YTLzHePI/C8ERb9TCvaDkQ2rx/arQZCyHtk3GPvgHpR7gSh8If+AwNqmllOmL3/YJDpl
lyZw==
X-Gm-Message-State: AFeK/H3UXInmPp5JMv3mEAt21D1oS45H71q7x1XfONLw/wUtQGp5jtWYS+yq/KjniWbl9w==
X-Received: by 10.99.23.102 with SMTP id 38mr31955174pgx.188.1491435690509;
Wed, 05 Apr 2017 16:41:30 -0700 (PDT)
Received: from localhost ([205.185.122.187]) by smtp.gmail.com with ESMTPSA id
s65sm30409481pgb.34.2017.04.05.16.41.29
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 05 Apr 2017 16:41:30 -0700 (PDT)
Date: Wed, 5 Apr 2017 16:42:41 -0700
From: Joseph Poon <joseph@lightning.network>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170405234241.GA8379@lightning.network>
References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@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: Wed, 05 Apr 2017 23:41:31 -0000
Hi Greg,
On Wed, Apr 05, 2017 at 09:37:45PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> Reverse engineering of a particular mining chip has demonstrated
> conclusively that ASICBOOST has been implemented
> in hardware.
>
> On that basis, I offer the following BIP draft for discussion.
> This proposal does not prevent the attack in general, but only
> inhibits covert forms of it which are incompatible with
> improvements to the Bitcoin protocol.
>
> I hope that even those of us who would strongly prefer that
> ASICBOOST be blocked completely can come together to support
> a protective measure that separates concerns by inhibiting
> the covert use of it that potentially blocks protocol improvements.
>
> [...]
>
> ==New consensus rule==
>
> Beginning block X and until block Y the coinbase transaction of
> each block MUST either contain a BIP-141 segwit commitment or a
> correct WTXID commitment with ID 0xaa21a9ef.
>
> (See BIP-141 "Commitment structure" for details)
>
> Existing segwit using miners are automatically compatible with
> this proposal. Non-segwit miners can become compatible by simply
> including an additional output matching a default commitment
> value returned as part of getblocktemplate.
>
> Miners SHOULD NOT automatically discontinue the commitment
> at the expiration height.
Decentralized systems without patent encumbrance is an important topic
for me. We'd be very interested in adding this into extension blocks.
Claims like these merit serious attention. If you can provide any kind
of proof or documentation of this (doesn't need to be conclusive, just
something), I will provide my word and promise publicly here and now
that I will personally see to it that a commitment which solves this
(albeit possibly using a slightly different format to make it
compatible) is added into the Extension Blocks spec. If there is
evidence, my support and authorship of the Extension Block specification
is contingent upon resolving this issue.
We have added an issue here:
https://github.com/tothemoon-org/extension-blocks/issues/6
I'm interested in a more detailed explanation on how the Merle tree
structure works so we can add it to the spec, I didn't follow exactly
the new consensus rule and its mechanism in those several lines.
We will begin making a pull request adding it into our specification,
but more clarity on how to do it on its own would be helpful. We will
also consider the code exposure change to adding in SegWit on the
Canonical/1MB chain if it is more elegant to implement.
Packaging this into our proposal would not only be important, but
helpful to the end goals of this proposal as it becomes a standard
soft-fork consensus rule which has greater guarantees around
enforcibility than user-actication.
Further, can you provide clarity and confirmation into why this
commitment wasn't required as part of SegWit?
--
Joseph Poon
|
