User:Casascius/Base58Check-encoded objects proposal
|
This page describes a BIP (Bitcoin Improvement Proposal). |
BIP: Draft Title: Basic security features and standardization for Bitcoin private keys Author: Mike Caldwell <casascius@mc2cs.com> Status: Draft Type: Standards Track Created: 2012-08-02
Abstract
With the increasing popularity of the use of paper wallets as offline Bitcoin storage, there is a growing demand for ways to make that offline storage more secure, for various reasons of the user's choice. Currently, there exists no straightforward way to encrypt a paper Bitcoin wallet.
There is also growing demand for paper wallets that can be split and saved in redundant geographical locations or with different trusted parties. This proposal introduces a standard based on elliptic curve multiplication where Base58Check-encoded strings and/or QR codes can be used to represent parts of a multi-part key. This proposal also introduces a simple standard format for denoting a RAID-like recovery record, so that a multi-part key can be distributed and redeemed in a fashion that tolerates the loss of any one part of the key.
This proposal also seeks to define unique prefixes on Base58Check-encoded strings so that they convey useful visual information to a user, and requests that other developers maintain awareness of the string prefixes and maximize their usefulness to the user.
History
Overview
Proposal for redefinition of the "version byte"
Currently, all objects in Bitcoin when encoded in Base58Check have a "version byte". For example, a Bitcoin address has a byte of 0. A private key has a byte of 0x80. Derivative "altcoins" follow the scheme as well, and therefore their addresses and other objects are easily identified programmatically.
As a result of this practice, all Base58encoded objects tend to have similar prefixes that have come to be used to identify the object by users. A Bitcoin address always starts with a '1', a private key always starts with a '5'. Testnet coins and altcoin addresses can similarly be identified visually by their prefix.
I propose that the "numberspace" in this version byte as used by implementers yield its importance to the "prefixspace" as seen by users. It is much more important that users be able to grasp Bitcoin concepts than it is for us to assign "version" bytes using some sort of sequential orthodoxy.
I propose that this byte be redefined as an "object identifier prefix". Object types should be recognized by two attributes: this byte, as well as the payload length. Because the payload cannot be arbitrarily shortened or lengthened accidentally by users (the checksum will catch omissions or insertions), the payload length is a safe attribute for reliable recognition of objects.
Proposal to standardize the Sipa-format key
- User story: As a Bitcoin user who uses paper wallets or who imports/exports private keys, I don't want to have to worry about different applications that use different formats to represent private keys. I don't want to have to learn about multiple proprietary private key formats just to know which format I should use. I would like the private key format to be just as simple and universal as the Bitcoin address format.
Indicates an uncompressed private key. Widely accepted as "wallet import format", "sipa format".
No changes are proposed to this specification. Rather, it is proposed that this format be considered the standard way of representing a regular uncompressed Bitcoin private key any time there is a need to present one to the user. Specifically, this contemplates discouraging and/or deprecating export and display of any of the following formats (but they should all be recognized as valid input)
- Base64 (except when dealing with the private key material as raw binary data)
- Hexadecimal (except when dealing with the private key material as raw binary data)
- The "internal base58 format" used by Blockchain.info (which is 32 raw bytes encoded in base58 with no prefix or checksum)
- Any other non-standard or proprietary formats that do not provide any features beyond what is present in the Sipa-format key.
Minikeys should similarly be accepted as import whenever possible, but not displayed. Applications should always display and export the standard format key, except where displaying or exporting a minikey is explicitly desired as a feature.
Specification
- Version byte (object identifier prefix): 0x80
- Payload bytes (beyond prefix): 32
- How the user sees it: Always 51 characters beginning with '5' (specifically: 5H, 5J, or 5K)
- Range in base58 encoding:
- Lowest possible value: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAbuatmU
- Highest possible value: 5Km2kuu7vtFDPpxywn4u3NLu8iSdrqhxWT8tUKjeEXs2f9yxoWz
Proposal to standardize the private key format indicating compression
Present specification
- Version byte: 0x80
- Payload bytes (beyond prefix): 33 (32 for the key, plus the constant 0x01)
- How the user sees it: Always 52 characters, beginning with K or L
- Lowest possible value: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73Nd2Mcv1
- Highest possible value: L5oLkpV3aqBjhki6LmvChTCq73v9gyymzzMpBbhDLjDpKCuAXpsi
Rationale
- User story: As a Bitcoin user who uses paper wallets or who imports/exports private keys, I don't want to have to learn the difference between private keys that start with '5' and ones that start with something else, if there are no differences that pertain to me as a user or the way I use the key or what I can do with it.
Whether we like it or not, many users (particularly power users) will see base58 encoded objects, such as on paper wallets.
Since the distinction of compressed/uncompressed is of little practical difference to the user, and the question "why is this one 5 and that one K/L" an unnecessary burden that disregards simplicity, I propose a different encoding that both preserves the '5' and keeps a visual distinction there (in the second character) for those who can make use of it.
Backward compatibility with the current specification can be easily maintained under this proposal by always accepting the existing compressed private key format as input, but applications should only output strings in the proposed format.
Proposed specification
- Version byte (object identifier prefix): 0x82
- Payload bytes (beyond prefix): 32
- How the user sees it: Always 51 characters beginning with '5' (specifically: 5M, 5N, or 5P)
- Range in base58 encoding:
- Lowest possible value: 5Mhmw9M9nJvSXeYgrMgtzgwg3q4MWYYqJ6CziURYEBsR9t6VP82
- Highest possible value: 5PeX7NoBdjbffU8PkwJtx1YSxwg5AFPi5jH6xd7SDqsoeMcxpoG
- Note: By using 0x82 instead of 0x81 we ensure the second character always visually divulges the compressed status. If we used 0x81, then the prefix '5K' could belong to either, and would be ambiguous.
Proposed encoding for a passphrase-protected private key
- User story: As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factor: something I have plus something I know.
This proposal contemplates existence of a private key that requires a decryption passphrase before it can be used.
I propose having the Base58Check-encoded string start with a '6'. The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could include keys participating in multisig transactions. The second character ought to give a hint as to what is needed, and for a simple SHA256-based password, I propose the lowercase letter p.
I propose the string having an optional 14 bits of password typo resistance. That is, a 14-bit checksum of the password may be added so that the vast majority of password typos can be detected and reported to the user, rather than inadvertently accepted as correct, which will simply yield the wrong private key and frustrate the user. This checksum is optional, and a bit flag is defined for the purpose of disabling it.
The choice of a low-bitcount checksum is intended to reduce its usefulness to someone attempting to crack the password.
To decrypt the key is to simply XOR it with the SHA256 hash of the valid passphrase.
Proposed specification
- Object identifier prefix: 0x0205
- Payload bytes (beyond prefix): 34
- 2 bytes: compressed flag and passphrase typo resistance (1 bit: passphrase enable/disable, 14 bits: passphrase checksum, 1 bit: compressed flag)
- 32 bytes: Private key xor passphrase
- How the user sees it: 54 characters always starting with '6p'
- Range in base58check encoding:
- Minimum value: 6pZbbCzeNu7567y9swhRL8zC4yXioQc6oaUmwPMof6zvChFcMrTmMp
- Maximum value: 6ptXqrvUjVYbnPvXPrC2S4tRVvAFdXBKDUC7K96C9ukAKogUFQynhy
Passphrase typo resistance bytes: The most significant bit is the enable(0)/disable(1) bit, the next 14 bits hold the passphrase checksum. The checksum is defined as SHA256(correct passphrase + "?")[0...1] & 0x7FFE. The least significant bit is 0 for an uncompressed key, and 1 for a compressed key.
If the passphrase is disabled, the passphrase checksum bits MUST be 0 (so the two bytes will be 0x8000 or 0x8001).
The valid range of the passphrase typo resistance bytes are 0x0000 thru 0x8001. Values above 0x8001 are excluded from the definition of keys valid for this proposal. Note that if the value were to be above 0xabb9, the prefix "6p" is lost and becomes "6q".
Proposed specification for a multi-part key using EC multiplication
- User story: As a Bitcoin user who uses paper wallets or who imports/exports private keys, I would like the ability to secure my private key by separating it into parts and keeping the parts in more than one geographic location, or entrusted to more than one person.
I propose a private key format that can self-specify that it is a single part of a key, and that other parts of the key are needed to reconstitute the complete key. Under this proposal, each part is a factor, and the key is reconstituted using elliptic curve multiplication.
The proposal contemplates a field that specifies how many parts (up to 15) are needed to complete the key.
The proposal also contemplates a 11-bit field that is used for matching purposes - so the individual parts can be identified as likely belonging to each other, and that they form the correct address when put together. This allows a user interface to know to ask for other parts, to know how many parts to ask for, to reject parts that don't belong, and to confirm that all parts are likely present when provided.
Proposed specification
- Object identifier prefix: 0x0211
- Count of payload bytes (beyond the prefix): 34
- 2 bytes: bit-mapped field
- 4 most significant bits: number of total parts required, minus two. A value of 0-13 here allows for 2-15 parts. Values above 13 break the '6x' prefix and are disallowed.
- 11 bits: checksum
- 1 least significant bit: compressed private key flag (0=uncompressed 1=compressed)
- 32 bytes: factor representing partial private key
- How the user sees it: 54 characters always starting with the prefix '6x'
The checksum for a Bitcoin address is defined as SHA256(BitcoinAddress[0...1]) & 0x0FFE, where BitcoinAddress is a base58check-encoded string representation of the Bitcoin address that should result when all parts are reconstituted. Taking the SHA256 of the Bitcoin address is chosen as preferable over taking something directly from the hash160 of the bitcoin address, to reduce the likelihood that the common practice of generating "vanity addresses" does not result in an increased likelihood of collisions on the checksum field.
Proposed specification for a RAID-like recovery record for a multi-part key
- User story: As a Bitcoin user who uses paper wallets or who imports/exports private keys in parts, I would like the ability to secure my multi-part keys against the potential loss or destruction of one of the parts.
I propose a key format that isn't actually a key: it is a simple RAID-5-like parity-based recovery record for a multi-part private key, that can be used in place of any one missing part.
This format looks similar to a single part of a multi-part key, including the bitmapped fields denoting the number of parts and the checksum of the Bitcoin address, except for a different object identifier prefix, and the payload is an XOR sum of all of the parts.
For the purpose of counting "parts" for the "total parts required" field, the recovery record is optional and is not considered a part. If a 3-part key is created along with a recovery record (so there are 4 base58check-encoded strings, recovery possible with any three), then all of the records (including the recovery record) shall indicate the key has three parts. Including this in the recovery record allows a user interface to be aware of what it expects if the recovery record is provided first: for example, a user interface, upon being presented a recovery record for a 3-part key, will know to ask for two more parts. It also facilitates rejection of parts that don't belong to the key being recovered.
Capability for only one recovery record per multi-part set is proposed here, for the sake of simplicity, and the fact that XOR and SHA256 are widely understood and available on all relevant platforms. More elaborate schemes (such as two recovery records using syndromes similar to use in RAID-6) are certainly possible, but avoided in this proposal to maximize the developer audience likely to be able to implement the proposal completely.
Proposed specification
- Object identifier prefix: 0x0208
- Count of payload bytes (beyond the prefix): 34
- 2 bytes: bit-mapped field, which must be identical to the corresponding 2-byte field in the partial keys to which the recovery record belongs (range of valid values: 0...0x8001)
- 32 bytes: result of XORing the 32 bytes of all of the partial keys
- How the user sees it: 54 characters always starting with the prefix '6r'