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.
This commit updates the documentation which discusses creating and opening
the manager to properly mention the wallet database namespace as well as
another typo.
This is performed by saving the SHA512(salt+passphrase) of the
waddrmgr.Manager private passphrase each time the manager is unlocked.
If another call to Unlock is performed before the next Lock, the hash
is applied to the new input. If it matches, we know the passphrase is
(likely) equal, so return early and continue using the crypto keys
already in memory. If it does not match, we know for certain the
passphrase is incorrect and the manager is locked.
The slice of keys which must have their private extended keys derived
on unlock was never being removed from and all of these keys were
being rederived unnecessarily on every unlock. Fix this by re-slicing
the deriveOnUnlock slice to remove the just derived key if the
derivation was successful.
