You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: devguide/wallets.rst
+9-7Lines changed: 9 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -1,3 +1,5 @@
1
+
.. _dev-wallets-header:
2
+
1
3
Wallets
2
4
=======
3
5
@@ -15,7 +17,7 @@ Wallet Programs
15
17
16
18
Permitting receiving and spending of satoshis is the only essential feature of wallet software—but a particular wallet program doesn’t need to do both things. Two wallet programs can work together, one program distributing public keys in order to receive satoshis and another program signing transactions spending those satoshis.
17
19
18
-
Wallet programs also need to interact with the `peer-to-peer network<../devguide/p2p_network.html>`__ to get information from the block chain and to broadcast new transactions. However, the programs which distribute public keys or sign transactions don’t need to interact with the `peer-to-peer network<../devguide/p2p_network.html>`__ themselves.
20
+
Wallet programs also need to interact with the |peer-to-peer network| to get information from the block chain and to broadcast new transactions. However, the programs which distribute public keys or sign transactions don’t need to interact with the |peer-to-peer network| themselves.
19
21
20
22
This leaves us with three necessary, but separable, parts of a wallet system: a public key distribution program, a signing program, and a networked program. In the subsections below, we will describe common combinations of these parts.
21
23
@@ -42,7 +44,7 @@ To help protect against theft, many wallet programs offer users the option of en
42
44
Signing-Only Wallets
43
45
~~~~~~~~~~~~~~~~~~~~
44
46
45
-
To increase security, private keys can be generated and stored by a separate wallet program operating in a more secure environment. These signing-only wallets work in conjunction with a networked wallet which interacts with the `peer-to-peer network<../devguide/p2p_network.html>`__.
47
+
To increase security, private keys can be generated and stored by a separate wallet program operating in a more secure environment. These signing-only wallets work in conjunction with a networked wallet which interacts with the |peer-to-peer network|.
46
48
47
49
Signing-only wallets programs typically use deterministic key creation (described in a later subsection) to create parent private and public keys which can create child private and public keys.
48
50
@@ -59,7 +61,7 @@ Often, users are given a chance to review the unsigned transactions’ details (
59
61
60
62
After the optional review step, the signing-only wallet uses the parent private key to derive the appropriate child private keys and signs the transactions, giving the signed transactions back to the networked wallet.
61
63
62
-
The networked wallet then broadcasts the signed transactions to the `peer-to-peer network<../devguide/p2p_network.html>`__.
64
+
The networked wallet then broadcasts the signed transactions to the |peer-to-peer network|.
63
65
64
66
The following subsections describe the two most common variants of signing-only wallets: offline wallets and hardware wallets.
65
67
@@ -70,13 +72,13 @@ Several full-service wallets programs will also operate as two separate wallets:
70
72
71
73
The offline wallet is so named because it is intended to be run on a device which does not connect to any |network|, greatly reducing the number of attack vectors. If this is the case, it is usually up to the user to handle all data transfer using removable media such as USB drives. The user’s workflow is something like:
72
74
73
-
1. (Offline) Disable all |network| connections on a device and install the wallet software. Start the wallet software in offline mode to create the parent private and public keys. Copy the parent public key to removable media.
75
+
1. (Offline) Disable all network connections on a device and install the wallet software. Start the wallet software in offline mode to create the parent private and public keys. Copy the parent public key to removable media.
74
76
75
77
2. (Online) Install the wallet software on another device, this one connected to the Internet, and import the parent public key from the removable media. As you would with a full-service wallet, distribute public keys to receive payment. When ready to spend satoshis, fill in the output details and save the unsigned transaction generated by the wallet to removable media.
76
78
77
79
3. (Offline) Open the unsigned transaction in the offline instance, review the output details to make sure they spend the correct amount to the correct address. This prevents malware on the online wallet from tricking the user into signing a transaction which pays an attacker. After review, sign the transaction and save it to removable media.
78
80
79
-
4. (Online) Open the signed transaction in the online instance so it can broadcast it to the `peer-to-peer network<../devguide/p2p_network.html>`__.
81
+
4. (Online) Open the signed transaction in the online instance so it can broadcast it to the |peer-to-peer network|.
80
82
81
83
The primary advantage of offline wallets is their possibility for greatly improved security over full-service wallets. As long as the offline wallet is not compromised (or flawed) and the user reviews all outgoing transactions before signing, the user’s satoshis are safe even if the online wallet is compromised.
82
84
@@ -115,7 +117,7 @@ Wallet programs which run in difficult-to-secure environments, such as webserver
115
117
116
118
- Use a parent public key to create child public keys. To avoid key reuse, a method must be used to ensure the same public key isn’t distributed twice. This can be a database entry for each key distributed or an incrementing pointer to the :term:`key index` number.
117
119
118
-
Neither method adds a significant amount of overhead, especially if a database is used anyway to associate each incoming payment with a separate public key for payment tracking. See the `Payment Processing <../devguide/payment_processing.html>`__ section for details.
120
+
Neither method adds a significant amount of overhead, especially if a database is used anyway to associate each incoming payment with a separate public key for payment tracking. See the :ref:`dev-payment-processing-header` section for details.
119
121
120
122
Wallet Files
121
123
------------
@@ -132,7 +134,7 @@ Private keys are what are used to unlock satoshis from a particular address. In
132
134
Wallet Import Format (WIF)
133
135
^^^^^^^^^^^^^^^^^^^^^^^^^^
134
136
135
-
In order to make copying of private keys less prone to error, :term:`Wallet Import Format` may be utilized. WIF uses base58Check encoding on a private key, greatly decreasing the chance of copying error, much like standard Bitcoin addresses.
137
+
In order to make copying of private keys less prone to error, :term:`Wallet Import Format` may be utilized. WIF uses :term:`base58Check` encoding on a private key, greatly decreasing the chance of copying error, much like standard Bitcoin addresses.
0 commit comments