From e8cbfafebc43652b525c10fd70302b9308fd47c0 Mon Sep 17 00:00:00 2001 From: pasta Date: Thu, 29 Oct 2026 19:39:20 +0000 Subject: [PATCH 1/7] docs: archive v23.1.8 and v23.1.9 release notes Co-Authored-By: Claude Opus 5.5 --- .../dash/release-notes-23.1.8.md | 161 ++++++++++++++++++ .../dash/release-notes-23.1.9.md | 157 +++++++++++++++++ 2 files changed, 318 insertions(+) create mode 100644 doc/release-notes/dash/release-notes-23.1.8.md create mode 100644 doc/release-notes/dash/release-notes-23.1.9.md diff --git a/doc/release-notes/dash/release-notes-23.1.8.md b/doc/release-notes/dash/release-notes-23.1.8.md new file mode 100644 index 000000000000..2a8d804abe00 --- /dev/null +++ b/doc/release-notes/dash/release-notes-23.1.8.md @@ -0,0 +1,161 @@ +# Dash Core version v23.1.8 + +This is a new patch version release, fixing three remotely reachable crashes and +bringing further hardening of the peer-to-peer message handlers along with +networking, RPC and build fixes. +Upgrading is **strongly recommended** for all nodes, and required for +masternodes. + +Please report bugs using the issue tracker at GitHub: + + + +# Upgrading and downgrading + +## How to Upgrade + +If you are running an older version, shut it down. Wait until it has completely +shut down (which might take a few minutes for older versions), then run the +installer (on Windows) or just copy over /Applications/Dash-Qt (on Mac) or +dashd/dash-qt (on Linux). + +## Downgrade warning + +### Downgrade to a version < v23.0.0 + +Downgrading to a version older than v23.0.0 is not supported, and will +require a reindex. + +# Release Notes + +## Critical fixes + +This release fixes three crashes that a remote party could trigger. None of +them affect consensus rules or put funds at risk, but each one can take a node +offline, so all operators should upgrade promptly. + +- Fixed a crash while removing provider transactions that a masternode's + operator-key change invalidates. Those transactions are collected before any + of them are removed, so when one was an in-mempool descendant of another it + was already erased along with its ancestor, and the stale entry was then + dereferenced. Such entries are now skipped. This is reachable whenever a block + carries a provider registrar update or revocation for a masternode that has + chained service updates pending in the mempool. +- Fixed a crash caused by an unvalidated LLMQ type in a `qsigshare` message. A + masternode that received a signature share naming an LLMQ type its chain does + not register would index a per-type quorum cache that is only populated for + known types, aborting the process. Unregistered types are now rejected before + the lookup, and the affected cache lookups no longer create missing entries. +- Fixed a crash caused by a quorum commitment naming a block with no parent, + such as the genesis block. The parentless block index reached a non-null + precondition and terminated the process instead of failing validation, which + no exception handler could contain. Commitments with a parentless quorum base + block are now rejected, and the LLMQ activation check treats a null + predecessor as "not enabled" rather than a contract violation. + +## Security + +This release continues the hardening of peer-to-peer message handlers against +denial-of-service from remote peers. These issues do not affect consensus and do +not put funds at risk, but they could be used to crash or degrade nodes - +masternodes in particular - so upgrading is recommended. + +- LLMQ / signing: the queues of not-yet-verified recovered signatures and + signature shares are now bounded, and the vectors carried by the QSIGSHARE, + QSIGSESANN, QSIGSHARESINV, QGETSIGSHARES and QBSIGSHARES messages are bounded + before any allocation or decoding takes place. The number of signing share + sessions a single peer may announce is also capped, so a peer can no longer + grow that per-peer state without limit (dash#7351). +- LLMQ / DKG: the number of encrypted contribution blobs in a DKG contribution + is now checked against the quorum's lower bound as well as its upper bound. +- LLMQ / quorum data: the verification vector and encrypted contribution + vectors in QDATA responses are validated against their expected sizes before + any BLS decoding is performed. +- Transaction relay: an oversized `notfound` message is now penalised rather + than silently ignored (dash#7348). +- ChainLocks: the cache of seen ChainLock signatures is now bounded. +- Governance: per-object vote sync requests are now throttled per peer, and + governance object and vote responses are only accepted from a peer if that + peer announced them or they were requested from it, using the net-layer + per-peer request tracker. Governance vote signatures are bounded when read + from the network and must use one of the two legitimate encodings. +- CoinJoin: the vectors carried by CoinJoin mixing messages are bounded before + allocation, and a non-participant can no longer abort another session's + signing phase. An invalid `dstx` message now carries a misbehaviour score + instead of being dropped for free (dash#7347). +- Bloom filters: filterload and filteradd payloads are bounded before + allocation. +- Sporks: spork signatures are bounded during deserialization, and malformed + spork messages now attribute misbehaviour to the sending peer. +- Compact block relay: batched hardening backported from upstream Bitcoin Core + (dash#7398), including detection of mutated blocks as a defence-in-depth + measure. + +## RPC + +- `protx listdiff` no longer reports an always-zero `platformP2PPort` / + `platformHTTPPort` for masternodes registered with extended addresses; the + live Platform ports are reported instead. + +## GUI + +- The PoSe score column is no longer hidden together with banned masternodes in + the masternode list. +- Fixed an abort when scaling widgets whose font was set in pixels rather than + points (for example by a stylesheet's `font-size: Npx`); such fonts are now + converted to a point size instead of being assumed to have one (dash#7465). + +## Build and CI + +- Fixed a CMake compatibility error when building the freetype dependency with + newer CMake (dash#7372). +- Stabilized the `-par` / `-parbls` help text (and the generated man pages) so + they no longer embed the core count of the build machine. +- Updated GitHub Actions pins for the Node 24 runtime. +- Fixed the circular-dependencies lint script under Python 3.15. + +## Tests + +- Governance inventory cache coverage moved from a functional test to unit + tests, and governance vote test fixtures are now wire-valid. + +# v23.1.8 Change log + +See detailed [set of changes][set-of-changes]. + +# Credits + +Thanks to everyone who directly contributed to this release: + +- Konstantin Akimov +- PastaClaw +- PastaPastaPasta +- UdjinM6 + +As well as everyone that submitted issues, reviewed pull requests and helped +debug the release candidates. + +# Older releases + +These releases are considered obsolete. Old release notes can be found here: + +- [v23.1.7](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.7.md) released Jun/30/2026 +- [v23.1.5](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.5.md) released Jun/19/2026 +- [v23.1.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.4.md) released Jun/18/2026 +- [v23.1.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.3.md) released May/28/2026 +- [v23.1.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.2.md) released Mar/12/2026 +- [v23.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.0.md) released Feb/15/2026 +- [v23.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.0.2.md) released Dec/4/2025 +- [v23.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.0.0.md) released Nov/10/2025 +- [v22.1.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.1.3.md) released Jul/15/2025 +- [v22.1.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.1.2.md) released Apr/15/2025 +- [v22.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.1.1.md) released Feb/17/2025 +- [v22.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.1.0.md) released Feb/10/2025 +- [v22.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.0.0.md) released Dec/12/2024 +- [v21.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.1.1.md) released Oct/22/2024 +- [v21.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.1.0.md) released Aug/8/2024 +- [v21.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.0.2.md) released Aug/1/2024 +- [v21.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.0.0.md) released Jul/25/2024 +- [v20.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.1.1.md) released April/3/2024 + +[set-of-changes]: https://github.com/dashpay/dash/compare/v23.1.7...dashpay:v23.1.8 diff --git a/doc/release-notes/dash/release-notes-23.1.9.md b/doc/release-notes/dash/release-notes-23.1.9.md new file mode 100644 index 000000000000..2f1c11f9b3bf --- /dev/null +++ b/doc/release-notes/dash/release-notes-23.1.9.md @@ -0,0 +1,157 @@ +# Dash Core version v23.1.9 + +This is a new patch version release. It fixes a consensus-affecting +transaction-encoding bug, several remotely reachable crashes and +denial-of-service issues in the masternode, DKG, signing and governance paths, +and backports a number of hardening and robustness fixes from later releases. + +Upgrading is **strongly recommended** for all nodes, and required for +masternodes. + +Please report bugs using the issue tracker at GitHub: + + + +# Upgrading and downgrading + +## How to Upgrade + +If you are running an older version, shut it down. Wait until it has completely +shut down (which might take a few minutes for older versions), then run the +installer (on Windows) or just copy over /Applications/Dash-Qt (on Mac) or +dashd/dash-qt (on Linux). + +## Downgrade warning + +### Downgrade to a version < v23.0.0 + +Downgrading to a version older than v23.0.0 is not supported, and will +require a reindex. + +# Release Notes + +## Consensus + +- Transactions whose version field is negative are now rejected once DIP3 is + active. The version and type share one 32-bit field; a negative version was + sign-extended when a transaction was re-serialized, so a block containing such + a transaction could be accepted by a node that received the original bytes and + rejected by every node that received the re-serialized form, leading to a + persistent chain split. The new rule rejects these transactions uniformly. No + valid or historical transaction is affected and transaction ids are unchanged. + +## Crash fixes + +These issues do not affect consensus rules or put funds at risk, but each one +can take a node offline. + +- Fixed an abort during the DKG when a quorum member sent a contribution whose + decrypted secret-key share was invalid: the share reached an aggregation + assertion and terminated the process on every honest member of the quorum. + Invalid shares are now rejected before aggregation. +- Fixed block-template failures caused by provider transactions: a + `ProUpServTx` with an invalid type, a `ProRegTx` reusing collateral already + referenced by an in-mempool update, and a pending owner key colliding with a + Platform node id are now rejected at mempool acceptance. +- Bounded the masternode-list caches by size so a peer cannot drive unbounded + memory growth between blocks. +- Bounded `DomainPort` deserialization so a small provider transaction can no + longer make the node allocate and zero very large buffers while holding + `cs_main`. +- Decoding an unknown-version provider transaction through the verbose decode + RPCs no longer dereferences a missing network-info object. +- `masternode payments` no longer aborts at the genesis block, and the + masternode-list RPCs no longer cache a list for a block outside the active + chain. +- Evonodes no longer abort at credit-pool snapshot boundaries when the pool is + first constructed outside a block connection (for example by + `getassetunlockstatuses`). +- Flat-file (block and undo) positions are now stored and seeked as 64-bit + values. Block-undo data can be several times the size of its block, so a busy + chain could push a data file past the point a 32-bit offset can address; the + write and seek paths no longer narrow the position to 32 bits, which avoided a + silent wrap (and, on Windows, a failure past 2 GiB). + +## InstantSend + +- Provider (masternode) transactions are no longer given InstantSend locks. + Locking them served no purpose and interacted badly with lock eviction on + mempool removal. Software that waited for an InstantSend lock on a provider + transaction should wait for a ChainLock or for confirmations instead. + +## Security and denial-of-service hardening + +These issues do not affect consensus and do not put funds at risk. + +- DKG contribution verification: a single verification-vector coefficient + shared between two members no longer fails the whole verification batch. + Previously that marked unrelated honest members' contributions invalid and + caused them to be complained about; contributions are now verified + individually, so only the offending member is affected. +- Signature-share batch verification is now scoped per sender, so one peer can + no longer get an honest peer penalised or have a forged share stored in place + of an honest one. Malformed detached quorum share batches are rejected, and + signing intake is gated against the active-quorum set before any quorum is + retrieved. +- Governance: an orphan vote now requires a valid masternode signature before + it is cached, the number of orphan parent objects re-requested per tick is + bounded, governance vote signature checks are memoised to bound the cost of a + sync request, a vote is no longer recorded before it is validated, and a + failed BLS vote-signature check is logged under the governance category + instead of unconditionally, so a peer cannot fill `debug.log` with it. +- Socket exception monitoring is now consistent between the `poll()` and + `select()` backends, and a peer whose send buffer stalls is now subject to the + send timeout, so it can no longer hold a connection slot indefinitely. +- Verified inbound connections are bounded per operator identity; `CHECKDATASIG` + uses the signature cache; repeated authenticated Platform bans are skipped; + `DYNBITSET` allocation is bounded against the remaining stream size; a bogus + InstantSend lock no longer drops a batch of unrelated locks; and + `-allowprivatenet` no longer influences masternode address validation. + +## Wallet + +- Invalid-mnemonic errors no longer echo the recovery phrase, an encrypted + wallet is relocked if an HD upgrade fails after it was unlocked, and a wallet + unlock deadline can no longer be extended without re-authenticating. + +# v23.1.9 Change log + +See detailed [set of changes][set-of-changes]. + +# Credits + +Thanks to everyone who directly contributed to this release: + +- Konstantin Akimov +- PastaClaw +- PastaPastaPasta +- UdjinM6 + +As well as everyone that submitted issues, reviewed pull requests and helped +debug the release candidates. + +# Older releases + +These releases are considered obsolete. Old release notes can be found here: + +- [v23.1.8](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.8.md) released Jul/29/2026 +- [v23.1.7](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.7.md) released Jun/30/2026 +- [v23.1.5](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.5.md) released Jun/19/2026 +- [v23.1.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.4.md) released Jun/18/2026 +- [v23.1.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.3.md) released May/28/2026 +- [v23.1.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.2.md) released Mar/12/2026 +- [v23.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.0.md) released Feb/15/2026 +- [v23.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.0.2.md) released Dec/4/2025 +- [v23.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.0.0.md) released Nov/10/2025 +- [v22.1.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.1.3.md) released Jul/15/2025 +- [v22.1.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.1.2.md) released Apr/15/2025 +- [v22.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.1.1.md) released Feb/17/2025 +- [v22.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.1.0.md) released Feb/10/2025 +- [v22.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-22.0.0.md) released Dec/12/2024 +- [v21.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.1.1.md) released Oct/22/2024 +- [v21.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.1.0.md) released Aug/8/2024 +- [v21.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.0.2.md) released Aug/1/2024 +- [v21.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.0.0.md) released Jul/25/2024 +- [v20.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.1.1.md) released April/3/2024 + +[set-of-changes]: https://github.com/dashpay/dash/compare/v23.1.8...dashpay:v23.1.9 From 28c39fc4ad223ac7ee72e7c61f959d17db8ec0f0 Mon Sep 17 00:00:00 2001 From: pasta Date: Thu, 29 Oct 2026 19:57:08 +0000 Subject: [PATCH 2/7] docs: add v24.0.0 release notes and remove individual release notes files Fold every doc/release-notes-*.md fragment on v24.0.x into the v24.0.0 major-release notes, add the network upgrade, compatibility and downgrade sections, reference Bitcoin-numbered fragments by their Dash backport PR, and delete the fragments. Co-Authored-By: Claude Opus 5.5 --- doc/release-notes-16807.md | 10 - doc/release-notes-19602.md | 9 - doc/release-notes-24118.md | 10 - doc/release-notes-25122.md | 7 - doc/release-notes-25204.md | 9 - doc/release-notes-25375.md | 11 - doc/release-notes-25504.md | 6 - doc/release-notes-25574.md | 13 - doc/release-notes-25730.md | 6 - doc/release-notes-25934.md | 8 - doc/release-notes-25957.md | 9 - doc/release-notes-26076.md | 13 - doc/release-notes-26213.md | 8 - doc/release-notes-26265.md | 6 - doc/release-notes-26471.md | 13 - doc/release-notes-26646.md | 8 - doc/release-notes-27217.md | 6 - doc/release-notes-27279.md | 10 - doc/release-notes-27302.md | 4 - doc/release-notes-27632.md | 5 - doc/release-notes-28113.md | 7 - doc/release-notes-28354.md | 6 - doc/release-notes-28414.md | 5 - doc/release-notes-29189.md | 15 - doc/release-notes-6236.md | 6 - doc/release-notes-6888.md | 17 - doc/release-notes-7052.md | 45 -- doc/release-notes-7099.md | 25 - doc/release-notes-7101.md | 13 - doc/release-notes-7107.md | 9 - doc/release-notes-7181.md | 14 - doc/release-notes-7204.md | 21 - doc/release-notes-7261.md | 8 - doc/release-notes-7265.md | 11 - doc/release-notes-7278.md | 19 - doc/release-notes-7294.md | 44 -- doc/release-notes-7300.md | 16 - doc/release-notes-7335.md | 6 - doc/release-notes-7340.md | 17 - doc/release-notes-7428.md | 7 - doc/release-notes-7437.md | 105 --- doc/release-notes-7473.md | 25 - doc/release-notes-7480.md | 28 - doc/release-notes-7505.md | 20 - doc/release-notes-7570.md | 8 - doc/release-notes-7595.md | 9 - doc/release-notes-7600.md | 16 - doc/release-notes-7618.md | 9 - doc/release-notes-7629.md | 10 - doc/release-notes-7634.md | 10 - doc/release-notes-7639.md | 39 -- doc/release-notes-7694.md | 6 - doc/release-notes-7712.md | 21 - doc/release-notes-7754.md | 15 - doc/release-notes-7755.md | 7 - doc/release-notes-7779.md | 6 - doc/release-notes-7807.md | 20 - doc/release-notes-7831.md | 8 - doc/release-notes-7842.md | 21 - doc/release-notes-7857.md | 13 - doc/release-notes-7858.md | 8 - doc/release-notes-remove-rescan.md | 9 - doc/release-notes.md | 1039 +++++++++++++++++++++++++--- 63 files changed, 937 insertions(+), 997 deletions(-) delete mode 100644 doc/release-notes-16807.md delete mode 100644 doc/release-notes-19602.md delete mode 100644 doc/release-notes-24118.md delete mode 100644 doc/release-notes-25122.md delete mode 100644 doc/release-notes-25204.md delete mode 100644 doc/release-notes-25375.md delete mode 100644 doc/release-notes-25504.md delete mode 100644 doc/release-notes-25574.md delete mode 100644 doc/release-notes-25730.md delete mode 100644 doc/release-notes-25934.md delete mode 100644 doc/release-notes-25957.md delete mode 100644 doc/release-notes-26076.md delete mode 100644 doc/release-notes-26213.md delete mode 100644 doc/release-notes-26265.md delete mode 100644 doc/release-notes-26471.md delete mode 100644 doc/release-notes-26646.md delete mode 100644 doc/release-notes-27217.md delete mode 100644 doc/release-notes-27279.md delete mode 100644 doc/release-notes-27302.md delete mode 100644 doc/release-notes-27632.md delete mode 100644 doc/release-notes-28113.md delete mode 100644 doc/release-notes-28354.md delete mode 100644 doc/release-notes-28414.md delete mode 100644 doc/release-notes-29189.md delete mode 100644 doc/release-notes-6236.md delete mode 100644 doc/release-notes-6888.md delete mode 100644 doc/release-notes-7052.md delete mode 100644 doc/release-notes-7099.md delete mode 100644 doc/release-notes-7101.md delete mode 100644 doc/release-notes-7107.md delete mode 100644 doc/release-notes-7181.md delete mode 100644 doc/release-notes-7204.md delete mode 100644 doc/release-notes-7261.md delete mode 100644 doc/release-notes-7265.md delete mode 100644 doc/release-notes-7278.md delete mode 100644 doc/release-notes-7294.md delete mode 100644 doc/release-notes-7300.md delete mode 100644 doc/release-notes-7335.md delete mode 100644 doc/release-notes-7340.md delete mode 100644 doc/release-notes-7428.md delete mode 100644 doc/release-notes-7437.md delete mode 100644 doc/release-notes-7473.md delete mode 100644 doc/release-notes-7480.md delete mode 100644 doc/release-notes-7505.md delete mode 100644 doc/release-notes-7570.md delete mode 100644 doc/release-notes-7595.md delete mode 100644 doc/release-notes-7600.md delete mode 100644 doc/release-notes-7618.md delete mode 100644 doc/release-notes-7629.md delete mode 100644 doc/release-notes-7634.md delete mode 100644 doc/release-notes-7639.md delete mode 100644 doc/release-notes-7694.md delete mode 100644 doc/release-notes-7712.md delete mode 100644 doc/release-notes-7754.md delete mode 100644 doc/release-notes-7755.md delete mode 100644 doc/release-notes-7779.md delete mode 100644 doc/release-notes-7807.md delete mode 100644 doc/release-notes-7831.md delete mode 100644 doc/release-notes-7842.md delete mode 100644 doc/release-notes-7857.md delete mode 100644 doc/release-notes-7858.md delete mode 100644 doc/release-notes-remove-rescan.md 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-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 deleted file mode 100644 index 7ae5f6ce7776..000000000000 --- a/doc/release-notes-28113.md +++ /dev/null @@ -1,7 +0,0 @@ -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) 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 deleted file mode 100644 index 7fca11f8220b..000000000000 --- a/doc/release-notes-28414.md +++ /dev/null @@ -1,5 +0,0 @@ -RPC Wallet ----------- - -- RPC `walletprocesspsbt` return object now includes field `hex` (if the transaction -is complete) containing the serialized transaction suitable for RPC `sendrawtransaction`. (#28414) 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 bbae7e647268..000000000000 --- a/doc/release-notes-7300.md +++ /dev/null @@ -1,16 +0,0 @@ -P2P and network changes ------------------------ - -* Startup now fails if any configured `-bind`, `-whitebind` or the implicit Tor - onion-service bind (`127.0.0.1:9996` by default) cannot be set up. Dash Core - v23 and earlier started as long as at least one bind succeeded. - -* Nodes configured with `-bind` but no specific `-bind==onion` now - refuse to start when `-listenonion` is enabled. This includes nodes without - Tor configured, since `-listenonion` is enabled by default when listening. - Shared binds cannot distinguish Tor-forwarded connections from direct - connections, which can grant Tor peers unintended IP-based whitelist - permissions. Nodes without `-bind`, including those using only `-whitebind`, - continue to get the default onion target. Users should add a specific - `-bind==onion` to accept incoming Tor connections, or set - `-listenonion=0` to disable automatic onion service creation. 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 caea5381b477..000000000000 --- a/doc/release-notes-7437.md +++ /dev/null @@ -1,105 +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. -- `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-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 2a8d804abe00..69fd8aaa2c16 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -1,10 +1,10 @@ -# Dash Core version v23.1.8 +# Dash Core version v24.0.0 -This is a new patch version release, fixing three remotely reachable crashes and -bringing further hardening of the peer-to-peer message handlers along with -networking, RPC and build fixes. -Upgrading is **strongly recommended** for all nodes, and required for -masternodes. +This is a new major version release, bringing new features, various bugfixes and other improvements. + +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: @@ -19,107 +19,887 @@ 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. 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. + ## Downgrade warning +### Downgrade to a version < v24.0.0 + +Once the `v24` hard fork activates, versions older than v24.0.0 can no longer +follow the network and must not be used. + +Before activation, downgrading to v23.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. +- 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. + ### 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 - -## Critical fixes - -This release fixes three crashes that a remote party could trigger. None of -them affect consensus rules or put funds at risk, but each one can take a node -offline, so all operators should upgrade promptly. - -- Fixed a crash while removing provider transactions that a masternode's - operator-key change invalidates. Those transactions are collected before any - of them are removed, so when one was an in-mempool descendant of another it - was already erased along with its ancestor, and the stale entry was then - dereferenced. Such entries are now skipped. This is reachable whenever a block - carries a provider registrar update or revocation for a masternode that has - chained service updates pending in the mempool. -- Fixed a crash caused by an unvalidated LLMQ type in a `qsigshare` message. A - masternode that received a signature share naming an LLMQ type its chain does - not register would index a per-type quorum cache that is only populated for - known types, aborting the process. Unregistered types are now rejected before - the lookup, and the affected cache lookups no longer create missing entries. -- Fixed a crash caused by a quorum commitment naming a block with no parent, - such as the genesis block. The parentless block index reached a non-null - precondition and terminated the process instead of failing validation, which - no exception handler could contain. Commitments with a parentless quorum base - block are now rejected, and the LLMQ activation check treats a null - predecessor as "not enabled" rather than a contract violation. - -## Security - -This release continues the hardening of peer-to-peer message handlers against -denial-of-service from remote peers. These issues do not affect consensus and do -not put funds at risk, but they could be used to crash or degrade nodes - -masternodes in particular - so upgrading is recommended. - -- LLMQ / signing: the queues of not-yet-verified recovered signatures and - signature shares are now bounded, and the vectors carried by the QSIGSHARE, - QSIGSESANN, QSIGSHARESINV, QGETSIGSHARES and QBSIGSHARES messages are bounded - before any allocation or decoding takes place. The number of signing share - sessions a single peer may announce is also capped, so a peer can no longer - grow that per-peer state without limit (dash#7351). -- LLMQ / DKG: the number of encrypted contribution blobs in a DKG contribution - is now checked against the quorum's lower bound as well as its upper bound. -- LLMQ / quorum data: the verification vector and encrypted contribution - vectors in QDATA responses are validated against their expected sizes before - any BLS decoding is performed. -- Transaction relay: an oversized `notfound` message is now penalised rather - than silently ignored (dash#7348). -- ChainLocks: the cache of seen ChainLock signatures is now bounded. -- Governance: per-object vote sync requests are now throttled per peer, and - governance object and vote responses are only accepted from a peer if that - peer announced them or they were requested from it, using the net-layer - per-peer request tracker. Governance vote signatures are bounded when read - from the network and must use one of the two legitimate encodings. -- CoinJoin: the vectors carried by CoinJoin mixing messages are bounded before - allocation, and a non-participant can no longer abort another session's - signing phase. An invalid `dstx` message now carries a misbehaviour score - instead of being dropped for free (dash#7347). -- Bloom filters: filterload and filteradd payloads are bounded before - allocation. -- Sporks: spork signatures are bounded during deserialization, and malformed - spork messages now attribute misbehaviour to the sending peer. -- Compact block relay: batched hardening backported from upstream Bitcoin Core - (dash#7398), including detection of mutated blocks as a defence-in-depth - measure. - -## RPC - -- `protx listdiff` no longer reports an always-zero `platformP2PPort` / - `platformHTTPPort` for masternodes registered with extended addresses; the - live Platform ports are reported instead. - -## GUI - -- The PoSe score column is no longer hidden together with banned masternodes in - the masternode list. -- Fixed an abort when scaling widgets whose font was set in pixels rather than - points (for example by a stylesheet's `font-size: Npx`); such fonts are now - converted to a point size instead of being assumed to have one (dash#7465). - -## Build and CI - -- Fixed a CMake compatibility error when building the freetype dependency with - newer CMake (dash#7372). -- Stabilized the `-par` / `-parbls` help text (and the generated man pages) so - they no longer embed the core count of the build machine. -- Updated GitHub Actions pins for the Node 24 runtime. -- Fixed the circular-dependencies lint script under Python 3.15. - -## Tests - -- Governance inventory cache coverage moved from a functional test to unit - tests, and governance vote test fixtures are now wire-valid. - -# v23.1.8 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. 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. + +The earliest possible activation is therefore roughly two to three weeks after +November 9, 2026. + +Earliest possible activation: TBD-EARLIEST-DATE + +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. +Before activation there is no behavior change. (#7437, #7340) + +### Multi-party payouts + +- 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`. (#7340) + +### 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. + +### 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) + +### 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_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. +- `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 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) + +## Version 2 Asset Unlock transactions + +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. (#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. + +## 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. +- 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. (#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) + +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 + +Current versions of Dash Platform read the `service` field and the +`getblockchaininfo` `softforks` field from Dash Core. Operators running an +EvoNode with Dash Platform (including setups managed with dashmate) must start +Dash Core with both `-deprecatedrpc=service` and `-deprecatedrpc=softforks` +until the Platform version they run no longer requires these fields. Removing +either option before then can prevent Platform from operating 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) + +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) + +## Asynchronous address, spent and timestamp indexes + +`TimestampIndex`, `SpentIndex`, and `AddressIndex` have been migrated from +synchronous to asynchronous operation, following the same pattern as `TxIndex` +and other indexes using the `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. (#7101) + +## Masternode configuration requirements + +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. (#7754) + +In addition, 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`). (#7755) + +## InstantSend and provider transactions + +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) + +## Bitcoin Core backports + +This release includes a large number of backports from Bitcoin Core, covering +most of the changes from Bitcoin Core v25 and a substantial part of Bitcoin +Core v26, along with selected fixes from later releases. User-visible changes +from these backports are listed in the sections below. Notable additions +include the `sendall` RPC, the experimental `migratewallet` RPC, +`minconf`/`maxconf` options for funding RPCs, faster descriptor wallet rescans +using compact block filters, and stricter validation of configuration options +and RPC parameters. + +## Other notable changes + +- 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) +- `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. (#7278) +- Multi-key ("M-of-N") spork signing, which was never deployed on any network, + has been removed. The `sporks.dat` cache format changed; caches written by + previous versions are discarded on startup and sporks are re-synced from + peers. (#7505) +- 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) +- This release also contains many robustness and denial-of-service hardening + fixes in the P2P, LLMQ, governance and CoinJoin message handlers. + +## P2P and network changes + +- `PROTOCOL_VERSION` has been bumped to `70242`. Protocol version `70241` + introduces CoinJoin promotion/demotion signaling and protocol version `70242` + introduces relay of version 2 Asset Unlock transactions by instance hash. + (#7052, #7639) +- The `dsa` message gained a version-gated flags field (protocol version 70241) + 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) +- Version 2 Asset Unlock transactions are relayed by instance hash using the new + inventory type `MSG_ASSET_UNLOCK` (protocol version 70242). (#7639) +- Startup now fails if any configured `-bind`, `-whitebind` or the implicit Tor + onion-service bind (`127.0.0.1:9996` by default) cannot be set up. Dash Core + v23 and earlier started as long as at least one bind succeeded. +- Nodes configured with `-bind` but no specific `-bind==onion` now + refuse to start when `-listenonion` is enabled. This includes nodes without + Tor configured, since `-listenonion` is enabled by default when listening. + Shared binds cannot distinguish Tor-forwarded connections from direct + connections, which can grant Tor peers unintended IP-based whitelist + permissions. Nodes without `-bind`, including those using only `-whitebind`, + continue to get the default onion target. Users should add a specific + `-bind==onion` to accept incoming Tor connections, or set + `-listenonion=0` to disable automatic onion service creation. (#7300, #7786) +- `getqrinfo` requests now carry at most 4096 `baseBlockHashes`. A request with + more is rejected and the sending peer is penalized as misbehaving. No known + client sends more than a handful. The `quorum rotationinfo` RPC applies the + same limit and returns an error when it is exceeded. (#7629) + +## Mining and mempool policy + +- Transactions of size 65 bytes and above are now allowed by mempool and relay + policy (previously 83 bytes). This better reflects the actual afforded + protections against CVE-2017-12842 and opens up additional use-cases of + smaller transaction sizes. (#7666) +- 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) +- 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) +- `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. (#7278) + +## 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. + (#7099) +- 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. (#7099) +- Previously the `setban`, `addpeeraddress` and `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. Passing any value except `true`, `false`, or `null` now triggers a + JSON value is not of expected type error. (#7666) +- `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) +- 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. 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) +- `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. (#7428) +- `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. (#7480) +- `gettxoutsetinfo` no longer returns `block_info.unspendables.bip30`. Dash + never had transactions overridden by duplicates, so the value was always + zero. (#7335) +- 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. + (#7551) +- 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. (#7492) +- 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) +- 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. (#7710) +- 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. (#7237, #7338) + +## New RPCs + +- `getcreditpoolinfo` (see [Relative asset unlock limit](#relative-asset-unlock-limit)). (#7712) +- `getquorumproofchain`, `verifyquorumproofchain` and `getchainlockbyheight` + (see [Compact quorum proofs](#compact-quorum-proofs)). (#7107) +- `getdeploymentinfo` and the `/rest/deploymentinfo` REST endpoint (see + [Deprecated RPC fields now hidden by default](#deprecated-rpc-fields-now-hidden-by-default)). (#6888) +- `protx shared_*` (see [Decentralized masternode shares and multi-party payouts](#decentralized-masternode-shares-and-multi-party-payouts)). (#7437, #7807) +- `migratewallet` (see [Descriptor wallets by default](#descriptor-wallets-by-default)). (#7275) +- 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) + +## 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. (#7710) +- `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 (`-allowignoredconf`) to restore the previous behavior of using the + datadir while ignoring the dash.conf contained in it. (#7710) +- Passing an invalid `-debug`, `-debugexclude`, or `-loglevel` logging + configuration option now raises an error, rather than logging an easily missed + warning. (#7710) +- 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. (#7684) +- 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`. (#7710) + +## Command-line options + +### New options + +- 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. (#7265) +- `-allow-deprecated-long-mnemonics` (see [Wallet](#wallet)). (#7842) + +### Changed options + +- `-sporkaddr` now configures a single spork address. Previously it could be + specified multiple times to configure a set of valid spork signers. (#7505) + +### Removed 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. (#7505) +- 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. + +## 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. +- 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. (#7480) +- 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) +- Rescans for descriptor wallets are now significantly faster if compact block + filters (BIP158) are available. Since those are not constructed by default on + regular nodes, 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`. + (#7085) +- Address purpose 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. (#7871) + +## RPC 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. (#7261) +- 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` and + `sendall`. (#7709) +- 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. (#7550) +- RPC `listsinceblock` now accepts an optional `label` argument to fetch + incoming transactions having the specified label. (#7648) +- RPC `getreceivedbylabel` now returns an error, "Label not found in wallet" + (-4), if the label is not in the address book. (#7550) +- 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). (#7646) +- RPC `walletprocesspsbt` return object now includes field `hex` (if the + transaction is complete) containing the serialized transaction suitable for + RPC `sendrawtransaction`. (#7354) +- 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. (#7710) +- 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`. (#7711) + +## 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) +- Shared masternodes can be registered and maintained from the Masternodes tab + (see [Decentralized masternode shares and multi-party payouts](#decentralized-masternode-shares-and-multi-party-payouts)). (#7701) +- 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) +- 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) + +## Build system + +- macOS binaries now target macOS 14 (Sonoma) (see [Compatibility](#compatibility)). +- The `--enable-gprof` configure option has been removed. + +## Library + +- `libdashconsensus` is deprecated and will be removed in a future release. It + has existed for nearly 10 years with very little known uptake or impact, and + 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. (#7378) See detailed [set of changes][set-of-changes]. @@ -127,10 +907,16 @@ See detailed [set of changes][set-of-changes]. Thanks to everyone who directly contributed to this release: +- Antonio Moratti +- Kittywhiskers Van Gogh - Konstantin Akimov - PastaClaw - PastaPastaPasta +- takeshikurosawaa +- thephez - UdjinM6 +- Vijay +- zxccxccxz As well as everyone that submitted issues, reviewed pull requests and helped debug the release candidates. @@ -139,6 +925,8 @@ debug the release candidates. These releases are considered obsolete. Old release notes can be found here: +- [v23.1.9](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.9.md) released Oct/29/2026 +- [v23.1.8](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.8.md) released Jul/29/2026 - [v23.1.7](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.7.md) released Jun/30/2026 - [v23.1.5](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.5.md) released Jun/19/2026 - [v23.1.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-23.1.4.md) released Jun/18/2026 @@ -157,5 +945,52 @@ These releases are considered obsolete. Old release notes can be found here: - [v21.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.0.2.md) released Aug/1/2024 - [v21.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-21.0.0.md) released Jul/25/2024 - [v20.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.1.1.md) released April/3/2024 - -[set-of-changes]: https://github.com/dashpay/dash/compare/v23.1.7...dashpay:v23.1.8 +- [v20.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.1.0.md) released March/5/2024 +- [v20.0.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.4.md) released Jan/13/2024 +- [v20.0.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.3.md) released December/26/2023 +- [v20.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.2.md) released December/06/2023 +- [v20.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.1.md) released November/18/2023 +- [v20.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-20.0.0.md) released November/15/2023 +- [v19.3.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-19.3.0.md) released July/31/2023 +- [v19.2.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-19.2.0.md) released June/19/2023 +- [v19.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-19.1.0.md) released May/22/2023 +- [v19.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-19.0.0.md) released Apr/14/2023 +- [v18.2.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.2.2.md) released Mar/21/2023 +- [v18.2.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.2.1.md) released Jan/17/2023 +- [v18.2.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.2.0.md) released Jan/01/2023 +- [v18.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.1.1.md) released January/08/2023 +- [v18.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.1.0.md) released October/09/2022 +- [v18.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.0.2.md) released October/09/2022 +- [v18.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.0.1.md) released August/17/2022 +- [v0.17.0.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.17.0.3.md) released June/07/2021 +- [v0.17.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.17.0.2.md) released May/19/2021 +- [v0.16.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.1.1.md) released November/17/2020 +- [v0.16.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.1.0.md) released November/14/2020 +- [v0.16.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.0.1.md) released September/30/2020 +- [v0.15.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.15.0.0.md) released Febrary/18/2020 +- [v0.14.0.5](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.5.md) released December/08/2019 +- [v0.14.0.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.4.md) released November/22/2019 +- [v0.14.0.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.3.md) released August/15/2019 +- [v0.14.0.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.2.md) released July/4/2019 +- [v0.14.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.1.md) released May/31/2019 +- [v0.14.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.md) released May/22/2019 +- [v0.13.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.13.3.md) released Apr/04/2019 +- [v0.13.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.13.2.md) released Mar/15/2019 +- [v0.13.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.13.1.md) released Feb/9/2019 +- [v0.13.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.13.0.md) released Jan/14/2019 +- [v0.12.3.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.3.4.md) released Dec/14/2018 +- [v0.12.3.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.3.3.md) released Sep/19/2018 +- [v0.12.3.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.3.2.md) released Jul/09/2018 +- [v0.12.3.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.3.1.md) released Jul/03/2018 +- [v0.12.2.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.3.md) released Jan/12/2018 +- [v0.12.2.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.2.md) released Dec/17/2017 +- [v0.12.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.md) released Nov/08/2017 +- [v0.12.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.1.md) released Feb/06/2017 +- [v0.12.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.0.md) released Aug/15/2015 +- [v0.11.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.11.2.md) released Mar/04/2015 +- [v0.11.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.11.1.md) released Feb/10/2015 +- [v0.11.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.11.0.md) released Jan/15/2015 +- [v0.10.x](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.10.0.md) released Sep/25/2014 +- [v0.9.x](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.9.0.md) released Mar/13/2014 + +[set-of-changes]: https://github.com/dashpay/dash/compare/v23.1.9...dashpay:v24.0.0 From 3bbe3e23100e84152791785ef3b8fdc64c3fb712 Mon Sep 17 00:00:00 2001 From: pasta Date: Thu, 29 Oct 2026 20:04:10 +0000 Subject: [PATCH 3/7] docs: address review of v24.0.0 release notes Add missing PR references for the -rescan and --enable-gprof removals, restore the deprecation history of the top-level mempool fee fields, and give the shared-masternode subsections unique headings. Co-Authored-By: Claude Opus 5.5 --- doc/release-notes.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/release-notes.md b/doc/release-notes.md index 69fd8aaa2c16..a8d41f103320 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -184,13 +184,13 @@ Before activation there is no behavior change. (#7437, #7340) also covers the EvoNode's `platformNodeID`. The digest of a regular shared registration is unchanged. (#7807) -### Relay policy changes +### 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. -### New RPCs +### 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 @@ -221,7 +221,7 @@ Before activation there is no behavior change. (#7437, #7340) reward scripts are not valid in update transactions. - `protx shared_update_registrar_prepare` builds an unsigned ProUpSharedRegTx. -### Updated RPCs +### Updated masternode list RPCs - `masternodelist` and `masternode list` report comma-separated share owner addresses in `owneraddress` for shared masternodes. The `json` and `recent` @@ -229,7 +229,7 @@ Before activation there is no behavior change. (#7437, #7340) masternode state omit the singular `ownerAddress` field in `protx` and decoded transaction output; each participant's owner address is in `shares`. (#7437) -### GUI changes +### Shared masternode GUI - The Masternodes tab gains a "Shared Masternode…" wizard for registering a masternode funded by several people. The coordinator enters the participants, @@ -670,7 +670,7 @@ and RPC parameters. 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. - (#7551) + The top-level fee fields were previously deprecated in v22.1.0. (#7551) - 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 @@ -696,7 +696,7 @@ and RPC parameters. `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. + 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. (#7237, #7338) @@ -767,7 +767,7 @@ and RPC parameters. threshold of one — and the implementation has been removed. (#7505) - 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. + please use the `rescanblockchain` RPC to trigger a rescan. (#7037) ## Wallet @@ -890,7 +890,7 @@ and RPC parameters. ## Build system - macOS binaries now target macOS 14 (Sonoma) (see [Compatibility](#compatibility)). -- The `--enable-gprof` configure option has been removed. +- The `--enable-gprof` configure option has been removed. (#7452) ## Library From fe78211f52fd7ef9bca6ba9eff153d449d3629fc Mon Sep 17 00:00:00 2001 From: pasta Date: Thu, 29 Oct 2026 20:04:53 +0000 Subject: [PATCH 4/7] docs: state the earliest v24 activation height and the v23.1.9 fixes Co-Authored-By: Claude Opus 5.5 --- doc/release-notes.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/doc/release-notes.md b/doc/release-notes.md index a8d41f103320..d76a1dba096b 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -94,10 +94,12 @@ Activation proceeds as follows: 3. If the threshold is reached within a window, the hard fork locks in, and it activates one window later. -The earliest possible activation is therefore roughly two to three weeks after -November 9, 2026. - -Earliest possible activation: TBD-EARLIEST-DATE +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. @@ -540,6 +542,9 @@ and RPC parameters. 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) +- This release includes the fixes shipped in Dash Core v23.1.9, including the + consensus rule that rejects transactions with a negative `nVersion` once DIP3 + is active. - This release also contains many robustness and denial-of-service hardening fixes in the P2P, LLMQ, governance and CoinJoin message handlers. From 8660e54ba282ceae83cc44463676c5ce1c30e403 Mon Sep 17 00:00:00 2001 From: pasta Date: Fri, 30 Oct 2026 00:51:14 +0000 Subject: [PATCH 5/7] docs: complete the v24.0.0 release notes against the full v24 changeset Fold in doc/release-notes-7861.md (pruning keeps 2304 blocks), which landed on v24.0.x after these notes were drafted, and document changes from the v23.1.9..v24.0.x range that the notes missed: - breaking: -txindex=0 now requires -disablegovernance (#7785), -deprecatedrpc=exclude_coinbase removed (#7492), rescanblockchain needs an unlocked wallet (#7711), per-element -rpcwhitelist batch checks (#7722), ProTx version 3 wire format and EvoNode ExtAddr rules (#7302, #7741, #7748, #7751), multiplicity-correct coinbase payment matching (#7362, #7377), mandatory script flag reject reason (#7710), system time for block validation (#7430) - How to Upgrade: index-flag continuity (#7745), -txindex/governance, pruning depth - RPC/REST/wallet/GUI items: scanblocks, getrawtransaction verbosity, generateblock submit, masternode status quorumParticipation, quorum dkgstatus semantics, index-syncing errors, REST mempool parameters, dash-wallet -legacy, stale fee estimates, importwallet on pruned nodes, hybrid keys, mixing-only unlock no longer signs PSBTs, shared_combine registrar checks, P2P penalties and spork announcements, SHA-256 acceleration, Asset Lock history rows, Migrate Wallet menu, splash screen, coin control and options moves Fix inaccuracies: _legacy RPCs never accept a payouts array while register_prepare(_evo) do, descriptorprocesspsbt does not exist in Dash, #7858 already shipped in v23.1.9, the Bitcoin Core coverage claim, and the stale devnet-reset note. Credit only people who contributed to Dash Core directly, and fix the dead v0.15.0.0 and v0.12.1 archive links. Co-Authored-By: Claude Opus 5.5 --- doc/release-notes-7861.md | 12 --- doc/release-notes.md | 220 +++++++++++++++++++++++++++++++------- 2 files changed, 182 insertions(+), 50 deletions(-) delete mode 100644 doc/release-notes-7861.md 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.md b/doc/release-notes.md index d76a1dba096b..758391b4a5a5 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -22,9 +22,23 @@ 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. 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. +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: 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, since `-prune` disables governance validation +already. + +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 @@ -124,12 +138,17 @@ Before activation there is no behavior change. (#7437, #7340) ### Multi-party payouts -- 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. +- 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-protx-version-3)). - 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` @@ -174,6 +193,10 @@ Before activation there is no behavior change. (#7437, #7340) 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) ### EvoNode restrictions @@ -214,7 +237,12 @@ Before activation there is no behavior change. (#7437, #7340) set. - `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`. + 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. @@ -302,11 +330,7 @@ longer penalized. (#7639, #7744) - 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. -- 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. (#7712) + next block. (#7712) ## Version 2 Asset Locks and Platform addresses @@ -368,6 +392,27 @@ does not accept that option. (#7294, #7285, #7577) its operator key, and `update_registrar` clamped the transaction version silently. (#7473) +## Extended addresses (ProTx version 3) + +- Once the `v24` hard fork activates, provider transactions and masternode + states may use version 3 (extended addresses, `ExtAddr`), which Dash Core + v23 introduced but did not enable. Version 4 has been dropped, and its + contents were folded into version 3. (#7302, #7741, #7748, #7751) +- The version 3 wire format differs from the one v23 defined. In version 3 + ProRegTx and ProUpRegTx payloads, `scriptPayout` is replaced by a + length-prefixed payout list, and a version 3 ProRegTx also carries the share + table, the join signatures and the early-exit terms. ProUpRegTx and ProUpRevTx + may now use version 3 as well. Software that parses or builds provider + transactions (explorers, SPV libraries, external wallets) must be updated. +- After activation, an EvoNode service update (`ProUpServTx`) must be version 3 + and list its Platform P2P and HTTPS addresses explicitly. 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. + ## CoinJoin promotion and demotion - CoinJoin can now promote and demote between adjacent standard denominations @@ -446,6 +491,9 @@ 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) +`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 @@ -466,6 +514,11 @@ 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. +Only indexes that are enabled on that start are migrated. If v24.0.0 is ever +started with one of these indexes disabled, its old data is marked stale, and +enabling the index later discards that data and rebuilds the index from +genesis. To keep existing index data, start v24.0.0 with the same index +settings as before. (#7745) Breaking changes: @@ -477,6 +530,10 @@ Breaking changes: 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. (#7101) +- While an index is still being built or catching up, the RPCs that read it + (`getaddressbalance`, `getaddressdeltas`, `getaddresstxids`, + `getaddressutxos`, `getspentinfo` and `getblockhashes`) return an + "… index is syncing" error instead of results. (#7101) ## Masternode configuration requirements @@ -501,21 +558,12 @@ connections to it advertise: - transaction relay (`relay=1` in the `version` message); - compact block filters (`NODE_COMPACT_FILTERS`). (#7755) -## InstantSend and provider transactions - -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) - ## Bitcoin Core backports -This release includes a large number of backports from Bitcoin Core, covering -most of the changes from Bitcoin Core v25 and a substantial part of Bitcoin -Core v26, along with selected fixes from later releases. User-visible changes +This release includes a large number of further backports from Bitcoin Core. +With them, Dash Core now includes about 80% of the changes from Bitcoin Core +v25 and about 60% of those from Bitcoin Core v26, along with selected fixes +from later releases. User-visible changes from these backports are listed in the sections below. Notable additions include the `sendall` RPC, the experimental `migratewallet` RPC, `minconf`/`maxconf` options for funding RPCs, faster descriptor wallet rescans @@ -544,7 +592,16 @@ and RPC parameters. again from the network. (#7831) - This release includes the fixes shipped in Dash Core v23.1.9, including the consensus rule that rejects transactions with a negative `nVersion` once DIP3 - is active. + is active, and the change that stopped masternodes from InstantSend-locking + provider transactions (#7858; software waiting for an islock on a provider + transaction should wait for a ChainLock or confirmations instead). +- Network-adjusted time is no longer used to validate block timestamps or to + build block templates; both use the system clock. Keep the system clock + accurate. `-maxtimeadjustment` now only affects Dash subsystems that still use + network-adjusted time, such as governance, sporks and CoinJoin. (#7430) +- Hardware-accelerated SHA-256 (SHA-NI, AVX2/SSE4.1 on x86 and the ARMv8 SHA2 + extensions), which had been unintentionally disabled since v23.0.0, is + enabled again. (#7573) - This release also contains many robustness and denial-of-service hardening fixes in the P2P, LLMQ, governance and CoinJoin message handlers. @@ -585,6 +642,21 @@ and RPC parameters. more is rejected and the sending peer is penalized as misbehaving. No known client sends more than a handful. The `quorum rotationinfo` RPC applies the same limit and returns an error when it is exceeded. (#7629) +- Transactions that fail the DERSIG, NULLDUMMY, CHECKLOCKTIMEVERIFY or + CHECKSEQUENCEVERIFY script checks are now rejected with + `mandatory-script-verify-flag-failed (…)` instead of + `non-mandatory-script-verify-flag (…)`, and the relaying peer is penalized. + Software that matches reject reasons may need updating. (#7710) +- Unsolicited `clsig`, `qfcommit` and DKG messages, which the node never + requested, are dropped and add a misbehavior score of 10 to the sending peer. + (#7484) +- Pending `qgetdata` requests are now limited to 64 per peer and 4096 in total; + a peer that exceeds the limit is penalized. (#7519) +- Sporks are now announced to every peer once the handshake completes, instead + of being requested with `getsporks` during masternode sync, so a node that + starts without sporks (for example after the `sporks.dat` reset) receives + them. Repeated `getsporks` requests are ignored while the active spork set is + unchanged. (#7893, #7343) ## Mining and mempool policy @@ -664,6 +736,29 @@ and RPC parameters. 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. (#7428) +- `quorum dkgstatus` now reports in `phase` the latest DKG phase whose messages + this node has already sent, rather than the phase the session is in (#7769), + and `minableCommitments` lists the commitments that can be mined in the next + block rather than at the current tip (#7770). +- `masternode status` reports a new `quorumParticipation` field. It is `false` + while DKG participation and quorum signing are disabled, which happens while + the node runs on a snapshot whose background validation has not completed; + `status` then says so as well. (#7456) +- JSON-RPC batch requests from users restricted by `-rpcwhitelist` are now + checked element by element: a batch is rejected with HTTP 403 if any of its + methods is not whitelisted for the user, as a single call already was. + Previously, depending on how the whitelist was written, batches either + bypassed the whitelist entirely or were always rejected. (#7722) +- `getrawtransaction` accepts `verbosity=2`, which adds the transaction fee and + each input's `prevout` when undo data is available. The argument formerly + named `verbose` is now `verbosity` in `getrawtransaction` and + `getrawtransactionmulti`; the old name is still accepted. (#7666) +- `generateblock` gains a `submit` argument (default `true`). With + `submit=false` it returns the block hex without submitting the block. (#7192) +- The `-deprecatedrpc=exclude_coinbase` option has been removed. + `getreceivedbyaddress`, `getreceivedbylabel`, `listreceivedbyaddress` and + `listreceivedbylabel` always count coinbase outputs, as they have by default + since v23.0.0. (#7492) - `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. (#7480) @@ -721,6 +816,16 @@ and RPC parameters. the recipient incurs the transaction fee, continue to use the `subtractfeefromamount` option via the `send`, `sendtoaddress`, or `sendmany` RPCs. (#7131) +- `scanblocks` returns the blocks that may contain transactions relevant to a + set of descriptors, using compact block filters. It requires + `-blockfilterindex=1`. Combined with `rescanblockchain` over the returned + range, it allows fast rescans. (#7192) + +## REST + +- The `/rest/mempool/contents.json` endpoint accepts `verbose=` and + `mempool_sequence=` query parameters (defaults: `verbose=true`, + `mempool_sequence=false`), matching the `getrawmempool` RPC. (#7390) ## Updated settings @@ -745,6 +850,27 @@ and RPC parameters. - 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`. (#7710) +- A node started with `-txindex=0` must now also set `-disablegovernance`; + otherwise startup fails with an error, because governance validation looks up + proposal collateral through the transaction index. Previously such a node + started and then rejected every governance proposal. Regtest is exempt, and + pruned nodes are not affected because `-prune` already disables governance + validation. (#7785) +- Fee estimates are now saved hourly, and `fee_estimates.dat` is ignored at + startup if it is more than 60 hours old, so a node that was offline for longer + than that rebuilds its estimates. (#7711) + +## 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`. (#7861) ## Command-line options @@ -834,6 +960,10 @@ and RPC parameters. "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. (#7871) +- `importwallet` now works on pruned nodes, as long as the blocks back to the + oldest key's timestamp are still on disk. Previously it was refused on any + pruned node. (#7666) +- Descriptors containing hybrid public keys are now rejected. (#7356) ## RPC Wallet @@ -860,10 +990,17 @@ and RPC parameters. - RPC `walletprocesspsbt` return object now includes field `hex` (if the transaction is complete) containing the serialized transaction suitable for RPC `sendrawtransaction`. (#7354) -- 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. (#7710) +- The `signrawtransactionwithkey`, `signrawtransactionwithwallet` and + `walletprocesspsbt` calls now return the more specific RPC_INVALID_PARAMETER + error instead of RPC_MISC_ERROR if their sighashtype argument is malformed. + (#7710) +- `rescanblockchain` on an encrypted wallet now fails with error -13 unless the + wallet has been unlocked with `walletpassphrase`, because the keypool may need + to be topped up during the rescan. The wallet cannot be relocked while the + rescan runs. (#7711) +- A wallet that is unlocked only for mixing can no longer sign transactions + created by `send` and `sendall`; they return an incomplete PSBT until the + wallet is fully unlocked. (#7663) - 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 @@ -891,6 +1028,17 @@ and RPC parameters. - 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) +- Asset Lock transactions appear in the transaction history as **Asset Lock**, + with their own filter, instead of as "Data Transaction". (#7652) +- The File menu gains a **Migrate Wallet** item that migrates a legacy wallet + to a descriptor wallet (see [Descriptor wallets by default](#descriptor-wallets-by-default)). + (#7277) +- The startup splash screen has been redesigned and now shows a progress bar, + including wallet rescan progress. (#7210) +- In Coin Control, the "toggle lock state" button has been replaced by an + "(un)lock all" button. (#7155) +- The "Show Masternodes Tab" and "Show Governance Tab" options moved from the + Wallet page to the Display page of the Options dialog. (#7152) ## Build system @@ -915,13 +1063,10 @@ Thanks to everyone who directly contributed to this release: - Antonio Moratti - Kittywhiskers Van Gogh - Konstantin Akimov -- PastaClaw - PastaPastaPasta -- takeshikurosawaa - thephez - UdjinM6 - Vijay -- zxccxccxz As well as everyone that submitted issues, reviewed pull requests and helped debug the release candidates. @@ -972,7 +1117,7 @@ These releases are considered obsolete. Old release notes can be found here: - [v0.16.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.1.1.md) released November/17/2020 - [v0.16.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.1.0.md) released November/14/2020 - [v0.16.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.0.1.md) released September/30/2020 -- [v0.15.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.15.0.0.md) released Febrary/18/2020 +- [v0.15.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.15.0.md) released February/18/2020 - [v0.14.0.5](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.5.md) released December/08/2019 - [v0.14.0.4](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.4.md) released November/22/2019 - [v0.14.0.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.14.0.3.md) released August/15/2019 @@ -990,7 +1135,6 @@ These releases are considered obsolete. Old release notes can be found here: - [v0.12.2.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.3.md) released Jan/12/2018 - [v0.12.2.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.2.md) released Dec/17/2017 - [v0.12.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.md) released Nov/08/2017 -- [v0.12.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.1.md) released Feb/06/2017 - [v0.12.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.0.md) released Aug/15/2015 - [v0.11.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.11.2.md) released Mar/04/2015 - [v0.11.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.11.1.md) released Feb/10/2015 From ddc82a837fe29857cdd0846dfa801cd7f8fa8ce4 Mon Sep 17 00:00:00 2001 From: pasta Date: Fri, 30 Oct 2026 01:15:57 +0000 Subject: [PATCH 6/7] docs: separate extended addresses from shared masternodes in v24 notes The "Extended addresses (ProTx version 3)" section mixed two features that only share a transaction version. Split it into a neutral "Provider transaction version 3 format" note (wire-format change, v3 for ProUpRegTx/ProUpRevTx, folded-in v4, parser impact) and an "Extended addresses" section (netInfo, EvoNode ProUpServTx v3 requirement, port 443). Both features activate with v24; extended addresses do not depend on evo_shares, while EvoNode shares and multiple payouts do. The shared masternode section now points to the format note instead of calling version 3 "extended addresses". Restate Bitcoin Core backport coverage per release: essentially all of v0.17-v24, about 90% of v25, 70% of v26, over half of v27 and a third of v28. Co-Authored-By: Claude Opus 5.5 --- doc/release-notes.md | 90 +++++++++++++++++++++++++++++--------------- 1 file changed, 59 insertions(+), 31 deletions(-) diff --git a/doc/release-notes.md b/doc/release-notes.md index 758391b4a5a5..371fcd6b4594 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -134,6 +134,10 @@ On testnet, both deployments start at `1790208000` (Thursday, September 24, 2026 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 @@ -148,10 +152,10 @@ Before activation there is no behavior change. (#7437, #7340) 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-protx-version-3)). -- 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` + [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; @@ -159,7 +163,9 @@ Before activation there is no behavior change. (#7437, #7340) ### Consensus changes (active with `v24`) -- A version 3 (extended addresses) ProRegTx may carry a collateral share table: +- 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 @@ -282,6 +288,48 @@ Before activation there is no behavior change. (#7437, #7340) 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. + ## Version 2 Asset Unlock transactions Once the `v24` hard fork activates, Platform withdrawals are issued as version 2 @@ -392,27 +440,6 @@ does not accept that option. (#7294, #7285, #7577) its operator key, and `update_registrar` clamped the transaction version silently. (#7473) -## Extended addresses (ProTx version 3) - -- Once the `v24` hard fork activates, provider transactions and masternode - states may use version 3 (extended addresses, `ExtAddr`), which Dash Core - v23 introduced but did not enable. Version 4 has been dropped, and its - contents were folded into version 3. (#7302, #7741, #7748, #7751) -- The version 3 wire format differs from the one v23 defined. In version 3 - ProRegTx and ProUpRegTx payloads, `scriptPayout` is replaced by a - length-prefixed payout list, and a version 3 ProRegTx also carries the share - table, the join signatures and the early-exit terms. ProUpRegTx and ProUpRevTx - may now use version 3 as well. Software that parses or builds provider - transactions (explorers, SPV libraries, external wallets) must be updated. -- After activation, an EvoNode service update (`ProUpServTx`) must be version 3 - and list its Platform P2P and HTTPS addresses explicitly. 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. - ## CoinJoin promotion and demotion - CoinJoin can now promote and demote between adjacent standard denominations @@ -560,11 +587,12 @@ connections to it advertise: ## Bitcoin Core backports -This release includes a large number of further backports from Bitcoin Core. -With them, Dash Core now includes about 80% of the changes from Bitcoin Core -v25 and about 60% of those from Bitcoin Core v26, along with selected fixes -from later releases. User-visible changes -from these backports are listed in the sections below. Notable additions +This release continues the backporting of Bitcoin Core, adding well over 200 +pull requests from the v25 and v26 release cycles alone. Dash Core now +includes essentially all of Bitcoin Core v0.17 through v24, about 90% of v25, +about 70% of v26, over half of v27 and about a third of v28, along with +selected fixes from later releases. User-visible changes from these backports +are listed in the sections below. Notable additions include the `sendall` RPC, the experimental `migratewallet` RPC, `minconf`/`maxconf` options for funding RPCs, faster descriptor wallet rescans using compact block filters, and stricter validation of configuration options From 5800e5d72511b07e5c37543b567980679cb1cf2f Mon Sep 17 00:00:00 2001 From: pasta Date: Fri, 30 Oct 2026 01:17:19 +0000 Subject: [PATCH 7/7] docs: state that SPORK_3/SPORK_9 were already hardened on mainnet The release notes said the two sporks were "effectively always enabled" on mainnet, which reads as if they could have been switched off there. Mainnet spork values have been hardcoded since v21.0.0 (#6140), so only the test networks still honored them; #7278 removes the definitions and that remaining test-network gating. Co-Authored-By: Claude Opus 5.5 --- doc/release-notes.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/doc/release-notes.md b/doc/release-notes.md index 371fcd6b4594..1d9cba237daf 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -604,11 +604,14 @@ and RPC parameters. blocks, even when the original ChainLock message was missed. This applies after v20 activation while ChainLocks are enabled. (#6236) - `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. (#7278) + been removed. On mainnet both have been hardcoded on, and could not be changed + by spork messages, since Dash Core v21.0.0 hardened all mainnet spork values + (#6140). Only the test networks (testnet, devnets and regtest) still honored + them. This release removes the two spork definitions and the remaining + test-network gating, so the associated functionality (InstantSend + conflicting-block rejection and superblock payments) is always enabled on + every network, and the sporks no longer appear in the `spork` RPC output. + (#7278) - Multi-key ("M-of-N") spork signing, which was never deployed on any network, has been removed. The `sporks.dat` cache format changed; caches written by previous versions are discarded on startup and sporks are re-synced from