fix: handle missing service/platformP2PPort/platformHTTPPort fields from Core RPC after dash#7181 #3227

Activity

1. thepastaclaw

   added

   bugSomething isn't workingSomething isn't working

   effort: MMedium effort — a few daysMedium effort — a few days

   priority: highHigh priority — address soonHigh priority — address soon

   on Mar 12, 2026
2. hilawe commented on Sep 27, 2026

   

   hilawe

   on Sep 27, 2026

   More actions

   Platform's Drive rejects the Dash Core v24 masternode list format for shared masternodes and for
   masternodes at the ExtAddr ProTx version. I am reporting it because once v24 is active,
   registering a shared masternode is an ordinary action open to anyone, and every Drive node reads
   the same masternode list. The service-field part of this is already public in
   #3227. The owner and payout part below is not mentioned there or in any issue I
   found.

   Versions checked:

   • Dash Core v24.0.0-rc.1 (tag).
   • dashpay/platform v4.1.1, rs-drive-abci, which pins dashpay/rust-dashcore at
     70d4bf8e36057c58e02d56769a6e9760f701dd06.
   • rust-dashcore master and dev (dev at 8354de94, 2026-09-27) carry the same DMNState
     definition.

   The mismatch:

   • Core, src/evo/core_write.cpp:154-196 (CDeterministicMNState::ToJson, used by protx listdiff):
     a shared masternode is written with shares and without ownerAddress or payoutAddress. A
     non-shared state at ProTxVersion::ExtAddr or later is written with payouts instead of
     payoutAddress.
   • rust-dashcore, rpc-json/src/lib.rs, DMNState: owner_address and payout_address are
     required fields with no default.
   • -deprecatedrpc=service restores service only. Nothing restores the owner or payout fields.

   What has been demonstrated, offline only:

   • The pinned dashcore-rpc-json crate parses a real protx listdiff response taken from a
     v23.1.8 testnet node.
   • It refuses the same response when the added masternode's state is rewritten as rc.1's source
     writes it. An ExtAddr state fails with missing payoutAddress. A shared state fails with missing
     ownerAddress, and still fails with missing payoutAddress once ownerAddress is restored.
   • service is present in every case, so the known issue is not the cause. Controls with the
     fields restored parse.
   • In rs-drive-abci v4.1.1 the error is not retried (rpc/core.rs, retry! retries only transport
     and warm-up errors). It propagates through update_state_masternode_list_v0 (line 103),
     update_masternode_list_v0, update_core_info_v0 and run_block_proposal_v0, and both
     prepare_proposal.rs and process_proposal.rs return it to the Application Blockchain Interface
     (ABCI) layer as a handler error rather than rejecting the proposal.

   What has not been demonstrated:

   • No running rc.1 node, Drive or Tenderdash was used. The v24 fixtures are derived from rc.1's
     source applied to a real v23.1.8 response.
   • How Tenderdash handles that handler error was not read, so a network-wide halt is not
     confirmed. Whether a proposal that does not advance the Core chain-locked height avoids the list
     update was not checked either.
   • No fix was found in the revisions and searches checked. Those were rust-dashcore master, dev
     and 70d4bf8e, and open pull requests in dashpay/platform and dashpay/rust-dashcore searched on
     2026-09-27. rust-dashcore#517 (the service fix) is closed, but its change chore(release): update version to 0.22.16 #523 was reverted by
     test(drive): synchronizeMasternodeIdentitiesFactory #586.

   The reproduction is attached

   cn152-repro.zip

   as cn152-repro.zip (21 KB). It holds a Cargo project pinned to
   70d4bf8e, the fixtures, the script that derives them from the real response, and the recorded
   run. Its README has the one-line Docker command that reruns it.

   👀React with 👀1Reacted by Michael