From e10c5c95792ea5e715e33f31ec7a8b6668b63317 Mon Sep 17 00:00:00 2001 From: pasta Date: Thu, 1 Aug 2024 09:15:50 -0500 Subject: [PATCH 1/3] Merge #6160: feat: add sbom and provenance in release for dockerhub; use jammy; apt remove as possible 9178e8a75f7f8846ef40f8f5af53462269b2d4ac feat: add smob and provenance in release for dockerhub; use jammy; apt remove as possible (pasta) Pull request description: ## Issue being fixed or feature implemented Docker provenance refers to the origin and history of Docker images, including how they were built, modified, and by whom. An SBOM (Software Bill of Materials) is a detailed list of all components in a software application, providing transparency about libraries, dependencies, and versions used, which is crucial for security and compliance. ## What was done? Add SBOM and provenance to docker build; this may allow some level of validation that GitHub actions is actually doing what it says it is. See this for more information https://docs.docker.com/build/ci/github-actions/attestations/ ## How Has This Been Tested? Building with buildx with sbom and provenance flags locally ## 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: UdjinM6: utACK 9178e8a75f7f8846ef40f8f5af53462269b2d4ac Tree-SHA512: 6e3f35a0b30f002e2d5d80d6dd18ee554a1c15c62c1d4cbe1185f38977f55a199998515cf5bb9a027670f068f3d56ef33faa062d8c4122a886375d00afe6bf2f --- .github/workflows/release_docker_hub.yml | 2 ++ .../containers/deploy/Dockerfile.GitHubActions.Release | 10 +++++++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/.github/workflows/release_docker_hub.yml b/.github/workflows/release_docker_hub.yml index 8926715d4414b..bbdf7551928b0 100644 --- a/.github/workflows/release_docker_hub.yml +++ b/.github/workflows/release_docker_hub.yml @@ -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: | diff --git a/contrib/containers/deploy/Dockerfile.GitHubActions.Release b/contrib/containers/deploy/Dockerfile.GitHubActions.Release index 7d977b7919aa4..c32bada29c588 100644 --- a/contrib/containers/deploy/Dockerfile.GitHubActions.Release +++ b/contrib/containers/deploy/Dockerfile.GitHubActions.Release @@ -1,4 +1,4 @@ -FROM ubuntu:focal +FROM ubuntu:jammy LABEL maintainer="Dash Developers " 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"] From 9e80d128c0796e2c56e0b04e96f59a5e578069f1 Mon Sep 17 00:00:00 2001 From: pasta Date: Thu, 1 Aug 2024 09:23:09 -0500 Subject: [PATCH 2/3] Merge #6163: fix: use blocks-only instead of address-only for inventory 3468ab34d1f15bc90eca3d258493bd48a6a0952e fix: use blocks-only instead of address-only for inventory (Konstantin Akimov) Pull request description: ## Issue being fixed or feature implemented Mobile client (without full blockchain) can't receive transactions before they are mined in the block. ## What was done? Fixed a condition "is an addr relay" to "not a block relay". It's an alternate solution for https://github.com/dashpay/dash/pull/6162 ## How Has This Been Tested? Tested with hashengineering - it works! ## Breaking Changes N/A ## Checklist: - [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 ACKs for top commit: PastaPastaPasta: utACK [3468ab3](https://github.com/dashpay/dash/pull/6163/commits/3468ab34d1f15bc90eca3d258493bd48a6a0952e); no diff kwvg: utACK 3468ab34d1f15bc90eca3d258493bd48a6a0952e Tree-SHA512: 6ad257a72be0f2fd4d7a8e3674d537e2a2c5f0c7c1bdfdf825403d8cb2975261bcf4574949fb02a16de76762d3f30b40e094be448cfa4ee6bae9f1f5be5f44d5 --- src/net_processing.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/net_processing.cpp b/src/net_processing.cpp index 6511ed614b401..d0cd8c7f366cb 100644 --- a/src/net_processing.cpp +++ b/src/net_processing.cpp @@ -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 From 5619c8f5fdb06ec3762697b74360d0ace08660d5 Mon Sep 17 00:00:00 2001 From: pasta Date: Thu, 1 Aug 2024 09:52:14 -0500 Subject: [PATCH 3/3] docs: add release notes for v21.0.1 and archive v21.0.0 Co-authored-by: Konstantin Akimov --- doc/release-notes.md | 368 +------------- .../dash/release-notes-21.0.0.md | 455 ++++++++++++++++++ 2 files changed, 471 insertions(+), 352 deletions(-) create mode 100644 doc/release-notes/dash/release-notes-21.0.0.md diff --git a/doc/release-notes.md b/doc/release-notes.md index ffdcea88c0bcb..5492997d2f3a4 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -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 `. - -### 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=` 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 diff --git a/doc/release-notes/dash/release-notes-21.0.0.md b/doc/release-notes/dash/release-notes-21.0.0.md new file mode 100644 index 0000000000000..ffdcea88c0bcb --- /dev/null +++ b/doc/release-notes/dash/release-notes-21.0.0.md @@ -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: + + + + +# 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 `. + +### 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=` 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