PlatformNodeId byte order differs between consensus_decode (wire-reversed) and from_ed25519_public_key (canonical) — payload/derived ids never match

[QuantumExplorer]

Summary

PlatformNodeId (#885) holds bytes in two different orders depending on construction path, making values from the two paths incomparable:

• PlatformNodeId::consensus_decode (ProRegTx / ProUpServTx platformNodeID) keeps the wire bytes as-is — and the wire serializes the field as a uint160 in Dash Core's internal (reversed) blob order.
• PlatformNodeId::from_ed25519_public_key (fix(key-wallet): platform node id is the Tenderdash node ID (SHA256[0..20]), not hash160 #884) produces the canonical forward Tenderdash node id (SHA256(pubkey)[0..20], as dashmate/Tenderdash display and derive it).

User-verified example (mainnet evonode): decoded payload renders 8cb97997a418f4814a63d3564b9574a393437968; the canonical id (dashmate / on-chain semantics) is 68794393a374954b56d3634a81f418a49779b98c — exact byte reversal.

Impact

1. Any consumer that compares a decoded payload's node id against a derived one silently never matches. This includes key-wallet's own provider matching: transaction_checking/account_checker.rs (~1034-1048) compares reg.platform_node_id against pool-derived ids — with the pool side canonical-forward (post-fix(key-wallet): platform node id is the Tenderdash node ID (SHA256[0..20]), not hash160 #884) and the payload side wire-reversed, wallet-owned platform node ids can never be recognized from ProRegTx.
2. Displaying a decoded PlatformNodeId (Display/LowerHex print the inner bytes forward) shows the reversed form, which doesn't match dashmate, Tenderdash, or any explorer.

Proposed fix

Normalize at the consensus boundary so the newtype always holds canonical forward bytes: consensus_decode reverses the wire bytes into canonical order, consensus_encode reverses back to wire order (mirroring how hash types separate wire order from display order, but with the invariant on the inner representation since this is an id, not a hash-of-this-data). from_ed25519_public_key, Display, FromHex etc. stay as-is.

Add a round-trip test: decode a known ProRegTx fixture → platform_node_id equals from_ed25519_public_key(payload_pubkey)'s value and the canonical dashmate form; re-encode → byte-identical wire.

Note for downstream

dashpay/platform will pick this up via pin bump; we deliberately did NOT work around it downstream (a local reversal would double-reverse once this fix lands).

Related: #883, #884, #885. Example vectors above; the #884 derivation golden (3130c143… → 302f2615…) is already canonical-forward and unaffected.

[Shaurya2k06]

Hey, I'd love to take this up!
cc @QuantumExplorer