The addblock utility was originally written as a quick debug tool during
initial development to populate blocks into the database. However, now
that it has been designated as the standard way to import bootstrap.dat
(and indeed block data files in general), it was lacking a few features
such as properly checking against the chain rules and known good
checkpoints.
This commit reworks and improves the utility in several ways:
- Imported blocks are now checked against the chain rules including
checkpoints to ensure they match the known good chain
- The utility now properly shuts down after processing all blocks
- Attempting to import orphan blocks (blocks which build off a block you
don't yet have in the database) returns an error
- Blocks that are already known are now skipped instead of causing an
error which means you can stop and restart the import mid-way through
without issues or start it after you've already downloaded a
portion of the chain
- The block height is no longer assumed to start at 0 which means input
files that start later in the chain will work properly so long as you
already have the chain at least up to the point of the block just before
the first one in the input file
- Improved error handling and reporting
- How often the progress display is shown is now configurable
- Statistics about how many blocks were processed, imported, and already
known are now displayed after the input file has been fully processed
This resolves comments made in #60.
This commit adds a new function to btcctl that shows the results as
properly indented JSON instead of relying on spew and changes all of the
commands that used spew to the new function. The output of btcctl
should be more user-facing than developer-facing.
This commit modifies btcctl to show float values with %f instead of the
default %v. This means the values will show similar to 1180923195.260000
instead of 1.18092319526e+09 (scientific notation).
This commit adds version information to btcctl. The plan is to keep
it in lock step with the btcd version. It also updates the release script
so the version file is updated automatically with the btcd one.
This commit improves the configuration for btcctl in several ways:
- Add the ability to specify a config file
- Add a default entry to the rpc cert to point to the location
it will likely be in the btcd home directory
- Move the config bits into a separate file for easier maintenance
All rpc sockets now listen using TLS by default, and this can not be
turned off. The keys (defauling to the datadirectory) may be provided by
--rpccert and --rpckey. If the keys do not exist we will generate a new
self-signed keypair with some sane defaults (hostname and all current
interface addresses).
Additionally add tls capability to btcctl so that it can still be used.
The certificate to use for verify can be provided on the commandline or
verification can be turned off (this leaves you susceptible to MITM
attacks)
Initial code from dhill (rpc tls support) and jrick (key generation),
cleanup, debugging and polishing from me.
So far we only do level 0 and level 1 checks (precense and basic
sanity). The checks done at higher levels in bitcoind are closely
coupled with their database layout.
arguably Closes#13
Rather than having to keep the usage in sync with the supported commands,
simply include the usage as a field in the command handlers map and
dynamically generate the usage from there.
This commit modifies the command handler in btcctl to check the existence
of a display handler before issues an RPC command. This prevents a round
trip to the server if there is no display handler.
Also, fix a couple of comments while here.
This commit significantly reworks btcctl to use a map based approach to
command handling. This reduces the number of lines of code needed,
simplifies adding new commands, improves the error handling, and removes
several cases where unexpected data was not handled properly (it could
panic).
This commit also adds the ability to specify the optional parameter on
getrawtransaction.
Discussed with dhill@.
This change paves the way for running btcwallet on the same system without
having to change any settings. The well-known ports used by the
reference implementation (8332 mainnet, 18332 testnet) will be exposed by
the separate wallet process, which will in turn forward unknown requests
to btcd via websockets (on 8334/18334). This allows the wallet process to
ultimately provide a unified interface that exposes the same RPC-JSON API
as the reference implementation will maintaining wallet and chain
separation.
