This commit adds a new boolean field, `V2Connection`, to the
`getpeerinfo` RPC result. This field indicates whether the connection
to the peer is using the v2 encrypted transport protocol.
The `peer.StatsSnap` struct is updated to include this `V2Connection`
field, which is populated based on the `UsingV2Conn` field in the peer's
configuration. The `btcjson.GetPeerInfoResult` struct is also updated
to include the corresponding JSON field `v2_connection`. Finally, the
`handleGetPeerInfo` RPC handler is modified to copy this value from the
peer's stats snapshot into the RPC response.
This commit introduces the concept of `AlwaysActiveHeight` to the
deployment mechanism, allowing a deployment to be forced into the active
state if the next block's height meets or exceeds this threshold.
This is intended primarily to be used alongside the new Testnet4
deployment, as the past major soft forks are meant to be active from the
very first block height.
This commit changes the `RejectReason` resulted from calling
btcd's `testmempoolaccept` to be un-matched, leaving it to the caller to
decide when and where to match it.
This commit creates a `RejectReasonMap` to map the errors returned from
`btcd` to bitcoind's `testmempoolaccept` so the `RejectReason` is
unified at the RPC level. To make sure the map keys are unique, the
error strings are modified in `btcd`.
This change is part of the effort to add pruning support to btcd.
Now that pruning is allowed in btcd, accurately report the prune status
back to the user.
In this commit, we add the deployment parameters of taproot as specified
in the deployment section of BIp 341:
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#deployment.
Take note of the custom activation threshold, as well as the specified
min activation heights for mainnet only.
In this commit, we create a new package to house the ECDSA-specific
logic in the new `btcec/v2` pacakge. Thsi c hange is meant to mirror the
structure of the `dcrec` package, as we'll soon slot in our own custom
BIP-340 implementation.
In this commit, we add a new "dummy" deployment that adds the new params
used to activate taproot. We chose to add a new deployment as unlike the
bitcoind codebase, we don't currently "bury" soft forks that have
happened in the past (hard code an activation height).
The old taproot deployment has been removed as with the way the array
works, a deployment needs to be defined for _all_ networks.
In this commit, we utilize the recently added ConsensusDeploymentStarter
and ConsensusDeploymentEnder interfaces. Concrete implementations of
this interface based on the median time past comparison are used now in
the ConsensusDeployment struct instead of hard coded start/end times.
Along the way, we had to switch to using the "zero time": time.Time{},
in place of 0 and math.MaxInt64 as comparison (After/Before) seems to be
broken in the Go stdlib for times very far in the future. It appears Go
isn't ready to handle the heat death of the universe.
In this commit, we update all the btcutil imports to point to the new
sub-module.
In the same commit, we also modify the recently added `btcutil/go.mod`
file as we need to continue pointing to the _old_ version of btcd, until
we merge this PR and push a new tag.
When processRequest can't find a rpc command, standardCmdResult returns
a `btcjson.ErrRPCMethodNotFound` but it gets ignored and a
`btcjson.ErrRPCInvalidRequest` is returned instead.
This makes processRequest return the right error message.
Updated the rpcserver handler for validateaddress JSON-RPC command to
have parity with the bitcoind 0.20.0 interface.
The new fields included are - isscript, iswitness, witness_version, and
witness_program. The scriptPubKey field has been left out since it
requires wallet access.
This update has no impact on the rpcclient.ValidateAddress method,
which uses the btcjson.ValidateAddressWalletResult type for modelling
the response from bitcoind.
This change makes btcd's getblock command match bitcoind's. Previously
the default verbosity was 0, which caused errors when using the
rpcclient library to connect to a bitcoind node - getblock would
unmarshall incorrectly since it didn't expect a verbosity=1 result when
it did not specify verbosity.
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.
backport of https://github.com/decred/dcrd/pull/1273
Notable difference being that btcd mainline currenlty
doesn't have a blockchain/blockindex_test.go file, so
those changes are omitted.
Great work @davecgh :)
