This is a rather monolithic commit that moves the old RPC server to
its own package (rpc/legacyrpc), introduces a new RPC server using
gRPC (rpc/rpcserver), and provides the ability to defer wallet loading
until request at a later time by an RPC (--noinitialload).
The legacy RPC server remains the default for now while the new gRPC
server is not enabled by default. Enabling the new server requires
setting a listen address (--experimenalrpclisten). This experimental
flag is used to effectively feature gate the server until it is ready
to use as a default. Both RPC servers can be run at the same time,
but require binding to different listen addresses.
In theory, with the legacy RPC server now living in its own package it
should become much easier to unit test the handlers. This will be
useful for any future changes to the package, as compatibility with
Core's wallet is still desired.
Type safety has also been improved in the legacy RPC server. Multiple
handler types are now used for methods that do and do not require the
RPC client as a dependency. This can statically help prevent nil
pointer dereferences, and was very useful for catching bugs during
refactoring.
To synchronize the wallet loading process between the main package
(the default) and through the gRPC WalletLoader service (with the
--noinitialload option), as well as increasing the loose coupling of
packages, a new wallet.Loader type has been added. All creating and
loading of existing wallets is done through a single Loader instance,
and callbacks can be attached to the instance to run after the wallet
has been opened. This is how the legacy RPC server is associated with
a loaded wallet, even after the wallet is loaded by a gRPC method in a
completely unrelated package.
Documentation for the new RPC server has been added to the
rpc/documentation directory. The documentation includes a
specification for the new RPC API, addresses how to make changes to
the server implementation, and provides short example clients in
several different languages.
Some of the new RPC methods are not implementated exactly as described
by the specification. These are considered bugs with the
implementation, not the spec. Known bugs are commented as such.
Removed links to outdated btcsuite MSIs, replacing these with links to
Github releases.
Combined installation and updating instructions since they are
identical.
Added Windows to the list of operating systems that the "Build from
source" instructions work with.
Added PowerShell examples for copying the sample btcd and btcwallet
configs for both MSI and source installs.
This change moves the chain and network parameter definitions, along
with the default client and server ports, to a package for reuse by
other utilities (most notably, tools in the cmd dir). Along with it,
functions commonly used for config parsing and validation are moved to
an internal package since they will also be useful for distributed
tools.
Logging from btcrpcclient is currently not possible to set, and defaults
to nothing. Letting it inherit chain's logger can greatly simplify
debugging of connectivity issues.
Also remove a now redundant log message upon connecting to btcd.
AFAICT this function has never worked correctly due to the hash being
signed not matching the hash created by Core. Core wallet writes
serialized strings to a double-sha256 hashing stream, while we were
using string concatination. This produced different messages since
the message before hashing did not include compact integers (called
varints in btcsuite code) preceding each string with the string
length.
Tested by creating signed messages from btcwallet and verifying them
with Bitcoin-Qt, as well as creating signatures from Bitcoin-Qt and
verifying them with btcwallet.
Fixes#323.
This change introduces additional network activity with the btcd
process to ensure that the network connection is not silently dropped.
Previously, if the connection was lost (e.g. wallet runs on a laptop
and connects to remote btcd, and the laptop is suspended/resumed) the
lost connection would not be detectable since all normal RPC activity
(excluding requests from btcwallet to btcd made by the user) is in the
direction of btcd to wallet in the form of websocket notifications.
The behaviour of function Address() in waddrmgr has been updated such that
it now displays the correct behaviour as described in the comments. That is,
when a public key address is given as a btcutil.Address, the key is converted
to a public key hash address so that serializing with ScriptAddress() yields
the corresponding public key hash. This allows the address manager to find
the corresponding private key, and fixes the signing of multisignature
transactions.
sync.Locker cannot be safely used to switch a sync.Mutex to a noop
locker since other goroutines that attempt to lock the mutex will race
on the changing interface. Instead, just statically dispatch
sync.Mutex methods.
Doing that may cause erratic test failures when we run them in parallel, so
move the functions the tests need to mock as struct fields that are not
shared across tests.
Rather than the main package being responsible for opening the address
and transaction managers, the namespaces of these components are
passed as parameters to the wallet.Open function.
Additionally, the address manager Options struct has been split into
two: ScryptOptions which holds the scrypt parameters needed during
passphrase key derivation, and OpenCallbacks which is only passed to
the Open function to allow the caller to provide additional details
during upgrades.
These changes are being done in preparation for a notification server
in the wallet package, with callbacks passed to the Open and Create
functions in waddrmgr and wtxmgr. Before this could happen, the
wallet package had to be responsible for actually opening the managers
from their namespaces.
If a long reorganize occurs farther back than the last saved recent
block hash (currently max 20 are saved) a full rescan is triggered
since there is no guarantee the previous blocks weren't also removed
in the reorg. In this case, the address manager was set unsynced, but
transaction history was not rolled back as well. This commit corrects
this by unconfirming all transactions but those in the genesis block.
StartWithdrawal now persists the WithdrawalStatus before returning, and also
returns a previously saved one in subsequent calls with the same parameters.
All transactions since the specified block (or the genesis block if
left unspecified) should be included in the result array
Along with this fix, update the help descriptions to mention that the
target confirmations parameter is not considered when including
transactions in the result object. That is, transactions with a
height greater than the height of the lastblock in the result object
are still included.
Fixes#263.
To increase compatibility with Bitcoin Core Wallet, additional fields
were added to and other fields made optional for the listtransactions
and gettransaction results structs. For both, fee was changed to be
optional (including the zero value is allowed).
If the account number to name index mapped the default account name to
an alias, the upgrade would not succeed and the upgrade would be
aborted (and rolled back).
This became a problem for upgrading old (pre-v3) wallets since the v3
upgrade did not rename the previous "" account to "default", but
instead just created an alias.
Fix tested by @dajohi, who ran into this issue with a wallet upgrade
from an older keystore version.
Rather than disallowing the default account to be renamed as was
proposed in #245 (and implemented in #246), the default account name
is no longer considered a reserved name by the address manager.
Instead, it is simply the initial name used for the first initial
account.
A database upgrade removes any additional aliases for the default
account in the database. This prevents a lookup for some name which
is not an account name from mapping to the default account
unexpectedly (potentially preventing incorrect account usage from the
RPC server due to bad iteraction with default parameters).
All unset account names in a JSON-RPC request are expected to be set
nil by btcjson. This behavior depends on btcsuite/btcd#399.
Additionally, the manager no longer considers the wildcard * to be a
reserved account name. Due to poor API decisions, the RPC server
overloads the meaning of account fields to optionally allow referring
to all accounts at a time, or a single account. This is not a address
manager responsibility, though, as a future cleaner API should not use
multiple differet meanings for the same field across multiple
requests. Therefore, don't burden down future APIs with this quirk
and prevent incorrect wildcard usage from the RPC server.
Closes#245.
