BIPs bitcoin improvement proposals

43 - Purpose Field for Deterministic Wallets

BIP: 43 Layer: Applications Title: Purpose Field for Deterministic Wallets Author: Marek Palatinus Pavol Rusnak Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0043 Status: Final Type: Informational Created: 2014-04-24 ==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. ==Purpose== We propose the first level of BIP32 tree structure to be...

44 - Multi-Account Hierarchy for Deterministic Wallets

BIP: 44 Layer: Applications Title: Multi-Account Hierarchy for Deterministic Wallets Author: Marek Palatinus Pavol Rusnak 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 ==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: m / purpose' / coin_type' / account' / change / address_index Apostrophe in the path indicates that BIP32 hardened derivation is used. Each level has a sp...

39 - Mnemonic code for generating deterministic keys

BIP: 39 Layer: Applications Title: Mnemonic code for generating deterministic keys Author: Marek Palatinus Pavol Rusnak Aaron Voisine Sean Bowe 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 ==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 a wallet seed. The sentence could be written on paper or spoken over the telephone. This guide is meant to be...

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...

50 - March 2013 Chain Fork Post-Mortem

BIP: 50 Title: March 2013 Chain Fork Post-Mortem Author: Gavin Andresen 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 ==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 would also reject the larger block. Thi...

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 ...