On 11/06/2014 04:11 PM, Jeff Garzik wrote: > RE soft fork vs. hard fork: It's about this time at Mike Hearn will > chime in, on the side of hard forks. Hard forks are in a sense much > cleaner, and permit solving problems not otherwise solvable with a > hard fork. However, hard forks clearly have risks, notably the Big > Risk akin to a US Constitutional Convention: once you open the door, > anything can happen, any rule no matter how "sacred" can be changed.
Yes, there are risks, but those risks could be managed with appropriate effort. Major players could publicly commit to a set of ground rules vis a vis what categories of changes are and are not acceptable. Maybe at some point there could even be something that resembles project management for the Bitcoin protocol. Why not schedule protocol upgrades every two years for the foreseeable future? Spend one year achieving broad consensus regarding what changes to make in the next upgrade, then spend one year in feature freeze (all future proposals postponed for the next cycle) then execute the upgrade. The top priority should be fixing bugs that make specifying and re-implementing the protocol nearly impossible. Those kinds of changes should have little difficulty achieving near-unanimous consensus. There shouldn't be any problems separating obviously-needed changes from the ones that let third parties blacklist coins, or a majority of miners vote to confiscate block rewards from minority, tamper with the issuance schedule, etc. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
0x38450DB5.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
