arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2025-02-18 10:32:05 +00:00
Code Issues Releases Wiki Activity

Made changes to ch04.asciidoc

Browse Source
This commit is contained in:
drusselloctal@gmail.com 2014-10-30 11:59:19 -07:00
parent 5881ffbb04
commit 416806c706
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ch04.asciidoc
View File

@ -777,9 +777,9 @@ On the fourth level, "change," an HD wallet has two subtrees, one for creating r
| m/44'/2'/0'/0/1 | The second private key in the Litecoin main account, for signing transactions | m/44'/2'/0'/0/1 | The second private key in the Litecoin main account, for signing transactions
|======= |=======
===== Experimenting with HD wallets using sx-tools ===== Experimenting with HD wallets using sx tools
Using the command line tool +sx+, introduced in <<ch03_bitcoin_client>>, you can experiment with generating and extending BIP0032 deterministic keys, as well as displaying them in different formats: Using the command-line tool +sx+, introduced in <<ch03_bitcoin_client>>, you can experiment with generating and extending BIP0032 deterministic keys, as well as displaying them in different formats:
==== ====
[source, bash] [source, bash]
@ -806,6 +806,8 @@ yUeAkRPe1kLR1P6Mn7jUrXFquUt
=== Advanced Keys and Addresses === Advanced Keys and Addresses
In the following sections we will look at advanced forms of keys and addresses, such as encrypted private keys, script and multi-signature addresses, vanity addresses, and paper wallets.
==== Encrypted Private Keys (BIP0038) ==== Encrypted Private Keys (BIP0038)
Private keys must remain secret. The need for _confidentiality_ of the private keys is a truism which is quite difficult to achieve in practice, as it conflicts with the equally important security objective of _availability_. Keeping the private key private is much harder when you need to store backups of the private key to avoid losing it. A private key stored in a wallet that is encrypted by a password may be secure, but that wallet needs to be backed up. At times, users need to move keys from one wallet to another -- to upgrade or replace the wallet software, for example. Private key backups might also be stored on paper (see <<paper_wallets>>) or on external storage media, such as a USB flash drive. But what if the backup itself is stolen or lost? These conflicting security goals led to the introduction of a portable and convenient standard for encrypting private keys in a way that can be understood by many different wallets and bitcoin clients, standardized by Bitcoin Improvement Proposal 38 or BIP0038 (see <<bip0038>>). Private keys must remain secret. The need for _confidentiality_ of the private keys is a truism which is quite difficult to achieve in practice, as it conflicts with the equally important security objective of _availability_. Keeping the private key private is much harder when you need to store backups of the private key to avoid losing it. A private key stored in a wallet that is encrypted by a password may be secure, but that wallet needs to be backed up. At times, users need to move keys from one wallet to another -- to upgrade or replace the wallet software, for example. Private key backups might also be stored on paper (see <<paper_wallets>>) or on external storage media, such as a USB flash drive. But what if the backup itself is stolen or lost? These conflicting security goals led to the introduction of a portable and convenient standard for encrypting private keys in a way that can be understood by many different wallets and bitcoin clients, standardized by Bitcoin Improvement Proposal 38 or BIP0038 (see <<bip0038>>).