The previous naming suggested that the value ((P+1)/4+1)/4 was being
returned, when in fact the returned value is simply (P+1)/4. The old
method is superseded by Q().
This commit optimizes the decompressPoint subroutine, used in extracting
compressed pubkeys and performing pubkey recovery. We do so by replacing
the use of big.Int.Exp with with square-and-multiply exponentiation of
btcec's more optimized fieldVals, reducing the overall latency and
memory requirements of decompressPoint.
Instead of operating on bits of Q = (P+1)/4, the exponentiation applies
the square-and-multiply operations on full bytes of Q. Compared to the
original speedup. Compared the bit-wise version, the improvement is
roughly 10%.
A new pair fieldVal methods called Sqrt and SqrtVal are added, which
applies the square-and-multiply exponentiation using precomputed
byte-slice of the value Q.
Comparison against big.Int sqrt and SAM sqrt over bytes of Q:
benchmark old ns/op new ns/op delta
BenchmarkParseCompressedPubKey-8 35545 23119 -34.96%
benchmark old allocs new allocs delta
BenchmarkParseCompressedPubKey-8 35 6 -82.86%
benchmark old bytes new bytes delta
BenchmarkParseCompressedPubKey-8 2777 256 -90.78%
As of https://github.com/btcsuite/btcd/pull/1193, decompressPoint now
validates that the point is on the curve. The x and y cooordinates are
also implicitly <= P, since the modular reduction is applied to both
before the method returns. The checks are moved so that they are still
applied when parsing an uncompressed pubkey, as the checks are not
redundant in that path.
It was possible for connections to bitcoind nodes to be closed from
their side if the OnVersion callback queued a message to send. This is
because bitcoind expects a verack message before attempting to process
any other messages. To address this, we ensure the verack is sent as
part of the handshake process, such that any queued messages happen
after the fact.
In this commit, we fix a bug in the rescan logic after a recent
refactoring that would cause the scanning node to potentially panic. If
the client disconnected, before the rescan was finished, then we would
return a nil `lastBlock` and `lastBlockHash`. We would then attempt to
send the rescan finished notification, causing a panic.
We remedy this by simply detecting this case (client disconnect), and
existing once again as the prior code would, pre-refactoring.
In this commit, we implement an optimization that will speed up clients
that attempt to perform a rescan in the past with no addresses. If the
client doesn't have any thing to search for, then we simply exit early
and send them a rescan finished notification with the final block in our
chain.
Adds stall detection when no blocks have been received from the sync
peer for at least 3 minutes.
The change backports parts of https://github.com/gcash/bchd/pull/105,
though has different behavior, such as:
- Rotating the sync peer at tip.
- Only disconnecting the sync peer if they're height exceeds our own.
Since we will instead rotate the sync peer at tip, this prevents us
from disconnecting good peers while waiting for new blocks.
- Not resetting the progress time when blocks are submitted via rpc.
In this commit, we update to the latest version of btcutil which
contains a bug fix for filter matching, and as optimizations speed up
both filter matching and constructions.
This commit modifies the sync peer selection to prefer peers with a
higher advertised height than our currently known best height. If no
peers are known with a higher height, we will fall back to selecting a
random peer with the same best height as our own.
The current algorithm currently selects a random peer from the union of
these two sets, while this approach will favor trying to make progress.
This will likely help in selecting a good peer once already at tip, such
as after a restart.
Backport of https://github.com/gcash/bchd/pull/96
In this commit, we update to the latest version of `btcutil`. This version
contains a bug fix for the neutrino filter generation. The implementation
within `btcutil` didn't fully comply with the BIP specification as it
included some OP_RETURN outputs, rather than excluding them all. As a
result, any active `btcd` node on mainnet/testnet will need to _drop their
entire `cfindex`_ and re-index after this is merged in.
In this commit, we update the serialized version of the AddressManager
to also store each address' service bits. This allows an address'
service bits to be properly set when read from disk, which allows
external callers to reliably filter out addresses which do not support
their required services.
Since the service bits were not previously stored, the serialization
version needed to be bumped. A test has been added to test the behavior
of upgrading from version 1 to 2.
In this commit, we modify the rescanBlock method to also determine
whether a script (encoded as an address in its rescanKeys) has been
spent. Upon detecting a spend, a btcjson.RedeemingTxNtfn is sent to the
client who requested it.
In this commit, we modify the rescanKeys struct, which contains the
relevant keys that should be matched when rescanning the chain, to take
addresses in their string representation. This ends up simplifying a lot
of the logic as we no longer have to special-case specific script types.
