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.
This commit introduces a new flag, --noclienttls, which can be used to disable
TLS for the RPC client. However, the flag can only be used when the RPC
client is connecting to localhost interfaces. This is intended to prevent
accidentally leaking sensitive data when switching between local and
remote servers.
This commit introduces a new flag, --noservertls, which can be used to disable
TLS for the RPC server. However, the flag can only be used when the RPC
server is bound to localhost interfaces. This is intended to prevent the
situation where someone decides they want to expose the RPC server to the
web for remote management/access, but forgot they have TLS disabled.
This will allow the worker goroutine to return even if one of the
other workers has already errored, preventing these goroutines from
lingering forever blocking on a channel send.
When detaching the tail end of a slice of blocks or transactions and
appending the newly inserted middle block, and the previous tail, the
capacity of the slice head must be limited to prevent overwriting the
newly inserted block/tx in the same memory as the tail slice.
Bug discovered by @mably while working on the peercoin port of
btcwallet and reported on IRC.
This matches the recent change made to bitcoin core wallet, and
follows roughly a year after the minimum mempool relay fee/kB was
dropped to the same value.
This prevents a downgrade attack to the vulnerable SSLv3. While here,
go ahead and require at least TLS 1.2 since TLS 1.0 and 1.1 have their
own set of issues and it's only a matter of time before those would
need to be completely avoided as well.
