For users don't want to set/manage a passphrase a default passphrase
"passphrase" will be used during wallet creation.
At startup, the wallet tries to unlock itself using the default
passphrase, or a user provided one (using -p).
Users that prefer a passphrase can override the default one at wallet
creation time using -p, or use the walletpassphrase rpc when
the wallet is running. This will prevent the wallet from auto-unlock,
and preserve the lock-by-default behavior.
1. remove lbcdusername and lbcdpassword
2. rename (username, password) to (rpcuser, rpcpass)
Most users are confused with the lbcduser and username at first,
and choose to use the same credentials between lbcd and lbcwallet.
1. Remove passphrase support for public keys.
2. Rename privPassphrase to passphrase to avoid confusion.
Note:
There has been a bug in the prompt, which prevents users from
specifying a custom public passphrase. So, most wallet databases
have been using the default password for the public keys, anyway.
This prevents treating a flag that was explicitly set to the default
as unchanged, since the explicit set is recorded in the new
*cfgutil.ExplicitString flag type.
In https://github.com/btcsuite/btcwallet/pull/419#issuecomment-212482492
I mentioned that btcwallet should wait until btcd also switches back
to upstream package paths so that duplicate packages are not included
in and bloat the btcwallet binary. Even while btcd has not yet
switched to the upstream flags package, this change can still be made
now since it is only used by btcd's main package, which is not
included in btcwallet.
When 29f31725ee deprecated the datadir
option, replacing it with --appdata/-A, the short --datadir option was
unintentinally changed from -b to -D. It was previously changed to -b
in fda2e14b99 for consistency with
btcd's --datadir short option.
This change reverts the unintentional switch back to -D.
This modifies the default configuration file to be relative to the
application data directory (configuratble with --appdata). If there
is no configuration file in this directory, then no additional
configuration options are applied (it does not fallback to
~/.btcwallet/btcwallet.conf).
Fixes#421.
This fixes home directory expansion on Windows and OS X. Previously
on these platforms, a leading ~ would expand to %LOCALAPPDATA% on
Windows or ~/Library/Application Support/ on OS X.
While here, add support for ~otheruser expansion to expand to
otheruser's home directory.
Note that this is a breaking change since it removes the mainnet
config option, replacing it with a testnet option. Old configuration
files that set mainnet=1 will cause the wallet to error during startup
since extraneous flags are treated as errors.
Because configuration files will have to be updated for the change
regardless, the old deprecated (and unused) options `disallowfree` and
`keypoolsize` have also been removed.
Closes#383.
This began as a change to improve the fee calculation code and evolved
into a much larger refactor which improves the readability and
modularity of all of the transaction creation code.
Transaction fee calculations have been switched from full increments
of the relay fee to a proportion based on the transaction size. This
means that for a relay fee of 1e3 satoshis/kB, a 500 byte transaction
is only required to pay a 5e2 satoshi fee and a 1500 byte transaction
only need pay a 1.5e3 fee. The previous code would end up estimating
these fees to be 1e3 and 2e3 respectively.
Because the previous code would add more fee than needed in almost
every case, the transaction size estimations were optimistic
(best/smallest case) and signing was done in a loop where the fee was
incremented by the relay fee again each time the actual size of the
signed transaction rendered the fee too low. This has switched to
using worst case transaction size estimates rather than best case, and
signing is only performed once.
Transaction input signature creation has switched from using
txscript.SignatureScript to txscript.SignTxOutput. The new API is
able to redeem outputs other than just P2PKH, so the previous
restrictions about P2SH outputs being unspendable (except through the
signrawtransaction RPC) no longer hold.
Several new public packages have been added:
wallet/txauthor - transaction authoring and signing
wallet/txfees - fee estimations and change output inclusion
wallet/txrules - simple consensus and mempool policy rule checks
Along with some internal packages:
wallet/internal/txsizes - transaction size estimation
internal/helpers - context free convenience functions
The txsizes package is internal as the estimations it provides are
specific for the algorithms used by these new packages.
This option prevents the RPC server TLS key from ever being written to
disk. This is performed by generating a new certificate pair each
startup and writing (possibly overwriting) the certificate but not the
key.
Closes#359.
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.
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.
