- Also update to use the new container-based builds
- Add coveralls.io support
- Update build badge to use SVG
- Add badges for coverage, license, and godoc
- For now, set it to change to he v2 directory
- This will need to be changed once the v1 code is replaced
This commit implements a reimagining of the way the btcjson package
functions based upon how the project has evolved and lessons learned while
using it since it was first written. It therefore contains significant
changes to the API. For now, it has been implemented in a v2 subdirectory
to prevent breaking existing callers, but the ultimate goal is to update
all callers to use the new version and then to replace the old API with
the new one.
This also removes the need for the btcws completely since those commands
have been rolled in.
The following is an overview of the changes and some reasoning behind why
they were made:
- The infrastructure has been completely changed to be reflection based instead
of requiring thousands and thousands of lines of manual, and therefore error
prone, marshal/unmarshal code
- This makes it much easier to add new commands without making marshalling
mistakes since it is simply a struct definition and a call to register that
new struct (plus a trivial New<foo>Cmd function and tests, of course)
- It also makes it much easier to gain a lot of information from simply
looking at the struct definition which was previously not possible
such as the order of the parameters, which parameters are required
versus optional, and what the default values for optional parameters
are
- Each command now has usage flags associated with them that can be
queried which are intended to allow classification of the commands such
as for chain server and wallet server and websocket-only
- The help infrastructure has been completely redone to provide automatic
generation with caller provided description map and result types. This
is in contrast to the previous method of providing the help directly
which meant it would end up in the binary of anything that imported the
package
- Many of the structs have been renamed to use the terminology from the
JSON-RPC
specification:
- RawCmd/Message is now only a single struct named Request to reflect the fact
it is a JSON-RPC request
- Error is now called RPCError to reflect the fact it is specifically an RPC
error as opposed to many of the other errors that are possible
- All RPC error codes except the standard JSON-RPC 2.0 errors have been
converted from full structs to only codes since an audit of the codebase
has shown that the messages are overridden the vast majority of the time
with specifics (as they should be) and removing them also avoids the
temptation to return non-specific, and therefore not as helpful, error
messages
- There is now an Error which provides a type assertable error with
error codes so callers can better ascertain failure reasons
programatically
- The ID is no longer a part of the command and is instead specified at the time
the command is marshalled into a JSON-RPC request. This aligns better with
the way JSON-RPC functions since it is the caller who manages the ID that is
sent with any given _request_, not the package
- All <Foo>Cmd structs now treat non-pointers as required fields and pointers as
optional fields
- All New<Foo>Cmd functions now accept the exact number of parameters, with
pointers to the appropriate type for optional parameters
- This is preferrable to the old vararg syntax since it means the code will
fail to compile if the optional arguments are changed now which helps
prevent errors creep in over time from missed modifications to optional args
- All of the connection related code has been completely eliminated since this
package is not intended to used a client, rather it is intended to provide
the infrastructure needed to marshal/unmarshal Bitcoin-specific JSON-RPC
requests and replies from static types
- The btcrpcclient package provides a robust client with connection management
and higher-level types that in turn uses the primitives provided by this
package
- Even if the caller does not wish to use btcrpcclient for some reason, they
should still be responsible for connection management since they might want
to use any number of connection features which the package would not
necessarily support
- Synced a few of the commands that have added new optional fields that
have since been added to Bitcoin Core
- Includes all of the commands and notifications that were previously in
btcws
- Now provides 100% test coverage with parallel tests
- The code is completely golint and go vet clean
This has the side effect of addressing nearly everything in, and therefore
closes#26.
Also fixes#18 and closes#19.
* Decouple logging and handling of distinct error messages for cases of
failed tx look up.
* This also fixes a bug wherein the `addrindexer` failed to lookup a tx
(since it didn't exist), but continued since the returned error was
nil.
This commit adds two new verification flags to txscript named
ScriptVerifyStrictEncoding and ScriptVerifyDerSignatures.
The ScriptVerifyStrictEncoding flag enforces signature scripts
and public keys to follow the strict encoding requirements.
The ScriptVerifyDerSignatures flag enforces signature scripts
to follow the strict encoding requirements.
These flags mimic Bitcoin Core's SCRIPT_VERIFY_STRICTENC and
SCRIPT_VERIFY_DERSIG flags and brings the Bitcoin Core test scripts up
to date.
This commit modifies the pre-computed table used to optimize the secp256k1
scalar multiplication to a string instead of a byte slice. This change
makes the compile more efficient since the Go compiler internally
represents bytes slices inefficiently.
This reduces the memory needed to compile btcec to 3MB versus the previous
40MB before this change.
In addition, it modifies the code which loads the pre-computed table to
deserialize directly into the table instead of into locals that are then
copied.
Fixes#297.
This commit corrects a case in the OP_CHECKMULTISIG handling where it was
possible to improperly validate a transaction that had a combination of
valid and malformed signatures.
It also adds a new test to ensure this case is properly handled and nukes
a superfluous comment.
Fixes#293.
This commit adds a new example to the txscript package that demonstrates
creating a new transaction which redeems funds and signing the referenced
transaction output the SignTxOutput function.
This commit contains various modifications for code and comment
consistency in the btcec package:
- Call out references at the top and reference them by their identifier in
the other comments
- Remove a TODO that no longer applies
- Add comments to the fields in the KoblitzCurve struct and reorder them
slightly
- Make comments wrap to 80
- Cleanup code that was far exceeding col 80 (only function declarations
typically do this)
- Extend block comments to use as much of the 80 cols as available
- Add a bit more explanation in a couple of places
- Update copyright year on secp256k1.go
- Fix a couple of typos in the comments
The benchmarks are still only compiled when running 'go test' so this has
no effect on regular usage. This is being done because benchmarks often
need access to internal state.
Normal tests are kept in a separate package since they also serve to
exercise the public API, and by intentionally making it more difficult to
reach into the internals, it helps ensure the public API is sanely usable.
Since the benchmarks can now access the internals directly, this commit
also removes the functions which exposed the internals to the test package
from internal_test.go which were only used by the benchmarks.
Also, it removes a duplicate benchmark.
This commit converts the initialization of the constants to use a function
which panics on error instead of just ignoring the error. This is
acceptable since they are hard-coded constants and should never fail.
This commit adds code which generates the linearly independent vectors
used by the secp256k1 endomorphism code. These value are hard-coded into
the curve already, but having the code used to generate them is handy
should any future curves be added which can also make use of the same
class of endomorphism.
This commit contains the entire btcnet repository along with several
changes needed to move all of the files into the chaincfg directory in
order to prepare it for merging. This does NOT update btcd or any of the
other packages to use the new location as that will be done separately.
- All import paths in the old btcnet test files have been changed to the
new location
- All references to btcnet as the package name have been changed to
chaincfg
- The coveralls badge has been removed since it unfortunately doesn't
support coverage of sub-packages
This is ongoing work toward #214.
* 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.
Use Non-Adjacent Form (NAF) of large numbers to reduce ScalarMult computation times.
Preliminary results indicate around a 8-9% speed improvement according to BenchmarkScalarMult.
The algorithm used is 3.77 from Guide to Elliptical Curve Crytography by Hankerson, et al.
This closes#3
This implements a speedup to ScalarMult using the endomorphism available to secp256k1.
Note the constants lambda, beta, a1, b1, a2 and b2 are from here:
https://bitcointalk.org/index.php?topic=3238.0
Preliminary tests indicate a speedup of between 17%-20% (BenchScalarMult).
More speedup can probably be achieved once splitK uses something more like what fieldVal uses. Unfortunately, the prime for this math is the order of G (N), not P.
Note the NAF optimization was specifically not done as that's the purview of another issue.
Changed both ScalarMult and ScalarBaseMult to take advantage of curve.N to reduce k.
This results in a 80% speedup to large values of k for ScalarBaseMult.
Note the new test BenchmarkScalarBaseMultLarge is how that speedup number can
be checked.
This closes#1
This commit reworks the way that the pre-computed table which is used to
accelerate scalar base multiple is generated and loaded to make use of the
go generate infrastructure and greatly reduce the memory needed to compile
as well as speed up the compile.
Previously, the table was being generated using the in-memory
representation directly written into the file. Since the table has a very
large number of entries, the Go compiler was taking up to nearly 1GB to
compile. It also took a comparatively long period of time to compile.
Instead, this commit modifies the generated table to be a serialized,
compressed, and base64-encoded byte slice. At init time, this process is
reversed to create the in-memory representation. This approach provides
fast compile times with much lower memory needed to compile (16MB versus
1GB). In addition, the init time cost is extremely low, especially as
compared to computing the entire table.
Finally, the automatic generation wasn't really automatic. It is now
fully automatic with 'go generate'.
