From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XmX1J-0005x9-L8 for bitcoin-development@lists.sourceforge.net; Fri, 07 Nov 2014 00:03:17 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XmX1H-0008OU-Nm for bitcoin-development@lists.sourceforge.net; Fri, 07 Nov 2014 00:03:17 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA7039mG048992; Fri, 7 Nov 2014 00:03:09 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 sA7035is075490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 7 Nov 2014 00:03:08 GMT Date: Thu, 6 Nov 2014 19:03:10 -0500 From: Peter Todd To: Justus Ranvier Message-ID: <20141107000310.GA6532@savin.petertodd.org> References: <20141106213215.GA12918@savin.petertodd.org> <545BF0C2.3030201@bluematt.me> <545BFAD6.1000504@riseup.net> <20141106232649.GD26859@savin.petertodd.org> <545C0617.7020300@riseup.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <545C0617.7020300@riseup.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 74c2eb8c-6611-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgUUFloCAgsB AmIbW1ReUF57WWs7 bA9PbARUfEhLXhtr VklWR1pVCwQmQm0G Bh0bC1pycABCcX4+ ZEBnVnEVW0ApdxMv Sh1JE2sHZHphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDIj4x DxwDEzsuFlABWzR7 KBJuNUQdAEcXPQ05 Nl06VFQDLgRwQgZE Hl1MCyZdb1IGSyd5 RR9aUAYlMRJ9aBx8 NSYJBDBsL3RYRyUw 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: 1XmX1H-0008OU-Nm Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug 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: Fri, 07 Nov 2014 00:03:17 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 06, 2014 at 05:36:55PM -0600, Justus Ranvier wrote: > This explanation is completely incoherent. >=20 > Because Bitcoin has a extra consensus requirements, requirements which > are really rare in engineering, the necessity of fixing bugs is even > greater. >=20 > There are two general ways to fix bugs: either as part of a > controlled, planned, and managed process, or as a response to an > immediate disaster. >=20 > The alternative to scheduling and planning the upgrades which are > necessary to fix the bugs in the protocol, where such fixes can be > written, tested, and documented at leisure, is to wait for some crisis > and slap on another bandaid when the network breaks again (like it did > March of last year). The protocol is what the protocol is; the bugs are when you don't match the protocol. > Who benefits from not fixing bugs in Bitcoin? We can bring up politics if you want. In the current model, the specification *is* the protocol, and the Bitcoin Core team is scared to death of changing anything; they've got very little real power. Soft-forks are the minimum-viable way of making changes to the protocol, and it's very clear how they get adopted: minerr consensus. They're also a fundemental way of changing the protocol that is impossible to prevent, so you might as well use it. Hard-forks require political consensus to achieve, and the way you create that political consensus is by creating committes, groups, associations... Foundations. Every last one of those things requires centralization and political power. You know, the smartest thing the Bitcoin Foundation could do if they wanted to cement their place in the Bitcoin ecosystem as a power broker would be to setup a program of periodic hard-forks, say every year or two, and then manage the committees that decide what goes into those hard-forks. That they haven't suggested that yet is a sign that they're either not evil, or they don't understand Bitcoin very well. I think programmers find this reality hard to accept, because they're mostly interested in writing code that'll get widely used. To them it's hard to accept that the Bitcoin protocol *is* a few thousand lines of C++ code, and they're not good enough to write their own implementation and make it match; if we replaced programmers with writers we might get the equally bizzare and pointless situation of people taking perfectly good RFCs and rewriting them in their own words. If you do care about keeping the politics of Bitcoin development free =66rom centralized control you should do what I advised the Dark Wallet team to do a year ago: fork Bitcoin Core and change the non-consensus-critical code that implements policy. I've done this myself in a minor way with my replace-by-fee(1) version. Luke-Jr has also done this with his Eligius branch, a fork that something like 30% of the Bitcoin hashing power appear to run. (Discus Fish has been mining non-standard transactions(2) lately) Multiple *forks* of the Bitcoin Core reference client that are actually getting used by miners and other users ensures that no one group maintaining such a fork has the ability to change anything without strong consensus. Forking the codebase, rather than rewriting it, best ensures that your code actually implements the protocol properly, is safe to use for mining, and actually gets used. Rewriting Bitcoin Core is a fun project, but it's terrible politics. 1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.3 2) https://blockchain.info/tx/e24a4085c54a6362e615f8eab758c12d80e488b73757e= 6d2b8ab6bfc8be7007e --=20 'peter'[:-1]@petertodd.org 000000000000000008f2290924a6882928d4566f487f33cc57203a6535795201 --UugvWAfsgieZRqgk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUXAw6XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxNDk1N2U5ZTIyNjQzMjA5NTcxZDdlMDUxOWYwNDkxZDg1 NjE0ZjM2NDRjNmVmZjYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfstYwgAp6Vyjs7wq3o44q+/RxGlGBny 1FXdFvu9xqJjI/Es6WcVmRo56yAxt9TvRjdYEACQDDZsWYD6cbgX9ikWr6Eu1rRY dECgOq6rssBpvQBLVpQ4q20ec8dHBjNex2Qc0N4RgR1ZgGDjyJYykSRYqr7HZMrf wOhKl3d01N2tSQ7zamXUZXwkPKofPzekTeie2qo9K8/F3TT5X18VAeDf+Sxk6WwZ 0hVrhTVoSlCl5aiLxp1WUH1mPpKAV5Dj6xIl7IsR1h4j+x2xQ2ybzbavo4iRm2TO FTawpgGi+HupveDK9k7MnC7duM+Dg/qFLcjBle4y63fyYRzKxD0qSlKZiwKl7Q== =U406 -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk--