Bitcoin has had big problems with wallet security, and eventually converged on the seed phrase system. A seed phrase generates a sequence of key pairs.
This is implemented as the BIP-039 standard.
On the other hand, Warpwallet indicates that with password strengthening, forty eight bits of passphrase security suffices, which if using the BIP-039 system is five words.
For durable storage, write the words on art low acid paper in pencil, and spray with art fixative to prevent the pencil from smudging.
We want to be able to create a receive only wallet, that can sign on with a name controlled by its master wallet, and can receive money that only its master wallet can spend.
In order for it to receive money, it has to be able to generate an indefinitely large number of public keys, that it cannot generate private keys for. It generates a pseudo random sequence, integer hashed with a 128 bit value, and multiplies the public key of the master by that pseudo random number. To spend the money, the master multiplies the private key by that pseudo random number.
Example code for maintaining a tree of deterministically generated keys, which is not exactly what we want, but which is similar.
One evident defect of this system is that leaking a single private key corresponding to the public keys generated by the receive only wallet, plus the information that enables the receive only wallet to generate an unlimited number of receive keys, leaks them all. It might be safer just to give the receive only wallet a great big bundle or receive keys.
A key that owns a name, can sign a statement allowing another key to use that name for some defined time, so the always logged on wallet can operate. If the always logged on wallet gets stolen, it will receive payments for some other key sequence,
so, given a strong secret, we generate two wallets – one of which can receive money, can chat, can assert it rightly has a certain zooko or ro identity, and one of which can spend that money and assert the same identity. Chat includes making conversations and files available, either generally, or two identities that have a key . This implements sale of books by the receive only wallet.
Everyone is converging to BIP0032 BIP0039 wallets
But electrum has some powerful and convincing objections to BIP0039 wallets
You want the wallet to depend only on the secret list of words, not on the wordlist, because the wordlist is likely to change. But you don’t want to let the user construct his own secret capriciously, because he will fuck up, so you need a checksum so that his own custom secret will not work.
So here is my solution: You hash his word list through secret strengthening, but the strengthened secret has to have some zeroes in the right places. Our code for generating the word list generates a hundred or so wordlist till it finds one that works. If the user tries his own master passphrase, probably will not work.
We need to have an explicit standard for generating the wallet from the passphrase, because with bitcoin a seed phrase only works with the same wallet software that created it. If storing for a long period of time, the seed phrase will stop working.
Therefore, need a standard test vector: A wallet must generate this (empty) test wallet with this phrase, which test wallet is authorized to use the name "anon 1". We need to make the construction of a wallet from a test phrase part of the standard, so that future wallet software will give you access to the same account for the same passphrase as past wallet software.
It has to be a standard for wallet software that for a given pass phrase that is valid for the standard wallet, any new wallet software shall give you access to the same accounts, and a test vector for this has to be part of the system from the beginning, giving a sequence of wallets authorized to use the names anonymous_1 anonymous_2, and anonymous_3
coinb.in is the client wallet for bitcoin. Before I roll my own, I need to understand what they are doing and why they are doing it.
This document is licensed under the CreativeCommons Attribution-Share Alike 3.0 License