Recoverable brain wallet.

[nathan-at-least]

Needs to track all information needed to generate a Pour transaction.

Edit 2015-08-24 We decided that #31 is a duplicate of this ticket.

Edit 2017-01-24 This ticket means different things to different people and thus needs to be split out into specific tickets:

• Recovery Secret Seed #2038 - feature to recover everything important from a static secret seed.
• #2039 - mnemonic entropy encoding (a la BIP39).
• Allow users to pick their own weak passwords for deterministic secret seeds. (strawman) #2040 - "Allow users to pick their own weak passwords for deterministic secret seeds. (strawman)"

[zookoatleastauthoritycom]

There's a design trade-off about which secrets are stored explicitly in local storage and which are recovered by scanning the blockchain for transactions encrypted to your public key. A related part of that trade-off is whether you ''always'' recover those secrets by scanning the blockchain, on process startup, or whether you do so only in the case that your local storage has been lost or corrupted.

I have strong opinions about these things… I believe that the starting position should be that as many secrets as possible are stored exclusively in the encrypted transactions in the block, and are recovered by scan-and-decrypt at process startup. This is because of the crash-only design and the Don't Repeat Yourself principle.

[tromer]

I suggest the following criterion: if you have printed out your address private key, then this data (which is immutable and transaction independent), together with the public data in the blockchain, should suffice to recognize and pour all coins you own. Any additional information you keep is merely for improved performance.

[matthewdgreen]

I have a particular hankering for a brainwallet. As a technical matter this should be pretty easy once we get the main functionality in place. The password would be used to derive a decryption key, then the client can simply scan the block chain for matching transactions. We need this functionality anyway.

[daira]

I agree with @tromer . We therefore need to change Mint transactions to include the "coin encrypted to self" field: #32

[mikeperry-tor]

Additionally, during the hackfest we discussed having the sender store encrypted POUR tuples (a_pk, v_i, p_i, r_i, s_i) and (v_i, k_i, s_i) in the transaction on the Zerocash blockchain, encrypted to two different keys. When these keys come from a single KDF, this allows a user to extract their full sent payment history (including destinations) or just their balance history using a single wallet seed. Without adding these tuples on the blockchain, this data is not possible to recover in the current Zerocash scheme with just a single seed. See https://github.com/Electric-Coin-Company/design-docs/blob/master/20141119-ZECC-meeting-notes.txt#L219 ("Send direction") for the notes from that discussion.

Also see https://github.com/Electric-Coin-Company/design-docs/blob/master/20141119-ZECC-meeting-notes.txt#L433 (section "Key management") for notes on one way to construct such a KDF that still allows people to opt out of certain portions of record retention, as well as to prune the historical data that they are capable of decrypting, by changing the form of wallet seed they retain.

[tromer]

See also Bitcoin's hierarchical deterministic (HD) wallets, which create a stream of fresh keypairs associated with the wallet's master key, for privacy. Since derivation is deterministic, wallet backups need only contain the master key.

The primary spec for this is BIP39 (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). There's also Electrum and the related BIP42 (https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki).

See overviews at https://en.bitcoin.it/wiki/Deterministic_wallet and https://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/ .

Such wallets have a nice feature: beside the "master private key" that allows spending transactions associated with the wallet's derived keys, each such wallet also have a "master public key" which allows derivation just of the derived public keys (thus giving a peek into the wallet's transactions and balance and giving up privacy) but does not give the ability to spend the coins. Zerocash was not designed to have such "reveal but don't allow spending" keys (individual transactions can be revealed, but not all transactions past and future associated with a Zerocash address). It would be good to add this feature (it might already exist implicitly...) and define+prove its properties. (Separate ticket?)

On related note, BIP39 describes the implementation of a mnemonic code or mnemonic sentence -- a group of easy to remember words -- for the generation of deterministic wallets. (https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)

[nathan-at-least]

I am also a fan of @tromer's suggested "stateless wallet" property, for two reasons: one is usability - I want to know the paper printout in my safety deposit box is still a fully valid backup even if I continue to use a copy on a live wallet which is busily sending/receiving coins.

The other is an engineering benefit: a minimum-viable wallet is now a much simpler stateless thing with no caching optimizations. It naively scans the blockchain on demand for a given operation. While this may not be "viable" in terms of usability or user adoption, it's viable in terms of providing correct functionality without state-management complexity. It can be released early and the state tracking optimizations can evolve in future releases.

Suppose there is a bug in wallet state tracking code. If this state tracking is required for coin validity, such a bug may destroy a user's currency units. If, OTOH, the bug exists in state tracking which is merely an optimization, the user's currency is safe in the blockchain, and they must simply patch their wallet and move aside their corrupted local cache. The same reasoning applies to corruption from non-bug disasters.

[daira]

Yes, that is why #32 is one of my highest priorities. I'd love to start working on features and enhancements, but I feel that's pretty much blocked on getting the build and testing working (#58, #71, #78).

[zookoatleastauthoritycom]

@imichaelmiers Please read!

[nathan-at-least]

Let's make sure that we capture the features of any secret-state managment design in the use case document #72 (which does not yet exist, leave comments on #72).

[nathan-at-least]

@tromer's #410 (comment) is a fundamental question which should be explicitly answered for this ticket, quoted here (in response to a comment by @jcb82):

it would require people to keep old parameters around that they should reasonably delete for forward security

Actually, our brain wallet functionality (Issue #18) is already pretty close to this. The difference is that it only lets you recover coins, whereas recomputing the SNARK proofss may need some additional "provenance" information. We need to make a conscious decision about which we want, and ensure that the provenance information is either deleted (forward security) or recoverable (recomputable SNARKs).

[daira]

Wait, forward security vs recoverability of buckets sent to an address is not a system-wide choice. Holders of private spend-authority keys (a_sk) and receive-authority keys (sk_enc) independently get to decide when and under what conditions to delete each key or move it to less-accessible storage.

[ryancdotorg]

If you do anything on this, I urge you to provide randomly generated mnemonics, and implement it in such a way that it's difficult for anyone to make up their own. Including an extra word or two as checksum, for example.

[ebfull]

There is already a standard for mnemonics for passphrases which meets that goal: https://raw.githubusercontent.com/bitcoin/bips/master/bip-0039.mediawiki

Lots of people (myself included) use this for their cryptocurrencies, including Zcash! It's a well-thought-out and well-supported standard. I've never seen a usability or security complaint about it.

[nathan-at-least]

I'm on the hook to split this up into distinct tickets. I started by adding #2038 to split out stateless recovery.

[nathan-at-least]

I'm closing this ticket because I believe the three breakout tickets in the updated description cover the main conflated proposals in this thread. If I missed something, let me know and I can add more sub-tickets.