Shortly we will add new types of address, so make AddressInfo an
interface, with concrete types providing address-specific information.
Adapt existing code to this new status quo.
The flag marking chained addresses as needing private keys be
generated on the next wallet unlock was not being correctly unset
after creating and encrypting the private key. After
serializing/deserializing the wallet, on next unlock, recreating
missing private keys would begin too early in the chain and fail due
to trying to encrypt an already encrypted address.
This change correctly unsets the flag and bumps the version so a
special case can be created for ignoring duplicate encryption attempts
when reading an old wallet file. Tests have also been added to the
chained pubkey test to test for this error case.
Previous to this commit, all change addresses were indistinguishable
from manually requested addresses. This adds a new function to return
the new address, setting a new change flag to true, and return the
change status with the AddressInfo.
This is needed as part of resolving #41 (getrawchangeaddress).
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.
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 saves (at most) the last 20 block hashes to disk. Upon
btcd connect, in the handshake, btcwallet checks whether btcd's best
chain still contains these blocks, starting from the most recently
added block and continuing until the earliest saved. If any blocks
are missing, Tx history and UTXOs from any blocks no longer in the
chain are removed, and a rescan is started from after the best block
still in the main chain.
If all previous block hashes are exhausted (either due to a large
reorg, or because not enough blocks have been seen), a full rescan is
triggered (full meaning from the earliest block that matters to this
wallet) since the last synced up to point is no longer available.
The previous 20 seen block hashes are saved to the wallet file, which
required bumping the file version. Older wallets written with lesser
versions will use the previous reading function, making this change
backwards compatible.
This change adds an additional check when creating a new wallet or
extending the keypool. All public and private keypairs are parsed
from their serialized forms, and an ecdsa signature is created and
verified using the keypairs. If the verifiction fails at any point,
the wallet creation or keypool extension is aborted to prevent any
errors where an address is returned to a user, but any funds send to
that address are unspendable due to a mismatched keypair.
This change better organizes account handling by creating a new
AccountStore type and accountstore global variable, with receiver
funcs for all operations that require all accounts. More Account
funcs are also added to clean up account handling in the RPC code.
Intial work on this done by dhill.
This adds the necessary bits for handling importing addresses for the
wallet file format, as well as implementing the importprivkey and
dumpprivkey RPC requests.
Initial code by dhill.
Wallets that include compressed pubkeys are no longer compatible with
armory, however, imported wallets from armory (using uncompressed
pubkeys) are still valid.
When a wallet is opened, a rescan request will be sent to btcd with
all active addresses from the wallet, to rescan from the last synced
block (now saved to the wallet file) and the current best block.
As multi-account support is further explored, rescan requests should
be batched together to send a single request for all addresses from
all wallets.
This change introduces several changes to the wallet, tx, and utxo
files. Wallet files are still compatible, however, a rescan will try
to start at the genesis block since no correct "last synced to" or
"created at block X" was saved. The tx and utxo files, however, are
not compatible and should be deleted (or an error will occur on read).
If any errors occur opening the utxo file, a rescan will start
beginning at the creation block saved in the wallet.
This change switches the time fields (firstSeen/lastSeen) of an
address from uint64 to int64, to be compatible with (time.Time).Unix,
as well as changing the block height fields (firstBlock/lastBlock)
from uint32 to int32, since block height is normally represented
signed.
This is a big change that also many general fixes to problems found
when creating transactions. In particular the Utxo and Tx formats and
serialization functions were updated with additional information that
would be necessary for rolling back old utxo and tx data data after
btcd chain switches. This change also implements the json methods
'sendfrom' and 'sendmany' to create a new transaction based on a
frontend request.
Transactions are currently not sent to btcd since the tx relay code is
not finished yet, so a temporary error is returned back to frontends
who try to send new transactions.
