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; 
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)
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?)
Precedence: list


--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--