e9bdf2a094
The last transaction store was a great example of how not to write scalable software. For a variety of reasons, it was very slow at processing transaction inserts. Among them: 1) Every single transaction record being saved in a linked list (container/list), and inserting into this list would be an O(n) operation so that records could be ordered by receive date. 2) Every single transaction in the above mentioned list was iterated over in order to find double spends which must be removed. It is silly to do this check for mined transactions, which already have been checked for this by btcd. Worse yet, if double spends were found, the list would be iterated a second (or third, or fourth) time for each removed transaction. 3) All spend tracking for signed-by-wallet transactions was found on each transaction insert, even if the now spent previous transaction outputs were known by the caller. This list could keep going on, but you get the idea. It was bad. To resolve these issues a new transaction store had to be implemented. The new implementation: 1) Tracks mined and unmined transactions in different data structures. Mined transactions are cheap to track because the required double spend checks have already been performed by the chain server, and double spend checks are only required to be performed on newly-inserted mined transactions which may conflict with previous unmined transactions. 2) Saves mined transactions grouped by block first, and then by their transaction index. Lookup keys for mined transactions are simply the block height (in the best chain, that's all we save) and index of the transaction in the block. This makes looking up any arbitrary transaction almost an O(1) operation (almost, because block height and block indexes are mapped to their slice indexes with a Go map). 3) Saves records in each transaction for whether the outputs are wallet credits (spendable by wallet) and for whether inputs debit from previous credits. Both structures point back to the source or spender (credits point to the transaction that spends them, or nil for unspent credits, and debits include keys to lookup the transaction credits they spent. While complicated to keep track of, this greatly simplifies the spent tracking for transactions across rollbacks and transaction removals. 4) Implements double spend checking as an almost O(1) operation. A Go map is used to map each previous outpoint for all unconfirmed transactions to the unconfirmed tx record itself. Checking for double spends on confirmed transaction inserts only involves looking up each previous outpoint of the inserted tx in this map. If a double spend is found, removal is simplified by only removing the transaction and its spend chain from store maps, rather than iterating a linked list several times over to remove each dead transaction in the spend chain. 5) Allows the caller to specify the previous credits which are spent by a debiting transaction. When a transaction is created by wallet, the previous outputs are already known, and by passing their record types to the AddDebits method, lookups for each previously unspent credit are omitted. 6) Bookkeeps all blocks with transactions with unspent credits, and bookkeeps the transaction indexes of all transactions with unspent outputs for a single block. For the case where the caller adding a debit record does not know what credits a transaction debits from, these bookkeeping structures allow the store to only consider known unspent transactions, rather than searching through both spent and unspents. 7) Saves amount deltas for the entire balance as a result of each block, due to transactions within that block. This improves the performance of calculating the full balance by not needing to iterate over every transaction, and then every credit, to determine if a credit is spent or unspent. When transactions are moved from unconfirmed to a block structure, the amount deltas are incremented by the amount of all transaction credits (both spent and unspent) and debited by the total amount the transaction spends from previous wallet credits. For the common case of calculating a balance with just one confirmation, the only involves iterating over each block structure and adding the (possibly negative) amount delta. Coinbase rewards are saved similarly, but with a different amount variable so they can be seperatly included or excluded. Due to all of the changes in how the store internally works, the serialization format has changed. To simplify the serialization logic, support for reading the last store file version has been removed. Past this change, a rescan (run automatically) will be required to rebuild the transaction history. |
||
|---|---|---|
| tx | ||
| wallet | ||
| .gitignore | ||
| .travis.yml | ||
| account.go | ||
| acctmgr.go | ||
| CHANGES | ||
| cmd.go | ||
| config.go | ||
| createtx.go | ||
| createtx_test.go | ||
| deps.txt | ||
| disksync.go | ||
| log.go | ||
| ntfns.go | ||
| params.go | ||
| README.md | ||
| rename_plan9.go | ||
| rename_unix.go | ||
| rename_windows.go | ||
| rescan.go | ||
| rpc.go | ||
| rpcclient.go | ||
| rpcserver.go | ||
| sample-btcwallet.conf | ||
| sockets.go | ||
| updates.go | ||
| version.go | ||
btcwallet
[
]
(https://travis-ci.org/conformal/btcwallet)
btcwallet is a daemon handling bitcoin wallet functionality for a single user. It acts as both an RPC client to btcd and an RPC server for wallet frontends and legacy RPC applications.
The wallet file format is based on Armory and provides a deterministic wallet where all future generated private keys can be recovered from a previous wallet backup. Unencrypted wallets are unsupported and are never written to disk. This design decision has the consequence of generating new wallets on the fly impossible: a frontend is required to provide a wallet encryption passphrase.
btcwallet is not an SPV client and requires connecting to a local or remote btcd instance for asynchronous blockchain queries and notifications over websockets. Full btcd installation instructions can be found here.
As a daemon, btcwallet provides no user interface and an additional graphical or command line client is required for normal, personal wallet usage. Conformal has written btcgui as a graphical frontend to btcwallet.
This project is currently under active development is not production ready yet. Support for creating and using wallets the main Bitcoin network is currently disabled by default.
Installation
Windows - MSI Available
Install the btcd suite MSI here:
https://opensource.conformal.com/packages/windows/btcdsuite/
Linux/BSD/POSIX - Build from Source
-
Install Go according to the installation instructions here: http://golang.org/doc/install
-
Run the following commands to obtain and install btcwallet and all dependencies:
$ go get -u -v github.com/conformal/btcd/...
$ go get -u -v github.com/conformal/btcwallet/...
- btcd and btcwallet will now be installed in either
$GOROOT/binor$GOPATH/bindepending on your configuration. If you did not already add to your system path during the installation, we recommend you do so now.
Updating
Windows
Install a newer btcd suite MSI here:
https://opensource.conformal.com/packages/windows/btcdsuite/
Linux/BSD/POSIX - Build from Source
- Run the following commands to update btcwallet, all dependencies, and install it:
$ go get -u -v github.com/conformal/btcd/...
$ go get -u -v github.com/conformal/btcwallet/...
Getting Started
The follow instructions detail how to get started with btcwallet connecting to a localhost btcd.
Windows (Installed from MSI)
Open Btcd Suite from the Btcd Suite menu in the Start
Menu. This will also open btcgui, which can be closed if you only
want btcd and btcwallet running.
Linux/BSD/POSIX/Source
- Run the following command to start btcd:
$ btcd --testnet -u rpcuser -P rpcpass
- Run the following command to start btcwallet:
$ btcwallet -u rpcuser -P rpcpass
If everything appears to be working, it is recommended at this point to copy the sample btcd and btcwallet configurations and update with your RPC username and password.
$ cp $GOPATH/src/github.com/conformal/btcd/sample-btcd.conf ~/.btcd/btcd.conf
$ cp $GOPATH/src/github.com/conformal/btcwallet/sample-btcwallet.conf ~/.btcwallet/btcwallet.conf
$ $EDITOR ~/.btcd/btcd.conf
$ $EDITOR ~/.btcwallet/btcwallet.conf
Frontend Usage
Frontends wishing to use btcwallet must connect to the path
/frontend over a websocket connection. Messages sent to btcwallet
over this websocket are expected to follow the standard Bitcoin JSON
API (partially documented
here).
Websocket connections also enable additional API extensions and
JSON-RPC notifications (currently undocumented). The btcd packages
btcjson and btcws provide types and functions for creating and
JSON (un)marshaling these requests and notifications.
TODO
- Full RPC compatibility with bitcoind, including mining support
- RPC documentation (both bitcoind commands and btcwallet extensions available for websocket connections)
- P2SH and multisig functionality
- Improved test coverage
GPG Verification Key
All official release tags are signed by Conformal so users can ensure the code has not been tampered with and is coming from Conformal. To verify the signature perform the following:
-
Download the public key from the Conformal website at https://opensource.conformal.com/GIT-GPG-KEY-conformal.txt
-
Import the public key into your GPG keyring:
gpg --import GIT-GPG-KEY-conformal.txt -
Verify the release tag with the following command where
TAG_NAMEis a placeholder for the specific tag:git tag -v TAG_NAME
License
btcwallet is licensed under the liberal ISC License.