Code uses a windowing/precomputing strategy to minimize ECC math.
Every 8-bit window of the 256 bits that compose a possible scalar multiple has a complete map that's pre-computed.
The precomputed data is in secp256k1.go and the generator for that file is in gensecp256k1.go
Also fixed a spelling error in a benchmark test.
Results so far seem to indicate the time taken is about 35% of what it was before.
Closes#2
This change removes transactions from a newly connected block
from the orphan pool if they exist. Additionally, any orphan
transactions that are no longer orphan transactions are moved
to the mempool and inv'd to the currently connected peers.
This commit adds a couple of options which were not details in the sample
config file. It also fixes a couple of typos and makes the example default
maxpeers setting in the config file match the actual default used in btcd.
The go vet command complains about untagged struct initializers when
defining a ShaHash directly. This seems to be a limitation where go vet
does not exclude the warning for types which are a constant size byte
array like it does for normal constant size byte array definition.
This commit simply modifies the code to use a constant definition cast to
a ShaHash to overcome the limitation of go vet.
Add the word 'string' to the error string so if this is printed, it
will be clearer that it was a hash string decode that failed (as
opposed to other errors creating a ShaHash from a byte slice) and
change 'chars' to 'bytes', since the string length is measured in
bytes, not UTF-8 code points.
ok @davecgh
The go vet command complains about untagged struct initializers when
defining a ShaHash directly. This seems to be a limitation where go vet
does not exclude the warning for types which are a constant size byte array
like it does for normal constant size byte array definition.
This commit simply modifies the tests to use a constant definition cast to a
ShaHash to overcome the limitation of go vet.
This commit explicitly ignores errors that were already intentionally
ignored in btcctl by using an _ to make the errcheck utility happy. It is
also nice to make it explicit that the error is being ignored
intentionally rather than leave questions of whether it was accidentally
forgotten.
This commit resolves a minor issue where an error in the config file would
prevent the help from being shown until the config file error was
resolved.
This results in the following behavior:
- With a malformed header:
$ ./btcd
Error parsing config file: ~/btcd/btcd.conf:14: malformed section header
Use btcd -h to show usage
- With an invalid option:
$ ./btcd
Error parsing config file: unknown option: bogus
Use btcd -h to show usage
- Invoking help with an error in the config file:
$ ./btcd -h
Usage:
...
- Invoking with an invalid command line option:
$ ./btcd --bogus=bogus
unknown flag `bogus'
Use btcd -h to show usage
ok @jrick
This commit builds on the recent limiter updates. The recent changes
introduced a new function named calcTxFee which could easily be confused
with calculating the fees of the transaction rather than its intended
purpose of calculating the minimum transaciton relay fee.
Rather than taking that approach, this commit instead renames the existing
function to calcMinRequiredTxRelayFee and uses a consistent variable name
for the serialized size of a transaction. It then moves the check for
whether or not the check should be applied based on the serialized size of
the transcation and block priority to the call site.
This approach also has the benefit of avoiding two calls to the
calculation function since it's a local at the call site.
ok @jrick, @dajohi
Before, btcd was rate limiting all transactions that had a minimum
fee of zero. Now, btcd only rate limits transactions that contain
a fee less than the calculated fee based on size.
Closes#163
This commit adds an example test file so it integrates nicely with Go's
example tooling.
This allows the example output to be tested as a part of running the
normal Go tests to help ensure it doesn't get out of date with the code.
It is also nice to have the examples in one place rather than repeating it
in doc.go and README.md.
Links and information about the examples have been included in README.md in
place of the examples and doc.go has been updated accordingly.
