60 - Fixed Length "version" Message (Relay-Transactions Field)
BIP: 60 Layer: Peer Services Title: Fixed Length "version" Message (Relay-Transactions Field) Author: Amir Taaki Comments-Summary: Discouraged for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0060 Status: Draft Type: Standards Track Created: 2013-06-16 License: PD ==Abstract== [[BIP 0037]] introduced a new flag to version messages which says whether to relay new transaction messages to that node. The protocol version was upgraded to 70001, and the (now accepted) BIP 0037 became implemented. The implementation is problematic because the RelayTransactions flag is an optional part of the version message stream. ==Motivation== One property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one. As an example, the length of version messages might be checked to ensure...
33 - Stratized Nodes
BIP: 33 Layer: Peer Services Title: Stratized Nodes Author: Amir Taaki Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0033 Status: Rejected Type: Standards Track Created: 2012-05-15 == Abstract == As the Bitcoin network scales, roles are fast becoming specialised. In the beginning, a single Bitcoin user would perform the synonymous roles of miner, merchant and end-user. With the growth however of this system, these functions are being abstracted away to specialised services as a natural part of Bitcoin's growth. Bitcoin's blockchain becomes more unwieldy for end users over time, negatively affecting the usability of Bitcoin clients. As it grows, it becomes ever more impractical to deal with on portable devices or low end machines. Several proposals have been put forward to deal with this such as lightweight (headers-only) clients and skipping validation for blocks before the last checkpoint. However these measures ar...
1 - BIP Purpose and Guidelines
BIP: 1 Title: BIP Purpose and Guidelines Author: Amir Taaki Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001 Status: Replaced Type: Process Created: 2011-09-19 Superseded-By: 2 ==What is a BIP?== BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature p...
15 - Aliases
BIP: 15 Layer: Applications Title: Aliases Author: Amir Taaki Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0015 Status: Deferred Type: Standards Track Created: 2011-12-10 [[bip-0070.mediawiki|BIP 0070]] (payment protocol) may be seen as the alternative to Aliases. Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist. This document aims to layout through careful argument, a bitcoin alias system. This is a big modification to the protocol that is not easily changed in the future and has big ramifications. There is impetus in getting it correct the first time. Aliases have to be robust and secure. == Schemes == Here are a few different proposals and the pro...
14 - Protocol Version and User Agent
BIP: 14 Layer: Peer Services Title: Protocol Version and User Agent Author: Amir Taaki Patrick Strateman Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0014 Status: Final Type: Standards Track Created: 2011-11-10 Post-History: 2011-11-02 In this document, bitcoin will be used to refer to the protocol while Satoshi will refer to the current client in order to prevent confusion. == Past Situation == Bitcoin as a protocol began life with the Satoshi client. Now that the community is diversifying, a number of alternative clients with their own codebases written in a variety of languages (Java, Python, Javascript, C++) are rapidly developing their own feature-sets. Embedded in the protocol is a version number. Primarily this version number is in the "version" and "getblocks" messages, but is also in the "block" message to indicate the software version that created that block. Currently this version number is t...
123 - BIP Classification
BIP: 123 Title: BIP Classification Author: Eric Lombrozo Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0123 Status: Active Type: Process Created: 2015-08-26 License: CC0-1.0 GNU-All-Permissive ==Abstract== This document describes a classification scheme for BIPs. BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. ==Copyright== This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. ==Motivation== Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them. In order to have a BIP process which more closely ...