User:Casascius/Base58Check-encoded objects proposal

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'.

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.

Regular private key

Indicates an uncompressed private key. Widely accepted as "wallet import format", "sipa format".

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

Compressed private key

Present specification

• Version byte: 0x00
• 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

Proposal

Rationale: 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 (0x80 + 32bytes + 0x01) 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

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.

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

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 prefix and are disallowed.
  • 11 bits: checksum
  • 1 least significant bit: compressed private key flag
• 32 bytes: factor representing partial private key
• How the user sees it: 54 characters always starting with the prefix '6x'

Observation

A Base58Check string starts with '5' when it has a version byte of 0x80 and a payload of 43 bytes. (range: 5h thru 5j - lowercase mimic!)