Requests and Responses

From CloudCoin Wiki
Revision as of 20:04, 20 February 2022 by Seanw (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Off Ledger Service

The RAIDA is the world's most private currency. Off-ledger services allow for exchange without any ledger.


All Services

This document describes how the request and response bodies of the RAIDA's services should be formated. This does discuss the request headers and response headers. You will need to see the document [Request Headers and Response Headers](https://github.com/worthingtonse/RAIDAX/blob/main/Request_Response_Headers.md)" to see this.

All these services have a header which is not encrypted and a body that is encrypted.

All bodies start with a four byte challenge that is a random number generated by the client.

The server decrypts the body, reads the challenge and returns a MD5 hash (truncated to 4 bytes) with the response.

Note that the MD5 hash is located in the response header and is not encrypted.

Note: The Response Header will be not be encrypted.

The Response Body will be encrypted using the same encryption key as the Request.

Response Header Codes
Command Code Service Status
0 POWN
1 Detect
2 Find
3 Fix
4 Fix V2
5 Echo
6 Put Key
7 Move Key
8 Identify (NOT IMPLEMENTED)
9 Request Move
10 Recover(NOT IMPLEMENTED) Phase 2
11 Get Ticket
15 Version(NOT IMPLEMENTED)
17 Logs(NOT IMPLEMENTED)
21 PANG
215 Upgrade Coin


ECHO

Request with empty body:

E3 E3

Response will have no body. The status code in the response header will be:

0xFA //Decimal code 250

ECHO Version 0x01

Echo version 0x01 tests the encryption to ensure it is working. This echo is more for debugging than production work.


CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
E3 E3

Response is the same as ECHO except there will be the four Hash Bytes.


POWN

POWN means "Password Own". The client sends the Serial Number, Authenticity Number and the Proposed Authenticity Number. The AN and PAN must be different or an error will be returned with a status that the ANs and PANs matched. The server checks to see if the AN that the client sent matches the AN in the table. If it matches, the AN in the table is replaced with the PAN provided by the client and the "pass" status is returned. If multiple coins are sent then the server may return "all pass" or "all fail" status. If some of the coins are found authentic and some are foud counterfeit, then the "mixed" status is returned along with a bitfield. The bitfield has one bit per coin. A bit set to '1' is a pass and each bit set to '0' is a fail. Since the server only returns whole bytes, the client must know when to stop reading the bitfield based on how many coins were sent.

Like all services, the Pown allows the client to send a 16 byte challenge. The server returns the first four bytes of an MD5 hash of this challenge. This allows the client to be certain that the response came from the RAIDA since only the RAIDA would be able to decrypt the challenge.

CloudCoin does have a "Strings Attached" vulnerability. After the POWN service POWNs all the coins, it must check all the tickets in the ticket table to see if the coins that have just been powned are in those tickets. If any coin is found in the ticket folder, that ticket must be deleted to make sure the coin is not turned back to the former owner.

Request with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA
E3 E3
Response body if all passed Response body if all failed: Response body if mixed with passes and fails:
no response body no response body MT MT MT MT MS //The MT are just zeros. 0x00 00 00 00. They are for future use.

MS means Mixed Status. Each bit returned represents the status of one coin. If the bit is a zero then that coin has failed. If the bit is a 1 then that coin is authentic.

Response Status Code
All Pass 241
All Fail 242
Mixed 243


DETECT

Detect does not require a PAN (Proposed Authenticity Number) and requires less bandwidth and processing power than POWS. This is used as a fast way of checking to see if coins are authentic as in a "Check Health" function on a wallet.

Example with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
E3 E3
Response Status Code
All Pass 241
All Fail 242
Mixed 243

Response body only present if there is mixed content

MS //Mixed content bitfield

GET TICKET

The GET TICKET service is nearly identical to DETECT accept a Ticket is returned. A ticket is a 4-byte random number that the RAIDA gives to the caller as proof that the coins are authentic. This ticket can be used by the client to prove its authenticity to other RAIDA. The Ticket can be claimed one time by each RAIDA server. After the ticket grows old. It should be removed from the table.

After the Ticket is generated, and the response is sent to the client, the GET TICKET service will write the Ticket to its' Tickets table and write all SNs in one column. Also, all of the RAIDA columns in the Ticket Table will be set to '1' which means that that RAIDA has not claimed that ticket.

Sample Ticket Table showing one ticket with six serial numbers and has not been claimed by and RAIDA except for RAIDA 1.

Timestamp Ticket SNs Claimed Codes
90 54 B2 C4 FA 40 39 77 03 44 23 5F 0C 82 B9 EC 5D 49 46 B6 23 90 4D 86 25 4E 01 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01


The client gets a one ticket from a RAIDA and can send that ticket to 24 other RAIDA. Each RAIDA can get the serial numbers one time. So it is necessary to track which RAIDA have already got the ticket.

When you check ticket table, you should also check their expiration time so that they can be removed if old.

Example with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
E3 E3
Response Status Code
All Pass 241
All Fail 242
Mixed 243

Example Response if all pass or mixed:

MT MT MT MT //Master Ticket

FIND

Command Code #2. The RAIDA Find Protocol allows many coins that are in "Limbo". A coin is in Limbo when the client makes a request to POWN but there is no response from the RAIDA. The client is uncertain if the RAIDA got the message and turned the AN to the PAN or if the RAIDA did not get the message and the AN is unchanged.

To get the coin out of Limbo the client sends a Find Request and sends the AN and the PAN to the RAIDA and asks which one is it's AN. The RAIDA will tell the Client if the AN is authentic, the PAN is authentic or if neither is authentic.

The Fix Lost service allows the caller to send both AN and PAN to see if they are authentic. The service then responds with the correct answer. If neither are correct, it will respond with a status of "Neither". '0x00'= Neither. "0x01" = AN and "0x02"=PAN.

Example with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA PA
E3 E3

Response Statuses

Code Status Description
208 Find All Neither Neither the ANs or the PANs on any of the coins were authentic
209 Find All AN The ANs of all of the coins were authentic
210 Find All PAN The PANs of all of the coins were authentic
210 Find mixed The coins had a mix of ANs good, PANs good and Neither good.

Mixed Results Codes

Hex Code Meaning
0x00 Nether the AN or the PAN presented by the Client was authentic.
0x01 The AN is authentic and the RAIDA has it in its database.
0x02 The PAN is authentic and the RAIDA has the PAN as in its database.

Response Body if Results are Mixed for four coins: One byte per coin

01
01
00
02 //1st & 2nd coins the ANs matched. 3rd neither matched. 4th the PAN matched.

FIX

All 25 RAIDA should agree that a coin is authentic. When all RAIDA are not in agreement about the authenticity of a coin, we call the coin "Fractured" or "Fract" for short. The Fix protocol allows for Fract coins to become whole.

The fix protocol must look at two config files to determine which other RAIDA to trust and how many of the RAIDA need to be in agreement to switch the AN to the client's request. All of the file's data are located in the file's name and the file is located in the Config folder

Example config file that tells this RAIDA can accept tickets from all 25 RAIDA and it needs 13 good tickets to turn the AN.

trusted.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.13.config

This example file name shows that the RAIDA is to trust no other RAIDA except for RAIDA 0 and that it must have one good ticket.

trusted.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.config

This example show that it can get tickets from any RAIDA except 10 and that it needs 13 good tickets.

trusted.1.1.1.1.1.1.1.1.1.1.0.1.1.1.1.1.1.1.1.1.1.1.1.1.1.13.config

Each RAIDA Trusts the majority of other RAIDA. The client can get 'tickets' from RAIDA that think the coin is authentic and give them to the fracked RAIDA. The RAIDA requires 13 of the 25 RAIDA to change its AN to the AN that the client specifies.

The fracked RAIDA will always receive 25 tickets although they will all be zeros unless the actually contain a ticket. So the majority of the tickets are just place holders.

The Fix protocol may receive empty tickets with all "00000". In this case there is no ticket.

Client Steps

  1. Client receives a "fail" from one or more of the RAIDA (up to 12).
  2. Client requests tickets from 13 or more RAIDA that are good.
  3. Client sends all the tickets to all the RAIDA that are fracked (received a fail).
  4. RAIDA checks the tickets. If the tickets are good then the fracked RAIDA set the AN that the clients specifies.


RAIDA Steps

  1. The fracted RAIDA receives Tickets with the Serial Numbers of the Coins that are fract and the Proposed Authenticity Numbers (or Proposed Authenticity Number Generator) that client wants to give them.
  2. The fracted RAIDA sends the Tickets to all the trusted RAIDA in parallel using the VALIDATE TICKE protocol.
  3. Trusted RAIDA respond with the serial numbers associated with they ticket.
  4. Fract RAIDA compares the Serial Numbers returned by the Good RAIDA with the Serial Numbers specified by the Client.
  5. If there are 13 Good RAIDAs that agree with what the Serial numbers that the client sent, the Authenticity Numbers on the Fract RAIDA are changed.
  6. All Pass is returned if all the coin were fixed. All fail if none of the coins were fixed. Mixed if some of the coins were fixed.
  7. IMPORTANT: Fix should check the owners table and delete any row that has the fixed SN.
  8. NOTE: If there is only one ticket provided and that ticket is from the RAIDA itself, the AN will be changed to that asked for by the client.

Fix Algorithm

Fix allows you to fix multiple CloudCoin using tickets that it got from the Get_Ticket service. Each ticket can only be used one time per RAIDA. Each RAIDA can use the same ticket to fix. This allows the client to use all the tickets returned from a Get_Ticket request to fix all the fracked coins on all the RAIDA without needed to go and get more tickets. The Fix then calls the "Validate Ticket" service and sees what SNs are returned. If 13 or 25 RAIDA return the same SN, that SN's ANs are changed to the PAN supplied by the Client in Version 0 of the Fix command. Version 1 requires the caller to supply a PAN Generator instead of PANs.


Example Request Body with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN
SN SN SN
SN SN SN
SN SN SN
PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG //PAN Generator that will be used to generate PANs.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 0 through RAIDA 4.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 5 through RAIDA 9.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickts for RAIDA 10 through RAIDA 14.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 15 through RAIDA 19.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 20 through RAIDA 24.
E3 E3


The PAN is determined by concatenating the RAIDA ID, Serial Number and the PG. Like this

  1. The Client will generate a 16 byte random seed.
  2. The Client will send this seed to the RAIDA. This seed is called a "PAN Generator".
  3. The Client and the RAIDA will use an algorithm to figure out what the Authenticity numbers will be for each serial number that fixes.
  4. The Authenticity numbers for each serial number will be calculated by concatenating the RAIDA Number (String), the Coin's Serial Number (string) and the Seed that will be (converted into a 32 character string) together.
1 + 1632435 + 9195C7A60CF0471BBE9B66144F5681C5 and then running an MD5 hash agains that.

Then the concatenated string is:

PAN = MD5( "116324359195C7A60CF0471BBE9B66144F5681C5");

So the AN will be:

fd1495be732ab2f6959559f3041c72c0

Example With Actual Bytes for an attempt to fix RAIDA 12 for four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
00 00 01
05 00 23
05 00 24
05 00 25
13 0A B9 AD 18 5E 45 1C 8E F4 11 13 74 95 65 FB
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 //NO Tickets for RAIDA 0 through RAIDA 4.
8A F4 55 E7 00 00 00 00 A4 BB 4A BF B6 5C 74 87 00 00 00 00 //Tickets for RAIDA 5, 7 and 8. RAIDA 6 and 9 are empty.
00 00 00 00 08 4C 38 8B 00 00 00 00 00 00 00 00 00 00 00 00 //Tickets for RAIDA 11. RAIDA 10,12, 13 and 14 are empty.
00 00 00 00 75 E5 6A A4 00 00 00 00 56 3C 57 72 00 00 00 00 //Tickets for RAIDA 16 and 18. RAIDA 15,17 and 19 are empty.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 //NO Tickets for RAIDA 20 through RAIDA 24.
E3 E3
Response body if all fixed Response body if all failed to fix Response body if mixed with fixed and fails:
No response body No response body MS

Fix V2

Version 2 of Fix requires the caller to specify the PAN and does not use a PAN Generator

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 0 through RAIDA 4.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 5 through RAIDA 9.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 10 through RAIDA 14.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 15 through RAIDA 19.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 20 through RAIDA 24.
E3 E3

Fix V3

Version 3 is just for debugging. It shows what the response from the validate ticket response from other RAIDA. The Request is the same as V2.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 0 through RAIDA 4.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 5 through RAIDA 9.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 10 through RAIDA 14.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 15 through RAIDA 19.
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Tickets for RAIDA 20 through RAIDA 24.
E3 E3

Response:

ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST ST //25 Statuses of Validate Ticket returns.
SN SN SN //First Serial Number returned from RAIDA 0.
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN //First serial Number returned from RAIDA 24

Status codes:

0x00 means that the server did not have a ticket to send to that RAIDA.

0x01 means that the server was not able to get the IP Address of the RAIDA.

0x02 Means that the server was unable to open a port to talk to the other RAIDA

0x03 Means that the server received no response from that RAIDA.

0x04 Means that at least one serial number was returned.

0xXX Any other codes means that this is the status code returned by the RAIDA.

VALIDATE TICKET

This is the only off-ledger protocol where RAIDA talk to each other.

The Validate Ticket protocol allows RAIDA to confirm that a friendly RAIDA says that the coin is authentic. One ticket per call. The Validate ticket protocol uses the same encryption as all others except it uses SNs from its group of 1000 SNs. RAIDA 0 has 0-999, RAIDA 1 has 1000-1999. RAIDA 24 has 24000-24999 and so on.

EXAMPLE BODY OF REQUEST

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
RI //The Raida that is sending the REQUEST
TK TK TK TK
E3 E3

EXAMPLE REPLY: Shows seven serial numbers returned. The number is divisible by 3 bytes.

SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN

PUT KEY

Command # 6

The Upload Encryption Key service helps clients share encryption keys with RAIDA that is has no common secret with. Like RAIDA that are fracked on all coins.

This allows a client to give a RAIDA an Encryption Key that can later be moved to another RAIDA and used for encryption. Note that all RAIDA will have a "Key" table.

First, the client will create a random three-byte number (From 0 to 16777215) called the Key ID. The Client will then hash this Key ID and send that hash in the Request Body along with a 16 byte random Encryption Key.

Note: The RAIDA should not allow keys to exist for more than five minutes and there should be no more than 100,000 keys until they start to over write each other.

How a client can establish an encrypted connection with a RAIDA that it does not share a secret with:

Command Client Request Body Responding RAIDA Action Response
PUT KEY Generates random 3 byte Key ID and random 16 Byte Encryption Key. Includes a hash of Key ID and the 16 Byte Encryption Key Makes a hash of the Encryption Key. Stores the Hash of the Key ID and Hash of Encryption Key in the Key Table Success
MOVE KEY Receives move Request from Client with the Key ID to move jdk Receiver hashes Key ID and Checks in Key Table Returns the Encryption Key from the Key Tabls (Which is actually a hash of the real key)
REQUEST MOVE Client Sends Key ID Contains Key ID And RAIDA ID where Key is Stored Hashes the Key ID and seizes it from the other RAIDA Places the response (Hash of Key) in the Key Table and returns Success
Fix (with no key) Client uses the Encryption Type 2 (the EN byte in the request header) and encrypts the body with the hash of the Encryption Key. The 3 byte SNs in the Header is the Key ID. Body is the Fix request body encrypted with the hash of the Encryption Key RAIDA gets the Encryption Key from the Key Table and uses it to decrypt the body. The Encryption Key is then removed from the Key Table. The Coin IDs can be random numbers used as the Nonce along with the SNs (Key ID). All Pass, All Fail or mixed. Encrypted with same Encryption Key found in the Key Table.

Resulting Key Table Contents

Key ID Key
Key ID Hash of Encryption Key

Example Request:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
IH IH IH // (Note: Client is actually sending its 3 bytes of a hash of the real Key's ID. This will be be used as a unique identifier in the Key Table).
KY KY KY KY KY KY KY KY KY KY KY KY KY KY KY KY //Encryption Key (16 Bytes)
E3 E3

Example response:

//Status is set to success.


MOVE KEY

Command #7

The "Move Encryption Key" service is used to move an Encryption Key from the Responding RAIDA to the Requesting RAIDA. An Encryption Key can only be seized once and then it is removed from the Responding RAIDA's Key Table and placed in the Requesting RAIDA's Key Table.

The Request Body will include the three byte Key ID. The responding RAIDA will make a hash of this Key ID and use the first three bytes of the hash to find the key in its Key Table. The Responding RAIDA will not actually respond with the Encryption Key associated with the Encryption ID. Instead, the responding RAIDA will send a hash of the Encryption Key.

This hash will be surrounded by spacers to make it impossible to match with the Key ID that is sent clear text with the encrypted Request Seizure body.

Steps:

  1. Generate a 7 digit hexadecimal character string as the spacers code like: 3E 02 32 5. Each hexadecimal number represents the length of one of the random arrays of hexadecimal numbers.
  2. Turn the 3 byte Key ID into a hexadecimal string. For example, the Key ID number "13,360,9921" becomes "CB CF 19".
  3. Weave the spacers and the ID Key hex characters together. If the first spacer is three, there will be three random hex numbers first. The Key CBCF19 and the Spacer 3EFE320C2 becomes "XXX-C-XXXXXXXXXXXXXX-B-C-XX-F-XXX-1-XX-9-XXXXX". The 'X's are random hexadecimal numbers between 0 and 15. It is ok to pad the last number with a random hex if the number is not even.

Note: Each hex character in the Spacer Hex's String generates that number of random characters. So if the Spacer string starts with 'A' then ten random numbers will added, then the first character of the Key ID. The if the second character of the spacer key is 'E' then 15 random numbers will be added as space between the next character in the key 'B'. 'S's shown below are Random Hexadecimal numbers. There will be between zero and 15 random numbers between each key's hex.


Example Encrypted Request Body:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SP SP SP SP SP //Five bytes that are viewed as 8 hexadecimal numbers.
SS SS SS SS KS SS SS SS SK SS SS SS SS KS SS SS SS SK SS SS SS SS KS SS SS SS SK SS SS SS SS KS SS SS SS SK SS SS SS SS //S means spacer, K means Key part. The length of this will vary but will usually be around 43 bytes log.
E3 E3

Example Request Using Hex where the key is Decimal 1,358,4699 or "14 BA 85" hex. And the spacer is "68 3B 73 1"

7C3CB1-1-5F430515-4-836-B-A5B941730AE-A-3198E75-8-D1E-5-9 //Hyphens added between key parts.

Resulting Key Table Contents

Key ID Key
Key ID Hash of Encryption Key

REQUEST MOVE

Command #9

Client tells one RAIDA to get a key from another RAIDA. NOTE: This command uses Encryption type '0' and is unencrypted.

Header

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
KI KI KI // The three byte Key ID.
RI // RAIDA ID.
E3 E3


The RAIDA will go fetch the key using the MOVE ENCRYPTION KEY service and then it will put what is returned into its Key Table. The Key Table will end up containing the real Key ID and a Hash of the original Encryption Key.

Resulting Key Table Contents (Same as SEIZE ENCRYPTION KEY)

Key ID Key
Key ID Hash of Encryption Key

FIX WITHOUT KEY

This is the same as FIX. The only difference is that the Encryption type will be 2. 2 means use AES 128 CTR but get the key from the Key Table. The key will be in the three SN SN SN bytes in the header. These will also be used as part of the nonce along with all the other usual nonce bytes. Once the Encryption key is recovered from the Key Table, the body of the Fix request can be decrypted and the Encryption Key removed from the Key Table. The response will be encrypted using the same key.


IDENTIFY

This service allows the person to remember the ANs of coins. This makes it easy for the person to remember and store in mind. The entire table of ANs must be searched.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
E3 E3

Returns: (Five Serial Numbers were found with this AN)

SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN

NEWS

Returns the url of a news server.

//No Body

Example Response:

//URL of a website HH TT MM LL // // :: NN EE WW SS .. CC OO MM // // NN EE WW SS .. HH TT MM LL E3 E3

LOGS

This service will only return logs for RAIDA Administrators. The serial numbers must be 1 though 1000.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
DT DT DT DT DT DT DT DT DT DT DT DT DT DT //Data and Time Start Reading (00 00 00 00 means now)
LT LT LT //How many records to read
E3 E3

Example Response:

//Returns a bunch of html with one byte per ascii character.
RT //Record Type
TS TS TS TS TS TS TS TS TS TS TS TS//Time Stamp
ST //Status
ME ME ME ME //Message

VERSION

This service will return the date of the last update.

//No Body

Example Response:

html 2021‐08‐10 
18:17:54


PANG

PANG means "Proposed Authenticity Number Generator". The client sends the Serial Number, Authenticity Number and the Proposed Authenticity Number Generator. The RAIDA then generates the PANs based on the PANG. The rules for generation are to take the RAIDA number, the Serial Number and the PANG and concatenate them:

WARNING: Client should send a different PG to each RAIDA otherwise the coin will be stolen by any RAIDA admin.

Sample PANG Outcomes

RAIDA ID Serial Number PAN Generator Seed Resulting Concatenation Resulting hash (PAN)
0 99832 3031900e6c47411da57192574faa61c3 0998323031900e6c47411da57192574faa61c3 572aadc4c4e4cd5a7f0bff6adbe91828
24 16777215 5ab8661c15c44bc995f5bda379efdaf4 24167772155ab8661c15c44bc995f5bda379efdaf4 ab17712695c31d0bcbbff2fc95b8e2c8
9 2 ed797feb38b0416ba2bd1d7db29f68d7 92ed797feb38b0416ba2bd1d7db29f68d7 c31f32f422b28efa484b0c6f376c1157

The PANG generates a ticket in the same manner as POWN.

Request with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
E3 E3

CloudCoin does have a "Strings Attached" vulnerability. To After the POWN service POWNs all the coins, it must check all the tickets in the ticket table to see if the coins that have just been powned are in those tickets. If any coin is found in the ticket folder, that ticket must be deleted to make sure the coin is not turned back to the former owner.

Return status will be AllPass, All Fail or Mixed. Status are the same as POWN. Four bytes of zeros are also returned. These are for future use incase we want to include a ticket.

MT MT MT MT MS //MS is only included if it is mixed.

ANG (Phase II)

AN Generator. Allows the client to send the Serial Number, "AN Generator" and PANs. The RAIDA then generates the ANs based on the ANG. The rules for generation are the same as PANG.

WARNING: Client should send a different PG to each RAIDA otherwise the coin will be stolen by any RAIDA admin.

The ANG will also create a "Master Ticket". This ticket can be used by the client to prove its authenticity to other RAIDA. The Master Ticket can be claimed one time by each RAIDA server. After the ticket grows old. It should be removed from the table.

After the Master Ticket is generated, and the response is sent to the client, the ANG service will write the Master Ticket to the Tickets table and write all SNs in one column. Also, all of the RAIDA columns in the Ticket Table will be set to '1' which means that that RAIDA has not claimed that ticket.

The ANG also receives a special Sub header called the Email Hash. This can be placed in the Email Hash table. This is an unencrypted 16 byte hash of the users email tacked on the end of the request header. If it is all zeros, then no email hash has been sent. Request with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
E3 E3
Response body if all passed Response body if all failed: Response body if mixed with passes and fails:
MT MT MT MT no response body MT MT MT MT MS //The MT are just zeros. 0x00 00 00 00. They are for future use.

ANGPANG (Phase II)

AN and PAN Generator. Allows the client to send the Serial Number, AN Generator and PAN Generator. The RAIDA then generates the ANs based on the ANG and PANs based on the PANG. The rules for generation are the same as PANG.

The ANGPANG will also create a "Master Ticket". This ticket can be used by the client to prove its authenticity to other RAIDA. The Master Ticket can be claimed one time by each RAIDA server. After the ticket grows old. It should be removed from the table.

After the Master Ticket is generated, and the response is sent to the client, the ANG service will write the Master Ticket to the Tickets table and write all SNs in one column. Also, all of the RAIDA columns in the Ticket Table will be set to '1' which means that that RAIDA has not claimed that ticket.

The ANGPANG also receives a special Sub header called the Email Hash. This can be placed in the Email Hash table. This is an unencrypted 16 byte hash of the users email tacked on the end of the request header. If it is all zeros, then no email hash has been sent. Request with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG //AN Generator
PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG //PAN Generator
SN SN SN
SN SN SN
SN SN SN
SN SN SN
E3 E3
WARNING: Client should send a different PG to each RAIDA otherwise the coin will be stolen by any RAIDA admin.
Response body if all passed Response body if all failed: Response body if mixed with passes and fails:
MT MT MT MT no response body MT MT MT MT MS //The MT are just zeros. 0x00 00 00 00. They are for future use.


RECOVER (Command 10)

The recover method is used to allow users to recover their lost CloudCoins. The customer would have first had to embed a hash of their unforgettable secret into their AN. Then they must send the serial numbers of their lost coins and their email. Unlike the other services, this service costs money. The reason it costs money is to keep people from trying to guess in order to steal coins.

Unforgettable secret

The unforgettable secret is a 16 byte GUID most likely created by a has of some other data. As far as the RAIDA goes, it does not matter how this number is created.

The suggested way of creating an unforgettable secret is to have three parts:

  1. Government ID (Like Social Security Number for Americans with no hyphens)
  2. 2nd Government ID (Like Driver's License for Americans)
  3. First 10 numbers in a significant Book ISBN. (From a book that the user will remember that they used as a code)

ENCRYPTED PAYLOAD WITH THE PAYMENT COIN.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
PC PC PC //Serial Number of the payment coin
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN (AN of the payment coin)
UF UF UF UF UF UF UF UF UF UF UF UF UF UF UF UF //unforgettable secret
PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG //PAN Generator
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
E3 E3

RESPONSE: //status of all pass or status of all fail or mixed. If Mixed then each bit represents 1 for pass and 0 for fail MS MS MS ....

Response Status Code
130 Payment Coin Counterfeit
All Pass 241
All Fail 242
Mixed 243

Algorithm

  1. The RAIDA checks to see if the payment coin is authentic. If it is, the payment coins will be assigned a random guid and the Months From Start will be changed to 1.
  2. The RAIDA compares the last four bytes of the UF (Unforgettable Secret) with the last four bytes of the AN for every serial number the client provides.
  3. If the numbers are the same then that coin has its AN changed to an AN created by the seed provided (PG).
  4. The RAIDA responds to the client with the outcome.

REPORT LOST

This allows people to report coins that have been lost. This can be used to help recover coins that have no

There is a file folder for every month.

ENCRYPTED PAYLOAD WITH THE PAYMENT COIN.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
PC PC PC PC (Serial Number of the payment coin)
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN (AN of the payment coin)
MFS //The months from start that the coins were lost.
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN ...
EM EM EM EM EM EM EM EM EM .. //The RAIDA Mail address will be 256 fixed bytes. There will be a \n at the end (byte 256).
E3 E3

RESPONSE IF THE PAYMENT COINS WAS GOOD OR BAD

//status will be "Report Received"

Note that the service does not tell the caller if there actually are coins that are actually lost.

RESPONSE IF THE PAYMENT COINS WAS GOOD OR BAD

//Status will be "request received" without any indication if the coins were found or not //If the payment coins is bad it will say "Bad Payment Coin". They must be CloudCOins

Algorithm

  1. The payment coin is checked to see if it is Authentic
  2. Program sends a response "Request Received"
  3. The email is hashed.
  4. Each serial number is checked against the Email Recovery table.
  5. If coins are there and match, a list of coins is sent the RAIDA Mail ID that matches the RAIDA Number.

Protocol to send to RAIDA Mail:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN //Coin to be spend to recover by email.
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
EM EM EM EM EM ....EM EM EM //256 fixed. Email address ends with a null character.
E3 E3

UPGRADE COIN

This command takes the ticket provided and sends it to the legacy server to see if the ticket is good. Maximum Coins: 400 Sample Request:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG //PAN Generator. Seed to create ANs TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //Legacy 22 Byte Ticket for Legacy RAIDA E3 E3

Response:

//Status will be either "all pass", "all fail" or "mixed" //if mixed the body will be like: MS MS MS MS ... one bit for each coin.

Algorithm

  1. The Super RAIDA connects to the legacy RAIDA over port 18000. The Super RAIDA will have the actual IP address of its legacy RAIDA and will connect directly.
  2. The connection is not encrypted and uses UDP.
  3. The only parameter that is passed is the 22 byte ticket and a random GUID that is called the receipt number.
  4. The legacy RAIDA will respond with a maximum of 400 serial numbers and it will remove these SNs from Network 1.
  5. The Super RAIDA will receive a stream of bytes that can be broken into 3 byte serial numbers.
  6. If the Legacy Returns an error, the Super RAIDA will tell the client about the error using an error status.
  7. If there is no response from the Legacy RAIDA, the program will need to call the check receipt service to see if the transaction was logged. If not then the client should be told that the call failed and try again. Or the RAIDA could try again instantly.
  8. The Super RAIDA will change the ANs to an AN based on the seed for each Serial Number returned.
  9. Now the coins have been upgraded from the legacy to the super.
  10. The Super RAIDA will then send the status back to the client along with any mixed results if needed.

NOTE: The Legacy will have a special program on it that can connect to UDP and MySQL. This program will be called the "Upgrade Helper"

Errors

80 Old RAIDA did not respond. 81 Old RAIDA's response was not understood.

HOST

Returns the IP addresses and ports of the servers that have the stripes

Request has no body

Response

IP IP IP IP PO PO PO //Stripe 0's IP and Port number
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO
IP IP IP IP PO PO PO //Stipe 31 IP and Port numbers

This data will be found in a file called "stipe_IPs.bin"