On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank <raph...@gmail.com> wrote: > Has this been considered? > > If made sufficiently general, older clients could support any > extension of the rules. > > Various "hard" parameters within the protocol are defined in main.h of > the official client. > > In BIP-34, there is a suggested way to make changes, based on consensus. > https://en.bitcoin.it/wiki/BIP_0034
You misunderstand what BIP_0034 is doing— it's not gauging consensus, it's making sure that the change is safe to enforce. This is a subtle but important difference. The mechanism happens to be the same, but we're not asking for anyone's approval there— the change is needed to make Bitcoin as secure as people previously believed it to be, there have been no serious alternatives tendered. As far as I can tell the proposal has always had universal agreement from anyone who's thought about it. The only open question was if it was safe to deploy, and thats what that process solves. Bitcoin is not a democracy— it quite intentionally uses the consensus mechanism _only_ the one thing that nodes can not autonomously and interdependently validate (the ordering of transactions). This protects the users of Bitcoin by making most of the system largely nonvolatile "constitutional" rules instead of being controlled by popular whim where 'two wolves may vote to have the one sheep for dinner'. If it were possible to run the whole thing autonomously it would be, but alas... Even if you accept the premise that voting is a just way of making decisions (it isn't; it's just often the least unjust when something must be done), mining is not a particularly just way of voting: 'Hashpower isn't people', and currently the authority to control the majority of the hashpower is vested in a only a half dozen people. Moreover, the incentives to abuse hashpower are sharply curtailed by its limited authority (all one can do with it is reorder transactions... which is powerful but still finite) and allowing arbitrary rule changes would vastly increase that power. There are some more subtle issues— if the acceptance of chain B depends on if you've seen orthogonal chains A or A' first then there can be a carefully timed announcement of A and A' which forever prevents global convergence (thanks to a finite speed of light an attacker can make sure some nodes see A first, some A'). If a rule change can be reorged out, then it's not really a rule— any actual rule prohibits otherwise valid blocks that violate it (and without this distinction you might as well implement the 'rule' as miner preferences). Additionally there is the very hard software engineering QA problem for a sufficiently complex rule language— script isn't turing complete and look at all the issues it has had. In summary— this sort of thing, which has come up before, is technically interesting and fun to think about but it would make for substantial engineering challenges and would not be obviously compatible with the economic motivations which make Bitcoin secure nor would it be morally compatible with the social contract embedded in the system today. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
