sikkienl/dash
1
0
Fork 0
mirror of https://github.com/dashpay/dash.git synced 2024-12-24 19:42:46 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge #6165: [v21.0.x] backport: 21.0.1 backports and release notes

Browse Source 
5619c8f5fd docs: add release notes for v21.0.1 and archive v21.0.0 (pasta)
9e80d128c0 Merge #6163: fix: use blocks-only instead of address-only for inventory (pasta)
e10c5c9579 Merge #6160: feat: add sbom and provenance in release for dockerhub; use jammy; apt remove as possible (pasta)

Pull request description:

  ## Issue being fixed or feature implemented
  Backport PRs for v21.0.1

  ## What was done?
  See commits

  ## How Has This Been Tested?
  See CI

  ## Breaking Changes
  None

  ## Checklist:
    _Go over all the following points, and put an `x` in all the boxes that apply._
  - [x] I have performed a self-review of my own code
  - [ ] I have commented my code, particularly in hard-to-understand areas
  - [ ] I have added or updated relevant unit/integration/functional/e2e tests
  - [ ] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_

ACKs for top commit:
  knst:
    utACK 5619c8f5fd
  kwvg:
    utACK 5619c8f5fd
  UdjinM6:
    utACK 5619c8f5fd

Tree-SHA512: 42c1e31319775e5800da2d82af00cae3aa0cee3baadd0123a809efc246d4ca5d0e6a4166b574e6ddebf66c0a80f4ee1655caff085f1687bb533889414a9fd4cf
This commit is contained in:
pasta 2024-08-01 12:30:16 -05:00
commit 491fa2b2a3
No known key found for this signature in database
GPG Key ID: 52527BEDABE87984
5 changed files with 483 additions and 354 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/workflows/release_docker_hub.yml vendored
View File

@ -65,6 +65,8 @@ jobs:
context: ./contrib/containers/deploy
file: ./contrib/containers/deploy/Dockerfile.GitHubActions.Release
push: true
provenance: mode=max
sbom: true
tags: ${{ steps.docker_meta.outputs.tags }}
labels: ${{ steps.docker_meta.outputs.labels }}
build-args: |

10
contrib/containers/deploy/Dockerfile.GitHubActions.Release
View File

@ -1,4 +1,4 @@
FROM ubuntu:focal
FROM ubuntu:jammy
LABEL maintainer="Dash Developers <dev@dash.org>"
LABEL description="Dockerised DashCore"
@ -33,6 +33,14 @@ RUN mach=$(uname -m) \
&& rm -rf /tmp/dashcore* \
&& chmod a+x /usr/local/bin/*
RUN apt-get update && \
apt list --installed && \
apt-get -y purge \
wget \
ca-certificates \
&& apt-get -y autoremove \
&& rm -rf /var/lib/apt/lists/*
USER dash
VOLUME ["/home/dash"]

368
doc/release-notes.md
View File

@ -1,9 +1,8 @@
# Dash Core version v21.0.0
# Dash Core version v21.0.1
This is a new major version release, bringing new features, various bugfixes
and other improvements.
This is a new patch release, bringing an important bugfix, as well as docker build improvements.
This release is **mandatory** for all masternodes.
This release is **strongly encouraged** for all masternodes.
This release is optional but recommended for all other nodes.
Please report bugs using the issue tracker at GitHub:
@ -35,352 +34,21 @@ reindex or re-sync the whole chain.
# Notable changes
Masternode Reward Location Reallocation (MN_RR) Hard Fork
---------------------------------------------------------
The MN_RR hard fork, first included in Dash Core v20, will be activated after v21 is adopted by masternodes. This
hard fork enables the major feature included in this release: Masternode Reward Location Reallocation. The activation
will also initiate the launch of the Dash Platform Genesis Chain.
Transaction Retrieval Bug
-------------------------
As the MN_RR hard fork is an [Enhanced Hard Fork](https://github.com/dashpay/dips/blob/master/dip-0023.md),
activation is dependent on both masternodes and miners. However, as this hard fork was first implemented in v20, only
masternodes are required to upgrade for the hard fork to activate. Once 85% of masternodes have upgraded to v21,
an EHF message will be signed by the `LLMQ_400_85` quorum, and mined into a block. This signature serves as proof that 85% of
active masternodes have upgraded.
Resolved a bug that prevented some clients (incl. Dash mobile wallets) from receiving transactions before they are mined
due to partial misclassification as block-only connections. Kudos to @HashEngineering and @knst for finding and
investigating this issue.
Once the EHF signed message is mined and a cycle ends, the hard fork status will move from `defined` to `started`. At this point,
miners on v20 and v21 will begin to signal for activation of MN_RR. As such, nearly 100% of miners will
likely be signalling. If a sufficient number of mined blocks signal support for activation (starting at 80% and gradually decreasing to 60%)
by the end of a cycle, the hard fork will change status from `started` to `locked_in`. At this point, hard fork activation
will occur at the end of the next cycle.
Docker Images now include SBOM
------------------------------
Now that the hard fork is active, the new rules will be in effect.
The [docker images](https://hub.docker.com/r/dashpay/dashd) should now provide SBOM and provenance.
SBOM and provenenance provide additional information about the build process and exact dependencies included.
See this [blog post](https://www.docker.com/blog/generate-sboms-with-buildkit/) by Docker for more information.
Masternode Reward Location Reallocation
---------------------------------------
Once the MN_RR hard fork activates, some coinbase funds will be moved into the Credit Pool (i.e., to Platform) each time a block is mined.
Evonodes will then receive a single reward per payment cycle on the Core chain - not rewards from four sequential blocks
as in v19/v20. The remainder of evonode payments will be distributed by Platform from the credit pool. This is to
incentivize evonodes to upgrade to Platform because only nodes running Platform can receive these reward payments.
Mainnet Spork Hardening
-----------------------
This version hardens all sporks on mainnet. Sporks remain in effect on all devnets and testnet; however, on mainnet,
the value of all sporks are hard coded to 0, or 1 for the `SPORK_21_QUORUM_ALL_CONNECTED` spork. These hardened values match the
active values historically used on mainnet, so there is no change in the network's functionality.
Default Branch Changed
----------------------
The Dash Core repository (`github.com/dashpay/dash`) will now use `develop` as the default branch. New clones
of the repository will no longer default to the `master` branch. If you want to continue using a stable version of
Dash Core, you should manually checkout the `master` branch.
# Additional Changes
Wallet
------
### Avoid Partial Spends
The wallet will now avoid partial spends (APS) by default if this does not result
in a difference in fees compared to the non-APS variant. The allowed fee threshold
can be adjusted using the new `-maxapsfee` configuration option. (dash#5930)
### Experimental Descriptor Wallets
Please note that Descriptor Wallets are still experimental and not all expected functionality
is available. Additionally there may be some bugs and current functions may change in the future.
Bugs and missing functionality can be reported to the [issue tracker](https://github.com/dashpay/dash/issues).
v21 introduces a new experimental type of wallet - Descriptor Wallets. Descriptor Wallets store
scriptPubKey information using descriptors. This is in contrast to the Legacy Wallet
structure where keys are used to generate scriptPubKeys and addresses. Because of this
shift to being script-based instead of key-based, many of the confusing things that Legacy
Wallets do are not possible with Descriptor Wallets. Descriptor Wallets use a definition
of "mine" for scripts which is simpler and more intuitive than that used by Legacy Wallets.
Descriptor Wallets also uses different semantics for watch-only things and imports.
As Descriptor Wallets are a new type of wallet, their introduction does not affect existing wallets.
Users who already have a Dash Core wallet can continue to use it as they did before without
any change in behavior. Newly created Legacy Wallets (which is the default type of wallet) will
behave as they did in previous versions of Dash Core.
The differences between Descriptor Wallets and Legacy Wallets are largely limited to non user facing
things. They are intended to behave similarly except for the import/export and watchonly functionality
as described below.
#### Creating Descriptor Wallets
Descriptor Wallets are not created by default. They must be explicitly created using the
`createwallet` RPC or via the GUI. A `descriptors` option has been added to `createwallet`.
Setting `descriptors` to `true` will create a Descriptor Wallet instead of a Legacy Wallet.
In the GUI, a checkbox has been added to the Create Wallet Dialog to indicate that a
Descriptor Wallet should be created.
A Legacy Wallet will be created if those options have not been set.
#### `IsMine` Semantics
`IsMine` refers to the function used to determine whether a script belongs to the wallet.
This is used to determine whether an output belongs to the wallet. `IsMine` in Legacy Wallets
returns true if the wallet would be able to sign an input that spends an output with that script.
Since keys can be involved in a variety of different scripts, this definition for `IsMine` can
lead to many unexpected scripts being considered part of the wallet.
With Descriptor Wallets, descriptors explicitly specify the set of scripts that are owned by
the wallet. Since descriptors are deterministic and easily enumerable, users will know exactly
what scripts the wallet will consider to belong to it. Additionally the implementation of `IsMine`
in Descriptor Wallets is far simpler than for Legacy Wallets. Notably, in Legacy Wallets, `IsMine`
allowed for users to take one type of address (e.g. P2PKH), mutate it into another address type
and the wallet would still detect outputs sending to the new address type
even without that address being requested from the wallet. Descriptor Wallets do not
allow for this and will only watch for the addresses that were explicitly requested from the wallet.
These changes to `IsMine` will make it easier to understand what scripts the wallet will
actually be watching for in outputs. However, for the vast majority of users, this change is
transparent and will not have noticeable effects.
#### Imports and Exports
In Legacy Wallets, raw scripts and keys could be imported to the wallet. Those imported scripts
and keys are treated separately from the keys generated by the wallet. This complicates the `IsMine`
logic as it has to distinguish between spendable and watchonly.
Descriptor Wallets handle importing scripts and keys differently. Only complete descriptors can be
imported. These descriptors are then added to the wallet as if it were a descriptor generated by
the wallet itself. This simplifies the `IsMine` logic so that it no longer has to distinguish
between spendable and watchonly. As such, the watchonly model for Descriptor Wallets is also
different and described in more detail in the next section.
To import into a Descriptor Wallet, a new `importdescriptors` RPC has been added that uses a syntax
similar to that of `importmulti`.
As Legacy Wallets and Descriptor Wallets use different mechanisms for storing and importing scripts and keys,
the existing import RPCs have been disabled for descriptor wallets.
New export RPCs for Descriptor Wallets have not yet been added.
The following RPCs are disabled for Descriptor Wallets:
* importprivkey
* importpubkey
* importaddress
* importwallet
* importelectrumwallet
* dumpprivkey
* dumpwallet
* dumphdinfo
* importmulti
* addmultisigaddress
#### Watchonly Wallets
A Legacy Wallet contains both private keys and scripts that were being watched.
Those watched scripts would not contribute to your normal balance. In order to see the watchonly
balance and to use watchonly things in transactions, an `include_watchonly` option was added
to many RPCs that would allow users to do that. However, it is easy to forget to include this option.
Descriptor Wallets move to a per-wallet watchonly model. An entire wallet is considered to be
watchonly depending on whether or not it was created with private keys disabled. This eliminates the need
to distinguish between things that are watchonly and things that are not within a wallet.
This change does have a caveat. If a Descriptor Wallet with private keys *enabled* has
a multiple key descriptor without all of the private keys (e.g. `multi(...)` with only one private key),
then the wallet will fail to sign and broadcast transactions. Such wallets would need to use the PSBT
workflow but the typical GUI Send, `sendtoaddress`, etc. workflows would still be available, just
non-functional.
This issue is worse if the wallet contains both single key (e.g. `pkh(...)`) descriptors and such
multiple key descriptors. In this case some transactions could be signed and broadcast while others fail. This is
due to some transactions containing only single key inputs while others contain both single
key and multiple key inputs, depending on which are available and how the coin selection algorithm
selects inputs. However, this is not a supported use case; multisigs
should be in their own wallets which do not already have descriptors. Although users cannot export
descriptors with private keys for now as explained earlier.
Configuration
-------------
### New cmd-line options
- `-networkactive=` Enable all P2P network activity (default: 1). Can be changed by the `setnetworkactive` RPC command.
- A new configuration flag `-maxapsfee` has been added, which sets the max allowed
avoid partial spends (APS) fee. It defaults to 0 (i.e. fee is the same with
and without APS). Setting it to -1 will disable APS, unless `-avoidpartialspends`
is set. (dash#5930)
### Updated cmd-line options
- The `-debug=db` logging category, which was deprecated in v0.18 and replaced by
`-debug=walletdb` to distinguish it from `coindb`, has been removed. (#6033)
- The `-banscore` configuration option, which modified the default threshold for
disconnecting and discouraging misbehaving peers, has been removed as part of
changes in this release to the handling of misbehaving peers. (dash#5511)
- If `-proxy=` is given together with `-noonion` then the provided proxy will
not be set as a proxy for reaching the Tor network. So it will not be
possible to open manual connections to the Tor network, for example, with the
`addnode` RPC. To mimic the old behavior use `-proxy=` together with
`-onlynet=` listing all relevant networks except `onion`.
Remote Procedure Calls (RPCs)
-----------------------------
### New RPCs
- A new `listdescriptors` RPC is available to inspect the contents of descriptor-enabled wallets.
The RPC returns public versions of all imported descriptors, including their timestamp and flags.
For ranged descriptors, it also returns the range boundaries and the next index to generate addresses from. (dash#5911)
- A new `send` RPC with similar syntax to `walletcreatefundedpsbt`, including
support for coin selection and a custom fee rate. The `send` RPC is experimental
and may change in subsequent releases. Using it is encouraged once it's no
longer experimental: `sendmany` and `sendtoaddress` may be deprecated in a future release.
- A new `quorum signplatform` RPC is added for Platform needs. This composite command limits Platform to only request signatures from the Platform quorum type. It is equivalent to `quorum sign <platform type>`.
### RPC changes
- `createwallet` has an updated argument list: `createwallet "wallet_name" ( disable_private_keys blank "passphrase" avoid_reuse descriptors load_on_startup )`
`load_on_startup` used to be argument 5 but now is number 6.
- `createwallet` requires specifying the `load_on_startup` flag when creating descriptor wallets due to breaking changes in v21.
- To make `sendtoaddress` more consistent with `sendmany`, the following
`sendtoaddress` error codes were changed from `-4` to `-6`:
- Insufficient funds
- Fee estimation failed
- Transaction has too long of a mempool chain
- Backwards compatibility has been dropped for two `getaddressinfo` RPC
deprecations, as notified in the 19.1.0 and 19.2.0 release notes.
The deprecated `label` field has been removed as well as the deprecated `labels` behavior of
returning a JSON object containing `name` and `purpose` key-value pairs. Since
20.1, the `labels` field returns a JSON array of label names. (dash#5823)
- `getnetworkinfo` now returns fields `connections_in`, `connections_out`,
`connections_mn_in`, `connections_mn_out`, `connections_mn`
that provide the number of inbound and outbound peer
connections. These new fields are in addition to the existing `connections`
field, which returns the total number of peer connections. Old fields
`inboundconnections`, `outboundconnections`, `inboundmnconnections`,
`outboundmnconnections` and `mnconnections` are removed (dash#5823)
- `getpeerinfo` no longer returns the `banscore` field unless the configuration
option `-deprecatedrpc=banscore` is used. The `banscore` field will be fully
removed in the next major release. (dash#5511)
- The `getpeerinfo` RPC no longer returns the `addnode` field by default. This
field will be fully removed in the next major release. It can be accessed
with the configuration option `-deprecatedrpc=getpeerinfo_addnode`. However,
it is recommended to instead use the `connection_type` field (it will return
`manual` when addnode is true). (#6033)
- The `sendtoaddress` and `sendmany` RPCs accept an optional `verbose=True`
argument to also return the fee reason about the sent tx. (#6033)
- The `getpeerinfo` RPC returns two new boolean fields, `bip152_hb_to` and
`bip152_hb_from`, that respectively indicate whether we selected a peer to be
in compact blocks high-bandwidth mode or whether a peer selected us as a
compact blocks high-bandwidth peer. High-bandwidth peers send new block
announcements via a `cmpctblock` message rather than the usual inv/headers
announcements. See BIP 152 for more details.
- `upgradewallet` now returns an object for future extensibility.
- The following RPCs: `gettxout`, `getrawtransaction`, `decoderawtransaction`,
`decodescript`, `gettransaction`, and REST endpoints: `/rest/tx`,
`/rest/getutxos`, `/rest/block` deprecated the following fields (which are no
longer returned in the responses by default): `addresses`, `reqSigs`.
The `-deprecatedrpc=addresses` flag must be passed for these fields to be
included in the RPC response. Note that these fields are attributes of
the `scriptPubKey` object returned in the RPC response. However, in the response
of `decodescript` these fields are top-level attributes, and included again as attributes
of the `scriptPubKey` object.
- The `listbanned` RPC now returns two new numeric fields: `ban_duration` and `time_remaining`.
Respectively, these new fields indicate the duration of a ban and the time remaining until a ban expires,
both in seconds. Additionally, the `ban_created` field is repositioned to come before `banned_until`. (#5976)
- The `walletcreatefundedpsbt` RPC call will now fail with
`Insufficient funds` when inputs are manually selected but are not enough to cover
the outputs and fee. Additional inputs can automatically be added through the
new `add_inputs` option.
- The `fundrawtransaction` RPC now supports an `add_inputs` option that, when `false`,
prevents adding more inputs even when necessary. In these cases the RPC fails.
- The `fundrawtransaction`, `send` and `walletcreatefundedpsbt` RPCs now support an `include_unsafe` option
that, when `true`, allows using unsafe inputs to fund the transaction.
Note that the resulting transaction may become invalid if one of the unsafe inputs disappears.
If that happens, the transaction must be funded with different inputs and republished.
- The `getnodeaddresses` RPC now returns a `network` field indicating the
network type (ipv4, ipv6, onion, or i2p) for each address.
- `getnodeaddresses` now also accepts a `network` argument (ipv4, ipv6, onion,
or i2p) to return only addresses of the specified network.
- A new `sethdseed` RPC allows users to initialize their blank HD wallets with an HD seed. **A new backup must be made
when a new HD seed is set.** This command cannot replace an existing HD seed if one is already set. `sethdseed` uses
WIF private key as a seed. If you have a mnemonic, use the `upgradetohd` RPC.
- The following RPCs, `protx list`, `protx listdiff`, `protx info` will no longer report `collateralAddress` if the
transaction index has been disabled (`txindex=0`).
### Improved support of composite commands
Dash Core's composite commands such as `quorum list` or `bls generate` now are compatible with a whitelist feature.
For example, the whitelist `getblockcount,quorumlist` will allow calling commands `getblockcount` and `quorum list`, but not `quorum sign`.
Note, that adding simply `quorum` in the whitelist will allow use of all `quorum...` commands, such as `quorum`, `quorum list`, `quorum sign`, etc.
### JSON-RPC Server Changes
The JSON-RPC server now rejects requests where a parameter is specified multiple times with the same name, instead of
silently overwriting earlier parameter values with later ones. (dash#6050)
P2P and network changes
-----------------------
- The protocol version has been bumped to 70232 even though it should be identical in behavior to 70231. This was done
to help easily differentiate between v20 and v21 peers.
- With I2P connections, a new, transient address is used for each outbound
connection if `-i2pacceptincoming=0`.
- A dashd node will no longer broadcast addresses to inbound peers by default.
They will become eligible for address gossip after sending an `ADDR`, `ADDRV2`,
or `GETADDR` message.
dash-tx Changes
---------------
- When creating a hex-encoded Dash transaction using the `dash-tx` utility
with the `-json` option set, the following fields: `addresses`, `reqSigs` are no longer
returned in the tx output of the response.
dash-cli Changes
----------------
- A new `-rpcwaittimeout` argument to `dash-cli` sets the timeout
in seconds to use with `-rpcwait`. If the timeout expires,
`dash-cli` will report a failure. (dash#5923)
- The `connections` field of `dash-cli -getinfo` is expanded to return a JSON
object with `in`, `out` and `total` numbers of peer connections and `mn_in`,
`mn_out` and `mn_total` numbers of verified mn connections. It previously
returned a single integer value for the total number of peer connections. (dash#5823)
- Update `-getinfo` to return data in a user-friendly format that also reduces vertical space.
- A new CLI `-addrinfo` command returns the number of addresses known to the
node per network type (including Tor v2 versus v3) and total. This can be
useful to see if the node knows enough addresses in a network to use options
like `-onlynet=<network>` or to upgrade to current and future Tor releases
that support Tor v3 addresses only. (#5904)
- CLI `-addrinfo` now returns a single field for the number of `onion` addresses
known to the node instead of separate `torv2` and `torv3` fields, as support
for Tor V2 addresses was removed from Dash Core in 18.0.
dash-wallet changes
-------------------
This release introduces several improvements and new features to the `dash-wallet` tool, making it more versatile and
user-friendly for managing Dash wallets.
- Wallets created with the `dash-wallet` tool will now utilize the `FEATURE_LATEST` version of wallet which is the HD
(Hierarchical Deterministic) wallets with HD chain inside.
- new command line argument `-usehd` allows creation of non-Hierarchical Deterministic (non-HD) wallets with the
`wallettool` for compatibility reasons since default version is bumped to HD version
- new command line argument `-descriptors` enables _experimental_ support of Descriptor wallets. It lets users
create descriptor wallets directly from the command line. This change aligns the command-line interface with
the `createwallet` RPC, promoting the use of descriptor wallets which offer a more flexible ways to manage
wallet addresses and keys.
- new commands `dump` and `createfromdump` have been added, enhancing the wallet's storage migration capabilities. The
`dump` command allows for exporting every key-value pair from the wallet as comma-separated hex values, facilitating a
storage agnostic dump. Meanwhile, the `createfromdump` command enables the creation of a new wallet file using the
records specified in a dump file. These commands are similar to BDB's `db_dump` and `db_load` tools and are useful
for manual wallet file construction for testing or migration purposes.
# v21.0.0 Change log
# v21.0.1 Change log
See detailed [set of changes][set-of-changes].
@ -388,13 +56,8 @@ See detailed [set of changes][set-of-changes].
Thanks to everyone who directly contributed to this release:
- Alessandro Rezzi
- Kittywhiskers Van Gogh
- Konstantin Akimov
- PastaPastaPasta
- thephez
- UdjinM6
- Vijay
As well as everyone that submitted issues, reviewed pull requests and helped
debug the release candidates.
@ -403,6 +66,7 @@ debug the release candidates.
These release are considered obsolete. Old release notes can be found here:
- [v21.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.0.0.md) released Jul/25/2024
- [v20.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.1.1.md) released April/3/2024
- [v20.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.1.0.md) released March/5/2024
- [v20.0.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.4.md) released Jan/13/2024
@ -452,4 +116,4 @@ These release are considered obsolete. Old release notes can be found here:
- [v0.10.x](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.10.0.md) released Sep/25/2014
- [v0.9.x](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.9.0.md) released Mar/13/2014
[set-of-changes]: https://github.com/dashpay/dash/compare/v20.1.1...dashpay:v21.0.0
[set-of-changes]: https://github.com/dashpay/dash/compare/v21.0.0...dashpay:v21.0.1

455
doc/release-notes/dash/release-notes-21.0.0.md Normal file
View File

@ -0,0 +1,455 @@
# Dash Core version v21.0.0
This is a new major version release, bringing new features, various bugfixes
and other improvements.
This release is **mandatory** for all masternodes.
This release is optional but recommended for all other nodes.
Please report bugs using the issue tracker at GitHub:
<https://github.com/dashpay/dash/issues>
# Upgrading and downgrading
## How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Dash-Qt (on Mac) or
dashd/dash-qt (on Linux).
## Downgrade warning
### Downgrade to a version < v21.0.0
Downgrading to a version older than v21.0.0 may not be supported due to changes
if you are using descriptor wallets.
### Downgrade to a version < v19.2.0
Downgrading to a version older than v19.2.0 is not supported due to changes
in the evodb database. If you need to use an older version, you must either
reindex or re-sync the whole chain.
# Notable changes
Masternode Reward Location Reallocation (MN_RR) Hard Fork
---------------------------------------------------------
The MN_RR hard fork, first included in Dash Core v20, will be activated after v21 is adopted by masternodes. This
hard fork enables the major feature included in this release: Masternode Reward Location Reallocation. The activation
will also initiate the launch of the Dash Platform Genesis Chain.
As the MN_RR hard fork is an [Enhanced Hard Fork](https://github.com/dashpay/dips/blob/master/dip-0023.md),
activation is dependent on both masternodes and miners. However, as this hard fork was first implemented in v20, only
masternodes are required to upgrade for the hard fork to activate. Once 85% of masternodes have upgraded to v21,
an EHF message will be signed by the `LLMQ_400_85` quorum, and mined into a block. This signature serves as proof that 85% of
active masternodes have upgraded.
Once the EHF signed message is mined and a cycle ends, the hard fork status will move from `defined` to `started`. At this point,
miners on v20 and v21 will begin to signal for activation of MN_RR. As such, nearly 100% of miners will
likely be signalling. If a sufficient number of mined blocks signal support for activation (starting at 80% and gradually decreasing to 60%)
by the end of a cycle, the hard fork will change status from `started` to `locked_in`. At this point, hard fork activation
will occur at the end of the next cycle.
Now that the hard fork is active, the new rules will be in effect.
Masternode Reward Location Reallocation
---------------------------------------
Once the MN_RR hard fork activates, some coinbase funds will be moved into the Credit Pool (i.e., to Platform) each time a block is mined.
Evonodes will then receive a single reward per payment cycle on the Core chain - not rewards from four sequential blocks
as in v19/v20. The remainder of evonode payments will be distributed by Platform from the credit pool. This is to
incentivize evonodes to upgrade to Platform because only nodes running Platform can receive these reward payments.
Mainnet Spork Hardening
-----------------------
This version hardens all sporks on mainnet. Sporks remain in effect on all devnets and testnet; however, on mainnet,
the value of all sporks are hard coded to 0, or 1 for the `SPORK_21_QUORUM_ALL_CONNECTED` spork. These hardened values match the
active values historically used on mainnet, so there is no change in the network's functionality.
Default Branch Changed
----------------------
The Dash Core repository (`github.com/dashpay/dash`) will now use `develop` as the default branch. New clones
of the repository will no longer default to the `master` branch. If you want to continue using a stable version of
Dash Core, you should manually checkout the `master` branch.
# Additional Changes
Wallet
------
### Avoid Partial Spends
The wallet will now avoid partial spends (APS) by default if this does not result
in a difference in fees compared to the non-APS variant. The allowed fee threshold
can be adjusted using the new `-maxapsfee` configuration option. (dash#5930)
### Experimental Descriptor Wallets
Please note that Descriptor Wallets are still experimental and not all expected functionality
is available. Additionally there may be some bugs and current functions may change in the future.
Bugs and missing functionality can be reported to the [issue tracker](https://github.com/dashpay/dash/issues).
v21 introduces a new experimental type of wallet - Descriptor Wallets. Descriptor Wallets store
scriptPubKey information using descriptors. This is in contrast to the Legacy Wallet
structure where keys are used to generate scriptPubKeys and addresses. Because of this
shift to being script-based instead of key-based, many of the confusing things that Legacy
Wallets do are not possible with Descriptor Wallets. Descriptor Wallets use a definition
of "mine" for scripts which is simpler and more intuitive than that used by Legacy Wallets.
Descriptor Wallets also uses different semantics for watch-only things and imports.
As Descriptor Wallets are a new type of wallet, their introduction does not affect existing wallets.
Users who already have a Dash Core wallet can continue to use it as they did before without
any change in behavior. Newly created Legacy Wallets (which is the default type of wallet) will
behave as they did in previous versions of Dash Core.
The differences between Descriptor Wallets and Legacy Wallets are largely limited to non user facing
things. They are intended to behave similarly except for the import/export and watchonly functionality
as described below.
#### Creating Descriptor Wallets
Descriptor Wallets are not created by default. They must be explicitly created using the
`createwallet` RPC or via the GUI. A `descriptors` option has been added to `createwallet`.
Setting `descriptors` to `true` will create a Descriptor Wallet instead of a Legacy Wallet.
In the GUI, a checkbox has been added to the Create Wallet Dialog to indicate that a
Descriptor Wallet should be created.
A Legacy Wallet will be created if those options have not been set.
#### `IsMine` Semantics
`IsMine` refers to the function used to determine whether a script belongs to the wallet.
This is used to determine whether an output belongs to the wallet. `IsMine` in Legacy Wallets
returns true if the wallet would be able to sign an input that spends an output with that script.
Since keys can be involved in a variety of different scripts, this definition for `IsMine` can
lead to many unexpected scripts being considered part of the wallet.
With Descriptor Wallets, descriptors explicitly specify the set of scripts that are owned by
the wallet. Since descriptors are deterministic and easily enumerable, users will know exactly
what scripts the wallet will consider to belong to it. Additionally the implementation of `IsMine`
in Descriptor Wallets is far simpler than for Legacy Wallets. Notably, in Legacy Wallets, `IsMine`
allowed for users to take one type of address (e.g. P2PKH), mutate it into another address type
and the wallet would still detect outputs sending to the new address type
even without that address being requested from the wallet. Descriptor Wallets do not
allow for this and will only watch for the addresses that were explicitly requested from the wallet.
These changes to `IsMine` will make it easier to understand what scripts the wallet will
actually be watching for in outputs. However, for the vast majority of users, this change is
transparent and will not have noticeable effects.
#### Imports and Exports
In Legacy Wallets, raw scripts and keys could be imported to the wallet. Those imported scripts
and keys are treated separately from the keys generated by the wallet. This complicates the `IsMine`
logic as it has to distinguish between spendable and watchonly.
Descriptor Wallets handle importing scripts and keys differently. Only complete descriptors can be
imported. These descriptors are then added to the wallet as if it were a descriptor generated by
the wallet itself. This simplifies the `IsMine` logic so that it no longer has to distinguish
between spendable and watchonly. As such, the watchonly model for Descriptor Wallets is also
different and described in more detail in the next section.
To import into a Descriptor Wallet, a new `importdescriptors` RPC has been added that uses a syntax
similar to that of `importmulti`.
As Legacy Wallets and Descriptor Wallets use different mechanisms for storing and importing scripts and keys,
the existing import RPCs have been disabled for descriptor wallets.
New export RPCs for Descriptor Wallets have not yet been added.
The following RPCs are disabled for Descriptor Wallets:
* importprivkey
* importpubkey
* importaddress
* importwallet
* importelectrumwallet
* dumpprivkey
* dumpwallet
* dumphdinfo
* importmulti
* addmultisigaddress
#### Watchonly Wallets
A Legacy Wallet contains both private keys and scripts that were being watched.
Those watched scripts would not contribute to your normal balance. In order to see the watchonly
balance and to use watchonly things in transactions, an `include_watchonly` option was added
to many RPCs that would allow users to do that. However, it is easy to forget to include this option.
Descriptor Wallets move to a per-wallet watchonly model. An entire wallet is considered to be
watchonly depending on whether or not it was created with private keys disabled. This eliminates the need
to distinguish between things that are watchonly and things that are not within a wallet.
This change does have a caveat. If a Descriptor Wallet with private keys *enabled* has
a multiple key descriptor without all of the private keys (e.g. `multi(...)` with only one private key),
then the wallet will fail to sign and broadcast transactions. Such wallets would need to use the PSBT
workflow but the typical GUI Send, `sendtoaddress`, etc. workflows would still be available, just
non-functional.
This issue is worse if the wallet contains both single key (e.g. `pkh(...)`) descriptors and such
multiple key descriptors. In this case some transactions could be signed and broadcast while others fail. This is
due to some transactions containing only single key inputs while others contain both single
key and multiple key inputs, depending on which are available and how the coin selection algorithm
selects inputs. However, this is not a supported use case; multisigs
should be in their own wallets which do not already have descriptors. Although users cannot export
descriptors with private keys for now as explained earlier.
Configuration
-------------
### New cmd-line options
- `-networkactive=` Enable all P2P network activity (default: 1). Can be changed by the `setnetworkactive` RPC command.
- A new configuration flag `-maxapsfee` has been added, which sets the max allowed
avoid partial spends (APS) fee. It defaults to 0 (i.e. fee is the same with
and without APS). Setting it to -1 will disable APS, unless `-avoidpartialspends`
is set. (dash#5930)
### Updated cmd-line options
- The `-debug=db` logging category, which was deprecated in v0.18 and replaced by
`-debug=walletdb` to distinguish it from `coindb`, has been removed. (#6033)
- The `-banscore` configuration option, which modified the default threshold for
disconnecting and discouraging misbehaving peers, has been removed as part of
changes in this release to the handling of misbehaving peers. (dash#5511)
- If `-proxy=` is given together with `-noonion` then the provided proxy will
not be set as a proxy for reaching the Tor network. So it will not be
possible to open manual connections to the Tor network, for example, with the
`addnode` RPC. To mimic the old behavior use `-proxy=` together with
`-onlynet=` listing all relevant networks except `onion`.
Remote Procedure Calls (RPCs)
-----------------------------
### New RPCs
- A new `listdescriptors` RPC is available to inspect the contents of descriptor-enabled wallets.
The RPC returns public versions of all imported descriptors, including their timestamp and flags.
For ranged descriptors, it also returns the range boundaries and the next index to generate addresses from. (dash#5911)
- A new `send` RPC with similar syntax to `walletcreatefundedpsbt`, including
support for coin selection and a custom fee rate. The `send` RPC is experimental
and may change in subsequent releases. Using it is encouraged once it's no
longer experimental: `sendmany` and `sendtoaddress` may be deprecated in a future release.
- A new `quorum signplatform` RPC is added for Platform needs. This composite command limits Platform to only request signatures from the Platform quorum type. It is equivalent to `quorum sign <platform type>`.
### RPC changes
- `createwallet` has an updated argument list: `createwallet "wallet_name" ( disable_private_keys blank "passphrase" avoid_reuse descriptors load_on_startup )`
`load_on_startup` used to be argument 5 but now is number 6.
- `createwallet` requires specifying the `load_on_startup` flag when creating descriptor wallets due to breaking changes in v21.
- To make `sendtoaddress` more consistent with `sendmany`, the following
`sendtoaddress` error codes were changed from `-4` to `-6`:
- Insufficient funds
- Fee estimation failed
- Transaction has too long of a mempool chain
- Backwards compatibility has been dropped for two `getaddressinfo` RPC
deprecations, as notified in the 19.1.0 and 19.2.0 release notes.
The deprecated `label` field has been removed as well as the deprecated `labels` behavior of
returning a JSON object containing `name` and `purpose` key-value pairs. Since
20.1, the `labels` field returns a JSON array of label names. (dash#5823)
- `getnetworkinfo` now returns fields `connections_in`, `connections_out`,
`connections_mn_in`, `connections_mn_out`, `connections_mn`
that provide the number of inbound and outbound peer
connections. These new fields are in addition to the existing `connections`
field, which returns the total number of peer connections. Old fields
`inboundconnections`, `outboundconnections`, `inboundmnconnections`,
`outboundmnconnections` and `mnconnections` are removed (dash#5823)
- `getpeerinfo` no longer returns the `banscore` field unless the configuration
option `-deprecatedrpc=banscore` is used. The `banscore` field will be fully
removed in the next major release. (dash#5511)
- The `getpeerinfo` RPC no longer returns the `addnode` field by default. This
field will be fully removed in the next major release. It can be accessed
with the configuration option `-deprecatedrpc=getpeerinfo_addnode`. However,
it is recommended to instead use the `connection_type` field (it will return
`manual` when addnode is true). (#6033)
- The `sendtoaddress` and `sendmany` RPCs accept an optional `verbose=True`
argument to also return the fee reason about the sent tx. (#6033)
- The `getpeerinfo` RPC returns two new boolean fields, `bip152_hb_to` and
`bip152_hb_from`, that respectively indicate whether we selected a peer to be
in compact blocks high-bandwidth mode or whether a peer selected us as a
compact blocks high-bandwidth peer. High-bandwidth peers send new block
announcements via a `cmpctblock` message rather than the usual inv/headers
announcements. See BIP 152 for more details.
- `upgradewallet` now returns an object for future extensibility.
- The following RPCs: `gettxout`, `getrawtransaction`, `decoderawtransaction`,
`decodescript`, `gettransaction`, and REST endpoints: `/rest/tx`,
`/rest/getutxos`, `/rest/block` deprecated the following fields (which are no
longer returned in the responses by default): `addresses`, `reqSigs`.
The `-deprecatedrpc=addresses` flag must be passed for these fields to be
included in the RPC response. Note that these fields are attributes of
the `scriptPubKey` object returned in the RPC response. However, in the response
of `decodescript` these fields are top-level attributes, and included again as attributes
of the `scriptPubKey` object.
- The `listbanned` RPC now returns two new numeric fields: `ban_duration` and `time_remaining`.
Respectively, these new fields indicate the duration of a ban and the time remaining until a ban expires,
both in seconds. Additionally, the `ban_created` field is repositioned to come before `banned_until`. (#5976)
- The `walletcreatefundedpsbt` RPC call will now fail with
`Insufficient funds` when inputs are manually selected but are not enough to cover
the outputs and fee. Additional inputs can automatically be added through the
new `add_inputs` option.
- The `fundrawtransaction` RPC now supports an `add_inputs` option that, when `false`,
prevents adding more inputs even when necessary. In these cases the RPC fails.
- The `fundrawtransaction`, `send` and `walletcreatefundedpsbt` RPCs now support an `include_unsafe` option
that, when `true`, allows using unsafe inputs to fund the transaction.
Note that the resulting transaction may become invalid if one of the unsafe inputs disappears.
If that happens, the transaction must be funded with different inputs and republished.
- The `getnodeaddresses` RPC now returns a `network` field indicating the
network type (ipv4, ipv6, onion, or i2p) for each address.
- `getnodeaddresses` now also accepts a `network` argument (ipv4, ipv6, onion,
or i2p) to return only addresses of the specified network.
- A new `sethdseed` RPC allows users to initialize their blank HD wallets with an HD seed. **A new backup must be made
when a new HD seed is set.** This command cannot replace an existing HD seed if one is already set. `sethdseed` uses
WIF private key as a seed. If you have a mnemonic, use the `upgradetohd` RPC.
- The following RPCs, `protx list`, `protx listdiff`, `protx info` will no longer report `collateralAddress` if the
transaction index has been disabled (`txindex=0`).
### Improved support of composite commands
Dash Core's composite commands such as `quorum list` or `bls generate` now are compatible with a whitelist feature.
For example, the whitelist `getblockcount,quorumlist` will allow calling commands `getblockcount` and `quorum list`, but not `quorum sign`.
Note, that adding simply `quorum` in the whitelist will allow use of all `quorum...` commands, such as `quorum`, `quorum list`, `quorum sign`, etc.
### JSON-RPC Server Changes
The JSON-RPC server now rejects requests where a parameter is specified multiple times with the same name, instead of
silently overwriting earlier parameter values with later ones. (dash#6050)
P2P and network changes
-----------------------
- The protocol version has been bumped to 70232 even though it should be identical in behavior to 70231. This was done
to help easily differentiate between v20 and v21 peers.
- With I2P connections, a new, transient address is used for each outbound
connection if `-i2pacceptincoming=0`.
- A dashd node will no longer broadcast addresses to inbound peers by default.
They will become eligible for address gossip after sending an `ADDR`, `ADDRV2`,
or `GETADDR` message.
dash-tx Changes
---------------
- When creating a hex-encoded Dash transaction using the `dash-tx` utility
with the `-json` option set, the following fields: `addresses`, `reqSigs` are no longer
returned in the tx output of the response.
dash-cli Changes
----------------
- A new `-rpcwaittimeout` argument to `dash-cli` sets the timeout
in seconds to use with `-rpcwait`. If the timeout expires,
`dash-cli` will report a failure. (dash#5923)
- The `connections` field of `dash-cli -getinfo` is expanded to return a JSON
object with `in`, `out` and `total` numbers of peer connections and `mn_in`,
`mn_out` and `mn_total` numbers of verified mn connections. It previously
returned a single integer value for the total number of peer connections. (dash#5823)
- Update `-getinfo` to return data in a user-friendly format that also reduces vertical space.
- A new CLI `-addrinfo` command returns the number of addresses known to the
node per network type (including Tor v2 versus v3) and total. This can be
useful to see if the node knows enough addresses in a network to use options
like `-onlynet=<network>` or to upgrade to current and future Tor releases
that support Tor v3 addresses only. (#5904)
- CLI `-addrinfo` now returns a single field for the number of `onion` addresses
known to the node instead of separate `torv2` and `torv3` fields, as support
for Tor V2 addresses was removed from Dash Core in 18.0.
dash-wallet changes
-------------------
This release introduces several improvements and new features to the `dash-wallet` tool, making it more versatile and
user-friendly for managing Dash wallets.
- Wallets created with the `dash-wallet` tool will now utilize the `FEATURE_LATEST` version of wallet which is the HD
(Hierarchical Deterministic) wallets with HD chain inside.
- new command line argument `-usehd` allows creation of non-Hierarchical Deterministic (non-HD) wallets with the
`wallettool` for compatibility reasons since default version is bumped to HD version
- new command line argument `-descriptors` enables _experimental_ support of Descriptor wallets. It lets users
create descriptor wallets directly from the command line. This change aligns the command-line interface with
the `createwallet` RPC, promoting the use of descriptor wallets which offer a more flexible ways to manage
wallet addresses and keys.
- new commands `dump` and `createfromdump` have been added, enhancing the wallet's storage migration capabilities. The
`dump` command allows for exporting every key-value pair from the wallet as comma-separated hex values, facilitating a
storage agnostic dump. Meanwhile, the `createfromdump` command enables the creation of a new wallet file using the
records specified in a dump file. These commands are similar to BDB's `db_dump` and `db_load` tools and are useful
for manual wallet file construction for testing or migration purposes.
# v21.0.0 Change log
See detailed [set of changes][set-of-changes].
# Credits
Thanks to everyone who directly contributed to this release:
- Alessandro Rezzi
- Kittywhiskers Van Gogh
- Konstantin Akimov
- PastaPastaPasta
- thephez
- UdjinM6
- Vijay
As well as everyone that submitted issues, reviewed pull requests and helped
debug the release candidates.
# Older releases
These release are considered obsolete. Old release notes can be found here:
- [v20.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.1.1.md) released April/3/2024
- [v20.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.1.0.md) released March/5/2024
- [v20.0.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.4.md) released Jan/13/2024
- [v20.0.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.3.md) released December/26/2023
- [v20.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.2.md) released December/06/2023
- [v20.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.1.md) released November/18/2023
- [v20.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.0.md) released November/15/2023
- [v19.3.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-19.3.0.md) released July/31/2023
- [v19.2.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-19.2.0.md) released June/19/2023
- [v19.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-19.1.0.md) released May/22/2023
- [v19.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-19.0.0.md) released Apr/14/2023
- [v18.2.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.2.2.md) released Mar/21/2023
- [v18.2.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.2.1.md) released Jan/17/2023
- [v18.2.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.2.0.md) released Jan/01/2023
- [v18.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.1.1.md) released January/08/2023
- [v18.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.1.0.md) released October/09/2022
- [v18.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.0.2.md) released October/09/2022
- [v18.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.0.1.md) released August/17/2022
- [v0.17.0.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.17.0.3.md) released June/07/2021
- [v0.17.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.17.0.2.md) released May/19/2021
- [v0.16.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.1.1.md) released November/17/2020
- [v0.16.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.1.0.md) released November/14/2020
- [v0.16.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.0.1.md) released September/30/2020
- [v0.15.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.15.0.0.md) released Febrary/18/2020
- [v0.14.0.5](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.5.md) released December/08/2019
- [v0.14.0.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.4.md) released November/22/2019
- [v0.14.0.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.3.md) released August/15/2019
- [v0.14.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.2.md) released July/4/2019
- [v0.14.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.1.md) released May/31/2019
- [v0.14.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.md) released May/22/2019
- [v0.13.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.13.3.md) released Apr/04/2019
- [v0.13.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.13.2.md) released Mar/15/2019
- [v0.13.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.13.1.md) released Feb/9/2019
- [v0.13.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.13.0.md) released Jan/14/2019
- [v0.12.3.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.3.4.md) released Dec/14/2018
- [v0.12.3.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.3.3.md) released Sep/19/2018
- [v0.12.3.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.3.2.md) released Jul/09/2018
- [v0.12.3.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.3.1.md) released Jul/03/2018
- [v0.12.2.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.3.md) released Jan/12/2018
- [v0.12.2.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.2.md) released Dec/17/2017
- [v0.12.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.md) released Nov/08/2017
- [v0.12.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.1.md) released Feb/06/2017
- [v0.12.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.0.md) released Aug/15/2015
- [v0.11.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.11.2.md) released Mar/04/2015
- [v0.11.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.11.1.md) released Feb/10/2015
- [v0.11.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.11.0.md) released Jan/15/2015
- [v0.10.x](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.10.0.md) released Sep/25/2014
- [v0.9.x](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.9.0.md) released Mar/13/2014
[set-of-changes]: https://github.com/dashpay/dash/compare/v20.1.1...dashpay:v21.0.0

2
src/net_processing.cpp
View File

@ -2592,7 +2592,7 @@ void PeerManagerImpl::ProcessGetData(CNode& pfrom, Peer& peer, const std::atomic
}
++it;
if (!peer.m_addr_relay_enabled && NetMessageViolatesBlocksOnly(inv.GetCommand())) {
if (peer.m_block_relay_only && NetMessageViolatesBlocksOnly(inv.GetCommand())) {
// Note that if we receive a getdata for non-block messages
// from a block-relay-only outbound peer that violate the policy,
// we skip such getdata messages from this peer