diff --git a/configure.ac b/configure.ac index ea1aed9c6979..d5d2b0651c14 100644 --- a/configure.ac +++ b/configure.ac @@ -2,7 +2,7 @@ AC_PREREQ([2.69]) dnl Don't forget to push a corresponding tag when updating any of _CLIENT_VERSION_* numbers define(_CLIENT_VERSION_MAJOR, 24) define(_CLIENT_VERSION_MINOR, 0) -define(_CLIENT_VERSION_BUILD, 0) +define(_CLIENT_VERSION_BUILD, 1) define(_CLIENT_VERSION_IS_RELEASE, true) define(_COPYRIGHT_YEAR, 2026) define(_COPYRIGHT_HOLDERS,[The %s developers]) diff --git a/contrib/flatpak/org.dash.dash-core.metainfo.xml b/contrib/flatpak/org.dash.dash-core.metainfo.xml index 6cbc10d952fe..4ac5f311efbf 100644 --- a/contrib/flatpak/org.dash.dash-core.metainfo.xml +++ b/contrib/flatpak/org.dash.dash-core.metainfo.xml @@ -21,6 +21,7 @@ + diff --git a/depends/packages/miniupnpc.mk b/depends/packages/miniupnpc.mk index e63752406107..6a0cfa8cc166 100644 --- a/depends/packages/miniupnpc.mk +++ b/depends/packages/miniupnpc.mk @@ -1,6 +1,6 @@ package=miniupnpc $(package)_version=2.2.7 -$(package)_download_path=https://miniupnp.tuxfamily.org/files/ +$(package)_download_path=http://miniupnp.free.fr/files/ $(package)_file_name=$(package)-$($(package)_version).tar.gz $(package)_sha256_hash=b0c3a27056840fd0ec9328a5a9bac3dc5e0ec6d2e8733349cf577b0aa1e70ac1 $(package)_patches=dont_leak_info.patch cmake_get_src_addr.patch fix_windows_snprintf.patch diff --git a/doc/man/dash-cli.1 b/doc/man/dash-cli.1 index a04d71f9b5cf..d7149d0f0286 100644 --- a/doc/man/dash-cli.1 +++ b/doc/man/dash-cli.1 @@ -1,7 +1,7 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-CLI "1" "November 2026" "dash-cli v24.0.0" "User Commands" +.TH DASH-CLI "1" "November 2026" "dash-cli v24.0.1" "User Commands" .SH NAME -dash-cli \- manual page for dash-cli v24.0.0 +dash-cli \- manual page for dash-cli v24.0.1 .SH SYNOPSIS .B dash-cli [\fI\,options\/\fR] \fI\, \/\fR[\fI\,params\/\fR] \fI\,Send command to Dash Core\/\fR @@ -15,7 +15,7 @@ dash-cli \- manual page for dash-cli v24.0.0 .B dash-cli [\fI\,options\/\fR] \fI\,help Get help for a command\/\fR .SH DESCRIPTION -Dash Core RPC client version v24.0.0 +Dash Core RPC client version v24.0.1 .SH OPTIONS .HP \-? diff --git a/doc/man/dash-qt.1 b/doc/man/dash-qt.1 index b5d118c05a14..bb5400952946 100644 --- a/doc/man/dash-qt.1 +++ b/doc/man/dash-qt.1 @@ -1,12 +1,12 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-QT "1" "November 2026" "dash-qt v24.0.0" "User Commands" +.TH DASH-QT "1" "November 2026" "dash-qt v24.0.1" "User Commands" .SH NAME -dash-qt \- manual page for dash-qt v24.0.0 +dash-qt \- manual page for dash-qt v24.0.1 .SH SYNOPSIS .B dash-qt [\fI\,command-line options\/\fR] [\fI\,URI\/\fR] .SH DESCRIPTION -Dash Core version v24.0.0 +Dash Core version v24.0.1 .PP Optional URI is a Dash address in BIP21 URI format. .SH OPTIONS diff --git a/doc/man/dash-tx.1 b/doc/man/dash-tx.1 index 932abfe40d4c..128aac1217d0 100644 --- a/doc/man/dash-tx.1 +++ b/doc/man/dash-tx.1 @@ -1,7 +1,7 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-TX "1" "November 2026" "dash-tx v24.0.0" "User Commands" +.TH DASH-TX "1" "November 2026" "dash-tx v24.0.1" "User Commands" .SH NAME -dash-tx \- manual page for dash-tx v24.0.0 +dash-tx \- manual page for dash-tx v24.0.1 .SH SYNOPSIS .B dash-tx [\fI\,options\/\fR] \fI\, \/\fR[\fI\,commands\/\fR] \fI\,Update hex-encoded dash transaction\/\fR @@ -9,7 +9,7 @@ dash-tx \- manual page for dash-tx v24.0.0 .B dash-tx [\fI\,options\/\fR] \fI\,-create \/\fR[\fI\,commands\/\fR] \fI\,Create hex-encoded dash transaction\/\fR .SH DESCRIPTION -Dash Core dash\-tx utility version v24.0.0 +Dash Core dash\-tx utility version v24.0.1 .SH OPTIONS .HP \-? diff --git a/doc/man/dash-util.1 b/doc/man/dash-util.1 index 40637cd6c6af..35e3f5290f68 100644 --- a/doc/man/dash-util.1 +++ b/doc/man/dash-util.1 @@ -1,12 +1,12 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-UTIL "1" "November 2026" "dash-util v24.0.0" "User Commands" +.TH DASH-UTIL "1" "November 2026" "dash-util v24.0.1" "User Commands" .SH NAME -dash-util \- manual page for dash-util v24.0.0 +dash-util \- manual page for dash-util v24.0.1 .SH SYNOPSIS .B dash-util [\fI\,options\/\fR] [\fI\,commands\/\fR] \fI\,Do stuff\/\fR .SH DESCRIPTION -Dash Core dash\-util utility version v24.0.0 +Dash Core dash\-util utility version v24.0.1 .SH OPTIONS .HP \-? diff --git a/doc/man/dash-wallet.1 b/doc/man/dash-wallet.1 index 73b24e314b25..6034d6b58b37 100644 --- a/doc/man/dash-wallet.1 +++ b/doc/man/dash-wallet.1 @@ -1,9 +1,9 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASH-WALLET "1" "November 2026" "dash-wallet v24.0.0" "User Commands" +.TH DASH-WALLET "1" "November 2026" "dash-wallet v24.0.1" "User Commands" .SH NAME -dash-wallet \- manual page for dash-wallet v24.0.0 +dash-wallet \- manual page for dash-wallet v24.0.1 .SH DESCRIPTION -Dash Core dash\-wallet version v24.0.0 +Dash Core dash\-wallet version v24.0.1 .PP dash\-wallet is an offline tool for creating and interacting with Dash Core wallet files. By default dash\-wallet will act on wallets in the default mainnet wallet directory in the datadir. diff --git a/doc/man/dashd.1 b/doc/man/dashd.1 index 32fd5dcb4238..8095630417fd 100644 --- a/doc/man/dashd.1 +++ b/doc/man/dashd.1 @@ -1,12 +1,12 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH DASHD "1" "November 2026" "dashd v24.0.0" "User Commands" +.TH DASHD "1" "November 2026" "dashd v24.0.1" "User Commands" .SH NAME -dashd \- manual page for dashd v24.0.0 +dashd \- manual page for dashd v24.0.1 .SH SYNOPSIS .B dashd [\fI\,options\/\fR] \fI\,Start Dash Core\/\fR .SH DESCRIPTION -Dash Core version v24.0.0 +Dash Core version v24.0.1 .SH OPTIONS .HP \-? diff --git a/doc/release-notes.md b/doc/release-notes.md index a068e9580a50..d152442844e4 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -1,10 +1,19 @@ -# Dash Core version v24.0.0 - -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. +# Dash Core version v24.0.1 + +This is a new patch version release. It fixes two problems that have delayed +the `v24` network upgrade on mainnet: masternodes signed the `v24` EHF signal +only once, so a first attempt that fell short was never retried, and +`LLMQ_400_85` quorums were failing to form because slower masternodes could +not finish the last step of the DKG in time. It also changes how masternodes +vote on superblock triggers so that a superblock cannot be left unpaid by a +change in the approved proposals, and fixes several other bugs. + +Like v24.0.0, this release carries the `v24` network upgrade (hard fork) and is +**mandatory** for all nodes. Masternodes should upgrade to v24.0.1 as soon as +possible. All other nodes must run v24.0.0 or later before the hard fork +activates, and upgrading to v24.0.1 is strongly recommended. The upgrade itself +and everything else introduced in v24 are described in the +[v24.0.0 release notes](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-24.0.0.md). Please report bugs using the issue tracker at GitHub: @@ -19,1274 +28,108 @@ shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Dash-Qt (on Mac) or dashd/dash-qt (on Linux). -On the first start after upgrading, a node that has `-addressindex`, -`-spentindex` or `-timestampindex` enabled migrates that index to its own -database (see [Asynchronous address, spent and timestamp indexes](#asynchronous-address-spent-and-timestamp-indexes)). -This can take 20-40 minutes or longer depending on hardware and index size. -Start v24.0.0 for the first time with the same `-addressindex`, `-spentindex` -and `-timestampindex` settings the node used before (pruned nodes: see -below): an index that is left -disabled on any start of v24.0.0 can no longer reuse its old data, and is -rebuilt from genesis when it is enabled again. The governance cache -(`governance.dat`) and the spork cache (`sporks.dat`) changed format and are -discarded and re-synced from the network on the first start. - -A node that runs with `-txindex=0` must now also set `-disablegovernance`; -otherwise it refuses to start (see [Updated settings](#updated-settings)). -Pruned nodes are not affected by this, since `-prune` disables governance -validation already. - -A pruned node (`-prune`) that also has `-addressindex` or `-spentindex` set -refuses to start with an error, because these indexes now need the undo data -that pruning deletes. v23 accepted that combination. Remove the index options -from such a node before upgrading. Keeping them means running the node -unpruned, which requires `-reindex` and downloading the whole chain again. -`-timestampindex` can no longer be enabled on a datadir that has already been -pruned (see -[Asynchronous address, spent and timestamp indexes](#asynchronous-address-spent-and-timestamp-indexes)). - -Masternodes refuse to start with some settings that v23 accepted, such as -`-blocksonly=1`, `-peerblockfilters=0` or a nonzero `-maxuploadtarget`. This -applies from the first start of v24.0.0, not from hard fork activation. Check -the masternode's configuration against -[Masternode configuration requirements](#masternode-configuration-requirements) -and remove such settings before upgrading. Masternodes must be upgraded and -running before the `v24` start date (November 9, 2026 on mainnet): the -activation signal needs 85% of the signing quorum's members to run v24, and a -masternode that refuses to start cannot contribute to it (see -[Network upgrade](#network-upgrade)). - -On mainnet, a masternode that moves to extended addresses must keep an IPv4 -address on the standard port as the first entry of each address list (see -[Extended addresses](#extended-addresses)). (#8018) - -A node that ran a v24.0.0 release candidate with `-addressindex`, -`-spentindex` or `-timestampindex` enabled should rebuild these indexes once -after upgrading (see -[Asynchronous address, spent and timestamp indexes](#asynchronous-address-spent-and-timestamp-indexes)), -in one of two ways: - -- restart once with `-reindex`; or -- start v24.0.0 once with `-addressindex=0 -spentindex=0 -timestampindex=0`, - stop it, delete the `indexes/addressindex`, `indexes/spentindex` and - `indexes/timestampindex` directories, then start it again with the indexes - enabled. They are rebuilt in the background. - -Do not only delete the index directories without the intermediate start: on a -datadir a release candidate has used, that can leave empty indexes that report -themselves as synced. - -Pruned nodes now keep at least 2304 blocks below the tip instead of 288 (see -[Pruning](#pruning)). Blocks that an earlier version already pruned are not -recovered; a node that fails to validate a block after upgrading needs -`-reindex`. +Upgrading from v24.0.0 needs no further steps. If you are upgrading from +v23.1.x or older, read "How to Upgrade" in the +[v24.0.0 release notes](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-24.0.0.md) +first: the first start migrates the address, spent and timestamp indexes, and +some settings changed. ## Downgrade warning -### Downgrade to a version < v24.0.0 - -There is no supported downgrade after `v24` activation: v23 and older cannot -follow the network once `v24` is active. They also cannot correctly read the -masternode list data that v24.0.0 stores after activation, so do not start an -older version on a datadir that v24.0.0 has used after activation. - -Before activation, downgrading to v23.1.x is possible with the following -caveats: - -- The address, spent and timestamp indexes are moved out of the block index - database into separate databases on the first start of v24.0.0. A node that - had any of these indexes enabled must be restarted with `-reindex` after - downgrading. Older versions enforce this: they refuse to start with an index - that v24.0.0 has migrated until `-reindex` is given. (#8031) -- The governance and spork caches written by v24.0.0 are not readable by older - versions; they are discarded and re-synced from the network. -- v24.0.0 does not upgrade the wallet file format. Wallet records added by - v24.0.0 that older versions do not know about (such as the new CoinJoin - pending-observation record) are ignored by them. -- Dash-Qt moves the dust attack protection setting into the settings it shares - with `dashd` (see `-dustprotectionthreshold` under - [New options](#new-options)). Older versions don't read it there, so after a - downgrade dust protection is disabled and has to be enabled again in the - options dialog. - -### Downgrade to a version < v23.0.0 - -Downgrading to a version older than v23.0.0 is not supported, and will -require a reindex. - -## Compatibility - -- Dash Core binaries now require macOS 14 (Sonoma) or later. Dash Core v23.1.x - binaries supported macOS 11 (Big Sur) or later. Because v24.0.0 is mandatory, - users on macOS 13 or older must upgrade macOS, or move their node or wallet - to a supported system, before the `v24` hard fork activates. Windows 10 or - later continues to be required on Windows. -- On Linux, kernel 3.17 or later is now required. The minimum glibc version - (2.31) is unchanged. -- `PROTOCOL_VERSION` has been bumped from `70240` to `70242` (see - [P2P and network changes](#p2p-and-network-changes)). - `MIN_PEER_PROTO_VERSION` is unchanged at `70221`. -- `MIN_MASTERNODE_PROTO_VERSION` has been bumped from `70240` to `70242`. During - DKG, quorum members connected over an older protocol version are considered - to have a bad connection and are voted bad, which leads to PoSe penalties. - All masternodes must therefore upgrade to v24.0.0. - -# Network upgrade - -This release introduces two new deployments that use the masternode-activated -[Enhanced Hard Fork](https://github.com/dashpay/dips/blob/master/dip-0023.md) -(EHF, DIP-0023) mechanism: - -| Deployment | Name | Version bit | -| --- | --- | --- | -| V24 | `v24` | 13 | -| EvoNode shares | `evo_shares` | 14 | - -On mainnet both deployments use identical parameters: - -- start time: `1794182400` (Monday, November 9, 2026 00:00:00 UTC); -- timeout: `1857340800` (Thursday, November 9, 2028 00:00:00 UTC); -- signaling window: 4032 blocks (about 7 days); -- threshold: 80% (3226 of 4032 blocks) in the first signaling window, decreasing - with each window to a floor of 60% (2420 of 4032 blocks) after 10 windows. - -Activation proceeds as follows: - -1. Once the median time past passes the start time, masternodes running v24 - sign an EHF signal with the `LLMQ_400_85` quorum. This requires 85% of the - quorum's members to be running v24. -2. After the signal is mined, miner signaling starts at the next 4032-block - window boundary. -3. If the threshold is reached within a window, the hard fork locks in, and it - activates one window later. - -Mainnet is expected to be near block 2,569,500 on November 9, 2026, so the -first window boundary after the signal is block 2,572,416 (around November 14). -If that window reaches the threshold, `v24` locks in at block 2,576,448 and -activates at block 2,580,480, around November 28, 2026. That is the earliest -possible activation; every window that misses the threshold delays it by about -one week. The dates are estimates based on 2.5-minute blocks. - -All masternodes must upgrade before the start date. All other nodes must -upgrade before activation, or they will follow an invalid chain. - -v24.0.0 does **not** sign the `evo_shares` signal. Until `evo_shares` activates, -EvoNodes cannot use shared collateral or more than one owner payout (see -[EvoNode restrictions](#evonode-restrictions)). A later release (v24.1) is -expected to sign it once Dash Platform supports EvoNode shares and payouts. -Both deployments carry identical parameters so that the later release can -activate `evo_shares` without another mainnet parameter change. - -On testnet, both deployments start at `1790208000` (Thursday, September 24, 2026 -00:00:00 UTC). - -# Notable changes - -## Decentralized masternode shares and multi-party payouts - -This release implements the Decentralized Masternode Shares DIP, activating -together with DIP-0026 multi-party payouts as part of the `v24` hard fork. -For EvoNodes, shared collateral and more than one owner payout additionally -require the `evo_shares` deployment (see [EvoNode restrictions](#evonode-restrictions)). -Both features use version 3 provider transactions (see -[Provider transaction version 3 format](#provider-transaction-version-3-format)). -Before activation there is no behavior change. (#7437, #7340) - -### Multi-party payouts - -- The `payoutAddress` argument of `protx register`, `protx register_evo`, - `protx register_fund`, `protx register_fund_evo`, `protx register_prepare`, - `protx register_prepare_evo` and `protx update_registrar` accepts, in addition - to a single address, an array of `{"address": ..., "reward": ...}` objects - that splits the owner reward between several payees, with `reward` given in - basis points. Multi-party payouts are only valid once the `v24` hard fork - activates. The `..._legacy` variants build legacy-scheme transactions, which - cannot carry a payout list, and reject an array. For an EvoNode still on - version 2, `protx update_registrar` keeps version 2 and accepts only a single - payout address; upgrade the EvoNode with `protx update_service_evo` first (see - [Extended addresses](#extended-addresses)). -- For version 3 masternode states and ProTx payloads the payout list is - reported as a `payouts` array in place of the single `payoutAddress` field, - which earlier versions keep. Shared masternodes report `shares` - instead. The fields appear in `protx info`, `protx list detailed`, - `protx listdiff`, `masternode status` (`dmnState`) and in decoded - `ProRegTx`/`ProUpRegTx` payloads of the transaction-decoding RPCs; - `protx diff` includes them only with `extended=true`. (#7340) - -### Consensus changes (active with `v24`) - -- A version 3 ProRegTx (see - [Provider transaction version 3 format](#provider-transaction-version-3-format)) - may carry a collateral share table: - 2 to 8 participants fund the masternode collateral atomically in one - registration, each recording an immutable amount, refund script and share - owner key, plus an updatable reward script. Every share owner consents by - signing a digest that binds the exact funding inputs, all outputs, the share - table, the penalty terms and the registrar configuration. Consent is tied to - the shares in the table, not to the funding inputs: signing an input into a - registration neither requires nor creates a share for its owner. The - early-period penalty must be below the smallest share and must be zero when - no early period is configured. -- The shared collateral is paid to the 7-byte template script - `04445348437551` (`0x04 "DSHC" OP_DROP OP_TRUE`). From activation, an output - paying this exact script is valid only as the collateral of a valid shared - registration, and spending such an output is valid only via a ProDisTx. - Template outputs mined before activation become permanently unspendable. -- Three new special transaction types: - - **ProDisTx (type 10)** dissolves a shared masternode, refunding every - participant's principal to its immutable refund script. Exactly one - signature (unilateral, penalized during the configured early period) or one - per share (unanimous, penalty-free). Validity is monotone: a ProDisTx that - is valid at some height is valid at every later height, which makes offline - "standby dissolutions" safe. The transaction fee is capped at 1000000 duffs - and a unilateral dissolution may not pay bonuses beyond the configured - early penalty, bounding what a stolen share owner key can drain from its - own share. - - **ProUpShareTx (type 11)** lets one share owner update their reward script. - - **ProUpSharedRegTx (type 12)** updates the operator key and/or voting key - with a signature from every share owner. A plain ProUpRegTx is invalid for - shared masternodes. -- The owner reward of a shared masternode is split across the share table - proportionally to the recorded contributions (sequential floor, remainder to - the last entry), paying each share's reward script (or its refund script when - none is set). Operator rewards are unchanged. -- Withdrawal (asset unlock) transactions may not pay the template script. -- Coinbase payments are matched by multiplicity: every expected masternode - payment and every superblock payment must be paid by its own coinbase output, - so two identical expected payments (same script and amount) require two - outputs. Before activation one output could satisfy both. (#7362, #7377) - Mining pools should build exactly one coinbase output per `masternode[]` and - per `superblock[]` entry of `getblocktemplate`, in template order, even when - entries share a script or amount. After activation, a block that merges or - deduplicates them is invalid (`bad-cb-payee` / `bad-cb-amount`). - -### EvoNode restrictions - -- EvoNodes cannot register with shared collateral or have more than one owner - payout until the `evo_shares` deployment activates. An EvoNode ProRegTx with a - share table is rejected with `bad-protx-shares-evo`, and an EvoNode ProRegTx - or ProUpRegTx with more than one owner payout is rejected with - `bad-protx-payouts-evo`. Regular masternodes are not affected. -- The consent digest that share owners sign for a shared EvoNode registration - also covers the EvoNode's `platformNodeID`. The digest of a regular shared - registration is unchanged. (#7807) - -### Shared masternode relay policy - -- The template output relays only as the declared collateral output of a shared - registration, and a template prevout is accepted only inside a ProDisTx; both - remain nonstandard everywhere else. - -### Shared masternode RPCs - -- `protx shared_register_prepare` builds an unsigned shared registration from a - caller-supplied funding transaction. The result echoes the decoded terms and - carries a `warning` when `earlyPenalty` is zero, since any participant can - then force an early exit at no cost beyond the transaction fee. Before signing - its funding inputs with `signrawtransactionwithwallet`, each participant should - confirm that the share table (`proRegTx.shares` in `decoderawtransaction`) - holds its share with its own amount and addresses. -- `protx shared_register_prepare_evo` creates an unsigned shared EvoNode - registration. It takes the arguments of `protx shared_register_prepare` - followed by `platformNodeID`, `platformP2PAddrs` and `platformHTTPSAddrs`, and - fails until `evo_shares` is active. (#7807) -- `protx shared_sign` signs a shared registration, dissolution or shared - registrar update with every share owner key the wallet holds. It returns the - decoded terms being consented to (for a dissolution, including the outputs) - alongside the signatures, and repeats the zero-penalty warning for a - registration. It refuses a registration or dissolution carrying an - unsatisfied lock time or a relative input lock unless `allowTimeLocks` is - set. It signs a dissolution only when it returns every share's principal to - its refund address, less the fee from the actor's share, as - `protx shared_dissolve_prepare` builds it. -- `protx shared_combine` combines collected signatures and optionally submits. - A dissolution combined here requires a signature from every share; unilateral - dissolutions come fully signed from `protx shared_dissolve`. A - ProUpSharedRegTx must be combined in the wallet that ran - `protx shared_update_registrar_prepare`, because combining re-signs its fee - inputs. It is refused unless those inputs are unlocked coins of a single - address of this wallet, any change returns to that address, and the fee is - within `-maxtxfee`. (#7881) -- `protx shared_dissolve` creates, signs and submits a unilateral ProDisTx (or, - with `submit=false`, returns hex suitable for offline standby storage). -- `protx shared_dissolve_prepare` builds an unsigned unanimous ProDisTx. -- `protx shared_update_share` updates one share's reward address. To restore - rewards to the immutable refund address, pass that address explicitly; empty - reward scripts are not valid in update transactions. -- `protx shared_update_registrar_prepare` builds an unsigned ProUpSharedRegTx. - -### Updated masternode list RPCs - -- `masternodelist` and `masternode list` report comma-separated share owner - addresses in `owneraddress` for shared masternodes. The `json` and `recent` - modes can be filtered by any share owner address. Shared registrations and - masternode state omit the singular `ownerAddress` field in `protx` and decoded - transaction output; each participant's owner address is in `shares`. (#7437) - -### Shared masternode GUI - -- The Masternodes tab gains a "Shared Masternode…" wizard for registering a - masternode funded by several people. The coordinator enters the participants, - masternode settings and exit terms, reserves coins for their own share and - copies one invitation; every participant pastes it, reserves their coins and - copies back their details. Two more rounds complete the registration: locked - terms out and approvals back, then a signing request out and signed - contributions back. Any message can be pasted from the landing page, replies - are accepted in any order, and every message shows a short code so - participants can confirm they hold the same one. Sessions can be saved and - reopened by either role. Reserved coins are released after broadcast. (#7701) -- Shared masternodes appear in the list with the type "Shared (you hold k of - n)", a details view listing every share, and context-menu actions to change - the wallet's reward address, rotate the operator or voting key (with every - share owner's approval), dissolve now, dissolve together, or create a - standby dissolution file holding both the penalty-free and the immediate - variant. Pasting a maintenance request or a standby dissolution into the - list opens the matching dialog. (#7701) -- The owned-masternode filter includes shared masternodes when the wallet holds - a participant's refund destination, including when rewards go to a different - wallet. (#7437) - -## Provider transaction version 3 format - -Once the `v24` hard fork activates, ProRegTx, ProUpServTx, ProUpRegTx and -ProUpRevTx may use version 3. Version 3 carries both -[extended addresses](#extended-addresses) and -[multi-party payouts and shared masternodes](#decentralized-masternode-shares-and-multi-party-payouts). -(#7302) - -- Dash Core v23 defined version 3 for ProRegTx and ProUpServTx only, behind the - same `v24` deployment, and its wire format has changed since. In version 3 - ProRegTx and ProUpRegTx payloads, `scriptPayout` is replaced by a - length-prefixed payout list. A version 3 ProRegTx also carries a share table - with one join signature per share, and the early-exit terms - (`nEarlyPeriodBlocks`, `nEarlyPenalty`); these are empty or zero for an - ordinary registration. -- ProUpRegTx and ProUpRevTx may now use version 3 as well. -- Development builds briefly used a separate version 4 for multi-party payouts. - It has been folded into version 3, and no released version of Dash Core uses - version 4. -- Software that parses or builds provider transactions (explorers, SPV - libraries, external wallets) must be updated. - -## Extended addresses - -Dash Core v23 introduced extended masternode addresses (`netInfo`, which lists -the core P2P, Platform P2P and Platform HTTPS endpoints explicitly) behind the -`v24` deployment. They become usable once `v24` activates, for regular -masternodes and EvoNodes alike, and do not depend on `evo_shares`. A masternode -moves to extended addresses with a version 3 provider transaction (see -[Provider transaction version 3 format](#provider-transaction-version-3-format)). -(#7741, #7748, #7751) - -- After activation, an EvoNode service update (`ProUpServTx`) must be version 3 - and list its Platform P2P and HTTPS addresses explicitly; the separate - Platform port fields are not carried over. A version 2 EvoNode `ProUpServTx` - is rejected with `bad-protx-version-disallowed`, and raising an EvoNode with - addresses to version 3 by any other transaction is rejected with - `bad-protx-netinfo-version`. `protx update_service_evo` builds the right - transaction, but third-party tools that build version 2 EvoNode service - updates must be updated. -- Platform HTTPS entries on port 443 are accepted in extended addresses. -- A version 3 (extended addresses) ProRegTx or ProUpServTx must list an IPv4 - address as its first `coreP2PAddrs` entry, and an EvoNode's first - `platformP2PAddrs` and `platformHTTPSAddrs` entries must use that same IPv4 - address. Further entries may use other addresses and network types (IPv6, - Tor, I2P, CJDNS, and domains for Platform HTTPS). Violations are rejected - with `bad-protx-netinfo-addr-type` or `bad-protx-netinfo-addr`. This applies - until masternodes are allowed to operate without IPv4, which is not scheduled - on mainnet. Testnet and devnets already allow it, so they are unaffected. - Regtest follows mainnet unless `-testactivationheight=ipv4_optional@` - is set. (#8018) -- On mainnet, the first entry of each address list must also use that list's - standard port: 9999 for `coreP2PAddrs`, 26656 for `platformP2PAddrs` and 443 - for `platformHTTPSAddrs`, as legacy ProTx versions already require there. - Additional entries may use any otherwise valid port. Violations are rejected - with `bad-protx-netinfo-port`. (#8018) - -## Version 2 Asset Unlock transactions - -Once the `v24` hard fork activates, version 2 Asset Unlock transactions become -valid. Version 1 Asset Unlock transactions remain valid after activation, and -Platform withdrawals keep using version 1 until a future Dash Platform release -starts issuing version 2. Until then, the version 2 features described below -(the stable txid, InstantSend locking and relay by instance hash) do not apply -to Platform withdrawals. - -The transaction hash of a version 2 Asset Unlock is computed with the quorum -signing fields (`requestedHeight`, `quorumHash`, `quorumSig`) zeroed, so every -instance Platform re-signs after an expiry is the same transaction with one -stable txid. Spends of an unmined withdrawal's outputs therefore stay valid -across re-signs. (#7639) - -A version 2 Asset Unlock is InstantSend-locked as soon as it can be mined in -the next block: it carries a valid signature from a recent quorum, is inside -its height window, no other instance of its withdrawal index is in the -mempool, and the withdrawals pending in the mempool fit the credit pool's -current limit. The lock pins the withdrawal index (as the outpoint -`{DIP-27 request id, 0}`) to the txid. Spends of a locked withdrawal are -ordinary InstantSend transactions and the wallet treats the withdrawal's -outputs as trusted, so Platform-to-Core transfers become rapidly respendable. - -Version 2 unlocks are relayed by instance hash (new inventory type -`MSG_ASSET_UNLOCK`, protocol version 70242), kept in the mempool while expired -awaiting a re-signed replacement, and committed to by the coinbase transaction -(CbTx version 4, `merkleRootAssetUnlocks`). An expired instance is also -accepted into the mempool (from peers and when reloading `mempool.dat`) if its -signature was valid at a height within its window, so its spends propagate; it -is neither mined nor InstantSend-locked until Platform re-signs it. Relaying an -Asset Unlock outside the receiving node's height window or quorum range is no -longer penalized. (#7639, #7744) - -- `getmempoolinfo` reports `pendingassetunlocks`, the sum of the withdrawal - amounts of the Asset Unlock transactions in the mempool. -- `getassetunlockstatuses` reports `instantlock` for mempooled withdrawals. -- `getrawtransaction` and `decoderawtransaction` report `instanceHash` for - version 2 Asset Unlock transactions. -- For pools, explorers and indexers: the txid of a version 2 Asset Unlock is - the double SHA-256 of the transaction with `requestedHeight`, `quorumHash` - and `quorumSig` zeroed, not of its serialized bytes. The full-bytes hash is - `instanceHash`. Block merkle roots and `getblocktemplate` - `transactions[].hash` use the txid, so software that hashes raw transaction - bytes (`getblocktemplate` `data`, ZMQ `rawtx`/`rawblock`, P2P) must use the - `hash` field or apply the same zeroing. - -## Relative asset unlock limit - -- The asset unlock limit that applies once the `v24` hard fork activates is now - a relative net rule on the credit pool balance instead of a flat 4000 DASH cap - on gross unlocks per window (576 blocks on mainnet and testnet). Asset unlocks - may not leave the credit pool below its balance one window earlier minus an - allowed drop of 20% of that balance, never less than 2000 DASH and with no - upper bound. -- Deposits and the per-block Platform reward inside the window raise the - balance and are withdrawable again, so a deposit followed by its withdrawal - does not consume the allowance of other users. -- The new `getcreditpoolinfo [height]` RPC reports the credit pool balance after - a block, the balance one window earlier, the window length, the amount - unlocked inside the window and the asset unlock limit that applies to the - next block. (#7712) - -## Version 2 Asset Locks and Platform addresses - -- Asset Lock special transactions gain a payload version 2, enabled by the - `v24` hard fork. Before activation only version 1 is valid; after activation - both version 1 and version 2 are. A version 2 payload signals that Platform - assigns each credit output to the matching Identity automatically, and it - extends the allowed `creditOutputs[].scriptPubKey` forms from P2PKH only to - P2PKH and P2SH. All other Asset Lock rules are unchanged. See DIP-27. -- `validateaddress` and `getaddressinfo` now accept DIP-18 Dash Platform - addresses (`dash1k…`/`dash1s…` on mainnet, `tdash1k…`/`tdash1s…` on the test - chains) and report them with a new `isplatform` field. `getaddressinfo` - describes such an address against the credit output script an Asset Lock would - carry for it, so `ismine` and `solvable` answer whether this wallet holds the - key or script behind the address. -- `sendtoaddress` and `sendmany` accept Platform addresses as recipients. Doing - so turns the transaction into an Asset Lock with a version 2 payload whose - credit outputs are the Platform recipients, plus a single empty `OP_RETURN` - output carrying their total. `subtractfeefromamount` is not supported for - Platform recipients, because the locked amount has to match the `OP_RETURN` - value exactly. Paying a Platform address is refused before the `v24` hard - fork activates. -- `getrawtransaction`, `decoderawtransaction` and the other - transaction-decoding RPCs report `assetLockTx.creditOutputs[].address` for - version 2 payloads, the DIP-18 Platform address the credit output pays. - Version 1 payloads carry no such address and the field is omitted. - -This release carries the consensus side of version 2 Asset Locks: after the -`v24` hard fork they are valid in a block. They remain non-standard for now, so -under default policy they are not accepted into the mempool or relayed, and -sending to a Platform address fails with -`Transaction is non-standard (assetlocktx-version-2) …`. A future release will -make them standard once Dash Platform can process them; that is a policy change -only and needs no further consensus change. On testnet, devnets and regtest the -node can be started with `-acceptnonstdtxn=1` to relay them already; mainnet -does not accept that option. (#7294, #7285, #7577) - -## Masternode operator keys and BLS schemes - -- Dash Core will no longer permit the registration of new legacy BLS scheme - masternodes after the `v24` hard fork activates. Existing basic scheme - masternodes will also be prohibited from downgrading to the legacy scheme - after activation. (#6729) -- Masternode operator key uniqueness is now enforced per key rather than per - BLS encoding. After the `v24` hard fork activates, registering or updating to - an operator public key already used by another masternode is rejected - regardless of which BLS scheme (legacy or basic) either side is encoded under, - closing a gap where the same key could be claimed twice under different - encodings. -- After the `v24` hard fork activates, a legacy (LegacyBLS) masternode migrates - to the basic BLS scheme *in place* when its state version is raised, keeping - the same operator key: the stored operator public key is re-encoded from the - legacy to the basic scheme, with no key rotation required. `protx - update_service` and `protx update_registrar` build the corresponding - basic-scheme migration transaction for a legacy masternode, and the - masternode is no longer PoSe-banned by the change. The `..._legacy` RPC - variants keep the masternode on the legacy scheme. Previously a legacy - masternode could not move to the basic scheme without effectively rotating - its operator key, and `update_registrar` clamped the transaction version - silently. (#7473) - -## CoinJoin promotion and demotion - -- CoinJoin can now promote and demote between adjacent standard denominations - within a mixing session after the `v24` hard fork activates. Promotion - combines 10 inputs of one denomination into 1 output of the next larger - denomination, while demotion splits 1 input into 10 outputs of the next - smaller denomination. Pre-v24 behavior remains unchanged. -- Conversions only spend fully-mixed coins, and their outputs start mixing over - from zero rounds. The 10:1 shape of a conversion publicly clusters one - participant's coins even inside a mixing transaction, so a converted coin is - not treated as mixed: it re-enters mixing at its new denomination and - disperses normally, while the histories of the fully-mixed coins that fed the - conversion remain protected. -- A mixing session only completes once each side of its denomination is - occupied by nobody or by at least two participants, since coins are only - concealed by other coins of the same size on the same side. A session that - attracts a lone promotion or demotion participant and no counterpart - therefore waits, and expires in the queue stage without charging anyone's - collateral, rather than publishing a transaction that would identify that - participant's coins. Because admission relies on the declared directions, a - participant whose entry deviates from what it declared has its collateral - consumed. (#7052) -- A wallet that still has coins to mix keeps standard mixing. It joins - promotion and demotion queues that other wallets opened, but only opens its - own when it has no standard mixing session to join or start, so a conversion - waiting for a counterpart never holds up mixing. (#7995) -- A promotion prefers fully-mixed coins from different mixing transactions. If - there are not enough of those, it also spends coins that came out of the same - mixing transaction, which links them as one owner's coins, as an ordinary send - of the same coins would. (#7996) - -See [P2P and network changes](#p2p-and-network-changes) for the related -protocol changes. - -## Compact quorum proofs +### Downgrade to v24.0.0 -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) +Downgrading to v24.0.0 is possible and needs no special steps. -## Deprecated RPC fields now hidden by default - -- The deprecated keys `service`, `platformP2PPort` and `platformHTTPPort` now - require the runtime flag `-deprecatedrpc=service`. (#7181) - - The following RPCs are affected: `decoderawtransaction`, `decodepsbt`, - `getblock`, `getrawtransaction`, `gettransaction`, `masternode status` - (only the `dmnState` key), `protx diff`, `protx listdiff`. - - This runtime gate also extends to the functionally identical key, `address` - in `masternode list` (and its alias, `masternodelist`). - - The same gate applies to `getcoinjoininfo`, `protx info`, - `protx list detailed` and `quorum info`. - - `dash-tx -json` output omits these keys as well and offers no way to restore - them, since `dash-tx` does not accept `-deprecatedrpc`. -- Information on soft fork status has been moved from `getblockchaininfo` to the - new `getdeploymentinfo` RPC, which allows querying soft fork status at any - block, rather than just at the chain tip. Inclusion of soft fork status in - `getblockchaininfo` can currently be restored using the configuration - `-deprecatedrpc=softforks`, but this will be removed in a future release. Note - that in either case, the `status` field now reflects the status of the current - block rather than the next block. A new `/rest/deploymentinfo` REST endpoint - provides the same information. (#6888) - -### Note for masternode operators running Dash Platform - -Dash Platform reads the `service` field from Dash Core, and Platform versions -before v5.0.0 also read the `getblockchaininfo` `softforks` field. EvoNode -operators should upgrade Dash Platform to v5.0.0 or later together with Dash -Core: - -- dashmate v5.0.0 and later start Dash Core with `-deprecatedrpc=service`, and - Platform v5.0.0 and later read deployment status from `getdeploymentinfo`, so - no extra configuration is needed. -- Setups not managed by dashmate v5.0.0 or later must start Dash Core with - `-deprecatedrpc=service`, and Platform versions before v5.0.0 also need - `-deprecatedrpc=softforks`. Without these options Platform cannot operate - correctly. - -## Descriptor wallets by default - -Descriptor wallets are now the default wallet type. Newly created wallets will -use descriptors unless `descriptors=false` is set during `createwallet`, or the -`Descriptor wallet` checkbox is unchecked in the GUI. - -Note that wallet RPC commands like `importmulti` and `dumpprivkey` cannot be -used with descriptor wallets, so if your client code relies on these commands -without specifying `descriptors=false` during wallet creation, you will need to -update your code. (#7204) - -`createwallet` now also refuses `descriptors=false` without `load_on_startup`; -since v21 this applied only to `descriptors=true`. To create a legacy wallet, -pass both, for example: - -``` -dash-cli -named createwallet wallet_name=mywallet descriptors=false load_on_startup=true -``` - -`dash-wallet create` also creates a descriptor wallet by default. Pass the new -`-legacy` option to create a legacy wallet instead. (#7204) - -An experimental RPC `migratewallet` has been added to migrate legacy -(non-descriptor) wallets to descriptor wallets. More information about the -migration process is available in the -[documentation](https://github.com/dashpay/dash/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets). -(#7275) - -Failure handling in `migratewallet`, `restorewallet` and -`dash-wallet createfromdump` was fixed with backports from Bitcoin Core 28.x. A -failed migration restores the original wallet and leaves the rest of the -wallet directory as it was. After a migration, the migrated wallet and the -watch-only and solvables wallets it created are reloaded from disk, and if one -of them fails to load, the migration is rolled back. Migration backups are now -named `_