MOVE_REQUEST — Group 20, Code 1

Queue a move of a coin's authority from root to a chosen suspect, effective at the next epoch.

Design-stage — parameters are a first draft

Field sizes below are drafted from raidax/ideas_for_suspect_raida_servers.txt (Addenda 5–7) and are not final. The body is encrypted per the header ENC_CODE; here ENC_CODE = 1 (AES under the coin's own AN), which also proves ownership.

Purpose

The client asks root to move coin X to suspect target_suspect_id. Root records a PENDING move; authority does not change until EPOCH_COMMIT runs at the epoch boundary, so the coin stays usable on root until then.

Phase I — essential

This command is part of the Phase I minimum needed for a coin to move from root to suspect (and back) and be trusted by a workstation. Starts a move; without it nothing moves.

How it works

A CloudCoin is proven authentic by a secret 16-byte number called its Authenticity Number (AN) — effectively the coin's password. Normally one server, the root RAIDA, is the authority that knows and checks that secret. This command begins moving that authority to a different, user-chosen server called a suspect (chosen because it is faster or run by an operator the user prefers).

MOVE_REQUEST does not move the coin immediately. It queues the move: the client proves it owns coin X (by encrypting the request under the coin's own AN), names which suspect server it wants, and the root records the request as “pending.” Moves only actually happen at a scheduled moment called an epoch (for example, the first day of the month), so that the list of which-coin-lives-where changes rarely and predictably. Until that epoch arrives, the coin stays fully usable on the root.

The server replies with the epoch the move will take effect and a reference number the client can later use to cancel or check on the request.

Direction & encryption

  • Direction: client → root
  • ENC_CODE: 1 (body encrypted under coin X's AN — proves the requester knows the AN)

Request Body parameters

FieldBytesDescription
CH (challenge)16Standard challenge / replay protection (per header convention).
DN1Denomination of coin X.
SN4Serial number of coin X.
target_suspect_id2Server id of the suspect to move to.
EOF2Terminator (0x3E3E).

Response Body parameters

FieldBytesDescription
accepted11 = move queued, 0 = rejected.
effective_epoch4Epoch id (YYYYMM) at which the move applies.
queue_ref4Handle the client can use to cancel or query the pending move.