HD钱包详解:Part 2——BIP32注解

2019-01-25
摘要:本文将介绍BIP32协议。

点击蓝字,轻松关注

公众号回复“1”,拉你进区块链技术讨论微信群

作者:程一帆

来源:旺链科技

本文有英文段,阅读(观看)可能需要60分钟+

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。



简介:本文将介绍BIP32协议。考虑到BIP32对密钥生成算法的描述已经非常简单优美,另写文章介绍也不能做到更好,但是原协议中确实有一些内容在初读之下不容易理解。经过再三考虑,我决定采用注释的形式将原文中难读难懂之处一一注解,希望能够对读者更方便地理解BIP32协议做一点微小的贡献。注释用粗体,其余为BIP32协议原文。

RECENT CHANGES:

  • (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage)

  • (30 Apr 2013) Switched from multiplication by IL to addition of IL (faster, easier implementation)

  • (25 May 2013) Added test vectors

  • (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions.

  • (24 Feb 2017) Added test vectors for hardened derivation with leading zeros

  BIP: 32
  Layer: Applications
  Title: Hierarchical Deterministic Wallets
  Author: Pieter WuilleComments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0032
  Status: Final
  Type: Informational
  Created: 2012-02-11
  License: BSD-2-Clause
Abstract

This document describes hierarchical deterministic wallets (or “HD Wallets”): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.

The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients.

The specification consists of two parts. In the first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.

Copyright

This BIP is licensed under the 2-clause BSD license.

Motivation

The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such “neutered” wallets lose the power to generate public keys as well.

Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits, for example, a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).

However, deterministic wallets typically consist of a single “chain” of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant’s wallet; only to those addresses which are used to receive customer’s payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root.

Specification: Key derivation

=Conventions=

In the rest of this text we will assume the public key cryptography used in Bitcoin, namely elliptic curve cryptography using the field and curve parameters defined by secp256k1 (https://www.secg.org/sec2-v2.pdf). Variables below are either:

  • Integers modulo the order of the curve (referred to as n).

  • Coordinates of points on the curve.

  • Byte sequences.

Addition (+) of two coordinate pair is defined as application of the EC group operation.
这里的加法是我们之前介绍过的椭圆曲线的加法,素数域上的椭圆曲线点集对于加法构成一个阿贝尔群

Concatenation (||) is the operation of appending one byte sequence onto another.

As standard conversion functions, we assume:
下面定义了几个转换函数

  • point(p): returns the coordinate pair resulting from EC point multiplication (repeated application of the EC group operation) of the secp256k1 base point with the integer p.
    这里的p是一个整数,返回的函数值是pG的坐标对,其中G是我们之前介绍过的secp256k1中的基点,乘法是加法的重复运算

  • ser32(i): serialize a 32-bit unsigned integer i as a 4-byte sequence, most significant byte first.
    这个函数将一个32位的无符号位整数i序列化为一个4字节的序列,采用了大端规则

  • ser256(p): serializes the integer p as a 32-byte sequence, most significant byte first.
    将长度为256位的整数p序列化为一个32字节的序列,大端规则

  • serP(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1’s compressed form: (0x02 or 0x03) || ser256(x), where the essay-header byte depends on the parity of the omitted y coordinate.
    与之前不同的是,这个函数序列化的对象是一个椭圆曲线上的点的坐标对P=(x,y),其中x和y都是256位的整数。我们知道由于椭圆曲线是上下对称的,所以每个坐标x都对应了两个关于x轴对称的点。为了用更少的字节表示P,在SEC1中规定了压缩格式:如果y是偶数,则在ser256(x)前增加前缀字节Ox03;如果y是奇数,则增加前缀Ox03.需要说明的是,在模素数p的运算中,y的两个可能取值的奇偶性总是相反的。因此,函数serP(P)返回的压缩坐标字节长度为33,相较未压缩的坐标(占用64字节),节省了近一半的空间

  • parse256(p): interprets a 32-byte sequence as a 256-bit number, most significant byte first.
    将一个32字节的序列解析为一个256位的数,大端规则

=Extended keys=

In what follows, we will define a function that derives a number of child keys from a parent key. In order to prevent these from depending solely on the key itself, we extend both private and public keys first with an extra 256 bits of entropy. This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes.

We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = point(k) and c the chain code.

Each extended key has 231 normal child keys, and 231 hardened child keys. Each of these child keys has an index. The normal child keys use indices 0 through 231-1. The hardened child keys use indices 231 through 232-1. To ease notation for hardened key indices, a number iH represents i+231.
HD钱包要从父密钥推导出子密钥,为了避免子密钥只依赖于父密钥,HD钱包为每个密钥增加了一个256位的随机数,也就是所谓的扩展密钥,这个随机数称为链码,对于一个密钥对,公钥和私钥对应的链码是相同的
每个子密钥对应一个序号,根据序号是否小于231,又可分为普通子密钥和硬化子密钥

=Child key derivation (CKD) functions=

Given a parent extended key and an index i, it is possible to compute the corresponding child extended key. The algorithm to do so depends on whether the child is a hardened key or not (or, equivalently, whether i ≥ 231), and whether we’re talking about private or public keys.
由于密钥可分为私钥和公钥,字密钥又可分为普通子密钥和硬化子密钥,因此不同的扩展密钥和不同的序号也就决定了不同的推导算法。需要指出的是,我们可以从父私钥推导出子私钥或子公钥,也可以从父公钥推导出子公钥,但是绝不可能从父公钥推导出子私钥,显然这意味者私钥的暴露

==Private parent key → private child key==

The function CKDpriv((kpar, cpar), i) → (ki, ci) computes a child extended private key from the parent extended private key:
这里(kpar, cpar)是扩展父私钥,其中kpar是父私钥, cpar是链码; i是子密钥序号,(ki, ci)是对应的第i个扩展子私钥

  • Check whether i ≥ 231 (whether the child is a hardened key).
    If so (hardened child): let I = HMAC-SHA512(Key = cpar, Data = 0x00 || ser256(kpar) || ser32(i)). (Note: The 0x00 pads the private key to make it 33 bytes long.) If not (normal child): let I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar)) || ser32(i)).
    这里的HMAC是一种基于哈希函数的特殊的消息验证码(MAC),它可以和不同的哈希函数结合起来组合成不同的HMAC算法,也就是说SHA512可以被其他的哈希函数,如SHA-3,MD-5, RIPEMD等等代替。当然,在当前的算法中,我们要求这个哈希函数的输入是512位的。HMAC的输入参数包含两个部分,Key和Data,具体的算法在这里不再展开。读者只需要知道它是把Key和Data进行掺杂后利用相应的哈希函数计算其哈希值。简单理解的话,就是一个输入参数个数为2的哈希函数
    对于硬化子密钥,可以看到Data部分加了前缀Ox00,这是为了和普通子密钥推导算法中的serP(point(kpar))保持长度一致,即33字节

    我们还可以看到,硬化子密钥和普通子密钥的推导算法的重要区别在于前者使用的参数是序列化的私钥,而后者使用的则是序列化的公钥(由私钥导出)

  • Split I into two 32-byte sequences, IL and IR.

  • The returned child key ki is parse256(IL) + kpar (mod n).
    这里的n是secp256k1中定义的一个常数,略小于2256。我们之前说过私钥的本质是一个256位的随机数,实际上它的取值范围是[1,n-1]

  • The returned chain code ci is IR.

  • In case parse256(IL) ≥ n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2127.)

The HMAC-SHA512 function is specified in [https://tools.ietf.org/html/rfc4231 RFC 4231].

==Public parent key → public child key==

The function CKDpub((Kpar, cpar), i) → (Ki, ci) computes a child extended public key from the parent extended public key. It is only defined for non-hardened child keys.

  • Check whether i ≥ 231 (whether the child is a hardened key).
    If so (hardened child): return failure If not (normal child): let I = HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i)).
    在这里我们看到,对于硬化子密钥,无法直接由父公钥推导出子公钥,这是因为不像普通子私钥,硬化子私钥是由父私钥直接计算得到的。
    我们可以比较父私钥——>子私钥推导算法中的核心函数I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar)) || ser32(i))和父公钥——>子公钥推导算法中的核心函数I = HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i)),可以看到后者中的Kpar(即父公钥)就是前者中的point(kpar)(从父私钥计算得到的父公钥),即两个函数本质是一模一样的

  • Split I into two 32-byte sequences, IL and IR.

  • The returned child key Ki is 

    point(parse256(IL)) + Kpar.
    需要注意:point(parse256(IL)) + Kpar中的加法不是数字之间的加法,而是椭圆曲线上点的加法。
    特别说明:对于普通子密钥,由父公钥计算得到的子公钥与由对应的父私钥计算得到的子私钥是对应成对的。这是因为point(parse256(IL) + kpar)=(parse256(IL) + kpar)
    ∗G=parse256(IL)∗G+kpar∗G=point(parse256(IL)) + Kpar=Ki.即从父私钥推导出的子私钥计算得到的相应的子公钥等于由父公钥直接推导出的子公钥

  • The returned chain code ci is IR.
    因为两种算法的核心函数I的参数相同,因此链码显然也相同

  • In case parse256(IL) ≥ n or Ki is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.

==Private parent key → public child key==

The function N((k, c)) → (K, c) computes the extended public key corresponding to an extended private key (the “neutered” version, as it removes the ability to sign transactions).

  • The returned key K is point(k).

  • The returned chain code c is just the passed chain code.

To compute the public child key of a parent private key:

  • N(CKDpriv((kpar, cpar), i)) (works always).

  • CKDpub(N(kpar, cpar), i) (works only for non-hardened child keys).
    由父私钥推导子公钥有两种方法。第一种很显然的方法是先推导出子私钥,再由子私钥推导出子公钥;第二种只适用于普通子密钥,即先从父私钥推导出对应的父公钥,再从父公钥推导出子公钥
    The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further for more information.

==Public parent key → private child key==

This is not possible.

=The key tree=

The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKDpriv(m,i) for several values of i, we get a number of level-1 derived nodes. As each of these is again an extended key, CKDpriv can be applied to those as well.

To shorten notation, we will write CKDpriv(CKDpriv(CKDpriv(m,3H),2),5) as m/3H/2/5. Equivalently for public keys, we write CKDpub(CKDpub(CKDpub(M,3),2),5) as M/3/2/5. This results in the following identities:

  • N(m/a/b/c) = N(m/a/b)/c = N(m/a)/b/c = N(m)/a/b/c = M/a/b/c.

  • N(m/aH/b/c) = N(m/aH/b)/c 

    = N(m/aH)/b/c.
    However, N(m/aH) cannot be rewritten as N(m)/aH, as the latter is not possible.

Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant non-hardened public keys.

=Key identifiers=

Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECDSA public key K, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself).

The first 32 bits of the identifier are called the key fingerprint.
每一对扩展密钥可以由公钥的Hash160标识

=Serialization format=

这一节介绍了如何序列化一个扩展密钥,下列信息按顺序排列在一起,涵盖了密钥本身的信息及其元数据的所有信息,一共78字节。这样得到一个序列化的扩展密钥后,除了链码和密钥外,我们还可以知道它适用于哪个网络,在HD钱包的哪一层,是该层的第几个密钥,等等

Extended public and private keys are serialized as follows:

  • 4 byte:

  •  version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private;

  • testnet: 0x043587CF public, 0x04358394 private)

  • 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, ….

  • 4 bytes: the fingerprint of the parent’s key (0x00000000 if master key)

  • 4 bytes: child number. This is ser32(i) for i in xi = xpar/i, with xi the key being serialized. (0x00000000 if master key)

  • 32 bytes: the chain code

  • 33 bytes: the public key or private key data (serP(K) for public keys, 0x00 || ser256(k) for private keys)

This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of up to 112 characters. Because of the choice of the version bytes, the Base58 representation will start with “xprv” or “xpub” on mainnet, “tprv” or “tpub” on testnet.

Note that the fingerprint of the parent only serves as a fast way to detect parent and child nodes in software, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.

When importing a serialized extended public key, implementations must verify whether the X coordinate in the public key data corresponds to a point on the curve. If not, the extended public key is invalid.

=Master key generation=

The total number of possible extended keypairs is almost 2512, but the produced keys are only 256 bits long, and offer about half of that in terms of security. Therefore, master keys are not generated directly, but instead from a potentially short seed value.

  • Generate a seed byte sequence S of a chosen length (between 128 and 512 bits; 256 bits is advised) from a (P)RNG.

  • Calculate I = HMAC-SHA512(Key = “Bitcoin seed”, Data = S)

  • Split I into two 32-byte sequences, IL and IR.

  • Use parse256(IL) as master secret key, and IR as master chain code.
    In case IL is 0 or ≥n, the master key is invalid.

Specification: Wallet structure

这里定义了一个默认的钱包结构,在bip43/44中得到了改进

The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimic it for compatibility, even if not all features are supported.

=The default wallet layout=

An HDW is organized as several ‘accounts’. Accounts are numbered, the default account ("") being number 0. Clients are not required to support more than one account - if not, they only use the default account.

Each account is composed of two keypair chains: an internal and an external one. The external keychain is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, …, anything that doesn’t need to be communicated). Clients that do not support separate keychains for these should use the external one for everything.

  • m/iH/0/k corresponds to the k’th keypair of the external chain of account number i of the HDW derived from master m.

  • m/iH/1/k corresponds to the k’th keypair of the internal chain of account number i of the HDW derived from master m.

=Use cases=

下面介绍了一些应用场景,读者可以自行了解

==Full wallet sharing: m==

In cases where two systems need to access a single shared wallet, and both need to be able to perform spendings, one needs to share the master private extended key. Nodes can keep a pool of N look-ahead keys cached for external chains, to watch for incoming payments. The look-ahead for internal chains can be very small, as no gaps are to be expected here. An extra look-ahead could be active for the first unused account’s chains - triggering the creation of a new account when used. Note that the name of the account will still need to be entered manually and cannot be synchronized via the block chain.

==Audits: N(m/*)==

In case an auditor needs full access to the list of incoming and outgoing payments, one can share all account public extended keys. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.

==Per-office balances: m/iH==

When a business has several independent offices, they can all use wallets derived from a single master. This will allow the headquarters to maintain a super-wallet that sees all incoming and outgoing transactions of all offices, and even permit moving money between the offices.

==Recurrent business-to-business transactions: N(m/iH/0)==

In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i h/0) as a sort of “super address”, allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment.
Such a mechanism could also be used by mining pool operators as variable payout address.

==Unsecure money receiver: N(m/iH/0)==

When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that are used to receive payments. The webserver only needs to know the public extended key of the external chain of a single account. This means someone illegally obtaining access to the webserver can at most see all incoming payments but will not be able to steal the money, will not (trivially) be able to distinguish outgoing transactions, nor be able to see payments received by other webservers if there are several.

Compatibility

To comply with this standard, a client must at least be able to import an extended public or private key, to give access to its direct descendants as wallet keys. The wallet structure (master/account/chain/subchain) presented in the second part of the specification is advisory only, but is suggested as a minimal structure for easy compatibility - even when no separate accounts or distinction between internal and external chains is made. However, implementations may deviate from it for specific needs; more complex applications may call for a more complex tree structure.

Security

这一节介绍了BIP32的安全标准

In addition to the expectations from the EC public-key cryptography itself:

  • Given a public key K, an attacker cannot find the corresponding private key more efficiently than by solving the EC discrete logarithm problem (assumed to require 2128 group operations).
    the intended security properties of this standard are:

  • Given a child extended private key (ki,ci) and the integer i, an attacker cannot find the parent private key kpar more efficiently than a 2256 brute force of HMAC-SHA512.

  • Given any number (2 ≤ N ≤ 232-1) of (index, extended private key) tuples (ij,(kij,cij)), with distinct ij‘s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (kpar,cpar) such that for each j in (0..N-1) CKDpriv((kpar,cpar),ij)=(kij,cij)), cannot be done more efficiently than a 2256 brute force of HMAC-SHA512.
    Note however that the following properties does not exist:

  • Given a parent extended public key (Kpar,cpar) and a child public key (Ki), it is hard to find i.

  • Given a parent extended public key (Kpar,cpar) and a non-hardened child private key (ki), it is hard to find kpar.

=Implications=

Private and public keys must be kept safe as usual. Leaking a private key means access to coins - leaking a public key can mean loss of privacy.

Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys.

One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.
It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.
如本节所言,对于非硬化子密钥,如果掌握了子私钥和父公钥,就能得到父私钥,从而能得到子私钥的兄弟密钥


Test Vectors

=Test vector 1=

Seed (hex): 000102030405060708090a0b0c0d0e0f

  • Chain m

ext pub:

xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8

ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi

  • Chain m/0H

ext pub: 

xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw

ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7

  • Chain m/0H/1

ext pub: 

xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ

ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs

  • Chain m/0H/1/2H

ext pub: 

xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5

ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM

  • Chain m/0H/1/2H/2

ext pub:

xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV 

ext prv:

xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334

  • Chain m/0H/1/2H/2/1000000000

ext pub:

xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy

ext prv:

xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76

=Test vector 2=

Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542

  • Chain m 

ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB

extprv:xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U

  • Chain m/0 

ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH 

ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt

  • Chain m/0/2147483647

extpub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a 

ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9

  • Chain m/0/2147483647H/1 

extpub:xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef

  • Chain m/0/2147483647H/1/2147483646

extpub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL 

ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc

  • Chain m/0/2147483647H/1/2147483646H/2 

ext pub:xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt 

ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j

=Test vector 3=

These vectors test for the retention of leading zeros. 

See [https://github.com/bitpay/bitcore-lib/issues/47 bitpay/bitcore-lib#47] 

and [https://github.com/iancoleman/bip39/issues/58 iancoleman/bip39#58] 

for more information.

Seed (hex):

4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45d239319ac14f863b8d5ab5a0d0c64d2e8a1e7d1457df2e5a3c51c73235be

  • Chain m 

ext pub: xpub661MyMwAqRbcEZVB4dScxMAdx6d4nFc9nvyvH3v4gJL378CSRZiYmhRoP7mBy6gSPSCYk6SzXPTf3ND1cZAceL7SfJ1Z3GC8vBgp2epUt13

ext prv: xprv9s21ZrQH143K25QhxbucbDDuQ4naNntJRi4KUfWT7xo4EKsHt2QJDu7KXp1A3u7Bi1j8ph3EGsZ9Xvz9dGuVrtHHs7pXeTzjuxBrCmmhgC6

  • Chain m/0

ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y 

ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L

Implementations

Two Python implementations exist:

PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features. BIP32Utils (https://github.com/jmcorgan/bip32utils) is a library and command line interface specifically focused on BIP0032 wallets and scripting.

2 Java implementations exist:

https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java 

and https://github.com/bushidowallet/bushido-java-core/tree/master/src/main/java/com/bushidowallet/core/bitcoin/bip32

A C++ implementation is available at 

https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinCore/src/hdkeys.h

An Objective-C implementation is available at 

https://github.com/oleganza/CoreBitcoin/blob/master/CoreBitcoin/BTCKeychain.h

A Ruby implementation is available at 

https://github.com/GemHQ/money-tree

Two Go implementations exist: hdkeychain 

(https://github.com/conformal/btcutil/tree/master/hdkeychain) provides an API for bitcoin hierarchical deterministic extended keys (BIP0032). Go HD Wallet (https://github.com/WeMeetAgain/go-hdwallet).

Two JavaScript implementations exist: available at 

https://github.com/sarchar/brainwallet.github.com/tree/bip32 and https://github.com/bitpay/bitcore

A PHP implementation is available at 

https://github.com/Bit-Wasp/bitcoin-lib-php

A C# implementation is available at

 https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey)

A Haskell implementation is available at 

https://github.com/haskoin/haskoin 

together with a CLI interface at

 https://github.com/np/hx


Acknowledgments


  • Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.

  • Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.

  • Eric Lombrozo for reviewing and revising this BIP.

  • Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.



文章发布只为分享区块链技术内容,版权归原作者所有,观点仅代表作者本人,绝不代表区块链兄弟赞同其观点或证实其描述。



猜猜你喜欢


HyperLedger Fabric入门指南

科普丨SM系列国密算法

2019智能合约开发新趋势

2018区块链十大热门应用新鲜出炉

区块链发展的五大里程碑

侧链、分片丨区块链高性能路在何方


点击“阅读原文”参与区块链问题讨论

声明:本文观点仅代表作者本人,不代表凤梨财经赞同或证实其观点描述。如若侵权,请联系我们删除文章。