Refactor GetBlockVerboseResult into two separate types: one type for getblock "hash" verbosity=1,
and a second type for getblock "hash" verbosity=2. This is necessary due to how getblock returns
a block's transaction data based on the provided verbosity parameter.
If verbosity=1, then getblock.Tx is an array of a block's transaction ids (txids) as strings.
If verbosity=2, then getblock.Tx is an array of raw transaction data.
Due to differences in how getblock returns data based on the provided verbosity parameter, it's necessary
to have two separate return types based on verbosity. This necessitates a separate unmarshalling function
(represented throughout rpcclient/chain.go as Result.Receive()) to ensure that data is correctly unmarshalled
and returned to the user.
* rpcclient: replace futures mainnet with params
Adds a chaincfg.Params to the Client
rpcclient: parse config to assign params
* rpcclient: change address commands to Address
* Change address future struct to contain a network field, so futures
can return the correct type for Receive
Due to differences in how getblock returns data based on the provided verbosity parameter, it's necessary
to have two separate return types based on verbosity. This necessitates a separate unmarshalling function
(represented throughout rpcclient/chain.go as Result.Receive()) to ensure that data is correctly unmarshalled
and returned to the user.
and a second type for getblock "hash" verbosity=2. This is necessary due to how getblock returns
a block's transaction data based on the provided verbosity parameter.
If verbosity=1, then getblock.Tx is an array of a block's transaction ids (txids) as strings.
If verbosity=2, then getblock.Tx is an array of raw transaction data.
$GOPATH caching has led to flaky tests as per #1503 and #1536. The speedup is marginal and while the false negatives are a headache, false positives are potentially dangerous.
This addresses an issue where the server ends up tracking a peer that
has been disconnected due to it processing a peer's `done` message
before its `add` message.
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.
