Mobility Service Overview (Group 20)
Moving a coin's authority from the trusted “root” RAIDA to a faster third-party “suspect” RAIDA, and back again.
Design-stage — not yet implemented
Group 20 is a proposed command group. It has been assigned a brand-new group ID (20 / 0x14) that has never been used, and is documented here so client and server teams can build against the same contract in parallel. Byte layouts are drafted from the design notes (raidax/ideas_for_suspect_raida_servers.txt, Addenda 1–7) and have not been cross-checked against an implementation. Verify before relying.
Build phases (whole feature)
The account-mobility feature spans several command groups. To stage the work, each command is tagged Phase I (the minimum needed for a coin to move and be trusted) or Phase II (convenience, recovery, optimization, and the offline move-locker / swap UX). Every command page also carries its own phase badge.
| Phase | Group | Commands |
|---|---|---|
| I | Mobility (20) | MOVE_REQUEST (1), MOVE_VALIDATE_TICKET (4), MOVE_ACCEPT_IN (5), MOVE_REPOWN (6), EPOCH_COMMIT (10, internal) |
| I | Authority (21) | GET_AUTHORITY_EPOCH (1), GET_AUTHORITY_SNAPSHOT (2), PUSH_AUTHORITY_SNAPSHOT (10), MIRROR_ACK (11), WHO_IS_AUTHORITATIVE (12) |
| I | Key Exchange (4) | ADMIT_SUSPECT_PEER (46) |
| II | Mobility (20) | MOVE_CANCEL (2), MOVE_QUEUE_STATUS (3), MOVE_ABORT (7), MOVE_STATUS (8) |
| II | Authority (21) | GET_AUTHORITY_DELTA (3), VERIFY_AUTHORITY_PROOF (4) |
| II | Key Exchange (4) | ROTATE_INTER_RAIDA_KEY (47) |
| II | Locker (8) | Move lockers: CREATE (90), STATUS (91), CLAIM (92), EPOCH_MOVE_EXECUTE (93), CANCEL (94). Swap: LIST_SWAPPABLE (95), PROPOSE_SWAP (96), EXECUTE_SWAP (97) |
Phase I notably ships without move lockers: an offline user is covered in Phase I by a timed client move-over (the client app finishes the move automatically at the epoch). Move lockers and swap are the Phase II offline/UX layer.
Overview
A user may move a coin's authority — the right to authenticate and re-key it — from the root RAIDA to a suspect RAIDA the user chooses (for speed, or because they trust that operator more). Authentication in RAIDA is a symmetric check: the 16-byte Authenticity Number (AN) is both the coin's password and its AES key. A move therefore re-establishes that secret on the destination server without ever exposing it, using AES only (no public keys), so the protocol is quantum-safe by construction.
Authority model
Each coin is authoritative on exactly one server at a time. The model is two-state and reversible:
- Authority = ROOT: root may
detect,pown,break, andjointhe coin. - Authority = SUSPECT: the suspect may
detectandpownonly. break/join are root-only — to restructure a coin held on a suspect, the user moves it back to root first.
Because suspects never break or join, they never allocate serial numbers, which removes the cross-server SN-collision problem entirely.
Commands
Development phases
Phase I is the minimum set needed for a coin to actually move root↔suspect and be trusted. Phase II adds convenience, recovery, and optimization that are not required for a first working move. The Phase column below marks each command.
| Code | Name | Phase | Direction | ENC | Purpose |
|---|---|---|---|---|---|
| 1 (0x01) | MOVE_REQUEST | I | client → root | 1 (coin AN) | Queue a move of coin X to suspect S, effective next epoch. |
| 2 (0x02) | MOVE_CANCEL | II | client → root | 1 (coin AN) | Drop a pending move before the epoch boundary. |
| 3 (0x03) | MOVE_QUEUE_STATUS | II | client → root | 1 | Report the move state of a coin. |
| 4 (0x04) | MOVE_VALIDATE_TICKET | I | dest → source | 7 (K_rs) | Destination validates a pickup ticket; source advances to MOVED_OUT. |
| 5 (0x05) | MOVE_ACCEPT_IN | I | client → dest | 1/bootstrap | Destination durably records INBOUND. |
| 6 (0x06) | MOVE_REPOWN | I | client → dest | bootstrap | Set fresh AN; INBOUND → AUTHORITATIVE. Completes the move. |
| 7 (0x07) | MOVE_ABORT | II | client → source | 1 | Pre-commit rollback of a MOVING_OUT coin. |
| 8 (0x08) | MOVE_STATUS | II | client → any | 0/1 | Authority state of a coin on this server. |
| 10 (0x0A) | EPOCH_COMMIT | I | internal | — | Scheduled job; not client-dispatchable. Applies pending moves, publishes the authority snapshot, sets tombstones. |
Move flow (root → suspect)
- Client authenticates coin X to root and sends
MOVE_REQUESTnaming suspect S. Root records a PENDING move; the coin stays usable on root for the rest of the epoch. - At the epoch boundary,
EPOCH_COMMITapplies the move: root issues a pickup ticket and stops answering for X (MOVED_OUT tombstone). - The destination validates the ticket back to the source (
MOVE_VALIDATE_TICKET, CMAC'd over the inter-RAIDA key K_rs) and records INBOUND (MOVE_ACCEPT_IN). - The user sets a fresh AN on S (
MOVE_REPOWN), flipping the coin to AUTHORITATIVE on S. The raw secret never crossed organizations.
The back direction (suspect → root) reuses the same commands with the roles swapped, and is the prerequisite for break/join.
Safety invariants
One authority at a time
A coin is never authoritative on two servers simultaneously. The source goes UNUSABLE before the destination becomes usable; the commit point is “destination records INBOUND and source records MOVED_OUT.” All state transitions are persisted (fsync) before the network reply is sent. A briefly-unusable coin is acceptable and recoverable; a doubly-owned coin is not.
Move messages that carry secrets are integrity-protected with AES-CMAC, not CRC (CRC is malleable under AES-CTR). Each encrypted blob is bound to its coin, sequence number, and direction to prevent replay.