The submitblock RPC returns a string containing an error if it failed for
any reason. This comment detects a non-null return from submitblock and
converts that string to an error which is returned.
This commit adds a new behavior flag, BFNoPoWCheck which allows the caller
to indicate the check which ensures a block hashes to a value less than
required target should not be performed.
This commit change the ProcessBlock function to accept a new type named
BehaviorFlags in place of the current fastAdd parameter.
This has been done to pave the way for adding more control over the checks
that are performed such as avoiding the proof of work checks which will be
in an upcoming commit. A bitmask was chosen because it will allow the
ProcessBlock API to remain a little more stable since new flag additions
that change the behavior are only likely to be used by new code because
adding flags does not change the existing behavior.
ok @jrick
This commit modifies the TLS setup to only override the RootCAs for the
TLS connection if certificates are specified. This allows the
Certificates parameter to be ommitted from the connection config to use
the system CAs.
Now that the ProcessBlock function returns whether or not the block was an
orphan, the code which requests the parent blocks from the peer that sent
them has been moved to directly after the call to it.
This makes the handling more obvious and has allowed removal of the
blockPeer map which was kept so the notification handler could identify
which peer to request the blocks from.
ok @jrick
This commit changes the way that orphan blocks are identified by adding a
new boolean return value on ProcessBlock and removing the notification for
NTOrphanBlock.
This allows the calling code to identify orphan blocks immediately instead
of having to setup a seperate callback handler and implementing some type
of state tracking. This, in turn, allows cleaner code for handling them.
In addition, the tests have been updated for the new function signature
and also now check that each block is or is not an orphan as expected
which makes the tests more robust.
ok @jrick
This commit changes the RuleError type to a struct which consists of an
error code and human-readable description.
From a usage perspective, existing code should not break since type
asserting an error to a RuleError still works in the same manner. The
difference is the caller can now take that type asserted RuleError and
access the .ErrorCode field on it to programmatically identify the
specific rule that was violated.
ok @jrick
If connecting to a bitcoin RPC server as an HTTP POST client, full
response objects rather than just the raw result bytes were being
passed to the specific result unmarshalers, causing unmarshal errors
for the incorrect JSON types. To fix this, first unmarshal the
response body into a rawResponse, and pass only the raw result bytes
(or an error) to the specific handlers.
This was reported by nskelsey on IRC.
ok @davecgh
This reasons for this change follow:
- All instances of the same key should be consistent amongst the commands
and returns
- Output indices can't be negative, so rather than adding more code to
check for a negative after unmarshal, just allow the unmarshal to weed
out negatives
ok @jcvernaleo
While here, fix a bug found through testing. Register will now return
ErrDuplicateNet if the caller attempts to register any of the standard
network parameters provided by this package.
ok @davecgh
There are certain RPCs where an address should be sent as the raw string
instead of the encoded bitcoin address since the RPC handler on the other
end expects "keys" instead of Bitcoin addresses.
For example, the multisignature RPCs addmultisigaddress and createmultisig
can work with pubkeys (compressed, uncompressed, or hybrid) as well as
Bitcoin addresses.
The original issue which prompted these changes was report by Paul Snow on
IRC.
This value matches testnet and mainnet and makes more sense because it
allows way more coins to be generated which is useful during simulation
testing.
NOTE: this will invalidate existing simnet chains, but since they
are only intended to be short lived for the duration of a simulation test,
this is a non-issue.
Now that btcd support CPU mining, update the getgenerate, setgenerate,
gethashespersec, and getmininginfo RPC handlers to return the appropriate
information.
Also, remove the various extra help addenda about btcd not supporting
mining since it is no longer true.
This commit implements a built-in concurrent CPU miner that can be enabled
with the combination of the --generate and --miningaddr options. The
--blockminsize, --blockmaxsize, and --blockprioritysize configuration
options wich already existed prior to this commit control the block
template generation and hence affect blocks mined via the new CPU miner.
The following is a quick overview of the changes and design:
- Starting btcd with --generate and no addresses specified via
--miningaddr will give an error and exit immediately
- Makes use of multiple worker goroutines which independently create block
templates, solve them, and submit the solved blocks
- The default number of worker threads are based on the number of
processor cores in the system and can be dynamically changed at
run-time
- There is a separate speed monitor goroutine used to collate periodic
updates from the workers to calculate overall hashing speed
- The current mining state, number of workers, and hashes per second can
be queried
- Updated sample-btcd.conf file has been updated to include the coin
generation (mining) settings
- Updated doc.go for the new command line options
In addition the old --getworkkey option is now deprecated in favor of the
new --miningaddr option. This was changed for a few reasons:
- There is no reason to have a separate list of keys for getwork and CPU
mining
- getwork is deprecated and will be going away in the future so that means
the --getworkkey flag will also be going away
- Having the work 'key' in the option can be confused with wanting a
private key while --miningaddr make it a little more clear it is an
address that is required
Closes#137.
Reviewed by @jrick.
