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.
in go-flags/ini_private.go in function readIni there is no mechanism for
adding inline comments. Only comments that have a semicolon as the first
non-whitespace character are ignored.
According to Wikipedia http://en.wikipedia.org/wiki/INI_file#Comments
inline comments are not universally supported.
This change adds some white space for readability, but
name := strings.TrimSpace(line[1 : len(line)-1]) removes accidental whitespace
left in later.
Closes#135.
