Authenticator

• Purpose:

The purpose of the authenticator is to make pown (password own) cloudcoins with the RAIDA and to write the coins with the new PANs to the Detected folder.

The Authenticator works in two modes that have to do with the way the PANs are generated. In Default mode, the PANs are generated completely random. Detection Mode sets the PANs to be the same as the ANs. Email Mode inserts a hash of the email address into the last octet of the PAN but keeps the first three octets random.

• Configuration

The Authenicator reads the user's configuration file to see if there is a recovery email. If there is, the recovery email is used as part of the PANs. If there is no recovery email, then then no recovery email will be included in the PAN.

Location of the config is C://users/[username]/documents/CloudCoin/Accounts/DefulatUser/config.txt

             {
             "email":"thisistheemail@mycompnay.com"
             }
            

or if not configured

             {
             "email":""
             }
            

• How To Start:

The Authenticator starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

The starter program will launch the Authenticator by using a command line command.

java Authenticator C:\\Program Files\CloudCoin\Authenticator

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

Authenticator myAuthenticator = new Authenticator("C:\Users\[username]\Documents\CloudCoin");
MyAuthenticator.pown(); //changes all ANs to PANs generated like random GUIDs

• Event that Starts:

When files are dropped into the Suspect folder, the Authenticator starts its' work

• Log Files:

Location of Log Files: CloudCoin/Accounts/DefulatUser/Logs/Authenticator

Number of Log Files: One log file is created every day. So one per day of use.

Naming convention of Log File:

\ 2018-07-2018.txt

Contents of Log Files:

2018-07-27,18:54:46.142,[Authenticator],[Result],No 731,SN:3781067,P/F,25/0,Pass,ppppppppppppppppppppppppp
2018-07-27,18:54:46.142,[Authenticator],[Result],No 732,SN:3781068,P/F,19/6,Fail,pfppfppppppfppppffppppppf
• How it works:

Note: The GUI should have had the Echoer echo before the Authenticator is called to work. The GUI must verify that the RAIDA is healthy enough to authenticate by looking at the Echo logs.

If the RAIDA is healthy, (more than 20 ready), the Authenticator is called by a command. The Authenticator gets the URLs of the RAIDA from within the 25 echo log files. The Authenticators then the user's config.txt file to see if there is an email that will be included in the PAN. (See config file below)

In order to generate a PAN that includes the email recovery, the algorith is as follows:

Generate a random GUID such as "0F799311-B1774110-8B85D0F9-CF0BD13F" (hyphens added for readability).

Take three components and concatenate them in order. The components are the CloudCoin's serial number, The RAIDA number that corresponds to the AN and the users email address.

In order to generate a PAN for RAIDA5 for Serial number 16,777,216 for user Sean@Worthington.net we would derive:

"167772165sean@worthington.net"

Note that we remove any commas in the numbers, leading zeros in the RAIDA number and turn any emails to lowercase.

Then we generate a MD5 has based on this: https://passwordsgenerator.net/md5-hash-generator/

The hash for 167772165sean@worthington.net is "34F2804F40039049EEEE097ADA6404A8".

We take the first 24 characters of the random GUID and add the first 8 characters of the MD5 Hash.

Our PAN will be: "0F799311-B1774110-8B85D0F9-34F2804F"

Before sending the detection requets, the Authenticator will delete all the contents of the Predetect folder and then move the coins from the Suspect folder to the Predetect folder. Then it will use the multi-detect protocol and store the results in the Detected folder. The coins that are put in the Detected folder will have the new PANs except if the RAIDA returned 'e' for error or if that RAIDA was not ready (known because it failed to echo) so then it will get a 'u' for untried and keep its AN. If there was no response from the RAIDA, it is assumed that the RAIDA got the request and the PAN is used. If there are too many non responses, the coin will become lost and the loss fixer will figure out if it should use the ANs or PANs.

The Authenticator can only send 400 coins to the multidetect service at a time. If will have to do more coins in batches.

• Test Design:

Test 1: Testing POWN with the RAIDA unavailable.

Outcome: Coins are moved to the Detected folder. Inside their "pown" is going to equal "nnnnnnnnnnnnnnnnnnnn"

1. Write the Fake RAIDA Host file to the computer computer's host file (c:\windows\system32\drivers\etc\hosts). The fake RAIDA host file can be found at: https://fakeraida.cloudcoin.global/index.php

2. Call a command to the fake raida to set all the raid to no-respond use an https Get call. Note: Change the password at the end of the call

         https://fakeraida.cloudcoin.global/updateFakeRaida.php?echo_0=Ready&delay_0=212&s0=n&echo_13=Ready&delay_13=200&s13=n&echo_1=Ready&delay_1=203
         &s1=n&echo_14=Ready&delay_14=200&s14=n&echo_2=Ready&delay_2=200&s2=n&echo_15=Ready&delay_15=200&s15=n&echo_3=Ready&delay_3=300&s3=n&
         echo_16=Ready&delay_16=200&s16=n&echo_4=Ready&delay_4=100&s4=n&echo_17=Ready&delay_17=200&s17=n&echo_5=Ready&delay_5=200&s5=n&
         echo_18=Ready&delay_18=197&s18=n&echo_6=Ready&delay_6=213&s6=n&echo_19=Ready&delay_19=200&s19=n&echo_7=Ready&delay_7=200&s7=n&
         echo_20=Ready&delay_20=200&s20=n&delay_8=200&s8=n&echo_21=Ready&delay_21=200&s21=n&echo_9=Ready&delay_9=200&s9=n&echo_22=Ready&
         delay_22=200&s22=n&echo_10=Ready&delay_10=207&s10=n&echo_23=Ready&delay_23=200&s23=n&echo_11=
         Ready&delay_11=100&s11=n&echo_24=Ready&delay_24=200&s24=n&echo_12=Ready&delay_12=200&s12=n&password=changeme
         

3. Write a CloudCoin (does not have to be real) to the Import folder.

4. Command the Authenticator to Authenticate and wait up to 20 seconds.

5. Check the log files and see if they are in order (format is correct). Report Pass or Fail

6. Check the Detected Folder to see if the CloudCoin is there and if it has all 'n's as it pown value. Report Pass or Fail

7. Write the host file back to the way way it was to end the test.

• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Authenticator-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Authenticator

Backupper

• Purpose:

The Backupper is given the location that a backup is to be placed and then copies all the coins from the Bank, Fracked and Gallery Folders into a folder called "CloudCoin Backup 2018 Oct 13 2.31 pm".

• How To Start:

The Backupper starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java Backupper C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

Backupper myBackupper = new Backupper("C:\Users\[username]\Documents\CloudCoin");
MyBackupper.backup();

• Event that Starts:

The Backupper watches the command folder for an Backup command.

• Commands

There is only one Backup command allowed in the CloudCoin/Command/ folder and new Backup commands overwrite old ones. The Backupper should move the command into the CommandHistory folder before it begins.

             File Name: backup.command
             Contents:
                Backup all files to backup location
                {
                    "command":"backup",
                    "account":"default" or  "account":"2i2iu",  //backup default account or specific account
                    "toPath":"default"  or "toPath":"C:\\bla\\bla\\foo\\" //Place to put the backed up CloudCoins
                }
    Note: If the path is not provided, backup to default location. 
         

• Log Files:

The Backupper does not require log files.

• How it works:

The Backupper makes a copy of all the files within: Root/CloudCoin/Accounts/[AccountName]/Bank where AccountName will be DefaultUser.

The Backupper makes a copy of all the files within: Root/CloudCoin/Accounts/[AccountName]/Fracked where AccountName will be DefaultUser.

The Backupper makes a copy of all the files within: Root/CloudCoin/Accounts/[AccountName]/Gallery where AccountName will be DefaultUser..

The Backupper makes a copy of all the files within: Root/CloudCoin/Accounts/[AccountName]/Valut where AccountName will be DefaultUser.

The Backupper makes a copy of all the files within: Root/CloudCoin/Accounts/[AccountName]/Lost where AccountName will be DefaultUser.

The Backupper makes a copy of all the files within: Root/CloudCoin/Accounts/[AccountName]/Mind where AccountName will be DefaultUser..

The Eraser deletes all the files within: Root/CloudCoin/Commands/ and subfolders.

• Test Design:
1. 1. Delete all contents in the Bank, Gallery and Fracked Folders
2. 2. Now add two files to each of these folders.
3. 3. Command the Backuper to Backup.
4. 4. Make sure the backup contains all the files that were in the Bank, Gallery and Fracked Folders. Note that the Gallery will have jpegs.
• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Backupper-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Echoer

• Purpose:

The job of the Echoer is to see if the RAIDA can be contacted and if the RAIDA is healthy enough to pown coins. The Echoer will also record the results so that other Servants will not waste time contacting RAIDA that are offline.

• How To Start:

The Echoer is started by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java C:\Program Files\CloudCoin\Echoer\Main C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

Echoer myEchoer = new Echoer("C:\Users\[username]\Documents\CloudCoin");
MyEchoer.echo();

• Event that Starts:

The Echoer watches the command folder for an Depositer command.

• Commands

There is only one Backup command allowed in the CloudCoin/Command/ folder and new Depositer commands overwrite old ones. The Depositer should move the command into the CommandHistory folder before it begins.

             FileName echoer.command
            {
                "command":"echo"
            }
         

• Log Files:

There are 25 RAIDA Echo Status reports and one Echo Event log.

Location of status and log files: CloudCoin/Logs/Echoer/

Name of status files: 0_ready_netlatency_internaltime.txt //latency milliseconds such as 0_ready_340_2.37.txt //the internal latency is 2.3751258850098

There will be an array of logs files in the folder like:

            0_ready_300_1.32.txt
            1_ready_724_2.32.txt
            2_ready_1452_.54.txt
            ...
            22_notready_345_2.32.txt
            23_ready_300_.52.txt
            24_ready_87_.84.txt
         

Contents of Status files

    within file:
    {
        "url": "https://raida0.CloudCoin.global"
    }
    
    or
    
    {
    "url":"https://88.33.234.21:40009"
    }
    
    

Log file FileName: 2018.11.30.log //New log file every day.

File contents: //Contents First is the timestamp, a space, the request and then response.

    {
        "timestamp": "2018-11-20 19:14:45:999",
        "request": "https://RAIDA0.CloudCoin.Global/service/echo",
        "response": "{"server":"RAIDA0","status":"ready","message":"Execution Time (milliseconds) = 0.582","version":"2018-04-25","time":"2018-10-11 03:45:17"} "
    }
    

• How it works:

The Echoer echos all the raida useing the cloudcoin.global namespace such as: raida10.CloudCoin.global .

Any raida that do not reply will be echoed again using the backup IP addresses:
95.179.159.178
66.42.61.239
45.32.134.65
Note that these require the Port number to be included as well. Each RAIDA's port number is different. RAIDA0 is port 40000. Raida24 is 40024.
You can test the RAIDA access here:
https://95.179.159.178:40005/service/echo
https://66.42.61.239:40005/service/echo
https://45.32.134.65:40005/service/echo

The results are recoreded in the logs.

• Test Design:
To test the Echoer Servant:
Note: This test requires the use of the fake RAIDA.

1. Install the Fake Raida Host file in the Set the computer to use the Host file and set all Primary RAIDA at CloudCoin.Global and secondary RAIDA at bf00-40aa-b2dc-2319cf6a8079.red.
2. Erase the Echoer's Log files.
3. Command the Echoer to echo.
4. Check to see if the log files follow the standard and are within limits.
5. Now set the Fake RAIDA so that all the RAIDA are not ready.
6. Check to see if the Echoer times out in an less than 10 seconds.
7. The log files will be checked to see if the follow the standard and are within limits. All RAIDA not ready.
8. Now set just the primary DNS names of the RAIDA (CloudCoin.global) to not ready and the
9. The Echoer should automatically try to echo the backup domain if all the RAIDA on CloudCOin.Global are not ready.
10. Set the Fake RAIDA to set all CloudCoin.global to not ready and the bf00-40aa-b2dc-2319cf6a8079.red domain to ready.
11. The testing program will command the Echoer to echo again and see if the values are over written. The logs should show that the that DNS name is the second and not the first.
• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Echoer-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Eraser

• Purpose:

The Eraser deletes all log files and receipts. It will not erase the last status file or configuration files.

• How To Start:

The Eraser starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java Eraser C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

Eraser myEraser = new Eraser("C:\Users\[username]\Documents\CloudCoin");
MyEraser.eraseAll();

• Event that Starts:

The Eraser watches the command folder for an Erase command.

• Commands

There is only one Erase command allowed in the CloudCoin/Command/ folder and new Erase commands overwrite old ones. The Eraser should move the command into the CommandHistory folder before it begins.

             File Name: eraser.command
             Contents:
             {
                "command":"eraser",
                "account":"default"
             }
         

• Log Files:

Name of Log Files: The Eraser does not have log files.

Location of Log Files: The Eraser does not have log files.

Format of Log Files: The Eraser does not have log files.

• How it works:

The Eraser deletes all the files within: Root/CloudCoin/Logs/ and subfolders.

The Eraser deletes all the files within: Root/CloudCoin/Accounts/DefulatUser/Logs/ and subfolders.

The Eraser deletes all the files within: Root/CloudCoin/Receipts/ and subfolders.

The Eraser deletes all the files within: Root/CloudCoin/Accounts/DefulatUser/Receipts/ and subfolders.

The Eraser deletes all the files within: Root/CloudCoin/Commands/ and subfolders.

• Test Design:

Test 1 (Autonomous operation): The tester program will place one log file into every folder and sub folder listed in the How it works above. Then the Eraser will be started by the module tester. Then the test program will put a command in the command folder ordering the Eraser to erase all the files. The Test program will then verify that the log files have been erased. If they are errased the test has passed. If the files are still there, the test fails.

• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Eraser-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Errasier

Emailer

The email takes stack files that have been dropped into the Email folder by the Export folder and emails them to the targeted address and uses an email template that is designated by the command. There will be a subfolder in the EmailOut folder for "Sent" and "Templates."

Configuration

The files that are dropped in this folder must have the email that they are going to be sent to as the tag. You can see a sample of an eml file by looking at: example.eml.

The Emailer will look within the .eml file to find a tag "[CLOUDCOINS]" and it will replace that with the CloudCoin files. 250.CloudCoin.Sean@Worthington.net.eml

The Emailer must be able to contact an SMTP server. It will use the Main Config file to find the contact info to the SMTP server. The system is designed so that the user can download the "Protonmail Bridge". This will allow the Emailer to send messages encrypted.

Then the once the stack file is sent, it should be put in the Sent subfolder of the Email folder.

Reports

The Emailer should place the send email in the "Sent" file.

Testing

1. Empty out the "Email" folder
2. Place one stack file in the "Suspect" folder
3. Look and see if the email arrives and if it looks correct.

Emailer

Exporter

• Purpose:

The job of the Exporter is to move the CloudCoins from the Bank, Vaul and Fracked Folders where they can be given to someone else. The Exporter will also move Images from the Gallery.

• How To Start:

The Exporter starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java C:\\Program Files\CloudCoin\Exporter\Main C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

Note that there are only a few file times that are supported now {stack, monostack, jpg, csv}. The monostack only has one Cloudcoin per stack. Exporter myExporter = new Exporter("C:\Users\[username]\Documents\CloudCoin");
MyExporter.exportAmount("default,stack,100,"Here is the tag name");//Account number, file format, amount to export, tag
MyExporter.export("default,jpg,0,0,0,0,0,"Here is the tag name");//Account number, file format, ones, fives, twentyfives, hundreds, twofifties, tag


• Event that Starts:

The Exporter watches the command folder for an Erase command.

• Commands

There is only one Exporter command allowed in the CloudCoin/Command/ folder and new Exporter commands overwrite old ones. The Exporter should move the command into the CommandHistory folder before it begins.

Types

Type 0: .stack (One per file)

type 1: .stack (multiple coins)

type 2: .jpg (One per file)

type 3: .csv (multiple coins)

type 4: .png (multiple coins)

type 5: .mp3 (multiple coins)

type 6: QR code (Envelope code)

type 7: bar code (one coin per code)

             File Name: exporter.command
             Contents:
                {
                	"command": "exporter",
                	"account": "default",
                	"amount": 100,
                	"1s":0,
                	"5s":0,
                	"25s":0,
                	"100s":1,
                	"250s":0,
                    "type": 0,
                    "tag": "Appended to filename"
                }
         

• Log Files:

For the log files, a copy of the exported cloudcoins are put in this file.

Location of Log Files: CloudCoin\Logs\Exporter\.

Name of Log Files: Same as the files being exported.

Format of Log Files: Same as the files being exported.

• How it works:

The Exporter removes stack files from the bank folder and puts the in the export folder in the specified format.

• Test Design:

Test 1 (Autonomous operation): The tester program will place one log file into every folder and sub folder listed in the How it works above. Then the Eraser will be started by the module tester. Then the test program will put a command in the command folder ordering the Eraser to erase all the files. The Test program will then verify that the log files have been erased. If they are errased the test has passed. If the files are still there, the test fails.

• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Eraser-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Frackfixer

• Purpose:

The FrackFixer synchronizes all RAIDA to agree that a CloudCoin is authentic. When one RAIDA beleives that a coin is fake, the FrackFixer can collect tickets from trusting RAIDA and fix the error in the RAIDA. This version of FrackFixer only uses MultiFix. The old fix is no longer needed and may be phazed out. The FrackFixer requires four tickets.

• How To Start:

The FrackFixer starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java C:\Program Files\CloudCoin\FrackFixer\Main C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

FrackFixer myFrackFixer = new FrackFixer("C:\Users\[username]\Documents\CloudCoin");
myFrackFixer.fix();

• Event that Starts:

The FrackFixer watches the Fracked folder and goes to work when files go there.

• Commands

No commands.

• Log Files:

The FrackFixer has one file that it writes to and moves files from the Fracked folder to Bank. The FrackFixer creats 25 files that track the status of the RAIDA so that the FrackFixer can intielligently fix the coins.

Location of Log Files: CloudCoin/Accounts/DefaultUser/Logs/FrackFixer

Name of Log Files: Todays date: 2018.11.24.txt

Format of Log Files: The Eraser does not have log files.

The log files should include tabs to make it more readable.

Here is a sample log file after Multi-fix is called for three coins.

There are ****** placed before the start of ENUMERATING

            *********
            2018-07-27 18:54:46.142 [FrackFixer],[ENUMERATING], *, *, *, Unfacking coin 1 of 3
            2018-07-27 18:54:46.142 [FrackFixer],[ENUMERATING], *, *, *, Unfacking coin 2 of 3
            2018-07-27 18:54:46.142 [FrackFixer],[ENUMERATING], *, *, *, Unfacking coin 3 of 3
            2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 546, pepppppppfppppppppppppppp, RAIDA 01, Attempting to fix Using Corner 1 
            2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 547, pepppppppfppppppppppppppp, RAIDA 01, Attempting to fix Using Corner 1 
            2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 548, pepppppppfppppppppppppppp, RAIDA 01, Attempting to fix Using Corner 1 
            2018-07-27 18:54:46.142 [FrackFixer],[SUCCESS],      29 546, pppppppppfppppppppppppppp, RAIDA 01, Unfracked Successfuly
            2018-07-27 18:54:46.142 [FrackFixer],[SUCCESS],      29 547, pppppppppfppppppppppppppp, RAIDA 01, Unfracked Successfuly
            2018-07-27 18:54:46.142 [FrackFixer],[SUCCESS],      29 548, pppppppppfppppppppppppppp, RAIDA 01, Unfracked Successfuly
    		2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 546, pppppppppfppppppppppppppp, RAIDA 18, Attempting to fix using Corner 1  
    		2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 547, pppppppppfppppppppppppppp, RAIDA 18, Attempting to fix using Corner 1  
    		2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 548, pppppppppfppppppppppppppp, RAIDA 18, Attempting to fix using Corner 1  
    		2018-07-27 18:54:46.142 [FrackFixer],[FAILED],       29 546, pppppppppfppppppppppppppp, RAIDA 18, Trusted server failed to provide ticket for corner 1  
    		2018-07-27 18:54:46.142 [FrackFixer],[FAILED],       29 547, pppppppppfppppppppppppppp, RAIDA 18, Trusted server failed to provide ticket for corner 1  
    		2018-07-27 18:54:46.142 [FrackFixer],[FAILED],       29 548, pppppppppfppppppppppppppp, RAIDA 18, Trusted server failed to provide ticket for corner 1  
    		2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 546, pppppppppfppppppppppppppp, RAIDA 18, Attempting to fix using Corner 2 
    		2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 547, pppppppppfppppppppppppppp, RAIDA 18, Attempting to fix using Corner 2 
    		2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 548, pppppppppfppppppppppppppp, RAIDA 18, Attempting to fix using Corner 2 
    		2018-07-27 18:54:46.142 [FrackFixer],[FAILED],       29 546, pppppppppfppppppppppppppp, RAIDA 18, RAIDA 18 did not accept the tickets from corner 2
    		2018-07-27 18:54:46.142 [FrackFixer],[FAILED],       29 547, pppppppppfppppppppppppppp, RAIDA 18, RAIDA 18 did not accept the tickets from corner 2
    		2018-07-27 18:54:46.142 [FrackFixer],[FAILED],       29 548, pppppppppfppppppppppppppp, RAIDA 18, RAIDA 18 did not accept the tickets from corner 2
    		2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 546, pppppppppfppppppppppppppp, RAIDA 18, Attempting to fix using Corner 3
    		2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 547, pppppppppfppppppppppppppp, RAIDA 18, Attempting to fix using Corner 3
    		2018-07-27 18:54:46.142 [FrackFixer],[FIXING],       29 548, pppppppppfppppppppppppppp, RAIDA 18, Attempting to fix using Corner 3
    		2018-07-27 18:54:46.142 [FrackFixer],[SUCCESS],      29 546, pppppppppfppppppppppppppp, RAIDA 18, Unfracked Successfuly
    		2018-07-27 18:54:46.142 [FrackFixer],[SUCCESS],      29 547, pppppppppfppppppppppppppp, RAIDA 18, Unfracked Successfuly
    		2018-07-27 18:54:46.142 [FrackFixer],[SUCCESS],      29 547, pppppppppfppppppppppppppp, RAIDA 18, Unfracked Successfuly
    		2018-07-27 18:54:46.142 [FrackFixer],[REPORT],       29 546, ppppppppppppppppppppppppp, RAIDA **, Time spent fixing coin in milliseconds: 222 
    		2018-07-27 18:54:46.142 [FrackFixer],[REPORT],       29 547, ppppppppppppppppppppppppp, RAIDA **, Time spent fixing coin in milliseconds: 222 
    		2018-07-27 18:54:46.142 [FrackFixer],[REPORT],       29 548, ppppppppppppppppppppppppp, RAIDA **, Time spent fixing coin in milliseconds: 222 
    		2018-07-27 18:54:46.142 [FrackFixer],[BANK],         29 546, ppppppppppppppppppppppppp, RAIDA **, Coin moved to Bank
    		2018-07-27 18:54:46.142 [FrackFixer],[BANK],         29 547, ppppppppppppppppppppppppp, RAIDA **, Coin moved to Bank
    		2018-07-27 18:54:46.142 [FrackFixer],[BANK],         29 548, ppppppppppppppppppppppppp, RAIDA **, Coin moved to Bank
    		*********
    		2018-07-27 18:54:46.142 [FrackFixer],[ENUMERATING], *, *, *, Unfacking coin 1 of 1
    
            

• Reports

There are 25 Status reports (one for each RAIDA). These status reports allow the FrackFixer to learn when RAIDA do not return good tickets and when a RAIDA does not seem to be able to fix. This will keep the FrackFixer from wasting time.

            0.returnsticket.true.fixes.true.txt
            1.returnsticket.true.fixes.true.txt
            2.returnsticket.true.fixes.true.txt
            ...
            23.returnsticket.true.fixes.true.txt
            24.returnsticket.true.fixes.true.txt
            

• How it works:

The Frack Fixer will ensure that all RAIDA see the coin as authentic. It does this by looking at the POWN results in the stack file. It will fix all things that are not "p" such as "n","e","f" and "u".

It must fix n, e, and u, too if it is to fix fs.

The Frack Fixer will use 4 of the bad RAIDA's neighbours to fix the frack and will first get 4 tickets. There are for combination of neighbours that will work. Each combination is called a "Corner."

The Frack Fixer must track any problems found in the RAIDA so that it know if some of the servers are down and cannot be used to get tickets and are impossible to fix.

The Frack Fixer takes two runs at fixes. It starts by trying to fix RAIDA 0 and moves up to RAIDA 24. After that, it will reverse and fix from RAIDA 24 to RAIDA 0. This should ensure that the coin is fixed completely.

• Possible Steps for Frack Fixing using Multi Fix

1. Load all the CloudCoin in the fracked folder into an array of CloudCoins called "Fracked".

2. Begin looping through RAIDA

3. Start with RAIDA 0. Check all coins to see if any RAIDA 0 are 'e', 'n', 'u' or 'f'. If yes then add them to an array called "RAIDA0Fracked"

4. Log. Suppose there were six coins in the fracked folder and three of them needed to be fixed on RAIDA 0. Write

"2018-07-27 18:54:46.142 [FrackFixer],[ENUMERATING], *, *, *, Unfacking coin 16777216

"2018-07-27 18:54:46.142 [FrackFixer],[ENUMERATING], *, *, *, Unfacking coin 352265

"2018-07-27 18:54:46.142 [FrackFixer],[ENUMERATING], *, *, *, Unfacking coin 859264

Note that the last number is the coin's serial number.

5. Check the echo log to see if RAIDA 0 is ready and the Frack Fixers Status file to see if RAIDA 0 is fixable.

If not: Log for each of the three coins and then give up on fixing 0 and move to RAIDA 1 (Step 3 next RAIDA):

2018-07-27 18:54:46.142 [FrackFixer],[FAILED], 16777216, fppppppppfppppppppppppppp, RAIDA 0, RAIDA 0 not ready to be fixed

6. Set the corder to fix as Corner 1. Log the following:

2018-07-27 18:54:46.142 [FrackFixer],[FIXING], 16777216, fppppppppfppppppppppppppp, RAIDA0, Attempting to fix using Corner 1

2018-07-27 18:54:46.142 [FrackFixer],[FIXING], 352265, fppppppppfppppppppppppppp, RAIDA0, Attempting to fix using Corner 1

2018-07-27 18:54:46.142 [FrackFixer],[FIXING], 859264, fppppppppfppppppppppppppp, RAIDA0, Attempting to fix using Corner 1

6. Check the FrackFixer status files to see if corner 1 trusted servers are giving tickets. If not make a log notation and move on to corner 2

2018-07-27 18:54:46.142 [FrackFixer],[FAILED], 16777216, fppppppppfppppppppppppppp, RAIDA 0, Trusted server failed to provide ticket for corner 1

7. Make a multi-ticket request for all the four trusted Servers on the corner.

8. Check them to see if they are good. If any failed move on to the next corner and log:

2018-07-27 18:54:46.142 [FrackFixer],[FAILED], 16777216, fppppppppfppppppppppppppp, RAIDA 0, Trusted server failed to provide ticket for corner 1

9. Send the tickets to the Mulit fix server.

if Failure:

2018-07-27 18:54:46.142 [FrackFixer],[FAILED], 16777216, fppppppppfppppppppppppppp, RAIDA 0, RAIDA 0 did not accept the tickets from corner 1

If Success: 2018-07-27 18:54:46.142 [FrackFixer],[SUCCESS], 16777216, pppppppppfppppppppppppppp, RAIDA 01, Unfracked Successfully

10. If the coin was fixed move on to fix another RAIDA (Step 3). If the coin was not fixed, Go to Step 6 and increment the next corner unless the next corner is 5 (does not exist). Then go log 2018-07-27 18:54:46.142 [FrackFixer],[FAILED], 16777216, fppppppppfppppppppppppppp, Coin could not be fixed.

11. After you have attempted to fix all RAIDA 0-24, then do them in reverse, RAIDA 24-0. Sometime you must fix one RAIDA in order to fix another. So we have to give it two swipes.

12. Check the coin to see if it no longer has any 'f's.

if there are no more 'f's, move the coin to bank and log:

2018-07-27 18:54:46.142 [FrackFixer],[REPORT], 16777216, ppppppppppppppppppppppppp, RAIDA **, Time spent fixing coin in milliseconds: 222

2018-07-27 18:54:46.142 [FrackFixer],[BANK], 16777216, ppppppppppppppppppppppppp, RAIDA **, Coin moved to Bank

If there are still 'f's, keep the coins in the fracked folder and log

2018-07-27 18:54:46.142 [FrackFixer],[FAILED], 16777216, fppppppppfppppppppppppppp, Coin could not be fixed.

• Test Design:

Tests to come.

• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-FrackFixer-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

FolderMaker

FolderMaker

Grader

• Purpose:

The purpose of the Grader is to take files that have been put in the Detected folder and sort them out into the Counterfeit, Bank, Fracked and Lost Folders.

• How To Start:

The Grader starts by calling the language, the path to the executable and providing a path to the root folder the Servant will use:

java C:\Program Files\CloudCoin\Grader\Main C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

Grader myGrader = new Grader("C:\Users\[username]\Documents\CloudCoin");
MyGrader.grade();

• Event that Starts:

The Grader watches the Detected folder for any new files.

• Commands

The Grader has no commands but only listens to changes in the Detected folder

• Log Files:

The Grader writes to one log (one each day), one receipt and moves files from the Detected folder to other folders.

Location of Log Files: CloudCoin/Accounts/DefaultUser/Logs/Grader/.

Name of Log Files: 2018.11.25.txt

Contents of Log Files:

2018-11-20 19:14:45:999 [GRADER],[grade],SN,250CC,Moved,/path/

Receipts

Location of Receipt Files: CloudCoin/Accounts/DefaultUser/Receipts/.

Name Format of Receipt File: receiptID.txt such as 981f7a936abc490e95803fc7f54987f5.txt

The recipt is like a report and will be formated in the following way:

		  
{
        "receipt_id":"e054a34f2790fd3353ea26e5d92d9d2f",
	"time": "2016-49-21 7:49:PM",
	"timezone": "UTC-7",
	"bank_server": "ccc.cloudcoin.global",
	"total_authentic": 5,
	"total_fracked": 7,
	"total_counterfeit": 1,
	"total_lost": 0,
	"total_unchecked": 0,
	"receipt_detail": [{
			"nn.sn": "1.16777216",
			"status": "authentic",
			"pown": "ppppppppepppppppppppeppp",
			"note": "Moved to Bank"
		},
		{
			"nn.sn": "1:1425632",
			"status": "counterfeit",
			"pown": "fffffffffpfffffffffffffff",
			"note": "Sent to trash"
		},
		{
			"nn.sn": "1.956258",
			"status": "authentic",
			"pown": "ppppppppppppppppppppppppf",
			"note": "Moved to Fracked"
		},
		{
			"nn.sn": "1.15666214",
			"status": "lost",
			"pown": "pfpfpfpfpfpfpfpfpfpfpfpfp",
			"note": "Moved to Lost"
		},
		{
			"nn.sn": "1.15265894",
			"status": "lost",
			"pown": "ppppffpeepfpppfpfffpfffpf",
			"note": "STRINGS ATTACHED!"
		}

	]

}
		  

• How it works:

The Grader opens files placed in the Detected folder.

The names of the files placed in the Detected folder may contain a "receipt" or batch number in the tag portion of the stack file.

The Grader uses a grading alorith and moves the files into folder according to weather they are authentic, counterfeit, lost or fracked.

The Grader logs the actions.

NOTE: The receipt file should have already been created by the unpacker process. If it is not created, the grader should just put notes in the log file. If there is a receipt already in the receipt folder with the same receipt ID, the Grader writes over each coin in the receipt file with the new updated status.

• Test Design:

Tests design will come later

C

Place coins into the Detected folder (They don't need to be authentic)

Set one pown to "ppppppppppppppppppppppppp" this should go to Bank.

Set one pown to "fpppppppppppppppppppppppp" this should go to Fracked.

Set one pown to "pppppppppppppppppppffffff" this should go to Counterfeit.(Dangerous in advanced mode)

Set one pown to "ppppppppppppppppppppnnnnn" this should go to Bank. It is ok to have five no replys.

Set one pown to "ppppppppppppppppppppeeeee" this should go to Bank. It is ok to have five errors.

Set one pown to "pppppppppppppppppppnnnnnn" this should go to Lost. It is not ok to have more than five no replys.

Set one pown to "pppppppppppppppppppeeeeee" this should go to Lost. It is not ok to have more than five errors.

• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Grader-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Loss Fixer

• Purpose:

If more than six RAIDA do not reply why detecting, the coin is considered lost and placed in the Lost folder. The Job of the Loss Fixer is to take lost coins in the Lost folder and make them authentic. Lost coins are coins that were in the process of being authenticated but the RAIDA did not respond. So it is unknown if the CloudCoin is using its old ANs or its new PANs.

• How To Start:

The LossFixer starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java LossFixer C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

LossFixer myFixer = new LossFixer("C:\Users\[username]\Documents\CloudCoin");
myFixer.FixAll();

• Event that Starts:

The LossFixer should start when a coin is put in the lost folder.

• Commands

Ther is no command to start.

• Log Files:

Name of Log Files: [sn].[fixed or not fixed].txt example 166777882.Fixed.txt

Location of Log Files: Root/CloudCoin/Logs/LossFixer.

Contents of Log Files: Record of Every RAIDA Call to fix that CloudCoin.

• How it works:

The Loss Fixer will look at the POWN value in the coin. The coin must be fixable (meaning it cannot have too many fails). It will then detect every 'n' using the PAN and if that fails it will try the AN. When it sends the detection request it will use same GUID for the an and pan parameters like this:

https://RAIDA20.cloudcoin.global/service/detect?nn=1&sn=1&an=1836843d928347fb22c2142b49d772b5&pan=1836843d928347fb22c2142b49d772b5&denomination=1
• Test Design:

Test 1 (Autonomous operation): Create an authentic test CloudCoin, but change its pown to have 6 n's. Place a copy in the lost and predetect folder. For just 3 of the RAIDA that were marked as n, send detects request with a new pan, and only update the file in the predetect folder. this way we have a lost coin with 3 unchanged ans and 3 changed ans.

• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-LossFixer-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Minder

The job of the minder is to take CloudCoins from the bank folder and put them the ANs in the user's mind and the serial numbers in the "Mind" Folder. The Minder also takes the coins out of the Mind Folder and puts them back in the Bank Folder. Putting the stack files in the Mind Folder is more difficult. It is easy to take them out.

The Minder needs a password, PIN number or passphase from the user. It uses the serial number of the CloudCoin, the RAIDA number of the RAIDA it will be stored on and user supplied passphrase concatinated to create a MD5 hash. The first 32 characters of this hash will be used for the AN. These ANs will need to be uploaded to the RAIDA by using the detect or multi-detect protocol. Note: The passphase will be made all lowercase to reduce errors.

How to create a hash seed for the AN for RAIDA 3 for CloudCoin SN 16,777,216:

passphrase = "Oppose political correctness";

passphrase = Passphrase.toLowerCase(Passphrase);

sn = 16777216;

raidaNumber = 3;

hashSeed = sn + raidaNumber + passphrase;



Command

The Minder is commanded to take all the contents of the bank and put them in the Mind folder by dropping a file into the Minder command folder. The file must have the passfrase in the file and the command file must be deleted just as soon as it is read.

Reports

It is possible that during the powning process coins can become fracked, lost or even counterfeit.

ShowCoins

• Purpose:

The job of the ShowCoins is to make a report of all the assets in the program. The folders that the ShowCoins look at are Bank, Fracked, Gallery, and Lost.

• How To Start:

The ShowCoins starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java ShowCoin C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

ShowCoins myShowCoins = new ShowCoins("C:\Users\[username]\Documents\CloudCoin");
myShowCoins.showCoins();

• Event that Starts:

The ShowCoins watches the command folder for an ShowCoins command.

• Commands

There is only one ShowCoins command allowed in the CloudCoin/Command/ folder and new ShowCoins commands overwrite old ones. The ShowCoins should move the command into the CommandHistory folder before it begins.

             File Name: showcoin.command
             Contents:
             {
                "command":"showcoins",
                "account":"default"
             }
         

• Log Files:

Number of status/ Log Files: 4.

Name of Log Files:

Bank.157.0.0.5.25.2.txt
Fracked.250.0.0.0.0.1.txt
Lost.0.0.0.0.0.0.txt
Gallery.true.txt or Gallery.false.txt (True if there are things in the Gallery folder, False if not.


Location of Log Files: CloudCoin/Accounts/[accountname]/Logs/ShowCoin.

Format of Log Files: No contents.

2018-11-20 19:14:45:999 [INFO] { "ones": 1 "fives": 0 "twentyfives": 0 "hundreds": 0 "twohundredfifties": 0 "total": 1 }
2018-11-20 19:14:46:001 [INFO] { "ones": 1 "fives": 0 "twentyfives": 0 "hundreds": 0 "twohundredfifties": 0 "total": 1 }
• How it works:

Counts how many coins of each denomination are in each folder location.

Root/CloudCoin/Accounts/DefulatUser/Bank/

Root/CloudCoin/Accounts/DefulatUser/Fracked/

Root/CloudCoin/Accounts/DefulatUser/Lost/

Root/CloudCoin/Accounts/DefulatUser/Gallery/

• Test Design:

1. Empties out folders first.
2. Puts a known amount of CloudCoin in each folder.
3. Calls the ShowCoin command.
4. Checks the folders to make sure the correct coins are there.


• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-ShowCoins-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Translator

• Purpose:

The job of the Translator is to take all the output from the other Servants and put them into one StatusReport.txt file so that GUIs can monitor just that. The translator can also translate the text to other languages and other local formats. The Translator can use languages from the Language folder to translate. Most of the fields in the translator should be in the native language unless they are boolean values.

• How To Start:

The translator should watch for changes in log files and be started with the master executable program.

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

Tranlator myTranslator = new Translator("C:\Users\[username]\Documents\CloudCoin");
MyTranslator.translator();

• Event that Starts:

The Translator watches the log folders for changes.

• Commands

No commands.

• Log Files:

There are no log files except for StatusReport.txt

See the status file standards for how to write to it.

• How it works:

The Translator read log changes, interprets them, perhaps into a different language, and the updates the StatusReport.txt folder.

• Test Design:
To test the Translator Servant:

1. Write fake log files and then check the StatusReport.txt to see if the expected results have arrived.
• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Echoer-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Unpacker

• Purpose:

The Unpacker's job is to extract CloudCoin data from files (such as .stack, .jpg, csv) and place them in the Suspect folder in a stadardised way so that each CloudCoin is in a seperate stack file.

• How To Start:

The Unpacker starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java C:\Program Files\CloudCoin\Unpacker\Main C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

Unpacker myUnpacker = new Unpacker("C:\Users\[username]\Documents\CloudCoin");
MyUnpacker.unpack();

• Event that Starts:

The Unpacker watches the Import folder for new additions.

• Commands

No Commands

• Log Files:

The Upacker creates a receipt file and an unpacker log file

Location of Log Files: CloudCoin/Accounts/DefaultUser/Logs/Unpacker/.

Name of Log Files one for each day: 2018.11.30.txt

Format of Log Files: The Unpacker lists all the serial numbers that were unpacked and put in the suspect or moved to trash.

        2018-07-27,18:54:46.142,[UNPACKER],[UNPACKED], 16777216

        2018-07-27,18:54:46.142,[UNPACKER],[TRASHED], filename.jpg, No CloudCoins detected
        2018-07-27,18:54:46.142,[UNPACKER],[TRASHED], 16777216, Duplicate found in Suspect folder
        2018-07-27,18:54:46.142,[UNPACKER],[DUPLICATE], 16777216, Duplicate found in Bank folder
        2018-07-27,18:54:46.142,[UNPACKER],[DUPLICATE], 16777216, Duplicate found in Lost folder
        2018-07-27,18:54:46.142,[UNPACKER],[DUPLICATE], 16777216, Duplicate found in Vault folder
        2018-07-27,18:54:46.142,[UNPACKER],[DUPLICATE], 16777216, Duplicate found in Gallery folder
        2018-07-27,18:54:46.142,[UNPACKER],[DUPLICATE], 16777216, Duplicate found in Fracked folder
    

Reports

Reports on the unpacker will be locted in the CloudCoin\Accountrs\DefaultUser\Logs\Unpacker\ folder.
Reports are just empty file names that start with the batch number.

There are six parts of the file name: 1. Batch number (Date and Receipt Number), 2.Four digit random number, 3 SerialNumber, 4. Status (Either unpacked, format or duplicate) 5. Qualifier (why the status). For unpacked it is always good. For duplicate it will be the folder name that the duplicate was in. For format it will have bad or empty. Sample response if good If powning process has not been started

{
	"receipt_id": "a0c1746b03dc479ea44b147b175258eb",
	"time": "2016-49-21 7:49:PM",
	"timezone": "UTC-7",
	"bank_server": "ccc.cloudcoin.global",
	"total_authentic": 0,
	"total_fracked": 0,
	"total_counterfeit": 0,
	"total_lost": 0,
	"total_suspect":5,
	"receipt_detail": [{
			"nn.sn": "1.16777216",
			"status": "suspect",
			"pown": "uuuuuuuuuuuuuuuuuuuuuuuuu",
			"note": "Waiting"
		},
		{
			"nn.sn": "1:1425632",
			"status": "suspect",
			"pown": "uuuuuuuuuuuuuuuuuuuuuuuuu",
			"note": "Waiting"
		},
		{
			"nn.sn": "1.956258",
			"status": "suspect",
			"pown": "uuuuuuuuuuuuuuuuuuuuuuuuu",
			"note": "Waiting"
		},
		{
			"nn.sn": "1.15666214",
			"status": "suspect",
			"pown": "uuuuuuuuuuuuuuuuuuuuuuuuu",
			"note": "Waiting"
		},
		{
			"nn.sn": "1.15265894",
			"status": "suspect",
			"pown": "uuuuuuuuuuuuuuuuuuuuuuuuu",
			"note": "Waiting"
		}

	]

}
				
		  

• How it works:

When the Unpacking starts, the unpacker will generate a "batch" number. The batch number is based on the timestamp and will be the year, month, day, hour and second such as "2018.10.09.13.34". Please put leading zeros if the number does not take up the entire space.

Note: The unpacker should check the Bank, Vault, Fracked, Gallery and Lost folders to see if the coins are already there. If a coin is already in one of these folders then the coin should be moved to the Trash folder.

It then moves the original files into the Imported folder.

In order to deal with duplicates, the stack files in the Suspect folder should have a random tag to keep the names different.

In order to deal with duplicates, the stack files in the Trash folder should have a random tag to keep the names different.

In order to deal with duplicates, the files in the Imported folder should have a random tag added to the end to keep the names different.

• Test Design:

Test 1 (Autonomous operation): The tester program will place one log file into every folder and sub folder listed in the How it works above. Then the Eraser will be started by the module tester. Then the test program will put a command in the command folder ordering the Eraser to erase all the files. The Test program will then verify that the log files have been erased. If they are errased the test has passed. If the files are still there, the test fails.

Testing

The need to ensure that the coins are extracted from the files, that miss-formatted coins are moved to trash and reported on, that duplicate coins can all go into the suspect folder and that if there is a coin with the same serial number that is already in the folders: Bank, Fracked, Gallery, or Lost. If there are duplicates in these folders, the coins should not be moved into the Suspect folder but into the trash folder. Any coin that is moved to the trash should be reported.

Tests

1. Start by deleting all files in the Import, Imported, Suspect, Trash, Detected, Bank, Gallery, Fracked and Lost Folders.
2. Put many CloudCoin files in the Import folder. Use every supported format (.jpg,.stack, Mp3)
3. Command the Unpacker to unpack. There are no configuration or paramters needed.
4. Check that all the CloudCoin files ended up in the Suspect folder.
5. Check that all the CloudCoin files have been moved out of the Import folder and put in the Imported folder.
6. Now move the files from the suspect folder and place one into the Bank, Fracked, Lost, Fracked and put a jpeg CloudCoin in the Gallery. Note: The files should have use the same naming conventions. The .jpeg file may be moved from the Imported to the Gallery file.
7. Check that the there is a report that shows that all the SNs were moved to Suspect folder.
8. Now move all the files that are in the Imported folder back to the Import folder.
9. Command the Unpacker to unpack again.
10. Check the Suspect Folder. There should be no files there that were put in the other folders (Bank, Fracked etc).
11. Check that the files have been moved to the trash folder.
12. Check the report to see if the report shows the files .
• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Eraser-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Takes a bunch of files in the Import folder, extract the CloudCoins and writes single stack files (one coin per file) and places those stack files into the Suspect folder.

Vaulter

• Purpose:

The Job of the Vaulter is to take Coins from the Bank, obscure parts of the AN and write it to the Vault Folder. It will also do the opposite Take from the Vault and put back into the folder. This will make it so that if the coins are stolen, they will be unusable.

• How To Start:

The Backupper starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java Vaulter C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

Vaulter myVaulter = new Vaulter("C:\Users\[username]\Documents\CloudCoin");
MyVaulter.vault( 2,0,4,0,500); //the integers mean that the user wants to vault 2 1s, 0 5s, 4 25s, 0 100s and 500 250 CloudCoin notes.

• Event that Starts:

The Vaulter watches the command folder for an Backup command.

• Commands

There is only one Backup command allowed in the CloudCoin/Command/ folder and new Backup commands overwrite old ones. The Backupper should move the command into the CommandHistory folder before it begins.

             File Name: vaulter.command
             Contents:
            From Bank folder to Vault
            {
                "command":"toVault",
                "account":"default",
                "passphrase":"kdjfkj98uv98udijijkerer",
                "cloudcoin":"all" or "cloudcoin":"56987", //specified amount
                "1s" : "10",
		        "5s": "2",
		        "25s": "4",
		        "100s" : "12",
		        "250s" : "20" 
            }
                    
            From Vault folder to Bank (or Fracked)
            {
                "command":"fromVault"
                "account":"2i2iu",
                "passphrase":"kdjfkj98uv98udijijkerer",
                "cloudcoin":"all" or "cloudcoin":"56987", //specified amount
                "1s":"10",
		        "5s":"2",
		        "25s":"4",
		        "100s":"12",
		        "250s":"20" 
            }

         

• Log Files:

        There is just one log for the Vaulter that reports on all coins moved to Vault
        Location: CloudCoin/Logs/Vaulter/
        File Name: Vaulter.log
        
        Example Entries
         
        2018-11-20 19:14:45:999 [ToVault] 16777210
        2018-11-20 19:14:45:999 [ToVault] 16777211
        2018-11-20 19:14:45:999 [FromVault] 16777210
        2018-11-20 19:14:45:999 [FromVault] 16777211The Backupper does not require log files.
        

• How it works:

When the user goes to use the Vaulter, they should get a warning: "Warning, unless you have enabled recover by email, you will lose all your cloudcoins if you forget your passcode. There will be no way to recover them except to wait two years." This warning will be part of the GUI and not this servant however.

The Vaulter must get a hexadecimal input from the user as the PIN / Password. Or this hexadecimal number can be changed into the PIN.

Here is the starting AN:


4C813701-0A324B45-A436BF8C-D4A6F1D8
The second and third octets are changed into decimal numbers:
0A324B45 = 171068229
A436BF8C = 2755051404
The user supplies a pin code, password or passphrase:
password = "password"
This is converted to a md5 Hash:
password = 5F4DCC3B5AA765D61D8327DEB882CF99
The two octets are take and the rest is discarded:
5F4DCC3B-5AA765D6 (Hyphen added for readability)
The AN octets are paired with password octets
(0A324B45, 5F4DCC3B), ( A436BF8C, 5AA765D6)
Convert the pairs to decimal:
0A324B45, 5F4DCC3B = 171068229, 1598934075
A436BF8C, 5AA765D6 = 2755051404, 1520920022
Then subtract:
First VAN = 171068229 - 1598934075 = -1427865846
Second VAN = 2755051404 - 1520920022 = 1234131382

Now you have the numbers subtracted. Change these number to Hex and pad the front with zeros so that there are 16 characters.
VAN 1 = 1427865846 = -551B80F6
VAN 2 = 1234131382 = 498F59B6

Now use these number to replace the 2nd and 3rd octets in the original AN:
4C813701-0A324B45-A436BF8C-D4A6F1D8
becomes
4C813701-(551B80F6)-498F59B6-D4A6F1D8 (Note that you must put parenthesis around negative number)

Note that the hyphens are there just for readability.
Now store the coin in the vault with these changed ANs.
--Coins are now in Vault--
To take the coins out:
password = 5F4DCC3B5AA765D61D8327DEB882CF99

The two octets are take and the rest is discarded:
5F4DCC3B-5AA765D6
Split these into two octets and convert these to decimal
5F4DCC3B = 1598934075
5AA765D6 = 1520920022

Now convert the 2nd and 3rd octets of the AN in the Vault to Decimel
4C813701-(551B80F6)-498F59B6-D4A6F1D8
VAN 1 = 551B80F6 = -1427865846
VAN 2 = 498F59B6 = 1234131382
Now add these numbers to password:
AN 1 = 1598934075 + -1427865846 = 171068229
AN 2 = 1520920022 + 1234131382 = 2755051404
Then convert these numbers to Hex and put them back into the AN.
Move the coin from the vault to the bank folder.

• Test Design

The testing program will start by placing many stack files in the bank folder and placing the exact same files in RAM (For later).

The testing software will order the Vaulter to vault the bank.

Test to see if the entire contents of the bank folder is empty.

Test to see that these files are now in the Vault folder.

Test to see that the AN numbers of the files in the folder have changed from the original numbers by compairing what is in RAM.

Then the testing program should order the Vaulter to "Bank" the coins.

The entire contents of the Vault folder should be empty.

All the coins should now be back in the bank with the original AN numbers.

• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Vaulter-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

ChangeMaker

• Purpose:

The job of the ChangeMaker is to go out to a Change Server and break a CloudCoin into smaller units.

• How To Start:

The ChangeMaker starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

java ChangeMaker C:\Users\[username]\Documents\CloudCoin

Note that the root path is also called the "Workspace" and will be found in the config.txt file located in the program's executable folder. eg (C:\Program Files\CloudCoin\config.txt)

• How To Call Programatically:

Assuming the Servant is to be used as an object in a monolithic program, the servant can be called by supplying the root directory to the constructor.

ChangeMaker myChangeMaker = new ChangeMaker("C:\Users\[username]\Documents\CloudCoin");
MyChangeMaker.makeChange(250);

• Event that Starts:

The ChangeMaker watches the command folder for a MakeChange command.

• Commands

There is only one ChangeMaker command allowed in the CloudCoin/Command/ folder and new ChangeMaker commands overwrite old ones. The ChangeMaker should move the command into the CommandHistory folder before it begins.

             File Name: ChangeMaker.makeChange.txt
             Contents:
                Backup all files to backup location
                {
                    "command":"makeChange",
                    "account":"default" or  "account":"2i2iu" //Use default if no account specified
                    "method":"100D"  //See table of methods
                }
Make Change CHANGE_MAKER METHODS:

Denominaton 1

1 (Cannot break)
Denaomination 5

Method 5A: 1,1,1,1,1
Denomination 25

Method 25A: 5,5,5,5,5 (Min)
Method 25B: 5,5,5,5,5A
Method 25C: 5,5,5A,5A,5A
Method 25D: 5A,5A,5A,5A (Max)
Denomination 100

Method 100A: 25,25,25,25 (min)
Method 100B: 25,25,25,25A
Method 100C: 25,25,25A,25B
Method 100D: 25D,25D,25D,25D (Max)
Denomination 250

Method 250A: 100,100,25,25 (Min)
Method 250B: 100A,100A,25A,25B
Method 250C: 100B,100B,25B,25C
Method 250D: 100D,100D,25D,25D (Max)

• Log Files:

Name of Log Files: Logs/ChangeMaker/change.log.

Location of Log Files: Logs/ChangeMaker/

Format of Log Files: 2018-07-27,18:54:46.142,[ChangeMaker],[MakeChange],success,100D

• How it works:

The ChangeMaker looks in the global config file to see who its Change Server is.

The ChangeMaker checks to see if it has the note wanted to be broke in the Bank folder.

The ChangeMaker sends the note to the ChangeMaker service and hopefully receives back a stack of change.

The ChangeMaker logs the results.

• Test Design:
1. 1. Delete all contents in the Bank.
2. 2. Now add two files to each of these folders.
3. 3. Command the Backuper to Backup.
4. 4. Make sure the backup contains all the files that were in the Bank, Gallery and Fracked Folders. Note that the Gallery will have jpegs.
• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-ChangeMaker-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester
• Configuration

It has to know the URL of the Change Maker service. This will be located in the main configuration file.

Sender

• Purpose:

The Sender allows many coins to be authenticated at the same time but their PANs are generated by the RAIDA instead of the owner. This allows CloudCoins to be transfered from person to person with no powning necessary. Note that this service uses an outside trusted server. The trusted outside servers that we are using now have DNS names of s0.teleportnow.cc trough s24.teleportnow.cc



• Commands

The sender may use the amount or specific denominations but not both. The Sender should move the command into the CommandHistory after it is done execuring the command.

             File Name: Sender.command
             Contents if splitting the ANs between 25 servers:
                {
                    "command": "sender",
                    "split_ans":"true",
                    "trusted_transfer_domain","teleportnow.cc",
                    "trusted_transfer_hostname","s#",
                	"from_account": "default",
                	"to_account": "16777215",
                	"amount": 0,
                	"1s":0,
                	"5s":0,
                	"25s":0,
                	"100s":1,
                	"250s":0,
                    "envelope_name": "invoice_98377992"
                }
                
                 Contents is sending the whole cloudcoin (Phase 2):
                {
                    "command": "sender",
                    "split_ans":"false",
                    "trusted_transfer_domain","cloudcoin.global",
                    "trusted_transfer_hostname","bank",
                	"from_account": "default",
                	"to_account": "16777215",
                	"amount": 100,
                	"1s":0,
                	"5s":0,
                	"25s":0,
                	"100s":0,
                	"250s":0,
                    "envelope_name": "For baby sitting Billy"
                }
         

• Log Files:

There are two status files and 25 (one for every RAIDA) log files created for every time the sender sends.

Location of log files and status files (creates a folder for each send attempt):

CloudCoin/Logs/Sender/16777215 sent 100/

The new folder name includes the account number (1-16777215) that the money was sent to and the total amount that was sent.

CloudCoin/Logs/Sender/[account number] sent [amount].

25 Log File Names:

         Attempted to send 100 to 16777215 on RAIDA 0.txt
         Attempted to send 100 to 16777215 on RAIDA 1.txt
         ...left out for brevity
         Attempted to send 100 to 16777215 on RAIDA 23.txt
         Attempted to send 100 to 16777215 on RAIDA 24.txt
       
           

Status file names

               passed 90 coins.txt
               failed 5 coins.txt
               duds 0 coins.txt
           
         
           The contents of the status files will list the serial numbers of coins, one per line
           16777200
           16777201
           16777202
           
           IF ABORTED BECAUSE OF ANY REASON SUCH AS NOT ENOUGH COINS IN BANK FOLDER:
           aborted 100 coins.txt
           inside will say why the attempt was aborted such as "Not enough Coins in bank"
           

The contents of the log files will be the response from the servers.

          Response from the server: 
          [{
  "server":"RAIDA1",
  "status":"pass",
  "sn":"66585",
  "nn":"1",
  "message":"Authentic: 1-unit. Your coins have been sent to the address you specified.",
  "time":"2016-44-19 7:44:PM"
},
{
  "server":"RAIDA1",
  "status":"pass",
  "sn":"66586",
  "nn":"1",
  "message":"Authentic: 1-unit. Your coins have been sent to the address you specified.",
  "time":"2016-44-19 7:44:PM"
},
{
  "server":"RAIDA1",
  "status":"pass",
  "sn":"16589554",
  "nn":"1",
  "message":"Authentic: 250-unit. Your coins have been sent to the address you specified.",
  "time":"2016-44-19 7:44:PM"
}]


CONTENTS IF BAD:

{
  "server":"RAIDA1",
  "status":"dud",
  "message":"sns: no sns can be the same as to_sn"
  "time":"2016-44-19 7:44:PM"
}


         

• How it works: Like Exporter except it sends messages to outside servants
• For phase one, the ANs will be split up and sent to 25 different trusted transfer servers. These steps only apply to phase one.

1. The Servant recieves a command in its command folder.

2. The Servant reads what domain it is going to sent the coins to (for now "teleportnow.cc".

3. The Servant reads what are the host names for the servers by replacing the # symbol with numbers 0 through 24. ("s0").

4. The Servant reads the number coins it needs from the bank folder and puts them into an array in RAM.

5. A folder is created to handle the log and status files for CloudCoin/Logs/Sender/[account number] sent [amount].

6. For phase one, if there is no exact amount then the whole process is aborted and a "aborted" status file is created.

7. The "send" called according to the "send" service api.See Send API which

8. A log file is created for each trusted server response.

9. The responses are all put together for each coin sent. Each coin is graded and put in either the Pass, Fail or Dud file. If there are more than 20 that are authentic, then the coin is considered passed and sent and they are moved from the bank folder to the sent folder (This is a new folder, see diagram). If there are less than 20 are authentic then the coin is considered failed and counterfeit and the coin will be moved from the bank to the counterfeit folder. folder.

• Test Design: (This test can be used to test both the Sender and Reciever Servants)

1. The program should send CloudCoins to their own account to reduce loss of coins. This means that there needs to be an ID folder with one CloudCoin in it. The id coins should have a tag of "default" like 1.cloudcoin.default.stack

• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Depositer-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Receiver

• Purpose:

The Receiver goes to the Trusted Transfer server and uses its ID CloudCoin to retreive coins that have been sent to it. The Receiver must specifiy the exact SNs of coins that it wants to download. Other Servants will have populated the the Envelopes and the Coins folders that are subfolders of the Envelopes folder. Lists of SNs will be found in the Coins folders. Note that this service uses an outside trusted server. The trusted outside servers that we are using now have DNS names of s0.teleportnow.cc trough s24.teleportnow.cc



• Commands

The Receiver for phase one only can recieve by requesting the name of the envelope and can only recive from 25 servers at a time. So the command file should specify the Envelope Name. In the future, the Receiver will be able to communicate with a single server and download whole coins ("split_ans"="false"). But now it can only talk to 25 servers, get ANs and put them all together to make coins. Receiver should move the command into the CommandHistory after it is done execuring the command.

             
             File Name: Receiver.command
             Contents if splitting the ANs between 25 servers:
                {
                    "command": "receiver",
                    "split_ans":"true",
                    "trusted_transfer_domain","teleportnow.cc",
                    "trusted_transfer_hostname","s#",
                	"to_account": "default",
                	"key_name": "default",
                    "envelope_name": "invoice_98377992"
                }
                
                 Contents is receiving the whole cloudcoin (Not needed until Phase 2):
                {
                    "command": "sender",
                    "split_ans":"false",
                    "trusted_transfer_domain","cloudcoin.global",
                    "trusted_transfer_hostname","bank",
                    "to_account": "default",
                	"key_name": "default",
                    "envelope_name": "invoice_98377992"
                }
         

• Log Files:

There are two status files and 25 (one for every RAIDA) log files created for every time the Receiver receives.

Location of log files and status files (creates a folder for each send attempt):

CloudCoin/Logs/Receiver/Received from 16777215/

or

CloudCoin/Logs/Sender/[account number] sent [amount].

Log File Name:

         Attempted to receieve account 16777215 from RAIDA 0.txt
         Attempted to receieve account 16777215 from RAIDA 1.txt
         ...left out for brevity
         Attempted to receive account 16777215 from RAIDA 23.txt
         Attempted to receive account 16777215 from RAIDA 24.txt
       
           

Status file names

bank 100 coins.txt fracked 4 coins.txt partial 0 coins.txt

               300 coins received.txt
              
           
         
           The contents of the status files will list the serial numbers of coins that were received, one per line
           16777200
           16777201
           16777202
           
           IF ABORTED BECAUSE OF ANY REASON SUCH AS NOT ENOUGH COINS IN BANK FOLDER:
           
           No coins received.txt
           
           inside will say why the attempt was aborted such as "No account found"
           

The contents of the log files will be the response from the servers.
• How it works: It has to get the ANs from each server and put them together. Then if there missing ANs the coins may need to go to fracked folder.
• For phase one, the Receiver will query 25 different trusted transfer servers. These steps only apply to phase one.

1. The Servant recieves a command in its command folder.

2. The Servant reads what domain it is going to sent the coins to (for now "teleportnow.cc".

3. The Servant reads what are the host names for the servers by replacing the # symbol with numbers 0 through 24. ("s0").

4. The Servant calls on the Receive service on the 25 servers.

5. The Servant recieves arrays of SNs, ANs and puts them all the ANs together under each serial number.

6. The Servant will then place the coins into the Bank, Fracked or Partial Folders. /p>

7. The "send" called according to the "send" service api.See Send API which

8. A log file is created for each trusted server response.

9. The responses are all put together for each coin sent. Each coin is graded and put in either the Pass, Fail or Dud file. If there are more than 20 that are authentic, then the coin is considered passed and sent and they are moved from the bank folder to the sent folder (This is a new folder, see diagram). If there are less than 20 are authentic then the coin is considered failed and counterfeit and the coin will be moved from the bank to the counterfeit folder.

• Test Design: (This test can be used to test both the Sender and Reciever Servants)

1. The program should send CloudCoins to their own account to reduce loss of coins. This means that there needs to be an ID folder with one CloudCoin in it. The id coins should have a tag of "default" like 1.cloudcoin.default.stack

2. At least one test should test if good coins were sent to the server and if they were removed from the bank folder.

3. One test should test if bad coins are sent to counterfeit folder.

4. The log files and status files should be created in the correct folders and should have the correct format.

• Git Repository:
https://github.com/CloudCoinConsortium/CloudCore-Depositer-Java
• Tester Repository:
https://github.com/CloudCoinConsortium/Module_Tester

Transfer

• Purpose:

The teller does many things including looking at envelopes on the Trusted Transfer, seeing how many coins are in each envelope, transfering coins to other people and renaming envelopes.

The purpose of ShowEnvelopes is to contact a trusted transfer server and see what envelopes (bundles of CloudCoins) are on the server CloudCoins are bundled into Envelopes to make identify when someone sends another CloudCoins.

It is possible that you will only need to query one RAIDA to get this informatoin as in thoery, all the RAIDA will have the same data. Note that this service uses an outside trusted server. The trusted outside servers that we are using now have DNS names of s0.teleportnow.cc trough s24.teleportnow.cc



• Commands

The Teller for phase one only can recieve by requesting the name of the envelope and can only recive from 25 servers at a time. In the future (phase 2), the Receiver will be able to communicate with a single server and download ANs and get a list of all the envelopes that belong to the account. ShowEnvelopes should move the command into the CommandHistory after it is done execuring the command.

             
             File Name: ShowEnvelopes.command
             
                {
                    "command": "showenvelopes",
                    "trusted_transfer_domain",
                    "teleportnow.cc",
                    "trusted_transfer_hostname","s#",
                	"to_account": "default", //The Folder name in the Accounts Folder on the local machine
                	"key_name": "default" //The ID CloudCoin in the ID folder
                    
                }
                
         

• Log Files:

Only one log file is generated

Location of log files and status files (creates a folder for each send attempt): The log file over writes itself so there is ony one.

CloudCoin/Logs/ShowEnvelopes/16777215/

or

CloudCoin/Logs/Sender/[account number].

Log File Name:

Envelopes.txt

         The contents of the file just list each envelope one per line. 
        The contents of the file just list each envelope one per line. Sample Conents:
         c7b8e8cfdac045988214e02d5ff809b3
         For Rent
         Account #88899998
         Wallmart Store 2283 sale no. 49998822
           

• How it works:

1.The Servant gets the ID coin from the ID folder.

Makes a request from one of the trusted transfer servers.

    https://s20.teleportnow.cc/service/shownenvelopes?nn=1&sn=1&an=1836843d928347fb22c2142b49d772b&denomination=1&envelope_name=8rie.

    

Logs the reply.

• Tests:

TagRenamer

TagRenamer

ShowEnvelopeCoins

• Purpose:

The ShowEnvelopCoins gives you a list of all the coin serial numbers that are in an envelope that is owend by the caller.

This list is necessary for so that the caller can then specify which coins that want to recieve or transfer.

This information should be the same on all RAIDA so you should only have to call RAIDA's showenvelopecoins service. Note that this service uses an outside trusted server. The trusted outside servers that we are using now have DNS names of s0.teleportnow.cc trough s24.teleportnow.cc



• Commands
File Name: ShowEnvelopeCoins.command { "command": "showenvelopes", "split_ans":"true", "trusted_transfer_domain","teleportnow.cc", "trusted_transfer_hostname","s#", "to_account": "default",//The Folder name in the Accounts Folder on the local machine "key_name": "default", //The ID CloudCoin in the ID folder "envelope_name": "invoice_98377992" }
• Log Files:

Only one log file is generated

Location of log files and status files (creates a folder for each send attempt): The log file over writes itself so there is ony one.

CloudCoin/Logs/ShowEnvelopeCoins/16777215/

or

CloudCoin/Logs/Sender/[account number]/.

Log File Name:

[envelope name]_coins.txt 16777215_coins.txt

         The contents of the file is a list of serial numbers in the envelope - one per line. 
        The contents Sample:
        
         16777200
         16777201
         16777202
           

• How it works:

1. The ShowEnvelopesFromCoins is sent a command to that includes the local account (like default) and the name of the envelope.

1. The ShoeEnvelopesFromCoins is sent a command to that includes the local account (like default) and the name of the envelope.

1. The ShowEnvelopesFromCoins loads their ID Coin from theirID folder .

1. The Servant calls one of the showenvelopeCoins on one of the trusted transfer servers.

    https://s20.teleportnow.cc/service/showcoinsinenvelope?nn=1&sn=1&an=1836843d928347fb22c2142b49d772b&denomination=1&envelope_name=8rie.

    

The results are written to log

• Test Design:

Test 1 (Autonomous operation): The tester program will place one log file into every folder and sub folder listed in the How it works above. Then the Eraser will be started by the module tester. Then the test program will put a command in the command folder ordering the Eraser to erase all the files. The Test program will then verify that the log files have been erased. If they are errased the test has passed. If the files are still there, the test fails.

Work Spacer

The job of the work spacer is to change the default location of the file structure that is used. This information is kept in the workspace configuration file that is located near the executable program.