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.
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.
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.
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.
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 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.
While fixing this code, the dirty flag was also cleared so that
unneeded syncs wouldn't be needed later. The dirty flag set and sync
was also added for the 'getnewaddress' handler, as it was previously
missing.
This runs a syncer once every minute to write any dirty wallet data
structures out to disk. As currently implemented, dirty wallets will
be lost if not written before btcwallet closes or crashes.
Deterministic wallet help migitate this issue (as private keys can be
created again as long as a previous wallet file was written) but this
can still be a nuisance as a longer rescan will be required to catch
up to chain.
This removes inputs spent by a transaction from the stored UTXOs. If
the UtxoStore is modified, all frontends are notified of the new
confirmed and unconfirmed account balances.
More work must be done later to check that the transaction actually
does occur in a later block. btcd will make a best try effort to
relay the tx to the network, but it is still ultimately btcwallet's
responsibility. Added a TODO so I remember to do this in the future.
We need to notify frontends of notifications for every account
(wallet), not just the "current" opened account, since wallet will
need to have multiple wallets open at the same time. Frontends will
have to filter notifications to show only details of only one account
if they need to display just one account at a time.
As of this commit, account balances and lock state notifications are
using this per-account notification scheme.
Use on mainnet is not recommended until extensive testing has been
done, and should be done at your own risk. Run btcwallet with
--mainnet to operate on main Bitcoin network.
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.
We must instead wait for the user to explicitly generate their own
wallet for an account name. This is because all btcwallet wallets
must be encrypted, and the passphrase must be known at time of wallet
generation.
