bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-26 12:10:14 +00:00
Code Issues Releases Wiki Activity

Created + relation to BIP32

wigy 2019-05-30 21:40:34 +02:00
parent ce9f1d5225
commit e96f78c657
1 changed files with 5 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
Comments:BIP-0178.md Normal file

@ -0,0 +1,5 @@
## Relation to BIP32 version bytes
Most wallets support BIP32 to allow the user to backup their secrets once and generate multiple keys and receiving addresses from that secret. BIP32 defines a [serialization format](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Serialization_format) of the extended private and public keys and uses a 4-byte length "version bytes" (xpub and xprv on the BTC mainnet). There are competing extensions to that serialization format. [SLIP-0132](https://github.com/satoshilabs/slips/blob/master/slip-0132.md) registers extra version bytes that were introduced by the Trezor and the [Electrum](http://docs.electrum.org/en/latest/xpub_version_bytes.html) wallets (ypub, zpub...). Another extension, [SLIP-0032](https://github.com/satoshilabs/slips/blob/master/slip-0032.md) serializes the full derivation path and therefore lets the wallet that imports the extended key detect the used script templates by the purpose part ([BIP-0043](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki)) of the key derivation. This is made possible, because [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki#public-key-derivation) uses `m/84'` as a subtree for P2WPKH scripts and [BIP-0049](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki#public-key-derivation) uses `m/49'` as a subtree for P2WPKH-nested-in-P2SH scripts.
This BIP-0178 seems to completely ignore that keys are nowadays in a hierarchy and the derivation path determines the script templates. If we assume that each key is independently created, backed up and later restored onto a fresh device, I completely see the purpose of this suggestion. But then I would even extend it with a way to backup a custom script template at the end of the exported WIF together with the private key.