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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1XmX1J-0005x9-L8
for bitcoin-development@lists.sourceforge.net;
Fri, 07 Nov 2014 00:03:17 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.161 as permitted sender)
client-ip=62.13.148.161; envelope-from=pete@petertodd.org;
helo=outmail148161.authsmtp.com;
Received: from outmail148161.authsmtp.com ([62.13.148.161])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1XmX1H-0008OU-Nm for bitcoin-development@lists.sourceforge.net;
Fri, 07 Nov 2014 00:03:17 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA7039mG048992;
Fri, 7 Nov 2014 00:03:09 GMT
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA7035is075490
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 7 Nov 2014 00:03:08 GMT
Date: Thu, 6 Nov 2014 19:03:10 -0500
From: Peter Todd <pete@petertodd.org>
To: Justus Ranvier <justusranvier@riseup.net>
Message-ID: <20141107000310.GA6532@savin.petertodd.org>
References: <20141106213215.GA12918@savin.petertodd.org>
<A53D2C60-1D6A-4796-9776-3AF396BEC9F1@bitsofproof.com>
<545BF0C2.3030201@bluematt.me>
<CAJHLa0NTj6m4JpHx3+nWtYVV1Zpwf-FaxiyFX9DR821cQYVqsg@mail.gmail.com>
<545BFAD6.1000504@riseup.net>
<20141106232649.GD26859@savin.petertodd.org>
<545C0617.7020300@riseup.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk"
Content-Disposition: inline
In-Reply-To: <545C0617.7020300@riseup.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 74c2eb8c-6611-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgUUFloCAgsB AmIbW1ReUF57WWs7 bA9PbARUfEhLXhtr
VklWR1pVCwQmQm0G Bh0bC1pycABCcX4+ ZEBnVnEVW0ApdxMv
Sh1JE2sHZHphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDIj4x DxwDEzsuFlABWzR7
KBJuNUQdAEcXPQ05 Nl06VFQDLgRwQgZE Hl1MCyZdb1IGSyd5
RR9aUAYlMRJ9aBx8 NSYJBDBsL3RYRyUw
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1XmX1H-0008OU-Nm
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The difficulty of writing consensus
critical code: the SIGHASH_SINGLE bug
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 00:03:17 -0000
--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Nov 06, 2014 at 05:36:55PM -0600, Justus Ranvier wrote:
> This explanation is completely incoherent.
>=20
> Because Bitcoin has a extra consensus requirements, requirements which
> are really rare in engineering, the necessity of fixing bugs is even
> greater.
>=20
> There are two general ways to fix bugs: either as part of a
> controlled, planned, and managed process, or as a response to an
> immediate disaster.
>=20
> The alternative to scheduling and planning the upgrades which are
> necessary to fix the bugs in the protocol, where such fixes can be
> written, tested, and documented at leisure, is to wait for some crisis
> and slap on another bandaid when the network breaks again (like it did
> March of last year).
The protocol is what the protocol is; the bugs are when you don't match
the protocol.
> Who benefits from not fixing bugs in Bitcoin?
We can bring up politics if you want.
In the current model, the specification *is* the protocol, and the
Bitcoin Core team is scared to death of changing anything; they've got
very little real power. Soft-forks are the minimum-viable way of making
changes to the protocol, and it's very clear how they get adopted:
minerr consensus. They're also a fundemental way of changing the
protocol that is impossible to prevent, so you might as well use it.
Hard-forks require political consensus to achieve, and the way you
create that political consensus is by creating committes, groups,
associations... Foundations. Every last one of those things requires
centralization and political power.
You know, the smartest thing the Bitcoin Foundation could do if they
wanted to cement their place in the Bitcoin ecosystem as a power broker
would be to setup a program of periodic hard-forks, say every year or
two, and then manage the committees that decide what goes into those
hard-forks. That they haven't suggested that yet is a sign that they're
either not evil, or they don't understand Bitcoin very well.
I think programmers find this reality hard to accept, because they're
mostly interested in writing code that'll get widely used. To them it's
hard to accept that the Bitcoin protocol *is* a few thousand lines of
C++ code, and they're not good enough to write their own implementation
and make it match; if we replaced programmers with writers we might get
the equally bizzare and pointless situation of people taking perfectly
good RFCs and rewriting them in their own words.
If you do care about keeping the politics of Bitcoin development free
=66rom centralized control you should do what I advised the Dark Wallet
team to do a year ago: fork Bitcoin Core and change the
non-consensus-critical code that implements policy. I've done this
myself in a minor way with my replace-by-fee(1) version. Luke-Jr has
also done this with his Eligius branch, a fork that something like 30%
of the Bitcoin hashing power appear to run. (Discus Fish has been mining
non-standard transactions(2) lately)
Multiple *forks* of the Bitcoin Core reference client that are actually
getting used by miners and other users ensures that no one group
maintaining such a fork has the ability to change anything without
strong consensus. Forking the codebase, rather than rewriting it, best
ensures that your code actually implements the protocol properly, is
safe to use for mining, and actually gets used.
Rewriting Bitcoin Core is a fun project, but it's terrible politics.
1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.3
2) https://blockchain.info/tx/e24a4085c54a6362e615f8eab758c12d80e488b73757e=
6d2b8ab6bfc8be7007e
--=20
'peter'[:-1]@petertodd.org
000000000000000008f2290924a6882928d4566f487f33cc57203a6535795201
--UugvWAfsgieZRqgk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUXAw6XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxNDk1N2U5ZTIyNjQzMjA5NTcxZDdlMDUxOWYwNDkxZDg1
NjE0ZjM2NDRjNmVmZjYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfstYwgAp6Vyjs7wq3o44q+/RxGlGBny
1FXdFvu9xqJjI/Es6WcVmRo56yAxt9TvRjdYEACQDDZsWYD6cbgX9ikWr6Eu1rRY
dECgOq6rssBpvQBLVpQ4q20ec8dHBjNex2Qc0N4RgR1ZgGDjyJYykSRYqr7HZMrf
wOhKl3d01N2tSQ7zamXUZXwkPKofPzekTeie2qo9K8/F3TT5X18VAeDf+Sxk6WwZ
0hVrhTVoSlCl5aiLxp1WUH1mPpKAV5Dj6xIl7IsR1h4j+x2xQ2ybzbavo4iRm2TO
FTawpgGi+HupveDK9k7MnC7duM+Dg/qFLcjBle4y63fyYRzKxD0qSlKZiwKl7Q==
=U406
-----END PGP SIGNATURE-----
--UugvWAfsgieZRqgk--
|
