User:Casascius/Passphrased private key proposal

This proposal, originally proposed by Casascius, is to standardize a means of creating Bitcoin private keys that are cryptographically encumbered by a password unknown to the party generating the private keys. This would allow, for example, a website to create paper wallets, or for a party to create physical Bitcoins, where there is no risk of the website or the manufacturer to steal the funds because they won't have all of the key material needed to spend the coins.

Instead of basing the Bitcoin address on G * N (where N is the private key), it would be based on (G * N1)(G * N2), where N1 is computed as the SHA256 of the passphrase.

Overview - Paper Wallets

• A person who wants a paper wallet would choose a secure passphrase.
• They would input that passphrase into a smartphone app, or via SMS to a web service, that "encrypted"* that passphrase into an intermediate string. (Using a mobile phone is suggested, so the computer used in later steps never has access to the passphrase).
• The "encrypted" passphrase would be pasted into the paper wallet generator. It would be computationally infeasible for the original passphrase
• The paper wallet generator would generate Bitcoin addresses and private keys. But the private keys would require the passphrase in order to be useful.

*By "encrypted", an elliptic curve computation would be performed: G * SHA256(passphrase). This would be serialized using Base58Check.

Overview - Physical Bitcoins

A physical Bitcoin bar denominated as "1000 BTC" would be valuable enough that two-factor security to minimize the potential for manufacturer fraud would be a desirable feature.

Two trusted independent parties could agree to make physical Bitcoins with two-factor security. The result would be a more trustworthy physical Bitcoin, as compromise would require collusion between both parties to commit fraud, rather than a single party unilaterally deciding to do so.

• One party could partially manufacture a physical Bitcoin piece with a hologram sticker. That party would convey the completed piece to the second party, along with the public key (G*N1) associated with the concealed code.
• The second party would generate a random passphrase, and compute a public key from it (G*N2, where N2 is SHA256(passphrase)).
• The second party could print, on the exterior of the physical Bitcoin, the Bitcoin address derived from both public keys, as well as the cleartext passphrase. This passphrase would not be known to the first party. The second party may choose to conceal the passphrase, or may leave it in plain sight.
• A person wishing to redeem the piece would have to peel the hologram and enter both the code from the hologram, as well as the passphrase on the exterior of the piece.
• The holder is protected from fraud, because neither of the two parties involved in manufacturing the final piece should possess the secret produced by the other party.

Redemption

Redeeming funds off these special private keys would be exactly the same as redemption on normal private keys now, except that the website or application doing the redemption would ask for the passphrase.

Ideally, the private key would contain a flag that tells the redeeming website/application that it needs to ask for a passphrase.

A specially flagged private key

Right now, private keys currently use Base58Check encoding to encapsulate a 0x80 version byte, along with a 32-byte payload.

I propose that the private key format be expanded so that it can include a "passphrase required" flag. This way, websites accepting the private key will know to show the second prompt for the passphrase.

• Incrementing the version byte to 0x81 will result in private keys that still start with the digit '5'.
• Changing the version byte to some other number will result in private keys with a different prefix, which could serve as a human-visible clue that it's a private key in need of a passphrase.
• Another possible way to indicate this flag, is to compute the checksum, but to flip a single bit with XOR (e.g. xor 0x80000000), so that environments that do not support the passphrase will reject the private key. However, this flag method would be invisible to human users.