A BIP is a document that presents a proposal for technical, organizational or any other improvement for the development of Bitcoin.

LBIP stands for Bitcoin Improvement Proposal, which in Spanish means Improvement Proposal for Bitcoin. This is a document that contains a proposal or design to improve the structure or functioning of the Bitcoin ecosystem. Whether this is technical or organizational in nature for the community behind the development of Bitcoin. The proposal is accompanied by a clear and concise explanation and justification of the new feature. This is necessary to submit it to approval or not by the community.

To achieve this, community comments are collected and a consensus is sought on the decision to be made. This work is part of the responsibilities of the author, who must also file positions for and against the proposal. Due to the way work is structured within the Bitcoin Core, they store their changes historically. In this way, the original proposal and its different variations will always be available to the rest of the team. An important work characteristic in the midst of such an active, heterogeneous and international development group.

The proposal to create these documents was given by the cryptanarchist developer Amir Taaki, on August 19, 2011. For its design, Taaki was based on the well-known PEP (Python Enhancement Proposals - Python Enhancement Proposals). Later, the structure would be improved by Luke dashjr.

Types of BIP

There are three types of BIP that can be presented, and they are the following:

Monitoring of Standards

Known as Standards TrackThese are used to describe changes that affect most or all Bitcoin implementations. These changes generally include, changes in network protocol, change in block or transaction validity rules, or any other changes or additions that affect the interoperability of applications that use Bitcoin. They are usually highly technical and long-debated BIPs due to their profound implications on the operation of the blockchain. An example of this type is presented in the followed (BIP-141).

Informative

These are used to describe or publicize a Bitcoin design problem, giving guidelines or recommendations for its solution. They are generally the results of private, group or business investigations. They present data, evidence or conceptual studies that support the proposal and its claims. An example of this type is Multi-Sig Transaction Distribution or BIP-10.

Our Process

These describe a process that surrounds Bitcoin, proposing a change or improvement of it. Process BIPs apply to different areas of the Bitcoin protocol. They can propose an implementation, but not directly to the Bitcoin base code. Being more than recommendations, they cannot be ignored like informational BIPs.

Examples of these BIPs include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in the development of Bitcoin. Any meta-BIP is also considered a process BIP. An example of these BIPs can be found in the BIP Classification or BIP-123.

Structuring a BIP

A BIP is structured as follows:

  1. Preamble. This section contains the headings where the BIP metadata is located.
  2. Summary. Here is a brief description (~ 200 words) of the technical problem being addressed.
  3. Copyright. This must be explicitly licensed under the acceptable copyright terms. This license is generally GPL-compliant or lacking.
  4. Specification. This point describes the syntax and semantics of any new features. The specification must be detailed enough to allow competitive and inter-operable implementations for any of the current Bitcoin platforms.
  5. Motivation. This is where the reasons why the proposal was created are clearly explained. It is crucial that this section is clear and clears any doubts about it and its creation.
  6. Justification. The specification rationale describes what motivated the design and why particular design decisions were made.
  7. Backward compatibility. All BIPs that introduce incompatibilities with previous versions must include a section that describes these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities.
  8. Reference implementation. The reference implementation must complete before any BIP has a status of “Final”, but it does not need to be completed before it is accepted. It's best to finish the spec and justification first and come to a consensus on it before writing the code. The final implementation should include the appropriate test code and documentation for the Bitcoin protocol.
  • beep-header-01
  • beep-header-02

Status of a BIP

A BIP has a certain life cycle that depends on its status. At that point we can say that the status of a BIP are as follows:

  1. Draft. At this point, the BIP is barely in its earliest filing state. At this point, the BIP is incomplete.
  2. Deferred. The BIP has been postponed because no progress has been made in its development.
  3. Proposed. It is the proposal accompanied with most of its explanatory elements and presented to the community. At this point, the debate on its application or not within the Bitcoin development ecosystem begins.
  4. Rejected. If the proposal presented is not well received, there are harmful elements or any other reason that the community uses for its rejection, it will be marked with this status.
  5. Retired (Withdraw). This status applies to those proposals that have been withdrawn by their authors for reasons that serve their interest.
  6. Final / Active. To get to this point, the proposal must have gone through community review and consensus. It must have all the necessary spaces and structures for its approval.
  7. Replaced. This status is given to proposals that have been replaced by better proposals. Generally because the new proposals, solve or further improve the previously presented proposal.
  8. Obsolete (Obsolete). This change of status is mainly related when the changes introduced by the BIP are no longer relevant. This can be due to different situations, generally because there are new changes that make its application unnecessary.
BIP-Life-Cycle

BIP and its different representations in other blockchain

There is no doubt that BIPs are a great tool to organize the work and development of Bitcoin. The model was exported from Python, where it has allowed the evolution of this programming language in a very rich way. And the same has happened in other blockchain developments. For example in Ethereum has the known EIP (Ethereum Improvement Proposal) and in Litecoin that LIP (Litecoin Improvement Proposal). Going a little further, in Dash there are DIP (Dash Improvement Proposal) and in TRON there are TIP (TRON Improvement Proposal). Each and every one of these structures base their operation on the basic scheme of the BIP . With some additions as the developers of these blockchains have believed necessary to adapt them to their particular development.

In any case, it is clear that the BIPs have had a profound impact on the way in which the development work of the BIPs is organized and made public. blockchain. In any case, Bitcoin was really cutting-edge in how to solve this part of the work and that, to this day, still continues to be thanks to the quantity and quality of its presentations.

How much do you know, cryptonuta?

Is the BIP structure intended to facilitate the work of Bitcoin authors and developers?

TRUE!

The structure and the way in which the BIPs are managed make it easier for the authors, the community and the developers of Bitcoin to participate, improve and manage each and every one of the proposals and the way in which they are carried out within the development of Bitcoin.

Relevant BIPs in Bitcoin

Some relevant BIPs within the Bitcoin blockchain are the following:

BIP-11: Standard M-of-N Transactions

El BIP-11, is designed to enable secure wallets, escrow transactions, and other use cases where the exchange of funds requires more than a single signature. Presented by Gavin Andresen, on October 18, 2011. This proposal is of the Standards Monitoring type and is in Final status.

BIP-16: Pay to Script Hash

El BIP-16, is a new way of managing Bitcoin payment systems allowing payment data to be included in a QR code to facilitate payments. This BIP was presented by Gavin Andresen, on January 03, 2012. This is another proposal of the Standards Monitoring type and is in Final status.

BIP-141: SegWit

El BIP-141 aims to increase the capacity of the Bitcoin network and also solves the problem of transaction malleability. A soft fork requiring the majority (95%) of miners to complete the upgrade for two weeks.

Segregated Witness (also know as followed) is a blockchain scaling solution. In plain language, SegWit means separating the signatures of the tokens from the transactions.