BIPs bitcoin improvement proposals

47 - Reusable Payment Codes for Hierarchical Deterministic Wallets

RECENT CHANGES: * (19 Apr 2016) Define version 2 payment codes * (17 Apr 2016) Clarify usage of outpoints in notification transactions * (18 Dec 2015) Update explanations to resolve FAQs <pre> BIP: 47 Layer: Applications Title: Reusable Payment Codes for Hierarchical Deterministic Wallets Author: Justus Ranvier <justus@openbitcoinprivacyproject.org> Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047 Status: Draft Type: Informational Created: 2015-04-24 </pre> ==Abstract== This BIP defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse. This BIP is a particular application of BIP43 and is intended to supplement HD wallets which implement BIP44. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMM...

81 - Hierarchy for Colored Voting Pool Deterministic Multisig Wallets

<pre> BIP: 81 Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets Author: Justus Ranvier <justus@opentransactions.org> Jimmy Song <jimmy@monetas.net> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0081 Status: Deferred Type: Informational Created: 2014-08-11 License: PD </pre> ==Abstract== This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig 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 and is based on BIP44. ==Motivation== The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed. ==Path levels== We define the following 8 levels in BIP32 path: <pre> m / purpose' / series' / (5 color definition levels) / address_index </pre> Apostrophe in the path indicates that BI...

80 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets

<pre> BIP: 80 Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets Author: Justus Ranvier <justus@opentransactions.org> Jimmy Song <jimmy@monetas.net> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0080 Status: Deferred Type: Informational Created: 2014-08-11 License: PD </pre> ==Abstract== This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig 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 and is based on BIP44. ==Motivation== The hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed. ==Path levels== We define the following 4 levels in BIP32 path: <pre> m / purpose' / coin_type' / series' / address_index </pre> Apostrophe in the path indicates that BIP32 ha...

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