diff options
| author | Peter Todd <pete@petertodd.org> | 2014-11-06 19:03:10 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-11-07 00:03:17 +0000 |
| commit | d6303e07ab0fbc10a2f670ccac400a23deef57c3 (patch) | |
| tree | c5f58ab24442c29cbb91e74d7d9260a66c785d6f /14 | |
| parent | 8ee43feca0d0fabcae9a216924c0fc2fb89bcf62 (diff) | |
| download | pi-bitcoindev-d6303e07ab0fbc10a2f670ccac400a23deef57c3.tar.gz pi-bitcoindev-d6303e07ab0fbc10a2f670ccac400a23deef57c3.zip | |
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Diffstat (limited to '14')
| -rw-r--r-- | 14/97c7c6c476ca3022ceb9e62ed17f5fa40afa8c | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/14/97c7c6c476ca3022ceb9e62ed17f5fa40afa8c b/14/97c7c6c476ca3022ceb9e62ed17f5fa40afa8c new file mode 100644 index 000000000..e8b7c9819 --- /dev/null +++ b/14/97c7c6c476ca3022ceb9e62ed17f5fa40afa8c @@ -0,0 +1,181 @@ +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 <pete@petertodd.org>) 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 <pete@petertodd.org> +To: Justus Ranvier <justusranvier@riseup.net> +Message-ID: <20141107000310.GA6532@savin.petertodd.org> +References: <20141106213215.GA12918@savin.petertodd.org> + <A53D2C60-1D6A-4796-9776-3AF396BEC9F1@bitsofproof.com> + <545BF0C2.3030201@bluematt.me> + <CAJHLa0NTj6m4JpHx3+nWtYVV1Zpwf-FaxiyFX9DR821cQYVqsg@mail.gmail.com> + <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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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-- + + |