This was previously done within the OnVersion listener, which should not
be a blocking operation. It turns out that requesting these messages
there can lead to blocking due to peers not being able to process
messages since their message queues have yet to start. Therefore, we'll
now request within handleAddPeerMsg, which should allow it to go
through.
This change is needed as part of requiring peers to also send a verack
message following their version message during protocol negotiation.
Peers were previously added to the SyncManager before their message
queues were started, causing the server to stall if a peer didn't
provide a timely verack response following their version. We now do this
within OnVerAck, which happens shortly before peer message queues are
started.
This makes the logic a bit more unified as previously it was possible we
for us to report the new peer to the SyncManager, but for whatever
reason failed to track the peer in the server internally within AddPeer.
This change ensures this can no longer happen.
This commit fixes an issue introduced in the recent #1429, where
the output of SqrtVal is not normalized before using IsOdd() to compare
with the expected parity of the y-coordinate. The IsOdd() is only
guaranteed to work if the value has been denormalized, so a denormalized
sqrt >= p would report the opposite parity. We fix this by normalizing
both after compute sqrt(x^3) and when negating the root as directed by
the ybit.
In this commit, we add the new release script that will be used to build
all release binaries going forward. We also remove the existing
Conformal key as it's no longer in use, updating the README to reflect
the new release build/verification process.
Doing so ensures we reach our target number of outbound peers as soon as
possible. This is only necessary after calls to connmgr.Remove, as these
won't request a new peer connection.
The Disconnect method would still attempt to reconnect to the same
peer, which could cause us to reconnect to bad/unstable peers if we came
across them. Instead, we'll now use Remove whenever we intend to remove
a peer that is not persistent.
We do this to ensure the address manager contains live addresses.
Previously, addresses with which we established connections with would
not be marked as connected because it would be done once we disconnect
peers. Given that we don't process all of the disconnect logic when
we're shutting down, addresses of stable and good peers would never be
marked as connected unless the connection was lost during operation.
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
