From e96f78c6571d09d4654c80b31652e9b2e217aca5 Mon Sep 17 00:00:00 2001 From: wigy Date: Thu, 30 May 2019 21:40:34 +0200 Subject: [PATCH] Created + relation to BIP32 --- Comments:BIP-0178.md | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 Comments:BIP-0178.md diff --git a/Comments:BIP-0178.md b/Comments:BIP-0178.md new file mode 100644 index 0000000..5ce7c94 --- /dev/null +++ b/Comments:BIP-0178.md @@ -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. \ No newline at end of file