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
|
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 5E2B6360
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Apr 2017 07:56:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com
[209.85.217.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C60C8108
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Apr 2017 07:56:32 +0000 (UTC)
Received: by mail-ua0-f170.google.com with SMTP id a1so44462567uaf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Apr 2017 00:56:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:from:date:message-id:subject:to;
bh=iS2nRLmpjXheKvvPP/5GNYgUJWSkkUpMhUfLZw0NVf0=;
b=fOnlUiRAz4sKpFgdINdg3AhRp0r7t35Q6pt9J2h1OpozhrGpVrbA0RRpj+Z1OOOsmw
U7aJ4HSrABwAp+VI9RPv/pQyEVZA33wPQyhLs+V98mXRQoiezi3N0vbcBjzga1ZPwWXC
LhVguQ32UzX1m9iOHTtFMv+PRP++U68o5Vr9HOosOsAktGWv5hX0kWVuslZpW3R+cpXf
Ay+L+Z+tSrNT/lHTuEVZiduY8x2KtWYeOydN3WfijmKutETfg9S3qCLcB/S9kBsxQJRY
cGqBDfWavfVsdY8ThzzI8U1hH9MOe7r30o6DLN0c3ZbDWl+MfHvqMkaG2/BkggdCWW9Q
+gUA==
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:from:date:message-id:subject
:to; bh=iS2nRLmpjXheKvvPP/5GNYgUJWSkkUpMhUfLZw0NVf0=;
b=dTqmjKBfwp5V4cFvn+2BVzVn5VhcjZD6BdV0bRTg+ypghOkmBhNZ8cMcpNqaXMahqI
FqJODqkdEk4ftKajk3XayQ/rHqvTR95OahjnK/difbDjoUcECxwrKhZEN3sUvBjRLg8d
00mMldDzSQ5xh7W/fgD5NwAhv/lau/vdZD+gCKb7XMGk/FNwOflNxqGP3UEAqOu/L9Dl
WD3ZRavWEsGCsRFpwWewIeqQvszwUYEbCPTqBrxc0vMo+A8Q4TZnFU6v6IhyR58GRqR3
ypVA+kEM4HYYeeNkrIUyu2CevABi3qF102zT0C/BEJxPomv5brcV2W5Bth8ToxKhbIz2
O1rA==
X-Gm-Message-State: AN3rC/6EHcAfHQ9RCb/lmHAAMi2njZEaAO8N/dlE2sqJZCp9st10fs9+
N21G3YiaCeP6DQVrZpWnTMuEPP3bdw==
X-Received: by 10.176.70.26 with SMTP id m26mr2831996uaa.167.1492156591771;
Fri, 14 Apr 2017 00:56:31 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.94.132 with HTTP; Fri, 14 Apr 2017 00:56:31 -0700 (PDT)
From: Gregory Maxwell <greg@xiph.org>
Date: Fri, 14 Apr 2017 07:56:31 +0000
X-Google-Sender-Auth: Dr3NbaK4QR7Ciy6nL2JLZv7EJNw
Message-ID: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
To: Bitcoin Dev <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: [bitcoin-dev] I do not support the BIP 148 UASF
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: Fri, 14 Apr 2017 07:56:33 -0000
I do not support the BIP148 UASF for some of the same reasons that I
do support segwit: Bitcoin is valuable in part because it has high
security and stability, segwit was carefully designed to support and
amplify that engineering integrity that people can count on now and
into the future.
I do not feel the the approach proposed in BIP148 really measures up
to the standard set by segwit itself, or the existing best practices
in protocol development in this community.
The primary flaw in BIP148 is that by forcing the activation of the
existing (non-UASF segwit) nodes it almost guarantees at a minor level
of disruption.
Segwit was carefully engineered so that older unmodified miners could
continue operating _completely_ without interruption after segwit
activates.
Older nodes will not include segwit spends, and so their blocks will
not be invalid even if they do not have segwit support. They can
upgrade to it on their own schedule. The only risk non-participating
miners take after segwit activation is that if someone else mines an
invalid block they would extend it, a risk many miners already
frequently take with spy-mining.
I do not think it is a horrible proposal: it is better engineered than
many things that many altcoins do, but just not up to our normal
standards. I respect the motivations of the authors of BIP 148. If
your goal is the fastest possible segwit activation then it is very
useful to exploit the >80% of existing nodes that already support the
original version of segwit.
But the fastest support should not be our goal, as a community-- there
is always some reckless altcoin or centralized system that can support
something faster than we can-- trying to match that would only erode
our distinguishing value in being well engineered and stable.
"First do no harm." We should use the least disruptive mechanisms
available, and the BIP148 proposal does not meet that test. To hear
some people-- non-developers on reddit and such-- a few even see the
forced orphaning of 148 as a virtue, that it's punitive for
misbehaving miners. I could not not disagree with that perspective any
more strongly.
Of course, I do not oppose the general concept of a UASF but
_generally_ a soft-fork (of any kind) does not need to risk disruption
of mining, just as segwit's activation does not. UASF are the
original kind of soft-fork and were the only kind of fork practiced by
Satoshi. P2SH was activated based on a date, and all prior ones were
based on times or heights. We introduced miner based activation as
part of a process of making Bitcoin more stable in the common case
where the ecosystem is all in harmony. It's kind of weird to see UASF
portrayed as something new.
It's important the users not be at the mercy of any one part of the
ecosystem to the extent that we can avoid it-- be it developers,
exchanges, chat forums, or mining hardware makers. Ultimately the
rules of Bitcoin work because they're enforced by the users
collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
something people can count on: the rules aren't easy to just change.
There have been some other UASF proposals that avoid the forced
disruption-- by just defining a new witness bit and allowing
non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
think they are vastly superior. They would be slower to deploy, but I
do not think that is a flaw.
We should have patience. Bitcoin is a system that should last for all
ages and power mankind for a long time-- ten years from now a couple
years of dispute will seem like nothing. But the reputation we earn
for stability and integrity, for being a system of money people can
count on will mean everything.
If these discussions come up, they'll come up in the form of reminding
people that Bitcoin isn't easily changed at a whim, even when the
whims are obviously good, and how that protects it from being managed
like all the competing systems of money that the world used to use
were managed. :)
So have patience, don't take short cuts. Segwit is a good improvement
and we should respect it by knowing that it's good enough to wait for,
and for however its activated to be done the best way we know how.
|
