docs(core): update special transaction and block docs for Dash Core 24.0.0

docs/core/guide/dash-features-masternode-sync.md

@@ -26,7 +26,7 @@ The following table details the data flow of P2P messages exchanged during initi
 | **Syncing Node Message** | **Direction**  | **Masternode Response**   | **Description** |
 | --- | :---: | --- | --- |
 | **1. Sporks** |   |  |  |
-| [`getsporks` message](../reference/p2p-network-control-messages.md#getsporks)                            | → |                           | Syncing node requests sporks
+| [`getsporks` message](../reference/p2p-network-control-messages.md#getsporks)                            | → |                           | **No longer sent during sync as of Dash Core 24.0.0**<br>Syncing node requests sporks. Dash Core 24.0.0 no longer requests sporks during sync. Instead, on test networks (testnet, devnets, and regtest), nodes announce their active sporks to each peer with [`inv` messages](../reference/p2p-network-data-messages.md#inv) once the connection handshake completes. Mainnet spork values are hardcoded, so no announcement is needed there. Dash Core 24.0.0 still responds to `getsporks` messages from older nodes.
 |                                                | ← | [`spork` message](../reference/p2p-network-control-messages.md#spork)(s)        |
 | **2. Mempool** |   |  |  |
 | [`mempool` message](../reference/p2p-network-data-messages.md#mempool)                            | → |                           | Syncing node requests mempool entries
@@ -61,7 +61,7 @@ The following tables detail the timing of various functions used to keep the mas
 
 | **Period (seconds)** | **Action** | **Description** |
 | --- | --- | --- |
-| 6   | MN Sync                   | Synchronizes sporks and governance objects (masternode-sync.cpp) |
+| 6   | MN Sync                   | Synchronizes governance objects (`node/sync_manager.cpp`). Prior to Dash Core 24.0.0, it also synchronized sporks. |
 
 The following actions only run when the masternode sync is past `MASTERNODE_SYNC_WAITING` status.
 

docs/core/guide/transactions-non-standard-transactions.md

@@ -20,6 +20,8 @@ Standard transactions must also meet the following conditions:
 
 * The transaction must be smaller than 100,000 bytes. That's around 200 times larger than a typical single-input, single-output P2PKH transaction.
 
+* The transaction must be at least 65 bytes. *Lowered from 83 bytes in Dash Core 24.0.0.*
+
 * Each of the transaction's signature scripts must be smaller than 1,650 bytes. That's large enough to allow 15-of-15 multisig transactions in P2SH using compressed [public keys](../resources/glossary.md#public-key).
 
 * Bare (non-P2SH) multisig transactions which require more than 3 public keys are currently non-standard.

docs/core/reference/block-chain-block-headers.md

@@ -69,6 +69,10 @@ If a block has three or more transactions, intermediate [merkle tree](../resourc
 
 TXIDs and intermediate hashes are always in [internal byte order](../resources/glossary.md#internal-byte-order) when they're concatenated, and the resulting merkle root is also in internal byte order when it's placed in the [block header](../resources/glossary.md#block-header).
 
+:::{note}
+The TXID of a [version 2 asset unlock transaction](../reference/transactions-special-transactions.md#version-2-asset-unlocks) (Dash Core 24.0.0+) excludes the transaction's quorum signing info, so the merkle root does not commit to that data. Instead, the coinbase special transaction commits to the full hashes of those transactions in its [`merkleRootAssetUnlocks` field](../reference/transactions-special-transactions.md#cbtx).
+:::
+
 ## Target nBits
 
 The [target threshold](../resources/glossary.md#target) is a 256-bit unsigned integer which a [header](../resources/glossary.md#header) hash must be equal to or below in order for that header to be a valid part of the [block chain](../resources/glossary.md#block-chain). However, the header field *[nBits](../resources/glossary.md#nbits)* provides only 32 bits of space, so the [target](../resources/glossary.md#target) number uses a less precise format called "compact" which works like a base-256 version of scientific notation:

docs/core/reference/block-chain-serialized-blocks.md

@@ -70,6 +70,12 @@ The following table details how the block subsidy and fees are allocated between
 | Miner | 20% | 25% | Payment for mining
 | Masternode | 60% | 75% | Payment for masternode services including [CoinJoin](../guide/dash-features-coinjoin.md), [InstantSend](../guide/dash-features-instantsend.md), [Governance](https://docs.dash.org/en/stable/introduction/features.html#decentralized-governance), etc.
 
+:::{note}
+Once the Dash Core 24.0.0 `v24` hard fork activates, the masternode owner reward may be split across multiple coinbase outputs. A masternode can list several payout scripts, each receiving a share of the owner reward in basis points, and a shared masternode splits the owner reward among its collateral participants based on their contributions. The operator reward is unchanged.
+
+After activation, coinbase payments are also matched by multiplicity. Each expected masternode payment, and each superblock payment, must be paid by a separate coinbase output, even when two expected payments of the same kind have the same script and amount. Blocks that merge or deduplicate those outputs are invalid.
+:::
+
 <img src="https://files.readme.io/fa5bfbe-mining-banner-1.svg" alt="Mining" style="width:50%;text-align:center;"/>
 
 #### Block Reward Reallocation

docs/core/reference/transactions-raw-transaction-format.md

@@ -8,6 +8,10 @@
 
 Dash transactions are broadcast between [peers](../resources/glossary.md#peer) in a serialized byte format, called [raw format](../resources/glossary.md#raw-format). It is this form of a transaction which is SHA256(SHA256()) hashed to create the [TXID](../resources/glossary.md#transaction-identifiers) and, ultimately, the [merkle root](../resources/glossary.md#merkle-root) of a [block](../resources/glossary.md#block) containing the transaction---making the transaction format part of the [consensus rules](../resources/glossary.md#consensus-rules).
 
+:::{note}
+As of Dash Core 24.0.0, the TXID of a [version 2 asset unlock transaction](../reference/transactions-special-transactions.md#version-2-asset-unlocks) is calculated with the payload's quorum signing info set to zero, so it is not the hash of the transaction's full raw format.
+:::
+
 Dash Core and many other tools print and accept [raw transactions](../resources/glossary.md#raw-transaction) encoded as hex.
 
 Transactions prior to protocol version 70209 defaulted to version 1. Transaction version 2 was the default in protocol versions => 70209 and < 70213. Version 2 transactions have the same format, but the `lock_time` parameter was redefined by [BIP68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) to enable relative lock-times. (Note: transactions in the [block chain](../resources/glossary.md#block-chain) are allowed to list a higher version number to permit [soft forks](../resources/glossary.md#soft-fork), but they are treated as version 2 transactions by current software.)