Introduce an ECDSA signature verification into btcd in order to
mitigate a certain DoS attack and as a performance optimization.
The benefits of SigCache are two fold. Firstly, usage of SigCache
mitigates a DoS attack wherein an attacker causes a victim's client to
hang due to worst-case behavior triggered while processing attacker
crafted invalid transactions. A detailed description of the mitigated
DoS attack can be found here: https://bitslog.wordpress.com/2013/01/23/fixed-bitcoin-vulnerability-explanation-why-the-signature-cache-is-a-dos-protection/
Secondly, usage of the SigCache introduces a signature verification
optimization which speeds up the validation of transactions within a
block, if they've already been seen and verified within the mempool.
The server itself manages the sigCache instance. The blockManager and
txMempool respectively now receive pointers to the created sigCache
instance. All read (sig triplet existence) operations on the sigCache
will not block unless a separate goroutine is adding an entry (writing)
to the sigCache. GetBlockTemplate generation now also utilizes the
sigCache in order to avoid unnecessarily double checking signatures
when generating a template after previously accepting a txn to the
mempool. Consequently, the CPU miner now also employs the same
optimization.
The maximum number of entries for the sigCache has been introduced as a
config parameter in order to allow users to configure the amount of
memory consumed by this new additional caching.
This commit converts all block height references to int32 instead of
int64. The current target block production rate is 10 mins per block
which means it will take roughly 40,800 years to reach the maximum
height an int32 affords. Even if the target rate were lowered to one
block per minute, it would still take roughly another 4,080 years to
reach the maximum.
In the mean time, there is no reason to use a larger type which results
in higher memory and disk space usage. However, for now, in order to
avoid having to reserialize a bunch of database information, the heights
are still serialized to the database as 8-byte uint64s.
This is being mainly being done in preparation for further upcoming
infrastructure changes which will use the smaller and more efficient
4-byte serialization in the database as well.
This commit modifies the argument handling for btcctl to treat a
parameter that is a single dash as an indicator to read that paramter from
stdin instead.
This change allows commands, such as the submitblock, to accept data piped
from stdin for any parameter. This, in turn, allows large arguments, such
as blocks, which can often be too big for a single argument due to
Operating System limitations to be submitted by putting them into a file
and redirecting stdin.
For example:
btcctl submitblock - <block.hex
cat block.hex | btcctl submitblock -
btcctl sendrawtransaction - <tx.hex
cat tx.hex | btcctl sendrawtransaction -
This commit contains what is essentially a complete rewrite of the btcctl
utility to make use of the new features provided by the latest version
btcjson and improve several things along the way. The following
summarizes the changes:
- The supported commands and handling now come directly from btcjson, so
it is no longer necessary to manually add new commands. Once a command
has been registered with btcjson, it will automatically become usable by
btcctl complete with full error handling (once it is re-compiled of
course)
- Rather than dumping the entire list of commands on every error, the user
now must specifically request the list of command via the -l option
- The list of commands is now categorized by chain and wallet and
alphabetized
- The help flag now only shows the help options instead of also dumping
all of the commands
- The error display on valid commands with invalid parameters has been
greatly improved to show the specific parameter number, reason, and
error code
- When a valid command is specified with invalid parameter, only the usage
for that specific command is shown now
- It is now possible to use a SOCKS5 proxy for connection
- The output of commands has been improved in the following ways:
- Strings on commands such as getbestblockhash no longer have quotes
wrapped around them
- Fields that are integers no longer show in scientific notation when
they are large (timestamps for example)
This closes#305 as a side effect.
* Address index is built up concurrently with the `--addrindex` flag.
* Entire index can be deleted with `--dropaddrindex`.
* New RPC call: `searchrawtransaction`
* Returns all transacitons related to a particular address
* Includes mempool transactions
* Requires `--addrindex` to be activated and fully caught up.
* New `blockLogger` struct has been added to factor our common logging
code
* Wiki and docs updated with new features.
This utility is a relic from initial development before it was possible to
request blocks and transactions via RPC. The correct way to do this now
is by using RPC since that works while btcd is operating unlike the
utility which requires an exclusive lock on the database.
