Request Headers

From CloudCoin Wiki
Revision as of 22:42, 25 January 2022 by Seanw (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


All requests to the RAIDA Bank have a Request Header and a Request Body.

The Request Header is not encrypted. The Header has a fixed length of 22 bytes.

RAIDA Protocol Header (22 Fixed Bytes)

Request Header Codes Explained
index Code Name Notes
0 CL Cloud ID Future Use. 0 for now.
1 SP Split ID Future Use. 0 for now.
2 RI RAIDA ID An integer between 0 and 24. Should match the RAIDA ID in the config file.
3 SH SHARD ID An integer between 0 and 31. Should match one of the the Shard IDs in the config file.
4 CM Command 0x00 //will be zero for all numbers below 255
5 CM Command 2 Will be the least significant number (This is the command number)
6 VE Command Version An integer that is zero but could be different as standards evolve.
7 ID Coin ID 1 Allows many coins to be on the same RAIDA. Including CloudCoin, NFTs and Identification coins.
8 ID Coin ID 2 Least significant number
9 NO Nonce 1 / Key ID The Nonce is used in AES CTR 128 Bit Encryption. There are 64 Bits in the Request Header.
10 NO Nonce 2 / Key ID The Key ID is used in the PUT KEY command as the identifier for the key in the key table.
11 NO Nonce 3 / Key ID
12 EC Nonce 4 / Echo 1 Client can send two bytes to the server and the server will echo these two bytes in the response.
13 EC Nonce 5 / Echo 2 Another echo
14 RE Reserved This is for future use in case more info is needed to make UDP more reliable
15 UD Total UDP Packets This tells the RAIDA how many UPD packets are part of the request. The max is 64 (see How UDP works below)
16 EN Encryption 0x00 means no encryption. See encryption codes table.
17 ID Coin ID 1 The coin ID of the coin used to encrypt (Most Significant Byte)
18 ID Coin ID 1 The coin ID of the coin used to encrypt (Least Significant Byte)
19 SN SN 1 / Nonce 6 /Key ID The SN of coin whose AN was used as a shared secret for encryption.
20 SN SN 2 / Nonce 7 /Key ID
21 SN SN 3 / Nonce 8 /Key ID
  • Note: Many bytes do two jobs. The SN will be the serial number of the coin to be encrypted and part of the nonce.

Command Codes
Command Code Command Description
0 POWN Change authenticity numbers (Password Own)
1 Detect Detect if a coin is authentic
2 Find Check if an AN or PAN is authentic
3 Fix Synchronize coins using Kerberos tickets
4 Echo Check connectivity to RAIDA
5 Validate Ticket See if a Kerberos Ticket it real
6 Upload Encryption Key Place an AES key on a trusted RAIDA
7 Take Key One RAIDA takes a key from another RAIDA
8 Identify Not implemented
9 Request Move Client requests the RAIDA take a key from another RAIDA
10 Recover (Phase 2) Get a coin that has been lost
11 Get Ticket Request a Kerberos Ticket from a RAIDA
15 Version The version of the RAIDA software
16 News Not implemented
17 Logs Not implemented
19 Report Lost Report a coin that has been lost
20 ANG Not Implemented
21 PANG POWN with a PAN generator (seed) instead of PANs
22 ANGPANG Not Implemented
30 Free ID Get an ID coin that can be used for a Skyvault account
100 Deposit Upload CloudCoins into a Skyvault
104 Withdraw Remove CloudCoins from a Skyvault
108 Transfer Move coins from one Skyvault account to another.
110 Balance See how many CloudCoins are in Skyvault account
114 Show Coins See the coin serial numbers in a Skyvault
115 Show Coins By Type See coin type table
130 Show Statements See history of transaction for a Skyvault
131 Delete ALL Statements remove all history of transaction in a Skyvault
132 Show Payment Show funds that have been received by others
150 Sync Transfer Add Tell a RAIDA that it needs to add coins to a Skyvault
152 Sync Transfer Delete Tell a RAIDA that it needs to delete coins from a Skyvault
215 Upgrade Coin Turn in old coins and get a ticket of new coins
216 Claim Coin Get new coins from a ticket

Coin IDs
Code Meaning
00 00 00 00 00 Identification Coins
00 00 00 00 01 CloudCoin
00 00 00 00 02 NFT

Encryption Codes
Code Name Description
0 No encryption Clear Text
1 128 AES CTR Using shared secret (AN)
2 128 AES CTR from Key Table 5 bytes ( 2 bytes random number, 3 bytes Key ID)

Request Body Codes
Code Bytes Name Notes
CH 16 Challenge Used for mutual athentication. The Client sends a 4 byte number to the RAIDA. The RAIDA create a hash of this number and returns the first 4 bytes of this hash.
OW 3 Serial Number 4 byte Integer. Serial Number of coin to be authenticated.
AN 16 Authenticity Number 16 bytes of random bytes.
PA 16 Proposed Authenticity Number The new AN if the AN is authentic (only used in POWN)
TK 4 Ticket Used only in Fix fracked RAIDA. This ticket comes from other RAIDA.
EM 256 Email address (Used only in Recover) A fixed 256 characters long string. The email address ends in a null code.
SE 8 Seed Used to create the ANs. $seed2 = THIS_NODE_NUMBER + $sn + $se; $pan = md5($seed2);
KI 16 Key ID Used to create a shared key. A number between 11,0001 and 11,020,000
PG 8 Proposed Authenticity Number Generator The PANG is used as a seed to calculate an AN so that the client does not have to download it. $seed2 = THIS_NODE_NUMBER + $sn + $pang; $pan = md5($seed2);
3E 2 End of Command This tells the server that one command has ended and another may follow (will have only one command in phase 1 so this is just there for future use) This is "0011 1110" binary "3E" hex or the character ">".

Coin Type
Type Code Name Description
0 Just Received This coin is new and not been processed by the owner. Anyone can send a type 0
1 Payment This coin was sent for a specific reason. Check the memo for details
2 RAIDA Payment This coin was sent to pay a RAIDA
3 Change This coin can be used as change for people who send the coin to a merchant
4 Public Change This coin can be used by anyone to create change
5 locked This coin cannot be moved without the owner 100%
6 processed This coin has been changed by the owner
200+ Any Code over 200 are user defined

How The UDP Works

UDP is used instead of TCP. The UDP protocol can be made to be much more reliable by following this protocol.

1. Only the first packet that you send will contain the 22 byte header. All following packets will not contain a header.

2. Each packet will be no more than 1024 bytes long. This will keep the bytes from being separated and arriving out of order.

3. The 15th byte of the Header Packet will contain the total amount of packets that the client is sending.

4. There may not be any more than 64 packets sent in one request.

5. It is up to the client to decide how many bytes each packet will have.

6. However, to make it so that it does not matter which order the packets arrive in, you can alter the requests so that coin serial numbers, authenticity numbers and PANs are not

6. The last packet that is sent will contain the 0x3E 0x3E. These bytes may be used in the future or ECC purpose but are there now just as a place holder.