From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Eric Voskuil Message-ID: <20150214131320.GA26731@savin.petertodd.org> References: <54CC0E1D.7030409@voskuil.org> <54D0414F.6030806@voskuil.org> <54DE7601.4070509@voskuil.org> <54DF07A5.1060004@voskuil.org> <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 , libbitcoin mailing list 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--