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.
btcrpcclient commit 9ca93b30ad11ec34348d2d788c58019571bf9524 switched
the client to btcjson v2 and broke the wallet build. This change is
the minimum amount of work to make wallet work again.
The rpc server still uses btcjson v1, so there will be 2 versions of
btcjson linked in the resulting binary. This is not optimal but not
compiling is worse.
This a refactor of the btcwallet main package to create a new wallet
package.
The main feature of this package is the integration of all the other
wallet components (waddrmgr, txstore, and chain) and the Wallet type is
'runnable', so it will be continuously updating itself against changes
notified by the remote btcd instance.
It also includes several methods which provide access to information
necessary to run a wallet RPC server.
The createtemp flag is used to create a temporary simnet wallet for
use with btcsim or other testing suites.
The flag only works if the datadir and network to use it on (simnet)
are specified.
After starting btcwallet with the flag, the wallet immediately opens
and is functional.
This introduce a new internal package to deal with the explicit
clearing of data (such as private keys) in byte slices, byte arrays
(32 and 64-bytes long), and multi-precision "big" integers.
Benchmarks from a xeon e3 (Xor is the zeroing funcion which Bytes
replaces):
BenchmarkXor32 30000000 52.1 ns/op
BenchmarkXor64 20000000 91.5 ns/op
BenchmarkRange32 50000000 31.8 ns/op
BenchmarkRange64 30000000 49.5 ns/op
BenchmarkBytes32 200000000 10.1 ns/op
BenchmarkBytes64 100000000 15.4 ns/op
BenchmarkBytea32 1000000000 2.24 ns/op
BenchmarkBytea64 300000000 4.46 ns/op
Removes an XXX from the votingpool package.
This commit makes the creation and updating of the address manager more
explicit so it's easier to upgrade in the future.
In particular, rather than treating the initial creation as an upgrade by
relying on creating the initial buckets on the fly on each load, the code
now explicitly provides distinct create and upgrade paths that are invoked
from the Create and Open functions, respectively.
It also adds some commented out sample code to illustrate how upgrades
should be done and a check to ensure bumping the version number without
writing upgrade code results in a new error, ErrUpgrade, being returned.
Finally, a test has been added for the new functionality.
Otherwise, if the websocket connection to btcd is lost and
reestablished, there is no sync to the current best block, and btcd
will not notify wallet of new relevant transactions.
This was previously using the most recently notified (by the chain
package) block, but transaction processing from this block may not be
finished yet. Using this block's height to calculate the number of
confirmations is therefore incorrect, and can result in every RPC
handler missing transactions or returning transactions from the wrong
block.
Wallet should handle these so that wallet clients don't end up
creating requests to btcd about the latest processed block, which is
not the same as wallet's most recently processed block.
By providing wallet clients with this info, we avoid a race where the
client thinks wallet has processed N blocks, but in fact is still
synced to N-1 (and perhaps currently processing transactions from
block N). This can cause unexpected results for many of the
bitcoind-compatible RPC APIs due to their reliance on number of
confirmations, rather than using absolute block heights.
This commit converts the wallet to use the new secure hierarchical
deterministic wallet address manager package as well as the walletdb
package.
The following is an overview of modified functionality:
- The wallet must now be created before starting the executable
- A new flag --create has been added to create the new wallet using wizard
style question and answer prompts
- Starting the process without an existing wallet will instruct now
display a message to run it with --create
- Providing the --create flag with an existing wallet will simply show an
error and return
In addition the snacl package has been modified to return the memory after
performing scrypt operations to the OS.
Previously a runtime.GC was being invoked which forced it to release the
memory as far as the garbage collector is concerned, but the memory was
not released back to the OS immediatley. This modification allows the
memory to be released immedately since it won't be needed again until the
next wallet unlock.
By using txscript.StandardVerifyFlags when creating and validating
transactions, we can ensure the transactions successfully created
won't be rejected due to script policy.
