Comparison Of Two Bitcoin Improvement Proposals
Bitcoin was improved many times in its history. This process can start in different ways: after an inspiring post on the forum, after some errors are disclosed by accident, or if the community of developers comes up with a bright idea. Later on, all proposals will be discussed and their efficiency will be estimated. Some ideas may be accepted from the very beginning, while others may be rejected. The destiny of all useless ideas is simple as that — they get abandoned as a dead weight in the forum topics.
Meanwhile, the accepted proposals go the other way — the way of adaptation and application. They all are put in a special place to be formally described before they get implemented. This place is the BIP collection page on GitHub. All proposals mature enough to be seriously discussed before their implementation once were there. Some of them were abandoned because of bad formatting, others are still discussed, yet others are implemented and given a corresponding status.
The first two proposals have a special place in the BIPs list. They are intended to define the concept of BIPs and their properties. The reasoning is simple: you can’t ask people to propose their ideas in a strict format without defining the format itself.
The first proposal was presented on September 19, 2011. According to the changelog, it has two major changes in terms of submission process clarification (October 10, 2015) and regarding community issues (January 1, 2016). On February 3, 2016, BIP1 was replaced by BIP2. There were plenty of changes implemented, including:
- Licensing approach was clarified. Some licences were explained as inappropriate;
- Comments, status changes, and a layer field were added;
- Authors details requirements were changed;
- Some formatting, attached files, and linking issues were considered.
As it is stated in BIP 1, “This document was derived heavily from Python's PEP-0001”. Such an approach is common among open source projects. If something is free-to-use and seems adequate enough, you can take it and adapt for your own purposes.
Since the second proposal substitutes the first one, it may be interesting to compare them. Such a comparison is worth attention because it shows the connection between BIP1 and BIP2 and contains mutual references. For convenience, let’s first describe header keywords and then move on to their content. All key positions are presented in the following table.
There are several common fields with data inside: “BIP”, “Title”, “Author”, “Comments-Summary”, “Comments-URI”, “Status”, “Type”, and “Created”. Meanwhile, the fields including different data seem way more interesting: “License”, “Replaces”, and “Superseded-By”. As we mentioned earlier, BIP2 brought some licensing changes. Here we see that these changes also affect the title — this is proven by the added “License” field in BIP2.
Two more fields are referencing each other in a way. BIP1 contains information about its substitute, while BIP2, vice versa, contains data on what it replaces (“Superseded-By” and “Replaces” fields). Referencing each other, BIPs create a traceable chain of ideas with a clear sequence. This allows searching for a previous version and analyzing it if necessarily.
Each proposal is valuable by itself but the sequence of connected proposals plays an equally important role. It shows the way things should be done. Changes in the fields are as important as the substitution of general details. The BIP body contains a wealth of data on this topic. We will talk about them next time.