From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 45DEB483 for ; Thu, 23 Jul 2015 00:49:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CA0631BF for ; Thu, 23 Jul 2015 00:49:43 +0000 (UTC) Received: by pachj5 with SMTP id hj5so147038935pac.3 for ; Wed, 22 Jul 2015 17:49:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=/PB8kF06kzCDFBBh2LC7CDRvFH5SQZ6rc+pwnw+P+lk=; b=m1cDacE6gxEWnveTS0mvCEBvHVJ+9HMDRW6U6d3awNXLWVWOX5i2nsQYB18MLARvLD Uk1ICFpKAmrNJfjZLOJKVPrbMig1BapzQGOGRC//OX8I/JoewDSbdcKkkAN8VrblOIuR frsqHSvlpAxvmtc8BTDhCfa/D3BFL1mHvdf3nTVnuZOXbrmHD1IFu93106Ghu6/E6XBF XQYM/fHCFrh/r5Zg3nhli1y4W5COXLnFmTlrOfAKUB5UcyG1WOrvu5gR3ZGsMtUZ7W0v ddc6u+EATK7fXSUiRYdFh87mt6PUqd6fpIpG7UAJHyk4Bwz3yXoVINlsEvEy3v0ceHRj rbnQ== X-Gm-Message-State: ALoCoQkSmyGomocTF3NTIR3bjvHnpljfpCwTwWkdixsBmj3DEac8gPt0JzNekNxJqu4cLajf//94 X-Received: by 10.70.45.225 with SMTP id q1mr12136637pdm.46.1437612583538; Wed, 22 Jul 2015 17:49:43 -0700 (PDT) Received: from [10.0.1.14] (c-67-161-88-20.hsd1.wa.comcast.net. [67.161.88.20]) by smtp.googlemail.com with ESMTPSA id fv5sm5434745pdb.19.2015.07.22.17.49.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 17:49:42 -0700 (PDT) Message-ID: <55B03A32.6050108@voskuil.org> Date: Wed, 22 Jul 2015 17:49:54 -0700 From: Eric Voskuil User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Eric Lombrozo , Cory Fields References: <068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sbikwx22kMXgv84OVfs8wgUKbVxHrjgMX" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 00:49:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Sbikwx22kMXgv84OVfs8wgUKbVxHrjgMX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/22/2015 05:13 PM, Eric Lombrozo via bitcoin-dev wrote: > Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test... We (libbitcoin) have taken the time to publish and maintain bitcoind's "libbitcoinconsensus" source files as an independent C++ library (with Java and Python bindings). https://en.bitcoin.it/wiki/Libbitcoin_Consensus It can be easily verified against bitcoind sources and in builds of libbitcoin-blockchain it can be swapped out for libbitcoin's native consensus checks. https://en.bitcoin.it/wiki/Libbitcoin_Blockchain#Consensus_Validation So there is really no reason to consider the original client synonymous with consensus. I initially argued for this library to be natively isolated from bitcoind, but that didn't seem to be in the cards so we did it independently. In any case I agree with your stated need for this isolation (if not the means) for the reasons you state. The community needs to move beyond a largely singular and monolithic codebase that is holding that position in part due to fear about consensus bug forks. To make choice regarding consensus an actual choice (and thereby actual consensus) the modularity you suggest is essential. One must be able to take new developments without having to take consensus changes. The option to fork the codebase is not reasonable for most people. At this point there is no defensible reason for coupling consensus checks with other features. e --Sbikwx22kMXgv84OVfs8wgUKbVxHrjgMX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVsDoyAAoJEDzYwH8LXOFO6mYH/3uRxMXA/tggRBSH3ADRn6GK 7SyJgc+x+cLwBAkaPTOnpoxddeleE9/OcIb5yJD40HhTF3OwEKRRcOz3BWRXXkxA igYhXH5pIGKRx/A64Dx8jhk/EE4EEBKu2+f2A02wp8UD/5cw/7sokhvijxYXhVzG aYMq5FsLwX+Bnei0Z0IY8mmp57nYugElTNZqrKCc5I4trbuw23GdKLxkV15aCwqo Scb9nJYexnuV1AQcGbbpOdmaZg/2Q78myh8iMmqZRpwW0USjUAndnkRPZG9yzX/7 0V9aiiWQvaJMETg1yXpByiduBcbd2f3K/HQ7w8dQJvcSUp8N6OZDdmGSlpHpVMA= =5j+F -----END PGP SIGNATURE----- --Sbikwx22kMXgv84OVfs8wgUKbVxHrjgMX--