https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Sipa&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-29T07:29:18ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Bech32_adoption&diff=68740Bech32 adoption2021-07-10T04:32:12Z<p>Sipa: </p>
<hr />
<div>[[Bech32]] is a bitcoin [[address]] format specified by [[BIP 0173]]. It is used for the native segwit version 0 output types, P2WPKH and P2WSH. The upcoming [[Taproot]] softfork will add another output type called Pay to Taproot (P2TR). P2TR outputs and future native segwit versions will be using an updated variant of [[Bech32]], called [[Bech32m]] (specified by [[BIP 0350]]). This page tracks the adoption of [[Bech32]] and [[Bech32m]].<br />
<br />
Ideally wallets and services would first support ''sending to'' new addresses. When most wallets and services support sending to the new address type, people are more likely to adopt it for receiving. <br />
<br />
The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Bitcoin Core || {{Yes|Since 0.16.0}} || {{Yes|Since 0.16.0}} || {{Yes|Since 0.21.1}} || {{Acceptable|Starting with 22.0}} || Uses P2WPKH as default address since version [https://bitcoin.org/en/release/v0.20.0 0.20.0]. Creating P2TR addresses requires manual import for now.<br />
|-<br />
| Bitcoin Knots || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| bcoin || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Electrum || {{Yes}} || {{Yes}} || {{Yes|Since 4.1.0}} || {{Evaluating|??}} || <br />
|-<br />
| Armory || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GreenAddress || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Breadwallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/udiWertheimer/status/975810157941796864<br />
|-<br />
| Samourai Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinomi || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]<br />
|-<br />
| BTC.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Casa || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Mycelium || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{Yes}} || {{Planned|Planned: via NBitcoin before Activation}} || {{Planned|Planned: via NBitcoin before Activation}} || https://twitter.com/NicolasDorier/status/1413693010236170241<br />
|-<br />
| Trust Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://trustwallet.com/blog/trust-wallet-adds-support-for-btc-ltc-bch official blog]<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://twitter.com/GuardaWallet/status/1194270398730448896 twitter announcement]<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger Live (desktop app) || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey chrome app || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox Desktop app || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Trezor + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Archos + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coldcard + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ballet + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Tangem + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Web Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Coinapult || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coin.Space || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitGo || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Full support on v2 platform, no plans to add support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9<br />
|-<br />
| blockchain.info web|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/provoost/status/1037802325874761728<br />
|-<br />
| HolyTransaction || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || open source JavaScript implementation<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/GuardaWallet/status/1194270398730448896<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| 1Fox || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://1fox.com/?c=en/content/blog&id=12<br />
|-<br />
| [[AgoraDesk]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Anycoin Direct || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://anycoindirect.eu/en/news/details/segwit-activated<br />
|-<br />
| BitBargain.co.uk || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bitcoin.de || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/<br />
|-<br />
| Bitfinex || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/bitfinex/status/1189164144789983234<br />
|-<br />
| BitMEX || {{yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blog.bitmex.com/bitmex-enables-bech32-sending-support/<br />
|-<br />
| Bittrex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/gqt1m6/bittrex_does_not_even_support_withdrawals_to/<br />
|-<br />
| Bittylicious || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bittylicious_/status/998881327347888128<br />
|-<br />
| Bitstamp || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/<br />
|-<br />
| Bitso || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bitso/status/1203784055340314624?s=20<br />
|-<br />
| Bitwage || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bisq || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || As of v1.5.0 https://bisq.network/blog/bisq-v1.5.0-highlights/<br />
|-<br />
| CEX.IO || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinbase.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/diogorsergio/status/983052769262292992 (Note that Coinbase commerce does not support sending to bech32)<br />
|-<br />
| CoinFalcon || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinfloor || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinfloor.co.uk/hodl/2020/09/16/a-few-updates-from-coinfloor/<br />
|-<br />
| [https://coinmate.io Coinmate.io] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinmate.io/blog/important-coinmate-update/<br />
|-<br />
| Coinsbank.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinygram || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Flyp.me || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GDax || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/<br />
|-<br />
| Gemini || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/<br />
|-<br />
| Genesis || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Globitex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| HitBTC || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Hodl Hodl || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56<br />
|-<br />
| Independent Reserve|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.independentreserve.com/bitcoin/investing<br />
|-<br />
| Itbit || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Kraken || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/krakenfx/status/1060306827848470528<br />
|-<br />
| LedgerX || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Liberalcoins || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://liberalcoins.com<br />
|-<br />
| [[LocalBitcoins]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/LocalBitcoins/status/1322194709159301120<br />
|-<br />
| Paxful.com || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Poloniex.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/<br />
|-<br />
| TheRockTrading.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/TheRockTrading/status/976787499648512003<br />
|-<br />
| Walltime || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://walltime.info<br />
|-<br />
| Purse.io || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| www.bitwala.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Xapo || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Bitcoin ATM Models ===<br />
<br />
Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| GenesisCoin || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| General Bytes || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Depending on configuration. Since version 20190613 https://www.generalbytes.com/en/support/changelog<br />
|-<br />
| Lamassu Douro || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@LamassuSupport/announcing-crafty-chnemu-v7-3-9522fe2868<br />
|}<br />
<br />
=== Blockchain Explorers ===<br />
<br />
For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.<br />
<br />
Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.<br />
<br />
See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Display Bech32 !! Index Bech32 !! Display Bech32m !! Index Bech32m !! Notes<br />
|-<br />
| Apirone.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://apirone.com<br />
|-<br />
| bitaps.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitaps.com<br />
|-<br />
| Bitflyer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chainflyer.bitflyer.jp/<br />
|-<br />
| Bitupper Explorer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitupper.com/en/explorer/bitcoin<br />
|-<br />
| blockchain.info || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Blockchair || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockchair.com/<br />
|-<br />
| Blockcypher || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://live.blockcypher.com/btc<br />
|-<br />
| Blockonomics || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.blockonomics.co<br />
|-<br />
| Blockpath || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockpath.com<br />
|-<br />
| BTC.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://BTC.com<br />
|-<br />
| Esplora || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/. [https://github.com/Blockstream/esplora/issues/323 Issue] for BIP350 support.<br />
|-<br />
| chaindex || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chaindex.com/blockchain/<br />
|-<br />
| Insight || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances include https://insight.bitpay.com/<br />
|-<br />
| OXT || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://oxt.me/<br />
|-<br />
| Tradeblock || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://tradeblock.com/bitcoin<br />
|}<br />
<br />
=== Payment Processors ===<br />
<br />
<!-- Payment processors in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! P2WPKH/P2WSH Invoices !! Bech32 Withdrawal addresses !! P2TR Invoices !! Bech32m Withdrawal addresses !! Notes<br />
|-<br />
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment notifications, merchant dashboard, plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart<br />
|-<br />
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment forwarding API, Wallet API, fault tolerance callback.<br />
|-<br />
| [https://btcpayserver.org BTCPay Server] || {{Yes}} || {{Yes}} || {{Planned|Planned: via NBitcoin before Activation}} || {{Planned|Planned: via NBitcoin before Activation}} || https://twitter.com/NicolasDorier/status/1413693010236170241<br />
|-<br />
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://confirmo.net CONFIRMO] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Highly customizable Bitcoin and Lightning Network payment gateway. Multi-sig, HD wallets, API, SDK.<br />
|}<br />
<br />
=== Mining Pools ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Payout to Bech32 !! Payout to Bech32m !! Notes<br />
|-<br />
| [https://pool.btc.com/ BTC.com Pool] || {{No}} || {{Evaluating|??}} ||<br />
|-<br />
| [http://ckpool.org/ Ckpool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://kano.is/ KanoPool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=789369.msg53374508#msg53374508 bitcointalk source]<br />
|-<br />
| [http://poolin.com/ Poolin] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]<br />
|-<br />
| [https://slushpool.com/ Slush Pool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]<br />
|-<br />
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
<!--<br />
<br />
=== Other Services ===<br />
<br />
Casinos, marketplaces, etc that let users withdraw money<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Withdrawals !! Notes<br />
|-<br />
| 1Broker || {{Yes}} || <br />
|-<br />
| [https://crypto.games Crypto.Games]|| {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]<br />
|-<br />
| YOLOdice || {{Yes}} ||<br />
|}<br />
<br />
--><br />
<br />
=== References ===<br />
<br />
[[Category:Software]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Bech32_adoption&diff=68739Bech32 adoption2021-07-10T04:30:53Z<p>Sipa: </p>
<hr />
<div>[[Bech32]] is a bitcoin [[address]] format specified by [[BIP 0173]]. It is used for the native segwit version 0 output types, P2WPKH and P2WSH. The upcoming [[Taproot]] softfork will add another output type called Pay to Taproot (P2TR). P2TR outputs and future native segwit versions will be using an updated variant of [[Bech32]], called [[Bech32m]] (specified by [[BIP 0350]]). This page tracks the adoption of [[Bech32]] and [[Bech32m]].<br />
<br />
Ideally wallets and services would first support ''sending to'' new addresses. When most wallets and services support sending to the new address type, people are more likely to adopt it for receiving. <br />
<br />
The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Bitcoin Core || {{Yes|Since 0.16.0}} || {{Yes|Since 0.16.0}} || {{Yes|Since 0.21.1}} || {{Acceptable|Starting with 22.0}} || Uses P2WPKH as default address since version [https://bitcoin.org/en/release/v0.20.0 0.20.0]. Creating P2TR addresses requires manual import for now.<br />
|-<br />
| Bitcoin Knots || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| bcoin || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Electrum || {{Yes}} || {{Yes}} || {{Yes|Since 4.1.0}} || {{Evaluating|??}} || <br />
|-<br />
| Armory || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GreenAddress || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Breadwallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/udiWertheimer/status/975810157941796864<br />
|-<br />
| Samourai Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinomi || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]<br />
|-<br />
| BTC.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Casa || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Mycelium || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{Yes}} || {{Planned|Planned: via NBitcoin before Activation}} || {{Planned|Planned: via NBitcoin before Activation}} || https://twitter.com/NicolasDorier/status/1413693010236170241<br />
|-<br />
| Trust Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://trustwallet.com/blog/trust-wallet-adds-support-for-btc-ltc-bch official blog]<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://twitter.com/GuardaWallet/status/1194270398730448896 twitter announcement]<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger Live (desktop app) || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey chrome app || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox Desktop app || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Trezor + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Archos + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coldcard + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ballet + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Tangem + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Web Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Coinapult || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coin.Space || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitGo || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Full support on v2 platform, no plans to add support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9<br />
|-<br />
| blockchain.info web|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/provoost/status/1037802325874761728<br />
|-<br />
| HolyTransaction || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || open source JavaScript implementation<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/GuardaWallet/status/1194270398730448896<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| 1Fox || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://1fox.com/?c=en/content/blog&id=12<br />
|-<br />
| [[AgoraDesk]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Anycoin Direct || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://anycoindirect.eu/en/news/details/segwit-activated<br />
|-<br />
| BitBargain.co.uk || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bitcoin.de || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/<br />
|-<br />
| Bitfinex || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/bitfinex/status/1189164144789983234<br />
|-<br />
| BitMEX || {{yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blog.bitmex.com/bitmex-enables-bech32-sending-support/<br />
|-<br />
| Bittrex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/gqt1m6/bittrex_does_not_even_support_withdrawals_to/<br />
|-<br />
| Bittylicious || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bittylicious_/status/998881327347888128<br />
|-<br />
| Bitstamp || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/<br />
|-<br />
| Bitso || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bitso/status/1203784055340314624?s=20<br />
|-<br />
| Bitwage || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bisq || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || As of v1.5.0 https://bisq.network/blog/bisq-v1.5.0-highlights/<br />
|-<br />
| CEX.IO || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinbase.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/diogorsergio/status/983052769262292992 (Note that Coinbase commerce does not support sending to bech32)<br />
|-<br />
| CoinFalcon || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinfloor || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinfloor.co.uk/hodl/2020/09/16/a-few-updates-from-coinfloor/<br />
|-<br />
| [https://coinmate.io Coinmate.io] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinmate.io/blog/important-coinmate-update/<br />
|-<br />
| Coinsbank.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinygram || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Flyp.me || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GDax || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/<br />
|-<br />
| Gemini || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/<br />
|-<br />
| Genesis || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Globitex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| HitBTC || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Hodl Hodl || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56<br />
|-<br />
| Independent Reserve|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.independentreserve.com/bitcoin/investing<br />
|-<br />
| Itbit || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Kraken || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/krakenfx/status/1060306827848470528<br />
|-<br />
| LedgerX || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Liberalcoins || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://liberalcoins.com<br />
|-<br />
| [[LocalBitcoins]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/LocalBitcoins/status/1322194709159301120<br />
|-<br />
| Paxful.com || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Poloniex.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/<br />
|-<br />
| TheRockTrading.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/TheRockTrading/status/976787499648512003<br />
|-<br />
| Walltime || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://walltime.info<br />
|-<br />
| Purse.io || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| www.bitwala.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Xapo || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Bitcoin ATM Models ===<br />
<br />
Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| GenesisCoin || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| General Bytes || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Depending on configuration. Since version 20190613 https://www.generalbytes.com/en/support/changelog<br />
|-<br />
| Lamassu Douro || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@LamassuSupport/announcing-crafty-chnemu-v7-3-9522fe2868<br />
|}<br />
<br />
=== Blockchain Explorers ===<br />
<br />
For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.<br />
<br />
Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.<br />
<br />
See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Display Bech32 !! Index Bech32 !! Display Bech32m !! Index Bech32m !! Notes<br />
|-<br />
| Apirone.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://apirone.com<br />
|-<br />
| bitaps.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitaps.com<br />
|-<br />
| Bitflyer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chainflyer.bitflyer.jp/<br />
|-<br />
| Bitupper Explorer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitupper.com/en/explorer/bitcoin<br />
|-<br />
| blockchain.info || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Blockchair || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockchair.com/<br />
|-<br />
| Blockcypher || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://live.blockcypher.com/btc<br />
|-<br />
| Blockonomics || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.blockonomics.co<br />
|-<br />
| Blockpath || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockpath.com<br />
|-<br />
| BTC.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://BTC.com<br />
|-<br />
| Esplora || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/. [[https://github.com/Blockstream/esplora/issues/323|Issue]] for BIP350 support.<br />
|-<br />
| chaindex || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chaindex.com/blockchain/<br />
|-<br />
| Insight || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances include https://insight.bitpay.com/<br />
|-<br />
| OXT || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://oxt.me/<br />
|-<br />
| Tradeblock || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://tradeblock.com/bitcoin<br />
|}<br />
<br />
=== Payment Processors ===<br />
<br />
<!-- Payment processors in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! P2WPKH/P2WSH Invoices !! Bech32 Withdrawal addresses !! P2TR Invoices !! Bech32m Withdrawal addresses !! Notes<br />
|-<br />
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment notifications, merchant dashboard, plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart<br />
|-<br />
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment forwarding API, Wallet API, fault tolerance callback.<br />
|-<br />
| [https://btcpayserver.org BTCPay Server] || {{Yes}} || {{Yes}} || {{Planned|Planned: via NBitcoin before Activation}} || {{Planned|Planned: via NBitcoin before Activation}} || https://twitter.com/NicolasDorier/status/1413693010236170241<br />
|-<br />
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://confirmo.net CONFIRMO] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Highly customizable Bitcoin and Lightning Network payment gateway. Multi-sig, HD wallets, API, SDK.<br />
|}<br />
<br />
=== Mining Pools ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Payout to Bech32 !! Payout to Bech32m !! Notes<br />
|-<br />
| [https://pool.btc.com/ BTC.com Pool] || {{No}} || {{Evaluating|??}} ||<br />
|-<br />
| [http://ckpool.org/ Ckpool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://kano.is/ KanoPool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=789369.msg53374508#msg53374508 bitcointalk source]<br />
|-<br />
| [http://poolin.com/ Poolin] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]<br />
|-<br />
| [https://slushpool.com/ Slush Pool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]<br />
|-<br />
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
<!--<br />
<br />
=== Other Services ===<br />
<br />
Casinos, marketplaces, etc that let users withdraw money<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Withdrawals !! Notes<br />
|-<br />
| 1Broker || {{Yes}} || <br />
|-<br />
| [https://crypto.games Crypto.Games]|| {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]<br />
|-<br />
| YOLOdice || {{Yes}} ||<br />
|}<br />
<br />
--><br />
<br />
=== References ===<br />
<br />
[[Category:Software]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Bech32_adoption&diff=68738Bech32 adoption2021-07-10T04:30:04Z<p>Sipa: </p>
<hr />
<div>[[Bech32]] is a bitcoin [[address]] format specified by [[BIP 0173]]. It is used for the native segwit version 0 output types, P2WPKH and P2WSH. The upcoming [[Taproot]] softfork will add another output type called Pay to Taproot (P2TR). P2TR outputs and future native segwit versions will be using an updated variant of [[Bech32]], called [[Bech32m]] (specified by [[BIP 0350]]). This page tracks the adoption of [[Bech32]] and [[Bech32m]].<br />
<br />
Ideally wallets and services would first support ''sending to'' new addresses. When most wallets and services support sending to the new address type, people are more likely to adopt it for receiving. <br />
<br />
The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Bitcoin Core || {{Yes|Since 0.16.0}} || {{Yes|Since 0.16.0}} || {{Yes|Since 0.21.1}} || {{Acceptable|Starting with 22.0}} || Uses P2WPKH as default address since version [https://bitcoin.org/en/release/v0.20.0 0.20.0]. Creating P2TR addresses requires manual import for now.<br />
|-<br />
| Bitcoin Knots || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| bcoin || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Electrum || {{Yes}} || {{Yes}} || {{Yes|Since 4.1.0}} || {{Evaluating|??}} || <br />
|-<br />
| Armory || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GreenAddress || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Breadwallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/udiWertheimer/status/975810157941796864<br />
|-<br />
| Samourai Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinomi || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]<br />
|-<br />
| BTC.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Casa || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Mycelium || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{Yes}} || {{Planned|Planned: via NBitcoin before Activation}} || {{Planned|Planned: via NBitcoin before Activation}} || https://twitter.com/NicolasDorier/status/1413693010236170241<br />
|-<br />
| Trust Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://trustwallet.com/blog/trust-wallet-adds-support-for-btc-ltc-bch official blog]<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://twitter.com/GuardaWallet/status/1194270398730448896 twitter announcement]<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger Live (desktop app) || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey chrome app || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox Desktop app || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Trezor + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Archos + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coldcard + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ballet + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Tangem + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Web Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Coinapult || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coin.Space || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitGo || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Full support on v2 platform, no plans to add support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9<br />
|-<br />
| blockchain.info web|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/provoost/status/1037802325874761728<br />
|-<br />
| HolyTransaction || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || open source JavaScript implementation<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/GuardaWallet/status/1194270398730448896<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| 1Fox || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://1fox.com/?c=en/content/blog&id=12<br />
|-<br />
| [[AgoraDesk]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Anycoin Direct || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://anycoindirect.eu/en/news/details/segwit-activated<br />
|-<br />
| BitBargain.co.uk || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bitcoin.de || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/<br />
|-<br />
| Bitfinex || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/bitfinex/status/1189164144789983234<br />
|-<br />
| BitMEX || {{yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blog.bitmex.com/bitmex-enables-bech32-sending-support/<br />
|-<br />
| Bittrex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/gqt1m6/bittrex_does_not_even_support_withdrawals_to/<br />
|-<br />
| Bittylicious || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bittylicious_/status/998881327347888128<br />
|-<br />
| Bitstamp || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/<br />
|-<br />
| Bitso || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bitso/status/1203784055340314624?s=20<br />
|-<br />
| Bitwage || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bisq || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || As of v1.5.0 https://bisq.network/blog/bisq-v1.5.0-highlights/<br />
|-<br />
| CEX.IO || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinbase.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/diogorsergio/status/983052769262292992 (Note that Coinbase commerce does not support sending to bech32)<br />
|-<br />
| CoinFalcon || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinfloor || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinfloor.co.uk/hodl/2020/09/16/a-few-updates-from-coinfloor/<br />
|-<br />
| [https://coinmate.io Coinmate.io] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinmate.io/blog/important-coinmate-update/<br />
|-<br />
| Coinsbank.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinygram || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Flyp.me || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GDax || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/<br />
|-<br />
| Gemini || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/<br />
|-<br />
| Genesis || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Globitex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| HitBTC || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Hodl Hodl || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56<br />
|-<br />
| Independent Reserve|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.independentreserve.com/bitcoin/investing<br />
|-<br />
| Itbit || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Kraken || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/krakenfx/status/1060306827848470528<br />
|-<br />
| LedgerX || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Liberalcoins || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://liberalcoins.com<br />
|-<br />
| [[LocalBitcoins]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/LocalBitcoins/status/1322194709159301120<br />
|-<br />
| Paxful.com || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Poloniex.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/<br />
|-<br />
| TheRockTrading.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/TheRockTrading/status/976787499648512003<br />
|-<br />
| Walltime || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://walltime.info<br />
|-<br />
| Purse.io || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| www.bitwala.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Xapo || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Bitcoin ATM Models ===<br />
<br />
Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| GenesisCoin || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| General Bytes || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Depending on configuration. Since version 20190613 https://www.generalbytes.com/en/support/changelog<br />
|-<br />
| Lamassu Douro || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@LamassuSupport/announcing-crafty-chnemu-v7-3-9522fe2868<br />
|}<br />
<br />
=== Blockchain Explorers ===<br />
<br />
For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.<br />
<br />
Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.<br />
<br />
See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Display Bech32 !! Index Bech32 !! Display Bech32m !! Index Bech32m !! Notes<br />
|-<br />
| Apirone.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://apirone.com<br />
|-<br />
| bitaps.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitaps.com<br />
|-<br />
| Bitflyer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chainflyer.bitflyer.jp/<br />
|-<br />
| Bitupper Explorer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitupper.com/en/explorer/bitcoin<br />
|-<br />
| blockchain.info || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Blockchair || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockchair.com/<br />
|-<br />
| Blockcypher || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://live.blockcypher.com/btc<br />
|-<br />
| Blockonomics || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.blockonomics.co<br />
|-<br />
| Blockpath || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockpath.com<br />
|-<br />
| BTC.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://BTC.com<br />
|-<br />
| Esplora || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/. [Issue|https://github.com/Blockstream/esplora/issues/323] for BIP350 support.<br />
|-<br />
| chaindex || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chaindex.com/blockchain/<br />
|-<br />
| Insight || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances include https://insight.bitpay.com/<br />
|-<br />
| OXT || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://oxt.me/<br />
|-<br />
| Tradeblock || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://tradeblock.com/bitcoin<br />
|}<br />
<br />
=== Payment Processors ===<br />
<br />
<!-- Payment processors in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! P2WPKH/P2WSH Invoices !! Bech32 Withdrawal addresses !! P2TR Invoices !! Bech32m Withdrawal addresses !! Notes<br />
|-<br />
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment notifications, merchant dashboard, plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart<br />
|-<br />
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment forwarding API, Wallet API, fault tolerance callback.<br />
|-<br />
| [https://btcpayserver.org BTCPay Server] || {{Yes}} || {{Yes}} || {{Planned|Planned: via NBitcoin before Activation}} || {{Planned|Planned: via NBitcoin before Activation}} || https://twitter.com/NicolasDorier/status/1413693010236170241<br />
|-<br />
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://confirmo.net CONFIRMO] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Highly customizable Bitcoin and Lightning Network payment gateway. Multi-sig, HD wallets, API, SDK.<br />
|}<br />
<br />
=== Mining Pools ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Payout to Bech32 !! Payout to Bech32m !! Notes<br />
|-<br />
| [https://pool.btc.com/ BTC.com Pool] || {{No}} || {{Evaluating|??}} ||<br />
|-<br />
| [http://ckpool.org/ Ckpool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://kano.is/ KanoPool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=789369.msg53374508#msg53374508 bitcointalk source]<br />
|-<br />
| [http://poolin.com/ Poolin] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]<br />
|-<br />
| [https://slushpool.com/ Slush Pool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]<br />
|-<br />
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
<!--<br />
<br />
=== Other Services ===<br />
<br />
Casinos, marketplaces, etc that let users withdraw money<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Withdrawals !! Notes<br />
|-<br />
| 1Broker || {{Yes}} || <br />
|-<br />
| [https://crypto.games Crypto.Games]|| {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]<br />
|-<br />
| YOLOdice || {{Yes}} ||<br />
|}<br />
<br />
--><br />
<br />
=== References ===<br />
<br />
[[Category:Software]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Bech32_adoption&diff=68736Bech32 adoption2021-07-10T03:59:13Z<p>Sipa: </p>
<hr />
<div>[[Bech32]] is a bitcoin [[address]] format specified by [[BIP 0173]]. It is used for the native segwit version 0 output types, P2WPKH and P2WSH. The upcoming [[Taproot]] softfork will add another output type called Pay to Taproot (P2TR). P2TR outputs and future native segwit versions will be using an updated variant of [[Bech32]], called [[Bech32m]] (specified by [[BIP 0350]]). This page tracks the adoption of [[Bech32]] and [[Bech32m]].<br />
<br />
Ideally wallets and services would first support ''sending to'' new addresses. When most wallets and services support sending to the new address type, people are more likely to adopt it for receiving. <br />
<br />
The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Bitcoin Core || {{Yes|Since 0.16.0}} || {{Yes|Since 0.16.0}} || {{Yes|Since 0.21.1}} || {{Acceptable|Starting with 22.0}} || Uses P2WPKH as default address since version [https://bitcoin.org/en/release/v0.20.0 0.20.0]. Creating P2TR addresses requires manual import for now.<br />
|-<br />
| Bitcoin Knots || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| bcoin || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Electrum || {{Yes}} || {{Yes}} || {{Yes|Since 4.1.0}} || {{Evaluating|??}} || <br />
|-<br />
| Armory || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GreenAddress || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Breadwallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/udiWertheimer/status/975810157941796864<br />
|-<br />
| Samourai Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinomi || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]<br />
|-<br />
| BTC.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Casa || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Mycelium || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Trust Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://trustwallet.com/blog/trust-wallet-adds-support-for-btc-ltc-bch official blog]<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://twitter.com/GuardaWallet/status/1194270398730448896 twitter announcement]<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger Live (desktop app) || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey chrome app || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox Desktop app || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Trezor + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Archos + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coldcard + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ballet + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Tangem + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Web Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Coinapult || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coin.Space || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitGo || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Full support on v2 platform, no plans to add support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9<br />
|-<br />
| blockchain.info web|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/provoost/status/1037802325874761728<br />
|-<br />
| HolyTransaction || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || open source JavaScript implementation<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/GuardaWallet/status/1194270398730448896<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| 1Fox || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://1fox.com/?c=en/content/blog&id=12<br />
|-<br />
| [[AgoraDesk]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Anycoin Direct || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://anycoindirect.eu/en/news/details/segwit-activated<br />
|-<br />
| BitBargain.co.uk || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bitcoin.de || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/<br />
|-<br />
| Bitfinex || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/bitfinex/status/1189164144789983234<br />
|-<br />
| BitMEX || {{yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blog.bitmex.com/bitmex-enables-bech32-sending-support/<br />
|-<br />
| Bittrex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/gqt1m6/bittrex_does_not_even_support_withdrawals_to/<br />
|-<br />
| Bittylicious || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bittylicious_/status/998881327347888128<br />
|-<br />
| Bitstamp || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/<br />
|-<br />
| Bitso || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bitso/status/1203784055340314624?s=20<br />
|-<br />
| Bitwage || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bisq || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || As of v1.5.0 https://bisq.network/blog/bisq-v1.5.0-highlights/<br />
|-<br />
| CEX.IO || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinbase.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/diogorsergio/status/983052769262292992 (Note that Coinbase commerce does not support sending to bech32)<br />
|-<br />
| CoinFalcon || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinfloor || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinfloor.co.uk/hodl/2020/09/16/a-few-updates-from-coinfloor/<br />
|-<br />
| [https://coinmate.io Coinmate.io] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinmate.io/blog/important-coinmate-update/<br />
|-<br />
| Coinsbank.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinygram || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Flyp.me || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GDax || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/<br />
|-<br />
| Gemini || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/<br />
|-<br />
| Genesis || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Globitex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| HitBTC || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Hodl Hodl || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56<br />
|-<br />
| Independent Reserve|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.independentreserve.com/bitcoin/investing<br />
|-<br />
| Itbit || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Kraken || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/krakenfx/status/1060306827848470528<br />
|-<br />
| LedgerX || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Liberalcoins || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://liberalcoins.com<br />
|-<br />
| [[LocalBitcoins]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/LocalBitcoins/status/1322194709159301120<br />
|-<br />
| Paxful.com || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Poloniex.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/<br />
|-<br />
| TheRockTrading.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/TheRockTrading/status/976787499648512003<br />
|-<br />
| Walltime || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://walltime.info<br />
|-<br />
| Purse.io || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| www.bitwala.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Xapo || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Bitcoin ATM Models ===<br />
<br />
Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| GenesisCoin || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| General Bytes || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Depending on configuration. Since version 20190613 https://www.generalbytes.com/en/support/changelog<br />
|-<br />
| Lamassu Douro || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@LamassuSupport/announcing-crafty-chnemu-v7-3-9522fe2868<br />
|}<br />
<br />
=== Blockchain Explorers ===<br />
<br />
For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.<br />
<br />
Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.<br />
<br />
See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Display Bech32 !! Index Bech32 !! Display Bech32m !! Index Bech32m !! Notes<br />
|-<br />
| Apirone.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://apirone.com<br />
|-<br />
| bitaps.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitaps.com<br />
|-<br />
| Bitflyer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chainflyer.bitflyer.jp/<br />
|-<br />
| Bitupper Explorer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitupper.com/en/explorer/bitcoin<br />
|-<br />
| blockchain.info || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Blockchair || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockchair.com/<br />
|-<br />
| Blockcypher || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://live.blockcypher.com/btc<br />
|-<br />
| Blockonomics || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.blockonomics.co<br />
|-<br />
| Blockpath || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockpath.com<br />
|-<br />
| BTC.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://BTC.com<br />
|-<br />
| Esplora || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/<br />
|-<br />
| chaindex || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chaindex.com/blockchain/<br />
|-<br />
| Insight || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances include https://insight.bitpay.com/<br />
|-<br />
| OXT || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://oxt.me/<br />
|-<br />
| Tradeblock || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://tradeblock.com/bitcoin<br />
|}<br />
<br />
=== Payment Processors ===<br />
<br />
<!-- Payment processors in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! P2WPKH/P2WSH Invoices !! Bech32 Withdrawal addresses !! P2TR Invoices !! Bech32m Withdrawal addresses !! Notes<br />
|-<br />
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment notifications, merchant dashboard, plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart<br />
|-<br />
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment forwarding API, Wallet API, fault tolerance callback.<br />
|-<br />
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://confirmo.net CONFIRMO] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Highly customizable Bitcoin and Lightning Network payment gateway. Multi-sig, HD wallets, API, SDK.<br />
|}<br />
<br />
=== Mining Pools ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Payout to Bech32 !! Payout to Bech32m !! Notes<br />
|-<br />
| [https://pool.btc.com/ BTC.com Pool] || {{No}} || {{Evaluating|??}} ||<br />
|-<br />
| [http://ckpool.org/ Ckpool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://kano.is/ KanoPool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=789369.msg53374508#msg53374508 bitcointalk source]<br />
|-<br />
| [http://poolin.com/ Poolin] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]<br />
|-<br />
| [https://slushpool.com/ Slush Pool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]<br />
|-<br />
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
<!--<br />
<br />
=== Other Services ===<br />
<br />
Casinos, marketplaces, etc that let users withdraw money<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Withdrawals !! Notes<br />
|-<br />
| 1Broker || {{Yes}} || <br />
|-<br />
| [https://crypto.games Crypto.Games]|| {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]<br />
|-<br />
| YOLOdice || {{Yes}} ||<br />
|}<br />
<br />
--><br />
<br />
=== References ===<br />
<br />
[[Category:Software]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Bech32_adoption&diff=68735Bech32 adoption2021-07-10T02:44:52Z<p>Sipa: </p>
<hr />
<div>[[Bech32]] is a bitcoin [[address]] format specified by [[BIP 0173]]. It is used for the native segwit version 0 output types, P2WPKH and P2WSH. The upcoming [[Taproot]] softfork will add another output type called Pay to Taproot (P2TR). P2TR outputs and future native segwit versions will be using an updated variant of [[Bech32]], called [[Bech32m]] (specified by [[BIP 0350]]). This page tracks the adoption of [[Bech32]] and [[Bech32m]].<br />
<br />
Ideally wallets and services would first support ''sending to'' new addresses. When most wallets and services support sending to the new address type, people are more likely to adopt it for receiving. <br />
<br />
The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Bitcoin Core || {{Yes|Since 0.16.0}} || {{Yes|Since 0.16.0}} || {{Yes|Since 0.21.1}} || {{Acceptable|Starting with 22.0}} || Uses P2WPKH as default address since version [https://bitcoin.org/en/release/v0.20.0 0.20.0]. Creating P2TR addresses requires manual import for now.<br />
|-<br />
| Bitcoin Knots || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| bcoin || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Armory || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GreenAddress || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Breadwallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/udiWertheimer/status/975810157941796864<br />
|-<br />
| Samourai Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinomi || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]<br />
|-<br />
| BTC.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Casa || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Mycelium || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Trust Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://trustwallet.com/blog/trust-wallet-adds-support-for-btc-ltc-bch official blog]<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://twitter.com/GuardaWallet/status/1194270398730448896 twitter announcement]<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger Live (desktop app) || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey chrome app || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox Desktop app || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Trezor + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Archos + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coldcard + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ballet + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Tangem + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Web Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Coinapult || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coin.Space || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitGo || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Full support on v2 platform, no plans to add support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9<br />
|-<br />
| blockchain.info web|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/provoost/status/1037802325874761728<br />
|-<br />
| HolyTransaction || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || open source JavaScript implementation<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/GuardaWallet/status/1194270398730448896<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| 1Fox || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://1fox.com/?c=en/content/blog&id=12<br />
|-<br />
| [[AgoraDesk]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Anycoin Direct || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://anycoindirect.eu/en/news/details/segwit-activated<br />
|-<br />
| BitBargain.co.uk || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bitcoin.de || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/<br />
|-<br />
| Bitfinex || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/bitfinex/status/1189164144789983234<br />
|-<br />
| BitMEX || {{yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blog.bitmex.com/bitmex-enables-bech32-sending-support/<br />
|-<br />
| Bittrex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/gqt1m6/bittrex_does_not_even_support_withdrawals_to/<br />
|-<br />
| Bittylicious || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bittylicious_/status/998881327347888128<br />
|-<br />
| Bitstamp || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/<br />
|-<br />
| Bitso || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bitso/status/1203784055340314624?s=20<br />
|-<br />
| Bitwage || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bisq || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || As of v1.5.0 https://bisq.network/blog/bisq-v1.5.0-highlights/<br />
|-<br />
| CEX.IO || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinbase.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/diogorsergio/status/983052769262292992 (Note that Coinbase commerce does not support sending to bech32)<br />
|-<br />
| CoinFalcon || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinfloor || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinfloor.co.uk/hodl/2020/09/16/a-few-updates-from-coinfloor/<br />
|-<br />
| [https://coinmate.io Coinmate.io] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinmate.io/blog/important-coinmate-update/<br />
|-<br />
| Coinsbank.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinygram || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Flyp.me || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GDax || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/<br />
|-<br />
| Gemini || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/<br />
|-<br />
| Genesis || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Globitex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| HitBTC || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Hodl Hodl || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56<br />
|-<br />
| Independent Reserve|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.independentreserve.com/bitcoin/investing<br />
|-<br />
| Itbit || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Kraken || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/krakenfx/status/1060306827848470528<br />
|-<br />
| LedgerX || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Liberalcoins || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://liberalcoins.com<br />
|-<br />
| [[LocalBitcoins]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/LocalBitcoins/status/1322194709159301120<br />
|-<br />
| Paxful.com || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Poloniex.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/<br />
|-<br />
| TheRockTrading.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/TheRockTrading/status/976787499648512003<br />
|-<br />
| Walltime || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://walltime.info<br />
|-<br />
| Purse.io || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| www.bitwala.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Xapo || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Bitcoin ATM Models ===<br />
<br />
Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| GenesisCoin || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| General Bytes || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Depending on configuration. Since version 20190613 https://www.generalbytes.com/en/support/changelog<br />
|-<br />
| Lamassu Douro || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@LamassuSupport/announcing-crafty-chnemu-v7-3-9522fe2868<br />
|}<br />
<br />
=== Blockchain Explorers ===<br />
<br />
For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.<br />
<br />
Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.<br />
<br />
See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Display Bech32 !! Index Bech32 !! Display Bech32m !! Index Bech32m !! Notes<br />
|-<br />
| Apirone.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://apirone.com<br />
|-<br />
| bitaps.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitaps.com<br />
|-<br />
| Bitflyer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chainflyer.bitflyer.jp/<br />
|-<br />
| Bitupper Explorer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitupper.com/en/explorer/bitcoin<br />
|-<br />
| blockchain.info || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Blockchair || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockchair.com/<br />
|-<br />
| Blockcypher || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://live.blockcypher.com/btc<br />
|-<br />
| Blockonomics || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.blockonomics.co<br />
|-<br />
| Blockpath || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockpath.com<br />
|-<br />
| BTC.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://BTC.com<br />
|-<br />
| Esplora || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/<br />
|-<br />
| chaindex || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chaindex.com/blockchain/<br />
|-<br />
| Insight || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances include https://insight.bitpay.com/<br />
|-<br />
| OXT || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://oxt.me/<br />
|-<br />
| Tradeblock || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://tradeblock.com/bitcoin<br />
|}<br />
<br />
=== Payment Processors ===<br />
<br />
<!-- Payment processors in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! P2WPKH/P2WSH Invoices !! Bech32 Withdrawal addresses !! P2TR Invoices !! Bech32m Withdrawal addresses !! Notes<br />
|-<br />
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment notifications, merchant dashboard, plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart<br />
|-<br />
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment forwarding API, Wallet API, fault tolerance callback.<br />
|-<br />
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://confirmo.net CONFIRMO] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Highly customizable Bitcoin and Lightning Network payment gateway. Multi-sig, HD wallets, API, SDK.<br />
|}<br />
<br />
=== Mining Pools ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Payout to Bech32 !! Payout to Bech32m !! Notes<br />
|-<br />
| [https://pool.btc.com/ BTC.com Pool] || {{No}} || {{Evaluating|??}} ||<br />
|-<br />
| [http://ckpool.org/ Ckpool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://kano.is/ KanoPool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=789369.msg53374508#msg53374508 bitcointalk source]<br />
|-<br />
| [http://poolin.com/ Poolin] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]<br />
|-<br />
| [https://slushpool.com/ Slush Pool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]<br />
|-<br />
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
<!--<br />
<br />
=== Other Services ===<br />
<br />
Casinos, marketplaces, etc that let users withdraw money<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Withdrawals !! Notes<br />
|-<br />
| 1Broker || {{Yes}} || <br />
|-<br />
| [https://crypto.games Crypto.Games]|| {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]<br />
|-<br />
| YOLOdice || {{Yes}} ||<br />
|}<br />
<br />
--><br />
<br />
=== References ===<br />
<br />
[[Category:Software]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Bech32_adoption&diff=68734Bech32 adoption2021-07-10T02:43:45Z<p>Sipa: </p>
<hr />
<div>[[Bech32]] is a bitcoin [[address]] format specified by [[BIP 0173]]. It is used for the native segwit version 0 output types, P2WPKH and P2WSH. The upcoming [[Taproot]] softfork will add another output type called Pay to Taproot (P2TR). P2TR outputs and future native segwit versions will be using an updated variant of [[Bech32]], called [[Bech32m]] (specified by [[BIP 0350]]). This page tracks the adoption of [[Bech32]] and [[Bech32m]].<br />
<br />
Ideally wallets and services would first support ''sending to'' new addresses. When most wallets and services support sending to the new address type, people are more likely to adopt it for receiving. <br />
<br />
The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Bitcoin Core || {{Yes|Since 0.16.0}} || {{Yes|Since 0.16.0}} || {{Yes|Since 0.21.1}} || {{Acceptable|Starting with 22.0}} || Uses P2WPKH as default address since version [https://bitcoin.org/en/release/v0.20.0 0.20.0]<br />
|-<br />
| Bitcoin Knots || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| bcoin || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Armory || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GreenAddress || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Breadwallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/udiWertheimer/status/975810157941796864<br />
|-<br />
| Samourai Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinomi || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]<br />
|-<br />
| BTC.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Casa || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Mycelium || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Trust Wallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://trustwallet.com/blog/trust-wallet-adds-support-for-btc-ltc-bch official blog]<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || [https://twitter.com/GuardaWallet/status/1194270398730448896 twitter announcement]<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger Live (desktop app) || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey chrome app || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox Desktop app || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Trezor + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ledger + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitBox + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| KeepKey + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Archos + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coldcard + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Ballet + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Tangem + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Web Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| Coinapult || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coin.Space || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| BitGo || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Full support on v2 platform, no plans to add support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9<br />
|-<br />
| blockchain.info web|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/provoost/status/1037802325874761728<br />
|-<br />
| HolyTransaction || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || open source JavaScript implementation<br />
|-<br />
| Guarda Wallet || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/GuardaWallet/status/1194270398730448896<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| 1Fox || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://1fox.com/?c=en/content/blog&id=12<br />
|-<br />
| [[AgoraDesk]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Anycoin Direct || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://anycoindirect.eu/en/news/details/segwit-activated<br />
|-<br />
| BitBargain.co.uk || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bitcoin.de || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/<br />
|-<br />
| Bitfinex || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/bitfinex/status/1189164144789983234<br />
|-<br />
| BitMEX || {{yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blog.bitmex.com/bitmex-enables-bech32-sending-support/<br />
|-<br />
| Bittrex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/gqt1m6/bittrex_does_not_even_support_withdrawals_to/<br />
|-<br />
| Bittylicious || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bittylicious_/status/998881327347888128<br />
|-<br />
| Bitstamp || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/<br />
|-<br />
| Bitso || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bitso/status/1203784055340314624?s=20<br />
|-<br />
| Bitwage || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Bisq || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || As of v1.5.0 https://bisq.network/blog/bisq-v1.5.0-highlights/<br />
|-<br />
| CEX.IO || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinbase.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/diogorsergio/status/983052769262292992 (Note that Coinbase commerce does not support sending to bech32)<br />
|-<br />
| CoinFalcon || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinfloor || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinfloor.co.uk/hodl/2020/09/16/a-few-updates-from-coinfloor/<br />
|-<br />
| [https://coinmate.io Coinmate.io] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinmate.io/blog/important-coinmate-update/<br />
|-<br />
| Coinsbank.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Coinygram || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Flyp.me || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| GDax || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/<br />
|-<br />
| Gemini || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/<br />
|-<br />
| Genesis || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Globitex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| HitBTC || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Hodl Hodl || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56<br />
|-<br />
| Independent Reserve|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.independentreserve.com/bitcoin/investing<br />
|-<br />
| Itbit || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Kraken || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/krakenfx/status/1060306827848470528<br />
|-<br />
| LedgerX || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || <br />
|-<br />
| Liberalcoins || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://liberalcoins.com<br />
|-<br />
| [[LocalBitcoins]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/LocalBitcoins/status/1322194709159301120<br />
|-<br />
| Paxful.com || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Poloniex.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/<br />
|-<br />
| TheRockTrading.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/TheRockTrading/status/976787499648512003<br />
|-<br />
| Walltime || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://walltime.info<br />
|-<br />
| Purse.io || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| www.bitwala.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Xapo || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
=== Bitcoin ATM Models ===<br />
<br />
Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes<br />
|-<br />
| GenesisCoin || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| General Bytes || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Depending on configuration. Since version 20190613 https://www.generalbytes.com/en/support/changelog<br />
|-<br />
| Lamassu Douro || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@LamassuSupport/announcing-crafty-chnemu-v7-3-9522fe2868<br />
|}<br />
<br />
=== Blockchain Explorers ===<br />
<br />
For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.<br />
<br />
Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.<br />
<br />
See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Display Bech32 !! Index Bech32 !! Display Bech32m !! Index Bech32m !! Notes<br />
|-<br />
| Apirone.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://apirone.com<br />
|-<br />
| bitaps.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitaps.com<br />
|-<br />
| Bitflyer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chainflyer.bitflyer.jp/<br />
|-<br />
| Bitupper Explorer || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://bitupper.com/en/explorer/bitcoin<br />
|-<br />
| blockchain.info || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| Blockchair || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockchair.com/<br />
|-<br />
| Blockcypher || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://live.blockcypher.com/btc<br />
|-<br />
| Blockonomics || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.blockonomics.co<br />
|-<br />
| Blockpath || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://blockpath.com<br />
|-<br />
| BTC.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://BTC.com<br />
|-<br />
| Esplora || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/<br />
|-<br />
| chaindex || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://chaindex.com/blockchain/<br />
|-<br />
| Insight || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || Open source explorer, instances include https://insight.bitpay.com/<br />
|-<br />
| OXT || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://oxt.me/<br />
|-<br />
| Tradeblock || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://tradeblock.com/bitcoin<br />
|}<br />
<br />
=== Payment Processors ===<br />
<br />
<!-- Payment processors in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! P2WPKH/P2WSH Invoices !! Bech32 Withdrawal addresses !! P2TR Invoices !! Bech32m Withdrawal addresses !! Notes<br />
|-<br />
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment notifications, merchant dashboard, plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart<br />
|-<br />
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment forwarding API, Wallet API, fault tolerance callback.<br />
|-<br />
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://confirmo.net CONFIRMO] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Highly customizable Bitcoin and Lightning Network payment gateway. Multi-sig, HD wallets, API, SDK.<br />
|}<br />
<br />
=== Mining Pools ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Payout to Bech32 !! Payout to Bech32m !! Notes<br />
|-<br />
| [https://pool.btc.com/ BTC.com Pool] || {{No}} || {{Evaluating|??}} ||<br />
|-<br />
| [http://ckpool.org/ Ckpool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://kano.is/ KanoPool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=789369.msg53374508#msg53374508 bitcointalk source]<br />
|-<br />
| [http://poolin.com/ Poolin] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]<br />
|-<br />
| [https://slushpool.com/ Slush Pool] || {{Yes}} || {{Evaluating|??}} ||<br />
|-<br />
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]<br />
|-<br />
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} || {{Evaluating|??}} ||<br />
|}<br />
<br />
<!--<br />
<br />
=== Other Services ===<br />
<br />
Casinos, marketplaces, etc that let users withdraw money<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Withdrawals !! Notes<br />
|-<br />
| 1Broker || {{Yes}} || <br />
|-<br />
| [https://crypto.games Crypto.Games]|| {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]<br />
|-<br />
| YOLOdice || {{Yes}} ||<br />
|}<br />
<br />
--><br />
<br />
=== References ===<br />
<br />
[[Category:Software]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Segwit_support&diff=63344Segwit support2017-06-12T19:58:27Z<p>Sipa: </p>
<hr />
<div><big><big>'''PLEASE NOTE:''' This list is not yet complete, nor completely vetted by the parties listed for accuracy.</big></big><br />
<br />
'''Developers: Please edit your row (add one if you're missing) to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''<br />
<br />
{| class="wikitable"<br />
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)<br />
|-<br />
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Evaluating}} || still evaluating the idea<br />
|-<br />
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Weak}} || better than nothing at all<br />
|-<br />
| {{Acceptable}} || it is a workable solution<br />
|-<br />
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences<br />
|}<br />
<br />
<!-- README: please keep alphabetically ordered by surname! --><br />
<br />
''Note that support for BIP148 does not mean developers support merging it into Core.''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 colspan=2 | Developer & affiliation* <!-- Using one year before the the creation date of this page as the benchmark. Do not list yourself as affiliated with a project that you haven't made meaningful contributions to since then. --><br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| ฿tcDrak || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Bryan Bishop || || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Andrew Chow || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Matt Corallo || Core || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||<br />
|-<br />
| Johnathan Corgan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Luke Dashjr || Core || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No}} || {{Deficient}}<br />
|-<br />
| Christian Decker || Core || {{Prefer}} || {{Acceptable}} || || || || <br />
|-<br />
| Nicolas Dorier || Core || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Marco Falke || Core || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Michael Ford || Core || {{Prefer}} || || || || ||<br />
|-<br />
| Mark Friedenbach || BIP 68/112 || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No|LOL}} || {{No|Nope}}<br />
|-<br />
| Pavel Janik || Core || {{Prefer}} || {{No}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Thomas Kerin || Core || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Johnson Lau || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || ||<br />
|-<br />
| Eric Lombrozo || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Greg Maxwell || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Alex Morcos || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Pavol "stick" Rusnak || Trezor || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Rusty Russell || c-lightning || {{Prefer}} || {{Prefer}} || || || ||<br />
|-<br />
| Gregory Sanders || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Jonas Schnelli || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Patrick Strateman || Core || {{Prefer}} || || || || ||<br />
|-<br />
| Jorge Timon || Core || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}<br />
|-<br />
| Peter Todd || Core || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Warren Togami || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||<br />
|-<br />
| Wladimir van der Laan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| flix1 || || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}}<br />
|-<br />
| Leo Wandersleb || Mycelium || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Pieter Wuille || Core || {{Prefer}} || || || || {{No}} ||<br />
|}<br />
<br />
* "affiliation" is an optional field for the company or project the individual is associated with, that most qualifies the person to comment on the matter and is not meant as a company or project endorsement of the individual's position.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Segwit_support&diff=63343Segwit support2017-06-12T19:56:54Z<p>Sipa: </p>
<hr />
<div><big><big>'''PLEASE NOTE:''' This list is not yet complete, nor completely vetted by the parties listed for accuracy.</big></big><br />
<br />
'''Developers: Please edit your row (add one if you're missing) to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''<br />
<br />
{| class="wikitable"<br />
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)<br />
|-<br />
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Evaluating}} || still evaluating the idea<br />
|-<br />
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Weak}} || better than nothing at all<br />
|-<br />
| {{Acceptable}} || it is a workable solution<br />
|-<br />
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences<br />
|}<br />
<br />
<!-- README: please keep alphabetically ordered by surname! --><br />
<br />
''Note that support for BIP148 does not mean developers support merging it into Core.''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 colspan=2 | Developer & affiliation* <!-- Using one year before the the creation date of this page as the benchmark. Do not list yourself as affiliated with a project that you haven't made meaningful contributions to since then. --><br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| ฿tcDrak || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Bryan Bishop || || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Andrew Chow || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Matt Corallo || Core || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||<br />
|-<br />
| Johnathan Corgan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Luke Dashjr || Core || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No}} || {{Deficient}}<br />
|-<br />
| Christian Decker || Core || {{Prefer}} || {{Acceptable}} || || || || <br />
|-<br />
| Nicolas Dorier || Core || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Marco Falke || Core || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Michael Ford || Core || {{Prefer}} || || || || ||<br />
|-<br />
| Mark Friedenbach || BIP 68/112 || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No|LOL}} || {{No|Nope}}<br />
|-<br />
| Pavel Janik || Core || {{Prefer}} || {{No}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Thomas Kerin || Core || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Johnson Lau || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || ||<br />
|-<br />
| Eric Lombrozo || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Greg Maxwell || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Alex Morcos || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Pavol "stick" Rusnak || Trezor || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Rusty Russell || c-lightning || {{Prefer}} || {{Prefer}} || || || ||<br />
|-<br />
| Gregory Sanders || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Jonas Schnelli || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Patrick Strateman || Core || {{Prefer}} || || || || ||<br />
|-<br />
| Jorge Timon || Core || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}<br />
|-<br />
| Peter Todd || Core || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Warren Togami || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||<br />
|-<br />
| Wladimir van der Laan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| flix1 || || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}}<br />
|-<br />
| Leo Wandersleb || Mycelium || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Pieter Wuille || Core || {{Prefer}} || || || || {{No}} || {{No}}<br />
|}<br />
<br />
* "affiliation" is an optional field for the company or project the individual is associated with, that most qualifies the person to comment on the matter and is not meant as a company or project endorsement of the individual's position.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Segwit_support&diff=63342Segwit support2017-06-12T19:56:19Z<p>Sipa: </p>
<hr />
<div><big><big>'''PLEASE NOTE:''' This list is not yet complete, nor completely vetted by the parties listed for accuracy.</big></big><br />
<br />
'''Developers: Please edit your row (add one if you're missing) to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''<br />
<br />
{| class="wikitable"<br />
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)<br />
|-<br />
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Evaluating}} || still evaluating the idea<br />
|-<br />
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Weak}} || better than nothing at all<br />
|-<br />
| {{Acceptable}} || it is a workable solution<br />
|-<br />
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences<br />
|}<br />
<br />
<!-- README: please keep alphabetically ordered by surname! --><br />
<br />
''Note that support for BIP148 does not mean developers support merging it into Core.''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 colspan=2 | Developer & affiliation* <!-- Using one year before the the creation date of this page as the benchmark. Do not list yourself as affiliated with a project that you haven't made meaningful contributions to since then. --><br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| ฿tcDrak || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Bryan Bishop || || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Andrew Chow || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Matt Corallo || Core || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||<br />
|-<br />
| Johnathan Corgan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Luke Dashjr || Core || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No}} || {{Deficient}}<br />
|-<br />
| Christian Decker || Core || {{Prefer}} || {{Acceptable}} || || || || <br />
|-<br />
| Nicolas Dorier || Core || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Marco Falke || Core || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Michael Ford || Core || {{Prefer}} || || || || ||<br />
|-<br />
| Mark Friedenbach || BIP 68/112 || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No|LOL}} || {{No|Nope}}<br />
|-<br />
| Pavel Janik || Core || {{Prefer}} || {{No}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Thomas Kerin || Core || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Johnson Lau || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || ||<br />
|-<br />
| Eric Lombrozo || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Greg Maxwell || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Alex Morcos || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Pavol "stick" Rusnak || Trezor || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Rusty Russell || c-lightning || {{Prefer}} || {{Prefer}} || || || ||<br />
|-<br />
| Gregory Sanders || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Jonas Schnelli || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Patrick Strateman || Core || {{Prefer}} || || || || ||<br />
|-<br />
| Jorge Timon || Core || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}<br />
|-<br />
| Peter Todd || Core || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Warren Togami || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||<br />
|-<br />
| Wladimir van der Laan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| flix1 || || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}}<br />
|-<br />
| Leo Wandersleb || Mycelium || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Pieter Wuille || Core || {{Prefer}} || || || || || {{No}} || {{No}}<br />
|}<br />
<br />
* "affiliation" is an optional field for the company or project the individual is associated with, that most qualifies the person to comment on the matter and is not meant as a company or project endorsement of the individual's position.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Segwit_support&diff=62907Segwit support2017-06-07T18:20:03Z<p>Sipa: </p>
<hr />
<div><big><big>'''PLEASE NOTE:''' This list is not yet complete, nor completely vetted by the parties listed for accuracy.</big></big><br />
<br />
'''Developers: Please edit your row (add one if you're missing) to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr to give it access.'''<br />
<br />
{| class="wikitable"<br />
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)<br />
|-<br />
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Evaluating}} || still evaluating the idea<br />
|-<br />
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Weak}} || better than nothing at all<br />
|-<br />
| {{Acceptable}} || it is a workable solution<br />
|-<br />
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences<br />
|}<br />
<br />
<!-- README: please keep alphabetically ordered by surname! --><br />
<br />
''Note that support for BIP148 does not mean developers support merging it into Core.''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 | Developer<br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| ฿tcDrak || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || ||<br />
|-<br />
| Andrew Chow || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Matt Corallo || {{Prefer}} || {{No}} || || {{Acceptable}} || ||<br />
|-<br />
| Johnathan Corgan || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{Evaluating}}<br />
|-<br />
| Suhas Daftuar || {{Prefer}} || {{No}} || || || ||<br />
|-<br />
| Luke Dashjr || {{Prefer}} || {{Prefer}} || {{Weak}} || {{Acceptable}} || {{No}} || {{Deficient}}<br />
|-<br />
| Christian Decker || {{Prefer}} || {{Acceptable}} || || || || <br />
|-<br />
| Nicolas Dorier || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Marco Falke || {{Prefer}} || || || || ||<br />
|-<br />
| Michael Ford || {{Prefer}} || || || || ||<br />
|-<br />
| Mark Friedenbach || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Pavel Janik || {{Prefer}} || || || || ||<br />
|-<br />
| Johnson Lau || {{Prefer}} || || || || ||<br />
|-<br />
| Eric Lombrozo || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{No}} || {{Evaluating}} || {{Evaluating}}<br />
|-<br />
| Greg Maxwell || {{Prefer}} || {{No}} || {{Acceptable}} || || ||<br />
|-<br />
| Alex Morcos || {{Prefer}} || {{No}} || || || ||<br />
|-<br />
| Rusty Russell || {{Prefer}} || {{Prefer}} || || || ||<br />
|-<br />
| Jonas Schnelli || {{Prefer}} || {{Wanting}} || {{Acceptable}} || || ||<br />
|-<br />
| Patrick Strateman || {{Prefer}} || || || || ||<br />
|-<br />
| Jorge Timon || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{Evaluating}} ||<br />
|-<br />
| Peter Todd || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Wladimir van der Laan || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|}</div>Sipahttps://tests.bitcoin.it/w/index.php?title=IRC_channels&diff=47202IRC channels2014-05-09T22:49:48Z<p>Sipa: </p>
<hr />
<div>Most of the following Bitcoin-related IRC channels are available on [http://www.freenode.net Freenode]:<br />
<br />
==Bitcoin Project==<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bc-news}} || RSS News related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion ([[Bitcoin_IRC_Channel_Guidelines | guidelines]]).<br />
|-<br />
| {{Freenode IRC|bitcoin-bots}} || Bot and bot-related discussion; trading bots, IRC bots, utility bots.<br />
|-<br />
| {{Freenode IRC|bitcoin-court}} || [[Bitcoin Court]] Settles disputes between parties.<br />
|-<br />
| {{Freenode IRC|bitcoin-dev}} || Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])<br />
|-<br />
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.<br />
|-<br />
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.<br />
|-<br />
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin<br />
|-<br />
| {{Freenode IRC|bitcoin-police}} || [[Bitcoin Police]] Investigates incidents related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.<br />
|-<br />
| {{Freenode IRC|bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price goes here<br />
|-<br />
| {{Freenode IRC|bitcoin-tweets}} || Automated announce of bitcoin-related tweets.<br />
|-<br />
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.<br />
|}<br />
<br />
===Local communities===<br />
<br />
{| class="wikitable"<br />
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.<br />
|-<br />
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-br}} || Brazilian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community. <br />
|-<br />
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.<br />
|-<br />
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.<br />
<br />
|}<br />
<br />
==Mining Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine<br />
|-<br />
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.<br />
|-<br />
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.<br />
|-<br />
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]] mining ASIC/FPGA/GPU.<br />
|-<br />
| {{Freenode IRC|btc.chat.miners}} || Russian discussion of mining specification.<br />
|-<br />
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])<br />
|-<br />
| {{Freenode IRC|give-me-coins}} || [[Give Me COINS]] mining pool community<br />
|-<br />
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community<br />
|-<br />
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]<br />
|-<br />
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool] <br />
|-<br />
| {{Freenode IRC|bithasher}} || Bit Pool Mining<br />
|-<br />
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool<br />
|-<br />
| {{Freenode IRC|btcserv}} || [[Btcserv.net]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion<br />
|}<br />
<br />
==Communities for Exchanges and Trading==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].<br />
|-<br />
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.<br />
|-<br />
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-aud}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-bgn}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-brl}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-cad}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-chf}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-eur}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-gbp}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-hkd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-inr}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-jpy}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-nzd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-pln}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-rub}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-sek}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-sgd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-sll}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-thb}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-usd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-zar}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])<br />
|-<br />
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.<br />
|-<br />
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers}} || Bitcoin tickers for all bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-aud}} || Bitcoin tickers for AUD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-bgn}} || Bitcoin tickers for BGN bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-brl}} || Bitcoin tickers for BRL bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-cad}} || Bitcoin tickers for CAD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-chf}} || Bitcoin tickers for CHF bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-eur}} || Bitcoin tickers for EUR bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-gbp}} || Bitcoin tickers for GBP bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-hkd}} || Bitcoin tickers for HKD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-inr}} || Bitcoin tickers for INR bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-jpy}} || Bitcoin tickers for JPY bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-nzd}} || Bitcoin tickers for NZD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-pln}} || Bitcoin tickers for PLN bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-rub}} || Bitcoin tickers for RUB bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-sek}} || Bitcoin tickers for SEK bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-sgd}} || Bitcoin tickers for SGD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-sll}} || Bitcoin tickers for SLL bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-thb}} || Bitcoin tickers for THB bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-usd}} || Bitcoin tickers for USD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-zar}} || Bitcoin tickers for ZAR bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].<br />
|-<br />
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.<br />
|-<br />
| {{Freenode IRC|#mtgox-chat}} || [[#MtGox]] chat (Note the pound sign (#) is part of the channel name)<br />
|-<br />
| {{Freenode IRC|mtgox}} || [[MtGox]] support<br />
|-<br />
| {{Freenode IRC|mtgoxlive}} || [[MtGox Live]] real-time view of trading<br />
|-<br />
| {{Freenode IRC|mtgox-news}} || Mt. Gox topics from Twitter.<br />
|-<br />
| {{Freenode IRC|mtgox-rt}} || Mt. Gox real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support<br />
|-<br />
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.<br />
|}<br />
<br />
==Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.<br />
|-<br />
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.<br />
|-<br />
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.<br />
|-<br />
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.<br />
|-<br />
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].<br />
<br />
|}<br />
<br />
[[pl:Kanały IRC]]<br />
[[ro:Canale]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=IRC_channels&diff=47201IRC channels2014-05-09T22:46:50Z<p>Sipa: </p>
<hr />
<div>Most of the following Bitcoin-related IRC channels are available on [http://www.freenode.net Freenode]:<br />
<br />
==Bitcoin Project==<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bc-news}} || RSS News related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion.<br />
|-<br />
| {{Freenode IRC|bitcoin-bots}} || Bot and bot-related discussion; trading bots, IRC bots, utility bots.<br />
|-<br />
| {{Freenode IRC|bitcoin-court}} || [[Bitcoin Court]] Settles disputes between parties.<br />
|-<br />
| {{Freenode IRC|bitcoin-dev}} || Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history], [[Bitcoin_IRC_Channel_Guidelines | guidelines]])<br />
|-<br />
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.<br />
|-<br />
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.<br />
|-<br />
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin<br />
|-<br />
| {{Freenode IRC|bitcoin-police}} || [[Bitcoin Police]] Investigates incidents related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.<br />
|-<br />
| {{Freenode IRC|bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price goes here<br />
|-<br />
| {{Freenode IRC|bitcoin-tweets}} || Automated announce of bitcoin-related tweets.<br />
|-<br />
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.<br />
|}<br />
<br />
===Local communities===<br />
<br />
{| class="wikitable"<br />
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.<br />
|-<br />
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-br}} || Brazilian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community. <br />
|-<br />
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.<br />
|-<br />
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.<br />
<br />
|}<br />
<br />
==Mining Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine<br />
|-<br />
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.<br />
|-<br />
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.<br />
|-<br />
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]] mining ASIC/FPGA/GPU.<br />
|-<br />
| {{Freenode IRC|btc.chat.miners}} || Russian discussion of mining specification.<br />
|-<br />
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])<br />
|-<br />
| {{Freenode IRC|give-me-coins}} || [[Give Me COINS]] mining pool community<br />
|-<br />
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community<br />
|-<br />
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]<br />
|-<br />
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool] <br />
|-<br />
| {{Freenode IRC|bithasher}} || Bit Pool Mining<br />
|-<br />
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool<br />
|-<br />
| {{Freenode IRC|btcserv}} || [[Btcserv.net]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion<br />
|}<br />
<br />
==Communities for Exchanges and Trading==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].<br />
|-<br />
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.<br />
|-<br />
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-aud}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-bgn}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-brl}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-cad}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-chf}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-eur}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-gbp}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-hkd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-inr}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-jpy}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-nzd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-pln}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-rub}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-sek}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-sgd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-sll}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-thb}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-usd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-zar}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])<br />
|-<br />
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.<br />
|-<br />
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers}} || Bitcoin tickers for all bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-aud}} || Bitcoin tickers for AUD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-bgn}} || Bitcoin tickers for BGN bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-brl}} || Bitcoin tickers for BRL bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-cad}} || Bitcoin tickers for CAD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-chf}} || Bitcoin tickers for CHF bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-eur}} || Bitcoin tickers for EUR bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-gbp}} || Bitcoin tickers for GBP bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-hkd}} || Bitcoin tickers for HKD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-inr}} || Bitcoin tickers for INR bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-jpy}} || Bitcoin tickers for JPY bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-nzd}} || Bitcoin tickers for NZD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-pln}} || Bitcoin tickers for PLN bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-rub}} || Bitcoin tickers for RUB bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-sek}} || Bitcoin tickers for SEK bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-sgd}} || Bitcoin tickers for SGD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-sll}} || Bitcoin tickers for SLL bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-thb}} || Bitcoin tickers for THB bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-usd}} || Bitcoin tickers for USD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-zar}} || Bitcoin tickers for ZAR bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].<br />
|-<br />
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.<br />
|-<br />
| {{Freenode IRC|#mtgox-chat}} || [[#MtGox]] chat (Note the pound sign (#) is part of the channel name)<br />
|-<br />
| {{Freenode IRC|mtgox}} || [[MtGox]] support<br />
|-<br />
| {{Freenode IRC|mtgoxlive}} || [[MtGox Live]] real-time view of trading<br />
|-<br />
| {{Freenode IRC|mtgox-news}} || Mt. Gox topics from Twitter.<br />
|-<br />
| {{Freenode IRC|mtgox-rt}} || Mt. Gox real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support<br />
|-<br />
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.<br />
|}<br />
<br />
==Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.<br />
|-<br />
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.<br />
|-<br />
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.<br />
|-<br />
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.<br />
|-<br />
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].<br />
<br />
|}<br />
<br />
[[pl:Kanały IRC]]<br />
[[ro:Canale]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=IRC_channels&diff=47200IRC channels2014-05-09T22:46:23Z<p>Sipa: Link to guidelines.</p>
<hr />
<div>Most of the following Bitcoin-related IRC channels are available on [http://www.freenode.net Freenode]:<br />
<br />
==Bitcoin Project==<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bc-news}} || RSS News related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion.<br />
|-<br />
| {{Freenode IRC|bitcoin-bots}} || Bot and bot-related discussion; trading bots, IRC bots, utility bots.<br />
|-<br />
| {{Freenode IRC|bitcoin-court}} || [[Bitcoin Court]] Settles disputes between parties.<br />
|-<br />
| {{Freenode IRC|bitcoin-dev}} || Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history], [[Bitcoin_IRC_Channel_Guidelines guidelines]])<br />
|-<br />
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.<br />
|-<br />
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.<br />
|-<br />
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin<br />
|-<br />
| {{Freenode IRC|bitcoin-police}} || [[Bitcoin Police]] Investigates incidents related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.<br />
|-<br />
| {{Freenode IRC|bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price goes here<br />
|-<br />
| {{Freenode IRC|bitcoin-tweets}} || Automated announce of bitcoin-related tweets.<br />
|-<br />
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.<br />
|}<br />
<br />
===Local communities===<br />
<br />
{| class="wikitable"<br />
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.<br />
|-<br />
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-br}} || Brazilian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community. <br />
|-<br />
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.<br />
|-<br />
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.<br />
<br />
|}<br />
<br />
==Mining Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine<br />
|-<br />
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.<br />
|-<br />
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.<br />
|-<br />
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]] mining ASIC/FPGA/GPU.<br />
|-<br />
| {{Freenode IRC|btc.chat.miners}} || Russian discussion of mining specification.<br />
|-<br />
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])<br />
|-<br />
| {{Freenode IRC|give-me-coins}} || [[Give Me COINS]] mining pool community<br />
|-<br />
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community<br />
|-<br />
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]<br />
|-<br />
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool] <br />
|-<br />
| {{Freenode IRC|bithasher}} || Bit Pool Mining<br />
|-<br />
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool<br />
|-<br />
| {{Freenode IRC|btcserv}} || [[Btcserv.net]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion<br />
|}<br />
<br />
==Communities for Exchanges and Trading==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].<br />
|-<br />
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.<br />
|-<br />
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-aud}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-bgn}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-brl}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-cad}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-chf}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-eur}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-gbp}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-hkd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-inr}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-jpy}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-nzd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-pln}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-rub}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-sek}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-sgd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-sll}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-thb}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-usd}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-markets-zar}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])<br />
|-<br />
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.<br />
|-<br />
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers}} || Bitcoin tickers for all bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-aud}} || Bitcoin tickers for AUD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-bgn}} || Bitcoin tickers for BGN bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-brl}} || Bitcoin tickers for BRL bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-cad}} || Bitcoin tickers for CAD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-chf}} || Bitcoin tickers for CHF bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-eur}} || Bitcoin tickers for EUR bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-gbp}} || Bitcoin tickers for GBP bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-hkd}} || Bitcoin tickers for HKD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-inr}} || Bitcoin tickers for INR bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-jpy}} || Bitcoin tickers for JPY bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-nzd}} || Bitcoin tickers for NZD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-pln}} || Bitcoin tickers for PLN bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-rub}} || Bitcoin tickers for RUB bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-sek}} || Bitcoin tickers for SEK bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-sgd}} || Bitcoin tickers for SGD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-sll}} || Bitcoin tickers for SLL bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-thb}} || Bitcoin tickers for THB bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-usd}} || Bitcoin tickers for USD bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-tickers-zar}} || Bitcoin tickers for ZAR bitcoin markets<br />
|-<br />
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].<br />
|-<br />
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.<br />
|-<br />
| {{Freenode IRC|#mtgox-chat}} || [[#MtGox]] chat (Note the pound sign (#) is part of the channel name)<br />
|-<br />
| {{Freenode IRC|mtgox}} || [[MtGox]] support<br />
|-<br />
| {{Freenode IRC|mtgoxlive}} || [[MtGox Live]] real-time view of trading<br />
|-<br />
| {{Freenode IRC|mtgox-news}} || Mt. Gox topics from Twitter.<br />
|-<br />
| {{Freenode IRC|mtgox-rt}} || Mt. Gox real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support<br />
|-<br />
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.<br />
|}<br />
<br />
==Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.<br />
|-<br />
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.<br />
|-<br />
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.<br />
|-<br />
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.<br />
|-<br />
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].<br />
<br />
|}<br />
<br />
[[pl:Kanały IRC]]<br />
[[ro:Canale]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=URI_Scheme&diff=42671URI Scheme2013-11-27T00:07:59Z<p>Sipa: Enough confusion, this page has caused.</p>
<hr />
<div>#REDIRECT [[BIP_0021]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0050&diff=40484BIP 00502013-08-25T23:07:17Z<p>Sipa: /* Resolution */</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 50<br />
Title: March 2013 Chain Fork Post-Mortem<br />
Author: Gavin Andresen <gavinandresen@gmail.com><br />
Status: Draft<br />
Type: Informational<br />
Created: 20-03-2013<br />
</pre><br />
<br />
==What went wrong==<br />
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 hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.<br />
<br />
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. This placed majority hashpower on the chain without the larger block.<br />
<br />
During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.<br />
<br />
==What went right==<br />
* The split was detected very quickly.<br />
* The right people were online and available in IRC or could be raised via Skype.<br />
* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.<br />
* Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.<br />
* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money<br />
<br />
==Root cause==<br />
Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:<br />
<br />
:The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.<br />
<br />
Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.<br />
<br />
Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.<br />
<br />
Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.<br />
<br />
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).<br />
<br />
==Action items==<br />
<br />
===Immediately===<br />
<br />
'''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:<br />
# Reject blocks that could cause more than 10,000 locks to be taken.<br />
# Limit the maximum block-size created to 500,000 bytes<br />
# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000<br />
# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.<br />
# Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.<br />
<br />
===Alert system===<br />
<br />
'''Done''': Review who has access to the alert system keys, make sure they all have contact information for each other, and get good timezone overlap by people with access to the keys.<br />
<br />
'''Done''': Implement a new bitcoind feature so services can get timely notification of alerts: -alertnotify=<command> Run command when an AppliesToMe() alert is received.<br />
<br />
'''Done''': Pre-generate 52 test alerts, and set a time every week when they are broadcast on -testnet (so -alertnotify scripts can be tested in as-close-to-real-world conditions as possible).<br />
<br />
Idea from Michael Gronager: encourage merchants/exchanges (and maybe pools) to run new code behind a bitcoind running the network-majority version.<br />
<br />
===Safe mode===<br />
<br />
'''Done''': Perhaps trigger an alert if there is a long enough side chain detected, even if it is not the main chain. Pools could use this to automatically suspend payouts if a long side-chain suddenly appeared out of nowhere (it’s hard for an attacker to mine such a thing).<br />
<br />
===Testing===<br />
<br />
Start running bots on the testnet that grab some coins from a testnet faucet, generate large numbers of random transactions that split/recombine them and then send them back to the faucet. Randomized online testing on the testnet might have revealed the pathological block type earlier.<br />
<br />
===Double spending===<br />
<br />
A double spend attack was successful, despite that both sides of the chain heard about the transactions in the same order. The reason is most likely that the memory pools were cleared when the mining pool nodes were downgraded. A solution is for nodes to sync their mempools to each other at startup, however, this requires a memory pool expiry policy to be implemented as currently node restarts are the only way for unconfirmed transactions to be evicted from the system.<br />
<br />
===Resolution===<br />
<br />
On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0050&diff=40483BIP 00502013-08-25T23:01:39Z<p>Sipa: /* Resolution */</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 50<br />
Title: March 2013 Chain Fork Post-Mortem<br />
Author: Gavin Andresen <gavinandresen@gmail.com><br />
Status: Draft<br />
Type: Informational<br />
Created: 20-03-2013<br />
</pre><br />
<br />
==What went wrong==<br />
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 hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.<br />
<br />
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. This placed majority hashpower on the chain without the larger block.<br />
<br />
During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.<br />
<br />
==What went right==<br />
* The split was detected very quickly.<br />
* The right people were online and available in IRC or could be raised via Skype.<br />
* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.<br />
* Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.<br />
* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money<br />
<br />
==Root cause==<br />
Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:<br />
<br />
:The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.<br />
<br />
Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.<br />
<br />
Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.<br />
<br />
Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.<br />
<br />
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).<br />
<br />
==Action items==<br />
<br />
===Immediately===<br />
<br />
'''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:<br />
# Reject blocks that could cause more than 10,000 locks to be taken.<br />
# Limit the maximum block-size created to 500,000 bytes<br />
# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000<br />
# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.<br />
# Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.<br />
<br />
===Alert system===<br />
<br />
'''Done''': Review who has access to the alert system keys, make sure they all have contact information for each other, and get good timezone overlap by people with access to the keys.<br />
<br />
'''Done''': Implement a new bitcoind feature so services can get timely notification of alerts: -alertnotify=<command> Run command when an AppliesToMe() alert is received.<br />
<br />
'''Done''': Pre-generate 52 test alerts, and set a time every week when they are broadcast on -testnet (so -alertnotify scripts can be tested in as-close-to-real-world conditions as possible).<br />
<br />
Idea from Michael Gronager: encourage merchants/exchanges (and maybe pools) to run new code behind a bitcoind running the network-majority version.<br />
<br />
===Safe mode===<br />
<br />
'''Done''': Perhaps trigger an alert if there is a long enough side chain detected, even if it is not the main chain. Pools could use this to automatically suspend payouts if a long side-chain suddenly appeared out of nowhere (it’s hard for an attacker to mine such a thing).<br />
<br />
===Testing===<br />
<br />
Start running bots on the testnet that grab some coins from a testnet faucet, generate large numbers of random transactions that split/recombine them and then send them back to the faucet. Randomized online testing on the testnet might have revealed the pathological block type earlier.<br />
<br />
===Double spending===<br />
<br />
A double spend attack was successful, despite that both sides of the chain heard about the transactions in the same order. The reason is most likely that the memory pools were cleared when the mining pool nodes were downgraded. A solution is for nodes to sync their mempools to each other at startup, however, this requires a memory pool expiry policy to be implemented as currently node restarts are the only way for unconfirmed transactions to be evicted from the system.<br />
<br />
===Resolution===<br />
<br />
On 16 August, 2013 block 252,451 was accepted by the main network, forking unpatched nodes off the network.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0050&diff=40482BIP 00502013-08-25T23:00:55Z<p>Sipa: /* Resolution */</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 50<br />
Title: March 2013 Chain Fork Post-Mortem<br />
Author: Gavin Andresen <gavinandresen@gmail.com><br />
Status: Draft<br />
Type: Informational<br />
Created: 20-03-2013<br />
</pre><br />
<br />
==What went wrong==<br />
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 hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.<br />
<br />
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. This placed majority hashpower on the chain without the larger block.<br />
<br />
During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.<br />
<br />
==What went right==<br />
* The split was detected very quickly.<br />
* The right people were online and available in IRC or could be raised via Skype.<br />
* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.<br />
* Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.<br />
* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money<br />
<br />
==Root cause==<br />
Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:<br />
<br />
:The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.<br />
<br />
Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.<br />
<br />
Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.<br />
<br />
Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.<br />
<br />
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).<br />
<br />
==Action items==<br />
<br />
===Immediately===<br />
<br />
'''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:<br />
# Reject blocks that could cause more than 10,000 locks to be taken.<br />
# Limit the maximum block-size created to 500,000 bytes<br />
# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000<br />
# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.<br />
# Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.<br />
<br />
===Alert system===<br />
<br />
'''Done''': Review who has access to the alert system keys, make sure they all have contact information for each other, and get good timezone overlap by people with access to the keys.<br />
<br />
'''Done''': Implement a new bitcoind feature so services can get timely notification of alerts: -alertnotify=<command> Run command when an AppliesToMe() alert is received.<br />
<br />
'''Done''': Pre-generate 52 test alerts, and set a time every week when they are broadcast on -testnet (so -alertnotify scripts can be tested in as-close-to-real-world conditions as possible).<br />
<br />
Idea from Michael Gronager: encourage merchants/exchanges (and maybe pools) to run new code behind a bitcoind running the network-majority version.<br />
<br />
===Safe mode===<br />
<br />
'''Done''': Perhaps trigger an alert if there is a long enough side chain detected, even if it is not the main chain. Pools could use this to automatically suspend payouts if a long side-chain suddenly appeared out of nowhere (it’s hard for an attacker to mine such a thing).<br />
<br />
===Testing===<br />
<br />
Start running bots on the testnet that grab some coins from a testnet faucet, generate large numbers of random transactions that split/recombine them and then send them back to the faucet. Randomized online testing on the testnet might have revealed the pathological block type earlier.<br />
<br />
===Double spending===<br />
<br />
A double spend attack was successful, despite that both sides of the chain heard about the transactions in the same order. The reason is most likely that the memory pools were cleared when the mining pool nodes were downgraded. A solution is for nodes to sync their mempools to each other at startup, however, this requires a memory pool expiry policy to be implemented as currently node restarts are the only way for unconfirmed transactions to be evicted from the system.<br />
<br />
===Resolution===<br />
<br />
On 22 August, 2013 block 252,451 was accepted by the main network, forking unpatched nodes off the network.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Protocol_documentation&diff=40251Protocol documentation2013-08-17T18:53:40Z<p>Sipa: /* mempool */</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
For protocol used in mining, see [[Getwork]].<br />
<br />
==Common standards==<br />
<br />
=== Hashes ===<br />
<br />
Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Merkle Trees ===<br />
<br />
Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.<br />
<br />
If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.<br />
<br />
First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.<br />
<br />
Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.<br />
<br />
This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''merkle root''' of the tree.<br />
<br />
For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The merkle tree is: <br />
<br />
d1 = dhash(a)<br />
d2 = dhash(b)<br />
d3 = dhash(c)<br />
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice<br />
<br />
d5 = dhash(d1 concat d2)<br />
d6 = dhash(d3 concat d4)<br />
<br />
d7 = dhash(d5 concat d6)<br />
<br />
where<br />
<br />
dhash(a) = sha256(sha256(a))<br />
<br />
''d7'' is the merkle root of the 3 transactions in this block.<br />
<br />
Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
<br />
Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.<br />
<br />
Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br />
<br />
=== Transaction Verification ===<br />
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br />
<br />
Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br />
<br />
Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br />
<br />
In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br />
<br />
A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br />
<br />
The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.<br />
<br />
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload in number of bytes<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br />
|-<br />
| ? || payload || uchar[] || The actual data<br />
|}<br />
<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value !! Sent over wire as<br />
|-<br />
| main || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| testnet || 0xDAB5BFFA || FA BF B5 DA<br />
|-<br />
| testnet3 || 0x0709110B || 0B 11 09 07<br />
|-<br />
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space.<br />
Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
Longer numbers are encoded in little endian.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br />
|-<br />
| - || 9 || 0xff followed by the length as uint64_t<br />
|}<br />
<br />
If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || time || uint32 || the Time (version >= 31402)<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br />
|-<br />
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Network address:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_recv || net_addr || The network address of the node receiving this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_from || net_addr || The network address of the node emitting this message<br />
|-<br />
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.<br />
|-<br />
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|-<br />
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001<br />
|}<br />
<br />
A "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
And here's a modern (60002) protocol version client advertising itself to a local peer...<br />
<br />
Newer protocol includes the checksum now, this is from a mainline (satoshi) client during <br />
an outgoing connection to another local client, notice that it does not fill out the <br />
address information at all when the source or destination is "unroutable".<br />
<br />
<pre><br />
<br />
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....<br />
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......<br />
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........<br />
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................<br />
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................<br />
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh<br />
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
64 00 00 00 - Payload is 100 bytes long<br />
3B 64 8D 5A - payload checksum<br />
<br />
Version message:<br />
62 EA 00 00 - 60002 (protocol version 60002)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address<br />
3B 2E B3 5D 8C E6 17 65 - Node ID<br />
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)<br />
C0 3E 03 00 - Last block sending node has is block #212672<br />
</pre><br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 5D F6 E0 E2 ........<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
5D F6 E0 E2 - Checksum<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br />
|-<br />
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).<br />
|}<br />
<br />
'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== notfound ===<br />
<br />
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. <br />
<br />
The locator hashes are processed by a node in the order as they appear in the message. If a block hash if found in the node's main chain, the list of it's children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.<br />
<br />
To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:<br />
<br />
<pre><br />
// From libbitcoin which is under AGPL<br />
std::vector<size_t> block_locator_indices(int top_depth)<br />
{<br />
// Start at max_depth<br />
std::vector<size_t> indices;<br />
// Push last 10 indices first<br />
size_t step = 1, start = 0;<br />
for (int i = top_depth; i > 0; i -= step, ++start)<br />
{<br />
if (start >= 10)<br />
step *= 2;<br />
indices.push_back(i);<br />
}<br />
indices.push_back(0);<br />
return indices;<br />
}<br />
</pre><br />
<br />
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br />
|-<br />
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Always locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time.<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || int64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br />
|-<br />
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br />
|}<br />
<br />
Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br />
<br />
=== getaddr ===<br />
<br />
The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== mempool ===<br />
<br />
The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
It is specified in [[BIP_0035|BIP 35]]. Since [[BIP_0037|BIP 37]], only transactions matching the filter are replied.<br />
<br />
=== checkorder ===<br />
<br />
This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.<br />
<br />
=== filterload, filteradd, filterclear, merkleblock ===<br />
<br />
These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].<br />
<br />
=== alert ===<br />
<br />
An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br />
<br />
Alert format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || payload || var_str || Serialized alert payload<br />
|-<br />
| ? || signature || var_str || An ECDSA signature of the message<br />
|}<br />
<br />
The developers of Satoshi's client use this public key for signing alerts:<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || Version || int32_t || Alert format version<br />
|-<br />
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br />
|-<br />
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br />
|-<br />
| 4 || ID || int32_t || A unique ID number for this alert<br />
|-<br />
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int> || All alert IDs contained in this set should be canceled as above<br />
|-<br />
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br />
|-<br />
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br />
|-<br />
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br />
|-<br />
| 4 || Priority || int32_t || Relative priority compared to other alerts<br />
|-<br />
| ? || Comment || string || A comment on the alert that is not displayed<br />
|-<br />
| ? || StatusBar || string || The alert message that is displayed to the user<br />
|-<br />
| ? || Reserved || string || Reserved<br />
|}<br />
<br />
Sample alert (no message header):<br />
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br />
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br />
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br />
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br />
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br />
<br />
Version: 1<br />
RelayUntil: 1329620535<br />
Expiration: 1329792435<br />
ID: 1010<br />
Cancel: 1009<br />
setCancel: <empty><br />
MinVer: 10000<br />
MaxVer: 61000<br />
setSubVer: <empty><br />
Priority: 100<br />
Comment: <empty><br />
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"<br />
Reserved: <empty><br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
== Wireshark dissector ==<br />
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Protocol_documentation&diff=40250Protocol documentation2013-08-17T18:53:09Z<p>Sipa: /* mempool */</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
For protocol used in mining, see [[Getwork]].<br />
<br />
==Common standards==<br />
<br />
=== Hashes ===<br />
<br />
Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Merkle Trees ===<br />
<br />
Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.<br />
<br />
If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.<br />
<br />
First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.<br />
<br />
Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.<br />
<br />
This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''merkle root''' of the tree.<br />
<br />
For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The merkle tree is: <br />
<br />
d1 = dhash(a)<br />
d2 = dhash(b)<br />
d3 = dhash(c)<br />
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice<br />
<br />
d5 = dhash(d1 concat d2)<br />
d6 = dhash(d3 concat d4)<br />
<br />
d7 = dhash(d5 concat d6)<br />
<br />
where<br />
<br />
dhash(a) = sha256(sha256(a))<br />
<br />
''d7'' is the merkle root of the 3 transactions in this block.<br />
<br />
Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
<br />
Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.<br />
<br />
Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br />
<br />
=== Transaction Verification ===<br />
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br />
<br />
Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br />
<br />
Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br />
<br />
In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br />
<br />
A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br />
<br />
The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.<br />
<br />
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload in number of bytes<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br />
|-<br />
| ? || payload || uchar[] || The actual data<br />
|}<br />
<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value !! Sent over wire as<br />
|-<br />
| main || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| testnet || 0xDAB5BFFA || FA BF B5 DA<br />
|-<br />
| testnet3 || 0x0709110B || 0B 11 09 07<br />
|-<br />
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space.<br />
Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
Longer numbers are encoded in little endian.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br />
|-<br />
| - || 9 || 0xff followed by the length as uint64_t<br />
|}<br />
<br />
If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || time || uint32 || the Time (version >= 31402)<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br />
|-<br />
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Network address:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_recv || net_addr || The network address of the node receiving this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_from || net_addr || The network address of the node emitting this message<br />
|-<br />
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.<br />
|-<br />
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|-<br />
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001<br />
|}<br />
<br />
A "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
And here's a modern (60002) protocol version client advertising itself to a local peer...<br />
<br />
Newer protocol includes the checksum now, this is from a mainline (satoshi) client during <br />
an outgoing connection to another local client, notice that it does not fill out the <br />
address information at all when the source or destination is "unroutable".<br />
<br />
<pre><br />
<br />
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....<br />
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......<br />
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........<br />
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................<br />
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................<br />
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh<br />
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
64 00 00 00 - Payload is 100 bytes long<br />
3B 64 8D 5A - payload checksum<br />
<br />
Version message:<br />
62 EA 00 00 - 60002 (protocol version 60002)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address<br />
3B 2E B3 5D 8C E6 17 65 - Node ID<br />
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)<br />
C0 3E 03 00 - Last block sending node has is block #212672<br />
</pre><br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 5D F6 E0 E2 ........<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
5D F6 E0 E2 - Checksum<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br />
|-<br />
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).<br />
|}<br />
<br />
'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== notfound ===<br />
<br />
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. <br />
<br />
The locator hashes are processed by a node in the order as they appear in the message. If a block hash if found in the node's main chain, the list of it's children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.<br />
<br />
To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:<br />
<br />
<pre><br />
// From libbitcoin which is under AGPL<br />
std::vector<size_t> block_locator_indices(int top_depth)<br />
{<br />
// Start at max_depth<br />
std::vector<size_t> indices;<br />
// Push last 10 indices first<br />
size_t step = 1, start = 0;<br />
for (int i = top_depth; i > 0; i -= step, ++start)<br />
{<br />
if (start >= 10)<br />
step *= 2;<br />
indices.push_back(i);<br />
}<br />
indices.push_back(0);<br />
return indices;<br />
}<br />
</pre><br />
<br />
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br />
|-<br />
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Always locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time.<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || int64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br />
|-<br />
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br />
|}<br />
<br />
Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br />
<br />
=== getaddr ===<br />
<br />
The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== mempool ===<br />
<br />
The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
It is specified in [[BIP 35|BIP_0035]]. Since [[BIP 37|BIP_0037]], only transactions matching the filter are replied.<br />
<br />
=== checkorder ===<br />
<br />
This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.<br />
<br />
=== filterload, filteradd, filterclear, merkleblock ===<br />
<br />
These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].<br />
<br />
=== alert ===<br />
<br />
An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br />
<br />
Alert format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || payload || var_str || Serialized alert payload<br />
|-<br />
| ? || signature || var_str || An ECDSA signature of the message<br />
|}<br />
<br />
The developers of Satoshi's client use this public key for signing alerts:<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || Version || int32_t || Alert format version<br />
|-<br />
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br />
|-<br />
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br />
|-<br />
| 4 || ID || int32_t || A unique ID number for this alert<br />
|-<br />
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int> || All alert IDs contained in this set should be canceled as above<br />
|-<br />
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br />
|-<br />
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br />
|-<br />
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br />
|-<br />
| 4 || Priority || int32_t || Relative priority compared to other alerts<br />
|-<br />
| ? || Comment || string || A comment on the alert that is not displayed<br />
|-<br />
| ? || StatusBar || string || The alert message that is displayed to the user<br />
|-<br />
| ? || Reserved || string || Reserved<br />
|}<br />
<br />
Sample alert (no message header):<br />
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br />
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br />
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br />
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br />
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br />
<br />
Version: 1<br />
RelayUntil: 1329620535<br />
Expiration: 1329792435<br />
ID: 1010<br />
Cancel: 1009<br />
setCancel: <empty><br />
MinVer: 10000<br />
MaxVer: 61000<br />
setSubVer: <empty><br />
Priority: 100<br />
Comment: <empty><br />
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"<br />
Reserved: <empty><br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
== Wireshark dissector ==<br />
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=38846BIP 00322013-06-22T17:28:22Z<p>Sipa: BIP32 is accepted</p>
<hr />
<div>{{bip}}<br />
<br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
* [25 May 2013] Added test vectors<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Accepted<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
<br />
==Test Vectors==<br />
<br />
For more detailed information about these (such as intermediate values and other representations), see [[BIP_0032_TestVectors]]<br />
<br />
Test vector 1<br />
<br />
Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw<br />
* ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7<br />
* [Chain m/0'/1]<br />
* ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ<br />
* ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs<br />
* [Chain m/0'/1/2']<br />
* ext pub: xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5<br />
* ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM<br />
* [Chain m/0'/1/2'/2]<br />
* ext pub: xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV<br />
* ext prv: xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* ext pub: xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy<br />
* ext prv: xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76<br />
<br />
Test vector 2<br />
<br />
Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon<br />
* ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL<br />
* ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt<br />
* ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=Bitcoin_Improvement_Proposals&diff=38845Bitcoin Improvement Proposals2013-06-22T17:03:15Z<p>Sipa: Accepted bip32</p>
<hr />
<div>People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.<br />
<br />
We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.<br />
<br />
Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.<br />
<br />
Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [[economic majority]]).<br />
<br />
{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"<br />
!Number<br />
!Title<br />
!Owner<br />
!Status<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0001|1]]<br />
| BIP Purpose and Guidelines<br />
| Amir Taaki<br />
| Active<br />
|-<br />
| [[BIP 0010|10]]<br />
| Multi-Sig Transaction Distribution<br />
| Alan Reiner<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0011|11]]<br />
| M-of-N Standard Transactions<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0012|12]]<br />
| OP_EVAL<br />
| Gavin Andresen<br />
| Withdrawn<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0013|13]]<br />
| Address Format for pay-to-script-hash<br />
| Gavin Andresen<br />
| Final<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0014|14]]<br />
| Protocol Version and User Agent<br />
| Amir Taaki, Patrick Strateman<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0015|15]]<br />
| Aliases<br />
| Amir Taaki<br />
| Withdrawn<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0016|16]]<br />
| Pay To Script Hash<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0017|17]]<br />
| OP_CHECKHASHVERIFY (CHV)<br />
| Luke Dashjr<br />
| Withdrawn<br />
|-<br />
| [[BIP 0018|18]]<br />
| hashScriptCheck<br />
| Luke Dashjr<br />
| Draft<br />
|-<br />
| [[BIP 0019|19]]<br />
| M-of-N Standard Transactions (Low SigOp)<br />
| Luke Dashjr<br />
| Draft<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0020|20]]<br />
| URI Scheme<br />
| Luke Dashjr<br />
| Replaced<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0021|21]]<br />
| URI Scheme<br />
| Nils Schneider, Matt Corallo<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0022|22]]<br />
| getblocktemplate - Fundamentals<br />
| Luke Dashjr<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0023|23]]<br />
| getblocktemplate - Pooled Mining<br />
| Luke Dashjr<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0030|30]]<br />
| Duplicate transactions<br />
| Pieter Wuille<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0031|31]]<br />
| Pong message<br />
| Mike Hearn<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0032|32]]<br />
| Hierarchical Deterministic Wallets<br />
| Pieter Wuille<br />
| Accepted<br />
|-<br />
| [[BIP 0033|33]]<br />
| Stratized Nodes<br />
| Amir Taaki<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0034|34]]<br />
| Block v2, Height in coinbase<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0035|35]]<br />
| mempool message<br />
| Jeff Garzik<br />
| Accepted<br />
|-<br />
| [[BIP 0036|36]]<br />
| Custom Services<br />
| Stefan Thomas<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0037|37]]<br />
| Bloom filtering<br />
| Mike Hearn and Matt Corallo<br />
| Accepted<br />
|- <br />
| [[BIP 0039|39]]<br />
| Deterministic key mnemonics<br />
| Slush<br />
| BIP number allocated<br />
|-<br />
| [[BIP 0040|40]]<br />
| Stratum wire protocol<br />
| Slush<br />
| BIP number allocated<br />
|-<br />
| [[BIP 0041|41]]<br />
| Stratum mining protocol<br />
| Slush<br />
| BIP number allocated<br />
<!-- 42-49 reserved for stratum extensions --><br />
|-<br />
| [[BIP 0050|50]]<br />
| March 2013 Chain Fork Post-Mortem<br />
| Gavin Andresen<br />
| Draft<br />
<!-- 50 series reserved for a group of post-mortems --><br />
|-<br />
| [[BIP 0060|60]]<br />
| Fixed Length "version" Message (Relay-Transactions Field)<br />
| Amir Taaki<br />
| Draft<br />
|}<br />
<br />
[[Hardfork Wishlist]]<br />
<br />
[[Category:BIP|Z]]<br />
<br />
[[es:Propuestas de mejora de Bitcoin]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0001&diff=38844BIP 00012013-06-22T16:46:07Z<p>Sipa: I think it's accepted now...</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 1<br />
Title: BIP Purpose and Guidelines<br />
Status: Accepted<br />
Type: Standards Track<br />
Created: 19-08-2011<br />
</pre><br />
<br />
==What is a BIP?==<br />
<br />
BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.<br />
<br />
We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.<br />
<br />
Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal<br />
.<br />
==BIP Types==<br />
<br />
There are three kinds of BIP:<br />
<br />
* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.<br />
* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.<br />
* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.<br />
<br />
==BIP Work Flow==<br />
<br />
The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to <gmaxwell@gmail.com> (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below.<br />
<br />
The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focussed the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocussed or too broad. If in doubt, split your BIP into several well-focussed ones.<br />
<br />
Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum or the [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] mailing list is the best way to go about this.<br />
<br />
Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used.<br />
<br />
Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal.<br />
<br />
Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors <gmaxwell@gmail.com>. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.<br />
<br />
If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and create and create a page for it on the [[Bitcoin_Improvement_Proposals|Bitcoin Wiki]]. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.<br />
<br />
The BIP author may update the Draft as necessary on the wiki.<br />
<br />
Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final.<br />
<br />
BIP authors are responsible for collecting community feedback on a BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page, etc. BIP authors should use their discretion here.<br />
<br />
For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.<br />
<br />
Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final".<br />
<br />
A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status.<br />
<br />
A BIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.<br />
<br />
BIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1.<br />
<br />
The possible paths of the status of BIPs are as follows:<br />
<br />
[[File:BIP-0001-Process.png]]<br />
<br />
Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 1 (this BIP).<br />
<br />
==What belongs in a successful BIP?==<br />
<br />
Each BIP should have the following parts:<br />
<br />
* Preamble -- RFC 822 style headers containing meta-data about the BIP, including the BIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.<br />
<br />
* Abstract -- a short (~200 word) description of the technical issue being addressed.<br />
<br />
* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License.<br />
<br />
* Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin).<br />
<br />
* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright.<br />
<br />
* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.<br />
<br />
* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.<br />
<br />
* Backwards Compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. BIP submissions without a sufficient backwards compatibility treatise may be rejected outright.<br />
<br />
* Reference Implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.<br />
<br />
* The final implementation must include test code and documentation appropriate for the Bitcoin protocol.<br />
<br />
==BIP Formats and Templates==<br />
<br />
BIPs should be written in mediawiki wiki syntax. Image files should be included in the current subdirectory for that BIP.<br />
<br />
==BIP Header Preamble==<br />
<br />
Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.<br />
<br />
<pre><br />
BIP: <BIP number><br />
Title: <BIP title><br />
Author: <list of authors' real names and optionally, email addrs><br />
* Discussions-To: <email address><br />
Status: <Draft | Active | Accepted | Deferred | Rejected |<br />
Withdrawn | Final | Superseded><br />
Type: <Standards Track | Informational | Process><br />
Created: <date created on, in dd-mm-yyyy format><br />
* Post-History: <dates of postings to bitcoin mailing list><br />
* Replaces: <BIP number><br />
* Superseded-By: <BIP number><br />
* Resolution: <url><br />
</pre><br />
<br />
The Author header lists the names, and optionally the email addresses of all the authors/owners of the BIP. The format of the Author header value must be<br />
<br />
Random J. User <address@dom.ain><br />
<br />
if the email address is included, and just<br />
<br />
Random J. User<br />
<br />
if the address is not given.<br />
<br />
If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.<br />
<br />
Note: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made.<br />
<br />
While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists.<br />
<br />
The Type header specifies the type of BIP: Standards Track, Informational, or Process.<br />
<br />
The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001.<br />
<br />
BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on.<br />
<br />
BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete.<br />
Auxiliary Files<br />
<br />
BIPs may include auxiliary files such as diagrams. Such files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png").<br />
<br />
==Transferring BIP Ownership==<br />
<br />
It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.<br />
<br />
If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor <gmaxwell@gmail.com>. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).<br />
BIP Editor Responsibilities & Workflow<br />
<br />
A BIP editor must subscribe to the <gmaxwell@gmail.com> list. All BIP-related correspondence should be sent (or CC'd) to <gmaxwell@gmail.com> (but please do not cross-post!).<br />
<br />
For each new BIP that comes in an editor does the following:<br />
<br />
* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.<br />
* The title should accurately describe the content.<br />
* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7).<br />
<br />
If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.<br />
<br />
Once the BIP is ready for the repository, the BIP editor will:<br />
<br />
* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141).<br />
<br />
* List the BIP in BIP 0 (in two places: the categorized list, and the numeric list).<br />
<br />
* Add the BIP to the wiki.<br />
<br />
* Send email back to the BIP author with next steps (post to bitcoin mailing list).<br />
<br />
Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.<br />
<br />
The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume.<br />
<br />
==History==<br />
<br />
This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the Bitcoin editors or the forums at bitcointalk.org.<br />
<br />
[[Category:BIP|A]]</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=38396BIP 00322013-06-05T04:00:17Z<p>Sipa: small ambiguity reported by grau</p>
<hr />
<div>{{bip}}<br />
<br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
* [25 May 2013] Added test vectors<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
<br />
==Test Vectors==<br />
<br />
For more detailed information about these (such as intermediate values and other representations), see [[BIP_0032_TestVectors]]<br />
<br />
Test vector 1<br />
<br />
Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw<br />
* ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7<br />
* [Chain m/0'/1]<br />
* ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ<br />
* ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs<br />
* [Chain m/0'/1/2']<br />
* ext pub: xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5<br />
* ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM<br />
* [Chain m/0'/1/2'/2]<br />
* ext pub: xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV<br />
* ext prv: xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* ext pub: xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy<br />
* ext prv: xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76<br />
<br />
Test vector 2<br />
<br />
Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon<br />
* ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL<br />
* ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt<br />
* ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=38097BIP 00322013-05-27T20:39:26Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
* [25 May 2013] Added test vectors<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
<br />
==Test Vectors==<br />
<br />
For more detailed information about these (such as intermediate values and other representations), see [[BIP_0032_TestVectors]]<br />
<br />
Test vector 1<br />
<br />
Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw<br />
* ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7<br />
* [Chain m/0'/1]<br />
* ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ<br />
* ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs<br />
* [Chain m/0'/1/2']<br />
* ext pub: xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5<br />
* ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM<br />
* [Chain m/0'/1/2'/2]<br />
* ext pub: xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV<br />
* ext prv: xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* ext pub: xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy<br />
* ext prv: xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76<br />
<br />
Test vector 2<br />
<br />
Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon<br />
* ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL<br />
* ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt<br />
* ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032_TestVectors&diff=38095BIP 0032 TestVectors2013-05-27T18:55:08Z<p>Sipa: fix</p>
<hr />
<div>Test vector 1<br />
<br />
Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* Identifier<br />
* (hex): 3442193e1bb70916e914552172cd4e2dbc9df811<br />
* (fpr): 0x3442193e<br />
* (main addr): 15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma<br />
* Secret key<br />
* (hex): e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b35<br />
* (wif): L52XzL2cMkHxqxBXRyEpnPQZGUs3uKiL3R11XbAdHigRzDozKZeW<br />
* Public key<br />
* (hex): 0339a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c2<br />
* Chain code<br />
* (hex): 873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d508<br />
* Serialized<br />
* (pub hex): 0488b21e000000000000000000873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d5080339a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c2<br />
* (prv hex): 0488ade4000000000000000000873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d50800e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b35<br />
* (pub b58): xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* (prv b58): xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* Identifier<br />
* (hex): 5c1bd648ed23aa5fd50ba52b2457c11e9e80a6a7<br />
* (fpr): 0x5c1bd648<br />
* (main addr): 19Q2WoS5hSS6T8GjhK8KZLMgmWaq4neXrh<br />
* Secret key<br />
* (hex): edb2e14f9ee77d26dd93b4ecede8d16ed408ce149b6cd80b0715a2d911a0afea<br />
* (wif): L5BmPijJjrKbiUfG4zbiFKNqkvuJ8usooJmzuD7Z8dkRoTThYnAT<br />
* Public key<br />
* (hex): 035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc56<br />
* Chain code<br />
* (hex): 47fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141<br />
* Serialized<br />
* (pub hex): 0488b21e013442193e8000000047fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc56<br />
* (prv hex): 0488ade4013442193e8000000047fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae623614100edb2e14f9ee77d26dd93b4ecede8d16ed408ce149b6cd80b0715a2d911a0afea<br />
* (pub b58): xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw<br />
* (prv b58): xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7<br />
* [Chain m/0'/1]<br />
* Identifier<br />
* (hex): bef5a2f9a56a94aab12459f72ad9cf8cf19c7bbe<br />
* (fpr): 0xbef5a2f9<br />
* (main addr): 1JQheacLPdM5ySCkrZkV66G2ApAXe1mqLj<br />
* Secret key<br />
* (hex): 3c6cb8d0f6a264c91ea8b5030fadaa8e538b020f0a387421a12de9319dc93368<br />
* (wif): KyFAjQ5rgrKvhXvNMtFB5PCSKUYD1yyPEe3xr3T34TZSUHycXtMM<br />
* Public key<br />
* (hex): 03501e454bf00751f24b1b489aa925215d66af2234e3891c3b21a52bedb3cd711c<br />
* Chain code<br />
* (hex): 2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19<br />
* Serialized<br />
* (pub hex): 0488b21e025c1bd648000000012a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c1903501e454bf00751f24b1b489aa925215d66af2234e3891c3b21a52bedb3cd711c<br />
* (prv hex): 0488ade4025c1bd648000000012a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19003c6cb8d0f6a264c91ea8b5030fadaa8e538b020f0a387421a12de9319dc93368<br />
* (pub b58): xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ<br />
* (prv b58): xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs<br />
* [Chain m/0'/1/2']<br />
* Identifier<br />
* (hex): ee7ab90cde56a8c0e2bb086ac49748b8db9dce72<br />
* (fpr): 0xee7ab90c<br />
* (main addr): 1NjxqbA9aZWnh17q1UW3rB4EPu79wDXj7x<br />
* Secret key<br />
* (hex): cbce0d719ecf7431d88e6a89fa1483e02e35092af60c042b1df2ff59fa424dca<br />
* (wif): L43t3od1Gh7Lj55Bzjj1xDAgJDcL7YFo2nEcNaMGiyRZS1CidBVU<br />
* Public key<br />
* (hex): 0357bfe1e341d01c69fe5654309956cbea516822fba8a601743a012a7896ee8dc2<br />
* Chain code<br />
* (hex): 04466b9cc8e161e966409ca52986c584f07e9dc81f735db683c3ff6ec7b1503f<br />
* Serialized<br />
* (pub hex): 0488b21e03bef5a2f98000000204466b9cc8e161e966409ca52986c584f07e9dc81f735db683c3ff6ec7b1503f0357bfe1e341d01c69fe5654309956cbea516822fba8a601743a012a7896ee8dc2<br />
* (prv hex): 0488ade403bef5a2f98000000204466b9cc8e161e966409ca52986c584f07e9dc81f735db683c3ff6ec7b1503f00cbce0d719ecf7431d88e6a89fa1483e02e35092af60c042b1df2ff59fa424dca<br />
* (pub b58): xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5<br />
* (prv b58): xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM<br />
* [Chain m/0'/1/2'/2]<br />
* Identifier<br />
* (hex): d880d7d893848509a62d8fb74e32148dac68412f<br />
* (fpr): 0xd880d7d8<br />
* (main addr): 1LjmJcdPnDHhNTUgrWyhLGnRDKxQjoxAgt<br />
* Secret key<br />
* (hex): 0f479245fb19a38a1954c5c7c0ebab2f9bdfd96a17563ef28a6a4b1a2a764ef4<br />
* (wif): KwjQsVuMjbCP2Zmr3VaFaStav7NvevwjvvkqrWd5Qmh1XVnCteBR<br />
* Public key<br />
* (hex): 02e8445082a72f29b75ca48748a914df60622a609cacfce8ed0e35804560741d29<br />
* Chain code<br />
* (hex): cfb71883f01676f587d023cc53a35bc7f88f724b1f8c2892ac1275ac822a3edd<br />
* Serialized<br />
* (pub hex): 0488b21e04ee7ab90c00000002cfb71883f01676f587d023cc53a35bc7f88f724b1f8c2892ac1275ac822a3edd02e8445082a72f29b75ca48748a914df60622a609cacfce8ed0e35804560741d29<br />
* (prv hex): 0488ade404ee7ab90c00000002cfb71883f01676f587d023cc53a35bc7f88f724b1f8c2892ac1275ac822a3edd000f479245fb19a38a1954c5c7c0ebab2f9bdfd96a17563ef28a6a4b1a2a764ef4<br />
* (pub b58): xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV<br />
* (prv b58): xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* Identifier<br />
* (hex): d69aa102255fed74378278c7812701ea641fdf32<br />
* (fpr): 0xd69aa102<br />
* (main addr): 1LZiqrop2HGR4qrH1ULZPyBpU6AUP49Uam<br />
* Secret key<br />
* (hex): 471b76e389e528d6de6d816857e012c5455051cad6660850e58372a6c3e6e7c8<br />
* (wif): Kybw8izYevo5xMh1TK7aUr7jHFCxXS1zv8p3oqFz3o2zFbhRXHYs<br />
* Public key<br />
* (hex): 022a471424da5e657499d1ff51cb43c47481a03b1e77f951fe64cec9f5a48f7011<br />
* Chain code<br />
* (hex): c783e67b921d2beb8f6b389cc646d7263b4145701dadd2161548a8b078e65e9e<br />
* Serialized<br />
* (pub hex): 0488b21e05d880d7d83b9aca00c783e67b921d2beb8f6b389cc646d7263b4145701dadd2161548a8b078e65e9e022a471424da5e657499d1ff51cb43c47481a03b1e77f951fe64cec9f5a48f7011<br />
* (prv hex): 0488ade405d880d7d83b9aca00c783e67b921d2beb8f6b389cc646d7263b4145701dadd2161548a8b078e65e9e00471b76e389e528d6de6d816857e012c5455051cad6660850e58372a6c3e6e7c8<br />
* (pub b58): xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy<br />
* (prv b58): xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76<br />
<br />
Test vector 2<br />
<br />
Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* Identifier<br />
* (hex): bd16bee53961a47d6ad888e29545434a89bdfe95<br />
* (fpr): 0xbd16bee5<br />
* (main addr): 1JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg<br />
* Secret key<br />
* (hex): 4b03d6fc340455b363f51020ad3ecca4f0850280cf436c70c727923f6db46c3e<br />
* (wif): KyjXhyHF9wTphBkfpxjL8hkDXDUSbE3tKANT94kXSyh6vn6nKaoy<br />
* Public key<br />
* (hex): 03cbcaa9c98c877a26977d00825c956a238e8dddfbd322cce4f74b0b5bd6ace4a7<br />
* Chain code<br />
* (hex): 60499f801b896d83179a4374aeb7822aaeaceaa0db1f85ee3e904c4defbd9689<br />
* Serialized<br />
* (pub hex): 0488b21e00000000000000000060499f801b896d83179a4374aeb7822aaeaceaa0db1f85ee3e904c4defbd968903cbcaa9c98c877a26977d00825c956a238e8dddfbd322cce4f74b0b5bd6ace4a7<br />
* (prv hex): 0488ade400000000000000000060499f801b896d83179a4374aeb7822aaeaceaa0db1f85ee3e904c4defbd9689004b03d6fc340455b363f51020ad3ecca4f0850280cf436c70c727923f6db46c3e<br />
* (pub b58): xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* (prv b58): xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* Identifier<br />
* (hex): 5a61ff8eb7aaca3010db97ebda76121610b78096<br />
* (fpr): 0x5a61ff8e<br />
* (main addr): 19EuDJdgfRkwCmRzbzVBHZWQG9QNWhftbZ<br />
* Secret key<br />
* (hex): abe74a98f6c7eabee0428f53798f0ab8aa1bd37873999041703c742f15ac7e1e<br />
* (wif): L2ysLrR6KMSAtx7uPqmYpoTeiRzydXBattRXjXz5GDFPrdfPzKbj<br />
* Public key<br />
* (hex): 02fc9e5af0ac8d9b3cecfe2a888e2117ba3d089d8585886c9c826b6b22a98d12ea<br />
* Chain code<br />
* (hex): f0909affaa7ee7abe5dd4e100598d4dc53cd709d5a5c2cac40e7412f232f7c9c<br />
* Serialized<br />
* (pub hex): 0488b21e01bd16bee500000000f0909affaa7ee7abe5dd4e100598d4dc53cd709d5a5c2cac40e7412f232f7c9c02fc9e5af0ac8d9b3cecfe2a888e2117ba3d089d8585886c9c826b6b22a98d12ea<br />
* (prv hex): 0488ade401bd16bee500000000f0909affaa7ee7abe5dd4e100598d4dc53cd709d5a5c2cac40e7412f232f7c9c00abe74a98f6c7eabee0428f53798f0ab8aa1bd37873999041703c742f15ac7e1e<br />
* (pub b58): xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* (prv b58): xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* Identifier<br />
* (hex): d8ab493736da02f11ed682f88339e720fb0379d1<br />
* (fpr): 0xd8ab4937<br />
* (main addr): 1Lke9bXGhn5VPrBuXgN12uGUphrttUErmk<br />
* Secret key<br />
* (hex): 877c779ad9687164e9c2f4f0f4ff0340814392330693ce95a58fe18fd52e6e93<br />
* (wif): L1m5VpbXmMp57P3knskwhoMTLdhAAaXiHvnGLMribbfwzVRpz2Sr<br />
* Public key<br />
* (hex): 03c01e7425647bdefa82b12d9bad5e3e6865bee0502694b94ca58b666abc0a5c3b<br />
* Chain code<br />
* (hex): be17a268474a6bb9c61e1d720cf6215e2a88c5406c4aee7b38547f585c9a37d9<br />
* Serialized<br />
* (pub hex): 0488b21e025a61ff8effffffffbe17a268474a6bb9c61e1d720cf6215e2a88c5406c4aee7b38547f585c9a37d903c01e7425647bdefa82b12d9bad5e3e6865bee0502694b94ca58b666abc0a5c3b<br />
* (prv hex): 0488ade4025a61ff8effffffffbe17a268474a6bb9c61e1d720cf6215e2a88c5406c4aee7b38547f585c9a37d900877c779ad9687164e9c2f4f0f4ff0340814392330693ce95a58fe18fd52e6e93<br />
* (pub b58): xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* (prv b58): xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* Identifier<br />
* (hex): 78412e3a2296a40de124307b6485bd19833e2e34<br />
* (fpr): 0x78412e3a<br />
* (main addr): 1BxrAr2pHpeBheusmd6fHDP2tSLAUa3qsW<br />
* Secret key<br />
* (hex): 704addf544a06e5ee4bea37098463c23613da32020d604506da8c0518e1da4b7<br />
* (wif): KzyzXnznxSv249b4KuNkBwowaN3akiNeEHy5FWoPCJpStZbEKXN2<br />
* Public key<br />
* (hex): 03a7d1d856deb74c508e05031f9895dab54626251b3806e16b4bd12e781a7df5b9<br />
* Chain code<br />
* (hex): f366f48f1ea9f2d1d3fe958c95ca84ea18e4c4ddb9366c336c927eb246fb38cb<br />
* Serialized<br />
* (pub hex): 0488b21e03d8ab493700000001f366f48f1ea9f2d1d3fe958c95ca84ea18e4c4ddb9366c336c927eb246fb38cb03a7d1d856deb74c508e05031f9895dab54626251b3806e16b4bd12e781a7df5b9<br />
* (prv hex): 0488ade403d8ab493700000001f366f48f1ea9f2d1d3fe958c95ca84ea18e4c4ddb9366c336c927eb246fb38cb00704addf544a06e5ee4bea37098463c23613da32020d604506da8c0518e1da4b7<br />
* (pub b58): xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon<br />
* (prv b58): xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* Identifier<br />
* (hex): 31a507b815593dfc51ffc7245ae7e5aee304246e<br />
* (fpr): 0x31a507b8<br />
* (main addr): 15XVotxCAV7sRx1PSCkQNsGw3W9jT9A94R<br />
* Secret key<br />
* (hex): f1c7c871a54a804afe328b4c83a1c33b8e5ff48f5087273f04efa83b247d6a2d<br />
* (wif): L5KhaMvPYRW1ZoFmRjUtxxPypQ94m6BcDrPhqArhggdaTbbAFJEF<br />
* Public key<br />
* (hex): 02d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0<br />
* Chain code<br />
* (hex): 637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e29<br />
* Serialized<br />
* (pub hex): 0488b21e0478412e3afffffffe637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e2902d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0<br />
* (prv hex): 0488ade40478412e3afffffffe637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e2900f1c7c871a54a804afe328b4c83a1c33b8e5ff48f5087273f04efa83b247d6a2d<br />
* (pub b58): xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL<br />
* (prv b58): xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* Identifier<br />
* (hex): 26132fdbe7bf89cbc64cf8dafa3f9f88b8666220<br />
* (fpr): 0x26132fdb<br />
* (main addr): 14UKfRV9ZPUp6ZC9PLhqbRtxdihW9em3xt<br />
* Secret key<br />
* (hex): bb7d39bdb83ecf58f2fd82b6d918341cbef428661ef01ab97c28a4842125ac23<br />
* (wif): L3WAYNAZPxx1fr7KCz7GN9nD5qMBnNiqEJNJMU1z9MMaannAt4aK<br />
* Public key<br />
* (hex): 024d902e1a2fc7a8755ab5b694c575fce742c48d9ff192e63df5193e4c7afe1f9c<br />
* Chain code<br />
* (hex): 9452b549be8cea3ecb7a84bec10dcfd94afe4d129ebfd3b3cb58eedf394ed271<br />
* Serialized<br />
* (pub hex): 0488b21e0531a507b8000000029452b549be8cea3ecb7a84bec10dcfd94afe4d129ebfd3b3cb58eedf394ed271024d902e1a2fc7a8755ab5b694c575fce742c48d9ff192e63df5193e4c7afe1f9c<br />
* (prv hex): 0488ade40531a507b8000000029452b549be8cea3ecb7a84bec10dcfd94afe4d129ebfd3b3cb58eedf394ed27100bb7d39bdb83ecf58f2fd82b6d918341cbef428661ef01ab97c28a4842125ac23<br />
* (pub b58): xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt<br />
* (prv b58): xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032_TestVectors&diff=38039BIP 0032 TestVectors2013-05-25T22:58:53Z<p>Sipa: Created page with "Test vector 1 Master (hex): 000102030405060708090a0b0c0d0e0f * [Chain m] * Identifier * (hex): 3442193e1bb70916e914552172cd4e2dbc9df811 * (fpr): ..."</p>
<hr />
<div>Test vector 1<br />
<br />
Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* Identifier<br />
* (hex): 3442193e1bb70916e914552172cd4e2dbc9df811<br />
* (fpr): 0x3442193e<br />
* (main addr): 15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma<br />
* Secret key<br />
* (hex): e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b35<br />
* (wif): L52XzL2cMkHxqxBXRyEpnPQZGUs3uKiL3R11XbAdHigRzDozKZeW<br />
* Public key<br />
* (hex): 0339a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c2<br />
* Chain code<br />
* (hex): 873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d508<br />
* Serialized<br />
* (pub hex): 0488b21e000000000000000000873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d5080339a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c2<br />
* (prv hex): 0488ade4000000000000000000873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d50800e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b35<br />
* (pub b58): xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* (prv b58): xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* Identifier<br />
* (hex): 5c1bd648ed23aa5fd50ba52b2457c11e9e80a6a7<br />
* (fpr): 0x5c1bd648<br />
* (main addr): 19Q2WoS5hSS6T8GjhK8KZLMgmWaq4neXrh<br />
* Secret key<br />
* (hex): edb2e14f9ee77d26dd93b4ecede8d16ed408ce149b6cd80b0715a2d911a0afea<br />
* (wif): L5BmPijJjrKbiUfG4zbiFKNqkvuJ8usooJmzuD7Z8dkRoTThYnAT<br />
* Public key<br />
* (hex): 035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc56<br />
* Chain code<br />
* (hex): 47fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141<br />
* Serialized<br />
* (pub hex): 0488b21e013442193e0000008047fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc56<br />
* (prv hex): 0488ade4013442193e0000008047fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae623614100edb2e14f9ee77d26dd93b4ecede8d16ed408ce149b6cd80b0715a2d911a0afea<br />
* (pub b58): xpub68Gmy5EVb2BirTFP4SuLeZw3sn3TC9o4ZwRHbQFe6M7t6b3o6oAHtM2DHZ34QSrHhwnkAcN6XyWKWCJmkXnXdCDqh5gGQuJnayTxrhi9oAm<br />
* (prv b58): xprv9uHRZZhbkedRdyAuxRNLHRzKKkCxnh5DCiVgo1r2Y1auDnieZFr3LYhjSHBPYxueVFVwAj8PYPvoT3BD9rVgjLqYmcpva2bs1wNWwpp3xqH<br />
* [Chain m/0'/1]<br />
* Identifier<br />
* (hex): bef5a2f9a56a94aab12459f72ad9cf8cf19c7bbe<br />
* (fpr): 0xbef5a2f9<br />
* (main addr): 1JQheacLPdM5ySCkrZkV66G2ApAXe1mqLj<br />
* Secret key<br />
* (hex): 3c6cb8d0f6a264c91ea8b5030fadaa8e538b020f0a387421a12de9319dc93368<br />
* (wif): KyFAjQ5rgrKvhXvNMtFB5PCSKUYD1yyPEe3xr3T34TZSUHycXtMM<br />
* Public key<br />
* (hex): 03501e454bf00751f24b1b489aa925215d66af2234e3891c3b21a52bedb3cd711c<br />
* Chain code<br />
* (hex): 2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19<br />
* Serialized<br />
* (pub hex): 0488b21e025c1bd648010000002a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c1903501e454bf00751f24b1b489aa925215d66af2234e3891c3b21a52bedb3cd711c<br />
* (prv hex): 0488ade4025c1bd648010000002a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19003c6cb8d0f6a264c91ea8b5030fadaa8e538b020f0a387421a12de9319dc93368<br />
* (pub b58): xpub6ASuArnXPAkxrYAJZEXBQRZXBmxFRSLgbhnWrr3nPTiQA1KugzrQWo9nRosbXKzKekW2tYfMCeEh871nutUf5T85udprZ2HJQvhgabyHAE3<br />
* (prv b58): xprv9wTYmMFdYoCfe45qTCzB3Hcndk7m1ycqEUrv4TeAq8BRHCzm9TY9xzqJaWkQrq7NvRLrv4ZyBB87cafdyDouH7QJCk6PJGLxsxPpuoQpGZm<br />
* [Chain m/0'/1/2']<br />
* Identifier<br />
* (hex): ee7ab90cde56a8c0e2bb086ac49748b8db9dce72<br />
* (fpr): 0xee7ab90c<br />
* (main addr): 1NjxqbA9aZWnh17q1UW3rB4EPu79wDXj7x<br />
* Secret key<br />
* (hex): cbce0d719ecf7431d88e6a89fa1483e02e35092af60c042b1df2ff59fa424dca<br />
* (wif): L43t3od1Gh7Lj55Bzjj1xDAgJDcL7YFo2nEcNaMGiyRZS1CidBVU<br />
* Public key<br />
* (hex): 0357bfe1e341d01c69fe5654309956cbea516822fba8a601743a012a7896ee8dc2<br />
* Chain code<br />
* (hex): 04466b9cc8e161e966409ca52986c584f07e9dc81f735db683c3ff6ec7b1503f<br />
* Serialized<br />
* (pub hex): 0488b21e03bef5a2f90200008004466b9cc8e161e966409ca52986c584f07e9dc81f735db683c3ff6ec7b1503f0357bfe1e341d01c69fe5654309956cbea516822fba8a601743a012a7896ee8dc2<br />
* (prv hex): 0488ade403bef5a2f90200008004466b9cc8e161e966409ca52986c584f07e9dc81f735db683c3ff6ec7b1503f00cbce0d719ecf7431d88e6a89fa1483e02e35092af60c042b1df2ff59fa424dca<br />
* (pub b58): xpub6D4BDPcEpAEonFzrRZxqsHcg6wRarryz1Kr6sLoxHfUbAYuHYjokqTDHcY6e7uGAnEHa2LJoG3evu67ochEgqxxk3Y31MDd6qizZkTmksfm<br />
* (prv b58): xprv9z4pot5LyngWZmvPKYRqW9fwYub6TQG8e6vW4xQLjKwcHka91CVWHetomG1EymTQCr442wBjH3oHASN7Ywwb7GXn7MtxASs2CLWncyE79fZ<br />
* [Chain m/0'/1/2'/2]<br />
* Identifier<br />
* (hex): d880d7d893848509a62d8fb74e32148dac68412f<br />
* (fpr): 0xd880d7d8<br />
* (main addr): 1LjmJcdPnDHhNTUgrWyhLGnRDKxQjoxAgt<br />
* Secret key<br />
* (hex): 0f479245fb19a38a1954c5c7c0ebab2f9bdfd96a17563ef28a6a4b1a2a764ef4<br />
* (wif): KwjQsVuMjbCP2Zmr3VaFaStav7NvevwjvvkqrWd5Qmh1XVnCteBR<br />
* Public key<br />
* (hex): 02e8445082a72f29b75ca48748a914df60622a609cacfce8ed0e35804560741d29<br />
* Chain code<br />
* (hex): cfb71883f01676f587d023cc53a35bc7f88f724b1f8c2892ac1275ac822a3edd<br />
* Serialized<br />
* (pub hex): 0488b21e04ee7ab90c02000000cfb71883f01676f587d023cc53a35bc7f88f724b1f8c2892ac1275ac822a3edd02e8445082a72f29b75ca48748a914df60622a609cacfce8ed0e35804560741d29<br />
* (prv hex): 0488ade404ee7ab90c02000000cfb71883f01676f587d023cc53a35bc7f88f724b1f8c2892ac1275ac822a3edd000f479245fb19a38a1954c5c7c0ebab2f9bdfd96a17563ef28a6a4b1a2a764ef4<br />
* (pub b58): xpub6FHa3pjLLJSfQmtahE1mHR8tU4Nm29BBxVAe5ocavBEyeEj1XDaZfN36LbkuJpCyrc7TsPsuF6FMoyy3Z9pm6L8F8zd4A2MzbU51aJ5eaef<br />
* (prv b58): xprvA2JDeKCSVvtNCHp7bCUkvHC9v2YGcgTLbGF3HRCyMqhzmSPrygGK7ZicVK5aDYeushtUMuWT8Awkz6mobXdoqRp4hH1uh9Xo6N9YomRreS6<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* Identifier<br />
* (hex): d69aa102255fed74378278c7812701ea641fdf32<br />
* (fpr): 0xd69aa102<br />
* (main addr): 1LZiqrop2HGR4qrH1ULZPyBpU6AUP49Uam<br />
* Secret key<br />
* (hex): 471b76e389e528d6de6d816857e012c5455051cad6660850e58372a6c3e6e7c8<br />
* (wif): Kybw8izYevo5xMh1TK7aUr7jHFCxXS1zv8p3oqFz3o2zFbhRXHYs<br />
* Public key<br />
* (hex): 022a471424da5e657499d1ff51cb43c47481a03b1e77f951fe64cec9f5a48f7011<br />
* Chain code<br />
* (hex): c783e67b921d2beb8f6b389cc646d7263b4145701dadd2161548a8b078e65e9e<br />
* Serialized<br />
* (pub hex): 0488b21e05d880d7d800ca9a3bc783e67b921d2beb8f6b389cc646d7263b4145701dadd2161548a8b078e65e9e022a471424da5e657499d1ff51cb43c47481a03b1e77f951fe64cec9f5a48f7011<br />
* (prv hex): 0488ade405d880d7d800ca9a3bc783e67b921d2beb8f6b389cc646d7263b4145701dadd2161548a8b078e65e9e00471b76e389e528d6de6d816857e012c5455051cad6660850e58372a6c3e6e7c8<br />
* (pub b58): xpub6H1LXWLWVdyPxBs9No8ZDmJF398PzxRZNFzrGfxvgAa68MWgAEQQU8w75csHPsxDs6pgwb1gzubwuVb2UGurDhoGwdh3F5EPePwzoqtnm3h<br />
* (prv b58): xprvA41z7zocfGR6jhngGmbYrdMWV7HubVhi135FUHZK7q37FZBXch69vLcdEN4DNGSX1uiQi7hPBq8sVN18wsEnEVyWxsS36daGcfxyYB3vzmp<br />
<br />
Test vector 2<br />
<br />
Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* Identifier<br />
* (hex): bd16bee53961a47d6ad888e29545434a89bdfe95<br />
* (fpr): 0xbd16bee5<br />
* (main addr): 1JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg<br />
* Secret key<br />
* (hex): 4b03d6fc340455b363f51020ad3ecca4f0850280cf436c70c727923f6db46c3e<br />
* (wif): KyjXhyHF9wTphBkfpxjL8hkDXDUSbE3tKANT94kXSyh6vn6nKaoy<br />
* Public key<br />
* (hex): 03cbcaa9c98c877a26977d00825c956a238e8dddfbd322cce4f74b0b5bd6ace4a7<br />
* Chain code<br />
* (hex): 60499f801b896d83179a4374aeb7822aaeaceaa0db1f85ee3e904c4defbd9689<br />
* Serialized<br />
* (pub hex): 0488b21e00000000000000000060499f801b896d83179a4374aeb7822aaeaceaa0db1f85ee3e904c4defbd968903cbcaa9c98c877a26977d00825c956a238e8dddfbd322cce4f74b0b5bd6ace4a7<br />
* (prv hex): 0488ade400000000000000000060499f801b896d83179a4374aeb7822aaeaceaa0db1f85ee3e904c4defbd9689004b03d6fc340455b363f51020ad3ecca4f0850280cf436c70c727923f6db46c3e<br />
* (pub b58): xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* (prv b58): xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* Identifier<br />
* (hex): 5a61ff8eb7aaca3010db97ebda76121610b78096<br />
* (fpr): 0x5a61ff8e<br />
* (main addr): 19EuDJdgfRkwCmRzbzVBHZWQG9QNWhftbZ<br />
* Secret key<br />
* (hex): abe74a98f6c7eabee0428f53798f0ab8aa1bd37873999041703c742f15ac7e1e<br />
* (wif): L2ysLrR6KMSAtx7uPqmYpoTeiRzydXBattRXjXz5GDFPrdfPzKbj<br />
* Public key<br />
* (hex): 02fc9e5af0ac8d9b3cecfe2a888e2117ba3d089d8585886c9c826b6b22a98d12ea<br />
* Chain code<br />
* (hex): f0909affaa7ee7abe5dd4e100598d4dc53cd709d5a5c2cac40e7412f232f7c9c<br />
* Serialized<br />
* (pub hex): 0488b21e01bd16bee500000000f0909affaa7ee7abe5dd4e100598d4dc53cd709d5a5c2cac40e7412f232f7c9c02fc9e5af0ac8d9b3cecfe2a888e2117ba3d089d8585886c9c826b6b22a98d12ea<br />
* (prv hex): 0488ade401bd16bee500000000f0909affaa7ee7abe5dd4e100598d4dc53cd709d5a5c2cac40e7412f232f7c9c00abe74a98f6c7eabee0428f53798f0ab8aa1bd37873999041703c742f15ac7e1e<br />
* (pub b58): xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* (prv b58): xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* Identifier<br />
* (hex): d8ab493736da02f11ed682f88339e720fb0379d1<br />
* (fpr): 0xd8ab4937<br />
* (main addr): 1Lke9bXGhn5VPrBuXgN12uGUphrttUErmk<br />
* Secret key<br />
* (hex): 877c779ad9687164e9c2f4f0f4ff0340814392330693ce95a58fe18fd52e6e93<br />
* (wif): L1m5VpbXmMp57P3knskwhoMTLdhAAaXiHvnGLMribbfwzVRpz2Sr<br />
* Public key<br />
* (hex): 03c01e7425647bdefa82b12d9bad5e3e6865bee0502694b94ca58b666abc0a5c3b<br />
* Chain code<br />
* (hex): be17a268474a6bb9c61e1d720cf6215e2a88c5406c4aee7b38547f585c9a37d9<br />
* Serialized<br />
* (pub hex): 0488b21e025a61ff8effffffffbe17a268474a6bb9c61e1d720cf6215e2a88c5406c4aee7b38547f585c9a37d903c01e7425647bdefa82b12d9bad5e3e6865bee0502694b94ca58b666abc0a5c3b<br />
* (prv hex): 0488ade4025a61ff8effffffffbe17a268474a6bb9c61e1d720cf6215e2a88c5406c4aee7b38547f585c9a37d900877c779ad9687164e9c2f4f0f4ff0340814392330693ce95a58fe18fd52e6e93<br />
* (pub b58): xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* (prv b58): xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* Identifier<br />
* (hex): 78412e3a2296a40de124307b6485bd19833e2e34<br />
* (fpr): 0x78412e3a<br />
* (main addr): 1BxrAr2pHpeBheusmd6fHDP2tSLAUa3qsW<br />
* Secret key<br />
* (hex): 704addf544a06e5ee4bea37098463c23613da32020d604506da8c0518e1da4b7<br />
* (wif): KzyzXnznxSv249b4KuNkBwowaN3akiNeEHy5FWoPCJpStZbEKXN2<br />
* Public key<br />
* (hex): 03a7d1d856deb74c508e05031f9895dab54626251b3806e16b4bd12e781a7df5b9<br />
* Chain code<br />
* (hex): f366f48f1ea9f2d1d3fe958c95ca84ea18e4c4ddb9366c336c927eb246fb38cb<br />
* Serialized<br />
* (pub hex): 0488b21e03d8ab493701000000f366f48f1ea9f2d1d3fe958c95ca84ea18e4c4ddb9366c336c927eb246fb38cb03a7d1d856deb74c508e05031f9895dab54626251b3806e16b4bd12e781a7df5b9<br />
* (prv hex): 0488ade403d8ab493701000000f366f48f1ea9f2d1d3fe958c95ca84ea18e4c4ddb9366c336c927eb246fb38cb00704addf544a06e5ee4bea37098463c23613da32020d604506da8c0518e1da4b7<br />
* (pub b58): xpub6DF8uhdavm4Heqy6MGM3swJq91Pt5bxSd7oGXhEEV3pZfG6PDmy37noxcDLSR23EBPhUWGGa5uknBpb7Bg72nuRBg8wnUBi5WGmfnPuR8Ky<br />
* (prv b58): xprv9zFnWC6h6PVzSMtdFEp3WoN6ayZPg9EbFtsfjJpcviHanTmEgEenZzVUkuwURjHUdBNKuYnssvxTxrzYaFkzqFaMeBhy8zeLUPjev2dM8z8<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* Identifier<br />
* (hex): 31a507b815593dfc51ffc7245ae7e5aee304246e<br />
* (fpr): 0x31a507b8<br />
* (main addr): 15XVotxCAV7sRx1PSCkQNsGw3W9jT9A94R<br />
* Secret key<br />
* (hex): f1c7c871a54a804afe328b4c83a1c33b8e5ff48f5087273f04efa83b247d6a2d<br />
* (wif): L5KhaMvPYRW1ZoFmRjUtxxPypQ94m6BcDrPhqArhggdaTbbAFJEF<br />
* Public key<br />
* (hex): 02d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0<br />
* Chain code<br />
* (hex): 637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e29<br />
* Serialized<br />
* (pub hex): 0488b21e0478412e3afeffffff637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e2902d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0<br />
* (prv hex): 0488ade40478412e3afeffffff637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e2900f1c7c871a54a804afe328b4c83a1c33b8e5ff48f5087273f04efa83b247d6a2d<br />
* (pub b58): xpub6ERApfZwQbhPicHkhUQKzUFC77LjjSiJVHzrd5SJEztkh3G5Q4WKZDS8sz3mkkJTNna4qqpHtyzUVCpaBpUp2bMWUgiXekZ8UAmZojPj4Cv<br />
* (prv b58): xprvA1RpRA33aE96W8DHbSsKdLJTZ5WFKyzT855Fph2ggfMmpEvvrXC51R7f2jFhCWQYQhsykT3t2mStRj9zQTvm3RVPzmhXuURbuefVUBDHron<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* Identifier<br />
* (hex): 26132fdbe7bf89cbc64cf8dafa3f9f88b8666220<br />
* (fpr): 0x26132fdb<br />
* (main addr): 14UKfRV9ZPUp6ZC9PLhqbRtxdihW9em3xt<br />
* Secret key<br />
* (hex): bb7d39bdb83ecf58f2fd82b6d918341cbef428661ef01ab97c28a4842125ac23<br />
* (wif): L3WAYNAZPxx1fr7KCz7GN9nD5qMBnNiqEJNJMU1z9MMaannAt4aK<br />
* Public key<br />
* (hex): 024d902e1a2fc7a8755ab5b694c575fce742c48d9ff192e63df5193e4c7afe1f9c<br />
* Chain code<br />
* (hex): 9452b549be8cea3ecb7a84bec10dcfd94afe4d129ebfd3b3cb58eedf394ed271<br />
* Serialized<br />
* (pub hex): 0488b21e0531a507b8020000009452b549be8cea3ecb7a84bec10dcfd94afe4d129ebfd3b3cb58eedf394ed271024d902e1a2fc7a8755ab5b694c575fce742c48d9ff192e63df5193e4c7afe1f9c<br />
* (prv hex): 0488ade40531a507b8020000009452b549be8cea3ecb7a84bec10dcfd94afe4d129ebfd3b3cb58eedf394ed27100bb7d39bdb83ecf58f2fd82b6d918341cbef428661ef01ab97c28a4842125ac23<br />
* (pub b58): xpub6FnCn6nT87VYJer3zxBQrgkuR7fc5USLtkQCBs2K11Xvu6LWSn2AsRzWziFJfnYz2uwrp9bgdzeD12GxYXGp4MMHKtNEeiDQVxamjrYLJcT<br />
* (prv b58): xprvA2nrNbFZHjwF6AmatveQVYpAs5q7g1iVXXUbPUchSfzx2J1MuEhvKdg39U3x8zPSb5uGjaxgLAvKVfSPfPQ5ouNK1f2f2UvrxWd4pCHQBvC</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=38038BIP 00322013-05-25T22:57:25Z<p>Sipa: /* Test Vectors */</p>
<hr />
<div>{{bip}}<br />
<br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
* [25 May 2013] Added test vectors<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
<br />
==Test Vectors==<br />
<br />
For more detailed information about these (such as intermediate values and other representations), see [[BIP_0032_TestVectors]]<br />
<br />
Test vector 1<br />
<br />
Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* ext pub: xpub68Gmy5EVb2BirTFP4SuLeZw3sn3TC9o4ZwRHbQFe6M7t6b3o6oAHtM2DHZ34QSrHhwnkAcN6XyWKWCJmkXnXdCDqh5gGQuJnayTxrhi9oAm<br />
* ext prv: xprv9uHRZZhbkedRdyAuxRNLHRzKKkCxnh5DCiVgo1r2Y1auDnieZFr3LYhjSHBPYxueVFVwAj8PYPvoT3BD9rVgjLqYmcpva2bs1wNWwpp3xqH<br />
* [Chain m/0'/1]<br />
* ext pub: xpub6ASuArnXPAkxrYAJZEXBQRZXBmxFRSLgbhnWrr3nPTiQA1KugzrQWo9nRosbXKzKekW2tYfMCeEh871nutUf5T85udprZ2HJQvhgabyHAE3<br />
* ext prv: xprv9wTYmMFdYoCfe45qTCzB3Hcndk7m1ycqEUrv4TeAq8BRHCzm9TY9xzqJaWkQrq7NvRLrv4ZyBB87cafdyDouH7QJCk6PJGLxsxPpuoQpGZm<br />
* [Chain m/0'/1/2']<br />
* ext pub: xpub6D4BDPcEpAEonFzrRZxqsHcg6wRarryz1Kr6sLoxHfUbAYuHYjokqTDHcY6e7uGAnEHa2LJoG3evu67ochEgqxxk3Y31MDd6qizZkTmksfm<br />
* ext prv: xprv9z4pot5LyngWZmvPKYRqW9fwYub6TQG8e6vW4xQLjKwcHka91CVWHetomG1EymTQCr442wBjH3oHASN7Ywwb7GXn7MtxASs2CLWncyE79fZ<br />
* [Chain m/0'/1/2'/2]<br />
* ext pub: xpub6FHa3pjLLJSfQmtahE1mHR8tU4Nm29BBxVAe5ocavBEyeEj1XDaZfN36LbkuJpCyrc7TsPsuF6FMoyy3Z9pm6L8F8zd4A2MzbU51aJ5eaef<br />
* ext prv: xprvA2JDeKCSVvtNCHp7bCUkvHC9v2YGcgTLbGF3HRCyMqhzmSPrygGK7ZicVK5aDYeushtUMuWT8Awkz6mobXdoqRp4hH1uh9Xo6N9YomRreS6<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* ext pub: xpub6H1LXWLWVdyPxBs9No8ZDmJF398PzxRZNFzrGfxvgAa68MWgAEQQU8w75csHPsxDs6pgwb1gzubwuVb2UGurDhoGwdh3F5EPePwzoqtnm3h<br />
* ext prv: xprvA41z7zocfGR6jhngGmbYrdMWV7HubVhi135FUHZK7q37FZBXch69vLcdEN4DNGSX1uiQi7hPBq8sVN18wsEnEVyWxsS36daGcfxyYB3vzmp<br />
<br />
Test vector 2<br />
<br />
Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* ext pub: xpub6DF8uhdavm4Heqy6MGM3swJq91Pt5bxSd7oGXhEEV3pZfG6PDmy37noxcDLSR23EBPhUWGGa5uknBpb7Bg72nuRBg8wnUBi5WGmfnPuR8Ky<br />
* ext prv: xprv9zFnWC6h6PVzSMtdFEp3WoN6ayZPg9EbFtsfjJpcviHanTmEgEenZzVUkuwURjHUdBNKuYnssvxTxrzYaFkzqFaMeBhy8zeLUPjev2dM8z8<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* ext pub: xpub6ERApfZwQbhPicHkhUQKzUFC77LjjSiJVHzrd5SJEztkh3G5Q4WKZDS8sz3mkkJTNna4qqpHtyzUVCpaBpUp2bMWUgiXekZ8UAmZojPj4Cv<br />
* ext prv: xprvA1RpRA33aE96W8DHbSsKdLJTZ5WFKyzT855Fph2ggfMmpEvvrXC51R7f2jFhCWQYQhsykT3t2mStRj9zQTvm3RVPzmhXuURbuefVUBDHron<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* ext pub: xpub6FnCn6nT87VYJer3zxBQrgkuR7fc5USLtkQCBs2K11Xvu6LWSn2AsRzWziFJfnYz2uwrp9bgdzeD12GxYXGp4MMHKtNEeiDQVxamjrYLJcT<br />
* ext prv: xprvA2nrNbFZHjwF6AmatveQVYpAs5q7g1iVXXUbPUchSfzx2J1MuEhvKdg39U3x8zPSb5uGjaxgLAvKVfSPfPQ5ouNK1f2f2UvrxWd4pCHQBvC<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=38036BIP 00322013-05-25T22:27:48Z<p>Sipa: formatting</p>
<hr />
<div>{{bip}}<br />
<br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
* [25 May 2013] Added test vectors<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
<br />
==Test Vectors==<br />
<br />
Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* ext pub: xpub68Gmy5EVb2BirTFP4SuLeZw3sn3TC9o4ZwRHbQFe6M7t6b3o6oAHtM2DHZ34QSrHhwnkAcN6XyWKWCJmkXnXdCDqh5gGQuJnayTxrhi9oAm<br />
* ext prv: xprv9uHRZZhbkedRdyAuxRNLHRzKKkCxnh5DCiVgo1r2Y1auDnieZFr3LYhjSHBPYxueVFVwAj8PYPvoT3BD9rVgjLqYmcpva2bs1wNWwpp3xqH<br />
* [Chain m/0'/1]<br />
* ext pub: xpub6ASuArnXPAkxrYAJZEXBQRZXBmxFRSLgbhnWrr3nPTiQA1KugzrQWo9nRosbXKzKekW2tYfMCeEh871nutUf5T85udprZ2HJQvhgabyHAE3<br />
* ext prv: xprv9wTYmMFdYoCfe45qTCzB3Hcndk7m1ycqEUrv4TeAq8BRHCzm9TY9xzqJaWkQrq7NvRLrv4ZyBB87cafdyDouH7QJCk6PJGLxsxPpuoQpGZm<br />
* [Chain m/0'/1/2']<br />
* ext pub: xpub6D4BDPcEpAEonFzrRZxqsHcg6wRarryz1Kr6sLoxHfUbAYuHYjokqTDHcY6e7uGAnEHa2LJoG3evu67ochEgqxxk3Y31MDd6qizZkTmksfm<br />
* ext prv: xprv9z4pot5LyngWZmvPKYRqW9fwYub6TQG8e6vW4xQLjKwcHka91CVWHetomG1EymTQCr442wBjH3oHASN7Ywwb7GXn7MtxASs2CLWncyE79fZ<br />
* [Chain m/0'/1/2'/2]<br />
* ext pub: xpub6FHa3pjLLJSfQmtahE1mHR8tU4Nm29BBxVAe5ocavBEyeEj1XDaZfN36LbkuJpCyrc7TsPsuF6FMoyy3Z9pm6L8F8zd4A2MzbU51aJ5eaef<br />
* ext prv: xprvA2JDeKCSVvtNCHp7bCUkvHC9v2YGcgTLbGF3HRCyMqhzmSPrygGK7ZicVK5aDYeushtUMuWT8Awkz6mobXdoqRp4hH1uh9Xo6N9YomRreS6<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* ext pub: xpub6H1LXWLWVdyPxBs9No8ZDmJF398PzxRZNFzrGfxvgAa68MWgAEQQU8w75csHPsxDs6pgwb1gzubwuVb2UGurDhoGwdh3F5EPePwzoqtnm3h<br />
* ext prv: xprvA41z7zocfGR6jhngGmbYrdMWV7HubVhi135FUHZK7q37FZBXch69vLcdEN4DNGSX1uiQi7hPBq8sVN18wsEnEVyWxsS36daGcfxyYB3vzmp<br />
<br />
Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* ext pub: xpub6DF8uhdavm4Heqy6MGM3swJq91Pt5bxSd7oGXhEEV3pZfG6PDmy37noxcDLSR23EBPhUWGGa5uknBpb7Bg72nuRBg8wnUBi5WGmfnPuR8Ky<br />
* ext prv: xprv9zFnWC6h6PVzSMtdFEp3WoN6ayZPg9EbFtsfjJpcviHanTmEgEenZzVUkuwURjHUdBNKuYnssvxTxrzYaFkzqFaMeBhy8zeLUPjev2dM8z8<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* ext pub: xpub6ERApfZwQbhPicHkhUQKzUFC77LjjSiJVHzrd5SJEztkh3G5Q4WKZDS8sz3mkkJTNna4qqpHtyzUVCpaBpUp2bMWUgiXekZ8UAmZojPj4Cv<br />
* ext prv: xprvA1RpRA33aE96W8DHbSsKdLJTZ5WFKyzT855Fph2ggfMmpEvvrXC51R7f2jFhCWQYQhsykT3t2mStRj9zQTvm3RVPzmhXuURbuefVUBDHron<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* ext pub: xpub6FnCn6nT87VYJer3zxBQrgkuR7fc5USLtkQCBs2K11Xvu6LWSn2AsRzWziFJfnYz2uwrp9bgdzeD12GxYXGp4MMHKtNEeiDQVxamjrYLJcT<br />
* ext prv: xprvA2nrNbFZHjwF6AmatveQVYpAs5q7g1iVXXUbPUchSfzx2J1MuEhvKdg39U3x8zPSb5uGjaxgLAvKVfSPfPQ5ouNK1f2f2UvrxWd4pCHQBvC<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=38035BIP 00322013-05-25T22:27:43Z<p>Sipa: formatting</p>
<hr />
<div>{{bip}}<br />
<br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
* [25 May 2013] Added test vectors<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* ext pub: xpub68Gmy5EVb2BirTFP4SuLeZw3sn3TC9o4ZwRHbQFe6M7t6b3o6oAHtM2DHZ34QSrHhwnkAcN6XyWKWCJmkXnXdCDqh5gGQuJnayTxrhi9oAm<br />
* ext prv: xprv9uHRZZhbkedRdyAuxRNLHRzKKkCxnh5DCiVgo1r2Y1auDnieZFr3LYhjSHBPYxueVFVwAj8PYPvoT3BD9rVgjLqYmcpva2bs1wNWwpp3xqH<br />
* [Chain m/0'/1]<br />
* ext pub: xpub6ASuArnXPAkxrYAJZEXBQRZXBmxFRSLgbhnWrr3nPTiQA1KugzrQWo9nRosbXKzKekW2tYfMCeEh871nutUf5T85udprZ2HJQvhgabyHAE3<br />
* ext prv: xprv9wTYmMFdYoCfe45qTCzB3Hcndk7m1ycqEUrv4TeAq8BRHCzm9TY9xzqJaWkQrq7NvRLrv4ZyBB87cafdyDouH7QJCk6PJGLxsxPpuoQpGZm<br />
* [Chain m/0'/1/2']<br />
* ext pub: xpub6D4BDPcEpAEonFzrRZxqsHcg6wRarryz1Kr6sLoxHfUbAYuHYjokqTDHcY6e7uGAnEHa2LJoG3evu67ochEgqxxk3Y31MDd6qizZkTmksfm<br />
* ext prv: xprv9z4pot5LyngWZmvPKYRqW9fwYub6TQG8e6vW4xQLjKwcHka91CVWHetomG1EymTQCr442wBjH3oHASN7Ywwb7GXn7MtxASs2CLWncyE79fZ<br />
* [Chain m/0'/1/2'/2]<br />
* ext pub: xpub6FHa3pjLLJSfQmtahE1mHR8tU4Nm29BBxVAe5ocavBEyeEj1XDaZfN36LbkuJpCyrc7TsPsuF6FMoyy3Z9pm6L8F8zd4A2MzbU51aJ5eaef<br />
* ext prv: xprvA2JDeKCSVvtNCHp7bCUkvHC9v2YGcgTLbGF3HRCyMqhzmSPrygGK7ZicVK5aDYeushtUMuWT8Awkz6mobXdoqRp4hH1uh9Xo6N9YomRreS6<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* ext pub: xpub6H1LXWLWVdyPxBs9No8ZDmJF398PzxRZNFzrGfxvgAa68MWgAEQQU8w75csHPsxDs6pgwb1gzubwuVb2UGurDhoGwdh3F5EPePwzoqtnm3h<br />
* ext prv: xprvA41z7zocfGR6jhngGmbYrdMWV7HubVhi135FUHZK7q37FZBXch69vLcdEN4DNGSX1uiQi7hPBq8sVN18wsEnEVyWxsS36daGcfxyYB3vzmp<br />
<br />
Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* ext pub: xpub6DF8uhdavm4Heqy6MGM3swJq91Pt5bxSd7oGXhEEV3pZfG6PDmy37noxcDLSR23EBPhUWGGa5uknBpb7Bg72nuRBg8wnUBi5WGmfnPuR8Ky<br />
* ext prv: xprv9zFnWC6h6PVzSMtdFEp3WoN6ayZPg9EbFtsfjJpcviHanTmEgEenZzVUkuwURjHUdBNKuYnssvxTxrzYaFkzqFaMeBhy8zeLUPjev2dM8z8<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* ext pub: xpub6ERApfZwQbhPicHkhUQKzUFC77LjjSiJVHzrd5SJEztkh3G5Q4WKZDS8sz3mkkJTNna4qqpHtyzUVCpaBpUp2bMWUgiXekZ8UAmZojPj4Cv<br />
* ext prv: xprvA1RpRA33aE96W8DHbSsKdLJTZ5WFKyzT855Fph2ggfMmpEvvrXC51R7f2jFhCWQYQhsykT3t2mStRj9zQTvm3RVPzmhXuURbuefVUBDHron<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* ext pub: xpub6FnCn6nT87VYJer3zxBQrgkuR7fc5USLtkQCBs2K11Xvu6LWSn2AsRzWziFJfnYz2uwrp9bgdzeD12GxYXGp4MMHKtNEeiDQVxamjrYLJcT<br />
* ext prv: xprvA2nrNbFZHjwF6AmatveQVYpAs5q7g1iVXXUbPUchSfzx2J1MuEhvKdg39U3x8zPSb5uGjaxgLAvKVfSPfPQ5ouNK1f2f2UvrxWd4pCHQBvC<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=38034BIP 00322013-05-25T22:25:31Z<p>Sipa: changelog</p>
<hr />
<div>{{bip}}<br />
<br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
* [25 May 2013] Added test vectors<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
* Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* ext pub: xpub68Gmy5EVb2BirTFP4SuLeZw3sn3TC9o4ZwRHbQFe6M7t6b3o6oAHtM2DHZ34QSrHhwnkAcN6XyWKWCJmkXnXdCDqh5gGQuJnayTxrhi9oAm<br />
* ext prv: xprv9uHRZZhbkedRdyAuxRNLHRzKKkCxnh5DCiVgo1r2Y1auDnieZFr3LYhjSHBPYxueVFVwAj8PYPvoT3BD9rVgjLqYmcpva2bs1wNWwpp3xqH<br />
* [Chain m/0'/1]<br />
* ext pub: xpub6ASuArnXPAkxrYAJZEXBQRZXBmxFRSLgbhnWrr3nPTiQA1KugzrQWo9nRosbXKzKekW2tYfMCeEh871nutUf5T85udprZ2HJQvhgabyHAE3<br />
* ext prv: xprv9wTYmMFdYoCfe45qTCzB3Hcndk7m1ycqEUrv4TeAq8BRHCzm9TY9xzqJaWkQrq7NvRLrv4ZyBB87cafdyDouH7QJCk6PJGLxsxPpuoQpGZm<br />
* [Chain m/0'/1/2']<br />
* ext pub: xpub6D4BDPcEpAEonFzrRZxqsHcg6wRarryz1Kr6sLoxHfUbAYuHYjokqTDHcY6e7uGAnEHa2LJoG3evu67ochEgqxxk3Y31MDd6qizZkTmksfm<br />
* ext prv: xprv9z4pot5LyngWZmvPKYRqW9fwYub6TQG8e6vW4xQLjKwcHka91CVWHetomG1EymTQCr442wBjH3oHASN7Ywwb7GXn7MtxASs2CLWncyE79fZ<br />
* [Chain m/0'/1/2'/2]<br />
* ext pub: xpub6FHa3pjLLJSfQmtahE1mHR8tU4Nm29BBxVAe5ocavBEyeEj1XDaZfN36LbkuJpCyrc7TsPsuF6FMoyy3Z9pm6L8F8zd4A2MzbU51aJ5eaef<br />
* ext prv: xprvA2JDeKCSVvtNCHp7bCUkvHC9v2YGcgTLbGF3HRCyMqhzmSPrygGK7ZicVK5aDYeushtUMuWT8Awkz6mobXdoqRp4hH1uh9Xo6N9YomRreS6<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* ext pub: xpub6H1LXWLWVdyPxBs9No8ZDmJF398PzxRZNFzrGfxvgAa68MWgAEQQU8w75csHPsxDs6pgwb1gzubwuVb2UGurDhoGwdh3F5EPePwzoqtnm3h<br />
* ext prv: xprvA41z7zocfGR6jhngGmbYrdMWV7HubVhi135FUHZK7q37FZBXch69vLcdEN4DNGSX1uiQi7hPBq8sVN18wsEnEVyWxsS36daGcfxyYB3vzmp<br />
* Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* ext pub: xpub6DF8uhdavm4Heqy6MGM3swJq91Pt5bxSd7oGXhEEV3pZfG6PDmy37noxcDLSR23EBPhUWGGa5uknBpb7Bg72nuRBg8wnUBi5WGmfnPuR8Ky<br />
* ext prv: xprv9zFnWC6h6PVzSMtdFEp3WoN6ayZPg9EbFtsfjJpcviHanTmEgEenZzVUkuwURjHUdBNKuYnssvxTxrzYaFkzqFaMeBhy8zeLUPjev2dM8z8<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* ext pub: xpub6ERApfZwQbhPicHkhUQKzUFC77LjjSiJVHzrd5SJEztkh3G5Q4WKZDS8sz3mkkJTNna4qqpHtyzUVCpaBpUp2bMWUgiXekZ8UAmZojPj4Cv<br />
* ext prv: xprvA1RpRA33aE96W8DHbSsKdLJTZ5WFKyzT855Fph2ggfMmpEvvrXC51R7f2jFhCWQYQhsykT3t2mStRj9zQTvm3RVPzmhXuURbuefVUBDHron<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* ext pub: xpub6FnCn6nT87VYJer3zxBQrgkuR7fc5USLtkQCBs2K11Xvu6LWSn2AsRzWziFJfnYz2uwrp9bgdzeD12GxYXGp4MMHKtNEeiDQVxamjrYLJcT<br />
* ext prv: xprvA2nrNbFZHjwF6AmatveQVYpAs5q7g1iVXXUbPUchSfzx2J1MuEhvKdg39U3x8zPSb5uGjaxgLAvKVfSPfPQ5ouNK1f2f2UvrxWd4pCHQBvC<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=38033BIP 00322013-05-25T22:24:19Z<p>Sipa: test vectors</p>
<hr />
<div>{{bip}}<br />
<br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
* Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* ext pub: xpub68Gmy5EVb2BirTFP4SuLeZw3sn3TC9o4ZwRHbQFe6M7t6b3o6oAHtM2DHZ34QSrHhwnkAcN6XyWKWCJmkXnXdCDqh5gGQuJnayTxrhi9oAm<br />
* ext prv: xprv9uHRZZhbkedRdyAuxRNLHRzKKkCxnh5DCiVgo1r2Y1auDnieZFr3LYhjSHBPYxueVFVwAj8PYPvoT3BD9rVgjLqYmcpva2bs1wNWwpp3xqH<br />
* [Chain m/0'/1]<br />
* ext pub: xpub6ASuArnXPAkxrYAJZEXBQRZXBmxFRSLgbhnWrr3nPTiQA1KugzrQWo9nRosbXKzKekW2tYfMCeEh871nutUf5T85udprZ2HJQvhgabyHAE3<br />
* ext prv: xprv9wTYmMFdYoCfe45qTCzB3Hcndk7m1ycqEUrv4TeAq8BRHCzm9TY9xzqJaWkQrq7NvRLrv4ZyBB87cafdyDouH7QJCk6PJGLxsxPpuoQpGZm<br />
* [Chain m/0'/1/2']<br />
* ext pub: xpub6D4BDPcEpAEonFzrRZxqsHcg6wRarryz1Kr6sLoxHfUbAYuHYjokqTDHcY6e7uGAnEHa2LJoG3evu67ochEgqxxk3Y31MDd6qizZkTmksfm<br />
* ext prv: xprv9z4pot5LyngWZmvPKYRqW9fwYub6TQG8e6vW4xQLjKwcHka91CVWHetomG1EymTQCr442wBjH3oHASN7Ywwb7GXn7MtxASs2CLWncyE79fZ<br />
* [Chain m/0'/1/2'/2]<br />
* ext pub: xpub6FHa3pjLLJSfQmtahE1mHR8tU4Nm29BBxVAe5ocavBEyeEj1XDaZfN36LbkuJpCyrc7TsPsuF6FMoyy3Z9pm6L8F8zd4A2MzbU51aJ5eaef<br />
* ext prv: xprvA2JDeKCSVvtNCHp7bCUkvHC9v2YGcgTLbGF3HRCyMqhzmSPrygGK7ZicVK5aDYeushtUMuWT8Awkz6mobXdoqRp4hH1uh9Xo6N9YomRreS6<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* ext pub: xpub6H1LXWLWVdyPxBs9No8ZDmJF398PzxRZNFzrGfxvgAa68MWgAEQQU8w75csHPsxDs6pgwb1gzubwuVb2UGurDhoGwdh3F5EPePwzoqtnm3h<br />
* ext prv: xprvA41z7zocfGR6jhngGmbYrdMWV7HubVhi135FUHZK7q37FZBXch69vLcdEN4DNGSX1uiQi7hPBq8sVN18wsEnEVyWxsS36daGcfxyYB3vzmp<br />
* Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* ext pub: xpub6DF8uhdavm4Heqy6MGM3swJq91Pt5bxSd7oGXhEEV3pZfG6PDmy37noxcDLSR23EBPhUWGGa5uknBpb7Bg72nuRBg8wnUBi5WGmfnPuR8Ky<br />
* ext prv: xprv9zFnWC6h6PVzSMtdFEp3WoN6ayZPg9EbFtsfjJpcviHanTmEgEenZzVUkuwURjHUdBNKuYnssvxTxrzYaFkzqFaMeBhy8zeLUPjev2dM8z8<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* ext pub: xpub6ERApfZwQbhPicHkhUQKzUFC77LjjSiJVHzrd5SJEztkh3G5Q4WKZDS8sz3mkkJTNna4qqpHtyzUVCpaBpUp2bMWUgiXekZ8UAmZojPj4Cv<br />
* ext prv: xprvA1RpRA33aE96W8DHbSsKdLJTZ5WFKyzT855Fph2ggfMmpEvvrXC51R7f2jFhCWQYQhsykT3t2mStRj9zQTvm3RVPzmhXuURbuefVUBDHron<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* ext pub: xpub6FnCn6nT87VYJer3zxBQrgkuR7fc5USLtkQCBs2K11Xvu6LWSn2AsRzWziFJfnYz2uwrp9bgdzeD12GxYXGp4MMHKtNEeiDQVxamjrYLJcT<br />
* ext prv: xprvA2nrNbFZHjwF6AmatveQVYpAs5q7g1iVXXUbPUchSfzx2J1MuEhvKdg39U3x8zPSb5uGjaxgLAvKVfSPfPQ5ouNK1f2f2UvrxWd4pCHQBvC<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=37700BIP 00322013-05-11T08:40:59Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final.<br />
</div><br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=37414BIP 00322013-04-30T18:44:31Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final.<br />
</div><br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 0, "public derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i) (with K<sub>par</sub> = k<sub>par</sub>*G, EC multiplication)<br />
** If 1, "secret derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=0x00 || k<sub>par</sub> || i) (The 0x00 makes sure the data being hashed aligns with the public version)<br />
** (in the above, i is encoded as a 32 bits unsigned integer, most significant byte first; '||' represents concatenation)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>+k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* If i has its highest bit set, return error<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*G + K<sub>par</sub> (EC addition).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=37158BIP 00322013-04-19T22:44:46Z<p>Sipa: 256 ought to be enough for everyone</p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 0, "public derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i) (with K<sub>par</sub> = k<sub>par</sub>*G, EC multiplication)<br />
** If 1, "secret derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=0x00 || k<sub>par</sub> || i) (The 0x00 makes sure the data being hashed aligns with the public version)<br />
** (in the above, i is encoded as a 32 bits unsigned integer, most significant byte first; '||' represents concatenation)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* If i has its highest bit set, return error<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub> (EC multiplication).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=37093BIP 00322013-04-16T19:43:47Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 0, "public derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i) (with K<sub>par</sub> = k<sub>par</sub>*G, EC multiplication)<br />
** If 1, "secret derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=0x00 || k<sub>par</sub> || i) (The 0x00 makes sure the data being hashed aligns with the public version)<br />
** (in the above, i is encoded as a 32 bits unsigned integer, most significant byte first; '||' represents concatenation)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* If i has its highest bit set, return error<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub> (EC multiplication).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=37070BIP 00322013-04-16T00:35:52Z<p>Sipa: /* Test Vectors */</p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 0, "public derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i) (with K<sub>par</sub> = k<sub>par</sub>*G, EC multiplication)<br />
** If 1, "secret derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub> || i)<br />
** (in the above, i is encoded as a 32 bits unsigned integer, most significant byte first; '||' represents concatenation)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* If i has its highest bit set, return error<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub> (EC multiplication).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=37069BIP 00322013-04-16T00:35:18Z<p>Sipa: /* The key tree */</p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 0, "public derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i) (with K<sub>par</sub> = k<sub>par</sub>*G, EC multiplication)<br />
** If 1, "secret derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub> || i)<br />
** (in the above, i is encoded as a 32 bits unsigned integer, most significant byte first; '||' represents concatenation)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* If i has its highest bit set, return error<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub> (EC multiplication).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final. Things will likely change still.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=37068BIP 00322013-04-16T00:34:10Z<p>Sipa: /* Child key derivation function */</p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 0, "public derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i) (with K<sub>par</sub> = k<sub>par</sub>*G, EC multiplication)<br />
** If 1, "secret derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub> || i)<br />
** (in the above, i is encoded as a 32 bits unsigned integer, most significant byte first; '||' represents concatenation)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* If i has its highest bit set, return error<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub> (EC multiplication).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/s<sub>3'</sub>/p<sub>2</sub>/p<sub>5</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final. Things will likely change still.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=37067BIP 00322013-04-16T00:33:29Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
* * If 0, "public derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i) (with K<sub>par</sub> = k<sub>par</sub>*G, EC multiplication)<br />
* * If 1, "secret derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub> || i)<br />
* * (in the above, i is encoded as a 32 bits unsigned integer, most significant byte first; '||' represents concatenation)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* If i has its highest bit set, return error<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub> (EC multiplication).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/s<sub>3'</sub>/p<sub>2</sub>/p<sub>5</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final. Things will likely change still.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=37066BIP 00322013-04-16T00:33:07Z<p>Sipa: Private derivation</p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
* If 0, "public derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i) (with K<sub>par</sub> = k<sub>par</sub>*G, EC multiplication)<br />
* If 1, "secret derivation" is used: let I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub> || i)<br />
* (in the above, i is encoded as a 32 bits unsigned integer, most significant byte first; '||' represents concatenation)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* If i has its highest bit set, return error<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub> (EC multiplication).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/s<sub>3'</sub>/p<sub>2</sub>/p<sub>5</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
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 mimick it for compatibility, even if not all features are supported.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
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'/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final. Things will likely change still.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36944BIP 00322013-04-13T16:20:05Z<p>Sipa: /* Security */</p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final. There is a small security weakness with it still, and I'm planning to make a few changes soon to deal with it. It will involve complicating the key derivation algorithm.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || i), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and i is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i), where i is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,i<sub>1</sub>),i<sub>2</sub>),i<sub>3</sub>) as m/i<sub>1</sub>/i<sub>2</sub>/i<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>. <span style="color:red">This is considered a weakness, and is planned to be changed.</span><br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final. Things will likely change still.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36943BIP 00322013-04-13T16:18:52Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final. There is a small security weakness with it still, and I'm planning to make a few changes soon to deal with it. It will involve complicating the key derivation algorithm.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || i), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and i is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i), where i is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,i<sub>1</sub>),i<sub>2</sub>),i<sub>3</sub>) as m/i<sub>1</sub>/i<sub>2</sub>/i<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final. Things will likely change still.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36942BIP 00322013-04-13T16:16:28Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<div style="color:red"><br />
WARNING: please do not assume this specification is final. There is a small security weakness with it still, and I'm planning to make a few changes soon to deal with it. It will involve complication the key derivation algorithm.<br />
</div><br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || i), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and i is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i), where i is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,i<sub>1</sub>),i<sub>2</sub>),i<sub>3</sub>) as m/i<sub>1</sub>/i<sub>2</sub>/i<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final. Things will likely change still.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36941BIP 00322013-04-13T16:13:01Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
WARNING: please do not assume this specification is final. There is a small security weakness with it still, and I'm planning to make a few changes soon to deal with it. It will involve complication the key derivation algorithm.<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || i), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and i is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i), where i is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,i<sub>1</sub>),i<sub>2</sub>),i<sub>3</sub>) as m/i<sub>1</sub>/i<sub>2</sub>/i<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
I'll publish test vectors as soon as the specification is assumed to be final. Things will likely change still.<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36333BIP 00322013-03-23T22:13:38Z<p>Sipa: /* Child key derivation function */</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || i), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and i is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i (note that this has a chance lower than 1 in 2<sup>127</sup>).<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i), where i is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,i<sub>1</sub>),i<sub>2</sub>),i<sub>3</sub>) as m/i<sub>1</sub>/i<sub>2</sub>/i<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
Come back soon!<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36332BIP 00322013-03-23T22:12:55Z<p>Sipa: /* Child key derivation function */</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),i), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || i), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and i is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i), where i is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,i<sub>1</sub>),i<sub>2</sub>),i<sub>3</sub>) as m/i<sub>1</sub>/i<sub>2</sub>/i<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
Come back soon!<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36331BIP 00322013-03-23T22:11:54Z<p>Sipa: rename n to i; reject I_L >= n</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),n), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer i, to produce a child extended secret key (k<sub>i</sub>,c<sub>i</sub>).<br />
<br />
To define (k<sub>i</sub>,c<sub>i</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || i), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and i is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>i</sub>,c<sub>i</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),i):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || i), where i is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>i</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0 or >=n, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,i) is identical to the evaluation of CKD'(X,i), with X the extended public key corresponding to x. Symbolically, CKD(x,i)*G = CKD'(x*G,i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,i<sub>1</sub>),i<sub>2</sub>),i<sub>3</sub>) as m/i<sub>1</sub>/i<sub>2</sub>/i<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
Come back soon!<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36142BIP 00322013-03-15T18:24:31Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve, serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),n), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer n, to produce a child extended secret key (k<sub>n</sub>,c<sub>n</sub>).<br />
<br />
To define (k<sub>n</sub>,c<sub>n</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),n):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || n), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and n is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>n</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>n</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0, the resulting key is invalid.<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>n</sub>,c<sub>n</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),n):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || n), where n is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>n</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>n</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0, the resulting key is invalid.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,n) is identical to the evaluation of CKD'(X,n), with X the extended public key corresponding to x. Symbolically, CKD(x,n)*G = CKD'(x*G,n). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,n) for several values of n, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,n<sub>1</sub>),n<sub>2</sub>),n<sub>3</sub>) as m/n<sub>1</sub>/n<sub>2</sub>/n<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number n in x<sub>n</sub> = x<sub>par</sub>/n, with x<sub>n</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>n</sub>,c<sub>n</sub>) and the integer n, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>n</sub>), it is hard to find n.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>n</sub>), it is hard to find k<sub>par</sub>.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
Come back soon!<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36140BIP 00322013-03-15T16:30:18Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve, serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),n), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer n, to produce a child extended secret key (k<sub>n</sub>,c<sub>n</sub>).<br />
<br />
To define (k<sub>n</sub>,c<sub>n</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),n):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || n), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and n is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>n</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>n</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0, the resulting key is invalid.<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>n</sub>,c<sub>n</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),n):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || n), where n is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>n</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>n</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0, the resulting key is invalid.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,n) is identical to the evaluation of CKD'(X,n), with X the extended public key corresponding to x. Symbolically, CKD(x,n)*G = CKD'(x*G,n). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,n) for several values of n, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,n<sub>1</sub>),n<sub>2</sub>),n<sub>3</sub>) as m/n<sub>1</sub>/n<sub>2</sub>/n<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number n in x<sub>n</sub> = x<sub>par</sub>/n, with x<sub>n</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>n</sub>,c<sub>n</sub>) and the integer n, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i,(p<sub>i</sub>,c<sub>i</sub>)), with distinct i's, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each i in [1..N] CKD((p<sub>par</sub>,c<sub>par</sub>),i)=(p<sub>i</sub>,c<sub>i</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
==Test Vectors==<br />
<br />
Come back soon!<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipahttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=36139BIP 00322013-03-15T14:29:57Z<p>Sipa: </p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Draft<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
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.<br />
<br />
The specification consists of two parts. In a 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.<br />
<br />
==Motivation==<br />
<br />
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. <br />
<br />
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 a 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).<br />
<br />
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.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
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 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve, serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
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.<br />
<br />
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 the normal public key and c the chain code.<br />
<br />
===Child key derivation function===<br />
<br />
We define the child key derivation function CKD((k<sub>par</sub>,c<sub>par</sub>),n), which takes a parent extended secret key (k<sub>par</sub>,c<sub>par</sub>) and a 32-bit integer n, to produce a child extended secret key (k<sub>n</sub>,c<sub>n</sub>).<br />
<br />
To define (k<sub>n</sub>,c<sub>n</sub>) = CKD((k<sub>par</sub>,c<sub>par</sub>),n):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=k<sub>par</sub>*G || n), where k<sub>par</sub>*G is the public key corresponding to k<sub>par</sub>, || is concatenation, and n is encoded as a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>n</sub> is equal to I<sub>L</sub>*k<sub>par</sub> (mod n).<br />
* c<sub>n</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0, the resulting key is invalid.<br />
<br />
We also define a version that operates on extended public keys instead of private ones: (K<sub>n</sub>,c<sub>n</sub>) = CKD'((K<sub>par</sub>,c<sub>par</sub>),n):<br />
* call I = HMAC-SHA512(Key=c<sub>par</sub>, Data=K<sub>par</sub> || n), where n is encoded a 32 bits unsigned integer, most significant byte first.<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>n</sub> is equal to I<sub>L</sub>*K<sub>par</sub>.<br />
* c<sub>n</sub> is equal to I<sub>R</sub>.<br />
In case I<sub>L</sub> is 0, the resulting key is invalid.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(x,n) is identical to the evaluation of CKD'(X,n), with X the extended public key corresponding to x. Symbolically, CKD(x,n)*G = CKD'(x*G,n). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,n) for several values of n, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,n<sub>1</sub>),n<sub>2</sub>),n<sub>3</sub>) as m/n<sub>1</sub>/n<sub>2</sub>/n<sub>3</sub> now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. 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 public keys.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, 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).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number n in x<sub>n</sub> = x<sub>par</sub>/n, with x<sub>n</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
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.<br />
<br />
Note that the fingerprint of the parent only serves as a checksum here, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
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.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, 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.<br />
<br />
* Generate a seed S of a chosen length (at least, but not limited to, 128 bits) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> (mod n) as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. <br />
<br />
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.<br />
<br />
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.<br />
<br />
* m/i/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
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.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i====<br />
<br />
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.<br />
<br />
====Recurrent business-to-business transactions: M/i/0====<br />
<br />
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/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.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be 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 (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
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.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* 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 2<sup>128</sup> group operations).<br />
, the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>n</sub>,c<sub>n</sub>) and the integer n, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
<br />
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.<br />
<br />
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 the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys.<br />
<br />
We rely on resistance against (partial) preimages in HMAC-SHA512 to prevent I<sub>L</sub> in key derivation and master key generation from being zero.<br />
<br />
<br />
==Test Vectors==<br />
<br />
Come back soon!<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Sipa