MOVE_QUEUE_STATUS — Group 20, Code 3
Report the queued-move state of a coin.
Design-stage — parameters are a first draft
Field sizes are drafted from raidax/ideas_for_suspect_raida_servers.txt (Addenda 5–7) and are not final or implementation-verified. The body is encrypted per the header ENC_CODE; see below.
Phase II — later
This command is Phase II: convenience, recovery, or optimization that is not required for the first working move. Diagnostic: report a pending move. Optional.
How it works
This is a read-only question a client asks the root: “what is going to happen to this coin?” Because moves are queued and only execute at an epoch boundary, a user may want to confirm a request is really pending, see which server it is headed to, and learn exactly when it will take effect.
The client names the coin; the root replies with the coin's queue state (none, pending move out to a suspect, or pending move back to root), the destination server, and the epoch at which the change will occur. Nothing is modified — it only reports.
Direction & encryption
- Direction: client → root
- ENC_CODE: 1
Request Body parameters
| Field | Bytes | Description |
|---|---|---|
| CH (challenge) | 16 | Standard challenge / replay protection (per header convention). |
| DN | 1 | Denomination of coin X. |
| SN | 4 | Serial number of coin X. |
| EOF | 2 | Terminator (0x3E3E). |
Response Body parameters
| Field | Bytes | Description |
|---|---|---|
| state | 1 | 0 NONE, 1 PENDING_OUT, 2 PENDING_BACK. |
| target_id | 2 | Destination server id (0 = root). |
| effective_epoch | 4 | Epoch the queued move applies. |