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.
This change enables the --mainnet flag to connect to a mainnet btcd
instance and open and create mainnet wallets. Attempting to connect
to a testnet btcd, or opening a testnet wallet when running in mainnet
mode will result in an error printed to the logging output.
Testnet (version 3) remains the default network for now. btcwallet
will continue to receive fixes and new features, but at the moment we
believe that early adopters familar with using btcwallet on testnet
can safely use it for mainnet now as well.
Reminder: when dealing with mainnet coins, it is always a good idea to
keep backups of your wallet. btcwallet uses a deterministic wallet,
and any later addresses for an account can be recreated with just the
account's original wallet file (this does *not* include imported
addresses). Might we recommend Cyphertite for a backup solution?
