diff --git a/doc/man/dash-cli.1 b/doc/man/dash-cli.1 index 47158fbf95ff..a04d71f9b5cf 100644 --- a/doc/man/dash-cli.1 +++ b/doc/man/dash-cli.1 @@ -1,5 +1,5 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-CLI "1" "October 2026" "dash-cli v24.0.0" "User Commands" +.TH DASH-CLI "1" "November 2026" "dash-cli v24.0.0" "User Commands" .SH NAME dash-cli \- manual page for dash-cli v24.0.0 .SH SYNOPSIS diff --git a/doc/man/dash-qt.1 b/doc/man/dash-qt.1 index aba940422d27..b5d118c05a14 100644 --- a/doc/man/dash-qt.1 +++ b/doc/man/dash-qt.1 @@ -1,5 +1,5 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-QT "1" "October 2026" "dash-qt v24.0.0" "User Commands" +.TH DASH-QT "1" "November 2026" "dash-qt v24.0.0" "User Commands" .SH NAME dash-qt \- manual page for dash-qt v24.0.0 .SH SYNOPSIS @@ -30,9 +30,9 @@ datadir as a warning, not an error. If this block is in the chain assume that it and its ancestors are valid and potentially skip their script verification (0 to verify all, default: -00000000000000119fe42827219e0686d3f7b494ae65f823194c740c5dbab492, +000000000000000346a1804da4832b0b69dd9a7f96b14c7cb54585a9ac6ae98f, testnet: -000000541a23f9db7411cddbe50f9f1ebd4aa7108ebdcad62214753f648c0239, +000000116cd3c11d44c88cbc0a26804bd277a5d790f684ec3a8aaa820690318c, devnet: 0000000000000000000000000000000000000000000000000000000000000000) .HP @@ -60,10 +60,10 @@ Specify directory to hold blocks subdirectory for *.dat files (default: .HP \fB\-blocksonly\fR .IP -Whether to reject transactions from network peers. Automatic broadcast -and rebroadcast of any transactions from inbound peers is -disabled, unless the peer has the 'forcerelay' permission. RPC -transactions are not affected. (default: 0) +Whether to reject transactions from network peers. Disables automatic +broadcast and rebroadcast of transactions, unless the source peer +has the 'forcerelay' permission. RPC transactions are not +affected. (default: 0) .HP \fB\-chainlocknotify=\fR .IP @@ -222,10 +222,11 @@ Bind to given address and always listen on it (default: 0.0.0.0). Use connections to that address and port as incoming Tor connections (default: 127.0.0.1:9996=onion, testnet: 127.0.0.1:19996=onion, devnet: 127.0.0.1:19796=onion, regtest: 127.0.0.1:19896=onion). -The default onion bind is added only when no \fB\-bind\fR is specified. -When \fB\-listenonion\fR is enabled and \fB\-bind\fR is specified, a -non\-wildcard =onion bind is required, and wildcard =onion binds -are rejected. +Without an =onion bind, the default onion bind is added unless +\fB\-bind\fR is given and \fB\-listenonion\fR is disabled; failing to bind it +stops startup only with an explicit \fB\-listenonion\fR=\fI\,1\/\fR, and otherwise +no onion service is created. While \fB\-listenonion\fR is enabled, a +wildcard =onion bind is an error. .HP \fB\-cjdnsreachable\fR .IP @@ -285,7 +286,9 @@ Accept connections from outside (default: 1 if no \fB\-proxy\fR, \fB\-connect\fR .HP \fB\-listenonion\fR .IP -Automatically create Tor onion service (default: 1) +Automatically create Tor onion service if Tor is available and the onion +bind could be bound (see \fB\-bind\fR). If set to 1 explicitly, fail to +start if the onion bind cannot be bound (default: 1) .HP \fB\-maxconnections=\fR .IP @@ -426,10 +429,11 @@ download,noban,mempool,relay). Can be specified multiple times. .HP \fB\-whitelist=\fR<[permissions@]IP address or network> .IP -Add permission flags to the peers connecting from the given IP address -(e.g. 1.2.3.4) or CIDR\-notated network (e.g. 1.2.3.0/24). Uses -the same permissions as \fB\-whitebind\fR. Can be specified multiple -times. +Add permission flags to the peers using the given IP address (e.g. +1.2.3.4) or CIDR\-notated network (e.g. 1.2.3.0/24). Uses the same +permissions as \fB\-whitebind\fR. Additional flags "in" and "out" +control whether permissions apply to incoming connections and/or +manual (default: incoming only). Can be specified multiple times. .PP Indexing options: .HP @@ -447,7 +451,7 @@ This will also rebuild active optional indexes. .IP Rebuild chain state from the currently indexed blocks. When in pruning mode or if blocks on disk might be corrupted, use full \fB\-reindex\fR -instead. Deactivate all optional indexes before running this. +instead. .HP \fB\-spentindex\fR .IP @@ -1059,15 +1063,15 @@ Relay non\-P2SH multisig (default: 1) .HP \fB\-whitelistforcerelay\fR .IP -Add 'forcerelay' permission to whitelisted inbound peers with default +Add 'forcerelay' permission to whitelisted peers with default permissions. This will relay transactions even if the transactions were already in the mempool. (default: 0) .HP \fB\-whitelistrelay\fR .IP -Add 'relay' permission to whitelisted inbound peers with default -permissions. This will accept relayed transactions even when not -relaying transactions (default: 1) +Add 'relay' permission to whitelisted peers with default permissions. +This will accept relayed transactions even when not relaying +transactions (default: 1) .PP Block creation options: .HP diff --git a/doc/man/dash-tx.1 b/doc/man/dash-tx.1 index f1317f16df76..932abfe40d4c 100644 --- a/doc/man/dash-tx.1 +++ b/doc/man/dash-tx.1 @@ -1,5 +1,5 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-TX "1" "October 2026" "dash-tx v24.0.0" "User Commands" +.TH DASH-TX "1" "November 2026" "dash-tx v24.0.0" "User Commands" .SH NAME dash-tx \- manual page for dash-tx v24.0.0 .SH SYNOPSIS diff --git a/doc/man/dash-util.1 b/doc/man/dash-util.1 index 9f7c983b6e06..40637cd6c6af 100644 --- a/doc/man/dash-util.1 +++ b/doc/man/dash-util.1 @@ -1,5 +1,5 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-UTIL "1" "October 2026" "dash-util v24.0.0" "User Commands" +.TH DASH-UTIL "1" "November 2026" "dash-util v24.0.0" "User Commands" .SH NAME dash-util \- manual page for dash-util v24.0.0 .SH SYNOPSIS diff --git a/doc/man/dash-wallet.1 b/doc/man/dash-wallet.1 index 0e4a33ece48e..73b24e314b25 100644 --- a/doc/man/dash-wallet.1 +++ b/doc/man/dash-wallet.1 @@ -1,5 +1,5 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-WALLET "1" "October 2026" "dash-wallet v24.0.0" "User Commands" +.TH DASH-WALLET "1" "November 2026" "dash-wallet v24.0.0" "User Commands" .SH NAME dash-wallet \- manual page for dash-wallet v24.0.0 .SH DESCRIPTION diff --git a/doc/man/dashd.1 b/doc/man/dashd.1 index 213ae11d5007..32fd5dcb4238 100644 --- a/doc/man/dashd.1 +++ b/doc/man/dashd.1 @@ -1,5 +1,5 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASHD "1" "October 2026" "dashd v24.0.0" "User Commands" +.TH DASHD "1" "November 2026" "dashd v24.0.0" "User Commands" .SH NAME dashd \- manual page for dashd v24.0.0 .SH SYNOPSIS @@ -28,9 +28,9 @@ datadir as a warning, not an error. If this block is in the chain assume that it and its ancestors are valid and potentially skip their script verification (0 to verify all, default: -00000000000000119fe42827219e0686d3f7b494ae65f823194c740c5dbab492, +000000000000000346a1804da4832b0b69dd9a7f96b14c7cb54585a9ac6ae98f, testnet: -000000541a23f9db7411cddbe50f9f1ebd4aa7108ebdcad62214753f648c0239, +000000116cd3c11d44c88cbc0a26804bd277a5d790f684ec3a8aaa820690318c, devnet: 0000000000000000000000000000000000000000000000000000000000000000) .HP @@ -58,10 +58,10 @@ Specify directory to hold blocks subdirectory for *.dat files (default: .HP \fB\-blocksonly\fR .IP -Whether to reject transactions from network peers. Automatic broadcast -and rebroadcast of any transactions from inbound peers is -disabled, unless the peer has the 'forcerelay' permission. RPC -transactions are not affected. (default: 0) +Whether to reject transactions from network peers. Disables automatic +broadcast and rebroadcast of transactions, unless the source peer +has the 'forcerelay' permission. RPC transactions are not +affected. (default: 0) .HP \fB\-chainlocknotify=\fR .IP @@ -220,10 +220,11 @@ Bind to given address and always listen on it (default: 0.0.0.0). Use connections to that address and port as incoming Tor connections (default: 127.0.0.1:9996=onion, testnet: 127.0.0.1:19996=onion, devnet: 127.0.0.1:19796=onion, regtest: 127.0.0.1:19896=onion). -The default onion bind is added only when no \fB\-bind\fR is specified. -When \fB\-listenonion\fR is enabled and \fB\-bind\fR is specified, a -non\-wildcard =onion bind is required, and wildcard =onion binds -are rejected. +Without an =onion bind, the default onion bind is added unless +\fB\-bind\fR is given and \fB\-listenonion\fR is disabled; failing to bind it +stops startup only with an explicit \fB\-listenonion\fR=\fI\,1\/\fR, and otherwise +no onion service is created. While \fB\-listenonion\fR is enabled, a +wildcard =onion bind is an error. .HP \fB\-cjdnsreachable\fR .IP @@ -283,7 +284,9 @@ Accept connections from outside (default: 1 if no \fB\-proxy\fR, \fB\-connect\fR .HP \fB\-listenonion\fR .IP -Automatically create Tor onion service (default: 1) +Automatically create Tor onion service if Tor is available and the onion +bind could be bound (see \fB\-bind\fR). If set to 1 explicitly, fail to +start if the onion bind cannot be bound (default: 1) .HP \fB\-maxconnections=\fR .IP @@ -424,10 +427,11 @@ download,noban,mempool,relay). Can be specified multiple times. .HP \fB\-whitelist=\fR<[permissions@]IP address or network> .IP -Add permission flags to the peers connecting from the given IP address -(e.g. 1.2.3.4) or CIDR\-notated network (e.g. 1.2.3.0/24). Uses -the same permissions as \fB\-whitebind\fR. Can be specified multiple -times. +Add permission flags to the peers using the given IP address (e.g. +1.2.3.4) or CIDR\-notated network (e.g. 1.2.3.0/24). Uses the same +permissions as \fB\-whitebind\fR. Additional flags "in" and "out" +control whether permissions apply to incoming connections and/or +manual (default: incoming only). Can be specified multiple times. .PP Indexing options: .HP @@ -445,7 +449,7 @@ This will also rebuild active optional indexes. .IP Rebuild chain state from the currently indexed blocks. When in pruning mode or if blocks on disk might be corrupted, use full \fB\-reindex\fR -instead. Deactivate all optional indexes before running this. +instead. .HP \fB\-spentindex\fR .IP @@ -1057,15 +1061,15 @@ Relay non\-P2SH multisig (default: 1) .HP \fB\-whitelistforcerelay\fR .IP -Add 'forcerelay' permission to whitelisted inbound peers with default +Add 'forcerelay' permission to whitelisted peers with default permissions. This will relay transactions even if the transactions were already in the mempool. (default: 0) .HP \fB\-whitelistrelay\fR .IP -Add 'relay' permission to whitelisted inbound peers with default -permissions. This will accept relayed transactions even when not -relaying transactions (default: 1) +Add 'relay' permission to whitelisted peers with default permissions. +This will accept relayed transactions even when not relaying +transactions (default: 1) .PP Block creation options: .HP diff --git a/doc/release-notes-16807.md b/doc/release-notes-16807.md deleted file mode 100644 index 3cdd0b36af5a..000000000000 --- a/doc/release-notes-16807.md +++ /dev/null @@ -1,10 +0,0 @@ -Updated RPCs ------------- - -- The `validateaddress` RPC now returns an `error_locations` array for invalid -addresses, with the indices of invalid character locations in the address (if -known). For example, this will attempt to locate up to two Bech32 errors, and -return their locations if successful. Success and correctness are only guaranteed -if fewer than two substitution errors have been made. -The error message returned in the `error` field now also returns more specific -errors when decoding fails. \ No newline at end of file diff --git a/doc/release-notes-19602.md b/doc/release-notes-19602.md deleted file mode 100644 index fc0a68a4a1a8..000000000000 --- a/doc/release-notes-19602.md +++ /dev/null @@ -1,9 +0,0 @@ -Wallet -====== - -Migrating Legacy Wallets to Descriptor Wallets ---------------------------------------------- - -An experimental RPC `migratewallet` has been added to migrate Legacy (non-descriptor) wallets to -Descriptor wallets. More information about the migration process is available in the -[documentation](https://github.com/dashpay/dash/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets). diff --git a/doc/release-notes-24118.md b/doc/release-notes-24118.md deleted file mode 100644 index e8b03fc8204e..000000000000 --- a/doc/release-notes-24118.md +++ /dev/null @@ -1,10 +0,0 @@ -New RPCs --------- - -- The `sendall` RPC spends specific UTXOs to one or more recipients - without creating change. By default, the `sendall` RPC will spend - every UTXO in the wallet. `sendall` is useful to empty wallets or to - create a changeless payment from select UTXOs. When creating a payment - from a specific amount for which the recipient incurs the transaction - fee, continue to use the `subtractfeefromamount` option via the - `send`, `sendtoaddress`, or `sendmany` RPCs. (#7131) diff --git a/doc/release-notes-25122.md b/doc/release-notes-25122.md deleted file mode 100644 index 5c5f0f911154..000000000000 --- a/doc/release-notes-25122.md +++ /dev/null @@ -1,7 +0,0 @@ - -Wallet ------- - -- RPC `getreceivedbylabel` now returns an error, "Label not found - in wallet" (-4), if the label is not in the address book. (dash#7550) - diff --git a/doc/release-notes-25204.md b/doc/release-notes-25204.md deleted file mode 100644 index b4336ae71b57..000000000000 --- a/doc/release-notes-25204.md +++ /dev/null @@ -1,9 +0,0 @@ -Updated RPCs ------------- - -- The `deprecatedrpc=fees` configuration option has been removed. The top-level - fee fields `fee`, `modifiedfee`, `ancestorfees` and `descendantfees` are no - longer returned by RPCs `getmempoolentry`, `getrawmempool(verbose=true)`, - `getmempoolancestors(verbose=true)` and `getmempooldescendants(verbose=true)`. - The same fee fields can be accessed through the `fees` object in the result. - The top-level fee fields were previously deprecated in 23.0. (#25204) diff --git a/doc/release-notes-25375.md b/doc/release-notes-25375.md deleted file mode 100644 index 504a2644f461..000000000000 --- a/doc/release-notes-25375.md +++ /dev/null @@ -1,11 +0,0 @@ -Updated RPCs --------- - -The `minconf` option, which allows a user to specify the minimum number -of confirmations a UTXO being spent has, and the `maxconf` option, -which allows specifying the maximum number of confirmations, have been -added to the following RPCs: -- `fundrawtransaction` -- `send` -- `walletcreatefundedpsbt` -- `sendall` diff --git a/doc/release-notes-25504.md b/doc/release-notes-25504.md deleted file mode 100644 index bf80f180318a..000000000000 --- a/doc/release-notes-25504.md +++ /dev/null @@ -1,6 +0,0 @@ -Updated RPCs ------------- - -- The `listsinceblock`, `listtransactions` and `gettransaction` output now contain a new - `parent_descs` field for every "receive" entry. -- A new optional `include_change` parameter was added to the `listsinceblock` command. diff --git a/doc/release-notes-25574.md b/doc/release-notes-25574.md deleted file mode 100644 index f8eed08e3dff..000000000000 --- a/doc/release-notes-25574.md +++ /dev/null @@ -1,13 +0,0 @@ -Updated settings ----------------- - -If the `-checkblocks` or `-checklevel` options are explicitly provided by the -user, but the verification checks cannot be completed due to an insufficient -dbcache, Dash Core will now return an error at startup. (dash#7710) - -RPC ---- -The `-verifychain` RPC will now return `false` if the checks didn't fail, -but couldn't be completed at the desired depth and level. This could be due -to missing data while pruning, due to an insufficient dbcache or due to -the node being shutdown before the call could finish. (dash#7710) diff --git a/doc/release-notes-25730.md b/doc/release-notes-25730.md deleted file mode 100644 index 33393cf31490..000000000000 --- a/doc/release-notes-25730.md +++ /dev/null @@ -1,6 +0,0 @@ -RPC Wallet ----------- - -- RPC `listunspent` now has a new argument `include_immature_coinbase` - to include coinbase UTXOs that don't meet the minimum spendability - depth requirement (which before were silently skipped). (#25730) \ No newline at end of file diff --git a/doc/release-notes-25934.md b/doc/release-notes-25934.md deleted file mode 100644 index b4f1ae0d3cf7..000000000000 --- a/doc/release-notes-25934.md +++ /dev/null @@ -1,8 +0,0 @@ -Low-level changes -================= - -RPC ---- - -- RPC `listsinceblock` now accepts an optional `label` argument - to fetch incoming transactions having the specified label. (#25934) \ No newline at end of file diff --git a/doc/release-notes-25957.md b/doc/release-notes-25957.md deleted file mode 100644 index c71afa2c2e17..000000000000 --- a/doc/release-notes-25957.md +++ /dev/null @@ -1,9 +0,0 @@ -Wallet ------- - -- Rescans for descriptor wallets are now significantly faster if compact - block filters (BIP158) are available. Since those are not constructed - by default, the configuration option "-blockfilterindex=1" has to be - provided to take advantage of the optimization. This improves the - performance of the RPC calls `rescanblockchain`, `importdescriptors` - and `restorewallet`. (#25957) diff --git a/doc/release-notes-26076.md b/doc/release-notes-26076.md deleted file mode 100644 index f95e4be0e391..000000000000 --- a/doc/release-notes-26076.md +++ /dev/null @@ -1,13 +0,0 @@ -RPC ---- - -- The `listdescriptors`, `decodepsbt` and similar RPC methods now show `h` rather than apostrophe (`'`) to indicate - hardened derivation. This does not apply when using the `private` parameter, which - matches the marker used when descriptor was generated or imported. Newly created - wallets use `h`. This change makes it easier to handle descriptor strings manually. - E.g. the `importdescriptors` RPC call is easiest to use `h` as the marker: `'["desc": ".../0h/..."]'`. - With this change `listdescriptors` will use `h`, so you can copy-paste the result, - without having to add escape characters or switch `'` to 'h' manually. - Note that this changes the descriptor checksum. - For legacy wallets the `hdkeypath` field in `getaddressinfo` is unchanged, - nor is the serialization format of wallet dumps. (#26076) diff --git a/doc/release-notes-26213.md b/doc/release-notes-26213.md deleted file mode 100644 index 2fba5ec6137f..000000000000 --- a/doc/release-notes-26213.md +++ /dev/null @@ -1,8 +0,0 @@ -Low-level changes -================= - -- Previously `setban`, `addpeeraddress`, `walletcreatefundedpsbt`, methods - allowed non-boolean and non-null values to be passed as boolean parameters. - Any string, number, array, or object value that was passed would be treated - as false. After this change, passing any value except `true`, `false`, or - `null` now triggers a JSON value is not of expected type error. (#7666) diff --git a/doc/release-notes-26265.md b/doc/release-notes-26265.md deleted file mode 100644 index ca2313d95694..000000000000 --- a/doc/release-notes-26265.md +++ /dev/null @@ -1,6 +0,0 @@ -P2P and network changes ---------- - -- Transactions of non-witness size 65 and above are now allowed by mempool - and relay policy. This is to better reflect the actual afforded protections - against CVE-2017-12842 and open up additional use-cases of smaller transaction sizes. (#26265) diff --git a/doc/release-notes-26471.md b/doc/release-notes-26471.md deleted file mode 100644 index 2cb74804cade..000000000000 --- a/doc/release-notes-26471.md +++ /dev/null @@ -1,13 +0,0 @@ -Updated settings ----------------- - -- Setting `-blocksonly` will now reduce the maximum mempool memory - to 5MB (users may still use `-maxmempool` to override). Previously, - the default 300MB would be used, leading to unexpected memory usage - for users running with `-blocksonly` expecting it to eliminate - mempool memory usage. - - As unused mempool memory is shared with dbcache, this also reduces - the dbcache size for users running with `-blocksonly`, potentially - impacting performance. - diff --git a/doc/release-notes-26646.md b/doc/release-notes-26646.md deleted file mode 100644 index 8765a8af594d..000000000000 --- a/doc/release-notes-26646.md +++ /dev/null @@ -1,8 +0,0 @@ -JSON-RPC --------- - -The `testmempoolaccept` RPC now returns 2 additional results within the "fees" result: -"effective-feerate" is the feerate including fees and sizes of transactions validated together if -package validation was used, and also includes any modified fees from prioritisetransaction. The -"effective-includes" result lists the txids of transactions whose modified fees and sizes were used -in the effective-feerate (#7684). diff --git a/doc/release-notes-27114.md b/doc/release-notes-27114.md deleted file mode 100644 index 980ffd78a44f..000000000000 --- a/doc/release-notes-27114.md +++ /dev/null @@ -1,2 +0,0 @@ -- Additional flags "in" and "out" have been added to `-whitelist` to control whether - permissions apply to incoming connections and/or manual (default: incoming only). \ No newline at end of file diff --git a/doc/release-notes-27217.md b/doc/release-notes-27217.md deleted file mode 100644 index ab1452fc9420..000000000000 --- a/doc/release-notes-27217.md +++ /dev/null @@ -1,6 +0,0 @@ -Wallet ------- - -* Address Purposes strings are now restricted to the currently known values of "send", "receive", and "refund". - Wallets that have unrecognized purpose strings will have loading warnings, and the `listlabels` - RPC will raise an error if an unrecognized purpose is requested. diff --git a/doc/release-notes-27279.md b/doc/release-notes-27279.md deleted file mode 100644 index 82bc604e8485..000000000000 --- a/doc/release-notes-27279.md +++ /dev/null @@ -1,10 +0,0 @@ -Wallet ------- - -- In the createwallet, loadwallet, unloadwallet, and restorewallet RPCs, the - "warning" string field is deprecated in favor of a "warnings" field that - returns a JSON array of strings to better handle multiple warning messages and - for consistency with other wallet RPCs. The "warning" field will be fully - removed from these RPCs in v25. It can be temporarily re-enabled during the - deprecation period by launching dashd with the configuration option - `-deprecatedrpc=walletwarningfield`. (dash#7711) diff --git a/doc/release-notes-27302.md b/doc/release-notes-27302.md deleted file mode 100644 index 5d6cfebacdc1..000000000000 --- a/doc/release-notes-27302.md +++ /dev/null @@ -1,4 +0,0 @@ -Configuration ---- - -- `dashd` and `dash-qt` will now raise an error on startup if a datadir that is being used contains a dash.conf file that will be ignored, which can happen when a datadir= line is used in a dash.conf file. The error message is just a diagnostic intended to prevent accidental misconfiguration, and it can be disabled to restore the previous behavior of using the datadir while ignoring the dash.conf contained in it. (dash#7710) diff --git a/doc/release-notes-27632.md b/doc/release-notes-27632.md deleted file mode 100644 index e267222aa7d6..000000000000 --- a/doc/release-notes-27632.md +++ /dev/null @@ -1,5 +0,0 @@ -Updated settings ----------------- - -- Passing an invalid `-debug`, `-debugexclude`, or `-loglevel` logging configuration - option now raises an error, rather than logging an easily missed warning. (dash#7710) diff --git a/doc/release-notes-28113.md b/doc/release-notes-28113.md index 7ae5f6ce7776..718b2776eef4 100644 --- a/doc/release-notes-28113.md +++ b/doc/release-notes-28113.md @@ -1,7 +1,6 @@ RPC Wallet ---------- -- The `signrawtransactionwithkey`, `signrawtransactionwithwallet`, - `walletprocesspsbt` and `descriptorprocesspsbt` calls now return the more - specific RPC_INVALID_PARAMETER error instead of RPC_MISC_ERROR if their - sighashtype argument is malformed. (dash#7710) +- The `descriptorprocesspsbt` call returns the more specific + RPC_INVALID_PARAMETER error instead of RPC_MISC_ERROR if its sighashtype + argument is malformed, as `walletprocesspsbt` does. (dash#7710) diff --git a/doc/release-notes-28354.md b/doc/release-notes-28354.md deleted file mode 100644 index 28a358c89d6b..000000000000 --- a/doc/release-notes-28354.md +++ /dev/null @@ -1,6 +0,0 @@ -Tests ------ - -- Non-standard transactions are now disabled by default on testnet and devnets - for relay and mempool acceptance. The previous behaviour can be - re-enabled by setting `-acceptnonstdtxn=1`. (dash#7710) diff --git a/doc/release-notes-28414.md b/doc/release-notes-28414.md index 3f83a7325254..563c6002637d 100644 --- a/doc/release-notes-28414.md +++ b/doc/release-notes-28414.md @@ -1,6 +1,5 @@ RPC Wallet ---------- -- RPC `walletprocesspsbt`, and `descriptorprocesspsbt` return object now includes field `hex` (if the transaction +- RPC `descriptorprocesspsbt` return object includes field `hex` (if the transaction is complete) containing the serialized transaction suitable for RPC `sendrawtransaction`. - diff --git a/doc/release-notes-29189.md b/doc/release-notes-29189.md deleted file mode 100644 index 3bed5ab5ef2b..000000000000 --- a/doc/release-notes-29189.md +++ /dev/null @@ -1,15 +0,0 @@ -dashconsensus -======================== - -This library is deprecated and will be removed for v28. - -It has existed for nearly 10 years with very little known uptake or impact. It -has become a maintenance burden. - -The underlying functionality does not change between versions, so any users of -the library can continue to use the final release indefinitely, with the -understanding that it will not receive future consensus updates. - -In the future, a kernel library will provide a much more useful API that is -aware of the UTXO set, and therefore be able to fully validate transactions and -blocks. diff --git a/doc/release-notes-6236.md b/doc/release-notes-6236.md deleted file mode 100644 index 17c5df40e6e8..000000000000 --- a/doc/release-notes-6236.md +++ /dev/null @@ -1,6 +0,0 @@ -Miscellaneous -------------- - -- Synced nodes now recover and relay ChainLocks embedded in newly connected - blocks, even when the original ChainLock message was missed. This applies - after v20 activation while ChainLocks are enabled. (#6236) diff --git a/doc/release-notes-6888.md b/doc/release-notes-6888.md deleted file mode 100644 index ae2a9c8d1aba..000000000000 --- a/doc/release-notes-6888.md +++ /dev/null @@ -1,17 +0,0 @@ -Updated RPCs ------------- - -- Information on soft fork status has been moved from `getblockchaininfo` - to the new `getdeploymentinfo` RPC which allows querying soft fork status at any - block, rather than just at the chain tip. Inclusion of soft fork - status in `getblockchaininfo` can currently be restored using the - configuration `-deprecatedrpc=softforks`, but this will be removed in - a future release. Note that in either case, the `status` field - now reflects the status of the current block rather than the next - block (#6888). - -New REST endpoint ------------------ - -- A new `/rest/deploymentinfo` endpoint has been added for fetching various - state info regarding deployments of consensus changes (#6888). diff --git a/doc/release-notes-7052.md b/doc/release-notes-7052.md deleted file mode 100644 index fd611b543701..000000000000 --- a/doc/release-notes-7052.md +++ /dev/null @@ -1,45 +0,0 @@ -P2P and network changes ------------------------ - -- The protocol version was bumped to 70241. The `dsa` message gained a - version-gated flags field declaring which mixing direction a - participant intends. A session commits to carrying promotion/demotion - entries only once a participant is admitted that actually declared one, - and it becomes closed to pre-70241 clients only from that point on; - conversely, a session that has already admitted a pre-70241 client - refuses later promotion/demotion participants. Either way the refusal - happens at acceptance time, before any collateral is committed, so a - client doing ordinary 1:1 mixing is never turned away from a session - simply because of who opened it. Unbalanced (promotion/demotion) DSTXes - are only announced as `dstx` to peers at protocol 70241 or newer, since - older peers would reject them as structurally invalid and penalize the - relayer; those peers are sent a plain `tx` announcement instead, so - they still receive the transaction without the mixing metadata they - cannot parse. (#7052) - -- A mixing session only completes once each side of its denomination is - occupied by nobody or by at least two participants, since coins are - only concealed by other coins of the same size on the same side. A - session that attracts a lone promotion or demotion participant and no - counterpart therefore waits, and expires in the queue stage without - charging anyone's collateral, rather than publishing a transaction that - would identify that participant's coins. Because admission relies on - the declared directions, a participant whose entry deviates from what - it declared has its collateral consumed. (#7052) - -Wallet ------- - -- CoinJoin can now promote and demote between adjacent standard - denominations within a mixing session after V24 activation. - Promotion combines 10 inputs of one denomination into 1 output of the - next larger denomination, while demotion splits 1 input into 10 - outputs of the next smaller denomination. Pre-V24 behavior remains - unchanged. (#7052) - -- Conversions only spend fully-mixed coins, and their outputs start - mixing over from zero rounds. The 10:1 shape of a conversion publicly - clusters one participant's coins even inside a mixing transaction, so - a converted coin is not treated as mixed: it re-enters mixing at its - new denomination and disperses normally, while the histories of the - fully-mixed coins that fed the conversion remain protected. (#7052) diff --git a/doc/release-notes-7099.md b/doc/release-notes-7099.md deleted file mode 100644 index c14a367f6f93..000000000000 --- a/doc/release-notes-7099.md +++ /dev/null @@ -1,25 +0,0 @@ -Updated RPCs ------------- - -* Dash RPCs will no longer permit submitting strings to boolean input fields in line with validation - enforced on upstream RPCs, where this is already the case. Requests must now use unquoted `true` - or `false`. - - * The following RPCs are affected, `bls generate`, `bls fromsecret`, `coinjoinsalt generate`, - `coinjoinsalt set`, `masternode connect`, `protx diff`, `protx list`, `protx register`, - `protx register_legacy`, `protx register_evo`, `protx register_fund`, `protx register_fund_legacy`, - `protx register_fund_evo`, `protx revoke`, `protx update_registrar`, `protx update_registrar_legacy`, - `protx update_service`, `protx update_service_evo`, `quorum info`, `quorum platformsign`, - `quorum rotationinfo`, `quorum sign`. - - * This restriction can be relaxed by setting `-deprecatedrpc=permissive_bool` at runtime - but is liable to be removed in future versions of Dash Core. - -* Numeric arguments of the Dash-specific RPCs (`quorum`, `protx`, `gobject`, - `masternode` and their sub-commands) must now be passed as JSON numbers. - Strings containing a number, which earlier versions accepted, are rejected - with a type error (code -3). The only exception is the `baseBlock` and - `block` arguments of `protx diff` and `protx listdiff`, which take a block - hash or a height and therefore still accept a height as a string. There is - no runtime option to restore the old behaviour; `-deprecatedrpc=permissive_bool` - only applies to booleans. diff --git a/doc/release-notes-7101.md b/doc/release-notes-7101.md deleted file mode 100644 index b273e69bf994..000000000000 --- a/doc/release-notes-7101.md +++ /dev/null @@ -1,13 +0,0 @@ -## Indexes - -### Async Index Migration (#7101) - -`TimestampIndex`, `SpentIndex`, and `AddressIndex` have been migrated from synchronous to asynchronous operation, following the same pattern as `TxIndex` and other indexes using `BaseIndex` framework. - -When enabling an index for the first time, the node will build the index in the background while remaining fully operational. Progress can be monitored via the `getindexinfo` RPC. - -Existing nodes with indexes enabled will automatically migrate data from the old location (block index database) to new separate databases on first startup. This migration may take 20-40 minutes or longer depending on hardware specifications and index sizes. The node will log progress during migration. - -Breaking changes: -- `SpentIndex` and `AddressIndex` are incompatible with pruned nodes as they require access to undo data now -- `TimestampIndex` can no longer be enabled on a datadir where pruning has already occurred. It still works when started together with `-prune` from a fresh sync or reindex (the index is built forward as blocks arrive), but enabling it on an existing pre-pruned datadir now fails at startup. The old synchronous implementation built forward from the current tip and accepted that case diff --git a/doc/release-notes-7107.md b/doc/release-notes-7107.md deleted file mode 100644 index c55325465ae4..000000000000 --- a/doc/release-notes-7107.md +++ /dev/null @@ -1,9 +0,0 @@ -New RPCs --------- - -- Add `getquorumproofchain` and `verifyquorumproofchain` for compact mining-transaction - proofs from an independently trusted snapshot, plus `getchainlockbyheight` for - historical coinbase-carried certificates. The RPCs read required blocks on - demand, without an additional index or startup scan, and keep what they read - in bounded in-memory caches of up to about 50 MiB. Nodes must retain the - required historical blocks to generate proofs. (#7107, #7727) diff --git a/doc/release-notes-7181.md b/doc/release-notes-7181.md deleted file mode 100644 index 3c7784c5afb0..000000000000 --- a/doc/release-notes-7181.md +++ /dev/null @@ -1,14 +0,0 @@ -Updated RPCs ------------- - -* The deprecated keys `service`, `platformP2PPort` and `platformHTTPPort` will now require the runtime - flag `-deprecatedrpc=service`. - * The following RPCs are affected `decoderawtransaction`, `decodepsbt`, `getblock`, - `getrawtransaction`, `gettransaction`, `masternode status` (only the `dmnState` key), `protx diff`, - `protx listdiff`. - * This runtime gate also extends to the functionally identical key, `address` in `masternode list` - (and its alias, `masternodelist`) - * The same gate applies to `getcoinjoininfo`, `protx info`, `protx list detailed` - and `quorum info`. - * `dash-tx -json` output omits these keys as well and offers no way to restore - them, since `dash-tx` does not accept `-deprecatedrpc`. diff --git a/doc/release-notes-7204.md b/doc/release-notes-7204.md deleted file mode 100644 index fd8b4744470b..000000000000 --- a/doc/release-notes-7204.md +++ /dev/null @@ -1,21 +0,0 @@ -Notable changes -=============== - -Updated RPCs ------------- - - -Changes to wallet related RPCs can be found in the Wallet section below. - -Wallet ------- - -- Descriptor wallets are now the default wallet type. Newly created wallets - will use descriptors unless `descriptors=false` is set during `createwallet`, or - the `Descriptor wallet` checkbox is unchecked in the GUI. (dash#7204) - - Note that wallet RPC commands like `importmulti` and `dumpprivkey` cannot be - used with descriptor wallets, so if your client code relies on these commands - without specifying `descriptors=false` during wallet creation, you will need - to update your code. - diff --git a/doc/release-notes-7261.md b/doc/release-notes-7261.md deleted file mode 100644 index 3e6478a54913..000000000000 --- a/doc/release-notes-7261.md +++ /dev/null @@ -1,8 +0,0 @@ -Wallet ------- - -* `fundrawtransaction`, `send`, `sendall` and `walletcreatefundedpsbt` accept a - `use_cj` option, previously available only on `sendtoaddress` and `sendmany`, - that restricts coin selection to fully mixed CoinJoin outputs. `send` and - `sendall` record the resulting transaction as a CoinJoin spend (`DS` in - `gettransaction`), as `sendtoaddress` and `sendmany` already do. diff --git a/doc/release-notes-7265.md b/doc/release-notes-7265.md deleted file mode 100644 index ac6ac41cff19..000000000000 --- a/doc/release-notes-7265.md +++ /dev/null @@ -1,11 +0,0 @@ -New settings ------------- - -* The dust attack protection introduced in v23.1.0 as a GUI option is now - available to `dashd` as well through `-dustprotectionthreshold=`: UTXOs - received from external transactions whose value is at or below `` duffs are - locked automatically by the wallet, so they are not spent together with other - coins. It is disabled by default (`0`). The GUI option and the command-line - option control the same setting. Locks persist across restarts and are not - released when the threshold is lowered or the option is removed; use - `lockunspent` to unlock such outputs manually. diff --git a/doc/release-notes-7278.md b/doc/release-notes-7278.md deleted file mode 100644 index 9adbdcd16591..000000000000 --- a/doc/release-notes-7278.md +++ /dev/null @@ -1,19 +0,0 @@ -Removed Sporks --------------- - -* `SPORK_3_INSTANTSEND_BLOCK_FILTERING` and `SPORK_9_SUPERBLOCKS_ENABLED` have - been removed. These sporks were already effectively always enabled on mainnet - but continued to gate behavior on test networks (testnet, regtest, and devnet). - The associated functionality (InstantSend conflicting-block rejection and - superblock payments) is now permanently enabled across all networks, and the - sporks will no longer appear in the `spork` RPC output. - -Updated RPCs ------------- - -* `getblocktemplate` now always reports `superblocks_enabled` as `true`. The - field is retained for backwards compatibility. - -* `getblocktemplate` now requires a fully synced node at superblock heights. - This check is skipped on test networks. Previously it was gated by - `SPORK_9_SUPERBLOCKS_ENABLED` which was already always active on mainnet. diff --git a/doc/release-notes-7294.md b/doc/release-notes-7294.md deleted file mode 100644 index bc317cf12f7e..000000000000 --- a/doc/release-notes-7294.md +++ /dev/null @@ -1,44 +0,0 @@ -Consensus changes ------------------ - -* Asset Lock special transactions gain a payload version 2, enabled by the `v24` - hard fork. Before activation only version 1 is valid; after activation both - version 1 and version 2 are. A version 2 payload signals that Platform assigns - each credit output to the matching Identity automatically, and it extends the - allowed `creditOutputs[].scriptPubKey` forms from P2PKH only to P2PKH and P2SH. - All other Asset Lock rules are unchanged. See DIP-27. (dash#7294) - -Updated RPCs ------------- - -* `validateaddress` and `getaddressinfo` now accept DIP-18 Dash Platform - addresses (`dash1k…`/`dash1s…` on mainnet, `tdash1k…`/`tdash1s…` on the test - chains) and report them with a new `isplatform` field. `getaddressinfo` - describes such an address against the credit output script an Asset Lock would - carry for it, so `ismine` and `solvable` answer whether this wallet holds the - key or script behind the address. (dash#7294) - -* `sendtoaddress` and `sendmany` accept Platform addresses as recipients. Doing - so turns the transaction into an Asset Lock with a version 2 payload whose - credit outputs are the Platform recipients, plus a single empty `OP_RETURN` - output carrying their total. `subtractfeefromamount` is not supported for - Platform recipients, because the locked amount has to match the `OP_RETURN` - value exactly. (dash#7294) - -* `getrawtransaction`, `decoderawtransaction` and the other transaction-decoding - RPCs report `assetLockTx.creditOutputs[].address` for version 2 payloads, the - DIP-18 Platform address the credit output pays. Version 1 payloads carry no - such address and the field is omitted. (dash#7294) - -Notes ------ - -* This release carries the consensus side of version 2 Asset Locks: after the - `v24` hard fork they are valid in a block. They remain non-standard for now, - so under default policy they are not accepted into the mempool or relayed, - and sending to a Platform address fails with - `Transaction is non-standard (assetlocktx-version-2) …`. A future release - will make them standard once Dash Platform can process them; that is a - policy change only and needs no further consensus change. On testnet, - devnets and regtest the node can be started with `-acceptnonstdtxn=1` to - relay them already; mainnet does not accept that option. (dash#7294) diff --git a/doc/release-notes-7300.md b/doc/release-notes-7300.md deleted file mode 100644 index a3bd6502dac2..000000000000 --- a/doc/release-notes-7300.md +++ /dev/null @@ -1,28 +0,0 @@ -P2P and network changes ------------------------ - -* Startup now fails if any configured `-bind` (including `-bind=...=onion`) or - `-whitebind` cannot be set up. Dash Core v23 and earlier started as long as - at least one bind succeeded. The implicit Tor onion-service bind - (`127.0.0.1:9996` by default) is still best effort, as in v23, unless - `-listenonion=1` is set explicitly. - -* The automatic Tor onion service (`-listenonion`) only forwards to a - dedicated, non-wildcard onion listener that the node actually bound, so peers - arriving through Tor are always recognized as onion peers. Without a - `-bind==onion`, Dash Core adds the default onion bind as v23 did, - also when `-bind` is given; with `-bind` and `-listenonion=0` it no longer - does. If the default onion bind fails, for example because another instance - on the same host holds it, the node logs a warning and creates no onion - service rather than pointing Tor at whatever holds that port. It still - starts and still uses Tor for outbound onion connections if its control port - is reachable; the debug log notes that no onion service was created. With an - explicit `-listenonion=1`, a failed default onion bind makes startup fail. To - run onion services for several instances on one host, give each its own - `-bind=127.0.0.1:=onion`. - -* A wildcard onion bind such as `-bind=0.0.0.0:=onion` is a startup error - unless `-listenonion=0` is set, also with the default `-listenonion`. The node - can't tell which connections to a wildcard listener came through Tor, so Tor - peers would be treated as clearnet peers. Dash Core v23 accepted it. Use a - specific address such as `-bind=127.0.0.1:=onion` instead. diff --git a/doc/release-notes-7335.md b/doc/release-notes-7335.md deleted file mode 100644 index ddfa30522e00..000000000000 --- a/doc/release-notes-7335.md +++ /dev/null @@ -1,6 +0,0 @@ -Updated RPCs ------------- - -* `gettxoutsetinfo` no longer returns `block_info.unspendables.bip30`. Dash - never had transactions overridden by duplicates, so the value was always - zero. diff --git a/doc/release-notes-7340.md b/doc/release-notes-7340.md deleted file mode 100644 index 39d31387f83e..000000000000 --- a/doc/release-notes-7340.md +++ /dev/null @@ -1,17 +0,0 @@ -Updated RPCs ------------- - -* The `payoutAddress` argument of `protx register`, `protx register_legacy`, - `protx register_evo`, `protx register_fund`, `protx register_fund_legacy`, - `protx register_fund_evo` and `protx update_registrar` accepts, in addition to - a single address, an array of `{"address": ..., "reward": ...}` objects that - splits the owner reward between several payees, with `reward` given in basis - points. Multi-party payouts are only valid once the v24 hard fork activates. - -* For ExtAddr (version 3) masternode states and ProTx payloads the payout list - is reported as a `payouts` array in place of the single `payoutAddress` - field, which legacy versions keep. Shared masternodes report `shares` - instead. The fields appear in `protx info`, `protx list detailed`, - `protx listdiff`, `masternode status` (`dmnState`) and in decoded - `ProRegTx`/`ProUpRegTx` payloads of the transaction-decoding RPCs; - `protx diff` includes them only with `extended=true`. diff --git a/doc/release-notes-7428.md b/doc/release-notes-7428.md deleted file mode 100644 index e73c44e5c2cd..000000000000 --- a/doc/release-notes-7428.md +++ /dev/null @@ -1,7 +0,0 @@ -Updated RPCs ------------- - -* `quorum dkginfo` accepts an optional `proTxHash` argument and reports, in a - new `upcoming_dkgs` array, the DKG sessions that masternode will take part in - whose work block is already mined. Without the argument the local active - masternode is used, if any. diff --git a/doc/release-notes-7437.md b/doc/release-notes-7437.md deleted file mode 100644 index 655aa14bfd07..000000000000 --- a/doc/release-notes-7437.md +++ /dev/null @@ -1,107 +0,0 @@ -# Decentralized Masternode Shares - -This release implements the Decentralized Masternode Shares DIP, activating -together with DIP-0026 multi-party payouts as part of the v24 hard fork -(`DEPLOYMENT_V24`). Before activation there is no behavior change. - -## Consensus changes (active with v24) - -- A version 3 (extended addresses) ProRegTx may carry a collateral share table: 2 to 8 participants - fund the masternode collateral atomically in one registration, each recording - an immutable amount, refund script and share owner key, plus an updatable - reward script. Every share owner consents by signing a digest that binds the - exact funding inputs, all outputs, the share table, the penalty terms and the - registrar configuration. Consent is tied to the shares in the table, not to - the funding inputs: signing an input into a registration neither requires nor - creates a share for its owner. The early-period penalty must be below the - smallest share and must be zero when no early period is configured. -- The shared collateral is paid to the 7-byte template script - `04445348437551` (`0x04 "DSHC" OP_DROP OP_TRUE`). From activation, an output - paying this exact script is valid only as the collateral of a valid shared - registration, and spending such an output is valid only via a ProDisTx. - Template outputs mined before activation become permanently unspendable. -- Three new special transaction types: - - **ProDisTx (type 10)** dissolves a shared masternode, refunding every - participant's principal to its immutable refund script. Exactly one - signature (unilateral, penalized during the configured early period) or one - per share (unanimous, penalty-free). Validity is monotone: a ProDisTx that - is valid at some height is valid at every later height, which makes offline - "standby dissolutions" safe. The transaction fee is capped at 1000000 duffs - and a unilateral dissolution may not pay bonuses beyond the configured - early penalty, bounding what a stolen share owner key can drain from its - own share. - - **ProUpShareTx (type 11)** lets one share owner update their reward script. - - **ProUpSharedRegTx (type 12)** updates the operator key and/or voting key - with a signature from every share owner. A plain ProUpRegTx is invalid for - shared masternodes. -- The owner reward of a shared masternode is split across the share table - proportionally to the recorded contributions (sequential floor, remainder to - the last entry), paying each share's reward script (or its refund script when - none is set). Operator rewards are unchanged. -- Withdrawal (asset unlock) transactions may not pay the template script. - -## Relay policy changes - -- The template output relays only as the declared collateral output of a shared - registration, and a template prevout is accepted only inside a ProDisTx; both - remain nonstandard everywhere else. - -## New RPCs - -- `protx shared_register_prepare` builds an unsigned shared registration from a - caller-supplied funding transaction. The result echoes the decoded terms and - carries a `warning` when `earlyPenalty` is zero, since any participant can - then force an early exit at no cost beyond the transaction fee. Before signing - its funding inputs with `signrawtransactionwithwallet`, each participant should - confirm that the share table (`proRegTx.shares` in `decoderawtransaction`) - holds its share with its own amount and addresses. -- `protx shared_sign` signs a shared registration, dissolution or shared - registrar update with every share owner key the wallet holds. It returns the - decoded terms being consented to (for a dissolution, including the outputs) - alongside the signatures, and repeats the zero-penalty warning for a - registration. It refuses a registration or dissolution carrying an - unsatisfied lock time or a relative input lock unless `allowTimeLocks` is - set. It signs a dissolution only when it returns every share's principal to - its refund address, less the fee from the actor's share, as - `protx shared_dissolve_prepare` builds it. -- `protx shared_combine` combines collected signatures and optionally submits. - A dissolution combined here requires a signature from every share; unilateral - dissolutions come fully signed from `protx shared_dissolve`. -- `protx shared_dissolve` creates, signs and submits a unilateral ProDisTx (or, with - `submit=false`, returns hex suitable for offline standby storage). -- `protx shared_dissolve_prepare` builds an unsigned unanimous ProDisTx. -- `protx shared_update_share` updates one share's reward address. To restore rewards to the immutable refund address, pass that address explicitly; empty reward scripts are not valid in update transactions. -- `protx shared_update_registrar_prepare` builds an unsigned ProUpSharedRegTx. - -Updated RPCs ------------- - -- `masternodelist` and `masternode list` report comma-separated share owner - addresses in `owneraddress` for shared masternodes. The `json` and `recent` - modes can be filtered by any share owner address. Shared registrations and - masternode state omit the singular `ownerAddress` field in `protx` and decoded - transaction output; each participant's owner address is in `shares`. (#7437) - -GUI changes ------------ - -- The owned-masternode filter includes shared masternodes when the wallet holds - a participant's refund destination, including when rewards go to a different - wallet. (#7437) -- The Masternodes tab gains a "Shared Masternode…" wizard for registering a - masternode funded by several people. The coordinator enters the participants, - masternode settings and exit terms, reserves coins for their own share and - copies one invitation; every participant pastes it, reserves their coins and - copies back their details. Two more rounds complete the registration: locked - terms out and approvals back, then a signing request out and signed - contributions back. Any message can be pasted from the landing page, replies - are accepted in any order, and every message shows a short code so - participants can confirm they hold the same one. Sessions can be saved and - reopened by either role. Reserved coins are released after broadcast. -- Shared masternodes appear in the list with the type "Shared (you hold k of - n)", a details view listing every share, and context-menu actions to change - the wallet's reward address, rotate the operator or voting key (with every - share owner's approval), dissolve now, dissolve together, or create a - standby dissolution file holding both the penalty-free and the immediate - variant. Pasting a maintenance request or a standby dissolution into the - list opens the matching dialog. diff --git a/doc/release-notes-7473.md b/doc/release-notes-7473.md deleted file mode 100644 index a4313023e891..000000000000 --- a/doc/release-notes-7473.md +++ /dev/null @@ -1,25 +0,0 @@ -Notable changes -=============== - -* Masternode operator key uniqueness is now enforced per key rather than per BLS - encoding. After the v24 hard fork activates, registering or updating to an - operator public key already used by another masternode is rejected regardless of - which BLS scheme (legacy or basic) either side is encoded under, closing a gap - where the same key could be claimed twice under different encodings. - -Updated RPCs ------------- - -* After the v24 hard fork activates, a legacy (LegacyBLS) masternode migrates to the - basic BLS scheme *in place* when its state version is raised, keeping the same - operator key: the stored operator public key is re-encoded from the legacy to the - basic scheme, with no key rotation required. `protx update_service` and - `protx update_registrar` build the corresponding basic-scheme migration - transaction for a legacy masternode, and the masternode is no longer PoSe-banned by - the change. The `..._legacy` RPC variants keep the masternode on the legacy scheme. - Previously a legacy masternode could not move to the basic scheme without - effectively rotating its operator key, and `update_registrar` clamped the - transaction version silently. - -These changes are gated on the v24 deployment and have no effect until it activates -(v24 is not yet scheduled on mainnet or testnet). diff --git a/doc/release-notes-7480.md b/doc/release-notes-7480.md deleted file mode 100644 index ec2892275529..000000000000 --- a/doc/release-notes-7480.md +++ /dev/null @@ -1,28 +0,0 @@ -Updated RPCs ------------- - -* `getcoinjoininfo` gained a `pending_inputs` field, reporting how many - successfully mixed inputs are currently kept locked while waiting for the - finalized mixing transaction spending them to be observed. - -CoinJoin --------- - -* After a mixing session completes successfully, the inputs a client - contributed to it are no longer released as soon as the `DSCOMPLETE` message - is processed. They stay locked until the wallet observes a transaction - spending them, or for at most an hour if that transaction never propagates. - Previously the completion message routinely overtook the trickle-relayed - mixing transaction, leaving a window in which another session (with - `-coinjoinmultisession=1`, where the one-block cooldown does not apply) could - select and sign the very same inputs and produce a second, conflicting - CoinJoin transaction. - - These locks are persisted, so they survive a restart. They are tracked in a - new wallet database record, `cj_pending_obs`, which is written only when a - mixing session completes successfully. Older clients loading such a wallet - ignore the record, counting it as an unknown record; the accompanying - `lockedutxo` entries are understood by them regardless, so the inputs stay - locked either way. Locks the user set themselves via `lockunspent` are never - adopted or released by this mechanism, and unlocking a pending input manually - purges it from the pending set. diff --git a/doc/release-notes-7505.md b/doc/release-notes-7505.md deleted file mode 100644 index 749abb2fa328..000000000000 --- a/doc/release-notes-7505.md +++ /dev/null @@ -1,20 +0,0 @@ -Removed command-line options ---------------------------- - -* `-minsporkkeys` has been removed. Multi-key ("M-of-N") spork signing was never - deployed on any network — every chain shipped a single spork address with a - threshold of one — and the implementation has been removed. (dash#7505) - -Updated command-line options ----------------------------- - -* `-sporkaddr` now configures a single spork address. Previously it could be - specified multiple times to configure a set of valid spork signers. - (dash#7505) - -Notes ------ - -* The `sporks.dat` cache format changed. Caches written by previous versions are - discarded on startup and sporks are re-synced from peers, as is already the - case for any cache-format change. (dash#7505) diff --git a/doc/release-notes-7570.md b/doc/release-notes-7570.md deleted file mode 100644 index 4147781d3abc..000000000000 --- a/doc/release-notes-7570.md +++ /dev/null @@ -1,8 +0,0 @@ -Bug Fixes ---------- - -- Block template creation now checks credit pool limits across complete - transaction packages. Because Asset Unlock limits are cumulative, a package - may exceed the block's limit even though its transactions were accepted - individually. Such packages are now skipped so miners can continue building - a template instead of template creation failing. (#7570) diff --git a/doc/release-notes-7595.md b/doc/release-notes-7595.md deleted file mode 100644 index deedec190141..000000000000 --- a/doc/release-notes-7595.md +++ /dev/null @@ -1,9 +0,0 @@ -GUI changes ------------ - -- Dash-Qt now labels masternode registration and update transactions in the - transaction history as **Masternode Registration** and **Masternode Update** - instead of generic "Payment to yourself" rows. A new **Masternode** filter - shows only these operations. The amount shown is the transaction's net effect - on your wallet (for example, the network fee on a self-funded registration). - (#7595) diff --git a/doc/release-notes-7600.md b/doc/release-notes-7600.md deleted file mode 100644 index 323608c15252..000000000000 --- a/doc/release-notes-7600.md +++ /dev/null @@ -1,16 +0,0 @@ -RPC changes ------------ - -- Normal and Evo `protx` registration and maintenance commands now share a - typed provider-transaction implementation with other wallet frontends. RPC - names and successful result formats are unchanged. Fixed: when a wallet - cannot completely sign the inputs it selected (e.g. `protx register_submit` - run in a different wallet than the one that prepared the registration), - the command now fails with a clear wallet error naming the problem instead - of reporting success with a partially signed transaction or attempting a - broadcast that failed mempool acceptance with a bare `-26` error. The - external-signing workflow (`protx register_prepare` followed by - `protx register_submit`) is unchanged. - `protx update_service` on a masternode whose state does not yield a usable - default fee source now returns an explicit "specify feeSourceAddress" - parameter error instead of an internal error. (#7600) diff --git a/doc/release-notes-7618.md b/doc/release-notes-7618.md deleted file mode 100644 index 02ea16131a6b..000000000000 --- a/doc/release-notes-7618.md +++ /dev/null @@ -1,9 +0,0 @@ -GUI changes ------------ - -- Dash-Qt can now register and maintain regular masternodes and EvoNodes from - the Masternodes tab. The registration wizard supports wallet-funded, - wallet-owned, and externally held collateral, while row actions provide - Update Service, Update Registrar, and Revoke workflows. Generated operator - keys are shown and confirmed before registration; wallet-seed-derived - operator keys are not required. (#7618) diff --git a/doc/release-notes-7629.md b/doc/release-notes-7629.md deleted file mode 100644 index 4d4973c4a93c..000000000000 --- a/doc/release-notes-7629.md +++ /dev/null @@ -1,10 +0,0 @@ -P2P and network changes ------------------------ - -- `getqrinfo` requests now carry at most 4096 `baseBlockHashes`. A request - with more is rejected before it is parsed and the sending peer is penalised - as misbehaving. No known client sends more than a handful; the previous - format accepted up to 98304 entries in one message, which an - unauthenticated peer could use to make the node do work proportional to - the list size while holding `cs_main`. The `quorum rotationinfo` RPC - applies the same limit and returns an error when it is exceeded. (#7629) diff --git a/doc/release-notes-7634.md b/doc/release-notes-7634.md deleted file mode 100644 index 464d5c842c4d..000000000000 --- a/doc/release-notes-7634.md +++ /dev/null @@ -1,10 +0,0 @@ -Wallet changes --------------- - -- CoinJoin denomination counts, average mixing rounds and the normalized - anonymized balance no longer include outputs of transactions that cannot - confirm as they stand: conflicted ones, and ones that were abandoned, never - broadcast, or rejected from the mempool. Previously such outputs inflated - these figures, which could make the wallet create fewer denominations than - intended and report mixing progress that did not match the coins it could - actually use. (#7634) diff --git a/doc/release-notes-7639.md b/doc/release-notes-7639.md deleted file mode 100644 index 70f33f1f6922..000000000000 --- a/doc/release-notes-7639.md +++ /dev/null @@ -1,39 +0,0 @@ -Notable changes ---------------- - -### Version 2 Asset Unlock transactions (v24) - -Once the `v24` hard fork activates, Platform withdrawals are issued as version 2 -Asset Unlock transactions. Their transaction hash is computed with the quorum -signing fields (`requestedHeight`, `quorumHash`, `quorumSig`) zeroed, so every -instance Platform re-signs after an expiry is the same transaction with one -stable txid. Spends of an unmined withdrawal's outputs therefore stay valid -across re-signs. - -A version 2 Asset Unlock is InstantSend-locked as soon as it can be mined in -the next block: it carries a valid signature from a recent quorum, is inside -its height window, no other instance of its withdrawal index is in the -mempool, and the withdrawals pending in the mempool fit the credit pool's -current limit. The lock pins the withdrawal index (as the outpoint -`{DIP-27 request id, 0}`) to the txid. Spends of a locked withdrawal are -ordinary InstantSend transactions and the wallet treats the withdrawal's -outputs as trusted, so Platform-to-Core transfers become rapidly respendable. - -Version 2 unlocks are relayed by instance hash (new inventory type -`MSG_ASSET_UNLOCK`, protocol version 70242), kept in the mempool while expired -awaiting a re-signed replacement, and committed to by the coinbase transaction -(CbTx version 4, `merkleRootAssetUnlocks`). An expired instance is also -accepted into the mempool (from peers and when reloading `mempool.dat`) if its -signature was valid at a height within its window, so its spends propagate; it is -neither mined nor InstantSend-locked until Platform re-signs it. Relaying an -Asset Unlock outside the receiving node's height window or quorum range is no -longer penalized. - -Updated RPCs ------------- - -- `getmempoolinfo` reports `pendingassetunlocks`, the sum of the withdrawal - amounts of the Asset Unlock transactions in the mempool. -- `getassetunlockstatuses` reports `instantlock` for mempooled withdrawals. -- `getrawtransaction` and `decoderawtransaction` report `instanceHash` for - version 2 Asset Unlock transactions. diff --git a/doc/release-notes-7694.md b/doc/release-notes-7694.md deleted file mode 100644 index b520e1ae6cf2..000000000000 --- a/doc/release-notes-7694.md +++ /dev/null @@ -1,6 +0,0 @@ -GUI changes ------------ - -- The Governance tab now shows the wallet's current weighted proposal votes and - voting deadline estimate. The Votes dialog shows each eligible masternode's - current vote and allows voting with selected masternodes. (#7694) diff --git a/doc/release-notes-7712.md b/doc/release-notes-7712.md deleted file mode 100644 index c56243a56ab3..000000000000 --- a/doc/release-notes-7712.md +++ /dev/null @@ -1,21 +0,0 @@ -Consensus (v24, not yet activated on mainnet or testnet) ---------------------------------------------------------- - -- The asset unlock limit that applies once the `v24` hard fork activates is now a relative net - rule on the credit pool balance instead of a flat 4000 DASH cap on gross unlocks per window - (576 blocks on mainnet and testnet). Asset unlocks may not leave the credit pool below its - balance one window earlier minus an allowed drop of 20% of that balance, never less than 2000 - DASH and with no upper bound. - Deposits and the per-block Platform reward inside the window raise the balance and are - withdrawable again, so a deposit followed by its withdrawal does not consume the allowance of - other users. -- Devnets that have had `v24` active must be reset with fresh datadirs: the credit pool limit - is part of the EvoDB credit pool snapshot, and a datadir written by an earlier version would - keep serving the old value at snapshot heights. - -New RPCs --------- - -- `getcreditpoolinfo [height]` reports the credit pool balance after a block, the balance one - window earlier, the window length, the amount unlocked inside the window and the asset unlock - limit that applies to the next block. diff --git a/doc/release-notes-7754.md b/doc/release-notes-7754.md deleted file mode 100644 index 1d4b4b496da3..000000000000 --- a/doc/release-notes-7754.md +++ /dev/null @@ -1,15 +0,0 @@ -Masternode configuration ------------------------- - -A masternode (`-masternodeblsprivkey`) now refuses to start unless: - -* `-blocksonly=0` -* `-peerblockfilters=1` -* `-maxuploadtarget=0` -* `-minrelaytxfee`, `-incrementalrelayfee`, `-dustrelayfee` and `-bytespersigop` are not above - their defaults -* `-datacarrier=1`, `-datacarriersize` is not below its default and `-permitbaremultisig=1` -* `-limitancestorcount`, `-limitancestorsize`, `-limitdescendantcount`, `-limitdescendantsize`, - `-maxmempool` and `-mempoolexpiry` are not below their defaults - -The relay policy checks do not apply on regtest. diff --git a/doc/release-notes-7755.md b/doc/release-notes-7755.md deleted file mode 100644 index 006d1ca899ca..000000000000 --- a/doc/release-notes-7755.md +++ /dev/null @@ -1,7 +0,0 @@ -Proof of Service ----------------- - -DKG members now also vote a member bad if none of their masternode connections to it advertise: - -* transaction relay (`relay=1` in the `version` message); -* compact block filters (`NODE_COMPACT_FILTERS`). diff --git a/doc/release-notes-7779.md b/doc/release-notes-7779.md deleted file mode 100644 index 6358edcfd0d5..000000000000 --- a/doc/release-notes-7779.md +++ /dev/null @@ -1,6 +0,0 @@ -Updated RPCs ------------- - -- `protx listdiff` reports the complete `addresses` object, `platform_p2p` and `platform_https` included, - when the core P2P address of an EvoNode on legacy (pre-extended) addresses changes, so its Platform - ports can be followed without `-deprecatedrpc=service`. (#7779) diff --git a/doc/release-notes-7807.md b/doc/release-notes-7807.md deleted file mode 100644 index ce06a893ef4b..000000000000 --- a/doc/release-notes-7807.md +++ /dev/null @@ -1,20 +0,0 @@ -Consensus (v24, not yet activated on mainnet or testnet) ---------------------------------------------------------- - -- EvoNodes cannot register with shared collateral or have more than one owner payout until - the new `evo_shares` deployment activates. An EvoNode ProRegTx with a share table is - rejected with `bad-protx-shares-evo`, and an EvoNode ProRegTx or ProUpRegTx with more than - one owner payout is rejected with `bad-protx-payouts-evo`. Regular masternodes are not - affected. -- `evo_shares` (version bit 14) is a masternode-activated deployment with the same parameters - as `v24`. This release follows it but its masternodes do not sign it, so it stays inactive - until a later release signs it once Platform supports EvoNode shares and payouts. -- The consent digest that share owners sign for a shared EvoNode registration also covers the - EvoNode's `platformNodeID`. The digest of a regular shared registration is unchanged. - -New RPCs --------- - -- `protx shared_register_prepare_evo` creates an unsigned shared EvoNode registration. It - takes the arguments of `protx shared_register_prepare` followed by `platformNodeID`, - `platformP2PAddrs` and `platformHTTPSAddrs`, and fails until `evo_shares` is active. diff --git a/doc/release-notes-7831.md b/doc/release-notes-7831.md deleted file mode 100644 index 3544e0b87877..000000000000 --- a/doc/release-notes-7831.md +++ /dev/null @@ -1,8 +0,0 @@ -P2P and network changes ------------------------ - -- Governance object signatures larger than 96 bytes are now rejected, both from - the network and from the on-disk governance cache (`governance.dat`). The - cache format version was bumped for this: on the first start after - upgrading, the existing cache is discarded and governance objects and votes - are synced again from the network. (#7831) diff --git a/doc/release-notes-7842.md b/doc/release-notes-7842.md deleted file mode 100644 index 9ce37eff3d8e..000000000000 --- a/doc/release-notes-7842.md +++ /dev/null @@ -1,21 +0,0 @@ -Wallet ------- - -- Creating an HD wallet with a mnemonic passphrase longer than 248 bytes (not characters) through `upgradetohd`, - `createwallet` or `-mnemonicpassphrase` is now rejected, and one longer than 256 bytes is always rejected. - Existing wallets are not affected. (#7842) - - Seed derivation uses the BIP39 salt `"mnemonic"` followed by the passphrase. Dash Core 19.2.0 started cutting that - salt at 256 bytes to stop a crash, so every passphrase byte after the 248th has been ignored since then. Two - passphrases that differ only after that point derive the same seed. Before 23.0.0 the salt was also cut at the - first NUL byte. - - The derivation is left as it is. Using the full passphrase would bring back the pre-19.2.0 derivation, and a wallet - created with a long passphrase on 19.2.0 or later could then no longer be recovered from its mnemonic. Instead, new - wallets can't be given a passphrase that the derivation would truncate. - - To recover a wallet that was created on 19.2.0 or later with a passphrase of 249 to 256 bytes, start the node with - the new `-allow-deprecated-long-mnemonics` option, which accepts passphrases of up to 256 bytes and derives the same - (truncated) seed as before. A wallet created before 19.2.0 with a passphrase longer than 248 bytes can't be - recovered from its mnemonic on current versions, with or without the option. Restore it from a wallet backup - instead. diff --git a/doc/release-notes-7857.md b/doc/release-notes-7857.md deleted file mode 100644 index d6781a125242..000000000000 --- a/doc/release-notes-7857.md +++ /dev/null @@ -1,13 +0,0 @@ -Mining and mempool policy -------------------------- - -- When a block template includes an operator key change or revocation for a masternode, it now - places the masternode's pending `ProUpServTx` signed with the key being replaced before it. Such - a service update could otherwise confirm after the change in the same block and restore the - previous operator's service and payout details. A service update that cannot be placed before - the change, or that does not fit in the block with it, is left out of that block. (#7857) -- The mempool now rejects with `protx-dup` a `ProUpServTx` that spends, directly or through other - pending transactions, an output of a pending operator key change or revocation, which it can only - confirm after, or of a pending asset lock, asset unlock or MNHF signal, which could keep it out of - a block. A service update funded from such outputs can be sent once they confirm, signed with the - operator key that is current then. (#7857) diff --git a/doc/release-notes-7858.md b/doc/release-notes-7858.md deleted file mode 100644 index fd931fc8fea8..000000000000 --- a/doc/release-notes-7858.md +++ /dev/null @@ -1,8 +0,0 @@ -InstantSend changes -------------------- - -- Masternodes no longer InstantSend-lock provider transactions (ProRegTx, ProUpServTx, ProUpRegTx, ProUpRevTx and the - other provider special transactions). They are mined once they have been in the mempool for 10 minutes, and - transactions that spend their outputs can be locked once the block that includes the provider transaction is - ChainLocked. Software that waits for an islock on a provider transaction should wait for a ChainLock or confirmations - instead. (#7858) diff --git a/doc/release-notes-7861.md b/doc/release-notes-7861.md deleted file mode 100644 index cfa126788d91..000000000000 --- a/doc/release-notes-7861.md +++ /dev/null @@ -1,12 +0,0 @@ -Pruning -------- - -- Pruned nodes on mainnet, testnet and devnets now keep at least four days of - blocks (2304) below the tip instead of 288. Validation reads older blocks - from disk: the credit pool is rebuilt from its newest daily snapshot after a - restart, and rotated quorum membership reads the work blocks of earlier DKG - cycles. `pruneblockchain` clamps its height accordingly, and on testnet and - devnets pruning starts once the chain is longer than 3000 blocks - (previously 1000). Blocks that an earlier version already pruned are not - recovered; a node that fails to validate a block after upgrading needs - `-reindex`. diff --git a/doc/release-notes-8018.md b/doc/release-notes-8018.md deleted file mode 100644 index ba245ac17045..000000000000 --- a/doc/release-notes-8018.md +++ /dev/null @@ -1,14 +0,0 @@ -Consensus changes ------------------ - -- A version 3 (extended addresses) ProRegTx or ProUpServTx must list an IPv4 address as its first - `coreP2PAddrs` entry, and an EvoNode's first `platformP2PAddrs` and `platformHTTPSAddrs` entries must use - that same IPv4 address. Further entries may use other addresses and network types (IPv6, Tor, I2P, CJDNS, - and domains for Platform HTTPS). Violations are rejected with `bad-protx-netinfo-addr-type` or - `bad-protx-netinfo-addr`. This applies until masternodes are allowed to operate without IPv4, which is - not scheduled on mainnet. Testnet and devnets already allow it, so they are unaffected. Regtest follows - mainnet unless `-testactivationheight=ipv4_optional@` is set. -- On mainnet, the first entry of each address list must also use that list's standard port: 9999 for - `coreP2PAddrs`, 26656 for `platformP2PAddrs` and 443 for `platformHTTPSAddrs`, as legacy ProTx versions - already require there. Additional entries may use any otherwise valid port. Violations are rejected - with `bad-protx-netinfo-port`. diff --git a/doc/release-notes-8029.md b/doc/release-notes-8029.md deleted file mode 100644 index 7a617b8d9a91..000000000000 --- a/doc/release-notes-8029.md +++ /dev/null @@ -1,4 +0,0 @@ -Configuration -------------- - -- `dashd` no longer creates an empty `dash.conf` when none exists, matching Bitcoin Core. `dash-qt`'s "Open Configuration File" still creates it on demand. (#8029) diff --git a/doc/release-notes-remove-rescan.md b/doc/release-notes-remove-rescan.md deleted file mode 100644 index 4122c1a1b5d9..000000000000 --- a/doc/release-notes-remove-rescan.md +++ /dev/null @@ -1,9 +0,0 @@ -Notable changes -=============== - -Rescan startup parameter removed --------------------------------- - -The `-rescan` startup parameter has been removed. Wallets which require -rescanning due to corruption will still be rescanned on startup. -Otherwise, please use the `rescanblockchain` RPC to trigger a rescan. diff --git a/doc/release-notes.md b/doc/release-notes.md index 4b89c8da4d63..a068e9580a50 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -1,11 +1,10 @@ -# Dash Core version v23.1.10 +# Dash Core version v24.0.0 -This is a new patch version release. It fixes a governance issue that could -stop a superblock from paying any proposals, and hardens DKG and BLS signature -verification against misbehaving quorum members and peers. +This is a new major version release, bringing new features, various bugfixes and other improvements. -Upgrading is **strongly recommended** for all nodes, and required for -masternodes. +This release introduces the `v24` network upgrade (hard fork) and is **mandatory** for all nodes. +Masternodes must upgrade before the hard fork start date; all other nodes must upgrade before the +hard fork activates. See [Network upgrade](#network-upgrade) below. Please report bugs using the issue tracker at GitHub: @@ -20,63 +19,1274 @@ 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). +On the first start after upgrading, a node that has `-addressindex`, +`-spentindex` or `-timestampindex` enabled migrates that index to its own +database (see [Asynchronous address, spent and timestamp indexes](#asynchronous-address-spent-and-timestamp-indexes)). +This can take 20-40 minutes or longer depending on hardware and index size. +Start v24.0.0 for the first time with the same `-addressindex`, `-spentindex` +and `-timestampindex` settings the node used before (pruned nodes: see +below): an index that is left +disabled on any start of v24.0.0 can no longer reuse its old data, and is +rebuilt from genesis when it is enabled again. The governance cache +(`governance.dat`) and the spork cache (`sporks.dat`) changed format and are +discarded and re-synced from the network on the first start. + +A node that runs with `-txindex=0` must now also set `-disablegovernance`; +otherwise it refuses to start (see [Updated settings](#updated-settings)). +Pruned nodes are not affected by this, since `-prune` disables governance +validation already. + +A pruned node (`-prune`) that also has `-addressindex` or `-spentindex` set +refuses to start with an error, because these indexes now need the undo data +that pruning deletes. v23 accepted that combination. Remove the index options +from such a node before upgrading. Keeping them means running the node +unpruned, which requires `-reindex` and downloading the whole chain again. +`-timestampindex` can no longer be enabled on a datadir that has already been +pruned (see +[Asynchronous address, spent and timestamp indexes](#asynchronous-address-spent-and-timestamp-indexes)). + +Masternodes refuse to start with some settings that v23 accepted, such as +`-blocksonly=1`, `-peerblockfilters=0` or a nonzero `-maxuploadtarget`. This +applies from the first start of v24.0.0, not from hard fork activation. Check +the masternode's configuration against +[Masternode configuration requirements](#masternode-configuration-requirements) +and remove such settings before upgrading. Masternodes must be upgraded and +running before the `v24` start date (November 9, 2026 on mainnet): the +activation signal needs 85% of the signing quorum's members to run v24, and a +masternode that refuses to start cannot contribute to it (see +[Network upgrade](#network-upgrade)). + +On mainnet, a masternode that moves to extended addresses must keep an IPv4 +address on the standard port as the first entry of each address list (see +[Extended addresses](#extended-addresses)). (#8018) + +A node that ran a v24.0.0 release candidate with `-addressindex`, +`-spentindex` or `-timestampindex` enabled should rebuild these indexes once +after upgrading (see +[Asynchronous address, spent and timestamp indexes](#asynchronous-address-spent-and-timestamp-indexes)), +in one of two ways: + +- restart once with `-reindex`; or +- start v24.0.0 once with `-addressindex=0 -spentindex=0 -timestampindex=0`, + stop it, delete the `indexes/addressindex`, `indexes/spentindex` and + `indexes/timestampindex` directories, then start it again with the indexes + enabled. They are rebuilt in the background. + +Do not only delete the index directories without the intermediate start: on a +datadir a release candidate has used, that can leave empty indexes that report +themselves as synced. + +Pruned nodes now keep at least 2304 blocks below the tip instead of 288 (see +[Pruning](#pruning)). Blocks that an earlier version already pruned are not +recovered; a node that fails to validate a block after upgrading needs +`-reindex`. + ## Downgrade warning +### Downgrade to a version < v24.0.0 + +There is no supported downgrade after `v24` activation: v23 and older cannot +follow the network once `v24` is active. They also cannot correctly read the +masternode list data that v24.0.0 stores after activation, so do not start an +older version on a datadir that v24.0.0 has used after activation. + +Before activation, downgrading to v23.1.x is possible with the following +caveats: + +- The address, spent and timestamp indexes are moved out of the block index + database into separate databases on the first start of v24.0.0. A node that + had any of these indexes enabled must be restarted with `-reindex` after + downgrading. Older versions enforce this: they refuse to start with an index + that v24.0.0 has migrated until `-reindex` is given. (#8031) +- The governance and spork caches written by v24.0.0 are not readable by older + versions; they are discarded and re-synced from the network. +- v24.0.0 does not upgrade the wallet file format. Wallet records added by + v24.0.0 that older versions do not know about (such as the new CoinJoin + pending-observation record) are ignored by them. +- Dash-Qt moves the dust attack protection setting into the settings it shares + with `dashd` (see `-dustprotectionthreshold` under + [New options](#new-options)). Older versions don't read it there, so after a + downgrade dust protection is disabled and has to be enabled again in the + options dialog. + ### Downgrade to a version < v23.0.0 Downgrading to a version older than v23.0.0 is not supported, and will require a reindex. -# Release Notes - -## Governance - -- Masternodes no longer vote NO-FUNDING on a superblock trigger before that - superblock's maturity window opens (about 3 days before the superblock on - mainnet), when they have no candidate of their own to compare it against. - These early votes could keep a trigger with the correct payments from - reaching the funding threshold, so the superblock paid no proposals. - Triggers that don't match a masternode's candidate still receive a NO vote - once the window opens. -- Masternodes no longer vote on triggers until they are fully synced. A - masternode restarting inside the maturity window could otherwise vote NO on - the correct trigger before it was able to build its own candidate. - -Masternodes running older versions still cast the early NO votes, so this -protection becomes effective as masternodes upgrade. Masternode operators -should upgrade before the next superblock. - -## Security and denial-of-service hardening - -These issues do not affect consensus and do not put funds at risk. - -- BLS batch verification (signature shares, recovered signatures, InstantSend - locks and DKG messages) now weights each signature with a secret random - factor before aggregating. Previously two invalid signatures whose errors - cancelled out could pass as a valid batch. A peer could use this to disrupt - InstantSend or ChainLock signing, get honest peers penalised, or get honest - DKG members marked bad. -- Batched verification of DKG contributions is weighted the same way, so - colluding members can no longer give another member invalid secret-key - shares that pass verification, which could leave that member unable to sign - for the quorum. This did not expose the quorum key. -- A DKG member copying another member's entire contribution could prevent the - whole quorum from forming. Members whose verification vectors share a - coefficient are now excluded from the commitment instead of the round - failing. This excludes both the copying member and the member it copied, - and both receive the usual PoSe penalty for failed DKG participation. -- Colluding DKG members could stop chosen honest members from building their - secret-key share, which could prevent a quorum from forming without any - member being blamed. The same condition made a node penalise an honest peer - serving quorum data during share recovery. Equal secret-key shares from - different members are now accepted; the resulting key share is still - verified against the quorum's verification vector. - -Like the governance fix, the DKG fixes protect a quorum once enough of its -members run this version. Weighted batch verification does more work per -message, so masternodes may see higher CPU use during DKG and signing. - -# v23.1.10 Change log +## Compatibility + +- Dash Core binaries now require macOS 14 (Sonoma) or later. Dash Core v23.1.x + binaries supported macOS 11 (Big Sur) or later. Because v24.0.0 is mandatory, + users on macOS 13 or older must upgrade macOS, or move their node or wallet + to a supported system, before the `v24` hard fork activates. Windows 10 or + later continues to be required on Windows. +- On Linux, kernel 3.17 or later is now required. The minimum glibc version + (2.31) is unchanged. +- `PROTOCOL_VERSION` has been bumped from `70240` to `70242` (see + [P2P and network changes](#p2p-and-network-changes)). + `MIN_PEER_PROTO_VERSION` is unchanged at `70221`. +- `MIN_MASTERNODE_PROTO_VERSION` has been bumped from `70240` to `70242`. During + DKG, quorum members connected over an older protocol version are considered + to have a bad connection and are voted bad, which leads to PoSe penalties. + All masternodes must therefore upgrade to v24.0.0. + +# Network upgrade + +This release introduces two new deployments that use the masternode-activated +[Enhanced Hard Fork](https://github.com/dashpay/dips/blob/master/dip-0023.md) +(EHF, DIP-0023) mechanism: + +| Deployment | Name | Version bit | +| --- | --- | --- | +| V24 | `v24` | 13 | +| EvoNode shares | `evo_shares` | 14 | + +On mainnet both deployments use identical parameters: + +- start time: `1794182400` (Monday, November 9, 2026 00:00:00 UTC); +- timeout: `1857340800` (Thursday, November 9, 2028 00:00:00 UTC); +- signaling window: 4032 blocks (about 7 days); +- threshold: 80% (3226 of 4032 blocks) in the first signaling window, decreasing + with each window to a floor of 60% (2420 of 4032 blocks) after 10 windows. + +Activation proceeds as follows: + +1. Once the median time past passes the start time, masternodes running v24 + sign an EHF signal with the `LLMQ_400_85` quorum. This requires 85% of the + quorum's members to be running v24. +2. After the signal is mined, miner signaling starts at the next 4032-block + window boundary. +3. If the threshold is reached within a window, the hard fork locks in, and it + activates one window later. + +Mainnet is expected to be near block 2,569,500 on November 9, 2026, so the +first window boundary after the signal is block 2,572,416 (around November 14). +If that window reaches the threshold, `v24` locks in at block 2,576,448 and +activates at block 2,580,480, around November 28, 2026. That is the earliest +possible activation; every window that misses the threshold delays it by about +one week. The dates are estimates based on 2.5-minute blocks. + +All masternodes must upgrade before the start date. All other nodes must +upgrade before activation, or they will follow an invalid chain. + +v24.0.0 does **not** sign the `evo_shares` signal. Until `evo_shares` activates, +EvoNodes cannot use shared collateral or more than one owner payout (see +[EvoNode restrictions](#evonode-restrictions)). A later release (v24.1) is +expected to sign it once Dash Platform supports EvoNode shares and payouts. +Both deployments carry identical parameters so that the later release can +activate `evo_shares` without another mainnet parameter change. + +On testnet, both deployments start at `1790208000` (Thursday, September 24, 2026 +00:00:00 UTC). + +# Notable changes + +## Decentralized masternode shares and multi-party payouts + +This release implements the Decentralized Masternode Shares DIP, activating +together with DIP-0026 multi-party payouts as part of the `v24` hard fork. +For EvoNodes, shared collateral and more than one owner payout additionally +require the `evo_shares` deployment (see [EvoNode restrictions](#evonode-restrictions)). +Both features use version 3 provider transactions (see +[Provider transaction version 3 format](#provider-transaction-version-3-format)). +Before activation there is no behavior change. (#7437, #7340) + +### Multi-party payouts + +- The `payoutAddress` argument of `protx register`, `protx register_evo`, + `protx register_fund`, `protx register_fund_evo`, `protx register_prepare`, + `protx register_prepare_evo` and `protx update_registrar` accepts, in addition + to a single address, an array of `{"address": ..., "reward": ...}` objects + that splits the owner reward between several payees, with `reward` given in + basis points. Multi-party payouts are only valid once the `v24` hard fork + activates. The `..._legacy` variants build legacy-scheme transactions, which + cannot carry a payout list, and reject an array. For an EvoNode still on + version 2, `protx update_registrar` keeps version 2 and accepts only a single + payout address; upgrade the EvoNode with `protx update_service_evo` first (see + [Extended addresses](#extended-addresses)). +- For version 3 masternode states and ProTx payloads the payout list is + reported as a `payouts` array in place of the single `payoutAddress` field, + which earlier versions keep. Shared masternodes report `shares` + instead. The fields appear in `protx info`, `protx list detailed`, + `protx listdiff`, `masternode status` (`dmnState`) and in decoded + `ProRegTx`/`ProUpRegTx` payloads of the transaction-decoding RPCs; + `protx diff` includes them only with `extended=true`. (#7340) + +### Consensus changes (active with `v24`) + +- A version 3 ProRegTx (see + [Provider transaction version 3 format](#provider-transaction-version-3-format)) + may carry a collateral share table: + 2 to 8 participants fund the masternode collateral atomically in one + registration, each recording an immutable amount, refund script and share + owner key, plus an updatable reward script. Every share owner consents by + signing a digest that binds the exact funding inputs, all outputs, the share + table, the penalty terms and the registrar configuration. Consent is tied to + the shares in the table, not to the funding inputs: signing an input into a + registration neither requires nor creates a share for its owner. The + early-period penalty must be below the smallest share and must be zero when + no early period is configured. +- The shared collateral is paid to the 7-byte template script + `04445348437551` (`0x04 "DSHC" OP_DROP OP_TRUE`). From activation, an output + paying this exact script is valid only as the collateral of a valid shared + registration, and spending such an output is valid only via a ProDisTx. + Template outputs mined before activation become permanently unspendable. +- Three new special transaction types: + - **ProDisTx (type 10)** dissolves a shared masternode, refunding every + participant's principal to its immutable refund script. Exactly one + signature (unilateral, penalized during the configured early period) or one + per share (unanimous, penalty-free). Validity is monotone: a ProDisTx that + is valid at some height is valid at every later height, which makes offline + "standby dissolutions" safe. The transaction fee is capped at 1000000 duffs + and a unilateral dissolution may not pay bonuses beyond the configured + early penalty, bounding what a stolen share owner key can drain from its + own share. + - **ProUpShareTx (type 11)** lets one share owner update their reward script. + - **ProUpSharedRegTx (type 12)** updates the operator key and/or voting key + with a signature from every share owner. A plain ProUpRegTx is invalid for + shared masternodes. +- The owner reward of a shared masternode is split across the share table + proportionally to the recorded contributions (sequential floor, remainder to + the last entry), paying each share's reward script (or its refund script when + none is set). Operator rewards are unchanged. +- Withdrawal (asset unlock) transactions may not pay the template script. +- Coinbase payments are matched by multiplicity: every expected masternode + payment and every superblock payment must be paid by its own coinbase output, + so two identical expected payments (same script and amount) require two + outputs. Before activation one output could satisfy both. (#7362, #7377) + Mining pools should build exactly one coinbase output per `masternode[]` and + per `superblock[]` entry of `getblocktemplate`, in template order, even when + entries share a script or amount. After activation, a block that merges or + deduplicates them is invalid (`bad-cb-payee` / `bad-cb-amount`). + +### EvoNode restrictions + +- EvoNodes cannot register with shared collateral or have more than one owner + payout until the `evo_shares` deployment activates. An EvoNode ProRegTx with a + share table is rejected with `bad-protx-shares-evo`, and an EvoNode ProRegTx + or ProUpRegTx with more than one owner payout is rejected with + `bad-protx-payouts-evo`. Regular masternodes are not affected. +- The consent digest that share owners sign for a shared EvoNode registration + also covers the EvoNode's `platformNodeID`. The digest of a regular shared + registration is unchanged. (#7807) + +### Shared masternode relay policy + +- The template output relays only as the declared collateral output of a shared + registration, and a template prevout is accepted only inside a ProDisTx; both + remain nonstandard everywhere else. + +### Shared masternode RPCs + +- `protx shared_register_prepare` builds an unsigned shared registration from a + caller-supplied funding transaction. The result echoes the decoded terms and + carries a `warning` when `earlyPenalty` is zero, since any participant can + then force an early exit at no cost beyond the transaction fee. Before signing + its funding inputs with `signrawtransactionwithwallet`, each participant should + confirm that the share table (`proRegTx.shares` in `decoderawtransaction`) + holds its share with its own amount and addresses. +- `protx shared_register_prepare_evo` creates an unsigned shared EvoNode + registration. It takes the arguments of `protx shared_register_prepare` + followed by `platformNodeID`, `platformP2PAddrs` and `platformHTTPSAddrs`, and + fails until `evo_shares` is active. (#7807) +- `protx shared_sign` signs a shared registration, dissolution or shared + registrar update with every share owner key the wallet holds. It returns the + decoded terms being consented to (for a dissolution, including the outputs) + alongside the signatures, and repeats the zero-penalty warning for a + registration. It refuses a registration or dissolution carrying an + unsatisfied lock time or a relative input lock unless `allowTimeLocks` is + set. It signs a dissolution only when it returns every share's principal to + its refund address, less the fee from the actor's share, as + `protx shared_dissolve_prepare` builds it. +- `protx shared_combine` combines collected signatures and optionally submits. + A dissolution combined here requires a signature from every share; unilateral + dissolutions come fully signed from `protx shared_dissolve`. A + ProUpSharedRegTx must be combined in the wallet that ran + `protx shared_update_registrar_prepare`, because combining re-signs its fee + inputs. It is refused unless those inputs are unlocked coins of a single + address of this wallet, any change returns to that address, and the fee is + within `-maxtxfee`. (#7881) +- `protx shared_dissolve` creates, signs and submits a unilateral ProDisTx (or, + with `submit=false`, returns hex suitable for offline standby storage). +- `protx shared_dissolve_prepare` builds an unsigned unanimous ProDisTx. +- `protx shared_update_share` updates one share's reward address. To restore + rewards to the immutable refund address, pass that address explicitly; empty + reward scripts are not valid in update transactions. +- `protx shared_update_registrar_prepare` builds an unsigned ProUpSharedRegTx. + +### Updated masternode list RPCs + +- `masternodelist` and `masternode list` report comma-separated share owner + addresses in `owneraddress` for shared masternodes. The `json` and `recent` + modes can be filtered by any share owner address. Shared registrations and + masternode state omit the singular `ownerAddress` field in `protx` and decoded + transaction output; each participant's owner address is in `shares`. (#7437) + +### Shared masternode GUI + +- The Masternodes tab gains a "Shared Masternode…" wizard for registering a + masternode funded by several people. The coordinator enters the participants, + masternode settings and exit terms, reserves coins for their own share and + copies one invitation; every participant pastes it, reserves their coins and + copies back their details. Two more rounds complete the registration: locked + terms out and approvals back, then a signing request out and signed + contributions back. Any message can be pasted from the landing page, replies + are accepted in any order, and every message shows a short code so + participants can confirm they hold the same one. Sessions can be saved and + reopened by either role. Reserved coins are released after broadcast. (#7701) +- Shared masternodes appear in the list with the type "Shared (you hold k of + n)", a details view listing every share, and context-menu actions to change + the wallet's reward address, rotate the operator or voting key (with every + share owner's approval), dissolve now, dissolve together, or create a + standby dissolution file holding both the penalty-free and the immediate + variant. Pasting a maintenance request or a standby dissolution into the + list opens the matching dialog. (#7701) +- The owned-masternode filter includes shared masternodes when the wallet holds + a participant's refund destination, including when rewards go to a different + wallet. (#7437) + +## Provider transaction version 3 format + +Once the `v24` hard fork activates, ProRegTx, ProUpServTx, ProUpRegTx and +ProUpRevTx may use version 3. Version 3 carries both +[extended addresses](#extended-addresses) and +[multi-party payouts and shared masternodes](#decentralized-masternode-shares-and-multi-party-payouts). +(#7302) + +- Dash Core v23 defined version 3 for ProRegTx and ProUpServTx only, behind the + same `v24` deployment, and its wire format has changed since. In version 3 + ProRegTx and ProUpRegTx payloads, `scriptPayout` is replaced by a + length-prefixed payout list. A version 3 ProRegTx also carries a share table + with one join signature per share, and the early-exit terms + (`nEarlyPeriodBlocks`, `nEarlyPenalty`); these are empty or zero for an + ordinary registration. +- ProUpRegTx and ProUpRevTx may now use version 3 as well. +- Development builds briefly used a separate version 4 for multi-party payouts. + It has been folded into version 3, and no released version of Dash Core uses + version 4. +- Software that parses or builds provider transactions (explorers, SPV + libraries, external wallets) must be updated. + +## Extended addresses + +Dash Core v23 introduced extended masternode addresses (`netInfo`, which lists +the core P2P, Platform P2P and Platform HTTPS endpoints explicitly) behind the +`v24` deployment. They become usable once `v24` activates, for regular +masternodes and EvoNodes alike, and do not depend on `evo_shares`. A masternode +moves to extended addresses with a version 3 provider transaction (see +[Provider transaction version 3 format](#provider-transaction-version-3-format)). +(#7741, #7748, #7751) + +- After activation, an EvoNode service update (`ProUpServTx`) must be version 3 + and list its Platform P2P and HTTPS addresses explicitly; the separate + Platform port fields are not carried over. A version 2 EvoNode `ProUpServTx` + is rejected with `bad-protx-version-disallowed`, and raising an EvoNode with + addresses to version 3 by any other transaction is rejected with + `bad-protx-netinfo-version`. `protx update_service_evo` builds the right + transaction, but third-party tools that build version 2 EvoNode service + updates must be updated. +- Platform HTTPS entries on port 443 are accepted in extended addresses. +- A version 3 (extended addresses) ProRegTx or ProUpServTx must list an IPv4 + address as its first `coreP2PAddrs` entry, and an EvoNode's first + `platformP2PAddrs` and `platformHTTPSAddrs` entries must use that same IPv4 + address. Further entries may use other addresses and network types (IPv6, + Tor, I2P, CJDNS, and domains for Platform HTTPS). Violations are rejected + with `bad-protx-netinfo-addr-type` or `bad-protx-netinfo-addr`. This applies + until masternodes are allowed to operate without IPv4, which is not scheduled + on mainnet. Testnet and devnets already allow it, so they are unaffected. + Regtest follows mainnet unless `-testactivationheight=ipv4_optional@` + is set. (#8018) +- On mainnet, the first entry of each address list must also use that list's + standard port: 9999 for `coreP2PAddrs`, 26656 for `platformP2PAddrs` and 443 + for `platformHTTPSAddrs`, as legacy ProTx versions already require there. + Additional entries may use any otherwise valid port. Violations are rejected + with `bad-protx-netinfo-port`. (#8018) + +## Version 2 Asset Unlock transactions + +Once the `v24` hard fork activates, version 2 Asset Unlock transactions become +valid. Version 1 Asset Unlock transactions remain valid after activation, and +Platform withdrawals keep using version 1 until a future Dash Platform release +starts issuing version 2. Until then, the version 2 features described below +(the stable txid, InstantSend locking and relay by instance hash) do not apply +to Platform withdrawals. + +The transaction hash of a version 2 Asset Unlock is computed with the quorum +signing fields (`requestedHeight`, `quorumHash`, `quorumSig`) zeroed, so every +instance Platform re-signs after an expiry is the same transaction with one +stable txid. Spends of an unmined withdrawal's outputs therefore stay valid +across re-signs. (#7639) + +A version 2 Asset Unlock is InstantSend-locked as soon as it can be mined in +the next block: it carries a valid signature from a recent quorum, is inside +its height window, no other instance of its withdrawal index is in the +mempool, and the withdrawals pending in the mempool fit the credit pool's +current limit. The lock pins the withdrawal index (as the outpoint +`{DIP-27 request id, 0}`) to the txid. Spends of a locked withdrawal are +ordinary InstantSend transactions and the wallet treats the withdrawal's +outputs as trusted, so Platform-to-Core transfers become rapidly respendable. + +Version 2 unlocks are relayed by instance hash (new inventory type +`MSG_ASSET_UNLOCK`, protocol version 70242), kept in the mempool while expired +awaiting a re-signed replacement, and committed to by the coinbase transaction +(CbTx version 4, `merkleRootAssetUnlocks`). An expired instance is also +accepted into the mempool (from peers and when reloading `mempool.dat`) if its +signature was valid at a height within its window, so its spends propagate; it +is neither mined nor InstantSend-locked until Platform re-signs it. Relaying an +Asset Unlock outside the receiving node's height window or quorum range is no +longer penalized. (#7639, #7744) + +- `getmempoolinfo` reports `pendingassetunlocks`, the sum of the withdrawal + amounts of the Asset Unlock transactions in the mempool. +- `getassetunlockstatuses` reports `instantlock` for mempooled withdrawals. +- `getrawtransaction` and `decoderawtransaction` report `instanceHash` for + version 2 Asset Unlock transactions. +- For pools, explorers and indexers: the txid of a version 2 Asset Unlock is + the double SHA-256 of the transaction with `requestedHeight`, `quorumHash` + and `quorumSig` zeroed, not of its serialized bytes. The full-bytes hash is + `instanceHash`. Block merkle roots and `getblocktemplate` + `transactions[].hash` use the txid, so software that hashes raw transaction + bytes (`getblocktemplate` `data`, ZMQ `rawtx`/`rawblock`, P2P) must use the + `hash` field or apply the same zeroing. + +## Relative asset unlock limit + +- The asset unlock limit that applies once the `v24` hard fork activates is now + a relative net rule on the credit pool balance instead of a flat 4000 DASH cap + on gross unlocks per window (576 blocks on mainnet and testnet). Asset unlocks + may not leave the credit pool below its balance one window earlier minus an + allowed drop of 20% of that balance, never less than 2000 DASH and with no + upper bound. +- Deposits and the per-block Platform reward inside the window raise the + balance and are withdrawable again, so a deposit followed by its withdrawal + does not consume the allowance of other users. +- The new `getcreditpoolinfo [height]` RPC reports the credit pool balance after + a block, the balance one window earlier, the window length, the amount + unlocked inside the window and the asset unlock limit that applies to the + next block. (#7712) + +## Version 2 Asset Locks and Platform addresses + +- Asset Lock special transactions gain a payload version 2, enabled by the + `v24` hard fork. Before activation only version 1 is valid; after activation + both version 1 and version 2 are. A version 2 payload signals that Platform + assigns each credit output to the matching Identity automatically, and it + extends the allowed `creditOutputs[].scriptPubKey` forms from P2PKH only to + P2PKH and P2SH. All other Asset Lock rules are unchanged. See DIP-27. +- `validateaddress` and `getaddressinfo` now accept DIP-18 Dash Platform + addresses (`dash1k…`/`dash1s…` on mainnet, `tdash1k…`/`tdash1s…` on the test + chains) and report them with a new `isplatform` field. `getaddressinfo` + describes such an address against the credit output script an Asset Lock would + carry for it, so `ismine` and `solvable` answer whether this wallet holds the + key or script behind the address. +- `sendtoaddress` and `sendmany` accept Platform addresses as recipients. Doing + so turns the transaction into an Asset Lock with a version 2 payload whose + credit outputs are the Platform recipients, plus a single empty `OP_RETURN` + output carrying their total. `subtractfeefromamount` is not supported for + Platform recipients, because the locked amount has to match the `OP_RETURN` + value exactly. Paying a Platform address is refused before the `v24` hard + fork activates. +- `getrawtransaction`, `decoderawtransaction` and the other + transaction-decoding RPCs report `assetLockTx.creditOutputs[].address` for + version 2 payloads, the DIP-18 Platform address the credit output pays. + Version 1 payloads carry no such address and the field is omitted. + +This release carries the consensus side of version 2 Asset Locks: after the +`v24` hard fork they are valid in a block. They remain non-standard for now, so +under default policy they are not accepted into the mempool or relayed, and +sending to a Platform address fails with +`Transaction is non-standard (assetlocktx-version-2) …`. A future release will +make them standard once Dash Platform can process them; that is a policy change +only and needs no further consensus change. On testnet, devnets and regtest the +node can be started with `-acceptnonstdtxn=1` to relay them already; mainnet +does not accept that option. (#7294, #7285, #7577) + +## Masternode operator keys and BLS schemes + +- Dash Core will no longer permit the registration of new legacy BLS scheme + masternodes after the `v24` hard fork activates. Existing basic scheme + masternodes will also be prohibited from downgrading to the legacy scheme + after activation. (#6729) +- Masternode operator key uniqueness is now enforced per key rather than per + BLS encoding. After the `v24` hard fork activates, registering or updating to + an operator public key already used by another masternode is rejected + regardless of which BLS scheme (legacy or basic) either side is encoded under, + closing a gap where the same key could be claimed twice under different + encodings. +- After the `v24` hard fork activates, a legacy (LegacyBLS) masternode migrates + to the basic BLS scheme *in place* when its state version is raised, keeping + the same operator key: the stored operator public key is re-encoded from the + legacy to the basic scheme, with no key rotation required. `protx + update_service` and `protx update_registrar` build the corresponding + basic-scheme migration transaction for a legacy masternode, and the + masternode is no longer PoSe-banned by the change. The `..._legacy` RPC + variants keep the masternode on the legacy scheme. Previously a legacy + masternode could not move to the basic scheme without effectively rotating + its operator key, and `update_registrar` clamped the transaction version + silently. (#7473) + +## CoinJoin promotion and demotion + +- CoinJoin can now promote and demote between adjacent standard denominations + within a mixing session after the `v24` hard fork activates. Promotion + combines 10 inputs of one denomination into 1 output of the next larger + denomination, while demotion splits 1 input into 10 outputs of the next + smaller denomination. Pre-v24 behavior remains unchanged. +- Conversions only spend fully-mixed coins, and their outputs start mixing over + from zero rounds. The 10:1 shape of a conversion publicly clusters one + participant's coins even inside a mixing transaction, so a converted coin is + not treated as mixed: it re-enters mixing at its new denomination and + disperses normally, while the histories of the fully-mixed coins that fed the + conversion remain protected. +- A mixing session only completes once each side of its denomination is + occupied by nobody or by at least two participants, since coins are only + concealed by other coins of the same size on the same side. A session that + attracts a lone promotion or demotion participant and no counterpart + therefore waits, and expires in the queue stage without charging anyone's + collateral, rather than publishing a transaction that would identify that + participant's coins. Because admission relies on the declared directions, a + participant whose entry deviates from what it declared has its collateral + consumed. (#7052) +- A wallet that still has coins to mix keeps standard mixing. It joins + promotion and demotion queues that other wallets opened, but only opens its + own when it has no standard mixing session to join or start, so a conversion + waiting for a counterpart never holds up mixing. (#7995) +- A promotion prefers fully-mixed coins from different mixing transactions. If + there are not enough of those, it also spends coins that came out of the same + mixing transaction, which links them as one owner's coins, as an ordinary send + of the same coins would. (#7996) + +See [P2P and network changes](#p2p-and-network-changes) for the related +protocol changes. + +## Compact quorum proofs + +New RPCs `getquorumproofchain` and `verifyquorumproofchain` produce and verify +compact mining-transaction proofs from an independently trusted snapshot, and +`getchainlockbyheight` returns historical coinbase-carried ChainLock +certificates. The RPCs read required blocks on demand, without an additional +index or startup scan, and keep what they read in bounded in-memory caches of up +to about 50 MiB. Nodes must retain the required historical blocks to generate +proofs. (#7107, #7727) + +## Deprecated RPC fields now hidden by default + +- The deprecated keys `service`, `platformP2PPort` and `platformHTTPPort` now + require the runtime flag `-deprecatedrpc=service`. (#7181) + - The following RPCs are affected: `decoderawtransaction`, `decodepsbt`, + `getblock`, `getrawtransaction`, `gettransaction`, `masternode status` + (only the `dmnState` key), `protx diff`, `protx listdiff`. + - This runtime gate also extends to the functionally identical key, `address` + in `masternode list` (and its alias, `masternodelist`). + - The same gate applies to `getcoinjoininfo`, `protx info`, + `protx list detailed` and `quorum info`. + - `dash-tx -json` output omits these keys as well and offers no way to restore + them, since `dash-tx` does not accept `-deprecatedrpc`. +- Information on soft fork status has been moved from `getblockchaininfo` to the + new `getdeploymentinfo` RPC, which allows querying soft fork status at any + block, rather than just at the chain tip. Inclusion of soft fork status in + `getblockchaininfo` can currently be restored using the configuration + `-deprecatedrpc=softforks`, but this will be removed in a future release. Note + that in either case, the `status` field now reflects the status of the current + block rather than the next block. A new `/rest/deploymentinfo` REST endpoint + provides the same information. (#6888) + +### Note for masternode operators running Dash Platform + +Dash Platform reads the `service` field from Dash Core, and Platform versions +before v5.0.0 also read the `getblockchaininfo` `softforks` field. EvoNode +operators should upgrade Dash Platform to v5.0.0 or later together with Dash +Core: + +- dashmate v5.0.0 and later start Dash Core with `-deprecatedrpc=service`, and + Platform v5.0.0 and later read deployment status from `getdeploymentinfo`, so + no extra configuration is needed. +- Setups not managed by dashmate v5.0.0 or later must start Dash Core with + `-deprecatedrpc=service`, and Platform versions before v5.0.0 also need + `-deprecatedrpc=softforks`. Without these options Platform cannot operate + correctly. + +## Descriptor wallets by default + +Descriptor wallets are now the default wallet type. Newly created wallets will +use descriptors unless `descriptors=false` is set during `createwallet`, or the +`Descriptor wallet` checkbox is unchecked in the GUI. + +Note that wallet RPC commands like `importmulti` and `dumpprivkey` cannot be +used with descriptor wallets, so if your client code relies on these commands +without specifying `descriptors=false` during wallet creation, you will need to +update your code. (#7204) + +`createwallet` now also refuses `descriptors=false` without `load_on_startup`; +since v21 this applied only to `descriptors=true`. To create a legacy wallet, +pass both, for example: + +``` +dash-cli -named createwallet wallet_name=mywallet descriptors=false load_on_startup=true +``` + +`dash-wallet create` also creates a descriptor wallet by default. Pass the new +`-legacy` option to create a legacy wallet instead. (#7204) + +An experimental RPC `migratewallet` has been added to migrate legacy +(non-descriptor) wallets to descriptor wallets. More information about the +migration process is available in the +[documentation](https://github.com/dashpay/dash/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets). +(#7275) + +Failure handling in `migratewallet`, `restorewallet` and +`dash-wallet createfromdump` was fixed with backports from Bitcoin Core 28.x. A +failed migration restores the original wallet and leaves the rest of the +wallet directory as it was. After a migration, the migrated wallet and the +watch-only and solvables wallets it created are reloaded from disk, and if one +of them fails to load, the migration is rolled back. Migration backups are now +named `_