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
|
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 72C841AC1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 20:31:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f193.google.com (mail-io0-f193.google.com
[209.85.223.193])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 002AD24B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 20:31:43 +0000 (UTC)
Received: by iofb144 with SMTP id b144so2210512iof.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 13:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:cc:content-type;
bh=z+Pd6kv1/xtf39Ud9EJs++RGIhKVylftmhcZYANnNAo=;
b=wGm43tauEGhkpRiVzbBhCOlvzzHJoqcvcoyip/3vpNLz20DJdQZJeKWK9fIl6faM20
sHgef9TkmFdbkPJJ6UBzhmTSYDYP4q62mWZdzwYI80hjLWMkGPvpO3nWjJu6h6bZlfe5
5npmwpJU9/ix2dwjV6VXEoMWIqT2wQGqy6vSRYxGVacmZRdc7jy7FXWRodOdlSb1Dcli
lKaBrPBkB1GWb01q/W7mIDlZrBBYAFHdCl0RTefuiB03Ha6jcTxdI8QCgHdk9zoDXNvL
LPED0MB8gvhUU18BrLQGQDEdDYPl01BO2wK4V5BbBL/tUQFPD8COB/yBLbz7XXy8Lq3F
YtXw==
MIME-Version: 1.0
X-Received: by 10.107.47.219 with SMTP id v88mr848310iov.134.1443558703251;
Tue, 29 Sep 2015 13:31:43 -0700 (PDT)
Received: by 10.107.19.30 with HTTP; Tue, 29 Sep 2015 13:31:43 -0700 (PDT)
Date: Tue, 29 Sep 2015 20:31:43 +0000
Message-ID: <CAAS2fgT-EjevwhCLJGx4U=7BOQ6z4ExL12_i_QBpuKA5vDzXTA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Dave Scotese <dscotese@litmocracy.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,PLING_QUERY,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Are 'soft forks' misnamed? [was: Let's deploy BIP65
CHECKLOCKTIMEVERIFY!]
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Tue, 29 Sep 2015 20:31:44 -0000
On Mon, Sep 28, 2015 at 10:16 PM, Dave Scotese via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Why are they called soft forks when they are really hidden forks? Isn't the
> point of a soft fork to prevent old clients from rejecting what they don't
> have the code to validate? That seems dangerous.
As an aside, this list loses utility if people insist on taking
tangential questions to the list in the middle of threads. It's
preferable to either split the thread or take the message off list.
The naming arose from a series of historical naming-by-comparisons:
The bitcoin network has self-arising forks in state when miners
concurrently create blocks. These are natural, unavoidable, and
self-resolving.
If a nodes enforce different and incompatible rules-- for example,
some decide to require that the subsidy stay at 25 BTC forever, then a
fork may come into existence which is not self resolvable.
Thus the term hardfork arose to talk about rule changes which were
incompatible with the existing network, would require all users to
upgrade, would exclude all non-consenting users from the resulting
system, and which have the power to arbitrarily rewrite rules. This
is in contrast to "forks" which are boring, natural, and happen every
day.
Its often possible to make critical fixes and powerful improvements to
the Bitcoin consensus rules by using the unavoidable power of miners
to filter transactions according to their own rules. New features and
fixes can be carved out of existing "do anything" space in the
protocol: like carving a statue out of a block of marble. Doing so
reduces the incidence of flag days which are costly to coordinate and
actively risky for users and avoids forcing constant software churn,
which is bad for decentralization. Such changes are a strict narrowing
of permissible actions. And as such, so long as they have a
super-majority hashpower behind them any network forking that happens
to result from them is automatically self-resolving.
So by contrast with hardfork the term softfork came into use to
describe these _compatible_ protocol rule changes.
There is explicit support for compatible rule changes the bitcoin
protocol in the form of no-op opcodes and free form, non-enforced,
version fields (for example). Every fix or enhancement you've heard
about to Bitcoin's consensus rules (going back to the system's
original author) was performed via some form of this mechanism.
In the modern form, the behavior to be soft-forked out is first made
non-standard (if it wasn't already-- they almost always are) meaning
that participants will not relay, mine, or display unconfirmed txn in
their wallets transactions which violate the new rule. But if a
violation shows up in a block, the block is still accepted. After
that the blockchain itself is used to coordinate a vast super-majority
of hashpower (recently 95% has been used) agreeing to enforce the new
rule which results in confidence confidence of low disruption on
account of the enforcement. Then when the threshold is reached, they
enforce (automatically). Old software continues to enforce all the
old rules they always enforced, the only difference in behavior
relates to non-standard transactions and contests between otherwise
valid blocks. Even unupgraded participants can tell that the network
is doing something new on account of the block version changing (and,
for example, Bitcoin Core warns users about this).
The primary disadvantage of this approach is that it only allowed you
to carve functionality of of "do anything" space, which is quite
natural for some features (especially since the Bitcoin protocol
includes tons of do anything space)--- e.g. height in coinbase, DER
strictness, transactions that have integer overflow creating a
kazillion coins-- but less natural for others.
Of course, it's always possible for the majority of hashpower to have
hidden transaction exclusion rules that _no one_ but them knows about
and this cannot be prevented, but at least the mechanism proscribed in
modern soft-forks is transparent (the network tells you that its doing
something you don't understand).
|
