The code was previously only changing the logging level if it wasn't the
default which is accurate for setting the log level once at startup time,
but it needs to set it unconditionally to allow dynamic updates.
Also, make every subsystem within btcd use its own logger instance so each
subsystem can have its own level specified independent of the others.
This is work towards #48.
Outbound we already have the exact same thing set up, and this should
quieten the race detector. Please note that this does *not* cause
problems with the service flags being wrong. Since by this point we have
already done every thing that would use the service flags from p.na in
addrmanager, and now p.Services is correct..
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
- Remove periods from --rpccert/--rpckey since none of the other options use
them
- Make it a little more clear that the --listen and --rpclisten options can be
used multiple times by changing the summary to start with "Add an ..."
which also matches the --addpeer style
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.
- Lock the mempool when removing transactions during a notification as
intended
- When generating the inventory vectors to serve on a mempool request,
recheck the memory pool for each hash since it's possible another thread
could have removed an entry after the initial query for available
hashes
- When a block is connected, remove any transactions which are now double
spends as a result of the newly connected transactions
The regression test mode is special and therefore most likely will not
want to use the same settings that are in the configuration file. The -C
option can still be used to specify a config file in regression test mode
if desired.
When a transaction is being checked for acceptance into the transation
memory pool, it makes use of a chain function to ensure the invariant rules
for what transactions are allowed into a block are not violated. That
function returns a btcchain.RuleError if rules are violated. However,
since this code path is tailored to free-standing transactions, the error
needs to be converted to a TxRuleError so the caller can properly detect
the transaction as a rejected transaction instead of treating it like an
real error.
This commit modifies the transaction memory pool handling so that it does
not relay resurrected transactions. The other peers on the network will
also be reorganizing to the same block, so they already know about them.
This commit makes use of the new default-mask go-flags option in
conjunction with delaying the usage display until after the config file is
parsed. This has a couple of nice properties such as showing the actual
values that will be used as loaded from the specific config file instead
of the defaults specified in btcd itself, and also allows any config file
parsing errors to be shown prior to displaying the usage.
This commit adds a few more checks to restrict what transactions are
allowed into the transaction memory pool and therefore are candidates
to be mined and relayed.
In particular, the following changes were made to what is considered
standard:
- nulldata scripts are now supported and considered standard
- multi-signature transaction are now checked to ensure they only have a
max of 3 pubkeys and the number of signatures doesn't exceed the number
of pubkeys
- the number of inputs to a signature script must now match the expected
number of inputs for the script type (includes support for additional
pay-to-script-hash inputs)
- the number of inputs pushed onto the stack by a redeeming sig script
must match the number of inputs consumed by the referenced pk script
- there can now only be a max of one nulldata output per transaction
