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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
Return-Path: <akaramaoun@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A40CB416
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2016 15:38:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CBBC61DE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2016 15:38:19 +0000 (UTC)
Received: by mail-wm0-f51.google.com with SMTP id e69so42594637wmg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2016 08:38:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:from:date:message-id:subject:to;
bh=wekBTdtga+HJCiR5HBNQfcRbRwaOfe7vV+A6xxk99zY=;
b=o9vKugzNVHRSS3FMNH47qsD+iL20Cpz6zUv4KErD3wBew1YrC0kC2DboQB9oYEB8pd
iA3KSoc69nzXJd216e35D8UCNydwKdpE0Elr54bwMc5ZPKdXleI+o/TQam5IBoqAJ51v
myCzDziDSApHIKWST1G3RVKDmTiWKh78HmKcPjJ4ATPdE6HCLN5xu11yu3Q7kaO0QuIi
3rPGx2n2jr5HEyNxBM2vPh8sh4u75Nlrl0nWSmFZjLoCmgbRSwRpBsWQW+mULs1SEKMq
XAmx2sSG49NttVPVE43QtZawA5sZ6YVtrkCNUq9KMY6h+S///AYtC/tj9IvHsEqB4w2h
oQpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
:to; bh=wekBTdtga+HJCiR5HBNQfcRbRwaOfe7vV+A6xxk99zY=;
b=YbLlzdiiwWoEftOjTh8KbaZy6OwBFn+VoqD05HwSw51EopxTYLBgWU64p2B6zg03Sb
KjyOOkEmoecxK2pxdV8UfplgQn8YeGbzwyAmGb9xNsWegq2qZEWxycxAHEdHzSCWtZ6t
cEID8VokS2vWTcODQnmL3FDsIG3qudAklTFeEt85Q6XbDLHcnRHYAmRzGaCFj/Gvp80F
LOwUzxohAXUtQ//+FDKhfxIYSJuZ9sU73EfJxUAwVNlzjTZEgsw3YuNSMLNjyYRAH+54
5BkJdDXXeKjFA9v3rT1NJQYkOyvuLMdvmSWbpht1kmAKBdf1Mg9X3QDkYaGcN/FJ5//6
JZ+w==
X-Gm-Message-State: ABUngvdp/6wBt9gawfP5+Hwt7JowGPGMNckC7Sj4sa09DvIqFRNvAniP3xyDiAGZQKij5vAsZ0EqxdLEdM2PSA==
X-Received: by 10.28.185.147 with SMTP id j141mr15441686wmf.108.1477582698180;
Thu, 27 Oct 2016 08:38:18 -0700 (PDT)
MIME-Version: 1.0
Sender: akaramaoun@gmail.com
Received: by 10.28.199.199 with HTTP; Thu, 27 Oct 2016 08:38:17 -0700 (PDT)
From: Andrew <onelineproof@gmail.com>
Date: Thu, 27 Oct 2016 15:38:17 +0000
X-Google-Sender-Auth: WHiTL9OSJ_rJK_C3JuV803_VmJI
Message-ID: <CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1148e28cda0708053fda87de
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] The Soft Fork Deception
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, 27 Oct 2016 15:38:24 -0000
--001a1148e28cda0708053fda87de
Content-Type: text/plain; charset=UTF-8
I have been reading recently through the history of soft forks provided by
Bitcoin Core:
https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks
.
It has led me to think that there is a deceiving notion that soft forks do
not force Bitcoin users to upgrade software. Yes, it's true that the past
soft forks still allow old nodes to accept blocks under the tighter rules
as valid, but what about miners who are still using old software? What
about users who want to make a transaction using the old rules? Those
people are no longer able to do those things. And if they want to do those
things, a hard fork will result.
Remember what happened when BIP 66 was activated? Luckily, it was short
lived, but this is just the beginning. If you keep tightening the rules,
you are building up more and more pressure for a split in the network to
occur. You can call this split a "hard fork" or just a "fork", but it is
dangerous either way, and it leads to basically the creation of two coins
when before we just had one, people instantly lose value, and the trust in
Bitcoin's store of value dies.
Obviously every one can debate about what should be the definition of a
soft fork, but whatever that is, I think it is unacceptable how sloppily
the past soft forks have been deployed. I can think of many ways in which
we could have these new features that the soft forks provided, but without
forcing the new rules, and simply making them features that can be used on
an individual miner or transaction signer basis. Is there a document from
Bitcoin Core that outlines the philosophy of soft forks and why it is
acceptable to force the tightening of rules and cause such risks? And
please give me another reason other than "it removes a few if statements
from the code".
Now that Segregated witness is scheduled to be deployed on November 15, we
should take a look at this "soft fork" as well. I like the idea of
Segregated Witness, but from conversations on Reddit and IRC, I see people
saying that this soft fork will be like the others: requiring a hard fork
in order to revert it. Is this true? I am getting conflicting messages by
reading the BIP. It says that if all transactions are non-segwit, then a
node will validate the block as before. But if we pass the threshhold
(usually 95 % for 1000 blocks) will miners mining non-segwit blocks be
ignored? This is not good... I really think we should make it optional.
Miners will have an incentive to mine segwit blocks, since it allows for
more transactions per block, so why force them? What if we want to slightly
modify the Segwit protocol in the future? What if we want to replace segwit
with something much different? We will be forced to do a hard fork in order
to do that.
Now, we can't go back in time and fix the deployment of the soft forks, but
I do propose one clean way to fix things: Remove all the previously "soft
forked" rules for non segwit transactions, and require them only for segwit
transactions. But make segwit optional! In addition to what I talked about
above, this may also relieve some tensions of people who are not
comfortable with segwit and are thinking of joining a hard fork like the
Bitcoin Unlimited project.
Unless people can give me a good explanation as to why we are deploying
soft forks in such forceful manner, or Bitcoin Core accepts my proposal,
then I will have no choice but to create a new client (I'm thinking to call
it Bitcoin Authentic), that will be just as Bitcoin Core but will always
follow the chain with the most work regardless of whether soft fork rules
are respected, and I would put at least CHECKLOCKTIMEVERIFY as mandatory
within segwit transactions.
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
--001a1148e28cda0708053fda87de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I have been reading recently through the history=
of soft forks provided by Bitcoin Core: <a href=3D"https://bitcoin.stackex=
change.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-for=
ks">https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-re=
cord-of-blockchain-soft-forks</a>.<br><br></div>It has led me to think that=
there is a deceiving notion that soft forks do not force Bitcoin users to =
upgrade software. Yes, it's true that the past soft forks still allow o=
ld nodes to accept blocks under the tighter rules as valid, but what about =
miners who are still using old software? What about users who want to make =
a transaction using the old rules? Those people are no longer able to do th=
ose things. And if they want to do those things, a hard fork will result.<b=
r><br>Remember what happened when BIP 66 was activated? Luckily, it was sho=
rt lived, but this is just the beginning. If you keep tightening the rules,=
you are building up more and more pressure for a split in the network to o=
ccur. You can call this split a "hard fork" or just a "fork&=
quot;, but it is dangerous either way, and it leads to basically the creati=
on of two coins when before we just had one, people instantly lose value, a=
nd the trust in Bitcoin's store of value dies.<br><br></div>Obviously e=
very one can debate about what should be the definition of a soft fork, but=
whatever that is, I think it is unacceptable how sloppily the past soft fo=
rks have been deployed. I can think of many ways in which we could have the=
se new features that the soft forks provided, but without forcing the new r=
ules, and simply making them features that can be used on an individual min=
er or transaction signer basis. Is there a document from Bitcoin Core that =
outlines the philosophy of soft forks and why it is acceptable to force the=
tightening of rules and cause such risks? And please give me another reaso=
n other than "it removes a few if statements from the code".<br><=
div><div><div><div><div><br></div><div>Now that Segregated witness is sched=
uled to be deployed on November 15, we should take a look at this "sof=
t fork" as well. I like the idea of Segregated Witness, but from conve=
rsations on Reddit and IRC, I see people saying that this soft fork will be=
like the others: requiring a hard fork in order to revert it. Is this true=
? I am getting conflicting messages by reading the BIP. It says that if all=
transactions are non-segwit, then a node will validate the block as before=
. But if we pass the threshhold (usually 95 % for 1000 blocks) will miners =
mining non-segwit blocks be ignored? This is not good... I really think we =
should make it optional. Miners will have an incentive to mine segwit block=
s, since it allows for more transactions per block, so why force them? What=
if we want to slightly modify the Segwit protocol in the future? What if w=
e want to replace segwit with something much different? We will be forced t=
o do a hard fork in order to do that.<br><br></div><div>Now, we can't g=
o back in time and fix the deployment of the soft forks, but I do propose o=
ne clean way to fix things: Remove all the previously "soft forked&quo=
t; rules for non segwit transactions, and require them only for segwit tran=
sactions. But make segwit optional! In addition to what I talked about abov=
e, this may also relieve some tensions of people who are not comfortable wi=
th segwit and are thinking of joining a hard fork like the Bitcoin Unlimite=
d project.<br><br></div><div>Unless people can give me a good explanation a=
s to why we are deploying soft forks in such forceful manner, or Bitcoin Co=
re accepts my proposal, then I will have no choice but to create a new clie=
nt (I'm thinking to call it Bitcoin Authentic), that will be just as Bi=
tcoin Core but will always follow the chain with the most work regardless o=
f whether soft fork rules are respected, and I would put at least CHECKLOCK=
TIMEVERIFY as mandatory within segwit transactions.<br clear=3D"all"></div>=
<div><div><br>-- <br><div class=3D"gmail_signature">PGP: B6AC 822C 451D 630=
4 6A28 =C2=A049E9 7DB7 011C D53B 5647</div>
</div></div></div></div></div></div></div>
--001a1148e28cda0708053fda87de--
|
