tgss-mem

Memory #133 CURRENT

Protocol gap — is_same_genesis hardcoded True PeerInfo.is_same_genesis is hardcoded True via dataclass default in src/pria_core/clock_peer/peer.py; neither receive_hello() nor complete_hello() overrides it. Demos relying on the "same genesis: True" line should treat it as "this field is unwired" not "founding rings match." Needs to compare genesis-block hashes from HELLO payload before any cross-genesis federation work. Surfaced 2026-04-29 while writing DEMO_PEER_SYNC_WALKTHROUGH.md §5.3. ## What it is In `src/pria_core/clock_peer/peer.py`, the `PeerInfo` dataclass has: ```python @dataclass class PeerInfo: ... is_same_genesis: bool = True federation_receipt_hex: str = "" ``` Both `PeerConnection.receive_hello(msg)` and `PeerConnection.complete_hello(ack_msg)` populate the rest of `PeerInfo` from the wire HELLO/HELLO_ACK payload but **never override `is_same_genesis`**. So every connected peer reports `is_same_genesis = True` regardless of whether the founding rings actually match. `demo_peer_sync.py` prints this field as `same genesis: True` — which currently reads as a successful verification but is in fact a hardcoded default. ## Why it doesn't break anything yet For the Mark↔Diego demo (and any same-foundation demo), both sides genuinely *do* build their wallets from `default_founding_entities()` with the same `T_GENESIS_0` constant. The hardcoded True happens to be correct in that scenario. The integration tests in `tests/test_clock_peer.py` §17 also use the same `default_founding_entities()` for both clocks, so they don't surface this gap either. ## When it will matter Any scenario that involves *distinct* founding rings: - Cross-genesis federation between two networks (e.g., TTF tailnet ↔ a partner-deployed PrIA tailnet). - Onboarding a node from outside the original 12-entity founding ring. - Any deployment where mismatched genesis is a *security* boundary (a node from network A trying to handshake into network B should be rejected, but currently would succeed). The `FederationManager` work (`src/pria_core/clock_peer/federation.py`) handles cross-genesis federation as a separate ceremony, but the *gating check* on whether federation is required is exactly what `is_same_genesis` should answer — and right now it answers "always same." ## What the fix looks like In both `receive_hello()` and `complete_hello()`: ```python remote_genesis_hex = hello_data.get("genesis_block_p0_hex", "") local_genesis_hex = local_clock.wallet.genesis_block_p0_hex # or equivalent peer_info.is_same_genesis = ( remote_genesis_hex != "" and remote_genesis_hex == local_genesis_hex ) ``` The HELLO payload currently includes `genesis_receipt` (which is the *wallet*'s receipt, not the genesis-block prime). The fix needs to add the genesis-block prime hash to the HELLO payload as well, then compare. Adjacent change: bump the protocol version. ## Severity - **Demo / test impact:** None today (both sides share founding ring in all current code paths). - **Production-readiness impact:** Medium-high. Federation gating is a security property; today's behavior is "always assume same network." A node from a different network making a HELLO would currently be accepted as a same-network peer, GEO-Sync would attempt to merge incompatible chains, and `chain.verify()` would presumably fail at the merge step — but the protocol-level rejection should happen earlier, at the handshake. ## Tracking Surfaced 2026-04-29 in `DEMO_PEER_SYNC_WALKTHROUGH.md §5.3` (committed at `f15...` or wherever — see `git log` for the actual SHA). Not yet tracked anywhere else; this memory is the only durable note. Worth folding into the next federation-readiness pass (V2.5+ axis) and into `OPEN_QUESTIONS_INDEX` if there's a canonical place for protocol open questions in the foundation repo. ## Cross-references - `src/pria_core/clock_peer/peer.py` (PeerConnection, PeerInfo) - `src/pria_core/clock_peer/federation.py` (the ceremony that should fire when is_same_genesis is False) - `src/pria_core/clock_peer/messages.py` (HELLO / HELLO_ACK payload format — needs `genesis_block_p0_hex` added) - `DEMO_PEER_SYNC_WALKTHROUGH.md` §5.3 (the surfacing document) - `project_lydian_demo_sync.md` — the demo this gap was found via — [project_protocol_gap_same_genesis.md]

Outgoing Edges

No outgoing edges.

Link to Another Memory