From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V0Em7-0003pV-Tm for bitcoin-development@lists.sourceforge.net; Fri, 19 Jul 2013 17:47:27 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of me.com designates 17.172.220.236 as permitted sender) client-ip=17.172.220.236; envelope-from=jeanpaulkogelman@me.com; helo=st11p02mm-asmtp001.mac.com; Received: from st11p02mm-asmtpout001.mac.com ([17.172.220.236] helo=st11p02mm-asmtp001.mac.com) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V0Em4-0007mV-Gj for bitcoin-development@lists.sourceforge.net; Fri, 19 Jul 2013 17:47:27 +0000 Received: from st11p02mm-spool002.mac.com ([17.172.220.247]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.05(7.0.4.27.4) 64bit (built Apr 23 2013)) with ESMTP id <0MQ7007ND2Q9LI20@st11p02mm-asmtp001.mac.com> for bitcoin-development@lists.sourceforge.net; Fri, 19 Jul 2013 17:47:02 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-07-19_06:2013-07-19, 2013-07-19, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000 definitions=main-1307190137 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6v39sDBKz5LmGaScvSoOlg)" Received: from localhost ([17.172.220.161]) by st11p02mm-spool002.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQ7006VV2QCOJ60@st11p02mm-spool002.mac.com> for bitcoin-development@lists.sourceforge.net; Fri, 19 Jul 2013 17:47:00 +0000 (GMT) To: bitcoin-development@lists.sourceforge.net From: Jean-Paul Kogelman Date: Fri, 19 Jul 2013 17:46:44 +0000 (GMT) X-Mailer: iCloud Mail (1R) X-Originating-IP: [159.153.138.53] Message-id: <20ec1e35-3051-45d6-b449-e4a4d5c06dc8@me.com> X-Spam-Score: -0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.0 FILL_THIS_FORM Fill in a form with personal information 0.4 FILL_THIS_FORM_FRAUD_PHISH Answer suspicious question(s) X-Headers-End: 1V0Em4-0007mV-Gj Subject: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:47:28 -0000 --Boundary_(ID_6v39sDBKz5LmGaScvSoOlg) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable =0AHi everyone,=0A=0AI'm looking for feedback on the proposal below.=0A=0A= Kind regards,=0A=0AJean-Paul=0A=0A---=0ABIP:=C2=A0=0ATitle: Base58 encoded= HD Wallet master seed with optional encryption=0AAuthor: Jean-Paul Kogelm= an=0AStatus: Draft=0AType: Informational=0ACreated: 17-07-2013=0A=0AAbstra= ct=0A=0AThis proposal describes a method for encoding and optionally encry= pting a Bitcoin Hierarchical Deterministic (HD) Wallet master seed. Encode= d master seeds are intended for use on paper wallets. Each string contains= all the information needed to verify and reconstitute an HD wallet except= for the optional passphrase. The encrypted version uses salting and scryp= t to resist brute-force attacks.=0A=0AThe method provides two encoding met= hodologies in 3 lengths each (16, 32 and 64 byte seeds). One is a clear ve= rsion of the master seed with verification information for integrity check= ing and the other is an encrypted representation.=0A=0AA 32-bit hash of th= e resulting master Bitcoin public address is encoded in plain text within = each seed record, so in the case of an encrypted seed, it can be correlate= d to a Bitcoin public address with reasonable probability by someone not k= nowing the passphrase. The complete Bitcoin public address can be derived = through successful decoding and optional decryption of the master seed rec= ord.=0A=0A=0AMotivation=0A=0AThe extended private keys proposed in BIP 003= 2 are long, fixed length records and don't offer any form of security. The= master seed used to generate the HD wallet is typically shorter than the = extended master private key that results from it.=C2=A0=0A=0AA compact rep= resentation of the master seed is easier to handle and a 2-factor version = of the master seed record allows for safe storage and the creation of pape= r wallets by 3rd parties.=C2=A0=0A=0A=0ACopyright=0A=0AThis proposal is he= reby placed in the public domain.=0A=0A=0ARationale=0A=0AUser story: As a = Bitcoin user who uses HD wallets, I would like the ability to store my wal= let master seed in a compact form as a paper wallet.=0A=0AUser story: As a= Bitcoin user who uses HD wallets, I would like the ability to have a 3rd = party create a paper wallet with my master seed in it, without having acce= ss to the funds stored in the wallet.=0A=0AUser story: As a Bitcoin user w= ho uses HD wallets, I would like the ability to choose the strength of the= master seed depending on my security requirements and how I wish to store= it.=C2=A0=0A=0A=0ASpecification=0A=0AThis proposal makes use of the follo= wing functions and definitions:=0A=0AAES256Encrypt, AES256Decrypt: the sim= ple form of the well-known AES block cipher without consideration for init= ialization vectors or block chaining. Each of these functions takes a 256-= bit key and a variable legth of input and deterministically yields output = data of similar length to the input.=0A=0ASHA256: a well-known hashing alg= orithm that takes an arbitrary number of bytes as input and deterministica= lly yields a 32-byte hash.=0A=0ARIPEMD160: a well known hashing algorithm = that takes an arbitrary number of bytes as input and deterministically yie= lds a 20-byte hash.=0A=0Ascrypt: 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.=0A=0AHMAC-SHA512: Pr= oduces a 64 byte (512 bit) hash based message authentication code using th= e SHA512 hash function using a seed (in our case we will use a byte repres= entation of "Bitcoin seed") and an aribtrary input message. The output wil= l be 64 bytes.=0A=0ABase58Check: a method for encoding arrays of bytes usi= ng 58 alphanumeric characters commonly used in the Bitcoin ecosystem.=0A=0A= G, N: Constants defined as part of the secp256k1 elliptic curve. G is an e= lliptic curve point, and N is a large positive integer.=0A=0APrefix=0A=0AI= t is proposed that the resulting Base58Check-encoded string start with eit= her "WS" for clear master seed records or "ws" for 2-factor master seed re= cords. The prefixes "WS" and "ws" were chosen as abreviations of the term = "Wallet Seed" and upper case to indicate whether it's a clear representati= on and lower case when it's a 2-factor representation.=C2=A0=0A=0ATo keep = the size of the encrypted key equal to the clear version, no initializatio= n vectors (IVs) are used in the AES encryption. Rather, suitable values fo= r IV-like use are derived using scrypt from the passphrase and from using = a 32-bit hash of the resulting Bitcoin public address as salt.=0A=0APropos= ed specification=0A=0AThere are 2 seed record representations with 3 lengt= hs each, resulting in a total of 6 different object identifier prefixes.=C2= =A0=0A=0APrefix 0x1093: Clear 16 byte master seed, total length: 22 bytes=0A= Prefix 0x1E68: Clear 32 byte master seed, total length: 38 bytes=0APrefix = 0x665A: Clear 64 byte master seed, total length: 70 bytes=0A=0APrefix 0x1E= E4: 2-factor 16 byte master seed, total length: 22 bytes=0APrefix 0x38AE: = 2-factor 32 byte master seed, total length: 38 bytes=0APrefix 0xBECB: 2-fa= ctor 64 byte master seed, total length: 70 bytes=0A=0AThese are constant b= ytes that appear at the beginning of the Base58Check-encoded record, and t= heir presence causes the resulting string to have a predictable prefix.=0A= =0AHow the user sees it: 35, 57 or 101 characters always starting with eit= her "WS" or "ws".=0A=0ACount of payload bytes (beyond prefix): 20, 36 or 6= 8=0A=0APayload format:=0A4 bytes: SHA256(SHA256(master_bitcoin_public_addr= ess))[0...3], used both for typo checking and as salt.=0A16, 32 or 64 byte= s: either a clear representation or an encrypted representation of the mas= ter seed.=0A=0ARange in Base58Check encoding for clear 16 byte master seed= (prefix WS):=0AMinimum value: WSJ5JnjiRZT8b15aZr6GGWzt2VMBPapmhBQ (based = on 0x10 0x93 plus twenty 0x00's)=0AMaximum value: WShQumr1iGdbTpWiesWbb189= p7rSLBiq3EJ (based on 0x10 0x93 plus twenty 0xFF's)=0A=0ARange in Base58Ch= eck encoding for clear 32 byte master seed (prefix WS):=0AMinimum value: W= S7SqjMWhDGCagcZxCk317LLWyWUny7465ENGKEKuxBf5sFvRHmRRfCgr (based on 0x1E 0x= 68 plus thirty-six 0x00's)=0AMaximum value: WSLAbo8WHEQr1Z1cv26Z5njh5URHMo= 9fPiDFYE2NpCwmAoPZwDxzm3PjB (based on 0x1E 0x68 plus thirty-six 0xFF's)=0A= =0ARange in Base58Check encoding for clear 64 byte master seed (prefix WS)= :=0AMinimum value: WS2cMzM9WrogWVLKYFzTaTXZnYCryY31uptmdevXuRFBXTWJhmt4No9= Eejoj3apqyU5RkyXsGHFPbZd14oz7Fv1Mi85kadBD4TPsL (based on 0x66 0x5A plus si= xty-eight 0x00's)=0AMaximum value: WS6PXJ1HoJXn9hyLz8uXQEy2ZajAVaFDTViXhZD= thwYbhyvfHRqjwU4FoGpepCbuuycAwMFbgoZB6E48baqD1c9PdMNUZCSSBmfE7 (based on 0= x66 0x5A plus sixty-eight 0xFF's)=0A=0ARange in Base58Check encoding for 2= -factor 16 byte master seed (prefix ws):=0AMinimum value: ws1nyTi9KjdRkJda= 4Yh1KkXSLC8SZ6kKzEM (based on 0x1E 0xE4 plus twenty 0x00's)=0AMaximum valu= e: wsR8aSpScSotd84i9a7LeEei7pdhVkeciX8 (based on 0x1E 0xE4 plus twenty 0xF= F's)=0A=0ARange in Base58Check encoding for 2-factor 32 byte master seed (= prefix ws):=0AMinimum value: wsC8sayZpTpeX3k6jcCMeTedDapXkXd7SZpRJbSjdeqKB= J2Vnrm1xyfD3 (based on 0x38 0xAE plus thirty-six 0x00's)=0AMaximum value: = wsQrdekZQUyHwv99hRYsj93yn5jLKMfikCoJaWEnXubRGEA9Jnxg5KaPW (based on 0x38 0= xAE plus thirty-six 0xFF's)=0A=0ARange in Base58Check encoding for 2-facto= r 64 byte master seed (prefix ws):=0AMinimum value: ws4XTrriTEyyy2TrGWv9R7= o94CyBiN69S2VxiK5tVW9htEi48w54sQ43JChCmadoGtYpZSu7vqbbQTMemCSyyToyLPPMjugh= cXNxE (based on 0xBE 0xCB plus sixty-eight 0x00's)=0AMaximum value: ws8JdA= Wrjgi5cF6siPqDEuEbqFVVEQJLyhKinDPFJ2T84m8Qib2kS4y4Sji8YCQsDQ5ZjpcrMMuNu7nn= HyJ5j9x1Fcg5iUwvZ7krH (based on 0xBE 0xCB plus sixty-eight 0xFF's)=0A=0AGe= neration of master seed:=0A=0A1. Take either an existing 16, 32 or 64 byte= master seed S, or generate one from a (P)RNG.=0A2. Calculate I =3D HMAC-S= HA512(key =3D "Bitcoin seed", msg =3D S)=0A3. Split I into two 32-byte seq= uences, IL and IR.=0A4. Use IL as master secret key. IR, the master chain = code is not relevant here.=0A5. In case IL is 0 or >=3D N, the master key = is invalid. Go back to step 1 if generating, or in case of a provided mast= er seed, return an error.=0A6. Compute the public key K =3D IL*G=0A7. Calc= ulate the master Bitcoin public address A =3D Base58Check(RIPEMD160(SHA256= (K)))=0A8. Calculate the salt =3D SHA256(SHA256(A))[0...3]=0A=0AEncryption= :=0A=0A9. Derive a hash H from the passphrase using scrypt=0A=C2=A0 =C2=A0= - Parameters: passphrase is the passphrase itself encoded in UTF-8, salt = =3D salt, n =3D 16384, r =3D 8, p =3D 8, length =3D seed length + 32=0A10.= The first number of bytes in H, equal to length of seed S are used to xor= seed S. Call the result X.=0A11. Do AES256Encrypt(message =3D X, key =3D = last 32 bytes of H), call this encrypted_seed.=0A=0A=0AThe encrypted_maste= r_seed is the Base58Check-encoded concatenation of the following, which to= tals 2 + 4 + seed length bytes (22, 38 or 70 bytes):=0A=0Aencrypted_master= _seed =3D prefix + salt + encrypted_seed=0A=0AThe clear version is:=0A=0Am= aster_seed =3D prefix + salt + seed S=0A=0A=0ADecryption:=0A=0A1. Collect = encrypted_master_seed and passphrase from user.=0A2. Perform step 9 of enc= ryption with the passphrase and the salt from the encrypted_master_seed.=0A= 3. With the encrypted_seed from encrypted_master_seed do AES256Decrypt(mes= sage =3D encrypted_seed, key =3D last 32 bytes of H), call this decrypted_= seed.=0A4. With the first number of bytes in H, equal to the length of the= decrypted_seed, perform the xor operation on decrypted_seed and call the = result S.=0A5. Perform generation steps 2 until 8 and verify that the gene= rated salt is equal to the salt from encrypted_master_seed.=0A=0A=0ASugges= tions for implementers of proposal with alt-chains=0A=0AThis proposal invo= lves hashing of a text representation of a public address which for Bitcoi= n includes the leading '1'. Alt-chains can easily be denoted simply by usi= ng the alt-chain's preferred format for representing an address. Alt-chain= implementers may also change the prefix such that encoded master seeds do= not start with "WS" or "ws".=0A=0A=0ABitcoin testnet representation=0A=0A= This proposal does not cover separate Bitcoin testnet representations of e= ncoded master seeds, although since the 4 salt bytes are based on a double= SHA256 of the Bitcoin public address, they will be different for Bitcoin = testnet public addresses and validation will fail.=C2=A0=0A=0A=0AReference= implementation=0A=0ATODO=0A=0A=0ATest vectors=0A=0ATest 1:=0A=0ASeed =C2=A0= =C2=A0 =C2=A0: 000102030405060708090a0b0c0d0e0f=0AClear =C2=A0 =C2=A0 : W= SZsLQ5c1uKrRQugbrZNYsvMhRixiaWaVmJ=0APassword =C2=A0: Satoshi=0AEncrypted = : wsHb15443fYPmneEXskd6wUZeP15fCiA69n=0AAddress =C2=A0 : 15mKKb2eos1hWa6ti= sdPwwDC1a5J1y9nma=0Axprv =C2=A0 =C2=A0 =C2=A0: xprv9s21ZrQH143K3QTDL4LXw2F= 7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33= yuGBxrMPHi=0Axpub =C2=A0 =C2=A0 =C2=A0: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLm= C4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMc= et8=0A=0ATest 2:=0A=0ASeed =C2=A0 =C2=A0 =C2=A0: 7f0ad7d595be13e6fe4cf1fa0= fbb6ae9c26c5d9b09920709414982b6363d5844=0AClear =C2=A0 =C2=A0 : WSB7z3izBZ= wDoaAUA4mDpEHzAZsA5zfTWu3cCxhkaLtZ4Ur6n6mXsgpMK=0APassword =C2=A0: Nakamot= o=0AEncrypted : wsFp1uM2gFhd2PuRzmNFReRud71hgmVwPoc7cGpxuvgETRsv8J1wHNANJ=0A= Address =C2=A0 : 1A54ECavJaJAoLGqqNrPd9Y3cvSvkL2Roz=0Axprv =C2=A0 =C2=A0 =C2= =A0: xprv9s21ZrQH143K3f9hMVvcbY4EX4CfxsEtc6C5BMkZtgGpTGpxAscoq7SLSAcL6k5dx= aZ9s4SChrtfSFoKpijuwAnhuPn76eva6W8bDr118t3=0Axpub =C2=A0 =C2=A0 =C2=A0: xp= ub661MyMwAqRbcG9EATXTcxfzy563ANKxjyK7fykABT1ooL5A6iQw4NukpHShDxYgeso4NHscF= mqcVEtdUt61c8RCf7FqXK9z6sgfkQvYBQPP=0A=0ATest 3:=0A=0ASeed =C2=A0 =C2=A0 =C2= =A0: fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c9= 99693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542=0AClear =C2=A0= =C2=A0 : WS6186bsAkSaGRjRZ1UGyCGigxsXPvnYGSqNHJYmauV9X4W8tLJke1DH8UP8YMsD= LdsjwgodcghjjKqkWQmk3t7qDbNMJVBDKcD2s=0APassword =C2=A0: Vires In Numeris=0A= Encrypted : ws7vDy7RjqMvcPX7GeakKvdK6vDKGhRSjQtaRfKUVQrJXwwetLSeTdNgGzn5BK= ZZqz1BBdaHBFYfLvNUSxDaoP1ojJMMJD9UnQuwt=0AAddress =C2=A0 : 1JEoxevbLLG8cVq= eoGKQiAwoWbNYSUyYjg=0Axprv =C2=A0 =C2=A0 =C2=A0: xprv9s21ZrQH143K31xYSDQpP= DxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2e= mdEXVYsCzC2U=0Axpub =C2=A0 =C2=A0 =C2=A0: xpub661MyMwAqRbcFW31YEwpkMuc5THy= 2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WE= GuduB=0A=0ATest 4:=0A=0ASeed =C2=A0 =C2=A0 =C2=A0: 6ca4a27ac660c683340f593= 53b1375a9=0AClear =C2=A0 =C2=A0 : WSXnfK5CJbDoSwcqMfz7Xqy3avuPHSxDQQk=0APa= ssword =C2=A0: =E8=81=A1=E4=B8=AD=E6=9C=AC=0AEncrypted : wsFWKz3c5eeHRwtJv= eSdFvwUrmoNVkJ5ns2=0AAddress =C2=A0 : 1JVncPbsdB2s4zHim3VdAWNkZ8JANBZ1U9=0A= xprv =C2=A0 =C2=A0 =C2=A0: xprv9s21ZrQH143K3mJ4upPSDfXdA34yNjem6PSsXT63vm8= dq8ikUJv4iiTD3PrSKtdGZXFVD689z5T7knXo55BjcHS2WL3Syp2DbGgnbgxw2QA=0Axpub =C2= =A0 =C2=A0 =C2=A0: xpub661MyMwAqRbcGFNY1qvSaoUMi4uTnCNcTcNUKqVfV6fchw3u1rE= KGWmgtfUMRKLgUHNZ7dfsh8Ys6SLwUojZqScFBQL3dFGF3QywNLJVZ2o=0A=0A=0AAcknowled= gements=0A=0AMike Caldwell for BIP 0038, which this proposal borrows heavi= ly from.=0A=0A=0ASee Also=0A=0ABIP 0032 Hierarchical Deterministic Wallets= : https://en.bitcoin.it/wiki/BIP_0032=0ABIP 0038 Passphrase-protected priv= ate key: https://en.bitcoin.it/wiki/BIP_0038=0A=0A= --Boundary_(ID_6v39sDBKz5LmGaScvSoOlg) Content-type: multipart/related; boundary="Boundary_(ID_1aeWVYtuDr9QTTO/wGdM5Q)"; type="text/html" --Boundary_(ID_1aeWVYtuDr9QTTO/wGdM5Q) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi everyone,

I'm looking for = feedback on the proposal below.

Kind regards,

Jean-Paul

---
BIP= : 
Title: Base58 encoded HD Wallet master seed with optiona= l encryption
Author: Jean-Paul Kogelman
Status: Draft<= /div>
Type: Informational
Created: 17-07-2013

=
Abstract

This proposa= l describes a method for encoding and optionally encrypting a Bitcoin Hier= archical Deterministic (HD) Wallet master seed. Encoded master seeds are i= ntended for use on paper wallets. Each string contains all the information= needed to verify and reconstitute an HD wallet except for the optional pa= ssphrase. The encrypted version uses salting and scrypt to resist brute-fo= rce attacks.

The method provides two encoding met= hodologies in 3 lengths each (16, 32 and 64 byte seeds). One is a clear ve= rsion of the master seed with verification information for integrity check= ing and the other is an encrypted representation.

A 32-bit hash of the resulting master Bitcoin public address is encoded i= n plain text within each seed record, so in the case of an encrypted seed,= it can be correlated to a Bitcoin public address with reasonable probabil= ity by someone not knowing the passphrase. The complete Bitcoin public add= ress can be derived through successful decoding and optional decryption of= the master seed record.


M= otivation

The extended private keys prop= osed in BIP 0032 are long, fixed length records and don't offer any form o= f security. The master seed used to generate the HD wallet is typically sh= orter than the extended master private key that results from it. 

A compact representation of the master seed is easie= r to handle and a 2-factor version of the master seed record allows for sa= fe storage and the creation of paper wallets by 3rd parties. 


Copyright

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

Rationale

User story: As a Bitcoin user who uses HD wallets, I would like th= e ability to store my wallet master seed in a compact form as a paper wall= et.

User story: As a Bitcoin user who uses HD wal= lets, I would like the ability to have a 3rd party create a paper wallet w= ith my master seed in it, without having access to the funds stored in the= wallet.

User story: As a Bitcoin user who uses H= D wallets, I would like the ability to choose the strength of the master s= eed depending on my security requirements and how I wish to store it. = ;


Specification

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

AES256Encrypt, AES256Decrypt: t= he simple form of the well-known AES block cipher without consideration fo= r initialization vectors or block chaining. Each of these functions takes = a 256-bit key and a variable legth of input and deterministically yields o= utput data of similar length to the input.

SHA256= : a well-known hashing algorithm that takes an arbitrary number of bytes a= s input and deterministically yields a 32-byte hash.

<= div>RIPEMD160: a well known hashing algorithm that takes an arbitrary numb= er of bytes as input and deterministically yields a 20-byte hash.

scrypt: A well-known key derivation algorithm. It takes t= he following parameters: (string) password, (string) salt, (int) n, (int) = r, (int) p, (int) length, and deterministically yields an array of bytes w= hose length is equal to the length parameter.

HMA= C-SHA512: Produces a 64 byte (512 bit) hash based message authentication c= ode using the SHA512 hash function using a seed (in our case we will use a= byte representation of "Bitcoin seed") and an aribtrary input message. Th= e output will be 64 bytes.

Base58Check: a method = for encoding arrays of bytes using 58 alphanumeric characters commonly use= d in the Bitcoin ecosystem.

G, N: Constants defin= ed as part of the secp256k1 elliptic curve. G is an elliptic curve point, = and N is a large positive integer.

Prefix

It is= proposed that the resulting Base58Check-encoded string start with either = "WS" for clear master seed records or "ws" for 2-factor master seed record= s. The prefixes "WS" and "ws" were chosen as abreviations of the term "Wal= let Seed" and upper case to indicate whether it's a clear representation a= nd lower case when it's a 2-factor representation. 

To keep the size of the encrypted key equal to the clear version, = no initialization vectors (IVs) are used in the AES encryption. Rather, su= itable values for IV-like use are derived using scrypt from the passphrase= and from using a 32-bit hash of the resulting Bitcoin public address as s= alt.

= Proposed specification

There are 2 seed re= cord representations with 3 lengths each, resulting in a total of 6 differ= ent object identifier prefixes. 

Prefix 0x10= 93: Clear 16 byte master seed, total length: 22 bytes
Prefix 0x1= E68: Clear 32 byte master seed, total length: 38 bytes
Prefix 0x= 665A: Clear 64 byte master seed, total length: 70 bytes

Prefix 0x1EE4: 2-factor 16 byte master seed, total length: 22 bytes=
Prefix 0x38AE: 2-factor 32 byte master seed, total length: 38 b= ytes
Prefix 0xBECB: 2-factor 64 byte master seed, total length: = 70 bytes

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: 35, 57 or 101 characters always starting with eit= her "WS" or "ws".

Count of payload bytes (beyond = prefix): 20, 36 or 68

Payload format:
4= bytes: SHA256(SHA256(master_bitcoin_public_address))[0...3], used both fo= r typo checking and as salt.
16, 32 or 64 bytes: either a clear = representation or an encrypted representation of the master seed.

Range in Base58Check encoding for clear 16 byte master se= ed (prefix WS):
Minimum value: WSJ5JnjiRZT8b15aZr6GGWzt2VMBPapmh= BQ (based on 0x10 0x93 plus twenty 0x00's)
Maximum value: WShQum= r1iGdbTpWiesWbb189p7rSLBiq3EJ (based on 0x10 0x93 plus twenty 0xFF's)

Range in Base58Check encoding for clear 32 byte maste= r seed (prefix WS):
Minimum value: WS7SqjMWhDGCagcZxCk317LLWyWUn= y7465ENGKEKuxBf5sFvRHmRRfCgr (based on 0x1E 0x68 plus thirty-six 0x00's)
Maximum value: WSLAbo8WHEQr1Z1cv26Z5njh5URHMo9fPiDFYE2NpCwmAoPZwD= xzm3PjB (based on 0x1E 0x68 plus thirty-six 0xFF's)

Range in Base58Check encoding for clear 64 byte master seed (prefix WS)= :
Minimum value: WS2cMzM9WrogWVLKYFzTaTXZnYCryY31uptmdevXuRFBXTW= Jhmt4No9Eejoj3apqyU5RkyXsGHFPbZd14oz7Fv1Mi85kadBD4TPsL (based on 0x66 0x5A= plus sixty-eight 0x00's)
Maximum value: WS6PXJ1HoJXn9hyLz8uXQEy= 2ZajAVaFDTViXhZDthwYbhyvfHRqjwU4FoGpepCbuuycAwMFbgoZB6E48baqD1c9PdMNUZCSSB= mfE7 (based on 0x66 0x5A plus sixty-eight 0xFF's)

Range in Base58Check encoding for 2-factor 16 byte master seed (prefix ws= ):
Minimum value: ws1nyTi9KjdRkJda4Yh1KkXSLC8SZ6kKzEM (based on = 0x1E 0xE4 plus twenty 0x00's)
Maximum value: wsR8aSpScSotd84i9a7= LeEei7pdhVkeciX8 (based on 0x1E 0xE4 plus twenty 0xFF's)

Range in Base58Check encoding for 2-factor 32 byte master seed (pr= efix ws):
Minimum value: wsC8sayZpTpeX3k6jcCMeTedDapXkXd7SZpRJbS= jdeqKBJ2Vnrm1xyfD3 (based on 0x38 0xAE plus thirty-six 0x00's)
M= aximum value: wsQrdekZQUyHwv99hRYsj93yn5jLKMfikCoJaWEnXubRGEA9Jnxg5KaPW (b= ased on 0x38 0xAE plus thirty-six 0xFF's)

Range i= n Base58Check encoding for 2-factor 64 byte master seed (prefix ws):
=
Minimum value: ws4XTrriTEyyy2TrGWv9R7o94CyBiN69S2VxiK5tVW9htEi48w54sQ= 43JChCmadoGtYpZSu7vqbbQTMemCSyyToyLPPMjughcXNxE (based on 0xBE 0xCB plus s= ixty-eight 0x00's)
Maximum value: ws8JdAWrjgi5cF6siPqDEuEbqFVVEQ= JLyhKinDPFJ2T84m8Qib2kS4y4Sji8YCQsDQ5ZjpcrMMuNu7nnHyJ5j9x1Fcg5iUwvZ7krH (b= ased on 0xBE 0xCB plus sixty-eight 0xFF's)

Genera= tion of master seed:

1. Take either an existing 1= 6, 32 or 64 byte master seed S, or generate one from a (P)RNG.
2= . Calculate I =3D HMAC-SHA512(key =3D "Bitcoin seed", msg =3D S)
3. Split I into two 32-byte sequences, IL and IR.
4. Use IL as = master secret key. IR, the master chain code is not relevant here.
5. In case IL is 0 or >=3D N, the master key is invalid. Go back to = step 1 if generating, or in case of a provided master seed, return an erro= r.
6. Compute the public key K =3D IL*G
7. Calculate t= he master Bitcoin public address A =3D Base58Check(RIPEMD160(SHA256(K)))
8. Calculate the salt =3D SHA256(SHA256(A))[0...3]

=
Encryption:

9. Derive a hash H from th= e passphrase using scrypt
    - Parameters: passphrase= is the passphrase itself encoded in UTF-8, salt =3D salt, n =3D 16384, r = =3D 8, p =3D 8, length =3D seed length + 32
10. The first number= of bytes in H, equal to length of seed S are used to xor seed S. Call the= result X.
11. Do AES256Encrypt(message =3D X, key =3D last 32 b= ytes of H), call this encrypted_seed.


<= div>The encrypted_master_seed is the Base58Check-encoded concatenation of = the following, which totals 2 + 4 + seed length bytes (22, 38 or 70 bytes)= :

encrypted_master_seed =3D prefix + salt + encry= pted_seed

The clear version is:

master_seed =3D prefix + salt + seed S

Decryption:

1. Collect encrypted_mas= ter_seed and passphrase from user.
2. Perform step 9 of encrypti= on with the passphrase and the salt from the encrypted_master_seed.
<= div>3. With the encrypted_seed from encrypted_master_seed do AES256Decrypt= (message =3D encrypted_seed, key =3D last 32 bytes of H), call this decryp= ted_seed.
4. With the first number of bytes in H, equal to the l= ength of the decrypted_seed, perform the xor operation on decrypted_seed a= nd call the result S.
5. Perform generation steps 2 until 8 and = verify that the generated salt is equal to the salt from encrypted_master_= seed.


Suggestions for impl= ementers of proposal with alt-chains

Thi= s proposal involves hashing of a text representation of a public address w= hich for Bitcoin includes the leading '1'. Alt-chains can easily be denote= d simply by using the alt-chain's preferred format for representing an add= ress. Alt-chain implementers may also change the prefix such that encoded = master seeds do not start with "WS" or "ws".


=
Bitcoin testnet representation

<= /div>
This proposal does not cover separate Bitcoin testnet representa= tions of encoded master seeds, although since the 4 salt bytes are based o= n a double SHA256 of the Bitcoin public address, they will be different fo= r Bitcoin testnet public addresses and validation will fail. 


Reference implementation=

TODO


Test vectors

Test 1:

=
Seed      : 000102030405060708090a0b0c0d0e0f
Clear     : WSZsLQ5c1uKrRQugbrZNYsvMhRixiaWaVmJ
Password  : Satoshi
Encrypted : wsHb15443fYPmneEXskd6wUZeP= 15fCiA69n
Address   : 15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma
xprv      : xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW= 2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
xpub      : xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1= Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<= /div>

Test 2:

Seed   &nbs= p;  : 7f0ad7d595be13e6fe4cf1fa0fbb6ae9c26c5d9b09920709414982b6363d584= 4
Clear     : WSB7z3izBZwDoaAUA4mDpEHzAZsA5zfTWu3cCxhk= aLtZ4Ur6n6mXsgpMK
Password  : Nakamoto
Encrypted = : wsFp1uM2gFhd2PuRzmNFReRud71hgmVwPoc7cGpxuvgETRsv8J1wHNANJ
Addr= ess   : 1A54ECavJaJAoLGqqNrPd9Y3cvSvkL2Roz
xprv   &nbs= p;  : xprv9s21ZrQH143K3f9hMVvcbY4EX4CfxsEtc6C5BMkZtgGpTGpxAscoq7SLSAc= L6k5dxaZ9s4SChrtfSFoKpijuwAnhuPn76eva6W8bDr118t3
xpub   &nb= sp;  : xpub661MyMwAqRbcG9EATXTcxfzy563ANKxjyK7fykABT1ooL5A6iQw4NukpHS= hDxYgeso4NHscFmqcVEtdUt61c8RCf7FqXK9z6sgfkQvYBQPP

Test 3:

Seed      : fffcf9f6f3f0e= deae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817= e7b7875726f6c696663605d5a5754514e4b484542
Clear     : = WS6186bsAkSaGRjRZ1UGyCGigxsXPvnYGSqNHJYmauV9X4W8tLJke1DH8UP8YMsDLdsjwgodcg= hjjKqkWQmk3t7qDbNMJVBDKcD2s
Password  : Vires In Numeris
Encrypted : ws7vDy7RjqMvcPX7GeakKvdK6vDKGhRSjQtaRfKUVQrJXwwetLSeTd= NgGzn5BKZZqz1BBdaHBFYfLvNUSxDaoP1ojJMMJD9UnQuwt
Address   := 1JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg
xprv      : x= prv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM= 8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U
xpub      : = xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6= Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB

Test 4:

Seed      : 6ca4a27ac660c683340f59353= b1375a9
Clear     : WSXnfK5CJbDoSwcqMfz7Xqy3avuPHSxDQQ= k
Password  : =E8=81=A1=E4=B8=AD=E6=9C=AC
Encrypt= ed : wsFWKz3c5eeHRwtJveSdFvwUrmoNVkJ5ns2
Address   : 1JVncP= bsdB2s4zHim3VdAWNkZ8JANBZ1U9
xprv      : xprv9s21= ZrQH143K3mJ4upPSDfXdA34yNjem6PSsXT63vm8dq8ikUJv4iiTD3PrSKtdGZXFVD689z5T7kn= Xo55BjcHS2WL3Syp2DbGgnbgxw2QA
xpub      : xpub661= MyMwAqRbcGFNY1qvSaoUMi4uTnCNcTcNUKqVfV6fchw3u1rEKGWmgtfUMRKLgUHNZ7dfsh8Ys6= SLwUojZqScFBQL3dFGF3QywNLJVZ2o


Acknowledgements

Mike Caldwell for = BIP 0038, which this proposal borrows heavily from.


See Also

BIP 0= 032 Hierarchical Deterministic Wallets: https://en.bitcoin.it/wiki/BIP_003= 2
BIP 0038 Passphrase-protected private key: https://en.bitcoin.= it/wiki/BIP_0038

= --Boundary_(ID_1aeWVYtuDr9QTTO/wGdM5Q)-- --Boundary_(ID_6v39sDBKz5LmGaScvSoOlg)--