Currently, the only way to register HD version bytes is by initializing
chaincfg.Params struct, and registering it during package init.
RegisterHDKeyID provides a way to populate custom HD version bytes,
without having to create new chaincfg.Params instances. This is useful
for library packages who want to use non-standard version bytes for
serializing extended keys, such as the ones documented in SLIP-0132.
This function is complementary to HDPrivateKeyToPublicKeyID, which is
used to lookup previously registered key IDs.
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 modifies the UpdateLastBlockHeight function to ensure the new
height is after the existing height before updating it in order to
prevent it from going backwards so it properly matches the intent of the
function which is to report the latest known block height for the peer.
Without this change, the value will properly start out at the latest
known block height reported by the peer during version negotiation,
however, it will be set to lower values when syncing from the peer due
to requesting old blocks and blindly updating the height.
It also adds a test to ensure proper functionality.
This is a backport of https://github.com/decred/dcrd/pull/1747
- remove prep_release.sh and notes.sample
- update license in release.sh
- add notes for maintainers on the release process
- mention CHANGES file modifications
backport from https://github.com/decred/dcrd/pull/2253
When a peer sends a notfound message, remove the hash from requested
map. Also increase notfound ban score and return early if it
disconnects the peer.
To run integration tests with btcd on Windows in non-interactive
environments (such as the Travis build with Windows machines), we
need to make sure we can still spawn a child process instead of only a
windows background service.
The implementation has been adapted from the dcrec module in dcrd. The
bug was initially fixed in decred/dcrd@3d9cda1 while transitioning to a
constant time algorithm. A large set of test vectors were subsequently
added in decred/dcrd@8c6b52d.
The function signature has been preserved for backwards compatibility.
This means that returning whether the value has overflowed, and the
corresponding test vectors have not been backported.
This fixes#1170 and closes a previous attempt to fix the bug in #1178.
The current methods to add to a UtxoViewpoint don't allow for a situation where
we have only UTXO data but not a whole transaction. This commit allows
contstruction of a UtxoEntry without requiring a full MsgTx.
AddTxOut() and AddTxOuts() both require a whole transaction, including the inputs,
which are only used in order to calculate the txid. In some situations, such as
with use of the utreexo accumulator, we only have the utxo data but not the
transaction which created it.
For reference, utreexo's initial usage of the blockchain.NewUtxoEntry() function is at
https://github.com/mit-dci/utreexo/pull/135/files#diff-3f7b8f9991ea957f1f4ad9f5a95415f0R96
Without this, users of this library wouldn't be able to issue GetBlock
requests to nodes which haven't updated to support the latest request
format, namely the use of a single `int` parameter to denote verbosity
instead of two `bool`s.
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.
I started playing with simnet and was confronted with error message:
```
[ERR] FNDG: Unable to broadcast funding tx for ChannelPoint(<point>:0):
-22: TX rejected: transaction <tx> has witness data, but segwit isn't active yet
```
I wasn't aware of the activation period so I got quite puzzled.
Google helped. But I think the message could mention likely cause.
Newly it optionally prints something like:
```
(The threshold for segwit activation is 300 blocks on simnet, current best height is 113)
```
