diff --git a/docs/core/guide/p2p-network-connecting-to-peers.md b/docs/core/guide/p2p-network-connecting-to-peers.md
index 83d111231..beba781d2 100644
--- a/docs/core/guide/p2p-network-connecting-to-peers.md
+++ b/docs/core/guide/p2p-network-connecting-to-peers.md
@@ -10,4 +10,4 @@ Connecting to a [peer](../resources/glossary.md#peer) is done by sending a [`ver
Once connected, the client can send to the remote node `getaddr` and [`addr` messages](../reference/p2p-network-control-messages.md#addr) to gather additional peers.
-In order to maintain a connection with a peer, nodes by default will send a message to peers before 30 minutes of inactivity. If 90 minutes pass without a message being received by a peer, the client will assume that connection has closed.
+In order to maintain a connection with a peer, nodes by default will send a [`ping` message](../reference/p2p-network-control-messages.md#ping) to peers every 2 minutes. If no data is sent to a peer for 20 minutes, no data is received from it for 20 minutes, or a `ping` message goes unanswered for 20 minutes, the client will assume that connection has closed. A peer is also disconnected if its send buffer stays full (sending paused) for 20 minutes.
diff --git a/docs/core/guide/p2p-network-misbehaving-nodes.md b/docs/core/guide/p2p-network-misbehaving-nodes.md
index d5b45e7d2..75ef1e146 100644
--- a/docs/core/guide/p2p-network-misbehaving-nodes.md
+++ b/docs/core/guide/p2p-network-misbehaving-nodes.md
@@ -38,40 +38,71 @@ Furthermore, a few additional changes are introduced to how discouraged addresse
| Net | Inventory List | 20 | More than `MAX_INV_SZ` (50000) inventories received (`inv` message)
| Net | Get Data Size | 20 | More than `MAX_INV_SZ` (50000) inventories requested (`getdata` message)
| Net | Orphan Transaction | **Varies** | Peer relayed an invalid orphan transaction. Ban score varies from 0-100 based on the specific reason (values set by `AcceptToMemoryPoolWorker()`)
-| Net | Bad Transaction | **Varies** | Transaction rejected from the mempool
+| Net | Bad Transaction | **Varies** | Transaction rejected from the mempool. Consensus failures score 100, including transactions that fail the DERSIG, NULLDUMMY, CHECKLOCKTIMEVERIFY, or CHECKSEQUENCEVERIFY script checks
| Net | Invalid Header | **Varies** | Invalid block header received from peer (`cmpctblock` message)
| Net | Invalid CompactBlock | **100** | Invalid compact block /non-matching block transactions received from peer (`cmpctblock` message)
+| Net | Repeated Block Transactions | **100** | Peer sent block transactions for a compact block whose previous reconstruction attempt failed ([`blocktxn` message](../reference/p2p-network-data-messages.md#blocktxn))
+| Net | Mutated Block | **100** | Peer relayed a mutated block (merkle root mismatch or 64-byte transaction malleation) ([`block` message](../reference/p2p-network-data-messages.md#block))
| Net | Header List Size | 20 | More than `MAX_HEADERS_RESULTS` (2000) headers received (`headers` message)
| Net | Header List Sequence | 20 | Non-continous headers sequence received (`headers` message)
| Net | Invalid Block | **Varies** | Invalid block header received from peer
-| Net | Bloom Filter Size | **100** | Maximum script element size (520) exceeded (`filterload` message or [`filteradd` message](../reference/p2p-network-control-messages.md#filteradd))
-| Net | MN List Diff | 1 | Failed to get masternode list diff (`getmnlistd` message)
+| Net | Bloom Filter Size | **100** | Malformed or oversized bloom filter: more than 36,000 bytes or 50 hash functions ([`filterload` message](../reference/p2p-network-control-messages.md#filterload)), or a data element exceeding the maximum script element size (520) ([`filteradd` message](../reference/p2p-network-control-messages.md#filteradd))
+| Net | Not Found List Size | 20 | More than `MAX_INV_SZ` (50000) entries received ([`notfound` message](../reference/p2p-network-data-messages.md#notfound))
+| Net | MN List Diff | 1 | Failed to get masternode list diff (`getmnlistd` message). Not applied when the failure is caused by block data this node does not have (pruned or below an unvalidated snapshot base)
| Net | Unrequested MN List Diff | **100** | Peer provided an unrequested masternode list diff (`mnlistdiff` message)
+| Net | Quorum Rotation Info | 1 | Failed to get quorum rotation info ([`getqrinfo` message](../reference/p2p-network-data-messages.md#getqrinfo)). Not applied when the failure is caused by block data this node does not have (pruned or below an unvalidated snapshot base)
+| Net | Malformed Quorum Rotation Info Request | **100** | Peer relayed a malformed request, including one with more than 4096 base block hashes (`getqrinfo` message)
+| Net | Unrequested Quorum Rotation Info | **100** | Peer provided unrequested quorum rotation info ([`qrinfo` message](../reference/p2p-network-data-messages.md#qrinfo))
| InstantSend | Invalid Lock Message | **100** | Invalid TXID or inputs in lock message (`isdlock` message)
| InstantSend | Verify Error | 20 | Peer relayed a message that failed to verify
| LLMQ ChainLock | Invalid | 10 | Invalid ChainLock message (`clsig` message)
+| LLMQ ChainLock | Unrequested | 10 | Peer sent a ChainLock that was not requested from it ([`clsig` message](../reference/p2p-network-instantsend-messages.md#clsig))
+| LLMQ Commitment | Unrequested | 10 | Peer sent a final commitment that was not requested from it ([`qfcommit` message](../reference/p2p-network-quorum-messages.md#qfcommit))
+| LLMQ Commitment | Stale Commitment | **100** | Peer with protocol version 70239 or higher relayed a commitment for a quorum more than one DKG interval old (`qfcommit` message)
| LLMQ Commitment | Null QcTx | **100** | Peer relayed a block with a null commitment
| LLMQ Commitment | Invalid LLMQ Type | **100** | Peer relayed a block containing an invalid LLMQ Type
| LLMQ Commitment | Invalid Height | **100** | Peer relayed a block that is not the first block in the DKG interval
| LLMQ Commitment | Invalid Commitment | **100** | Peer relayed a block with an invalid quorum commitment
-| LLMQ DKG | Empty Message | **100** | Peer relayed a message with no payload
+| LLMQ DKG | Unrequested | 10 | Peer sent a DKG message that was not requested from it (e.g. [`qcontrib` message](../reference/p2p-network-quorum-messages.md#qcontrib))
+| LLMQ DKG | Unverified Peer | 10 | Peer that is not a verified masternode relayed a DKG message
+| LLMQ DKG | Empty Message | **100** | Peer relayed a message too short to contain the LLMQ type and quorum hash
| LLMQ DKG | Invalid LLMQ Type | **100** | Peer relayed a message for an incorrect LLMQ Type
-| LLMQ DKG | Invalid Message | **100** | Peer relayed a message that could not be deserialized
+| LLMQ DKG | Invalid Quorum Hash | **100** | Peer relayed a message whose quorum hash is a block with no parent block or is not a valid quorum base block
+| LLMQ DKG | Invalid Message | **100** | Peer relayed a message that was oversized, malformed, or could not be deserialized
| LLMQ DKG | Preverify Failed | **100** | Peer relayed a message that could not be pre-verified
| LLMQ DKG | Signature | **100** | Peer relayed a message with an invalid signature
| LLMQ DKG | Full Verify Failed | **100** | Peer relayed a message that failed full verification
| LLMQ Signing | Too Many Messages | **100** | Maximum message count exceed in [`qsigsesann` message](../reference/p2p-network-quorum-messages.md#qsigsesann), [`qsigsinv` message](../reference/p2p-network-quorum-messages.md#qsigsinv), [`qgetsigs` message](../reference/p2p-network-quorum-messages.md#qgetsigs), or [`qbsigs` message](../reference/p2p-network-quorum-messages.md#qbsigs)
| LLMQ Signing | Signature | **100** | Peer relayed a message with an invalid recovered signature or signature share
+| LLMQ Quorum Data | Unauthorized Request | 10 | Request received by a node that is not a masternode, or from a peer that is neither a verified masternode nor a `qwatch` connection ([`qgetdata` message](../reference/p2p-network-quorum-messages.md#qgetdata))
+| LLMQ Quorum Data | Oversized Request | **100** | Request payload larger than a valid request (`qgetdata` message)
+| LLMQ Quorum Data | Invalid LLMQ Type | **100** | Request for an unknown LLMQ type (`qgetdata` message)
+| LLMQ Quorum Data | Too Many Requests | 25 | More than 64 requests from one masternode within about 5 minutes, or a repeated request for the same quorum within 5 minutes unless a requested quorum verification vector is missing (`qgetdata` message)
+| LLMQ Quorum Data | Unauthorized Response | 10 | Response from a peer that is not a verified masternode, or received by a node that is neither a masternode nor watching quorums ([`qdata` message](../reference/p2p-network-quorum-messages.md#qdata))
+| LLMQ Quorum Data | Unrequested Response | 10 | Response that was not requested, was already received, or does not match the request (`qdata` message)
+| LLMQ Quorum Data | Invalid Data Size | **100** | Verification vector or encrypted contributions with the wrong number of entries (`qdata` message)
+| LLMQ Quorum Data | Invalid Data | 10 | Invalid verification vector, contribution share, or resulting secret key share (`qdata` message)
| Masternode Authentication | Duplicate Message | **100** | Only 1 message allowed (`mnauth` message)
| Masternode Authentication | Invalid Services | **100** | Peer not advertising `NODE_NETWORK` or `NODE_BLOOM` services (`mnauth` message)
| Masternode Authentication | Empty Hash | **100** | Peer relayed a message with a null ProRegTx hash (`mnauth` message)
| Masternode Authentication | Signature | **100** | Peer relayed a message with an invalid signature (`mnauth` message)
| Masternode Authentication | Invalid MN | 10 | Peer not in the valid masternode list (`mnauth` message)
| Masternode Authentication | Invalid Signature | 10 | Signature verification failed (`mnauth` message)
-| Governance | Sync | 20 | Requesting a governance sync too frequently (`govsync` message with empty hash)
+| Governance | Sync | 20 | Requesting a governance sync too frequently (`govsync` message with empty hash), or repeatedly requesting votes for the same governance object that this node can sync (`govsync` message with an object hash and non-empty bloom filter)
+| Governance | Invalid Sync Filter | **100** | Malformed or oversized bloom filter ([`govsync` message](../reference/p2p-network-governance-messages.md#govsync))
+| Governance | Malformed Vote | **100** | Malformed vote, including a signature that is not 65 or 96 bytes ([`govobjvote` message](../reference/p2p-network-governance-messages.md#govobjvote))
| Governance | Invalid Object | 20 | Peer relayed an invalid governance object (`govobj` message)
| Governance | Invalid Vote | 20 | Peer relayed an invalid/invalid old vote(`govobjvote` message)
| Governance | Unsupported Vote Signal | 20 | Vote signal outside the accepted range (see [`govobjvote` message](../reference/p2p-network-governance-messages.md#govobjvote))
| CoinJoin | Signature | 10 | Peer relayed a message with an invalid signature (`dsq` message)
+| CoinJoin | Invalid DSTX | 10 | Peer relayed a CoinJoin broadcast transaction with an invalid structure or signature ([`dstx` message](../reference/p2p-network-privatesend-messages.md#dstx))
+| CoinJoin | Unverifiable DSTX | 1 | Peer relayed a CoinJoin broadcast transaction from an unknown masternode, or one that is only valid under rules activating at the next block (`dstx` message)
| Spork | Invalid Time | **100** | Peer relayed a spork with a timestamp too far in the future (`spork` message)
| Spork | Signature | **100** | Peer relayed a spork with an invalid signature (`spork` message)
+| Spork | Malformed | **100** | Peer relayed a spork that could not be deserialized ([`spork` message](../reference/p2p-network-control-messages.md#spork))
+| Platform | Unknown Masternode | 1 | Ban message references a ProTx hash not in the masternode list ([`platformban` message](../reference/p2p-network-masternode-messages.md#platformban))
+| Platform | Invalid Node Type | **100** | Ban message references a masternode that is not an evonode (`platformban` message)
+| Platform | Invalid Height | 1 | Requested height is up to 5 blocks outside the accepted range (576 blocks below the chain tip through the tip) (`platformban` message)
+| Platform | Invalid Height | 10 | Requested height is more than 5 blocks outside the accepted range (`platformban` message)
+| Platform | Unknown Quorum | **100** | Ban message references an unknown Platform quorum (`platformban` message)
+| Platform | Signature | **100** | Ban message has an invalid quorum signature (`platformban` message)
diff --git a/docs/core/guide/p2p-network-peer-discovery.md b/docs/core/guide/p2p-network-peer-discovery.md
index 6fc9113a9..8b4b54366 100644
--- a/docs/core/guide/p2p-network-peer-discovery.md
+++ b/docs/core/guide/p2p-network-peer-discovery.md
@@ -32,11 +32,11 @@ Once a program has connected to the [network](../resources/glossary.md#network),
However, peers often leave the network or change IP addresses, so programs may need to make several different connection attempts at startup before a successful connection is made. This can add a significant delay to the amount of time it takes to connect to the network, forcing a user to wait before sending a transaction or checking the status of payment.
-Dash Core tries to strike a balance between minimizing delays and avoiding unnecessary DNS seed use: if Dash Core has entries in its peer database, it spends up to 11 seconds attempting to connect to at least one of them before falling back to seeds; if a connection is made within that time, it does not query any seeds.
+Dash Core tries to strike a balance between minimizing delays and avoiding unnecessary DNS seed use: if Dash Core has entries in its peer database, it spends up to 11 seconds (or up to 5 minutes if the database has 1000 or more entries) attempting to connect to them before falling back to seeds; if it has at least two full-relay outbound connections at any point during that time, it does not query any seeds.
## Hardcoded Masternode IPs
-Dash Core also includes a hardcoded list of IP addresses and port numbers to several dozen nodes which were active around the time that particular version of the software was first released. Starting with Dash Core 0.12.3, [masternodes](../resources/glossary.md#masternode) are used for the seed list since they must remain online to receive their portion of the block reward (good availability) and must be compliant with [consensus rules](../resources/glossary.md#consensus-rules) (reliable). Dash Core will start attempting to connect to these nodes if none of the DNS seed servers have responded to a query within 60 seconds, providing an automatic fallback option.
+Dash Core also includes a hardcoded list of IP addresses and port numbers to a few hundred nodes which were active around the time that particular version of the software was first released. Starting with Dash Core 0.12.3, [masternodes](../resources/glossary.md#masternode) are used for the seed list since they must remain online to receive their portion of the block reward (good availability) and must be compliant with [consensus rules](../resources/glossary.md#consensus-rules) (reliable). Dash Core will start attempting to connect to these nodes if none of the DNS seed servers have responded to a query within 60 seconds, providing an automatic fallback option.
As a manual fallback option, Dash Core also provides several command-line connection options, including the ability to get a list of peers from a specific node by IP address, or to make a persistent connection to a specific node by IP address. See the `-help` text for details.
diff --git a/docs/core/guide/p2p-network-transaction-broadcasting.md b/docs/core/guide/p2p-network-transaction-broadcasting.md
index 61e017ec9..aeccbbcd1 100644
--- a/docs/core/guide/p2p-network-transaction-broadcasting.md
+++ b/docs/core/guide/p2p-network-transaction-broadcasting.md
@@ -8,6 +8,10 @@
In order to send a [transaction](../resources/glossary.md#transaction) to a [peer](../resources/glossary.md#peer), an [`inv` message](../reference/p2p-network-data-messages.md#inv) is sent. If a [`getdata` message](../reference/p2p-network-data-messages.md#getdata) is received in reply, the transaction is sent using a [`tx` message](../reference/p2p-network-data-messages.md#tx). If it is a valid transaction, the peer receiving the transaction also forwards the transaction to its peers.
+:::{note}
+As of Dash Core 24.0.0, version 2 asset unlock transactions (valid once the v24 hard fork activates) are announced to peers with protocol version 70242 or higher using the `MSG_ASSET_UNLOCK` [inventory](../reference/p2p-network-data-messages.md#inv) type, which identifies the transaction by its instance hash instead of its TXID. This allows a re-signed asset unlock to propagate even if a transaction with the same TXID is already in the mempool.
+:::
+
:::{note}
Dash Core 18.1.0 backported changes from Bitcoin to support block-only relay connections (specific connections that do not relay transaction information). This change was made to improve network topology and reduce information leaked by transaction relay. See the [Bitcoin pull request](https://github.com/bitcoin/bitcoin/pull/15759) for additional details.
:::
diff --git a/docs/core/reference/p2p-network-control-messages.md b/docs/core/reference/p2p-network-control-messages.md
index a0bed5aaa..634937956 100644
--- a/docs/core/reference/p2p-network-control-messages.md
+++ b/docs/core/reference/p2p-network-control-messages.md
@@ -267,6 +267,8 @@ There is no payload in a [`getaddr` message](../reference/p2p-network-control-me
The [`getsporks` message](../reference/p2p-network-control-messages.md#getsporks) requests [`spork` messages](../reference/p2p-network-control-messages.md#spork) from the receiving node.
+As of Dash Core 24.0.0, nodes no longer send `getsporks` messages during masternode sync (see the [`spork` message](../reference/p2p-network-control-messages.md#spork) for how sporks are shared on test networks instead). Nodes still respond to `getsporks` messages from older peers, but ignore repeated requests from a peer while their set of active sporks is unchanged.
+
There is no payload in a [`getsporks` message](../reference/p2p-network-control-messages.md#getsporks). See the [message header section](../reference/p2p-network-message-headers.md) for an example of a message without a payload.
## ping
@@ -367,6 +369,8 @@ Sporks are a mechanism by which updated code is released to test networks, but n
A [`spork` message](../reference/p2p-network-control-messages.md#spork) may be sent in response to a [`getsporks` message](../reference/p2p-network-control-messages.md#getsporks).
+As of Dash Core 24.0.0, on test networks (testnet, devnets, and regtest), a node announces each of its active sporks to a new peer with an [`inv` message](../reference/p2p-network-data-messages.md#inv) (`MSG_SPORK`) once the handshake completes. The peer then requests any sporks it does not have with a [`getdata` message](../reference/p2p-network-data-messages.md#getdata).
+
The [`spork` message](../reference/p2p-network-control-messages.md#spork) tells the receiving peer the status of the spork defined by the SporkID field. Upon receiving a [spork](../resources/glossary.md#spork) message, the client must verify the [signature](../resources/glossary.md#signature) before accepting the spork message as valid.
| Bytes | Name | Data type | Required | Description |
@@ -374,7 +378,7 @@ The [`spork` message](../reference/p2p-network-control-messages.md#spork) tells
| 4 | nSporkID | int | Required | ID assigned in spork.h
| 8 | nValue | int64_t | Required | Value assigned to spork
Default (disabled): `4000000000`
| 8 | nTimeSigned | int64_t | Required | Time the spork value was signed
-| 66 | vchSig | char[] | Required | Length (1 byte) + Signature (65 bytes)
+| 66 | vchSig | char[] | Required | Length (1 byte) + Signature (65 bytes)
As of Dash Core 23.1.8, spork messages with a signature longer than 65 bytes are rejected
The following annotated hexdump shows a [`spork` message](../reference/p2p-network-control-messages.md#spork).
@@ -405,8 +409,6 @@ sporks section](#removed-sporks) for a list of previously removed sporks.
| Spork ID | Num. | Name | Description |
| :----------: | :----------: | ----------- | ----------- |
| 10001 | 2 | `INSTANTSEND_ENABLED` | *Updated in Dash Core 0.17.0*
Turns InstantSend on and off network wide. Also determines if new mempool transactions should be locked or not.
-| 10002 | 3 | `INSTANTSEND_BLOCK_`
`FILTERING` | Turns on and off InstantSend block filtering
-| 10008 | 9 | `SUPERBLOCKS_ENABLED` | Superblocks are enabled (20% of the block subsidy is allocated to the Dash treasury for funding approved proposals)
| 10016 | 17 | `SPORK_17_QUORUM_DKG_`
`ENABLED` | Enable long-living masternode quorum (LLMQ) distributed key generation (DKG). When enabled, simple PoSe scoring and banning is active as well.
| 10018 | 19 | `SPORK_19_CHAINLOCKS_`
`ENABLED` | ***Updated in Dash Core 19.2.0***
Enable LLMQ-based ChainLocks.
| 10020 | 21 | `SPORK_21_QUORUM_ALL_`
`CONNECTED` | *Added in Dash Core 0.16.0*
Enable connections between all masternodes in a quorum to optimize the signature recovery process.
Note: Prior to Dash Core 0.17.0 this spork also enforced [PoSe requirements](../guide/dash-features-proof-of-service.md#distributed-key-generation-participation-requirements) for masternodes to support a minimum protocol version and maintain open ports.
@@ -447,21 +449,27 @@ The following sporks were used in the past but are no longer necessary and have
| :----------: | :----------: | ----------- | ----------- |
| *10005* | *6* | `NEW_SIGS` | _Removed in Dash Core 0.16.0.
Turns on and off new signature format for Dash-specific messages.
Never enabled on mainnet. The associated logic was hardened in [PR 3662](https://github.com/dashpay/dash/pull/3662) to support testnet (where it is enabled). If testnet is reset at some point in the future, the remaining logic will be removed._
| *10021* | *22* | `SPORK_22_PS_MORE_`
`PARTICIPANTS` | *Removed in Dash Core 0.17.0*
*Increase the maximum number of participants in CoinJoin sessions.*
+| *10002* | *3* | `INSTANTSEND_BLOCK_`
`FILTERING` | **Removed in Dash Core 24.0.0**
Turns on and off InstantSend block filtering. The associated functionality is now always enabled.
+| *10008* | *9* | `SUPERBLOCKS_ENABLED` | **Removed in Dash Core 24.0.0**
Superblocks are enabled (20% of the block subsidy is allocated to the Dash treasury for funding approved proposals). Superblocks are now always enabled.
| *10023* | *24* | `SPORK_24_TEST_EHF` | **Removed in Dash Core 22.0.0** (*Testnet/Devnet/Regtest only*)
Enables quorums to sign and broadcast the `mnhfsignal` message that allows the fork to proceed
### Spork verification
-To verify `vchSig`, compare the hard-coded spork public key (`strSporkPubKey` from [`src/chainparams.cpp`](https://github.com/dashpay/dash/blob/eaf90b77177efbaf9cbed46e822f0d794f1a0ee5/src/chainparams.cpp#L158)) with the public key recovered from the [`spork` message](../reference/p2p-network-control-messages.md#spork)'s hash and `vchSig` value (implementation details for Dash Core can be found in `CPubKey::RecoverCompact`). The hash is a double SHA-256 hash of:
+To verify `vchSig`, recover the public key from the [`spork` message](../reference/p2p-network-control-messages.md#spork)'s signature hash and `vchSig` value (implementation details for Dash Core can be found in `CPubKey::RecoverCompact`) and compare its key ID with the hard-coded spork address (`strSporkAddress` from [`src/chainparams.cpp`](https://github.com/dashpay/dash/blob/v24.0.0/src/chainparams.cpp#L304)). As of Dash Core 24.0.0, each network has a single spork address; support for multiple spork signers (the `-minsporkkeys` option) has been removed.
-* The spork magic message (`"DarkCoin Signed Message:\n"`)
-* nSporkID + nValue + nTimeSigned
+The signature hash is a double SHA-256 hash of:
-| Network | Spork Pubkey (wrapped) |
+* Testnet: the serialized nSporkID, nValue, and nTimeSigned fields
+* All other networks: the spork magic message (`"DarkCoin Signed Message:\n"`) followed by a string containing the decimal values of nSporkID, nValue, and nTimeSigned concatenated together (the same format used for signed messages)
+
+| Network | Spork Address |
| ---------- | ---------- |
-| Mainnet | 04549ac134f694c0243f503e8c8a9a986f5de6610049c40b07816809b0d1
d06a21b07be27b9bb555931773f62ba6cf35a25fd52f694d4e1106ccd237
a7bb899fdd |
-| Testnet3 | 046f78dcf911fbd61910136f7f0f8d90578f68d0b3ac973b5040fb7afb50
1b5939f39b108b0569dca71488f5bbf498d92e4d1194f6f941307ffd95f7
5e76869f0e |
-| RegTest | Undefined |
-| Devnets | 046f78dcf911fbd61910136f7f0f8d90578f68d0b3ac973b5040fb7afb50
1b5939f39b108b0569dca71488f5bbf498d92e4d1194f6f941307ffd95f7
5e76869f0e |
+| Mainnet | Xgtyuk76vhuFW2iT7UAiHgNdWXCf3J34wh |
+| Testnet3 | yjPtiKh2uwk3bDutTEA2q9mCtXyiZRWn55 |
+| RegTest | yj949n1UH6fDhw6HtVE5VMj2iSTaSWBMcW |
+| Devnets | yjPtiKh2uwk3bDutTEA2q9mCtXyiZRWn55 |
+
+The `-sporkaddr` option can override the spork address; it is only intended for use on RegTest and Devnets.
## verack
@@ -490,7 +498,7 @@ Protocol version 70214 added a [masternode](../resources/glossary.md#masternode)
| *Varies* | user_agent bytes | compactSize uint | Required | Number of bytes in following user\_agent field. If 0x00, no user agent field is sent.
| *Varies* | user_agent | string | Required if user_agent bytes > 0 | *Renamed in protocol version 60000.*
User agent as defined by BIP14. Previously called subVer.
Dash Core limits the length to 256 characters.
| 4 | start_height | int32_t | Required | The height of the transmitting node's best block chain or, in the case of an SPV client, best block header chain.
-| 1 | relay | bool | Optional | *Added in protocol version 70001 as described by BIP37.*
Transaction relay flag. If 0x00, no [`inv` messages](../reference/p2p-network-data-messages.md#inv) or [`tx` messages](../reference/p2p-network-data-messages.md#tx) announcing new transactions should be sent to this client until it sends a [`filterload` message](../reference/p2p-network-control-messages.md#filterload) or [`filterclear` message](../reference/p2p-network-control-messages.md#filterclear). If the relay field is not present or is set to 0x01, this node wants [`inv` messages](../reference/p2p-network-data-messages.md#inv) and [`tx` messages](../reference/p2p-network-data-messages.md#tx) announcing new transactions.
+| 1 | relay | bool | Optional | *Added in protocol version 70001 as described by BIP37.*
Transaction relay flag. If 0x00, no [`inv` messages](../reference/p2p-network-data-messages.md#inv) or [`tx` messages](../reference/p2p-network-data-messages.md#tx) announcing new transactions should be sent to this client until it sends a [`filterload` message](../reference/p2p-network-control-messages.md#filterload) or [`filterclear` message](../reference/p2p-network-control-messages.md#filterclear). If the relay field is not present or is set to 0x01, this node wants [`inv` messages](../reference/p2p-network-data-messages.md#inv) and [`tx` messages](../reference/p2p-network-data-messages.md#tx) announcing new transactions.
As of Dash Core 24.0.0, masternodes must set this flag to 0x01. During [DKG](../guide/dash-features-proof-of-service.md#distributed-key-generation-participation-requirements), quorum members flag a masternode as having a bad connection if none of their masternode connections to it set this flag. _Enforcement of this requirement is dependent on Spork 23 being enabled_
| 32 | mnauth_
challenge | uint256 | Optional | *Added in protocol version 70214*
A challenge to be signed by the receiving masternode. The response is returned via a [`mnauth` message](../reference/p2p-network-masternode-messages.md#mnauth) following the [`verack` message](../reference/p2p-network-control-messages.md#verack).
| 1 | mn_connection | bool | Optional | If 0x00, the connection is from a non-masternode. If 0x01, the connection is from a masternode.
@@ -503,7 +511,7 @@ The following service identifiers have been assigned.
| 0x02 | `NODE_GETUTXO` | **Removed in Dash Core 20.0.0**
This node is capable of responding to the getutxo protocol request.
| 0x04 | `NODE_BLOOM` | This node is capable and willing to handle bloom-filtered connections. Dash Core nodes used to support this by default, without advertising this bit, but no longer do as of protocol version 70201 (= NO_BLOOM_VERSION)
| 0x08 | `NODE_XTHIN` | **Dash Core does not support this service**
This node supports Xtreme Thinblocks.
-| 0x40 | `NODE_COMPACT_FILTERS` | This node supports basic block filter requests. See [BIP157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) and [BIP158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki) for details on how this is implemented.
+| 0x40 | `NODE_COMPACT_FILTERS` | This node supports basic block filter requests. See [BIP157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) and [BIP158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki) for details on how this is implemented.
As of Dash Core 24.0.0, masternodes must advertise this service. During [DKG](../guide/dash-features-proof-of-service.md#distributed-key-generation-participation-requirements), quorum members flag a masternode as having a bad connection if none of their masternode connections to it advertise this service. _Enforcement of this requirement is dependent on Spork 23 being enabled_
| 0x400 | `NODE_NETWORK_LIMITED` | This is the same as `NODE_NETWORK` with the limitation of only serving the last 288 blocks. See [BIP159](https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki) for details on how this is implemented. *Not supported prior to Dash Core 0.16.0*
| 0x800 | `NODE_HEADERS_COMPRESSED` | This node supports compressed headers as described in [DIP-25](https://github.com/dashpay/dips/blob/master/dip-0025.md)
| 0x1000 | `NODE_P2P_V2` | This node supports the version 2 of the peer-to-peer protocol, which provides an encrypted transport protocol. See [BIP-324](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki) for details. *Not supported prior to Dash Core 22.0.0*
diff --git a/docs/core/reference/p2p-network-data-messages.md b/docs/core/reference/p2p-network-data-messages.md
index 59c535f54..255c238d7 100644
--- a/docs/core/reference/p2p-network-data-messages.md
+++ b/docs/core/reference/p2p-network-data-messages.md
@@ -21,7 +21,7 @@ The currently-available type identifiers are:
| Type Identifier | Name | Description
|-----------------|---------------------------------|------------
-| 1 | MSG_TX | The hash is a TXID.
+| 1 | MSG_TX | The hash is a TXID.
**Note**: As of Dash Core 24.0.0, `MSG_TX` is also used to announce CoinJoin broadcast transactions that are unbalanced or oversized to peers below protocol version 70241 (instead of `MSG_DSTX`), and version 2 asset unlock transactions to peers below protocol version 70242 (instead of `MSG_ASSET_UNLOCK`).
| 2 | MSG_BLOCK | The hash is of a block header.
| 3 | MSG_FILTERED_BLOCK | The hash is of a block header; identical to `MSG_BLOCK`. When used in a [`getdata` message](../reference/p2p-network-data-messages.md#getdata), this indicates the response should be a [`merkleblock` message](../reference/p2p-network-data-messages.md#merkleblock) rather than a [`block` message](../reference/p2p-network-data-messages.md#block) (but this only works if a bloom filter was previously configured). **Only for use in [`getdata` messages](../reference/p2p-network-data-messages.md#getdata).**
| 6 | MSG_SPORK | The hash is Spork ID.
@@ -38,6 +38,8 @@ The currently-available type identifiers are:
| 29 | MSG_CLSIG | The hash is a ChainLock signature.
_Added in 0.14.0_
| 31 | MSG_ISDLOCK | The hash is an LLMQ-based deterministic InstantSend lock ([DIP22](https://github.com/dashpay/dips/blob/master/dip-0022.md)).
_Added in 18.0_
| 32 | MSG_DSQ | The hash of a CoinJoin [dsq message](./p2p-network-privatesend-messages.md#dsq).
**Added in 22.0.0**
+| 33 | MSG_PLATFORM_BAN | The hash of a [`platformban` message](../reference/p2p-network-masternode-messages.md#platformban), excluding its signature.
_Added in 23.0.0_
+| 34 | MSG_ASSET_UNLOCK | The hash is the instance hash (the hash of the full serialization, including the quorum signing info) of a version 2 asset unlock transaction. A [`getdata` message](../reference/p2p-network-data-messages.md#getdata) for this type is answered with a [`tx` message](../reference/p2p-network-data-messages.md#tx). Only announced to peers with protocol version 70242 or higher; older peers receive a `MSG_TX` inventory with the TXID instead.
_Added in 24.0.0_
**Deprecated Type Identifiers**
@@ -206,7 +208,7 @@ The [`cmpctblock` message](../reference/p2p-network-data-messages.md#cmpctblock)
Short transaction IDs are used to represent a transaction without sending a full 256-bit hash. They are calculated as follows,
* A single-SHA256 hashing the [block header](../resources/glossary.md#block-header) with the nonce appended (in little-endian)
-* Running SipHash-2-4 with the input being the transaction ID and the keys (k0/k1) set to the first two little-endian 64-bit integers from the above hash, respectively.
+* Running SipHash-2-4 with the input being the transaction ID (as of Dash Core 24.0.0, the transaction's instance hash, which equals the transaction ID for all transactions except version 2 asset unlock transactions) and the keys (k0/k1) set to the first two little-endian 64-bit integers from the above hash, respectively.
* Dropping the 2 most significant bytes from the SipHash output to make it 6 bytes.
The following annotated hexdump shows a [`cmpctblock` message](../reference/p2p-network-data-messages.md#cmpctblock). (The message header has been omitted.)
@@ -359,7 +361,7 @@ The [`getcfilters` message](../reference/p2p-network-data-messages.md#getcfilter
The [`getdata` message](../reference/p2p-network-data-messages.md#getdata) requests one or more data objects from another [node](../resources/glossary.md#node). The objects are requested by an inventory, which the requesting node typically previously received by way of an [`inv` message](../reference/p2p-network-data-messages.md#inv).
-The response to a [`getdata` message](../reference/p2p-network-data-messages.md#getdata) can be a [`tx` message](../reference/p2p-network-data-messages.md#tx), [`block` message](../reference/p2p-network-data-messages.md#block), [`merkleblock` message](../reference/p2p-network-data-messages.md#merkleblock), [`dstx` message](../reference/p2p-network-privatesend-messages.md#dstx), [`govobj` message](../reference/p2p-network-governance-messages.md#govobj), [`govobjvote` message](../reference/p2p-network-governance-messages.md#govobjvote), [`notfound` message](../reference/p2p-network-data-messages.md#notfound), [`cmpctblock` message](../reference/p2p-network-data-messages.md#cmpctblock), or any other messages that are exchanged by way of [`inv` messages](../reference/p2p-network-data-messages.md#inv).
+The response to a [`getdata` message](../reference/p2p-network-data-messages.md#getdata) can be a [`tx` message](../reference/p2p-network-data-messages.md#tx), [`block` message](../reference/p2p-network-data-messages.md#block), [`merkleblock` message](../reference/p2p-network-data-messages.md#merkleblock), [`dstx` message](../reference/p2p-network-privatesend-messages.md#dstx), [`govobj` message](../reference/p2p-network-governance-messages.md#govobj), [`govobjvote` message](../reference/p2p-network-governance-messages.md#govobjvote), [`platformban` message](../reference/p2p-network-masternode-messages.md#platformban), [`notfound` message](../reference/p2p-network-data-messages.md#notfound), [`cmpctblock` message](../reference/p2p-network-data-messages.md#cmpctblock), or any other messages that are exchanged by way of [`inv` messages](../reference/p2p-network-data-messages.md#inv). As of protocol version 70242, a request for a `MSG_ASSET_UNLOCK` inventory is answered with a [`tx` message](../reference/p2p-network-data-messages.md#tx).
This message cannot be used to request arbitrary data, such as historic transactions no longer in the memory pool or relay set. Full nodes may not even be able to provide older [blocks](../resources/glossary.md#block) if they've pruned old transactions from their block database. For this reason, the [`getdata` message](../reference/p2p-network-data-messages.md#getdata) should usually only be used to request data from a node which previously advertised it had that data by sending an [`inv` message](../reference/p2p-network-data-messages.md#inv).
@@ -402,6 +404,8 @@ The [`getmnlistd` message](../reference/p2p-network-data-messages.md#getmnlistd)
1. A full [masternode](../resources/glossary.md#masternode) list (if `baseBlockHash` is all-zero)
2. An update to a previously requested masternode list
+As of Dash Core 24.0.0, a node that cannot build the response because the required block data is unavailable (for example, a pruned node) ignores the request.
+
| Bytes | Name | Data type | Required | Description |
| ---------- | ----------- | --------- | -------- | -------- |
| 32 | baseBlockHash | uint256 | Required | Hash of a block the requester already has a valid masternode list of.
_Note: Can be all-zero to indicate that a full masternode list is requested._
@@ -421,12 +425,12 @@ db3fe368976296fd3b6d73fdaf898cc0 ........... Block hash
_Added in protocol version 70222 of Dash Core._
-The `getqrinfo` message requests a [`qrinfo` message](../reference/p2p-network-data-messages.md#qrinfo) that provides the information required to verify quorum details for quorums formed using the quorum rotation process.
+The `getqrinfo` message requests a [`qrinfo` message](../reference/p2p-network-data-messages.md#qrinfo) that provides the information required to verify quorum details for quorums formed using the quorum rotation process. As of Dash Core 24.0.0, a node that cannot build the response because the required block data is unavailable (for example, a pruned node) ignores the request.
| Bytes | Name | Data type | Required | Description
| ---------- | ----------- | --------- | -------- | --------
| Varies | baseBlockHashesNb | compactSize uint | Required | Number of masternode lists the light client already knows
-| Varies | baseBlockHashes | uint256[] | Required | Array of base block hashes for the masternode lists the light client already knows
+| Varies | baseBlockHashes | uint256[] | Required | Array of base block hashes for the masternode lists the light client already knows
As of Dash Core 24.0.0, requests with more than 4096 base block hashes are rejected
| 32 | blockRequestHash | uint256 | Required | Hash of the block for which the masternode list diff is requested
| 1 | extraShare | bool | Optional | Flag to indicate if an extra share is requested
@@ -987,8 +991,10 @@ Last quorum hash per index
The [`tx` message](../reference/p2p-network-data-messages.md#tx) transmits a single transaction in the [raw transaction](../resources/glossary.md#raw-transaction) format. It can be sent in a variety of situations;
-* **Transaction Response:** Dash Core will send it in response to a [`getdata` message](../reference/p2p-network-data-messages.md#getdata) that requests the transaction with an [inventory](../resources/glossary.md#inventory) type of `MSG_TX`.
+* **Transaction Response:** Dash Core will send it in response to a [`getdata` message](../reference/p2p-network-data-messages.md#getdata) that requests the transaction with an [inventory](../resources/glossary.md#inventory) type of `MSG_TX`, or `MSG_ASSET_UNLOCK` as of protocol version 70242.
* **MerkleBlock Response:** Dash Core will send it in response to a [`getdata` message](../reference/p2p-network-data-messages.md#getdata) that requests a [merkle block](../resources/glossary.md#merkle-block) with an [inventory](../resources/glossary.md#inventory) type of `MSG_MERKLEBLOCK`. (This is in addition to sending a [`merkleblock` message](../reference/p2p-network-data-messages.md#merkleblock).) Each [`tx` message](../reference/p2p-network-data-messages.md#tx) in this case provides a matched transaction from that [block](../resources/glossary.md#block).
+As of Dash Core 24.0.0, the TXID of a version 2 asset unlock transaction (an asset unlock with payload version 2) is calculated with the quorum signing info (requested height, quorum hash, and quorum signature) zeroed out, so it stays the same when Platform re-signs the withdrawal. The hash of the full serialization is the transaction's instance hash, which is used for `MSG_ASSET_UNLOCK` inventories.
+
For an example hexdump of the raw transaction format, see the [raw transaction section](../reference/transactions-raw-transaction-format.md).
diff --git a/docs/core/reference/p2p-network-governance-messages.md b/docs/core/reference/p2p-network-governance-messages.md
index 0356c8a22..61c6a5e38 100644
--- a/docs/core/reference/p2p-network-governance-messages.md
+++ b/docs/core/reference/p2p-network-governance-messages.md
@@ -25,7 +25,7 @@ The [`govobj` message](../reference/p2p-network-governance-messages.md#govobj) c
| 0-16384 | strData | string | Required | Data field - can be used for anything (leading varint indicates size of data)
| 4 | nObjectType | int | Required | Type of governance object:
• `0` - Unknown
• `1` - Proposal
• `2` - Trigger
| 36 | masternode
OutPoint | outPoint | Required* | The unspent outpoint of the masternode (holding 1000 DASH) which is signing this object.
Set to all zeros for proposals since they can be created by non-masternodes.
-| 97 | vchSig | char | Required* | BLS Signature of the masternode (Length (1 byte) + Signature (96 bytes))
**Note**: serialized using the basic BLS scheme after Dash 19.0 activation
Not required for proposals - they will have a length of 0x00 and no Signature.
+| 97 | vchSig | char | Required* | BLS Signature of the masternode (Length (1 byte) + Signature (96 bytes))
**Note**: serialized using the basic BLS scheme after Dash 19.0 activation
Not required for proposals - they will have a length of 0x00 and no Signature.
As of Dash Core 24.0.0, objects with a signature longer than 96 bytes are rejected.
Governance Object Types (defined by `src/governance-object.h`)
@@ -117,7 +117,7 @@ the node being banned.
| 4 | nVoteOutcome | int | Required | None (0), Yes (1), No (2), Abstain (3)
| 4 | nVoteSignal | int | Required | None (0), Funding (1), Valid (2), Delete (3), Endorsed (4)
| 8 | nTime | int64_t | Required | Time the vote was created
-| 97 | vchSig | char[] | Required | BLS Signature of the masternode (Length (1 byte) + Signature (96 bytes))
**Note**: serialized using the basic BLS scheme after Dash 19.0 activation
+| 66 or 97 | vchSig | char[] | Required | Signature of the masternode (Length (1 byte) + Signature). One of:
• 65-byte compact ECDSA signature by the masternode's voting key (`Funding` votes on proposals)
• 96-byte BLS signature by the masternode's operator key (other votes)
**Note**: BLS signatures are serialized using the basic BLS scheme after Dash 19.0 activation
As of Dash Core 23.1.8, votes with a signature of any other length are rejected.
Governance Object Vote Signals (defined by `src/governance-object.h`)
@@ -157,15 +157,21 @@ The [`govsync` message](../reference/p2p-network-governance-messages.md#govsync)
This message responds in one of two ways depending on the request:
-1. Object Sync - When a masternode receives a [`govsync` message](../reference/p2p-network-governance-messages.md#govsync) with a hash of all zeros, it responds with a [`ssc` message](../reference/p2p-network-masternode-messages.md#ssc) for `govobj` objects. The masternode also sends an [`inv` message](../reference/p2p-network-data-messages.md#inv) (MSG_GOVERNANCE_OBJECT - 0x17) for all valid `govobj` governance objects. Do note that Dash limits how frequently object sync can be requested. Frequent requests will result in the node being banned.
+1. Object Sync - When a masternode receives a [`govsync` message](../reference/p2p-network-governance-messages.md#govsync) with a hash of all zeros, it responds with a [`ssc` message](../reference/p2p-network-masternode-messages.md#ssc) for `govobj` objects. The masternode also sends an [`inv` message](../reference/p2p-network-data-messages.md#inv) (MSG_GOVERNANCE_OBJECT - 0x11) for all valid `govobj` governance objects. Do note that Dash limits how frequently object sync can be requested. Frequent requests will result in the node being banned.
*Governance object votes are excluded in this type of response.*
-2. Vote Sync - When a masternode receives a [`govsync` message](../reference/p2p-network-governance-messages.md#govsync) with a specific hash, it responds with an [`ssc` message](../reference/p2p-network-masternode-messages.md#ssc) for `govobjvote` objects. The masternode also sends a `govobjvote` inventory messages (MSG_GOVERNANCE_OBJECT_VOTE - 0x18) for the object requested.
+2. Vote Sync - When a masternode receives a [`govsync` message](../reference/p2p-network-governance-messages.md#govsync) with a specific hash, it responds with an [`ssc` message](../reference/p2p-network-masternode-messages.md#ssc) for `govobjvote` objects. The masternode also sends a `govobjvote` inventory messages (MSG_GOVERNANCE_OBJECT_VOTE - 0x12) for the object requested.
+
+:::{note}
+As of Dash Core 23.1.8, a [`govsync` message](../reference/p2p-network-governance-messages.md#govsync) with a specific hash and an empty bloom filter is treated as a request for the governance object itself rather than a vote sync. The node replies only with an [`inv` message](../reference/p2p-network-data-messages.md#inv) (MSG_GOVERNANCE_OBJECT - 0x11) for that object, and only if it has the object. No [`ssc` message](../reference/p2p-network-masternode-messages.md#ssc) or vote inventory is sent. Dash Core uses this to request the parent objects of orphan votes.
+
+Vote sync therefore requires a bloom filter whose data is not zero-length. Vote sync requests for the same object are also rate limited per peer. Frequent requests increase the requesting peer's misbehavior score.
+:::
| Bytes | Name | Data type | Required | Description |
| ---------- | ----------- | --------- | -------- | -------- |
| 32 | nHash | uint256 | Required | Hash of governance object to request
Set to all zeros to request all objects (excludes votes)
-| # | filter | CBloomFilter | Required | Can be set to all zeros.
Only supported since [protocol version 70206](../reference/p2p-network-protocol-versions.md)
+| # | filter | CBloomFilter | Required | Bloom filter of votes the requesting node already has. Can be set to all zeros (empty filter) for object sync.
As of Dash Core 23.1.8, an empty filter combined with a specific hash requests only the governance object (no votes).
Only supported since [protocol version 70206](../reference/p2p-network-protocol-versions.md)
The following annotated hexdump shows a [`govsync` message](../reference/p2p-network-governance-messages.md#govsync). (The message header has been omitted.)
diff --git a/docs/core/reference/p2p-network-instantsend-messages.md b/docs/core/reference/p2p-network-instantsend-messages.md
index bd8190c25..262662da0 100644
--- a/docs/core/reference/p2p-network-instantsend-messages.md
+++ b/docs/core/reference/p2p-network-instantsend-messages.md
@@ -16,6 +16,8 @@ The [`clsig` message](../reference/p2p-network-instantsend-messages.md#clsig) is
Once a [`clsig` message](../reference/p2p-network-instantsend-messages.md#clsig) is received, clients must reject any other blocks for the indicated block height as described in [DIP8 (ChainLocks)](https://github.com/dashpay/dips/blob/master/dip-0008.md). This increases security by preventing reorganization of a block with a ChainLock (and all blocks below it).
+As of Dash Core 24.0.0, a `clsig` message is only accepted if the node requested it from the sending peer via a [`getdata` message](../reference/p2p-network-data-messages.md#getdata); unrequested messages are ignored and the sending peer is treated as misbehaving. Also as of Dash Core 24.0.0, synced nodes recover ChainLocks from the ChainLock signature embedded in the coinbase transaction of newly connected blocks (after v20 activation) and relay them like any other new ChainLock, even if the original `clsig` message was missed.
+
| Bytes | Name | Data type | Description |
| --- | --- | --- | --- |
| 4 | nHeight | int32_t | Block height
@@ -52,10 +54,14 @@ The [`isdlock` message](../reference/p2p-network-instantsend-messages.md#isdlock
The request ID for an isdlock can be calculated deterministically using the formula: `hash("islock" + serialized_inputs)`, where "islock" is a string prefix and the inputs are serialized in their COutPoint format. This ID is used for quorum signature verification and can be obtained via the [`getislocks` RPC command](../api/remote-procedure-calls-raw-transactions.md#getislocks).
+As of Dash Core 24.0.0, version 2 asset unlock transactions can be locked by InstantSend. Since these transactions have no inputs, the `isdlock` carries a single synthetic outpoint consisting of the asset unlock's signing request ID (`hash("plwdtx" + withdrawal_index)`) and an index of `0`. This binds the withdrawal index to one TXID so any other transaction claiming the same index conflicts with the lock.
+
+Since Dash Core 23.1.3, `isdlock` inventory announcements are not sent to masternode peers that have requested recovered signatures via the [`qsendrecsigs` message](../reference/p2p-network-quorum-messages.md#qsendrecsigs), since they can reconstruct the `isdlock` from the recovered signature.
+
| Bytes | Name | Data type | Description |
| --- | --- | --- | --- |
| 1 | version | uint8 | The version of the isdlock message |
-| 1-9 | inputsSize | compactSize uint | Number of inputs |
+| 1-9 | inputsSize | compactSize uint | Number of inputs
As of Dash Core 23.1.7, limited to 48,780 (the maximum block size divided by 41, the minimum size of a transaction input) |
| 36 * `inputsSize`| inputs | COutPoint | Outpoints used in the transaction |
| 32 | txid | uint256 | TXID of the locked transaction |
| 32 | cycleHash | uint256 | Block hash of first block of the DKG cycle in which the quorum signing this isdlock is active.
**Note**: As of v23.0.0 (protocol 70237), this represents the signing quorum's cycle, not the current height's cycle |
diff --git a/docs/core/reference/p2p-network-masternode-messages.md b/docs/core/reference/p2p-network-masternode-messages.md
index da9258ce4..1345f13f2 100644
--- a/docs/core/reference/p2p-network-masternode-messages.md
+++ b/docs/core/reference/p2p-network-masternode-messages.md
@@ -49,6 +49,8 @@ As of protocol version 70218, when communicating with masternodes that have repo
This is primarily used as a DoS protection mechanism to allow persistent connections between masternodes to remain open even if inbound connection limits are reached.
+As of Dash Core 23.1.9, a node accepts at most 3 verified inbound connections per ProRegTx hash (`MAX_VERIFIED_INBOUND_PER_PROTX`). Additional inbound connections that authenticate with the same ProRegTx hash are disconnected.
+
| Bytes | Name | Data type | Description |
| --- | --- | --- | --- |
| 32 | proRegTxHash | uint256 | The hash of the ProRegTx that identifies the masternode
@@ -67,3 +69,25 @@ abffc96819c5030fd5a7601af9c8ee50
91e2a887f963904f33af851ddc9167d5
66d6d3bd6c07e99091edd8867d0dd56e ........... Masternode BLS Signature (96 bytes)
```
+
+## platformban
+
+*Added in protocol version 70238 of Dash Core*
+
+The [`platformban` message](../reference/p2p-network-masternode-messages.md#platformban) is used by Dash Platform to request a Proof of Service (PoSe) ban of an [EvoNode](../resources/glossary.md#evolution-masternode-evonode) as described in [DIP31](https://github.com/dashpay/dips/blob/master/dip-0031.md). Platform injects the message by sending it to a Dash Core node, which validates it and relays it to its peers. When quorum PoSe is enabled ([Spork 23](../reference/p2p-network-control-messages.md#spork)), masternodes that accept the message consider the targeted EvoNode to have a bad connection in subsequent DKG sessions until a ProUpServTx for that EvoNode is mined (for example, to revive it after a PoSe ban).
+
+A node only processes the message once its blockchain is synced. The message is accepted only if all of the following are true:
+
+* `protx_hash` identifies an EvoNode in the current masternode list
+* `requested_height` is no more than 576 blocks below the current chain tip and not above it
+* `quorum_hash` identifies an existing quorum of the network's Platform LLMQ type
+* `signature` is a valid threshold signature by that quorum, where the request ID is `hash("PlatformPoSeBan" + protx_hash + requested_height)` and the message hash is `hash(protx_hash + requested_height)`
+
+Valid messages are relayed using an [`inv` message](../reference/p2p-network-data-messages.md#inv) of type `MSG_PLATFORM_BAN` (33). The inventory hash is the hash of the message excluding the `signature` field. Peers request the message with a [`getdata` message](../reference/p2p-network-data-messages.md#getdata) and receive the `platformban` message in response. As of protocol version 70240, the message can use the BIP324 short message ID 168.
+
+| Bytes | Name | Data type | Required | Description |
+| ---------- | ----------- | --------- | -------- | -------- |
+| 32 | protx_hash | uint256 | Required | The ProRegTx hash of the EvoNode to ban
+| 4 | requested_height | int32_t | Required | Block height at which the ban was requested
+| 32 | quorum_hash | uint256 | Required | The hash of the Platform quorum that signed the message
+| 96 | signature | byte[] | Required | Platform quorum BLS signature
**Note**: serialized using the basic BLS scheme
diff --git a/docs/core/reference/p2p-network-message-headers.md b/docs/core/reference/p2p-network-message-headers.md
index c79797dbb..1ee3169e3 100644
--- a/docs/core/reference/p2p-network-message-headers.md
+++ b/docs/core/reference/p2p-network-message-headers.md
@@ -15,6 +15,10 @@ All messages in the network protocol use the same container format, which provid
| 4 | payload size | uint32_t | Number of bytes in payload. The current maximum number of bytes ([`MAX_SIZE`](https://github.com/dashpay/dash/blob/v0.15.x/src/serialize.h#L29)) allowed in the payload by Dash Core is 32 MiB---messages with a payload size larger than this will be dropped or rejected.
| 4 | checksum | char[4] | *Added in protocol version 209.*
First 4 bytes of SHA256(SHA256(payload)) in internal byte order.
If payload is empty, as in `verack` and [`getaddr` messages](../reference/p2p-network-control-messages.md#getaddr), the checksum is always 0x5df6e0e2 (SHA256(SHA256())).
+## BIP324 v2 transport
+
+Connections using the [BIP324](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki) v2 encrypted transport (supported since protocol version 70235 / Dash Core 22.0.0 and enabled by default since Dash Core 22.1.0) do not use the message header described above. Instead, each encrypted packet that carries a message begins its contents with the message type, encoded either as a 1-byte short ID or as a `0x00` byte followed by the 12-byte command name. Bitcoin messages use the short IDs 1–28 assigned by BIP324, and Dash-specific messages use short IDs 128–167 (see `V2_BITCOIN_IDS` and `V2_DASH_IDS` in [`src/net.cpp`](https://github.com/dashpay/dash/blob/v24.0.0/src/net.cpp#L906-L991) for the full mapping). As of protocol version 70240, the [`platformban` message](../reference/p2p-network-masternode-messages.md#platformban) uses short ID 168 when the negotiated protocol version is 70240 or higher; otherwise it is sent with the long (12-byte command name) encoding.
+
## Example
The following example is an annotated hex dump of a [mainnet](../resources/glossary.md#mainnet) message header from a [`verack` message](../reference/p2p-network-control-messages.md#verack) which has no payload.
diff --git a/docs/core/reference/p2p-network-privatesend-messages.md b/docs/core/reference/p2p-network-privatesend-messages.md
index 903f2b95c..4cd3fc4d5 100644
--- a/docs/core/reference/p2p-network-privatesend-messages.md
+++ b/docs/core/reference/p2p-network-privatesend-messages.md
@@ -22,10 +22,13 @@ The [`dsa` message](../reference/p2p-network-privatesend-messages.md#dsa) allows
Dash Core attempts to join an existing queue first and only requests a new one if no existing ones are available.
+As of protocol version 70241 (Dash Core 24.0.0), a participant can use the `nFlags` field to request a promotion or demotion session (see the [`dsi` message](#dsi)). Masternodes only accept promotion or demotion requests after the v24 hard fork activates and only from peers using protocol version 70241 or higher. Participants requesting promotion or demotion and participants using an older protocol version are never placed in the same session.
+
| Bytes | Name | Data type | Required | Description |
| ---------- | ----------- | --------- | -------- | -------- |
| 4 | nDenom | int | Required | Denomination that will be exclusively used when submitting inputs into the pool
| 216+ | txCollateral | [`tx` message](../reference/p2p-network-data-messages.md#tx) | Required | Collateral TX that will be charged if this client acts maliciously
+| 0 or 1 | nFlags | uint8_t | Required* | *Added in protocol version 70241 of Dash Core*
Only present when the negotiated protocol version is 70241 or higher. Declares the type of entry the participant intends to submit:
• Bit 0 (`0x01`) - Promotion
• Bit 1 (`0x02`) - Demotion
Setting both bits is invalid. A value of `0` indicates standard mixing.
The following annotated hexdump shows a [`dsa` message](../reference/p2p-network-privatesend-messages.md#dsa). (The message header has been omitted.) Note that the 'Required inputs' bytes will only be preset if [Spork](../resources/glossary.md#spork) 6 is active and protocol version => 70209.
@@ -74,6 +77,8 @@ d9070700 ............................. Session ID: 791686
The [`dsf` message](../reference/p2p-network-privatesend-messages.md#dsf) is sent by the masternode as the final transaction in a CoinJoin session. The [masternode](../resources/glossary.md#masternode) expects [nodes](../resources/glossary.md#node) in the session to respond with a [`dss` message](../reference/p2p-network-privatesend-messages.md#dss).
+Before the v24 hard fork activates, the final transaction must have an equal number of inputs and outputs (at most 180 each). After activation, sessions that include promotion or demotion entries can produce final transactions with unequal input and output counts. These transactions can have up to 200 inputs and 200 outputs, and neither count may exceed 10 times the other.
+
| Bytes | Name | Data type | Required | Description |
| ---------- | ----------- | --------- | -------- | -------- |
| 4 | nSessionID | int | Required | ID of the session
@@ -181,6 +186,12 @@ Transaction Message
The [`dsi` message](../reference/p2p-network-privatesend-messages.md#dsi) replies to a [`dsq` message](../reference/p2p-network-privatesend-messages.md#dsq) that has the Ready field set to 0x01. The [`dsi` message](../reference/p2p-network-privatesend-messages.md#dsi) contains user [inputs](../resources/glossary.md#input) for processing along with the [outputs](../resources/glossary.md#output) and a collateral. Once the [masternode](../resources/glossary.md#masternode) receives [`dsi` messages](../reference/p2p-network-privatesend-messages.md#dsi) from all members of the pool, it responds with a [`dsf` message](../reference/p2p-network-privatesend-messages.md#dsf).
+Each entry can contain at most 9 inputs and 9 outputs. After the v24 hard fork activates, sessions that include promotion or demotion participants (see the [`dsa` message](#dsa)) allow up to 10 inputs and 10 outputs per entry. Each entry must match the form declared by `nFlags` in the participant's `dsa` message; otherwise the masternode rejects it and consumes the participant's collateral. The permitted forms are:
+
+* Standard - N inputs of the session denomination and N outputs of the session denomination
+* Promotion - 10 inputs of the session denomination and 1 output of the next larger denomination
+* Demotion - 1 input of the next larger denomination and 10 outputs of the session denomination
+
| Bytes | Name | Data type | Required | Description |
| ---------- | ----------- | --------- | -------- | -------- |
| ? | vecTxDSIn | CTxDSIn[] | Required | Vector of users inputs (CTxDSIn serialization is equal to CTxIn serialization)
@@ -491,6 +502,8 @@ The following annotated hexdump shows a [`dssu` message](../reference/p2p-networ
The [`dstx` message](../reference/p2p-network-privatesend-messages.md#dstx) allows [masternodes](../resources/glossary.md#masternode) to broadcast subsidized transactions without fees (to provide security in processing).
+As of protocol version 70241 (Dash Core 24.0.0), a CoinJoin transaction that has unequal input and output counts (promotion/demotion) or more than 180 inputs is only announced as a `dstx` to peers using protocol version 70241 or higher. Peers using older protocol versions receive a plain transaction announcement instead. Since the transaction pays no fee and lacks the CoinJoin metadata, those peers may reject it under their normal relay fee rules until it is mined.
+
| Bytes | Name | Data type | Required | Description |
| ---------- | ----------- | --------- | -------- | -------- |
| # | tx | [`tx` message](../reference/p2p-network-data-messages.md#tx) | Required | The transaction
diff --git a/docs/core/reference/p2p-network-protocol-versions.md b/docs/core/reference/p2p-network-protocol-versions.md
index 45fdefcf7..1ade17390 100644
--- a/docs/core/reference/p2p-network-protocol-versions.md
+++ b/docs/core/reference/p2p-network-protocol-versions.md
@@ -10,10 +10,12 @@
The table below lists some notable versions of the P2P network protocol, with the most recent versions listed first.
-As of Dash Core 23.0.0, the most recent protocol version is 70238.
+As of Dash Core 24.0.0, the most recent protocol version is 70242.
| Version | Initial Release | Major Changes
|---------|------------------------------------|--------------
+| 70242 | [Dash Core 24.0.0](https://github.com/dashpay/dash/blob/v24.0.0/doc/release-notes.md)
(Nov 2026) | • [CoinJoin promotion/demotion](https://github.com/dashpay/dash/pull/7052) (protocol version 70241)
• [`MSG_ASSET_UNLOCK` inventory type](https://github.com/dashpay/dash/pull/7639) for version 2 asset unlock transactions
• [Removal of sporks 3 and 9](https://github.com/dashpay/dash/pull/7278)
• MIN_MASTERNODE_PROTO_VERSION set to 70242
+| 70240 | [Dash Core 23.1.0](https://github.com/dashpay/dash/blob/v23.1.0/doc/release-notes.md)
(Feb 2026) | • [Ban for re-propagation of stale `qfcommit` messages](https://github.com/dashpay/dash/pull/7079) (protocol version 70239)
• [BIP324 short ID for `platformban` message](https://github.com/dashpay/dash/pull/7082)
• MIN_MASTERNODE_PROTO_VERSION set to 70240
| 70238 | [Dash Core 23.0.0](https://github.com/dashpay/dash/blob/v23.0.0/doc/release-notes.md)
(Nov 2025) | • [Platform Proof-of-Service ban support](https://github.com/dashpay/dash/pull/6613)
• [Fix isdlock cycleHash](https://github.com/dashpay/dash/pull/6608)
• MIN_PEER_PROTO_VERSION set to 70221
| 70236 | [Dash Core 22.1.2](https://github.com/dashpay/dash/blob/v22.1.2/doc/release-notes.md)
(Apr 2025) | • [Optimized quorum diff processing](https://github.com/dashpay/dash/pull/6587)
• [Improved the performance of deterministic masternode list management](https://github.com/dashpay/dash/pull/6625)
| 70235 | [Dash Core 22.0](https://github.com/dashpay/dash/blob/v22.0.0/doc/release-notes.md)
(Nov 2024) | • [P2P protocol encryption (BIP 324)](https://github.com/dashpay/dash-issues/issues/7)
• [DSQ via inventory](https://github.com/dashpay/dash/pull/6148)
• [Support 8000 compressed headers per request](https://github.com/dashpay/dash/pull/6239/)
diff --git a/docs/core/reference/p2p-network-quorum-messages.md b/docs/core/reference/p2p-network-quorum-messages.md
index 8d6311cc9..ffe6a62cd 100644
--- a/docs/core/reference/p2p-network-quorum-messages.md
+++ b/docs/core/reference/p2p-network-quorum-messages.md
@@ -14,12 +14,18 @@ The following network messages enable the creation of long living masternode quo
With the exception of the [`qfcommit` message](../reference/p2p-network-quorum-messages.md#qfcommit), these messages are for intra-quorum communication only and are not propagated on the Dash network.
+:::{note}
+As of Dash Core 23.1.7, the [`qcontrib`](#qcontrib), [`qcomplaint`](#qcomplaint), [`qjustify`](#qjustify), and [`qpcommit`](#qpcommit) messages are only accepted from peers that have authenticated as a masternode via the [`mnauth` message](../reference/p2p-network-masternode-messages.md#mnauth), and messages that exceed the size or structure limits derived from the quorum parameters are rejected. As of Dash Core 24.0.0, these messages are also only accepted if the node requested them from the sending peer via a [`getdata` message](../reference/p2p-network-data-messages.md#getdata); unrequested messages are ignored and the sending peer is treated as misbehaving.
+
+As of Dash Core 24.0.0, nodes monitoring in Watch Mode that are not masternodes no longer request or process these four messages. See the [`qwatch` message](#qwatch) for details.
+:::
+
### qcontrib
*Added in protocol version 70214 of Dash Core*
:::{note}
-This message is used for intra-quorum communication and is only sent to the [masternodes](../resources/glossary.md#masternode) in the LLMQ and [nodes](../resources/glossary.md#node) that are monitoring in Watch Mode for auditing/debugging purposes.
+This message is used for intra-quorum communication and is only sent to the [masternodes](../resources/glossary.md#masternode) in the LLMQ and [nodes](../resources/glossary.md#node) that are monitoring in Watch Mode for auditing/debugging purposes. As of Dash Core 24.0.0, Watch Mode nodes that are not masternodes no longer request or process this message.
:::
The [`qcontrib` message](../reference/p2p-network-quorum-messages.md#qcontrib) is used by each member of the DKG process to send key contributions to all other members.
@@ -100,7 +106,7 @@ e000da1aeda5f98ec9e64b801681bfc1 ........... BLS signature (Operator Key)
*Added in protocol version 70214 of Dash Core*
:::{note}
-This message is used for intra-quorum communication and is only sent to the [masternodes](../resources/glossary.md#masternode) in the LLMQ and [nodes](../resources/glossary.md#node) that are monitoring in Watch Mode for auditing/debugging purposes.
+This message is used for intra-quorum communication and is only sent to the [masternodes](../resources/glossary.md#masternode) in the LLMQ and [nodes](../resources/glossary.md#node) that are monitoring in Watch Mode for auditing/debugging purposes. As of Dash Core 24.0.0, Watch Mode nodes that are not masternodes no longer request or process this message.
:::
The [`qcomplaint` message](../reference/p2p-network-quorum-messages.md#qcomplaint) is used to notify other members in the DKG process of any members that provided no contribution or an invalid secret key contribution. The notifications are divided into 2 fields:
@@ -239,6 +245,10 @@ This message is used for intra-quorum communication and is only sent to the [mas
The [`qgetdata` message](../reference/p2p-network-quorum-messages.md#qgetdata) is used to request DKG data from a masternode. The response to a `qgetdata` message is a [`qdata` message](../reference/p2p-network-quorum-messages.md#qdata). These messages allows an LLMQ member to recover its DKG data if needed with the help of other members of that LLMQ type.
+:::{note}
+As of Dash Core 24.0.0, a node tracks each received `qgetdata` request for about 5 minutes, whether or not it has been answered, and tracks at most 64 requests per requesting masternode (identified by its ProRegTx hash; all Watch Mode peers that are not masternodes share a single allowance) and at most 4096 requests in total. Requests beyond the per-masternode limit are dropped without a [`qdata` message](../reference/p2p-network-quorum-messages.md#qdata) reply and the sending masternode is treated as misbehaving. Requests beyond the shared Watch Mode allowance or the total limit are dropped without a reply. A `qgetdata` message with a payload larger than the fixed request size is rejected, and a request for an unknown `llmqType` is answered with a `QUORUM_TYPE_INVALID` error before the sending peer is treated as misbehaving.
+:::
+
| Bytes | Name | Data type | Description |
| --- | --- | --- | --- |
| 1 | llmqType | uint8_t | The type of LLMQ
@@ -265,7 +275,7 @@ c7ccb13df0c0e950b4d1b737808c2c72 ........... ProRegTx hash
*Added in protocol version 70214 of Dash Core*
:::{note}
-This message is used for intra-quorum communication and is only sent to the [masternodes](../resources/glossary.md#masternode) in the LLMQ and [nodes](../resources/glossary.md#node) that are monitoring in Watch Mode for auditing/debugging purposes.
+This message is used for intra-quorum communication and is only sent to the [masternodes](../resources/glossary.md#masternode) in the LLMQ and [nodes](../resources/glossary.md#node) that are monitoring in Watch Mode for auditing/debugging purposes. As of Dash Core 24.0.0, Watch Mode nodes that are not masternodes no longer request or process this message.
:::
The [`qjustify` message](../reference/p2p-network-quorum-messages.md#qjustify) is used to respond to complaints. This provides a way for [nodes](../resources/glossary.md#node) that have been complained about to offer proof of correct behavior. If a valid justification is not provided, all other nodes mark it as a bad. If a valid justification is provided, the complaining node is marked as bad instead (since it submitted a bad complaint).
@@ -328,7 +338,7 @@ Contribution #2
*Added in protocol version 70214 of Dash Core*
:::{note}
-This message is used for intra-quorum communication and is only sent to the [masternodes](../resources/glossary.md#masternode) in the LLMQ and [nodes](../resources/glossary.md#node) that are monitoring in Watch Mode for auditing/debugging purposes.
+This message is used for intra-quorum communication and is only sent to the [masternodes](../resources/glossary.md#masternode) in the LLMQ and [nodes](../resources/glossary.md#node) that are monitoring in Watch Mode for auditing/debugging purposes. As of Dash Core 24.0.0, Watch Mode nodes that are not masternodes no longer request or process this message.
:::
The [`qpcommit` message](../reference/p2p-network-quorum-messages.md#qpcommit) is used to exchange premature commitment messages for verification and selection of the final commitment.
@@ -389,6 +399,8 @@ The [`qfcommit` message](../reference/p2p-network-quorum-messages.md#qfcommit) i
It is possible to receive multiple valid final commitments for the same DKG session. These should only differ in the number of signers, which can be ignored as long as there are at least `quorumThreshold` number of signers. The set of valid members for these final commitments should always be the same, as each member only creates a single premature commitment. This means that only one set of valid members (and thus only one quorum verification vector and quorum [public key](../resources/glossary.md#public-key)) can gain a majority. If the threshold is not reached, there will be no valid final commitment.
+As of Dash Core 24.0.0, a `qfcommit` message is only accepted if the node requested it from the sending peer via a [`getdata` message](../reference/p2p-network-data-messages.md#getdata); unrequested messages are ignored and the sending peer is treated as misbehaving. As of protocol version 70239 (Dash Core 23.1.0), peers that relay a stale `qfcommit` message (one whose quorum base block is more than one DKG interval below the chain tip) are also treated as misbehaving.
+
:::{note}
* Version 2 (Dash Core 18.0) - updated the `qfcommit` message to support a [new method](https://github.com/dashpay/dips/blob/master/dip-0024.md) of quorum creation for some quorum types. Note the addition of the `quorumIndex` field in version 2 messages.
* Versions 3/4 (Dash Core 19.0) - `quorumPublicKey`, `quorumSig`, and `sig` serialized using the basic BLS scheme (versions <3 use the legacy BLS scheme).
@@ -581,14 +593,14 @@ This message is used for intra-quorum communication and is only sent to the [mas
The [`qgetsigs` message](../reference/p2p-network-quorum-messages.md#qgetsigs) is used to request signature shares. The response to a [`qgetsigs` message](../reference/p2p-network-quorum-messages.md#qgetsigs) is a [`qbsigs` message](../reference/p2p-network-quorum-messages.md#qbsigs).
:::{note}
-The number of inventories in a [`qgetsigs` message](../reference/p2p-network-quorum-messages.md#qgetsigs) is limited to 200 (as defined by `MAX_MSGS_CNT_QGETSIGSHARES` in Dash Core).
+The number of inventories in a [`qgetsigs` message](../reference/p2p-network-quorum-messages.md#qgetsigs) is limited to 200 (as defined by `MAX_MSGS_CNT_QSIGSHARES` in Dash Core).
:::
| Bytes | Name | Data type | Description |
| --- | --- | --- | --- |
| Varies | count | compactSize uint | Number of signature shares requested |
| Varies | sessionId | varint | Signing session ID
-| Varies | invSize | compactSize uint | Inventory size
+| Varies | invSize | compactSize uint | Inventory size (must equal the quorum size)
As of Dash Core 23.1.4, limited to 400 (as defined by `MAX_MSGS_TOTAL_BATCHED_SIGS` in Dash Core)
| Varies | inv | CAutoBitSet | Quorum signature inventory |
The following annotated hexdump shows a [`qgetsigs` message](../reference/p2p-network-quorum-messages.md#qgetsigs). (The message header has been omitted.)
@@ -617,6 +629,8 @@ The [`qsendrecsigs` message](../reference/p2p-network-quorum-messages.md#qsendre
SPV nodes should not send this message as they are usually only interested in the higher level messages.
:::
+As of Dash Core 23.1.0, peers that have sent a `qsendrecsigs` message enabling recovered signatures are not sent [`isdlock`](../reference/p2p-network-instantsend-messages.md#isdlock) inventory announcements, since they can reconstruct the `isdlock` from the recovered signature. Since Dash Core 23.1.3, this only applies to peers that have authenticated as a masternode via the [`mnauth` message](../reference/p2p-network-masternode-messages.md#mnauth); other peers (e.g., nodes running with `-watchquorums`) still receive `isdlock` announcements.
+
| Bytes | Name | Data type | Description |
| --- | --- | --- | --- |
| 1 | fSendRecSigs | bool | 0 - Notify peer to not send plain LLMQ recovered signatures
1 - Notify peer to send plain LLMQ recovered signatures (default for Dash Core nodes)
@@ -633,6 +647,8 @@ The following annotated hexdump shows a [`qsendrecsigs` message](../reference/p2
The [`qsigrec` message](../reference/p2p-network-quorum-messages.md#qsigrec) is used to provide recovered signatures and related quorum details to [nodes](../resources/glossary.md#node) that have requested this information via the [`qsendrecsigs` message](../reference/p2p-network-quorum-messages.md#qsendrecsigs).
+As of Dash Core 23.1.0, a node that produces a recovered signature locally (rather than receiving it from a peer) sends the `qsigrec` message directly to all peers that requested recovered signatures, without first announcing it via an [`inv` message](../reference/p2p-network-data-messages.md#inv). Recovered signatures for `LLMQ_100_67`, `LLMQ_400_60`, and `LLMQ_400_85` quorums are still announced via `inv` messages.
+
| Bytes | Name | Data type | Description |
| --- | --- | --- | --- |
| 1 | llmqType | uint8_t | The type of LLMQ
@@ -678,7 +694,7 @@ This message is used for intra-quorum communication and is only sent to the [mas
The [`qsigsesann` message](../reference/p2p-network-quorum-messages.md#qsigsesann) is used to announce the sessionId for a signing session. The sessionId will be used for all P2P messages related to that session.
:::{note}
-The maximum number of inventories in a [`qsigsinv` message](../reference/p2p-network-quorum-messages.md#qsigsinv) is limited to 200 (as defined by `MAX_MSGS_CNT_QSIGSHARESINV` in Dash Core).
+The maximum number of session announcements in a [`qsigsesann` message](../reference/p2p-network-quorum-messages.md#qsigsesann) is limited to 100 (as defined by `MAX_MSGS_CNT_QSIGSESANN` in Dash Core).
:::
| Bytes | Name | Data type | Description |
@@ -735,7 +751,7 @@ This message is used for intra-quorum communication and is only sent to the [mas
The [`qsigshare` message](../reference/p2p-network-quorum-messages.md#qsigshare) (quorum signature share) announces one or more quorum signature shares known by the transmitting peer.
:::{note}
-The maximum number of inventories in a [`qsigsinv` message](../reference/p2p-network-quorum-messages.md#qsigsinv) is limited to 200 (as defined by `MAX_MSGS_CNT_QSIGSHARESINV` in Dash Core).
+The maximum number of signature shares in a [`qsigshare` message](../reference/p2p-network-quorum-messages.md#qsigshare) is limited to 32 (as defined by `MAX_MSGS_SIG_SHARES` in Dash Core).
:::
| Bytes | Name | Data type | Description |
@@ -786,14 +802,14 @@ The [`qsigsinv` message](../reference/p2p-network-quorum-messages.md#qsigsinv) (
Info callout
:::{note}
-The maximum number of inventories in a [`qsigsinv` message](../reference/p2p-network-quorum-messages.md#qsigsinv) is limited to 200 (as defined by `MAX_MSGS_CNT_QSIGSHARESINV` in Dash Core).
+The maximum number of inventories in a [`qsigsinv` message](../reference/p2p-network-quorum-messages.md#qsigsinv) is limited to 200 (as defined by `MAX_MSGS_CNT_QSIGSHARES` in Dash Core).
:::
| Bytes | Name | Data type | Description |
| --- | --- | --- | --- |
| Varies | count | compactSize uint | Number of session announcements |
| Varies | sessionId | varint | Signing session ID (must be less than the maximum uint32_t value) |
-| Varies | invSize | compactSize uint | Inventory size
+| Varies | invSize | compactSize uint | Inventory size (must equal the quorum size)
As of Dash Core 23.1.4, limited to 400 (as defined by `MAX_MSGS_TOTAL_BATCHED_SIGS` in Dash Core)
| Varies | inv | CAutoBitSet | Quorum signature inventory |
The following annotated hexdump shows a [`qsigsinv` message](../reference/p2p-network-quorum-messages.md#qsigsinv). (The message header has been omitted.)
@@ -820,4 +836,8 @@ The [`qwatch` message](../reference/p2p-network-quorum-messages.md#qwatch) tells
This message is sent when a Dash Core node is started with the [`-watchquorums` option](../dashcore/wallet-arguments-and-commands-dashd.md#debuggingtesting-options) enabled.
+:::{note}
+As of Dash Core 24.0.0, nodes running with `-watchquorums` that are not masternodes no longer request or process DKG messages ([`qcontrib`](#qcontrib), [`qcomplaint`](#qcomplaint), [`qjustify`](#qjustify), and [`qpcommit`](#qpcommit)). Masternodes still announce these messages to `qwatch` peers, but such nodes treat the announcements as already known and do not request them. Watch Mode nodes can obtain quorum data using the [`qgetdata` message](#qgetdata) instead.
+:::
+
There is no payload in a [`qwatch` message](../reference/p2p-network-quorum-messages.md#qwatch). See the [message header section](../reference/p2p-network-message-headers.md) for an example of a message without a payload.