arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-12-23 07:08:13 +00:00
Code Issues Releases Wiki Activity

CH05: add section about backing up non-key data

Browse Source 
An often-overlooked backup concern among both wallet developers and
users is labels, which can't be restored from an HD seed.  Also,
wallets for LN and other contract protocols may have additional data
they need to recover all funds.  Mention these concerns and describe the
method used by several wallets (including LND) of encrypting wallet data
to one of the wallet's BIP32-derived keys.
This commit is contained in:
David A. Harding 2023-02-15 22:26:49 -10:00
parent 184ff4d73b
commit a69a1246f1
1 changed files with 78 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

79
ch05.asciidoc
View File

@ -390,7 +390,84 @@ duress. We suspect the debate will continue for as long as recovery
codes continue to be widely used.
****
FIXME:label export
==== Backing Up Non-Key Data
The most important data in a wallet database is its private keys. If
you lose access to the private keys, you lose the ability to spend your
bitcoins. Deterministic key derivation and recovery codes provide a
reasonably robust solution for backing up and recovering your keys and
the bitcoins they control. But many wallet databases store more than
just keys. They also also store user-provided information about every
transaction they sent or received.
For example, when Bob creates a new address as part of sending an
invoice to Alice, he adds a _label_ in to the address he generates
so that he can distinguish her payment
from other payments he receives. When Alice pays Bob's address, she
labels the transaction as paying Bob for the same reason. Some wallets
also add other useful information to transactions, such as the current
exchange rate, which can be useful for calculating taxes in some
jurisdictions. These labels are stored entirely within their own
wallets--not shared with the network--protecting their privacy
and keeping unnecessary personal data out of the blockchain.
.Alice's transaction history with each transaction labeled
[cols="1,1,1"]
|===
| Date | Label | BTC
| 2023-01-01 | Bought bitcoins from Joe | +0.0010
| 2023-01-02 | Paid Joe for podcast | -0.0075
|===
However, because address and transaction labels are stored only in each
user's wallet database and because they aren't deterministic, they can't
be restored by using just a recovery code. If the only recovery is
seed-based, then all the user will see is a list of approximate
transaction times and bitcoin amounts. This can make it quite difficult
to figure out how you used your money in the past. Imagine reviewing a
bank or credit card statement from a year ago that had the date and
amount of every transaction listed but a blank entry for the
"description" field.
Wallets should provide their users with a convenient way to back up
label data. That seems obvious, but there are a number of
widely used wallet applications that make it easy to create and use
recovery codes but which provide no way to back up or restore label
data.
Additionally, it may be useful for wallets applications to provide a
standardized format to export labels so that they can be used in other
applications, e.g. accounting software. A standard for that format is
proposed in BIP329.
Wallet applications implementing additional protocols beyond basic
Bitcoin support may also need or want to store other data. For example,
as of 2023, an increasing number of applications have added support for
sending and receiving transactions over the Lightning Network (LN).
Although the LN protocol provides a method to recover
funds in the event of a data loss, called _static channel backups_, it
can't guarantee results. If the node your wallet connects to realizes
you've lost data, it may be able to steal bitcoins from you. If it
loses its wallet database at the same time you lose your database, and
neither of you has an adequate backup, you'll both lose funds.
Again, this means users and wallet applications need to do more than just back up a
recovery code.
One solution implemented by a few wallet applications is to frequently
and automatically create complete backups of their wallet database
encrypted by one of the keys derived from their seed. Bitcoin keys must
be unguessable and modern encryption algorithms are considered very
secure, so nobody should be able to open the encrypted backup except
someone who can generate the seed, making it safe to store the backup on
untrusted computers such as cloud hosting services or even random
network peers.
Later, if the original wallet database is lost, the user can enter their
recovery code into the wallet application to restore their seed. The
application can then retrieve the latest backup file, regenerate the
encryption key, decrypt the backup, and restore all of the user's labels
and additional protocol data.
==== Wallet Best Practices