mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-23 15:18:11 +00:00
wallets, non-deterministic, seeds, bip0039, vanity addresses
This commit is contained in:
parent
691c759ba8
commit
656e60caeb
101
ch04.asciidoc
101
ch04.asciidoc
@ -376,8 +376,7 @@ Here's the same key, encoded in WIF and WIF-compressed formats
|
||||
|
||||
==== Wallets
|
||||
|
||||
Wallets are containers for private keys, usually implemented as structured files or simple databases. In the first implementations of bitcoin clients, wallets were simply collections of randomly generated private keys. For example, the Bitcoin Core Client pre-generates 100 random private keys when first started and generates more keys as needed, trying to use each key only once. The disadvantage of random keys is that if you generate many of them you must keep copies of all of them, meaning that the wallet must be backed-up frequently. Each key must be backed-up, or the funds it controls are irrevocably lost.
|
||||
|
||||
Wallets are containers for private keys, usually implemented as structured files or simple databases.
|
||||
Another method for making keys is _deterministic key generation_. Here you derive each new private key, using a one-way hash function from a previous private key, linking them in a sequence. As long as you can re-create that sequence, you only need the first key (known as a _seed_ or _master_ key) to generate them all. In this section we will examine the different methods of key generation and the wallet structures that are built around them.
|
||||
|
||||
[TIP]
|
||||
@ -387,15 +386,59 @@ Wallets contain keys, not coins. The coins are stored on the blockchain in the f
|
||||
|
||||
===== Non-Deterministic (Random) Wallets
|
||||
|
||||
In the first implementations of bitcoin clients, wallets were simply collections of randomly generated private keys. For example, the Bitcoin Core Client pre-generates 100 random private keys when first started and generates more keys as needed, trying to use each key only once. This type of wallet is nicknamed "Just a Bunch Of Keys" or JBOK and such wallets are being replaced with deterministic wallets because they are cumbersome to manage, backup and import. The disadvantage of random keys is that if you generate many of them you must keep copies of all of them, meaning that the wallet must be backed-up frequently. Each key must be backed-up, or the funds it controls are irrevocably lost. This conflicts directly with the principle of avoiding address re-use, by using each bitcoin address for only one transaction. Address re-use reduces privacy by associating multiple transactions and addresses with each other. A Type-0 wallet is a poor choice of wallet, especially if you want to avoid address re-use as that means managing many keys, which creates the need for very frequent backups. The Bitcoin Core Client includes a wallet that is implemented as a Type-0 wallet, but the use of this wallet is actively discouraged by the Bitcoin Core developers
|
||||
|
||||
[[Type0_wallet]]
|
||||
.Type-0 Non-Deterministic (Random) Wallet: A Collection of Randomly Generated Keys
|
||||
image::images/non-deterministic_wallet.png["non-deterministic wallet"]
|
||||
|
||||
This most basic form of key generation generates what are known as _Type-0_ or _Non-Deterministic_ (i.e. random) keys. When a sequence of keys is generated for a single user's wallet, each key is randomly generated when needed.
|
||||
|
||||
===== Deterministic (Seeded)
|
||||
|
||||
===== Seed Words (BIP0039)
|
||||
Deterministic, or "seeded" wallets are wallets that contain private keys which are all derived from a common seed, through the use of a one-way hash function. The seed is a randomly generated number which is combined with other data, such as an index number or "chain code" (see <<hd_wallets>>) to derive the private keys. In a deterministic wallet, the seed is sufficient to recover all the derived keys and therefore a single backup at creation time is sufficient. The seed is also sufficient for a wallet export or import, allowing for easy migration of all the user's keys between different wallet implementations.
|
||||
|
||||
===== Mnemonic Code Words (BIP0039)
|
||||
|
||||
Mnemonic codes are english word sequences that are generated from a random sequence and used to produce a seed for use in deterministic wallets. The sequence of words is sufficient to re-create the seed and from there re-create the wallet and all the derived keys. A wallet application that implements deterministic wallets with mnemonic code, will show the user a sequence of 12-24 words when first creating a wallet. That sequence of words is the wallet backup and can be used to recover and re-create all the keys, in the same or any compatible wallet application.
|
||||
|
||||
The common standard for mnemonic codes is defined in Bitcoin Improvement Proposal 39 (see <<bip0039>>), currently in Draft status.
|
||||
|
||||
The standard defines the creation of a mnemonic code and seed as a follows:
|
||||
|
||||
1. Create a random sequence (entropy) of 128 to 256 bits
|
||||
2. Create a checksum of the random sequence by taking the first few bits of it's SHA256 hash
|
||||
3. Add the checksum to the end of the random sequence
|
||||
4. Divide the sequence into sections of 11 bits, using those to index a dictionary of 2048 pre-defined words.
|
||||
5. Produce 12-24 words representing the mnemonic code.
|
||||
|
||||
.Mnemonic Codes: Entropy and Word Length
|
||||
[options="header"]
|
||||
|=======
|
||||
|Entropy (bits) | Checksum (bits) | Word Length
|
||||
| 128 | 4 | 132 | 12
|
||||
| 160 | 5 | 165 | 15
|
||||
| 192 | 6 | 198 | 18
|
||||
| 224 | 7 | 231 | 21
|
||||
| 256 | 8 | 264 | 24
|
||||
|=======
|
||||
|
||||
The mnemonic code represents 128 to 256 bits which are used to derive a longer seed (512 bits), through the use of the key-stretching function PBKDF2. The resulting seed is used to create a deterministic wallet and all of its derived keys.
|
||||
|
||||
Here are some examples of mnemonic codes and the seeds they produce:
|
||||
|
||||
.128-bit entropy mnemonic code and resulting seed
|
||||
|=======
|
||||
| entropy input (128 bits) | 0c1e24e5917779d297e14d45f14e1a1a
|
||||
| mnemonic (12 words) | army van defense carry jealous true garbage claim echo media make crunch
|
||||
| seed (512 bits) | 3338a6d2ee71c7f28eb5b882159634cd46a898463e9d2d0980f8e80dfbba5b0fa0291e5fb888a599b44b93187be6ee3ab5fd3ead7dd646341b2cdb8d08d13bf7
|
||||
|=======
|
||||
|
||||
|
||||
.256-bit entropy mnemonic code and resulting seed
|
||||
|=======
|
||||
| entropy input (256 bits) | 2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c (256 bits)
|
||||
| mnemonic (24 words) | cake apple borrow silk endorse fitness top denial coil riot stay wolf luggage oxygen faint major edit measure invite love trap field dilemma oblige (24 words)
|
||||
| seed (512 bits) | 3972e432e99040f75ebe13a660110c3e29d131a2c808c7ee5f1631d0a977fcf473bee22fce540af281bf7cdeade0dd2c1c795bd02f1e4049e205a0158906c343 (512 bits)
|
||||
|=======
|
||||
|
||||
===== Deterministic Chains (Electrum Key Chains)
|
||||
|
||||
@ -403,6 +446,7 @@ This most basic form of key generation generates what are known as _Type-0_ or _
|
||||
.Type-1 Deterministic Wallet: A Chain of Keys Generated from a Seed
|
||||
image::images/chained_wallet.png["chained wallet"]
|
||||
|
||||
[[hd_wallets]]
|
||||
===== Deterministic Trees (BIP0032)
|
||||
|
||||
[[Type2_wallet]]
|
||||
@ -426,6 +470,53 @@ image::images/HD_wallet.png["HD wallet"]
|
||||
|
||||
===== Vanity Addresses
|
||||
|
||||
Vanity addresses are valid bitcoin addresses that contain human-readable messages, for example 1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33 is a valid address that contains the letters forming the word "Love" as the first four Base-58 letters. Vanity addresses require generating and testing billions of candidate private keys, until one derives a bitcoin address with the desired pattern. While there are some optimizations in the vanity generation algorithm, the process essentially involves picking a private key at random, deriving the public key, deriving the bitcoin address and checking to see if it matches the desired vanity pattern, repeating billions of times until a match is found.
|
||||
|
||||
Once a vanity address matching the desired pattern is found, the private key from which it was derived can be used by the owner to spend bitcoins in exactly the same way as any other address. Vanity addresses are no less or more secure that any other address, they depend on the same Elliptic Curve Cryptography (ECC) and Secure Hash Algorithm (SHA) as any other address. You can no more find the private key of an address starting with a vanity pattern than you can any other address.
|
||||
|
||||
In our first chapter, we introduced Eugenio, a children's charity director operating in the Philippines. Let's say that Eugenio is organizing a bitcoin fundraising drive and wants to use a vanity bitcoin address to publicize the fundraising. Eugenio will create a vanity address that starts with "1Kids", to promote the children's charity fundraiser. Let's see how this vanity address will be created and what it means for the security of Eugenio's charity.
|
||||
|
||||
====== Generating Vanity Addresses
|
||||
|
||||
It's important to realize the a bitcoin address is simply a number represented by symbols in the Base-58 alphabet. The search for a pattern like "1Kids" can be seen as searching for an address in the range from "1Kids11111111111111111111111111111" to "1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz". There are approximately 58^31^ (approximately 4.6 * 10^54^) addresses in that range, all starting with "1Kids".
|
||||
|
||||
.The range of vanity addresses starting with "1Kids"
|
||||
|=======
|
||||
| From | 1Kids11111111111111111111111111111
|
||||
| To | 1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz
|
||||
|=======
|
||||
|
||||
Let's look at the pattern "1Kids" as a number and see how frequently we might find this pattern in a bitcoin address. An average desktop computer PC, without any specialized hardware, can search approximately 100,000 keys per second.
|
||||
|
||||
.The frequency of a vanity pattern (1KidsCharity) and average time-to-find on a desktop PC
|
||||
[options="header"]
|
||||
|=======
|
||||
| Length | Pattern | Frequency | Average Search Time
|
||||
| 1 | 1K | 1 in 58 keys | < 1 msec
|
||||
| 2 | 1Ki| 1 in 3,364 | 50 msec
|
||||
| 3 | 1Kid | 1 in 195k | < 2 seconds
|
||||
| 4 | 1Kids | 1 in 11m | 1 minute
|
||||
| 5 | 1KidsC | 1 in 656m | 1 hour
|
||||
| 6 | 1KidsCh | 1 in 38bn | 2 days
|
||||
| 7 | 1KidsCha | 1 in 2.2tn | 3-4 months
|
||||
| 8 | 1KidsChar | 1 in 128tn | 13-18 years
|
||||
| 9 | 1KidsChari | 1 in 7qn | > 800 years
|
||||
| 10 | 1KidsCharit | 1 in 400qdn | > 46,000 years
|
||||
| 11 | 1KidsCharity | 1 in 23qnt | > 2.5m years
|
||||
|
||||
|
||||
As you can see, Eugenio won't be creating the vanity address "1KidsCharity" any time soon, even if he had access to several thousand computers. Each additional character increases the difficulty by a factor of 58. Patterns with more than seven characters are usually found by specialized hardware, such as custom-built desktops with multiple Graphical Processing Units (GPUs). These are often re-purposed bitcoin mining "rigs", that are no longer profitable for bitcoin mining, but can be used effectively to find vanity addresses. Vanity searches on GPU systems are many orders of magnitude faster than on a general-purpose CPU.
|
||||
|
||||
Another way to find a vanity address is to outsource the work to a pool of vanity-miners, such as the pool at vanitypool.appspot.com. A pool is a service that allows those with GPU hardware to earn bitcoin searching for vanity addresses for others. For a small payment (0.01 bitcoin or approximately $5 when this was written), Eugenio can outsource the search for a 7-character pattern vanity address and get results in a few hours, instead of having to run a CPU search for months.
|
||||
|
||||
====== Vanity Address Security
|
||||
|
||||
Vanity addresses can be used to enhance _and_ to defeat security measures, they are truly a double-edged sword. Used to improve security, a distinctive address makes it harder for adversaries to substitute their own address and fool your customers into paying them instead of you. Unfortunately, vanity addresses also make it possible for anyone to create an address that _resembles_ any random address, or even another vanity address, thereby fooling your customers.
|
||||
|
||||
He could advertise a randomly generated address (e.g. 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy) to which people to send their donations. Or, Eugenio could generate a vanity address that starts with 1Kids, to make it more distinctive.
|
||||
|
||||
In both cases, one of the risks of using a single fixed address (rather than a separate dynamic address per donor) is that a thief might be able to infiltrate your website and replace it with their own address, thereby diverting donations to themselves. If you have advertised your donation address in a number of different places, your users may visually inspect the address before making a payment to ensure it is the same one they saw on your website, on your email, and on your flyer. In the case of a random address like "1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy", the average user will inspect the first few characters "1J7mdg" perhaps and be satisfied that the address matches. So does a vanity address increase security? If Eugenio generates the vanity address "1Kids33q44erFfpeXrmDSz7zEqG2FesZEN"
|
||||
|
||||
|
||||
==== Key Storage
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user