Author: Pindar Wong 2015-06-25 06:27:37
Published on: 2015-06-25T06:27:37+00:00
On June 24, 2015, Raystonn initiated a discussion on an undefined or unwritten portion of the BIP process. The question was who should get to vote on approval to commit a BIP implementation into Bitcoin Core and whether a simple majority of these voters is sufficient for approval or not. In response, Mark Friedenbach explained that consensus-changes in Bitcoin Core are merged only after 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 and must be so because they define the nature and validity of other people's money. On the same day, Milly Bitcoin expressed her opinion on this matter and questioned the lack of a defined process in Bitcoin development. She stated that most developers become defensive and give vague one-sentence answers when asked about the process for establishing a new testnet. She also suggested that personality-driven discussions are not based on computer science or any defined process, which creates a broken, unwritten/unspoken process. Developers see it as a threat to their authority/position if anyone brings up the discussion of how to move forward in some fashion, and everyone has to run software with the same consensus rules. She noted that 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.Warren Togami Jr. provided information on creating an entirely separate testnet network called "testnet4" by changing all the testnet chain parameters, such as port numbers, pchMessageStart magic, and block sizes. Rusty used this to test block propagation latency.Jeff Garzik replied to Milly's statement and requested to refrain from feeding the troll. He explained that Bitcoin development is decentralized because people can fork the code. He also mentioned that consensus must be unanimous, and there is a carefully constructed process that works 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, there are no outstanding objections, and the maintainer doing the merge makes a subjective judgment that the code is ready. In conclusion, while there seems to be some disagreement about the lack of a defined process in Bitcoin development, there is an established process for merging consensus-code changes into Bitcoin Core. The protocol's decentralized nature and the possibility of forking the code allow for multiple approaches to software development, which can lead to disagreements among developers.
Updated on: 2023-06-10T00:47:28.078684+00:00