Published on: 2016-03-18T22:52:55+00:00
Dave suggests that the BIP authors should be allowed to decide for themselves which wiki is better instead of arguing. He proposes using Draft-BIP2's provision for authors to specify their own backup wiki as policy in all cases, eliminating the need for a backup wiki altogether. This would allow for greater flexibility and autonomy among authors.In a discussion between Btc Drak and Luke Dashjr about the use of external sources for BIP comments, Luke argues that BIP comments are not part of the BIP itself and can be kept external. Btc Drak objects to using external sources and suggests using the Wiki feature at bitcoin/bips. Luke clarifies that stronger moderation was needed, which is why the BIP process was moved to GitHub. However, he believes that such moderation is unnecessary for BIP comments. The discussion ends without reaching a resolution.Luke suggests that BIP comments should not be linked to external sources like the Bitcoin Wiki but rather made using the Wiki feature at bitcoin/bips itself. External sources are bound to go stale over time. The forum for comments should have a low barrier of use, and the Bitcoin Wiki requires only a request for editing privileges unlike GitHub wiki that would require reading and agreeing to a lengthy Terms of Service contract. The Bitcoin Wiki has been shown to stand the test of time and is less likely to move than the GitHub repository. The BIP process originated on the Wiki and was only moved to GitHub because stronger moderation was needed. Such moderation is unnecessary for BIP Comments. It is suggested that non-reference implementation lists/links be moved to BIP Comments rather than constantly revising the BIPs with them.Mustafa Al-Bassam raises concerns about the adoption of hard-fork BIP by the entire Bitcoin economy. He points out that even if a small minority refuses to accept a hard fork, it can veto the entire process. Another member clarifies that the hardfork can still happen, but for it to move to the final state, deployment needs to be universal. The discussion highlights the importance of unanimous agreement in the Bitcoin ecosystem for hard forks to be successful.In a conversation between Luke Dashjr and Mustafa Al-Bassam, they discuss the wording of a soft-fork that does not become final as long as a hard-fork has potentially-majority support or at most three months. Mustafa raises concerns about the requirement for adoption from the entire Bitcoin economy for a hard-fork BIP. He questions what would happen if one shop owner out of thousands did not adapt to the hard-fork. Luke clarifies that one shop cannot operate in a vacuum and they will soon find themselves no longer selling in exchange for bitcoin payments. The discussion concludes that any hard fork BIPs are unlikely to reach final status.Jorge Timón raises concerns about an attacker preventing a BIP from reaching final status. Mustafa Al-Bassam proposes a definition for when a hard fork becomes active, but Timón points out that an attacker could easily prevent a BIP from becoming final with little time or effort. While there may not be an obvious incentive for such an attack, Timón argues that some people might do it purely for the enjoyment of causing trouble. He suggests that any hard fork BIPs are unlikely to reach final status.Luke Dashjr opens a pull request to move BIP 2 to final status. The current requirement is that "the reference implementation is complete and accepted by the community". Luke intends to apply BIP 2's more specific criteria to itself, which requires rough consensus on the mailing list and addressing all objections. If there are no outstanding objections by April 9th, 2016, the draft BIP will be considered to have reached rough consensus and updated to Final Status.
Updated on: 2023-08-01T17:57:21.303461+00:00