This change allows for the use of watching-only wallets. Unlike
normal, "hot" wallets, watching-only wallets do not contain any
private keys, and can be used in situations where you want to keep one
wallet online to create new receiving addresses and watch for received
transactions, while keeping the hot wallet offline (possibly on an
air-gapped computer).
Two (websocket) extension RPC calls have been added:
First, exportwatchingwallet, which will export the current hot wallet
to a watching-only wallet, saving either to disk or returning the
base64-encoded wallet files to the caller.
Second, recoveraddresses, which is used to recover the next n
addresses from the address chain. This is used to "sync" a watching
wallet with the hot wallet, or vice versa.
This adds some missing bookkeeping which broke rescans for the root
addresses of newly created wallets (not wallets read from disk) by
marking all active addresses (which would be just the root address) as
belonging to the account with a some particular name.
While here, return an error to the caller rather than just logging the
error if the newly-created wallet cannot be immediatelly written to
disk.
The exported watching wallet would include all imported addresses'
chain indexes added to the chain index map. Imported addresses are
special as they do not belong to the address chain, and this would
cause issues when serializing the wallet.
This adds a new function, ExtendActiveAddresses, to extend the number
of active addresses, generated by the address chain, by any arbitrary
positive number. This will be used for recovering wallet addresses
from a wallet backup, as well as getting the next as many addresses as
required to keep a watching wallet in sync with an original wallet
with the private keys, or sync an original wallet with new addresses
generated by the watching wallet.
This change introduces a new function to export a wallet in memory to
a watching wallet. Watching wallets allow to watch for balance
changes and transactions to wallet addresses while only storing the
public parts of a wallet (no private keys). New addresses created by
the watching wallet will use pubkey address chaining and will allow to
receive funds to an indefinite number of new addresses, and create the
private keys for said addresses from the non-watching wallet later.
The actual exporting of a watching wallet to a file (triggered by an
RPC request) is not yet implemented.
While here, fix an issue found by new test code for the chained
address code which incorrectly set the starting index of addresses in
the chain needing private keys to be created.
Strings are immutable, so instead of copying as a new variable (like
how was needed when receiving byte slices), just pass the marshaled
JSON string to the notification processing code.
This change adds a check for a valid (32-byte length) secret before
attempting to encrypt or decrypt any addresses. If the check fails, a
meaningful error (ErrWalletLocked) is returned to the caller, rather
than an error out of the aes package.
This function was not implemented (returning zero values) and all
versioning is handled internally by the wallet's ReadFrom and WriteTo
functions. If the read wallet does not match the latest file version,
it is read in the old format, but always written back with the new
format.
The wallet package was using a sync.Mutex around the saved decryption
key (kept in memory for an unlocked wallet). As the wallet package is
designed to use no internal locking, and correct synchronization is
provided by the importers of the package, this mutex has been removed.
This change uses the ChainedPubKey function to create addresses from
the previous address's public key and the wallet chaincode, without
the need for the private key, if the keypool has been depleted and the
wallet is locked. This is done since the next chained private key is
unsolvable without a locked wallet.
If a wallet contains any of these chained addresses with missing
private keys, the private keys are created during the next wallet
unlock, using ChainedPrivKey.
This change adds a function to generate the next public key of the
address chain from the previous public key and chaincode, without
needing the previous address's private key. This will be used to
allow generating new addresses with an unlocked wallet, where the
private keys are created on the next unlock.
Tests have been added to verify that the chained private and private
keys match each other (using both chaining functions) as well as an
expected value in the test case. ECDSA signature creation and
verifiction is also performed using the generated keypairs to verify
the next keypair is valid.
btcwallet originally correctly copied the behavior of armory when
chaining new private keys off the previous private key, but this
regressed in commit e8265eca41 with a
switch from double sha256 to a single sha256.
This change reverts the behavior (using the clearly-named function
btcwire.DoubleSha256) to match armory's and old btcwallet's address
chaining algorithm.
If you have flipped the switch to use btcwallet on mainnet, any newly
generated addresses created for the keypool after Jan 6, 2014 (the
date the regression was committed) should be backed up with
dumpprivkey (using btcctl) and a new wallet backup should be made of
your current wallet file (~/.btcwallet/mainnet/wallet.bin on unix) to
avoid the possibility of losing any real money.
This change makes the disk syncer write all three files (wallet, tx,
and utxo) instead of just the wallet, which will result in warnings at
startup if the tx/utxo files cannot be found.
Fixes#30.
When disk syncing a wallet file, if the wallet is flagged dirty, the
disk syncer must grab the wallet writer lock to set dirty=false. The
disk syncing code was being called in the end of
(*Account).RescanActiveAddresses with the reader lock held (unlocked
using a defer), which prevented the writer lock from being aquired.
This change removes the defered unlock to release the reader lock
before syncing to disk.
If ~/.btcwallet/btcd.cert does not exist and the CA file has not been
explicitly set using the config file or command line flags, it's
possible that the cert can be found in ~/.btcd. If connecting to a
localhost btcd and the previous statements are true, the default CA
file config option is updated for the certificate in them btcd
homedir.
If ~/.btcwallet/btcd.cert does exist and the CA file has not been set,
it is used without checking for a cert in the btcd homedir.
This change greatly cleans up the RPC connection between btcwallet and
btcd. Proper (JSON-RPC spec-following) notifications are now expected
rather than Responses with a non-empty IDs.
A new RPCConn interface type has also been introduced with a
BtcdRPCConn concrete type for btcd RPC connections. Non-btcd-specific
code handles the RPCConn, while the btcd details have been abstracted
away to a handful of functions. This will make it easier to write
tests by creating a new fake RPC connection with hardcoded expected
replies.
