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
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1YMcXU-0004tU-Jy
for bitcoin-development@lists.sourceforge.net;
Sat, 14 Feb 2015 13:13:40 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.95 as permitted sender)
client-ip=62.13.148.95; envelope-from=pete@petertodd.org;
helo=outmail148095.authsmtp.com;
Received: from outmail148095.authsmtp.com ([62.13.148.95])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YMcXS-0002sL-MP for bitcoin-development@lists.sourceforge.net;
Sat, 14 Feb 2015 13:13:40 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1EDDPZj074718;
Sat, 14 Feb 2015 13:13:25 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 t1EDDKNt019024
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sat, 14 Feb 2015 13:13:23 GMT
Date: Sat, 14 Feb 2015 08:13:20 -0500
From: Peter Todd <pete@petertodd.org>
To: Eric Voskuil <eric@voskuil.org>
Message-ID: <20150214131320.GA26731@savin.petertodd.org>
References: <CABm2gDpReRty6TdfMDssjF27XgC_SYs_U__SFBNdsYW24Mzh8w@mail.gmail.com>
<54CC0E1D.7030409@voskuil.org>
<CABm2gDqM6q24tPEBKSHbbVQu-mvfV37PNc4hD=VjyRHk2jujZw@mail.gmail.com>
<54D0414F.6030806@voskuil.org>
<CABm2gDo_sYjNWU6EEsKmOXt5uUu87Lj1oFzqio79MxSx2SYrNg@mail.gmail.com>
<54DE7601.4070509@voskuil.org>
<CABm2gDpt60B=Sf_2X9xt4fPH7x4fff7K4h36XfosHigV5tP+4Q@mail.gmail.com>
<54DF07A5.1060004@voskuil.org>
<CABm2gDoS+XOR7Ugt91kNWNdvwsb1_Zb-aO0sma_Xps2Sx-0N5g@mail.gmail.com>
<54DF2E80.5060506@voskuil.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24"
Content-Disposition: inline
In-Reply-To: <54DF2E80.5060506@voskuil.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 416eca6a-b44b-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bgdMdwYUHlAWAgsB AmMbWldeUV57W2c7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRR10 cmplLF1ydgxGeno+ Zk9iXXAVWEV8IBUs
RB9JR2kCN3phaTUb TUkOcAdJcANIexZF O1F8UScOLxpZdhg1
ABUyIzE3Mn11KThe RQALZRINSF1DJDNu DyMmHD8lHFEOQCQ1
GlQdI0IbB0YQek42 MFYnRQBQMgRaA0VQ GFtOYmdBLkIdD3Jt
VFsSRUkFCzxXRSoL Q3UA
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: 1YMcXS-0002sL-MP
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
libbitcoin mailing list <libbitcoin@lists.dyne.org>
Subject: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin]
Satoshi client: is a fork past 0.10 possible?)
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: Sat, 14 Feb 2015 13:13:40 -0000
--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I haven't bothered reading the thread, but I'll put this out there:
The consensus critical Satoshi-derived sourcecode is a protocol
*specification* that happens to also be machine readable and executable.
Rewriting it is just as silly as as taking RFC 791 and rewriting it
because you wanted to "decentralize control over the internet"
My replace-by-fee fork of Bitcoin Core is a perfect case in point: it
implements different non-consensus-critical policy than Bitcoin Core
does, while adhering to the same Bitcoin protocol by virtue of being the
same sourcecode - the same protocol specification. When I went to miners
asking them to implement it, the biggest concern for them is "Will it
stay in consensus with other miners?" If I had rewritten the whole thing
=66rom scratch the fact is the honest answer to them would be no way in
hell - reimplementing Bitcoin and getting it right is software
engineering's Apollo Project and none of us have the resources to pull
that off. But I didn't, which means we might soon have a significant
chunk of hashing power implementing a completely different mining policy
than what is promoted by the Bitcoin Core maintainers.
By reimplementing consensus code - rewriting the protocol spec - you
drop out of the political process that is Bitcoin development. You're
not decentralizing Bitcoin at all - you're contributing to its
centralization by not participating, leaving behind a smaller and more
centralized development process. Fact is, what you've implemented in
libbitcoin just isn't the Bitcoin protocol and isn't going to get
adopted by miners nor used by serious merchants and exchanges - the
sources of real political power.
Right now we could live in a world where a dozen different groups
maintain Bitcoin implementations that are actually used by miners. We
could have genuine innovation on the p2p networking layer, encryption,
better privacy for SPV clients, better resistance to DoS attacks. We
could have diverse tx acceptance policies rather than wasting hundreds
of man hours bitching about how many bytes OP_RETURN should allow. We
could have voices from multiple groups at the table when the community
discusses how to scale Bitcoin up.
Instead we have a world with a half dozen teams wasting hundreds if not
thousands of of man hours dicking around trying to rewrite consensus
critical *specifications* because they happen to be perfectly good
executable code, and the first thing a programmer thinks when they see
perfectly good battle-hardened code is "Hey! Let's rewrite that from
scratch!"
You know you does have significant political power over the development
of the Bitcoin protocol *other* than the Bitcoin Foundation?
Luke Dashjr.
Because he maintains the Eligius fork of Bitcoin Core that something
like %30 of the hashing power run. It Actually Works because it uses the
Actual Protocol Specification, and miners know if they run it they
aren't going to lose tens of thousands of dollars. It's why it's easy to
get transactiosn mined that don't meet the Bitcoin Core's IsStandard()
rules: they aren't part of the protocol spec, and Luke-Jr has different
views on what transactions should and should not be allowed into the
blockchain.
And when Gavin Andresen starts negotiating with alt-implementations to
get his bloat coin proposals implemented, you know who's going to be at
the table? Luke-Jr again! Oh sure, the likes of btcd, libbitcoin, toshi,
etc. will get invited, but no-one's going to really care what they say.
Because at best only a tiny - and foolish - sliver of hashing power will
be using their implementations of Something Almost But Not Quite
Bitcoin=E2=84=A2, and any sane merchant or exchange will be running at leas=
t one
or two Bitcoin Foundation Genuine Bitcoin Core=E2=84=A2 nodes in front of a=
ny
=66rom-scratch alt-implementation.
So stop wasting your time. Help get the consensus critical code out of
Bitcoin Core and into a stand-alone libconsensus library, wrap it in the
mempool policy, p2p networking code, and whatever else you feel like,
and convince some hashing power to adopt it. Then enjoy the fruits of
your efforts when the next time we decide to soft-fork Bitcoin the
process isn't some secretive IRC discussion by a half-dozen "core
developers" - and one guy who finds the term hilarious - but a full on
DIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW,
complete with twinkle fingers. A pow-wow that you'll be an equal part
of, and your opinions will matter.
Or you can be stereotypical programmers and dick around on github for
the next ten years chasing stupid consensus bugs in code no-one uses.
The choice is yours.
On Sat, Feb 14, 2015 at 03:16:16AM -0800, Eric Voskuil wrote:
> On 02/14/2015 01:51 AM, Jorge Tim=C3=B3n wrote:
> > I agree that this conversation is not being productive anymore. I'm
> > doing my best to understand you but I just happen to disagree with
> > many of your arguments.
> > I doubt it makes you feel better but it's being tedious and
> > frustrating for me as well.
> > I don't know about other people's intentions, but I know that my only
> > intention when recommending libbitcoin to depend on libconsensus is to
> > prevent its direct and indirect users from accidentally being forked
> > off the network due to a consensus failure.
>=20
> If you want to achieve that goal, I would again recommend that a
> standard suite of test vectors be published that other implementations
> can easily consume. Everyone runs the tests and compares results - just
> like deterministic build verification.
--=20
'peter'[:-1]@petertodd.org
00000000000000000e95dcd2476d820f6fd26eb1a9411e961347260342458e9c
--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJU30nrXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMWY0NTgzN2VmYWFjMTA4NTliZDJkODllYjExODI5ZTcz
NWZjYWMyMDZmMTUzYTgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsDPgf+IRnyWm6EHd+LB7bIlFrz+U2r
xbLOyQYcS1U+46cyhLQX134BcSIuF6fyFvqtmUltsfWboHhuedlup8Gpke0/YFKx
YJZSIIN2txkKOFsnAyGDqCUPgwnH1daECIzNvWL/MQYZgq3vPX3R4eHCsWuVuwvB
gE91dl1YZgb2/lRy7z5sRJ4Aj800ydfAg3Eb60F7c38fyqq0TNEcgl8682kg6hZR
bRFp44M2SqnId/R4+LJHe7g01T8Zf1XR98EM4QZwxZ90hna/hjoSVTCVUdZGOa03
XBM7DwwwbGYkkhAz5Yh/rh9qluv70ZvZF9DX1ZpG86cXPSRTI3a6S50bC8IUog==
=lj5j
-----END PGP SIGNATURE-----
--u3/rZRmxL6MmkK24--
|
