This change modifies the order in which transaction to watched
addresses are processed and when frontend notifications occur. Due to
btcd notifying all transactions before sending the blockconnected
notification, the UTXO and transaction stores can be modified without
sending any frontend notifications, and then a single frontend
notification is sent when the blockconnected notification arrives.
The order in which each file is synced to disk was also changed to
write out the UTXO and transaction stores before writing the wallet.
This is to prevent a race where wallet closes after writing the dirty
wallet, but before the dirty UTXO store is written. In this
situation, newly added UTXOs will be missed and not found again on the
next wallet open during the rescan. Writing the wallet (which holds
the synced-to-block information) last prevents this.
An issue where the unconfirmed change UTXO created from a new
transaction never being properly notified to frontends is fixed now as
well.
This change moves the handlers to a map (instead of falling through a
switch statement), and updates each handler to use a btcjson.Cmd
instead of passing parameters in a btcjson.Message manually.
Plenty of comments were also added, which should also make the code
much more understandable.
This removes the enforced check for the spent field for tx-to-me
notifications, as this is no longer sent, and should be calculated by
wallet (not done yet). Additionally, the full CreatedTx information
is saved with the unmined tx map, so when a tx is mined, information
about which inputs and ouputs it creates that are relevant to the
wallet can be used.
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 copies the behavior of btcd for using seelog for logging,
including making timestamps human readable, and setting the default
logging level to info.
Fixes#8.
When a new account (wallet) is created with the createencryptedwallet
JSON method, all frontends, including the one requesting the wallet,
must be notified of this new account and its balance (probably zero).
This removes the need for frontends to poll and check for any new
accounts.
This change automatically sends the btcdconnected notification for all
frontends as they connect to btcwallet. The old btcdconnected command
has been removed, as it is no longer needed for clients to explicitly
request this information any longer.
To start btcd and btcwallet with all the right settings for testnet,
the Btcd Suite batch file should be run from the start menu rather
than btcd and btcwallet individually. Update the README to reflect
that.
This change removes a lot of unnecessary and complicated locking (if
serializing requests is needed in the future, a goroutine will be used
instead) and also shifts the heavy lifting from frontends to btcwallet
itself to handle any notifications when they can be properly handled.
Although it's still legal to, frontends no longer need to explicitly
request account balances as these are calculated and sent as an async
notification on frontend connect, and these notifications will only
occur if btcd is currently connected. Likewise, when btcd connects,
all frontends are immediately notified of all notifications that
require btcd information, such as the current block height for
calculating account balances.
CalculateBalance now works correctly: if confirmations is 0, all UTXOs
will be used for the balance. Otherwise, unconfirmed UTXOs will be
exclused. 1 confirmation will allow the UTXO height and current block
height to be equal. Even though the difference is zero, the
transaction including the UTXO has been mined into one block.
This change also remove extraneous account balance notifications for
connected and disconnected blocks.
When sending a new transaction, the change address must receive the
same updates as explicitly-generated addresses. Without this
notification, the unconfirmed UTXO will never become confirmed as the
notification will never be received.
This fixes the issue where change UTXOs never move from "Unconfirmed"
to "Balance" in btcgui.
bitcoin-qt uses "Balance" to mean all spendable outputs that have been
mined into a block, while "Unconfirmed" only refers to outputs that
have not yet been mined into a block. This change copies that
behavior, instead of the previous required 6 blocks to be confirmed.
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.
Any and all resending should be handled directly by btcd, and btcd
ignores any duplicate transactions when adding to mempool anyways. A
set of unmined txs is still kept and send to btcd in case of btcd
restarting and losing wallet transactions from its mempool.
In case of a btcd restart, it is necessary to send unmined
transactions back to btcd so they can be added to the tx mempool.
btcd can make a best-try effort, but It is ultimately btcwallet's
responsibility that transactions appear in blocks even if btcd is
restarted.
This change fixes many issues with the tracking of unspent transaction
outputs. First, notifications for when UTXOs arse spent are now
requested from btcd, and when spent, will be removed from the
UtxoStore.
Second, when transactions are created, the unconfirmed (not yet in a
block) Utxo (with block height -1 and zeroed block hash) is added to
the wallet's UtxoStore. Notifications for when this UTXO is spent are
also requested from btcd. After the tx appears in a block, because
the UTXO has a pkScript to be spent by another owned wallet address, a
notification with the UTXO will be sent to btcwallet. We already
store the unconfirmed UTXO, so at this point the actual block height
and hash are filled in.
Finally, when calculating the balance, if confirmations is zero,
unconfirmed UTXOs (block height -1) will be included in the balance.
Otherwise, they are ignored.
