Bitcoin Wiki - User contributions [en]

User talk:Casascius/Radial BitCoin

2015-04-05T15:14:54Z

Casascius: Shout-out to Luke-Jr

'''Radial Bitcoin''' is a page once created by Casascius as a satirical disparagement of [[tonal bitcoin]]. It is now, temporarily at the least, an apology piece toward the person and the idea the satire was directed toward. Not for any specific reason or in reaction to anything - rather, this morning I got up and decided that today I would post this.

I am Mike Caldwell. Casascius. A part of me has always been bothered by my having created a page here like I did and thrown out unwarranted negativity toward one of the biggest contributors to the Bitcoin project. Sure, I think I still maintain that the idea of putting something in the Bitcoin software that would be confusing to everybody other than a select few isn't in the best interest in the project, but I am pretty sure that to put the level of effort I did into making a big deal out of it was pretty uncool. It was also unnecessary.

Bitcoin, at least now and even then, is not a one-man project, and the dynamics of collaboration were more than enough to ensure only the best ideas went into the project. In retrospect, the notion that I could or should come along and stifle someone's creative spirit just for presenting an idea that from my perspective wasn't likely to fly, seems pretty shameful. I am at peace with it today and trust by now I'm forgiven, esp giving that I'm coming to a wiki to own it, in writing no less.

Luke-Jr, you are a hero. You are a man with your hands touching and working on the beating heart of an upcoming major chapter in the history of the world and you are absolutely qualified to be doing that. I owe you no less than my utmost respect and I only wish that I could claim anywhere near the same level of involvement and interaction with the core application as you have. For me to have raised a stink about tonal bitcoin has said far more about me than it ever said about you. I am sorry, and this apology is long overdue.

As I write this, I think I now recall what got me thinking about you in the first place. It was maybe a week ago I came across Electronic Frontier Foundation's [https://www.eff.org/deeplinks/2015/03/eff-files-second-round-comments-new-yorks-bitlicense-proposal blog post] describing their comments to New York DFS in regards to the BitLicense proposal. I read just about all of it.

I read Ms. Hofmann refer to those back-in-the-day religious comments you put into the block chain with your mining pool. Those comments, which I of course saw in the block chain when you put them there, led me to roll my eyes in disdain at the time while conceding it was your right and privilege to put them there consistent with the established principles of how the block chain works. I'm inclined to be skeptical of religion myself. As far as I know, for me to have harbored contempt about those comments is my private behavior I have never taken credit for that I can recall, I likewise lol toward myself as to how I could have been short-sighted about them.

It was quite humbling for me to read those and point those out to NYDFS as prescient examples of protected expressions in the block chain. I found her argument to be captivating. I don't think I will go as far myself as to call your placement of them there any form of divine coincidence, but the look on my face as I write this, I think, says I don't think I'd stop you or anyone else from doing so.

At the time I was slamming tonal bitcoins to your face, I also offered to produce a tonal wall clock with my laser equipment. While I'm sure that looks a whole lot like being charitable with the right hand while throwing mud with the left, I think the driver behind that was my awareness that I was being a jerk (which offering to make a clock doesn't undo), and after some reflection I think I owe you a Casascius wall clock in the numbering system of your choice if you decide that to receive one is right for you. Just let me know what I should keep in mind as I design it, which could reasonably take me some sort of while.

I know this kind of personal correspondence, even as I make it open, probably doesn't really belong in the Bitcoin Wiki. But, admins, I hope it will survive here long enough for Luke to see it, as well as anyone who might share it. At the same time, I wouldn't be opposed to the past revision history of the spoof article being visible - I'm owning it after all. I will let Luke and others weigh in, and actually, beyond what I just said here, it probably shouldn't be my decision anyway.

Luke, keep on keeping on.

Mike Caldwell [[User:Casascius|Casascius]] ([[User talk:Casascius|talk]]) 15:14, 5 April 2015 (UTC)

Auditable paper wallet

2014-03-20T04:00:50Z

Casascius:

An '''auditable paper wallet''' is a paper wallet that includes an '''Audit Private Key''' for the purpose of guaranteeing to the user that the paper wallet includes sufficient entropy, in a manner that can be easily verified by the user.

The purpose of the auditing is to alleviate the concern that a program, Live CD, or paper wallet printer appliance offered to help people produce safe paper wallets might contain a flawed or predictable random number generator that could result in theft.

An auditable paper wallet provides a means for the user to introduce their own entropy through the keyboard, and then to confirm that the private keys on the paper wallets actually incorporate the user's entropy.

==How it works==

An auditable paper wallet generator first asks the user to enter a long string of their choice, between 20 and 40 characters. A suggested string is a simple mash of the keyboard, e.g. "as;dlfkjguwhaief;lkjsdvmnasdfkjh". The user should be reminded that the chosen string should be meant to be forgotten, should not be memorable, and the user should required to enter a string on the keyboard; no default or auto-generated string should ever be offered to the user. Note that keyboard mashes typically have low entropy per character (i.e. they're more likely to favor home-row lowercase letters), so encouraging longer entry is better.

Afterward, the paper wallet generator should guarantee that it generates private keys consisting solely of SHA256(USER_ENTROPY + PROGRAM_ENTROPY), where USER_ENTROPY is the string entered by the user, PROGRAM_ENTROPY is some sort of randomly generated string generated by the software, and + means concatenation. The string USER_ENTROPY + PROGRAM_ENTROPY should be offered to the user as the "Audit Private Key".

The program should offer the ability to display the Audit Private Key, to copy it to the system clipboard, and to show a QR code on screen, but should discourage (while not necessarily prohibiting) the Audit Private Key from being printed on the paper wallet itself. If the program offers the ability to print the Audit Private Key on the printed copy, it should be offered as a QR code, to enable the possibility of rapid auditing with a barcode scanner.

==What is an audit==
An audit is simply the process of verifying that the hash of the Audit Private Key equals the private key on the paper wallet, and that the Bitcoin address corresponds to that private key.

An audit allows the user to visually guarantee that the entropy he provided himself has been incorporated into the private key of the paper wallet. The premise is that the maker of a Live CD or appliance that generates paper wallets cannot predict USER_ENTROPY, and so as long as the user is diligent in supplying an unpredictable string that has sufficient entropy, a successful audit guarantees the unpredictability of the private key.

==Example==

*User enters string: drgow3u4hgy984hreuahiouioehirfnadsfjsjkd
*Program provides a random GUID: 1ee147fb-9416-4081-9dcb-60f5836d8822
*Audit Private Key: 1ee147fb-9416-4081-9dcb-60f5836d8822drgow3u4hgy984hreuahiouioehirfnadsfjsjkd
*Bitcoin Private key (which is based on SHA256 of Audit Private Key): 5JpkQkz2Gg9NFSTVKLcBJdG8R2WdbB8hXFwPZ3G1Apbp29M1ap3
*Bitcoin address: 1FRDyKZkCUVPjTXQkNbPohgyWiAgEM5mDe

==Caveats==

Printing the Audit Private Key should be discouraged on paper wallets that are likely to be given to others who have no need to audit the paper wallet, particularly if the same USER_ENTROPY is used to batch-print multiple paper wallets. The disclosure of USER_ENTROPY on one paper wallet could weaken the security of other paper wallets with identical USER_ENTROPY.

Users who might print the Audit Private Key should be made fully aware that the Audit Private Key can be used to regenerate the Private Key and that its disclosure could result in the theft of funds. Printing the Audit Private Key should be discouraged by default.

Users should be made aware that steps undertaken to audit the paper wallet might result in the disclosure of the private key. For example, if a user uses a website or a compromised computer to audit a paper wallet, the auditing process may result in the wallet being compromised and the funds stolen. A good recommendation would be to only audit a random sample from a batch, and to not use the audited paper wallets for Bitcoin storage.

An audit only protects a user against predictability. It does not protect a user from disclosure risks, such as a Live CD or program that finds an internet connection and leaks key material, or one that can write to a file system or other storage to trigger a future leak if that storage later comes into contact with internet access. It also does not protect a user from a compromised printer, or one that stores material from print jobs.

Auditable paper wallet

2014-03-20T03:57:14Z

Casascius: /* Example */

An '''auditable paper wallet''' is a paper wallet that includes an '''Audit Private Key''' for the purpose of guaranteeing to the user that the paper wallet includes sufficient entropy, in a manner that can be easily verified by the user.

The purpose of the auditing is to alleviate the concern that a program, Live CD, or paper wallet printer appliance offered to help people produce safe paper wallets might contain a flawed or predictable random number generator that could result in theft.

An auditable paper wallet provides a means for the user to introduce their own entropy through the keyboard, and then to confirm that the paper wallets actually include the user's entropy.

==How it works==

An auditable paper wallet generator first asks the user to enter a long string of their choice, between 20 and 40 characters. A suggested string is a simple mash of the keyboard, e.g. "as;dlfkjguwhaief;lkjsdvmnasdfkjh". The user should be reminded that the chosen string should be meant to be forgotten, should not be memorable, and the user should required to enter a string on the keyboard; no default or auto-generated string should ever be offered to the user.

Afterward, the paper wallet generator should guarantee that it generates private keys consisting solely of SHA256(USER_ENTROPY + PROGRAM_ENTROPY), where USER_ENTROPY is the string entered by the user, PROGRAM_ENTROPY is some sort of randomly generated string generated by the software, and + means concatenation. The string USER_ENTROPY + PROGRAM_ENTROPY should be offered to the user as the "Audit Private Key".

The program should offer the ability to display the Audit Private Key, to copy it to the system clipboard, and to show a QR code on screen, but should discourage (while not necessarily prohibiting) the Audit Private Key from being printed on the paper wallet itself. If the program offers the ability to print the Audit Private Key on the printed copy, it should be offered as a QR code, to enable the possibility of rapid auditing with a barcode scanner.

==What is an audit==
An audit is simply the process of verifying that the hash of the Audit Private Key equals the private key on the paper wallet, and that the Bitcoin address corresponds to that private key.

An audit allows the user to visually guarantee that the entropy he provided himself has been incorporated into the private key of the paper wallet. The premise is that the maker of a Live CD or appliance that generates paper wallets cannot predict USER_ENTROPY, and so as long as the user is diligent in supplying an unpredictable string that has sufficient entropy, a successful audit guarantees the unpredictability of the private key.

==Example==

*User enters string: drgow3u4hgy984hreuahiouioehirfnadsfjsjkd
*Program provides a random GUID: 1ee147fb-9416-4081-9dcb-60f5836d8822
*Audit Private Key: 1ee147fb-9416-4081-9dcb-60f5836d8822drgow3u4hgy984hreuahiouioehirfnadsfjsjkd
*Bitcoin Private key (which is based on SHA256 of Audit Private Key): 5JpkQkz2Gg9NFSTVKLcBJdG8R2WdbB8hXFwPZ3G1Apbp29M1ap3
*Bitcoin address: 1FRDyKZkCUVPjTXQkNbPohgyWiAgEM5mDe

==Caveats==

Printing the Audit Private Key should be discouraged on paper wallets that are likely to be given to others who have no need to audit the paper wallet, particularly if the same USER_ENTROPY is used to batch-print multiple paper wallets. The disclosure of USER_ENTROPY on one paper wallet could weaken the security of other paper wallets with identical USER_ENTROPY.

Users who might print the Audit Private Key should be made fully aware that the Audit Private Key can be used to regenerate the Private Key and that its disclosure could result in the theft of funds. Printing the Audit Private Key should be discouraged by default.

Users should be made aware that steps undertaken to audit the paper wallet might result in the disclosure of the private key. For example, if a user uses a website or a compromised computer to audit a paper wallet, the auditing process may result in the wallet being compromised and the funds stolen. A good recommendation would be to only audit a random sample from a batch, and to not use the audited paper wallets for Bitcoin storage.

An audit only protects a user against predictability. It does not protect a user from disclosure risks, such as a Live CD or program that finds an internet connection and leaks key material, or one that can write to a file system or other storage to trigger a future leak if that storage later comes into contact with internet access. It also does not protect a user from a compromised printer, or one that stores material from print jobs.

Auditable paper wallet

2014-03-20T03:56:36Z

Casascius: /* Example */

An '''auditable paper wallet''' is a paper wallet that includes an '''Audit Private Key''' for the purpose of guaranteeing to the user that the paper wallet includes sufficient entropy, in a manner that can be easily verified by the user.

The purpose of the auditing is to alleviate the concern that a program, Live CD, or paper wallet printer appliance offered to help people produce safe paper wallets might contain a flawed or predictable random number generator that could result in theft.

An auditable paper wallet provides a means for the user to introduce their own entropy through the keyboard, and then to confirm that the paper wallets actually include the user's entropy.

==How it works==

An auditable paper wallet generator first asks the user to enter a long string of their choice, between 20 and 40 characters. A suggested string is a simple mash of the keyboard, e.g. "as;dlfkjguwhaief;lkjsdvmnasdfkjh". The user should be reminded that the chosen string should be meant to be forgotten, should not be memorable, and the user should required to enter a string on the keyboard; no default or auto-generated string should ever be offered to the user.

Afterward, the paper wallet generator should guarantee that it generates private keys consisting solely of SHA256(USER_ENTROPY + PROGRAM_ENTROPY), where USER_ENTROPY is the string entered by the user, PROGRAM_ENTROPY is some sort of randomly generated string generated by the software, and + means concatenation. The string USER_ENTROPY + PROGRAM_ENTROPY should be offered to the user as the "Audit Private Key".

The program should offer the ability to display the Audit Private Key, to copy it to the system clipboard, and to show a QR code on screen, but should discourage (while not necessarily prohibiting) the Audit Private Key from being printed on the paper wallet itself. If the program offers the ability to print the Audit Private Key on the printed copy, it should be offered as a QR code, to enable the possibility of rapid auditing with a barcode scanner.

==What is an audit==
An audit is simply the process of verifying that the hash of the Audit Private Key equals the private key on the paper wallet, and that the Bitcoin address corresponds to that private key.

An audit allows the user to visually guarantee that the entropy he provided himself has been incorporated into the private key of the paper wallet. The premise is that the maker of a Live CD or appliance that generates paper wallets cannot predict USER_ENTROPY, and so as long as the user is diligent in supplying an unpredictable string that has sufficient entropy, a successful audit guarantees the unpredictability of the private key.

==Example==

*User enters string: drgow3u4hgy984hreuahiouioehirfnadsfjsjkd
*Program provides a random GUID: 1ee147fb-9416-4081-9dcb-60f5836d8822
*Audit private key: 1ee147fb-9416-4081-9dcb-60f5836d8822drgow3u4hgy984hreuahiouioehirfnadsfjsjkd
*Private key (which is SHA256 of Audit private key): 5JpkQkz2Gg9NFSTVKLcBJdG8R2WdbB8hXFwPZ3G1Apbp29M1ap3
*Bitcoin address: 1FRDyKZkCUVPjTXQkNbPohgyWiAgEM5mDe

==Caveats==

Printing the Audit Private Key should be discouraged on paper wallets that are likely to be given to others who have no need to audit the paper wallet, particularly if the same USER_ENTROPY is used to batch-print multiple paper wallets. The disclosure of USER_ENTROPY on one paper wallet could weaken the security of other paper wallets with identical USER_ENTROPY.

Users who might print the Audit Private Key should be made fully aware that the Audit Private Key can be used to regenerate the Private Key and that its disclosure could result in the theft of funds. Printing the Audit Private Key should be discouraged by default.

Users should be made aware that steps undertaken to audit the paper wallet might result in the disclosure of the private key. For example, if a user uses a website or a compromised computer to audit a paper wallet, the auditing process may result in the wallet being compromised and the funds stolen. A good recommendation would be to only audit a random sample from a batch, and to not use the audited paper wallets for Bitcoin storage.

An audit only protects a user against predictability. It does not protect a user from disclosure risks, such as a Live CD or program that finds an internet connection and leaks key material, or one that can write to a file system or other storage to trigger a future leak if that storage later comes into contact with internet access. It also does not protect a user from a compromised printer, or one that stores material from print jobs.

Auditable paper wallet

2014-03-20T03:56:19Z

Casascius: Created page with "An '''auditable paper wallet''' is a paper wallet that includes an '''Audit Private Key''' for the purpose of guaranteeing to the user that the paper wallet includes sufficien..."

An '''auditable paper wallet''' is a paper wallet that includes an '''Audit Private Key''' for the purpose of guaranteeing to the user that the paper wallet includes sufficient entropy, in a manner that can be easily verified by the user.

The purpose of the auditing is to alleviate the concern that a program, Live CD, or paper wallet printer appliance offered to help people produce safe paper wallets might contain a flawed or predictable random number generator that could result in theft.

An auditable paper wallet provides a means for the user to introduce their own entropy through the keyboard, and then to confirm that the paper wallets actually include the user's entropy.

==How it works==

An auditable paper wallet generator first asks the user to enter a long string of their choice, between 20 and 40 characters. A suggested string is a simple mash of the keyboard, e.g. "as;dlfkjguwhaief;lkjsdvmnasdfkjh". The user should be reminded that the chosen string should be meant to be forgotten, should not be memorable, and the user should required to enter a string on the keyboard; no default or auto-generated string should ever be offered to the user.

Afterward, the paper wallet generator should guarantee that it generates private keys consisting solely of SHA256(USER_ENTROPY + PROGRAM_ENTROPY), where USER_ENTROPY is the string entered by the user, PROGRAM_ENTROPY is some sort of randomly generated string generated by the software, and + means concatenation. The string USER_ENTROPY + PROGRAM_ENTROPY should be offered to the user as the "Audit Private Key".

The program should offer the ability to display the Audit Private Key, to copy it to the system clipboard, and to show a QR code on screen, but should discourage (while not necessarily prohibiting) the Audit Private Key from being printed on the paper wallet itself. If the program offers the ability to print the Audit Private Key on the printed copy, it should be offered as a QR code, to enable the possibility of rapid auditing with a barcode scanner.

==What is an audit==
An audit is simply the process of verifying that the hash of the Audit Private Key equals the private key on the paper wallet, and that the Bitcoin address corresponds to that private key.

An audit allows the user to visually guarantee that the entropy he provided himself has been incorporated into the private key of the paper wallet. The premise is that the maker of a Live CD or appliance that generates paper wallets cannot predict USER_ENTROPY, and so as long as the user is diligent in supplying an unpredictable string that has sufficient entropy, a successful audit guarantees the unpredictability of the private key.

==Example==

User enters string: drgow3u4hgy984hreuahiouioehirfnadsfjsjkd
Program provides a random GUID: 1ee147fb-9416-4081-9dcb-60f5836d8822
Audit private key: 1ee147fb-9416-4081-9dcb-60f5836d8822drgow3u4hgy984hreuahiouioehirfnadsfjsjkd
Private key (which is SHA256 of Audit private key): 5JpkQkz2Gg9NFSTVKLcBJdG8R2WdbB8hXFwPZ3G1Apbp29M1ap3
Bitcoin address: 1FRDyKZkCUVPjTXQkNbPohgyWiAgEM5mDe

==Caveats==

Printing the Audit Private Key should be discouraged on paper wallets that are likely to be given to others who have no need to audit the paper wallet, particularly if the same USER_ENTROPY is used to batch-print multiple paper wallets. The disclosure of USER_ENTROPY on one paper wallet could weaken the security of other paper wallets with identical USER_ENTROPY.

Users who might print the Audit Private Key should be made fully aware that the Audit Private Key can be used to regenerate the Private Key and that its disclosure could result in the theft of funds. Printing the Audit Private Key should be discouraged by default.

Users should be made aware that steps undertaken to audit the paper wallet might result in the disclosure of the private key. For example, if a user uses a website or a compromised computer to audit a paper wallet, the auditing process may result in the wallet being compromised and the funds stolen. A good recommendation would be to only audit a random sample from a batch, and to not use the audited paper wallets for Bitcoin storage.

An audit only protects a user against predictability. It does not protect a user from disclosure risks, such as a Live CD or program that finds an internet connection and leaks key material, or one that can write to a file system or other storage to trigger a future leak if that storage later comes into contact with internet access. It also does not protect a user from a compromised printer, or one that stores material from print jobs.

BIP 0038

2013-11-02T18:15:02Z

Casascius: /* Confirmation code */ fix error/inconsistency with ref implementation

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion)
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and organizations wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.

This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should, but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Concatenate ''ownersalt'' + ''lotsequence'' and call this ''ownerentropy''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4, and ''lotsequence'' is omitted. ''ownerentropy'' becomes an alias for ''ownersalt''.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pointb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pointbprefix''.
# Do AES256Encrypt(pointb[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pointbx1''.
# Do AES256Encrypt(pointb[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pointbx2''.
# Concatenate ''pointbprefix'' + ''pointbx1'' + ''pointbx2'' (total 33 bytes) and call the result ''encryptedpointb''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpointb''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression, no lot/sequence numbers===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

===EC multiply, no compression, lot/sequence numbers===

Test 1:
*Passphrase: MOLON LABE
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
*Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
*Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
*Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
*Unencrypted private key (hex): 44EA95AFBF138356A05EA32110DFD627232D0F2991AD221187BE356F19FA8190
*Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD
*Lot/Sequence: 263183/1

Test 2:
*Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
*Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
*Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
*Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D
*Unencrypted private key (hex): CA2759AA4ADB0F96C414F36ABEB8DB59342985BE9FA50FAAC228C8E7D90E3006
*Confirmation code: cfrm38V8G4qq2ywYEFfWLD5Cc6msj9UwsG2Mj4Z6QdGJAFQpdatZLavkgRd1i4iBMdRngDqDs51
*Lot/Sequence: 806938/1

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-10-25T17:05:22Z

Casascius: clarify numbering of BIP

BIP 38 was assigned to Mike Caldwell by Amir Taaki on November 22, 2012, consistent with the procedure described in [[BIP 0001]] as of the time the request was made. There is possibly a lack of consensus as to whether this BIP number was properly assigned. Because it has been implemented in multiple projects (including BitAddress.org, Bit2factor.org), concurrently assigning it to something else would have the effect of creating confusion as to what BIP 38 actually refers to. A request to the Bitcoin-development mailing list to formally assign BIP 38 to this proposal was made by Mike Caldwell on August 17, 2013. Discussion regarding this topic continues.

(Mike Caldwell had previously filled this page with [https://en.bitcoin.it/w/index.php?title=BIP_0038&oldid=36492 a BIP draft] which had not been proposed on the list or assigned a number and which doesn't appear to be moving forward.)

File:Casascius silver 2013 curl.jpg

2013-09-19T03:17:00Z

Casascius:

File:Casascius Aluminum Coins bag 500.jpg

2013-06-28T05:51:05Z

Casascius:

File:Casascius Silver 2013 1BTC.jpg

2013-06-28T01:07:30Z

Casascius: Casascius Silver 2013 1BTC Coin with Series 3 hologram

Casascius Silver 2013 1BTC Coin with Series 3 hologram

Paper wallet

2013-04-02T04:24:08Z

Casascius: /* Producing safe paper wallets */

A '''paper wallet''' is a way to store Bitcoins that involves printing the Bitcoin addresses and private keys directly on a piece of paper. When done properly, paper wallets are one of the safest ways possible to store Bitcoins.

__TOC__

A Bitcoin [[private key]] can be represented in several formats, but is typically a string of numbers and letters no more than about 51 characters in length. This is easy to print on paper, and if kept secret, can securely hold an unlimited quantity of Bitcoins.

==Producing safe paper wallets==
Several tools exist for producing paper wallets, including [[BitAddress.org]], [[vanitygen]], [[LinuxCoin]], and [[Bitcoin Address Utility]]. Paper wallets must be produced securely in order to be safe, because any leak of the private key constitutes the ability for an attacker to steal any present and future balance of the address. Consider the following:
* Paper wallets should be produced on a computer not connected to the Internet.
* Be aware that malware often allows a remote third party to view your screen and see your keystrokes, and these can compromise the integrity of your paper wallet. Also consider that antivirus software cannot completely rule out the possibility of malware. However, using bootable CD's prevents the vast majority of malware from being able to run. If you can generate a paper wallet with a bootable CD such as [[LinuxCoin]], the likelihood of malware being able to compromise your keys is very low.
* The private keys of paper wallets should never be saved to a computer hard drive. You should also never scan your paper wallet into your computer or type the private keys or save them in e-mail, except at the moment you are redeeming the balance.
* A web-based paper wallet generator should be written so that all of the generation happens on your computer, not the web server. After you load the paper wallet generating website in your web browser, you should disconnect from the internet, and observe that the paper wallet generator continues to function. Afterward, you should close your browser before reconnecting to the internet.
* A paper wallet generator should use an appropriate source of random numbers (entropy). This means that the generated addresses aren't predictable. If the addresses come from a predictable or partially-predictable pattern, someone else who can predict the pattern addresses can steal the balance. Generally, this rules out any "web-based" generator unless you know the technical capabilities of the browser it's running in and audit the code.

===Printer Security===

Some printers will store the output using storage in which the data can be recovered from the printer's memory or from a hard drive (if the printer has one) and stores its print jobs there. Most larger commercial printers have hard drives but whether or not documents are stored on them will vary based on manufacturer and model.

==Redeeming Keys==

There are various methods for copying the private key data from a paper wallet to other wallets.
bitcoind supports an "importprivkey" RPC method for this purpose.
Bitcoin-Qt's debug console can also be used in a similar way (see also [[how to import private keys v7+]]).
[[BlockChain.info]] and [[Armory]] can also import them directly into wallets.
[[MtGox|Mt. Gox]] provides the ability to Add Funds using a private key:
the exchange will then create a "sweep" transaction that spends any amount for that paper wallet address so that the amount is added to your account with them; it will also sweep to your account any bitcoins received to that address in the future as well.

==See Also==

* [[Private key]]

* [[Securing_your_wallet#Paper_Wallets]]

* [[How to import private keys]]

* [http://localbitcoins.blogspot.fi/2012/11/start-your-own-money-press.html Guide to paper wallets]

[[Category:Security]]

[[es:Monedero de papel]]

BIP 0038

2013-03-30T03:46:16Z

Casascius: /* Motivation */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and organizations wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.

This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should, but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Concatenate ''ownersalt'' + ''lotsequence'' and call this ''ownerentropy''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4, and ''lotsequence'' is omitted. ''ownerentropy'' becomes an alias for ''ownersalt''.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pointb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pointbprefix''.
# Do AES256Encrypt(pointb[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pointbx1''.
# Do AES256Encrypt(pointb[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pointbx2''.
# Concatenate ''pointbprefix'' + ''pointbx1'' + ''pointbx2'' (total 33 bytes) and call the result ''encryptedpointb''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownerentropy'' + ''addresshash'' + ''encryptedpointb''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression, no lot/sequence numbers===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

===EC multiply, no compression, lot/sequence numbers===

Test 1:
*Passphrase: MOLON LABE
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
*Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
*Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
*Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
*Unencrypted private key (hex): 44EA95AFBF138356A05EA32110DFD627232D0F2991AD221187BE356F19FA8190
*Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD
*Lot/Sequence: 263183/1

Test 2:
*Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
*Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
*Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
*Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D
*Unencrypted private key (hex): CA2759AA4ADB0F96C414F36ABEB8DB59342985BE9FA50FAAC228C8E7D90E3006
*Confirmation code: cfrm38V8G4qq2ywYEFfWLD5Cc6msj9UwsG2Mj4Z6QdGJAFQpdatZLavkgRd1i4iBMdRngDqDs51
*Lot/Sequence: 806938/1

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-20T05:17:45Z

Casascius: /* EC multiply, no compression, lot/sequence numbers */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.

This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should, but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Concatenate ''ownersalt'' + ''lotsequence'' and call this ''ownerentropy''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4, and ''lotsequence'' is omitted. ''ownerentropy'' becomes an alias for ''ownersalt''.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pointb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pointbprefix''.
# Do AES256Encrypt(pointb[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pointbx1''.
# Do AES256Encrypt(pointb[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pointbx2''.
# Concatenate ''pointbprefix'' + ''pointbx1'' + ''pointbx2'' (total 33 bytes) and call the result ''encryptedpointb''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownerentropy'' + ''addresshash'' + ''encryptedpointb''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression, no lot/sequence numbers===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

===EC multiply, no compression, lot/sequence numbers===

Test 1:
*Passphrase: MOLON LABE
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
*Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
*Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
*Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
*Unencrypted private key (hex): 44EA95AFBF138356A05EA32110DFD627232D0F2991AD221187BE356F19FA8190
*Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD
*Lot/Sequence: 263183/1

Test 2:
*Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
*Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
*Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
*Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D
*Unencrypted private key (hex): CA2759AA4ADB0F96C414F36ABEB8DB59342985BE9FA50FAAC228C8E7D90E3006
*Confirmation code: cfrm38V8G4qq2ywYEFfWLD5Cc6msj9UwsG2Mj4Z6QdGJAFQpdatZLavkgRd1i4iBMdRngDqDs51
*Lot/Sequence: 806938/1

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-20T05:16:38Z

Casascius: /* EC multiply, no compression */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.

This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should, but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Concatenate ''ownersalt'' + ''lotsequence'' and call this ''ownerentropy''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4, and ''lotsequence'' is omitted. ''ownerentropy'' becomes an alias for ''ownersalt''.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pointb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pointbprefix''.
# Do AES256Encrypt(pointb[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pointbx1''.
# Do AES256Encrypt(pointb[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pointbx2''.
# Concatenate ''pointbprefix'' + ''pointbx1'' + ''pointbx2'' (total 33 bytes) and call the result ''encryptedpointb''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownerentropy'' + ''addresshash'' + ''encryptedpointb''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression, no lot/sequence numbers===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

===EC multiply, no compression, lot/sequence numbers===

Test 1:
*Passphrase: MOLON LABE
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
*Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
*Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
*Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
*Unencrypted private key (hex): 44EA95AFBF138356A05EA32110DFD627232D0F2991AD221187BE356F19FA8190
*Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD

Test 2:
*Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
*Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
*Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
*Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D
*Unencrypted private key (hex): CA2759AA4ADB0F96C414F36ABEB8DB59342985BE9FA50FAAC228C8E7D90E3006
*Confirmation code: cfrm38V8G4qq2ywYEFfWLD5Cc6msj9UwsG2Mj4Z6QdGJAFQpdatZLavkgRd1i4iBMdRngDqDs51

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

File:BIP38 iPhone screenshot confirm.png

2013-01-08T06:27:23Z

Casascius:

File:BIP38 iPhone screenshot codes.png

2013-01-08T06:15:07Z

Casascius:

File:BIP38 iPhone screenshot ordering.png

2013-01-08T06:14:42Z

Casascius:

File:BIP38 iPhone screenshot passphrase.png

2013-01-08T06:14:16Z

Casascius:

File:BIP38 iPhone screenshot decrypted.png

2013-01-08T06:13:47Z

Casascius:

File:BIP38 iPhone screenshot decryption.png

2013-01-08T06:12:49Z

Casascius:

BIP 0038

2013-01-05T19:33:53Z

Casascius: /* Confirmation code */ rename "pubfactor" to "pointb"

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.

This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should, but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Concatenate ''ownersalt'' + ''lotsequence'' and call this ''ownerentropy''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4, and ''lotsequence'' is omitted. ''ownerentropy'' becomes an alias for ''ownersalt''.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pointb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pointbprefix''.
# Do AES256Encrypt(pointb[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pointbx1''.
# Do AES256Encrypt(pointb[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pointbx2''.
# Concatenate ''pointbprefix'' + ''pointbx1'' + ''pointbx2'' (total 33 bytes) and call the result ''encryptedpointb''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownerentropy'' + ''addresshash'' + ''encryptedpointb''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-05T18:26:36Z

Casascius: /* Encryption when EC multiply mode is used */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.

This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should, but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Concatenate ''ownersalt'' + ''lotsequence'' and call this ''ownerentropy''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4, and ''lotsequence'' is omitted. ''ownerentropy'' becomes an alias for ''ownersalt''.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownerentropy'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-04T20:29:29Z

Casascius: /* Proposed specification */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.

This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should, but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''lotsequence'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownersaltA'', ''ownersaltB'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4.
* ''lotsequence'' is omitted. The extra bytes in ''ownersalt'' take their place.
* All 8 bytes are provided as salt to the scrypt process.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

For the sake of simplicity, ''ownerentropy'' is used in future steps to refer to the 8 bytes produced by the owner (either 4 bytes ''ownersalt'' plus 4 bytes ''lotsequence'', or 8 bytes ''ownersalt'') where the distinction doesn't matter.

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownerentropy'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-04T19:33:29Z

Casascius: /* Encryption when EC multiply mode is used */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 selects one of two methods for introducing ''ownerentropy'' into the key derivation process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.

This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should, but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''lotsequence'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownersaltA'', ''ownersaltB'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4.
* ''lotsequence'' is omitted. The extra bytes in ''ownersalt'' take their place.
* All 8 bytes are provided as salt to the scrypt process.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

For the sake of simplicity, ''ownerentropy'' is used in future steps to refer to the 8 bytes produced by the owner (either 4 bytes ''ownersalt'' plus 4 bytes ''lotsequence'', or 8 bytes ''ownersalt'') where the distinction doesn't matter.

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownerentropy'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-04T19:09:10Z

Casascius: /* Proposed specification */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 selects one of two methods for introducing ''ownerentropy'' into the key derivation process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses.

Using EC multiply also allows a passphrase to be protected once by very expensive scrypt parameters, and then the protected passphrase be used to trivially generate large numbers of Bitcoin keypairs protected with the same passphrase without a correspondingly-expensive per-keypair delay or resource cost.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should, but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user, which will be included in the encrypted private key strings. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each one has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''lotsequence'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownersaltA'', ''ownersaltB'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4.
* ''lotsequence'' is omitted. The extra bytes in ''ownersalt'' take their place.
* All 8 bytes are provided as salt to the scrypt process.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

For the sake of simplicity, ''ownerentropy'' is used in future steps to refer to the 8 bytes produced by the owner (either 4 bytes ''ownersalt'' plus 4 bytes ''lotsequence'', or 8 bytes ''ownersalt'') where the distinction doesn't matter.

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownerentropy'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-04T16:57:51Z

Casascius: /* Encryption when EC multiply mode is used */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 selects one of two methods for introducing ''ownerentropy'' into the key derivation process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses.

Using EC multiply also allows a passphrase to be protected once by very expensive scrypt parameters, and then the protected passphrase be used to trivially generate large numbers of Bitcoin keypairs protected with the same passphrase without a correspondingly-expensive per-keypair delay or resource cost.

Steps performed by the person with the passphrase (call him the ''owner''):
# Generate 8 bytes of random numbers, call them ''ownerentropy''. Divide it into two halves, called ''ownersaltA'' and ''ownersaltB''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersaltA''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownersaltB'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownersaltA'', ''ownersaltB'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

NOTE: The methodology for creating an intermediate code was recently modified to introduce ''ownersaltB''. This permits rapid generation of batches of unique intermediate codes on mobile devices, allowing them to have a unique ''passfactor'' but without having to repeat the scrypt computation for each one. Summary of the differences: the magic ended in 0x53 instead of 0x51; the entirety of ''ownerentropy'' was given to scrypt as salt rather than just the first four bytes, and the double SHA256 step was skipped (so "passfactor" was the output of scrypt). Deprecation of the old methodology is recommended.

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if the magic ends in 0x51 instead of 0x53. (The decryption process needs this in order to derive the first factor from the passphrase, but the process of creating new encrypted keypairs is the same regardless of the value of this bit)
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownersaltA'' + ''ownersaltB'', n=1024, r=1, p=1, length=64 (n, r, p are provisional and subject to consensus). The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase. This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownersaltA'', ''ownersaltB'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownersaltA'' + ''ownersaltB'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase".

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-04T02:04:05Z

Casascius: /* Encryption when EC multiply mode is used */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 selects one of two methods for introducing ''ownerentropy'' into the key derivation process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses.

Using EC multiply also allows a passphrase to be protected once by very expensive scrypt parameters, and then the protected passphrase be used to trivially generate large numbers of Bitcoin keypairs protected with the same passphrase without a correspondingly-expensive per-keypair delay or resource cost.

Steps performed by the person with the passphrase (call him the ''owner''):
# Generate 8 bytes of random numbers, call them ''ownerentropy''. Divide it into two halves, called ''ownersaltA'' and ''ownersaltB''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersaltA''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownersaltB'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownersaltA'', ''ownersaltB'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

NOTE: The methodology for creating an intermediate code was recently modified to introduce ''ownersaltB''. This permits rapid generation of batches of unique intermediate codes on mobile devices, allowing them to have a unique ''passfactor'' but without having to repeat the scrypt computation for each one. Summary of the differences: the magic ended in 0x53 instead of 0x51; the entirety of ''ownerentropy'' was given to scrypt as salt rather than just the first four bytes, and the double SHA256 step was skipped (so "passfactor" was the output of scrypt). Deprecation of the old methodology is recommended.

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownersaltA'', ''ownersaltB'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte'' to 0x04 (or 0x24 if generating Bitcoin address with compressed public key)
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownersaltA'' + ''ownersaltB'', n=1024, r=1, p=1, length=64 (n, r, p are provisional and subject to consensus). The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownersaltA'' + ''ownersaltB'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase. This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownersaltA'', ''ownersaltB'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownersaltA'' + ''ownersaltB'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase".

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-04T01:13:25Z

Casascius: /* Encryption when EC multiply mode is used */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 selects one of two methods for introducing ''ownerentropy'' into the key derivation process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses.

Using EC multiply also allows a passphrase to be protected once by very expensive scrypt parameters, and then the protected passphrase be used to trivially generate large numbers of Bitcoin keypairs protected with the same passphrase without a correspondingly-expensive per-keypair delay or resource cost.

Steps performed by the person with the passphrase (call him the ''owner''):
# Generate 8 bytes of random numbers, call them ''ownerentropy''. Divide it into two halves, called ''ownersaltA'' and ''ownersaltB''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersaltA''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownersaltB'')) and call this ''passfactor''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownersaltA'', ''ownersaltB'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

NOTE: The methodology for creating an intermediate code was recently modified to introduce ''ownersaltB''. This permits rapid generation of batches of unique intermediate codes on mobile devices, allowing them to have a unique ''passpoint'' but without having to repeat the scrypt computation for each one. The magic bytes were different in the prior proposal, while still producing the "passphrase" prefix.

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownersaltA'', ''ownersaltB'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte'' to 0x04 (or 0x24 if generating Bitcoin address with compressed public key)
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownersaltA'' + ''ownersaltB'', n=1024, r=1, p=1, length=64 (n, r, p are provisional and subject to consensus). The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownersaltA'' + ''ownersaltB'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase. This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownersaltA'', ''ownersaltB'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownersaltA'' + ''ownersaltB'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase".

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-04T01:12:43Z

Casascius: /* Specification */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 selects one of two methods for introducing ''ownerentropy'' into the key derivation process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses.

Using EC multiply also allows a passphrase to be protected once by very expensive scrypt parameters, and then the protected passphrase be used to trivially generate large numbers of Bitcoin keypairs protected with the same passphrase without a correspondingly-expensive per-keypair delay or resource cost.

Steps performed by the person with the passphrase (call him the ''owner''):
# Generate 8 bytes of random numbers, call them ''ownerentropy''. Divide it into two halves, called ''ownersaltA'' and ''ownersaltB''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersaltA''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownersaltB'')) and call this ''passpoint''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownersaltA'', ''ownersaltB'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

NOTE: The methodology for creating an intermediate code was recently modified to introduce ''ownersaltB''. This permits rapid generation of batches of unique intermediate codes on mobile devices, allowing them to have a unique ''passpoint'' but without having to repeat the scrypt computation for each one. The magic bytes were different in the prior proposal, while still producing the "passphrase" prefix.

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownersaltA'', ''ownersaltB'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte'' to 0x04 (or 0x24 if generating Bitcoin address with compressed public key)
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownersaltA'' + ''ownersaltB'', n=1024, r=1, p=1, length=64 (n, r, p are provisional and subject to consensus). The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownersaltA'' + ''ownersaltB'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase. This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownersaltA'', ''ownersaltB'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownersaltA'' + ''ownersaltB'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase".

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-03T23:14:33Z

Casascius: /* Proposed specification */

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 selects one of two methods for introducing ''ownersalt'' into the key derivation process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses.

Using EC multiply also allows a passphrase to be protected once by very expensive scrypt parameters, and then the protected passphrase be used to trivially generate large numbers of Bitcoin keypairs protected with the same passphrase without a correspondingly-expensive per-keypair delay or resource cost.

Steps performed by the person with the passphrase (call him the ''owner''):
# Generate two 32-bit (4-byte) random numbers, call them ''ownersaltA'' and ''ownersaltB''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersaltA''. n=16384, r=8, p=8, length=32. (parameters n, r, p are provisional and subject to consensus-seeking)
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownersaltB'')) and call this ''passpoint''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownersaltA'', ''ownersaltB'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

NOTE: The methodology for creating an intermediate code was recently modified to introduce ''ownersaltB''. This permits rapid generation of batches of unique intermediate codes on mobile devices, allowing them to have a unique ''passpoint'' but without having to repeat the scrypt computation for each one. The magic bytes were different in the prior proposal, while still producing the "passphrase" prefix.

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownersaltA'', ''ownersaltB'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte'' to 0x04 (or 0x24 if generating Bitcoin address with compressed public key)
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownersaltA'' + ''ownersaltB'', n=1024, r=1, p=1, length=64 (n, r, p are provisional and subject to consensus). The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownersaltA'' + ''ownersaltB'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase. This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownersaltA'', ''ownersaltB'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownersaltA'' + ''ownersaltB'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase".

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

BIP 0038

2013-01-03T23:13:52Z

Casascius: /* Proposed specification */ Modified the proposal to introduce a hashing step in the intermediate code generation process. This helps allow bulk generation of intermediate codes with limited CPU, which in turn, improves security versus using 1 code

<pre>
BIP: 38
Title: Passphrase-protected private key
Author: Mike Caldwell
Status: Draft
Type: Standards Track
Created: 20-11-2012
</pre>

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and institutions wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''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.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting 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 be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
*** the bit with value 0x04 selects one of two methods for introducing ''ownersalt'' into the key derivation process. This applies to EC-multiplied keys only.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses.

Using EC multiply also allows a passphrase to be protected once by very expensive scrypt parameters, and then the protected passphrase be used to trivially generate large numbers of Bitcoin keypairs protected with the same passphrase without a correspondingly-expensive per-keypair delay or resource cost.

Steps performed by the person with the passphrase (call him the ''owner''):
# Generate two 32-bit (4-byte) random numbers, call them ''ownersaltA'' and ''ownersaltB''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersaltA''. n=16384, r=8, p=8, length=32. (parameters n, r, p are provisional and subject to consensus-seeking)
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownersaltB'')) and call this ''passpoint''.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownersaltA'', ''ownersaltB'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

NOTE: The methodology for creating an intermediate code was recently modified to introduce ''ownersaltB''. This permits rapid generation of batches of unique intermediate codes on mobile devices, allowing them to have a unique ''passpoint'' but without having to repeat the scrypt computation for each one. The magic bytes were different in the prior proposal, while still producing the "passphrase" prefix.

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownersaltA'', ''ownersaltB'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte'' to 0x04 (or 0x24 if generating Bitcoin address with compressed public key)
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownersaltA'' + ''ownersaltB'', n=1024, r=1, p=1, length=64 (n, r, p are provisional and subject to consensus). The "+" operator is concatenation.
#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownersaltA'' + ''ownersaltB'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase. This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownersaltA'', ''ownersaltB'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pubfactorb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pubfactorprefix''.
# Do AES256Encrypt(pubfactor[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pubfactorx1''.
# Do AES256Encrypt(pubfactor[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pubfactorx2''.
# Concatenate ''pubfactorprefix'' + ''pubfactorx1'' + ''pubfactorx2'' (total 33 bytes) and call the result ''encryptedpubfactor''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''ownersaltA'' + ''ownersaltB'' + ''addresshash'' + ''encryptedpubfactor''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase".

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

==See Also==

* [[List of address prefixes]]

[[Category: BIP]]

File:Dense Minikey sample.png

2012-12-16T18:07:57Z

Casascius:

Contract sample language/Selling precious metals for Bitcoin

2012-12-15T18:30:12Z

Casascius: Created page with "===Date=== The offer should be dated, since PGP signing doesn't establish the date. December 14, 2012. ===Offer for a fixed amount=== An offer for a fixed amount is simple..."

===Date===

The offer should be dated, since PGP signing doesn't establish the date.

December 14, 2012.

===Offer for a fixed amount===
An offer for a fixed amount is simple to understand and doesn't require the buyer to worry about volatility.

I, '''insert name here''', hereby offer to sell ten (10) one-ounce Austrian Philharmonic gold coins as described below,
for 132 Bitcoins each per coin, which includes fully insured Registered Mail shipping to any US address.
The coins can be bought in increments of a single coin - in other words, you do not have to buy all ten.

===Offer for an amount relative to MtGox===

I, '''insert name here''', hereby offer to sell ten (10) one-ounce Austrian Philharmonic gold coins as described below,
for the Bitcoin equivalent of $1770 per coin, which includes fully insured Registered Mail shipping to any US address.
The coins can be bought in increments of a single coin - in other words, you do not have to buy all ten.

Any or all of the following conditions can be made part of the offer. It will make the offer harder to accept, but also lessens the possibility of an opportunistic offer based on an unexpected surprise from MtGox.

The following restrictions apply to this offer. If an attempt to accept this offer is made while invalid for a reason
listed here, I reserve the right to elect to either issue a refund or complete the transaction regardless, without
prejudice to my right to refuse to do so under the same conditions in the future.
* This offer is only valid during periods of low volatility, defined as follows: the 24-hour MtGox high is less than
105% of the 24-hour MtGox low.
* This offer is only valid so long as the MtGox data feed for the last 24 hours is available and believed to be
substantially accurate.
* This offer is only valid so long as the USD/BTC exchange rate is at least $13.50.

===Describe what's for sale===

The 1 ounce Austrian Philharmonic gold coins for sale are brand new in an unopened mint tube of 10.
If a single buyer purchases all ten coins, they will be shipped in the original unopened mint tube.
More about the coin: http://www.monex.com/prods/gold_vienna.html
I certify that these coins were acquired through a reputable precious metals dealer.

===Describe how to accept the offer===
If requesting bitcoins to be sent directly to you:
The Bitcoin address for this transaction is: '''insert bitcoin address here'''
See activity: http://blockchain.info/address/'''insert bitcoin address here'''

If this is an address under the control of an escrow agent:
This Bitcoin address is under the combined control of me and an escrow agent as described below.
A PGP-signed message from the escrow agent follows my message.

For a fixed price offer:
As long as this address has fewer than 1320 Bitcoins sent to it, my offer is valid and unclaimed.

If not for a fixed price:
I anticipate that if this offer is accepted, that the above Bitcoin address will have had at least 1200 bitcoins
sent to it.

To accept this offer, send bitcoins in an even multiple of 132 bitcoins, but first:

===Add a cancellation clause if necessary===
It is totally reasonable to be willing to cancel your unaccepted offer when necessary. One way to cancel your offer is just to send enough of your own bitcoins to the address, essentially satisfying it yourself. But if you can't do that:

I reserve the right to cancel this offer so long as it has not been accepted. I will signal that I have
cancelled my offer by sending 0.01 BTC from address XXXXXXX to the above address. Any payment
received after cancellation will be refunded.

===Add instructions===
1. Please check the address to ensure that the offer has not already been claimed in its entirety.
2. You must be able to prove you are the owner of the Bitcoin address(es) that sent the payment.
Either you need to be able to sign messages with it, or move an arbitrary number of coins sent to it
upon request.
3. You must be able to accept Registered Mail at an address in the US.
4. The first person(s) who pay the above address (as determined by the BlockChain.info first-seen
timestamp) are the person(s) to whom I am selling. If I receive payments to purchase in excess of the ten
offered coins, I reserve the right to either refund the excess payments, or to sell further coins at the same
price, at my option. The ten coins will be allocated in the order the payments for them arrive.
5. This offer is for gold coins at a fixed price. Any payment that is not a multiple of 132 BTC in a single transaction
will not be deemed an acceptance of this offer.
6. This offer unconditionally expires at 18:00 UTC on December 16, 2012 to the extent it is not accepted
before then.
-----BEGIN PGP SIGNATURE-----
Version: XXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-----END PGP SIGNATURE-----

===Helpful info===
Stay safe!
Always verify the PGP signature of any signed offer asking you to send bitcoins.
Making a copy of the signed offer is a good idea too.
My PGP key is available from my bitcoin-otc profile.
http://bitcoin-otc.com/viewratingdetail.php?nick=casascius&sign=ANY&type=RECV

User:Casascius/Escrow scheme draft

2012-12-14T04:27:45Z

Casascius: /* Base58 codes (draft) for 3-party scheme */

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, one of the parties initiates an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

====Three party scheme====

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

* Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
* Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
* Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

====Four party scheme====
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
* Bob creates private keys a and b. He gives a and Gybx to Alice. He gives Gab to Charlie. He gives b and Gax to Eddie.
* Alice and Eddie don't create any private keys.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gybx. She calculates the Bitcoin address as (Gybx)a.
* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gax, b and y. He calculates the Bitcoin address as (Gax)by.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.

==Base58 codes (draft) for 3-party scheme==

An escrow invitation starts out with two random 256 bit numbers, x and y. One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy. The identifier for the proposal is the hash of Gxy (compressed notation).

We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier. This allows for the prefixes einva, einvb, einvc, as well as five or six characters following the prefixes to be the same for matching invitations. This number will be referred to as ''identifier31''.

Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:
* 8 bytes: Int64 sum of a constant plus ''identifier31''. The constant depends on whether this is to create part a or b. Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched. In this case, "plus" refers to addition.
** Constant for part a: 0x140bebc0a12ca9c6
** Constant for part b: 0x140bebc16ae0563b
* 1 byte: reserved, set this to 0 and reject an invitation that has something other than 0 here
* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x140bebcba900182f plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 1 byte: reserved, must be 0
* 32 bytes: z
* 20 bytes: hash160 of expected bitcoin address
* 1 byte: bitflags
** Bit with value 0x02: 0 if payment invitation was created by someone who knows the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
** Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
** all other bits: reserved and must be 0
* 11 bytes: set to all 0's

Payment confirmation generated by payee contains Gz and is 106 Base58 characters starting with "cfrmp". Its purpose is to prove the association of the generated Bitcoin address to the escrow agent, if needed, without giving away z, which would grant the ability to redeem funds.
Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x12f4eff38f7d74f9 plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 33 bytes: Gz
* 20 bytes: hash160 of expected bitcoin address
* 1 byte: bitflags
** Bit with value 0x02: 0 if address confirmation was created by someone who knows the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
** Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
** all other bits: reserved and must be 0
* 11 bytes: set to all 0's

User:Casascius/Escrow scheme draft

2012-12-14T00:09:27Z

Casascius: /* Base58 codes (draft) for 3-party scheme */

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, one of the parties initiates an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

====Three party scheme====

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

* Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
* Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
* Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

====Four party scheme====
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
* Bob creates private keys a and b. He gives a and Gybx to Alice. He gives Gab to Charlie. He gives b and Gax to Eddie.
* Alice and Eddie don't create any private keys.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gybx. She calculates the Bitcoin address as (Gybx)a.
* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gax, b and y. He calculates the Bitcoin address as (Gax)by.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.

==Base58 codes (draft) for 3-party scheme==

An escrow invitation starts out with two random 256 bit numbers, x and y. One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy. The identifier for the proposal is the hash of Gxy (compressed notation).

We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier. This allows for the prefixes einva, einvb, einvc, as well as five or six characters following the prefixes to be the same for matching invitations. This number will be referred to as ''identifier31''.

Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:
* 8 bytes: Int64 sum of a constant plus ''identifier31''. The constant depends on whether this is to create part a or b. Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched. In this case, "plus" refers to addition.
** Constant for part a: 0x140bebc0a12ca9c6
** Constant for part b: 0x140bebc16ae0563b
* 1 byte: reserved, set this to 0 and reject an invitation that has something other than 0 here
* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x140bebcba900182f plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 32 bytes: z
* 1 byte: bitflags
** Bit with value 0x02: 0 if payment invitation was created by someone who knows the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
** Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
** all other bits: reserved and must be 0
* 20 bytes: hash160 of expected bitcoin address
* 12 bytes: set to all 0's

User:Casascius/Escrow scheme draft

2012-12-13T23:47:26Z

Casascius: /* Base58 codes (draft) for 3-party scheme */

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, one of the parties initiates an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

====Three party scheme====

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

* Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
* Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
* Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

====Four party scheme====
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
* Bob creates private keys a and b. He gives a and Gybx to Alice. He gives Gab to Charlie. He gives b and Gax to Eddie.
* Alice and Eddie don't create any private keys.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gybx. She calculates the Bitcoin address as (Gybx)a.
* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gax, b and y. He calculates the Bitcoin address as (Gax)by.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.

==Base58 codes (draft) for 3-party scheme==

An escrow invitation starts out with two random 256 bit numbers, x and y. One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy. The identifier for the proposal is the hash of Gxy (compressed notation).

We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier. This allows for the prefixes einva, einvb, einvc, as well as five or six characters following the prefixes to be the same for matching invitations. This number will be referred to as ''identifier31''.

Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:
* 8 bytes: Int64 sum of a constant plus ''identifier31''. The constant depends on whether this is to create part a or b. Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched. In this case, "plus" refers to addition.
** Constant for part a: 0x140bebc0f619ffdd
** Constant for part b: 0x140bebc1bfcdac52
* 1 byte: reserved, set this to 0 and reject an invitation that has something other than 0 here
* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x140bebcbfded6e45 plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 32 bytes: z
* 1 byte: bitflags
** Bit with value 0x02: 0 if payment invitation was created by someone who knows the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
** Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
** all other bits: reserved and must be 0
* 20 bytes: hash160 of expected bitcoin address
* 12 bytes: set to all 0's

User:Casascius/Escrow scheme draft

2012-12-13T23:46:56Z

Casascius: /* Base58 codes (draft) for 3-party scheme */

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, one of the parties initiates an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

====Three party scheme====

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

* Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
* Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
* Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

====Four party scheme====
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
* Bob creates private keys a and b. He gives a and Gybx to Alice. He gives Gab to Charlie. He gives b and Gax to Eddie.
* Alice and Eddie don't create any private keys.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gybx. She calculates the Bitcoin address as (Gybx)a.
* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gax, b and y. He calculates the Bitcoin address as (Gax)by.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.

==Base58 codes (draft) for 3-party scheme==

An escrow invitation starts out with two random 256 bit numbers, x and y. One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy. The identifier for the proposal is the hash of Gxy (compressed notation).

We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier. This allows for the prefixes einva, einvb, einvc, as well as five or six characters following the prefixes to be the same for matching invitations. This number will be referred to as ''identifier31''.

Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:
* 8 bytes: Int64 sum of a constant plus ''identifier31''. The constant depends on whether this is to create part a or b. Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched. In this case, "plus" refers to addition.
** Constant for part a: 0x140bebc0f619ffdd
** Constant for part b: 0x140bebc1bfcdac52
* 1 byte: reserved, set this to 0
* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x140bebcbfded6e45 plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 32 bytes: z
* 1 byte: bitflags
** Bit with value 0x02: 0 if payment invitation was created by someone who knows the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
** Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
** all other bits: reserved and must be 0
* 20 bytes: hash160 of expected bitcoin address
* 12 bytes: set to all 0's

User:Casascius/Escrow scheme draft

2012-12-13T23:40:21Z

Casascius: /* Base58 codes (draft) for 3-party scheme */

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, one of the parties initiates an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

====Three party scheme====

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

* Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
* Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
* Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

====Four party scheme====
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
* Bob creates private keys a and b. He gives a and Gybx to Alice. He gives Gab to Charlie. He gives b and Gax to Eddie.
* Alice and Eddie don't create any private keys.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gybx. She calculates the Bitcoin address as (Gybx)a.
* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gax, b and y. He calculates the Bitcoin address as (Gax)by.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.

==Base58 codes (draft) for 3-party scheme==

An escrow invitation starts out with two random 256 bit numbers, x and y. One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy. The identifier for the proposal is the hash of Gxy (compressed notation).

We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier. This allows for the prefixes einva, einvb, einvc, as well as five or six characters following the prefixes to be the same for matching invitations. This number will be referred to as ''identifier31''.

Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:
* 8 bytes: Int64 sum of a constant plus ''identifier31''. The constant depends on whether this is to create part a or b. Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched. In this case, "plus" refers to addition.
** Constant for part a: 0x140bebc0f619ffdd
** Constant for part b: 0x140bebc1bfcdac52
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x140bebcbfded6e45 plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 32 bytes: z
* 1 byte: bitflags
** Bit with value 0x02: 0 if payment invitation was created with the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
** Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
** all other bits: reserved and must be 0
* 20 bytes: hash160 of expected bitcoin address
* 12 bytes: set to all 0's

User:Casascius/Escrow scheme draft

2012-12-13T23:37:26Z

Casascius: /* Base58 codes (draft) for 3-party scheme */

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, one of the parties initiates an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

====Three party scheme====

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

* Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
* Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
* Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

====Four party scheme====
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
* Bob creates private keys a and b. He gives a and Gybx to Alice. He gives Gab to Charlie. He gives b and Gax to Eddie.
* Alice and Eddie don't create any private keys.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gybx. She calculates the Bitcoin address as (Gybx)a.
* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gax, b and y. He calculates the Bitcoin address as (Gax)by.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.

==Base58 codes (draft) for 3-party scheme==

An escrow invitation starts out with two random 256 bit numbers, x and y. One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy. The identifier for the proposal is the hash of Gxy (compressed notation).

We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier. This allows for the prefixes einva, einvb, einvc, as well as five or six characters following the prefixes to be the same for matching invitations. This number will be referred to as ''identifier31''.

Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:
* 8 bytes: Int64 sum of a constant plus ''identifier31''. The constant depends on whether this is to create part a or b. Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched. In this case, "plus" refers to addition.
** Constant for part a: 0x140bebc0f619ffdd
** Constant for part b: 0x140bebc1bfcdac52
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x140bebcbfded6e45 plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 32 bytes: z
* 1 byte: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
* 20 bytes: hash160 of expected bitcoin address
* 12 bytes: set to all 0's

User:Casascius/Escrow scheme draft

2012-12-13T23:35:18Z

Casascius: /* Base58 codes (draft) for 3-party scheme */

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, one of the parties initiates an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

====Three party scheme====

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

* Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
* Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
* Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

====Four party scheme====
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
* Bob creates private keys a and b. He gives a and Gybx to Alice. He gives Gab to Charlie. He gives b and Gax to Eddie.
* Alice and Eddie don't create any private keys.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gybx. She calculates the Bitcoin address as (Gybx)a.
* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gax, b and y. He calculates the Bitcoin address as (Gax)by.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.

==Base58 codes (draft) for 3-party scheme==

An escrow invitation starts out with two random 256 bit numbers, x and y. One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy. The identifier for the proposal is the hash of Gxy (compressed notation).

We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier. This allows for the prefixes einva, einvb, einvc, as well as four or five characters following the prefixes to be the same for matching invitations. This number will be referred to as ''identifier31''.

Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:
* 8 bytes: Int64 sum of a constant plus ''identifier31''. The constant depends on whether this is to create part a or b. Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched. In this case, "plus" refers to addition.
** Constant for part a: 0x140bebc0f619ffdd
** Constant for part b: 0x140bebc1bfcdac52
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x140bebcbfded6e45 plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 32 bytes: z
* 1 byte: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
* 20 bytes: hash160 of expected bitcoin address
* 12 bytes: set to all 0's

User:Casascius/Escrow scheme draft

2012-12-13T23:28:47Z

Casascius:

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, one of the parties initiates an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

====Three party scheme====

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

* Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
* Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
* Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

====Four party scheme====
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
* Bob creates private keys a and b. He gives a and Gybx to Alice. He gives Gab to Charlie. He gives b and Gax to Eddie.
* Alice and Eddie don't create any private keys.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gybx. She calculates the Bitcoin address as (Gybx)a.
* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gax, b and y. He calculates the Bitcoin address as (Gax)by.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.

==Base58 codes (draft) for 3-party scheme==

An escrow invitation starts out with two random 256 bit numbers, x and y. One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy. The identifier for the proposal is the hash of Gxy (compressed notation).

We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier. This allows for the prefixes einva, einvb, einvc, as well as four or five characters following the prefixes to be the same for matching invitations. This number will be referred to as ''identifier31''.

Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:
* 16 bytes: Int64 sum of a constant plus ''identifier31''. The constant depends on whether this is to create part a or b. Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched. In this case, "plus" refers to addition.
** Constant for part a: 0x140bebc0f619ffdd
** Constant for part b: 0x140bebc1bfcdac52
* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 16 bytes: Int64 sum of 0x140bebcbfded6e45 plus ''identifier31'' from the accepted escrow proposal
* 32 bytes: z
* 1 byte: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet)
* 20 bytes: hash160 of expected bitcoin address
* 11 bytes: set to all 0's

List of address prefixes

2012-12-10T00:24:47Z

Casascius:

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Initial byte(s)
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|<tt>3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX</tt>
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Uncompressed Bitcoin Private key
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|128
|K or L
|Compressed Bitcoin Private key
|<tt>L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Testnet script hash
|
|-
|239
|9
|Uncompressed Testnet Private key
|<tt>91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6</tt>
|-
|239
|c
|Compressed Testnet Private key
|<tt>cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm</tt>
|
|-
|0x142, 0x143
|6P
|Encrypted private key ([[BIP 0038|BIP 38]])
|<tt> 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg </tt>
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-12-10T00:24:41Z

Casascius:

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Initial byte(s)
!Leading symbol
!Use
!Example
|-
|00
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|<tt>3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX</tt>
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Uncompressed Bitcoin Private key
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|128
|K or L
|Compressed Bitcoin Private key
|<tt>L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Testnet script hash
|
|-
|239
|9
|Uncompressed Testnet Private key
|<tt>91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6</tt>
|-
|239
|c
|Compressed Testnet Private key
|<tt>cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm</tt>
|
|-
|0x142, 0x143
|6P
|Encrypted private key ([[BIP 0038|BIP 38]])
|<tt> 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg </tt>
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-12-10T00:24:26Z

Casascius:

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Initial byte(s)
!Leading symbol
!Use
!Example
|-
|00
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|<tt>3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX</tt>
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Uncompressed Bitcoin Private key
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|128
|K or L
|Compressed Bitcoin Private key
|<tt>L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Testnet script hash
|
|-
|239
|9
|Uncompressed Testnet Private key
|<tt>91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6</tt>
|-
|239
|c
|Compressed Testnet Private key
|<tt>cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm</tt>
|
|-
|0x142, 0x0143
|6P
|Encrypted private key ([[BIP 0038|BIP 38]])
|<tt> 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg </tt>
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

User:Casascius/Escrow scheme draft

2012-12-08T23:57:25Z

Casascius: /* Initiation of Proposal */

User:Casascius/Escrow scheme draft

2012-12-08T16:10:46Z

Casascius: /* Four party scheme */

User:Casascius/Escrow scheme draft

2012-12-08T07:39:33Z

Casascius: /* Four party scheme */

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, any of the parties (other than Customer Charlie) can initiate an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

====Three party scheme====

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

* Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
* Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
* Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

====Four party scheme====
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie. He gives Gx to Alice.
* Bob creates private key b. He gives it to Eddie. Bob has b, x, and Gy. He gives Gbxy to Alice.
* Alice creates private key a. She gives it to Bob. Alice has a, Gx, and Gbxy. She gives Gax to Eddie.
* Now that Bob knows a, he provides Gab to Charlie.
* Eddie doesn't create any private keys but knows y, b, and Gax.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gbxy. She calculates the Bitcoin address as (Gxy)ab.
* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gabx and y. He calculates the Bitcoin address as (Gabx)y.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a is never known by Eddie or Charlie and prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.

User:Casascius/Escrow scheme draft

2012-12-08T07:34:12Z

Casascius: /* How the scheme works */

User:Casascius/Escrow scheme draft

2012-12-08T06:19:36Z

Casascius:

User:Casascius/Escrow scheme draft

2012-12-08T03:18:08Z

Casascius:

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

# One shared Bitcoin address for the entire transaction
# All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
# Escrow agent can control the disposition of the funds but cannot take the funds
# Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

* '''B - Beneficiary Bob''' - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
* '''A - Alternate Beneficiary Alice (or Customer Alice)''': Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

==How the scheme works==

===Initiation of Proposal===
First, any of the parties (other than Customer Charlie) can initiate an escrow transaction proposal. The second party creates a proposal that references the first. The third party creates an acceptance.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (S), Acceptance (A), or Confirmation (C)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

If a prospective Escrow Agent initiates a proposal, he generates two private keys we'll call x and y. He emits two records with prefixes EP4A and EP4B.
* EP4A contains private key x and public key Gy.
* EP4B contains private key y and public key Gx.
* Both records contain a 32-bit proposal identifier (which is the first 32 bits of RIPEMD160(SHA256(Gxy))).

If a prospective Beneficiary initiates a proposal, he generates a private key we'll call b. He emits two records with prefixes BP4A and BP4E.
* BP4A contains private key b.
* BP4E contains public key Gb.
* Both records contain a 32-bit proposal identifier, the first 32 bits of RIPEMD160(SHA256(Gb)).

If a prospective Alternate Beneficiary, or Customer who is also an Alternate Beneficiary, initiates a proposal, she generates a private key we'll call a. She emits two records with prefixes AP4B and AP4E.
* AP4B contains private key a.
* AP4E contains public key Ga.
* Both records contain a 32-bit proposal identifier, the first 32 bits of RIPEMD160(SHA256(Ga)).

===Intermediate acceptance and secondary proposal===
A party who receives an initial proposal as described above may Second the proposal and become the second party, producing an Acceptance record for the proposing party, and a Seconding record for the remaining party.

Proposals can be created and accepted by the parties in any order, except the escrow agent cannot be last.

If a prospective Escrow Agent seconds an initial proposal from a Beneficiary, then he generates private keys x and y, and emits an Acceptance record with prefix EA4B and a Seconding record with prefix ES4A.
* EA4B contains private key y and public key Gx.
* ES4A contains private key x and public key Gy.
* Both records use the same 32-bit proposal identifier that came from the Beneficiary, which is a hash based on Gb.
* The proposal record has bits set indicating that it is also the acceptance of a proposal by a prospective Beneficiary.

If a prospective Escrow Agent accepts an initial proposal from an Alternate Beneficiary / Customer who is also an Alternate Beneficiary, the same method is employed as described above, except swap all a and b, and swap all x and y as applicable.

If a prospective Beneficiary accepts an initial proposal created by an Escrow Agent, then he generates private key b, and emits an acceptance record BA4E and a secondary proposal record with prefix BP4A.
* BA4E contains public keys Gb and Gab.
* BP4A contains private key b.
* Both records use the same 32-bit proposal identifier that came from the Escrow Agent, which is a hash based on Gxy.

If a prospective Alternate Beneficiary accepts an initial proposal created by an Escrow Agent, follow the same procedure for a Beneficiary, swapping a and b, and x and y.

===Final acceptance===
A party in a position to issue a final acceptance will have received two proposals with identical proposal identifiers. That party should generate its own private key(s) as defined in the other stages, and emit acceptance records for the benefit of the first two parties. It is at this point that the accepting party knows the Bitcoin address for the entire arrangement.
* If the final acceptance happens by an Escrow Agent, he knows Gab, x, and y, and can calculate the Bitcoin address as (Gab)xy.
* If the final acceptance happens by a Beneficiary or Alternate Beneficiary, he/she knows or can calculate Gxy and knows a and b. He or she can calculate the Bitcoin address as (Gxy)ab.

Upon final acceptance, each party is in a position to issue a confirmation record for the benefit of Charlie the paying-only customer. This confirmation permits Charlie to ensure he is paying an address that is participating in an escrow scheme.

If confirmation is needed, each party shall issue one. Charlie will need three records in order to receive a satisfactory confirmation.
* The Escrow Agent provides a confirmation record which starts with EC4C and contains:
* The Beneficiary provides a confirmation which starts with BC4C and contains: