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.
This is an intial pass at converting the btcwallet and deps codebases
to pass a network by their parameters, rather than by a magic number
to identify the network. The parameters in params.go have been
updated to embed a *btcnet.Params, and all previous uses of cfg.Net()
have been replaced with activeNet.{Params,Net} (where activeNet is
the global var for the active network).
Although dependancy packages have not yet been updated from using
btcwire.BitcoinNet to btcnet.Params, the parameters are now accessible
at all callsites, and individual packages can be updated to use btcnet
without requiring updates in each external btc* package at once.
While here, the exported API for btcwallet internal library packages
(txstore and wallet) have been updated to pass full network parameters
rather than the btcwire definition of a network.
This change adds the new btcdusername and btcdpassword options which,
if set, are used instead of the username and password when
authenticating to a btcd RPC server. If these new options are unset,
the btcd user and password settings are shared with the client auth
settings.
