The info log level (default) will produce output about confirmed and
unconfirmed transactions being inserted into the store, as well as
unconfirmed transactions which have been mined into blocks. By
enabling the debug log level (-d TXST=debug), additional information
about transaction inputs and outputs is logged. This includes the
total amount of previously-unspent outputs which have been marked
spent by the inserted transaction, and the output indexes and amounts
for each spendable output. Additionally, the debug log level will log
whenever transactions are removed due to being a double spend of
another inserted transaction.
If a transaction is added that debits from previous transaction
outputs, and those outputs are still unconfirmed, it is possible that
if the credits were not already known (as is the case with
transactions notified after a sendrawtransaction), only mined unspent
transaction outputs would be searched and the unconfirmed unspent
credits would be missed. This results in spent outputs still being
marked unspent.
This change fixes the above by also searching through unconfirmed
transactions when the previous credits must be lookup up, rather than
being pass from an AddDebits call.
Fixes issue #91.
This commit is the result of inspecting the results of both cpu and
memory profiling, to improve areas where wallet can be more efficient
on transaction inserts.
One problem that's very evident by profiling is how much waiting there
is for file (txstore, wallet) writes. This commit does not attempt to
fix this yet, but focuses on the easier-to-fix memory allocation
issues which can slow down the rest of wallet due to excessive garbage
collection scanning.
While here, fix a race where a closure run as a goroutine was closing
over a range iterator.
The Credit and Debits structures are simple wrappers around an
embedded *txstore.TxRecord, as well as an output index in the case of
Credit. This means that a Credit is at most two words, while a Debits
struct is just one. To avoid the unnecessary garbage of creating
Credit and Debits structures on the heap (where the underlying
TxRecord likely already is), simply pass around everywhere as
non-pointer types, and modify the receivers for all Credit and Debits
methods to non-pointer receivers since none of them ever modify the
value.
This change "reverses" the mapping used by the transaction store to
reference and lookup unspent credits. Rather than mapping slice
indexes of a block, and then another block map for slice indexes of
transactions with unspent credits, and requiring a lookup through each
credit for whether it is spent or unspent, keep a simple map of
outpoints to a lookup key to find the transaction in a block.
This has a positive effect on performance when searching for previous
transaction outputs that have been spent by a newly-inserted
transaction. Rather than iterating through every block with an
unspent credit, and then every transaction with unspent credits, a
simple map lookup can be done to check whether a transaction input's
previous outpoint is marked as unspent by wallet, and then access the
transaction record itself by the lookup key. While transactions
created by wallet with the sendfrom/many RPCs may mark debits with the
previous credits already known, the previous outputs may still not be
known if a debiting transaction was added by rescan, or notified as a
result of a create+sendrawtransaction.
Fixes a hang where a send on the notification chan can block due to
the queue being filled, and the current running notification making a
blocking call to the rpc client.
Fixes#100.
This was only necessary for a very old version of the transaction
store. The current implementation stores both sent (debit) and
received (credit) records for individual transactions.
Unspent inputs were being sorted multiple times in an inner loop.
This change moves the sort outside the loop so it is only performed
once. While here, also move the transaction confirmation filter
outside the inner loop, as these can be calculated just once.
If a JSON array result was successfully calculated, but the
slice/array is empty, the result must be marshaled as '[]' rather than
the JSON null value. To do this in go, the RPC handlers should never
return nil slices for non-error returns, but return a non-nil slice
header with 0 length.
For example, an empty listtransactions result should be returned as
[]btcjson.ListTransactionsResult{}, rather than nil.
This change rewrites much of the error handling for the RPC server
components to match a more idiomatic Go error handling style as well as
fix several issues regarding error equality checks.
Closes#94.
If the transaction store cannot be opened and read (i.e. the version
is too old to be deserialized), the wallet is marked unsynced and
rewritten, and a new empty transaction store is written over the
previous.
The gettransaction handler was attempting to lookup the "sent-to"
address of an outgoing transaction from the transaction store (as a
wallet credit). This is the incorrect address when sending to an
address controlled by another wallet, and panics when there are no
credits (for example, sending to another wallet without any change
address). Instead, use the first non-change output address is used as
the address of the "send" result.
This fixes the panic reported when debugging issue #91.
While here, fix the category strings used for wallet credits to
support immature and generate (the categories for coinbase outputs).
This change immediately writes a new empty transaction store out to
disk if the old one could not be read. Since old transaction store
versions are not read in at start, and were previously not written out
until new transaction history was received, it was possible that a
full rescan started and finished without ever marking a synced tx
history for the next wallet start.
If a rescan fails (for example, due to a disconnected btcd) in the
btcd handshake, the last block height from a rescanprogress
notification should be used for the next rescan job on next wallet
connect. Previously, this rescan would always start at the earliest
block height for any wallet address if the transaction store could not
be read at wallet startup. This change unsets the boolean flag which
would cause a full rescan at next connect when a rescan progress
notification is received and a partial sync height is written.
Fixes#87.
If an unexpected error is encounted when creating the encrypted
wallet, rather than using btcjson.ErrInternal, wrap the error message
using btcjson.ErrWallet.Code.
18555 is the network port, and wallet cannot listen on this port.
Instead, follow the pattern laid out by mainnet, testnet3, and regtest
by listening on 18554 (one less than the network port).
If the data directory is modified on the command line or from the
config file, all paths relative to the directory, if unmodified, must
be changed to reference it.
This change is the result of using the errcheck tool
(https://github.com/kisielk/errcheck) to find all unchecked errors,
both unassigned and those assigned to the blank identifier.
Every returned error is now handled in some manner. These include:
- Logging errors that would otherwise be missed
- Returning errors to the caller for further processing
- Checking error values to determine what to do next
- Panicking for truely exceptional "impossible" errors
On the subject of panics, they are a sharp tool and should be used
sparingly. That being said, I have added them to check errors that
were previously explicitly ignored, because they were expected to
always return without failure. This could be due to fake error paths
(i.e. writing to a bytes.Buffer panics for OOM and should never return
an error) or previous logic asserts that an error case is impossible.
Rather than leaving these unhandled and letting code fail later,
either with incorrect results or a nil pointer dereference, it now
produces a stack trace at the error emit site, which I find far more
useful when debugging.
While here, a bunch of dead code was removed, including code to move
pre-0.1.1 uxto and transaction history account files to the new
directory (as they would be unreadable anyways) and a big chunk of
commented out rpcclient code.
So (SigHashAll & SigHashSingle)!= 0, which is not the intention here. fix up
that check to only match SigHashSingle.
Found by drahn, debugged together, fix by me.
