比特幣改進協議BIP32(翻譯)

比特幣改進協議BIP32(翻譯)

英文原文地址:

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#extended-keys

題目: 分層確定性錢包(Hierarchical Deterministic Wallets)


摘要

本文件描述了層級確定性錢包(或“HD錢包”):可以部分或全部與不同系統共享的錢包,每個錢包可以有或沒花費的功能。

該規范旨在為可在不同客戶之間互相通信的確定性錢包設定標準。雖然這里描述的錢包有許多功能,但并不是所有的支持客戶端都需要。

該規范由兩部分組成。 在第一部分中,提出了用于從單個種子導出密鑰對樹的系統。第二部分演示了如何在這樣的樹之上構建錢包結構。

版權

該BIP根據2條BSD許可證獲得許可。

目的

比特幣參考客戶端使用隨機生成的密鑰。為了避免在每個交易之后進行備份的必要性(默認情況下)100個密鑰緩存在一個預留密鑰池中。然而,這些錢包并不意圖在多個系統上同時共享和使用。 他們支持通過使用錢包加密功能隱藏他們的私鑰并且不公開密碼,但這樣的“中性”錢包也失去了生成公鑰的權力。

確定性錢包不需要這種頻繁的備份,橢圓曲線數學允許可以在不顯示私鑰的情況下計算公鑰的方案。 這允許例如網上商店讓網絡服務器為每個訂單或每個客戶生成新的地址(公鑰哈希),而不使網絡服務器訪問相應的私鑰(花費收到的資金需要私鑰)。

然而,確定性錢包通常由一個密鑰對“鏈”組成。只有一條鏈就意味著共享一個錢包是全無差異的。 然而,在某些情況下,只有一些(公開)密鑰才能被共享和可恢復。在網上商店的例子中,網絡服務器不需要訪問商家錢包的所有公鑰;僅用于用于接收客戶付款的那些地址,而不是例如商家花錢產生的更改地址。分層確定性錢包允許通過支持從單個根導出的多個密鑰對鏈來進行這種選擇性共享。

詳細說明:密鑰分散

約定

在本文的其余部分,我們假設使用Bitcoin公鑰密碼術,即使用由secp256k1(http://www.secg.org/sec2-v2.pdf)定義的字段和曲線參數的橢圓曲線加密。 以下變量是:

  • 整數模數曲線的順序(簡稱n)。
  • 曲線上的點坐標。
  • 字節序列。

兩個坐標對的加法(+)定義為EC組操作的應用。連接(||)是將一個字節序列附加到另一個字節序列的操作。

作為標準轉換函數,我們假設:

  • point(p):返回由整數p表示的secp256k1基點的EC點乘法(EC組操作的重復應用)產生的坐標對。
  • ser32(i):將32位無符號整數i序列化為4字節序列,大端存儲(計算機術語)。
  • ser256(p):將整數p序列化為32字節序列,大端存儲(計算機術語)。
  • serP(P):使用SEC1的壓縮格式將坐標對P=(x,y)串行化為字節序列:(0x02或0x03)|| ser256(x),其中頭字節取決于省略的y坐標的奇偶校驗。
  • parse256(p):將32字節序列轉換為256位數,大端存儲(計算機術語)。

擴展密鑰

接下來,我們將定義一個從父密鑰導出多個子密鑰的函數。為了防止這些僅僅依賴于密鑰本身,我們首先使用額外的256位熵來擴展私鑰和公鑰。稱為鏈碼的擴展對于相應的私鑰和公鑰是相同的,由32個字節組成。

我們將擴展私鑰表示為(k,c),k為普通私鑰,c為鏈碼。 擴展公鑰表示為(K,c),K = point(k),c表示鏈碼。

每個擴展密鑰有 2^31 個普通子密鑰,2^31個硬化子密鑰。 這些子密鑰都有一個索引。 普通子密鑰使用索引0到2^31-1。 硬化的子密鑰使用索引 2^31 到 2^32-1。 為了簡化硬化密鑰索引的符號,數字iH表示i + 2^31。

子密鑰分散(CKD)功能

給定父擴展密鑰和索引i,可以計算相應的子擴展密鑰。這樣做的算法取決于子密鑰是否是硬化密鑰(或等效地,i是否≥2^31),包括私鑰和公鑰。

父私鑰 → 子私鑰

函數CKDpriv((kpar,cpar),i)→(ki,ci)從父擴展私鑰計算子擴展私鑰:

  • 檢查 是否 i ≥ 2^31(子私鑰)。

如果是(硬化的子密鑰):讓I= HMAC-SHA512(Key = cpar,Data = 0x00 || ser256(kpar)|| ser32(i))。 (注意:0x00將私鑰補齊到33字節長。)

如果不是(普通的子密鑰):讓I= HMAC-SHA512(Key = cpar,Data = serP(point(kpar))|| ser32(i))。

  • 將I分為兩個32字節序列,IL和IR。
  • 返回的子密鑰ki是parse256(IL)+ kpar(mod n)。
  • 返回的鏈碼ci是IR。
  • 如果parse256(IL)≥n或ki = 0,則生成的密鑰無效,并且應繼續下一個i值。 (注:概率低于1/2127)

HMAC-SHA512功能在RFC 4231中規定。

父公鑰 → 子公鑰

函數CKDpub((Kpar,cpar),i)→(Ki,ci)從父擴展公鑰計算子擴展公鑰。它只針對未硬化的子密鑰定義。

  • 檢查是否 i ≥ 2^31 (子密鑰是否是硬化密鑰)

如果是(硬化子密鑰):返回失敗

如果不是(普通子密鑰):讓I= HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i)).

  • 將I分為兩個32字節序列,IL和IR。

  • 返回的子密鑰Ki是point(parse256(IL))+ Kpar。

  • 返回的鏈碼ci是IR。
  • 如果parse256(IL)≥n或Ki是無限遠的點,則生成的密鑰無效,并且應繼續下一個i值。

父私鑰 → 子公鑰

函數N((k,c))→(K,c)計算與擴展私鑰對應的擴展公鑰(“中和”版本,因為它消除了簽署交易的能力)。

  • 返回的密鑰K是point(k)。
  • 返回的鏈碼c只是傳遞的鏈碼。

要計算父私鑰的公用子密鑰:

  • N(CKDpriv((kpar,cpar),i))(總是工作)。

  • CKDpub(N(kpar,cpar),i)(僅適用于非硬化子密鑰)。

它們等價的事實是使非硬化密鑰有用(可以在不知道任何私鑰的情況下導出給定父密鑰的子公鑰),以及它們與硬密鑰的區別。 不總是使用非硬化鍵(更有用)的原因是安全性; 后面可以了解更詳細的信息。

父公鑰 → 子私鑰

不可能發生

密鑰樹結構

下一步是級聯幾個CKD結構來構建樹。我們從一個root開始,主擴展密鑰m。通過對i的幾個值評估CKDpriv(m,i),我們得到了多個1級派生節點。由于這些都是擴展密鑰,所以也可以應用CKDpriv。

為了縮短符號,

我們將寫入CKDpriv(CKDpriv(m,3H),2),5)作為m / 3H / 2/5。等同于公鑰,

我們寫入CKDpub(CKDpub(M,3),2),5)作為M / 3/2/5。

這導致以下身份:

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。

然而,N(m / aH)不能被重寫為N(m)/ aH,因為后者是不可能的。
樹中的每個葉節點對應于實際密鑰,而內部節點對應于從它們分散的密鑰的集合。葉節點的鏈碼被忽略,只有它們嵌入的私鑰或公鑰是相關的。由于這種結構,知道擴展私鑰允許重構所有后代私鑰和公鑰,并且知道擴展公鑰允許重建所有后代非硬化公鑰。

密鑰標識符

擴展密鑰可以由序列化的ECSDA公鑰K的Hash160(SHA256之后的RIPEMD160)標識,忽略鏈碼。 這完全對應于傳統比特幣地址中使用的數據。不建議以base58格式表示此數據,因為它可能被解釋為一種地址(并且錢包軟件不需要接受對鏈密鑰本身的支付)。

標識符的前32位稱為密鑰指紋。

序列化格式

擴展的公鑰和私鑰如下序列化:

  • 4字節:版本字節(mainnet:0x0488B21E public,0x0488ADE4 private; testnet:0x043587CF public,0x04358394 private)

  • 1字節:深度:主節點為0x00,級別1派生密鑰為0x01。

  • 4字節:父密鑰的指紋(如果主密鑰為0x00000000)

  • 4字節:子數字。這是對于i在xi = xpar / i中的ser32(i),其中xi是鍵序列化。 (如果主密鑰為0x00000000)

  • 32字節:鏈碼

  • 33字節:公鑰或私鑰數據(公鑰的serP(K),私鑰的0x00 || ser256(k))

可以通過首先添加32個校驗和位(從雙SHA-256校驗和派生),然后轉換為Base58表示,可以像Base58中的其他Bitcoin數據一樣對78字節結構進行編碼。這會導致最多112個字符的Base58編碼的字符串。由于可選擇版本字節,Base58表示將以“net”,“net”,“tpv”或“tpub”為起始的“xprv”或“xpub”開頭。

請注意,父指紋僅作為在軟件中檢測父節點和子節點的快速方式,軟件必須愿意處理沖突。在內部,可以使用完整的160位標識符。

導入序列化擴展公鑰時,實現必須驗證公鑰數據中的X坐標是否對應于曲線上的一個點。如果不是,擴展的公鑰是無效的。

主密鑰生成

可能的擴展密鑰對的總數幾乎為2^512,但生成的密鑰只有256位長,在安全性方面提供約一半的密鑰。 因此,主密鑰不是直接生成,而是從潛在的短種子值生成。

  • 從(P)RNG生成所選長度(128到512位;建議256位)的種子字節序列S。

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

  • 將I分為兩個32字節序列,IL和IR。

  • 使用parse256(IL)作為主密鑰,IR作為主鏈碼。

如果IL為0或≥n,則主密鑰無效。

image
image

詳細說明:錢包結構

前面的部分指定了關鍵樹及其節點。下一步是在這棵樹上施加錢包結構。本節中定義的布局是僅默認的,客戶端要求具備兼容性,即使不支持所有功能。

缺省的錢包結構

HDW被組織為幾個“帳戶”。 帳號已編號,默認帳號(“”)為數字0.客戶端不需要支持多個帳戶 - 如果不是,則只使用默認帳戶。

每個帳戶由兩個密鑰鏈組成:內部和外部鏈。 外部密鑰鏈用于生成新的公共地址,而內部密鑰鏈用于所有其他操作(更改地址,生成地址...,任何不需要傳達的內容)。 不支持單獨的密鑰鏈的客戶端應該使用外部的一個。

m / iH / 0 / k對應于從主站m導出的HDW的帳號i的外部鏈的第k個密鑰對。
m / iH / 1 / k對應于從主站m導出的HDW的帳號i的內部鏈的第k個密鑰。

示例

全錢包分享:m

在兩個系統需要訪問單個共享錢包的情況下,并且都需要能夠執行花費的情況下,需要共享主專用擴展密鑰。節點可以保留為外部鏈條緩存的N個預先密鑰池,以監聽收到的付款。內部鏈條的前瞻性可能非常小,因為這里不可能有任何差距。對于第一個未使用的帳戶的鏈,額外的預覽可能是活動的 - 在使用時觸發新帳戶的創建。請注意,帳戶的名稱仍然需要手動輸入,無法通過塊鏈同步。

審核:N(m / *)

如果審核員需要完全訪問傳入和傳出付款列表,則可以共享所有帳戶公用擴展密鑰。這將允許審核員在所有帳戶中查看和從錢包中獲得的所有交易,但不能查看單個保密密鑰。

每-辦公室余額:m / iH

當一家企業有幾個獨立的辦公室時,他們都可以使用從一個主人那里獲得的錢包。這將允許總部維持一個超級錢包,看到所有辦公室的所有進出口交易,甚至允許在辦公室之間移動資金。

經常性企業對企業交易:N(m / iH / 0)

如果兩個業務伙伴經常轉賬,可以將特定賬戶的外部鏈(M / ih / 0)的擴展公鑰用作“超級地址”,允許頻繁的交易(不容易)相關聯,但不需要為每個付款請求一個新的地址。這種機制也可以被礦井運營商用作可變支付地址。

不安全的收款人:N(m / iH / 0)

當使用不安全的網絡服務器來運行電子商務網站時,需要知道用于接收付款的公共地址。網絡服務器只需要知道單個帳戶的外部鏈路的公共擴展密鑰。這意味著有人非法獲取對網絡服務器的訪問權限,最多可以看到所有收到的付款,但是無法竊取錢,不能(簡單地)區分出去的交易,在存在交易的情況下也不能看到其他網絡服務器收到的付款。

兼容性

為符合本標準,客戶端必須至少能夠導入擴展的公鑰或私鑰,才能將其直接后代作為錢包密鑰訪問。 說明書第二部分中提供的錢包結構(主/賬戶/鏈/子鏈)僅供參考,但建議作為最小結構,以便易于兼容 - 即使沒有單獨的帳戶或內部和外部鏈條之間的區別。然而,實現可能會因特定需求而偏離它; 更復雜的應用程序可能需要更復雜的樹結構。

安全

除了期望EC公鑰自己加密之外:

  • 給定公鑰K,攻擊者無法通過比解決EC離散對數問題(假定需要2128個組操作)更有效地方式找到相應的私鑰。

本標準的預期安全屬性有:

  • 給定一個子擴展私鑰(ki,ci)和整數i,攻擊者不能比HMAC-SHA512的2^256暴力更有效地方式找到父私鑰kpar。
  • 給定具有不同ij的(索引,擴展私鑰)元組(ij,(kij,cij))的任何數目(2≤N≤2^32-1),確定它們是否從公開父擴展私鑰派生(即, 是否存在一個(kpar,cpar),使得對于(0..N-1)中的每個j,CKDpriv((kpar,cpar),ij)=(kij,cij))不能比2^256復雜度 HMAC-SHA512的更有效的完成。

請注意以下屬性不存在:

  • 給定父擴展公鑰(Kpar,cpar)和子公鑰(Ki),很難找到i。
  • 給定一個父擴展公鑰(Kpar,cpar)和一個非強化的子私鑰(ki),很難找到kpar。

含義

私鑰和公鑰必須像往常一樣保持安全。泄露私鑰意味著可以花費比特幣泄露公鑰可能意味著失去隱私。

對于擴展密鑰,必須更加小心,因為它們對應于整個(子)密鑰樹。

一個弱點可能不是很明顯的,就是知道父擴展公鑰加上從它分散的任何非硬化私鑰相當于知道父擴展私鑰(因此知道從其分散的每個私鑰和公鑰)。這意味著擴展公鑰必須比常規公鑰更仔細地對待。 這也是硬化密鑰存在的原因,為什么它們被用于樹中的帳戶級別。這樣一來,專用(或更低)私鑰的泄漏就不會危害主賬號或其他賬戶。

測試向量

測試向量 1

發送 (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

測試向量2

發送 (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542

Chain m
ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB
ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U
Chain m/0
ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH
ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt
Chain m/0/2147483647H
ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a
ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9
Chain m/0/2147483647H/1
ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon
ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef
Chain m/0/2147483647H/1/2147483646H
ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL
ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc
Chain m/0/2147483647H/1/2147483646H/2
ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt
ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j

測試向量3

These vectors test for the retention of leading zeros. See bitpay/bitcore-lib#47 and iancoleman/bip39#58 for more information.

Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45d239319ac14f863b8d5ab5a0d0c64d2e8a1e7d1457df2e5a3c51c73235be

Chain m
ext pub: xpub661MyMwAqRbcEZVB4dScxMAdx6d4nFc9nvyvH3v4gJL378CSRZiYmhRoP7mBy6gSPSCYk6SzXPTf3ND1cZAceL7SfJ1Z3GC8vBgp2epUt13
ext prv: xprv9s21ZrQH143K25QhxbucbDDuQ4naNntJRi4KUfWT7xo4EKsHt2QJDu7KXp1A3u7Bi1j8ph3EGsZ9Xvz9dGuVrtHHs7pXeTzjuxBrCmmhgC6
Chain m/0H
ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y
ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L

實現

(這里太簡單,就不翻了)

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

致謝

  • Gregory Maxwell提出了2型確定性錢包的原始想法,并對此進行了許多討論。

  • Alan Reiner在Armory中實施這一計劃,并隨后提出了一些建議。

  • Eric Lombrozo審查和修改此BIP。

  • Mike Caldwell為版本字節表示便于識別的Base58字符串作出貢獻。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,345評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,494評論 3 416
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,283評論 0 374
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,953評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,714評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,186評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,255評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,410評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,940評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,776評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,976評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,518評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,210評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,642評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,878評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,654評論 3 391
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,958評論 2 373

推薦閱讀更多精彩內容