This commit cleans up the recent test addition for testing the positive
and negative error paths of the Encrypt and Decrypt functions.
In particular:
- Add comments to all new functions
- Close the manager before trying to delete the file which is otherwise in
use
- Rename the temp prefix since these are not pool tests
- Rename setUp to setupManager to make it a bit more explicit what it's
doing
This commit implements a new namespaced db package which is intended to
be used be wallet and any sub-packages as its data storage mechanism.
- Key/value store
- Namespace support
- Allows multiple packages to have their own area in the database without
worrying about conflicts
- Read-only and read-write transactions with both manual and managed modes
- Nested buckets
- Supports registration of backend databases
- Comprehensive test coverage
This commit adds comments about the specific crypto key types, moves the
selectCryptoKey function before the Encrypt/Decrypt functions that call it
to be more consistent with the rest of the code base, and slightly
modifies the verbiage of the comment.
This function was misleading because it was actually *not* atomic
(meaning it should have never been used at all where atomicity was
required). This will break builds on Plan 9 but I consider this fine
to do since the soon-to-be-integrated waddrmgr package relies on bolt
as a database and also does not compile for Plan 9.
The crypto key type unsed in the manager is not needed outside of the
package. Also, rather than having the newCryptoKey func return the
specific cryptoKey type, make it return the EncryptorDecryptor interface.
This will allow it to be overridden with another type that implements the
interface from the tests.
Useful to test error conditions.
Also provide a new function that wraps snacl.GenerateCryptoKey(),
defined as a variable so that it can be replaced in tests.
This commit implements a new secure, scalable, hierarchical deterministic
wallet address manager package.
The following is an overview of features:
- BIP0032 hierarchical deterministic keys
- BIP0043/BIP0044 multi-account hierarchy
- Strong focus on security:
- Fully encrypted database including public information such as
addresses as well as private information such as private keys and
scripts needed to redeem pay-to-script-hash transactions
- Hardened against memory scraping through the use of actively clearing
private material from memory when locked
- Different crypto keys used for public, private, and script data
- Ability for different passphrases for public and private data
- Scrypt-based key derivation
- NaCl-based secretbox cryptography (XSalsa20 and Poly1305)
- Multi-tier scalable key design to allow instant password changes
regardless of the number of addresses stored
- Import WIF keys
- Import pay-to-script-hash scripts for things such as multi-signature
transactions
- Ability to export a watching-only version which does not contain any
private key material
- Programmatically detectable errors, including encapsulation of errors
from packages it relies on
- Address synchronization capabilities
This commit only provides the implementation package. It does not
include integration into to the existing wallet code base or conversion of
existing addresses. That functionality will be provided by future
commits.
Previously, the createencryptedwallet and stop requests did not check
that the client had successfully authenticated to the server. This
change moves the check outside of the select statement for these
special cased handlers (previously run from the default case) so an
auth check will occur even if a request method does not match either
of these two.
The stack trace did not make it evidant which request had caused this
issue, so add extra logging for the request that caused it. Sanitize
this request if it may contain any secrets.
Additionally, in this situation, begin shutting down the wallet rather
than simply dropping the response. This will help to catch the issue
since it's easier to notice all requests failing, rather than just one
that was dropped. If shutdown takes an unreasonably long time, panic.
Instead of using the zero value, explicitly set the last chain index
to -1, which represents the root key. If no additional keys are read
from the io.Reader, this could result in panics when looking up keys
at index 0, when no additional keys have been created yet.
Fixes#119.
Previously, registerations for wallet notifications (new txs, changed
account balances) were only passed up to websocket clients if the
wallet was loaded off disk (SetWallet was called with a non-nil
wallet), and not for the case when the RPC server would create the
wallet (if it wasn't created yet, and the user manually created it
with createencryptedwallet). This change fixes that by registering
for these notifications when this code path is taken.
The notified chain server connection state was being passed through
the wallet and then notified to the RPC server, which prevented this
notification from ever firing if a wallet didn't exist yet. Instead,
make the RPC server register for these notifications directly from the
chain server RPC client.
I'm not happy with this notification and how it's handled in the code,
but to not break existing clients this change is being made. Fixing
the notifiation mess and modifying existing clients to use a new
notification API will need to be done sometime later.
This prevents a hang when attempting to set the wallet (and register
for wallet notifications) when the process is interrupted and the rpc
server begins shutting down.
If a websocket client was already connected and the wallet and/or
chain server is loaded into the rpc server (enabling the handlers
specific to those components), the btcdconnected notifications were
not being sent, and this could break clients that expected the
notification. I'm not happy with this change, but since this is how
notifications are currently done (unsolicited), and to not break
compatibility yet, I'm adding these back in for now.
Eventually, this notification will require explicit registration
before it is received by a client. See issue #84.
Closes#115.
Addresses do no have balances. In situations where a payment is
required and just a single address was provided, it is better to track
the unspent outputs themselves, rather than watching some artificial
measure of payment.
