On Thu, Nov 06, 2014 at 05:36:55PM -0600, Justus Ranvier wrote: > This explanation is completely incoherent. > > Because Bitcoin has a extra consensus requirements, requirements which > are really rare in engineering, the necessity of fixing bugs is even > greater. > > 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. > > 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 from 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/e24a4085c54a6362e615f8eab758c12d80e488b73757e6d2b8ab6bfc8be7007e -- 'peter'[:-1]@petertodd.org 000000000000000008f2290924a6882928d4566f487f33cc57203a6535795201
signature.asc
Description: Digital signature
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
