The fields of the PeerInfo should not have been marked omit as the only
ones that should be omitted to for compatibility are the SyncNode and
BanScore fields.
In order to match the Satohsi client, the return is supposed to be an
8-digit string representation of the services instead of the actual
services numeric value.
The ScriptSig field of the Vin type for TxRawResult is now a pointer in
btcjson so it can be properly omitted. This commit updates the code to
create the new ScriptSig object as needed.
The previous commit modified the Vin ScriptSig field to be a pointer to an
anonymous struct so it could be properly omitted. However, the callers
need to be able to create a new object to assign to the field, so this
commit makes the previous anonymous struct an exported type named
ScriptSig.
In order for a field which is a struct to be omitted from JSON
marshal/unmarshal, it must be a pointer so the json package can tell when
it's empty (when it's nil).
The getrawtransaction RPC call should return a hex-encoded string of the
transaction when verbose is false instead of a TxRawResult object with the
Hex field set to be compatible with the Sathoshi client. This commit,
along with a recent commit to btcjson corrects this.
Also, while here, do a bit of cleanup, finish a TODO to check for an
invalid hash, and optimize the handling of non-verbose slightly.
The getrawtransaction command has recently added a verbose flag which
alters the output. The previous code made use of the "Hex" field of the
TxRawResult to return the information, but this is not consistent with the
original getrawtransaction RPC call which returns a string when verbose is
false and the TxRawResult JSON object when it is true.
This commit corrects that by allowing the result for getrawtransaction to
be either form.
The getblock RPC call should return a hex-encoded string of the block when
verbose is false instead of a BlockResult object with a Hex field set to
be compatible with the Sathoshi client. This commit, along with a recent
commit to btcjson corrects this.
Also, while here, move code which only applies to verbose mode after the
call which handles the non-verbose logic. This saves a few cycles since
the non-verbose logic doesn't need the extra information.
The getblock command has recently added a verbose flag which alters the
output. The previous code added a new field "Hex" to the BlockResult, but
this is not consistent with the origin getblock RPC call which returns a
string when verbose is false and the BlockResult JSON object when it is
true.
This commit corrects that by first removing the Hex field from the
BlockResult and second allowing the result for getblock to be either form.
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).
The fee field of the getrawmempool RPC JSON response should be in Bitcoins
instead of Satoshi. This commit corrects that issue.
Also, add a couple of comments and fix a comment typo while here.
Since there is already a variable for the current block height in addition
to the next block height, use the existing curHeight variable instead
doing nextBlockHeight-1 in mempool add.
This commit does some housekeeping on peer.go to make the code more
consistent, correct a few comments, and add new comments to explain the
peer data flow. A couple of examples are variables not using the standard
Go style (camelCase) and comments that don't match the style of other
comments.
Instead of one thread that queues and writes, we move to a two queue
model. The queueHandler muxes all the sources of outgoung packets and
drips them to the actual sender. This is done so that a large send
doesnt' allow the channels to fillup and cause blockmanager and server
to block, which delays other peers.
Most messages we handle as is. However, for getdata we do some manual
limiting and pipelining, we queue up three and then we load the next
into memory, not sending it until the otherp ackets have been sent. We
may want to change this later to queue the packet *then* wait so that we
don't completely drain the pipe.
A few misc tweaks to avoid deadlocking by ensuring the all channels will
always drain. mostly this relates to ensuring that we know no more data
will be coming before we drain the channel, and not queueing after we
are marked to disconnect.
Discussed heavily with drahn@ and davec@.
This commit modifies the code to use the new btcec Signature.Serialize API
instead of the internal sigDER which has now been removed. This closes#3.
ok @owainga
This commit exposes a new function named Serialize on the Signature type
which can be used to obtain a DER encoded signature. Previously this
function was named sigDer and was part of btcscript, but as @donovanhide
pointed out in issue btcscript/#3, it really should have been part of this
package.
ok @owainga
Since the function was only exported for use by the test package (and was
commented as such), just move it into the internal_test.go file so it is
only available when the tests run.
This commit essentially rewrites all of the primitives needed to perform
the arithmetic for ECDSA signature verification of secp256k1 signatures to
significantly speed it up. Benchmarking has shown signature verification
is roughly 10 times faster with this commit over the previous.
In particular, it introduces a new field value which is used to perform the
modular field arithmetic using fixed-precision operations specifically
tailored for the secp256k1 prime. The field also takes advantage of
special properties of the prime for significantly faster modular reduction
than is available through generic methods.
In addition, the curve point addition and doubling have been optimized
minimize the number of field multiplications in favor field squarings
since they are quite a bit faster. They routines also now look for
certain assumptions such as z values of 1 or equivalent z values which
can be used to further reduce the number of multiplicaitons needed when
possible.
Note there are still quite a few more optimizations that could be done
such as using precomputation for ScalarBaseMult, making use of the
secp256k1 endomorphism, and using windowed NAF, however this work already
offers significant performance improvements.
For example, testing 10000 random signature verifications resulted in:
New btcec took 15.9821565s
Old btcec took 2m34.1016716s
Closesconformal/btcd#26.
This changes notifications to JSON-RPC Requests, rather than
Responses, that also satisify the btcjson.Cmd interface and are
registered with btcjson's parser. This prevents issues where JSON-RPC
Response IDs clash due to a client using the same ID as what an old
notification used.
As this changes the API, and thus, requires notification handlers to
be modified, the remaining missing notifications used by btcwallet
have been implemented. Applications parsing these notifications, such
as btcgui, can now use a common handler function signature for all
notifications.
Test coverage for all notifications has been added (excluding testing
for badly-marshaled notifications with wrong numbers of parameters, or
wrong types).
Fixes#2.
The regression test does not work properly with the new headers-first
download approach, so force the old inv-based block download for
regression test mode.
It is not necessary to do all of the transaction validation on
blocks if they have been confirmed to be in the block chain leading
up to the final checkpoint in a given blockschain.
This algorithm fetches block headers from the peer, then once it has
established the full blockchain connection, it requests blocks.
Any blocks before the final checkpoint pass true for fastAdd on
btcchain operation, which causes it to do less valiation on the block.
It is not necessary to do all of the transaction validation on
blocks if they have been confirmed to be in the block chain leading
up to the final checkpoint in a given blockschain.
This algorithm fetches block headers from the peer, then once it has
established the full blockchain connection, it requests blocks.
Any blocks before the final checkpoint pass true for fastAdd on
btcchain operation, which causes it to do less valiation on the block.
