BIPs bitcoin improvement proposals

43 - Purpose Field for Deterministic Wallets

<pre> BIP: 43 Layer: Applications Title: Purpose Field for Deterministic Wallets Author: Marek Palatinus <slush@satoshilabs.com> Pavol Rusnak <stick@satoshilabs.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0043 Status: Final Type: Informational Created: 2014-04-24 </pre> ==Abstract== This BIP introduces a "Purpose Field" for use in deterministic wallets based on algorithm described in BIP-0032 (BIP32 from now on). ==Motivation== Although Hierarchical Deterministic Wallet structure as described by BIP32 is an important step in user experience and security of the cryptocoin wallets, the BIP32 specification offers implementors too many degrees of freedom. Multiple implementations may claim they are BIP32 compatible, but in fact they can produce wallets with different logical structures making them non-interoperable. This situation unfortunately renders "BIP32 compatible" statement rather useless. ...

44 - Multi-Account Hierarchy for Deterministic Wallets

<pre> BIP: 44 Layer: Applications Title: Multi-Account Hierarchy for Deterministic Wallets Author: Marek Palatinus <slush@satoshilabs.com> Pavol Rusnak <stick@satoshilabs.com> Comments-Summary: Mixed review (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0044 Status: Proposed Type: Standards Track Created: 2014-04-24 </pre> ==Abstract== This BIP defines a logical hierarchy for deterministic wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43. ==Motivation== The hierarchy proposed in this paper is quite comprehensive. It allows the handling of multiple coins, multiple accounts, external and internal chains per account and millions of addresses per chain. ==Path levels== We define the following 5 levels in BIP32 path: <pre> m / purpose' / coin_type' / account' / change / address_index </pre> Apost...

39 - Mnemonic code for generating deterministic keys

<pre> BIP: 39 Layer: Applications Title: Mnemonic code for generating deterministic keys Author: Marek Palatinus <slush@satoshilabs.com> Pavol Rusnak <stick@satoshilabs.com> Aaron Voisine <voisine@gmail.com> Sean Bowe <ewillbefull@gmail.com> Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039 Status: Proposed Type: Standards Track Created: 2013-09-10 </pre> ==Abstract== This BIP describes the implementation of a mnemonic code or mnemonic sentence -- a group of easy to remember words -- for the generation of deterministic wallets. It consists of two parts: generating the mnemonic and converting it into a binary seed. This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods. ==Motivation== A mnemonic code or sentence is superior for human interaction compared to the handling of raw binary or hexadecimal representations of...

33 - Stratized Nodes

<pre> BIP: 33 Layer: Peer Services Title: Stratized Nodes Author: Amir Taaki <genjix@riseup.net> 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 </pre> == 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 c...

50 - March 2013 Chain Fork Post-Mortem

<pre> BIP: 50 Title: March 2013 Chain Fork Post-Mortem Author: Gavin Andresen <gavinandresen@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0050 Status: Final Type: Informational Created: 2013-03-20 License: PD </pre> ==What went wrong== A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chain in total work, forcing 0.8 nodes to reorganise to the pre-0.8 chain). In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools...

123 - BIP Classification

<pre> BIP: 123 Title: BIP Classification Author: Eric Lombrozo <elombrozo@gmail.com> 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 </pre> ==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. ...