fix: verify merkle_root in BFT _validate_proposal against miners list

[wsimon1982]

Fixes #766

Problem

_validate_proposal in node/rustchain_bft_consensus.py checked that miner IDs in distribution existed in the miners list and that the total reward summed to 1.5 RTC — but it never re-computed the Merkle root from the submitted miners list and compared it to proposal["merkle_root"].

A Byzantine leader could recycle a valid merkle_root from a previous epoch while submitting a falsified miners list that still passes the miner-ID / total-reward checks. Honest nodes would send PREPARE messages for a proposal whose attestation data is inconsistent with the digest they are voting on.

Reproducer

bft = BFTConsensus("node-A", ":memory:", "secret")
miners_real = [{"miner_id": "miner-1", "weight": 1.0}]
miners_fake = [{"miner_id": "miner-1", "weight": 1.0}, {"miner_id": "miner-2", "weight": 0.0}]
real_merkle = bft._compute_merkle_root(miners_real)
fake_proposal = {
    "epoch": 1, "miners": miners_fake, "total_reward": 1.5,
    "distribution": {"miner-1": 1.5}, "proposer": "byzantine-leader",
    "merkle_root": real_merkle,  # stale / mismatched
}
assert bft._validate_proposal(fake_proposal)  # passes before fix — should fail

Solution

Recompute the Merkle root from the miners list and assert equality:

expected_merkle = self._compute_merkle_root(miners)
if proposal.get("merkle_root") != expected_merkle:
    logging.warning("Proposal merkle_root mismatch")
    return False

[Scottcjn]

Important consensus security fix. Without this, a Byzantine leader could recycle a valid merkle_root from a previous epoch while submitting a falsified miners list — honest nodes would still send PREPARE. The fix correctly recomputes _compute_merkle_root(miners) and validates before accepting.

Verdict: MERGE — 50 RTC bounty (consensus security hardening).

🤖 Reviewed with GPT-5.4 + Claude Opus dual-brain analysis