MOVE_ACCEPT_IN — Group 20, Code 5
Destination durably records the coin as INBOUND (owned here, not yet re-keyed).
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 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. Destination takes ownership; required to complete a move.
How it works
This is the destination server's step in receiving a coin. After the destination has confirmed the move ticket with the source (see MOVE_VALIDATE_TICKET), it must durably write down that it now owns this coin. MOVE_ACCEPT_IN records the coin in an INBOUND state: “this coin belongs here now, but it does not yet have its new password set.”
Recording INBOUND before anything is spendable is deliberate. The handoff is ordered so the source stops honoring the coin before the destination makes it usable; for a brief moment the coin belongs to nobody-usable, which is safe and recoverable. A coin owned by two servers at once would not be safe, so the protocol never allows it. The server replies that it is ready for the final step, re-setting the secret.
Direction & encryption
- Direction: client → dest
- ENC_CODE: 1 / bootstrap
Request Body parameters
| Field | Bytes | Description |
|---|---|---|
| CH (challenge) | 16 | Standard challenge / replay protection (per header convention). |
| ticket | 16 | Pickup ticket (already validated to the source). |
| DN | 1 | Denomination of coin X. |
| SN | 4 | Serial number of coin X. |
| EOF | 2 | Terminator (0x3E3E). |
Response Body parameters
| Field | Bytes | Description |
|---|---|---|
| accepted | 1 | 1 = INBOUND recorded; ready for re-POWN. |