From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YN2ao-0003Ju-MD for bitcoin-development@lists.sourceforge.net; Sun, 15 Feb 2015 17:02:50 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.43 as permitted sender) client-ip=62.13.149.43; envelope-from=pete@petertodd.org; helo=outmail149043.authsmtp.co.uk; Received: from outmail149043.authsmtp.co.uk ([62.13.149.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YN2an-0006lJ-6c for bitcoin-development@lists.sourceforge.net; Sun, 15 Feb 2015 17:02:50 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1FH2Yh6065275; Sun, 15 Feb 2015 17:02:34 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 t1FH2TKs063676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 15 Feb 2015 17:02:32 GMT Date: Sun, 15 Feb 2015 12:02:29 -0500 From: Peter Todd To: Tamas Blummer Message-ID: <20150215170228.GB21269@savin.petertodd.org> References: <54D0414F.6030806@voskuil.org> <54DE7601.4070509@voskuil.org> <54DF07A5.1060004@voskuil.org> <54DF2E80.5060506@voskuil.org> <20150214131320.GA26731@savin.petertodd.org> <3D4F2E23-CADE-4FE7-B960-3F79815E868C@bitsofproof.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <3D4F2E23-CADE-4FE7-B960-3F79815E868C@bitsofproof.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 6ea5dc10-b534-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwcUHlAWAgsB AmMbWlNeUF97WmE7 bA9PbARUfEhLXhtr VklWR1pVCwQmRR13 fhx6KVpycQZAf3g+ ZE9rX3YVWhErcBIu Q05JR2gFYXphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOTh0 fR0dBzQzHEsKDw8y MxchK1hUXFkYKQ0I PAlpanYZORUTFgZZ Hkd4YmdiLkUGXCoq RQheXEMYDG8VQDwU C1UmJQVLSiRbQTYQ XA0cE1kXDDheUSNM RWEcOgAA X-Authentic-SMTP: 61633532353630.1023: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: 1YN2an-0006lJ-6c Cc: Bitcoin Dev , libbitcoin@lists.dyne.org Subject: Re: [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: Sun, 15 Feb 2015 17:02:50 -0000 --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 14, 2015 at 03:23:47PM +0100, Tamas Blummer wrote: > Peter, >=20 > You did not address me but libbitcoin. Since our story and your evaluatio= n is probably similar, I chime in. >=20 > On Feb 14, 2015, at 2:13 PM, Peter Todd wrote: >=20 > > So stop wasting your time. Help get the consensus critical code out of > > Bitcoin Core and into a stand-alone libconsensus library, >=20 >=20 > We have seen that the consensus critical code practically extends to Berk= ley DB limits or OpenSSL laxness, therefore > it is inconceivable that a consensus library is not the same as Bitcoin C= ore, less its P2P service rules, wallet and RPC server. Wallet and RPC server are definitely not consensus critical code. P2P service rules are weakly consensus critical, in that a failure to relay valid blocks can in practice cause a loss of consensus. But relaying valid blocks is very easy, and you only need sone relay mechanism out of many to work for consensus to be maintained. OpenSSL is getting replaced by libsecp256k1, a library designed for consensus-critical applications. As for databases, look at the good #bitcoin-wizards discussion yesterday for strategies to make databases less relevant to consensus. > On Feb 14, 2015, at 2:13 PM, Peter Todd wrote: > >=20 > > 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. >=20 >=20 >=20 > The Core code base is unfriendly to feature extensions because of its cri= ticality, legacy design and ancient technology. It is also a commodity > that the ecosystem takes for granted and free.=20 Are you referring to feature extensions to consensus critical code - like my own CHECKLOCKTIMEVERIFY? - or extensions to code that isn't consensus critical? > I honestly admire the core team that works and progresses within these li= mits and perception. >=20 > I am not willing to work within the core=E2=80=99s legacy technology limi= ts. Does it mean I am dicking around? I think not. > It was my way to go down the rabbit hole by re-digging it and I created s= uccessful commercial products on the way. Yes you are dicking around. The effort you're going to spend recreating the core consensus code and getting it right is orders of magnitude more work than figuring out how to use the foreign function interface in your chosen language, or at worse, just running Bitcoin Core to do validation and using RPC or the p2p protocol locally to track that state. Don't assume your prior experience with other commercial projects has any bearing on Bitcoin: consensus-critical crypto is a brand new field within software engineering with very unique requirements, pioneered by Bitcoin itself. --=20 'peter'[:-1]@petertodd.org 00000000000000000a37c901cf2ae6c281f47b237e9bf1d7268fb561b4332345 --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJU4NEcXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxNmI2NDQ0ZTQ2M2M3ZDkyZGExNTc5MzYwYzVmNzFkNGZi ZDNkYWI0NWQxMzk5MGEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfv6Swf9FYLuRiJRMI8pl5FkJ3WPAPQo o4hANgaCmvSw3h4fOWg6Db9XP0b/xNvQepB2HKOPnUd0NlruQ9Q+NS8p5w0ca1nT 9l/F/kDq83Bq5pd6LySvUZ5rmHfjtOdj5suMoteD22qoZs4v0NuBZ2SCoGowVDKO rXOu6oUp7AMqj92BwaTBDKBBxEXDRlqilagWZCdtHq8YYCQeGwlxYu/GhCTOtevr oWUzwXDNRtjaynIvDU1SBlEXYvo0AewyTJ2wF7fsMRxe6TiKx7CWdjlE3DQbOXDT dxCnNavFF0I90DfBH9RGWGOeNHIn+H6JeUZ/VzyvAe1yFLTsBwRmTHiHnqxiUw== =b3NW -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd--