Author: Milly Bitcoin 2015-06-25 02:34:43
Published on: 2015-06-25T02:34:43+00:00
The discussion revolves around the undefined portion of the BIP process: who should get to vote on approval to commit a BIP implementation into Bitcoin Core? The issue is that there is no coherent plan or process. While there are scattered bits and pieces in different places, the lack of a defined process makes it difficult to move forward with developing some kind of process. From what can be seen, much of the discussion is personality-driven and not based on Computer Science or any defined process. Previously, when people talked about forking the code, the cultish answer was that Bitcoin development is decentralized because people can fork the code. However, when some developers want to fork the code, suddenly it becomes a big problem. The fact that there is so much diverse opinion on this shows a defined process has never been fully vetted or understood. The lead developer does not want to be a "decider" when in fact, he is a very significant decider. While the users have the ultimate choice in a practical sense the chief developer is the "decider." Business investors looking in from the outside will see this as a risk if the broken, unwritten/unspoken process remains, and the incentive for new developers to come in is that they will be paid by companies who want to influence the code and this should be considered. Until one gets passed all the personality-based arguments, defining a real process would be tough. Lack of a defined process leads to high risk and wasted effort.According to Mark Friedenbach, developers become defensive when asked about the process because they have a carefully constructed process that does work well and is well documented. Changes to the non-consensus sections of Bitcoin Core tend to get merged when there are a few reviews, tests, and ACKs from recognized developers, no outstanding objections remain, and the maintainer doing the merge makes a subjective judgment that the code is ready. Consensus-changes, on the other hand, get merged into Bitcoin Core only after the above criteria are met and an extremely long discussion period that has given all the relevant stakeholders a chance to comment, and no significant objections remain. Consensus-code changes are unanimous because they must be. The process of consensus is doing its job at rejecting controversial changes if a contentious change is proposed and not accepted by the process of consensus, which has nothing to do with personality but everything to do with the nature of bitcoin itself. The sort of process that exists in standards bodies, for example, with working groups and formal voting procedures, has no place where changes define the nature and validity of other people's money. Everyone must know and consent to any change made to the rules governing the nature of Bitcoin. So far, this process has been successful in deploying uncontroversial changes such as BIP 66, which will complete deployment soon, and developers intend to repeat this process for more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY.
Updated on: 2023-06-10T00:53:30.406194+00:00