Author: odinn 2015-07-01 22:34:01
Published on: 2015-07-01T22:34:01+00:00
The discussion on Bitcoin-dev mailing list is about the process of hard forks and soft forks in Bitcoin. The email thread starts with a suggestion that the hard fork issue has become too much of a distraction for people trying to maintain the nuts and bolts of the underlying system, so some kind of process needs to be developed. The suggestion is to have regularly scheduled hard forks planned, which would have cut off dates for hard-fork BIP submissions. This way, debates over whether there should be hard forks and what should be contained within them could be avoided. Tier Nolan, a participant in the discussion, explains that there is no process for handling hard forks, which aren't bug fixes, but soft forks have a defined process. He explains the soft fork process as: BIP proposal + discussion - Proposed code - Dev acceptance - Release - Miner vote/acceptance. The devs have a weak veto, and if they refuse to move forward with changes, miners could perform a soft fork on their own. The miner veto is stronger (for soft forks) but not absolute. However, when it comes to hard forks, the "checks and balances" of weak vetoes are not present. This means that things can devolve from consensus to mutual veto, and consensus ceases to be a goal and becomes a requirement. The fundamental problem is that there isn't agreement on what the block size is. The email thread also discusses the issue of users expecting changes/improvements that would require a hard fork, so the responsibility should be taken off the shoulders of the core maintainer. The process should follow the BIP process as closely as possible, possibly adding another step after "Dev acceptance" to include input from others such as merchants/exchanges/miners/users. It will only be an approximation of "decentralization," and the process won't be perfect, but if you want to move forward, then you need some way to do it.
Updated on: 2023-06-10T00:49:51.753278+00:00