Wraith: the election roster is still the publisher's word

[defenwycke]

Found while closing #697. The wallet now recomputes the coordinator draw and re-derives the beacon from its own node (fa8ed99c0, 6dfefc239), which closes the half of the trust gap that can be closed. The roster is the half that remains.

The gap

verify_election(beacon, epoch, roster, n, claimed) proves the seat list follows from the beacon and roster published beside it. The beacon is now pinned to the chain — it is SHA256(domain ‖ epoch ‖ block_hash_at(anchor_height)) and the wallet derives the anchor height from the epoch, so a publisher cannot invent one.

The roster has no such anchor. It arrives from the same place as the result, so a node that trims it — omitting qualified peers to improve its own odds, or to seat itself outright — produces an election that verifies perfectly. "No self-nomination" holds against the draw; it does not hold against control of the input set.

What closing it needs

The qualified set has to come from consensus rather than from whoever answered. The mesh already carries node capabilities and an elder roster, and epoch::canonical_roster already canonicalises whatever it is given, so the missing piece is agreement on membership rather than the derivation.

Worth deciding as part of it:

• Which membership signal is authoritative — the elder set, capability-verified coordinators, or a purpose-built roster checkpoint.
• Whether a wallet can check the roster independently at all, or whether it can only detect disagreement between several nodes' published views. The latter is cheaper and might be enough: a wallet that asks two nodes and compares rosters catches a unilateral liar without needing consensus membership.

Related: #708 makes this moot in practice today, since the live roster has one member.

[defenwycke]

Two findings that sharpen the choice, both verified against e97e71c93.

roster_commitment has no comparator anywhere

The field exists so disagreement is seen — roster_snapshot.rs:49 says that is its whole purpose, and the wallet repeats it: "two nodes can legitimately disagree, and roster_commitment exists to make that visible."

Nothing compares it. Grepping the tree, every occurrence outside roster_snapshot.rs and its own tests is a doc comment. It is computed, published, and read by no one — an inert control, the same shape as CapabilityType::Address being collected and never consulted (see my note on #605).

That is not an argument against it. It means the detection half of this issue is one comparison away, not a build.

The blocker for the cheap option is smaller than it looks, and is not what the docs imply

The cheap detection — ask several nodes, compare rosters, catch a unilateral liar — is blocked on one thing: the wallet holds exactly one pool URL (pool_url: RwLock<Option<String>>). There is no multi-pool concept, so there is currently nobody to compare against. Building the comparison today would produce dead code.

But the source of "whom to ask" is easier than this issue and the wallet's own comment suggest. That comment rules the mesh node-list checkpoint out — correctly — as the roster's source:

it cannot come from the mesh node-list checkpoint: that one carries public-mining nodes and their stratum ports, while this draws from coordinator-opted-in nodes

⇒ That objection does not apply to the cheap option. The detection does not need an authoritative list of who is qualified to coordinate; it needs several independent parties to ask. A public-mining node list is fine for that — a node that does not coordinate can still publish its view of the roster, and a liar is caught by disagreeing with it. The checkpoint is unsuitable as the roster and perfectly suitable as the address book.

So the decision is narrower than the issue states

• (a) consensus membership — a BFT-finalised coordinator roster checkpoint on the pool side, with a height gate and a fleet roll. Trustless, and a real project.
• (b) cross-node comparison — a wallet asks k nodes and refuses an election whose roster_commitment is not unanimous. Detects a unilateral liar, does not detect collusion, needs no consensus and no gate. The only new machinery is a source of peer URLs, and feat: arm decentralised mining discovery (signed node-list checkpoint + shim) + independent seeds #402's node-list checkpoint can supply it.

⚖ (b) is worth doing first even if (a) is the answer, because it is cheap and because it makes the existing roster_commitment mean something instead of being an inert field. It does not preclude (a).

⛔ Not building either without a steer: (b) has one genuine design choice inside it — what a wallet does when the views disagree. Refusing outright is safest and is also a denial-of-service surface, since one lying node in the sample would stop an honest wallet mixing. "Majority view, and warn" is friendlier and weaker. That is the call worth making before code.