Software

Anyone can include CloudCoins into their software

The CloudCoin Consortium was setup to enable the world to use CloudCoins free of charge. We have many developers who share their work with us.

You are free to use this software and modify it so long as you are not creating malware.

If you have any questions or concerns, please email CloudCoin@Protonmail.com

We are working frantically to create great client-side software.

Links to Know Open-Source CloudCoin Software

Mac Desktop

Android

iPhone

{ "networks":[ {"nn":1, "raida":[ {"raida_index":0, "failsEcho":"false","failsDetect":"false","failsFix":"false","failsTicket":"false","location":"au", "urls":[ {"url": "raida0.cloudcoin.global","port": 443,"milliseconds": 700} ]}, {"raida_index":1, "failsEcho":"false","failsDetect":"false","failsFix":"false","failsTicket":"false","location":"mk", "urls":[ {"url": "raida1.cloudcoin.global","port": 443,"milliseconds": 700} ]}, //RAIDA 2 though 23 left out for space. {"raida_index":24, "failsEcho":"false","failsDetect":"false","failsFix":"false","failsTicket":"false","location":"ca", "urls":[ {"url": "raida24.cloudcoin.global","port": 443,"milliseconds": 700} ]} ] },


RAIDA Advanced Client

Servant Based Architecture

Navigation
Diagram
Folders



Authenticator
Backupper
ChangeMaker
Depositer
Echoer
Emailer
Eraser
Exporter
Frack Fixer
Gallerist
GallertistExporter
Grader
Loss Fixer
Minder
Pay Forward
Show Coins
Traslator
Unpacker
Vaulter
WorkSpacer



Folder Structure

Windows

Executables: C:\\Program Files\CloudCoin
Data: C:\Users\[username]\Documents\CloudCoin

Mac

Executable: /Applications/CloudCoin.app
Data: /Users/[username]/Documents/CloudCoin

Linux

Executable: /usr/bin/CloudCoin
Data: /home/[username]/CloudCoin

CloudCoin
Accounts
passwords

Username.txt

123casdf324examp34le
Bank
Counterfeit
Dangerous
Deposit
Detected
Export
EmailOut
Fracked
Gallery
ID
Import
Imported
Logs
Lost
Mind
Partial
PayForward
Predetect
Receipts
Requests
RequestsResponse
Suspect
Templates
Trash
TrustedTransfer
DefaultUser
Bank
Counterfeit
Dangerous
Deposit
Detected
Export
EmailOut
Fracked
Gallery
ID
Import
Imported
Logs
Lost
Mind
Partial
PayForward
Predetect
Receipts
Requests
RequestsResponse
Suspect
Templates
Trash
TrustedTransfer
Template
Bank
Counterfeit
Dangerous
Deposit
Detected
Export
EmailOut
Fracked
Gallery
ID
Import
Imported
Logs
Lost
Mind
Partial
PayForward
Predetect
Receipts
Requests
RequestsResponse
Suspect
Templates
Trash
TrustedTransfer
Logs
Echoer
BackUpper
FrackFixer
Grader
ShowCoins
Minder
Gallerist
Exporter
Vaulter
Emailer
Transferer
PayForwarder
Receipts

20180901.txt

Command
CommandHistory

Servants

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:
  • The Authenticator it told by a command to start authenticating. The caller should check the echoer first to make sure the RAIDA is there.

  • Commands
  •               {
                        "command":"pown",
                        "account":"2i2iu"
                   }
                   
                 
  • 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

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: Backupper.backup.txt
                 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

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.

Depositer

  • Purpose:
  • The Depositer's Job is to get CloudCoins from outside of the program and bring them in.The Depositer will get the coins from the Com Broker and put them in then move them to the Import Folder.

  • How To Start:
  • The Depositer starts by calling the language, the name of the executable and providing a path to the root folder the Servant will use:

    java Depositer 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.

    Depositer myDepositer = new Depositer("C:\Users\[username]\Documents\CloudCoin");
    MyDepositer.backup();

  • Event that Starts:
  • The Depositer 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.

                 File Name: Depositer.retrieve.txt
                 Contents:
                    {
                        "command":"getDeposit",
                        "account":"default" or  "account":"2i2iu",  //backup default account or specific account
                        "bankURL":"bank.CloudCoin.global/service/retrieve",
                        "ID":"default"  //specifies the ID in the ID folder that will be used. 
                        "moveTo":"Import"  //specifies the folder that the depositer should put the coins in. 
                    }
             
  • Log Files:
  • The Backupper does not require log files.

  • How it works:
  • For now, the Depositor receives coins from the Com Broker that recieved them from RAIDA's PayForward Service.

    1. Read the CloudCoin that is in the ID folder. And get the Serial Number and one Authenticity Number so it can be used to get a ticket.

    2. You use the "GetTicket" service to get a ticket based on that Serial Number and Authenticity Number.

    3. Then it takes the ticket, and the SN of the ID, and send it to the Retrieve service.

  • Test Design:
    1. Setup a dummy service that will give a stack of CloudCoins
    2. Call the Depositer to deposite
    3. Check to see if the Coins made it into the specified folder.
  • Git Repository:
  • https://github.com/CloudCoinConsortium/CloudCore-Depositer-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.echo.txt
                {
                    "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

Test Echoer

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.eraseAll.txt
                 Contents:
                 {
                    "command":"eraseAll",
                    "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

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.

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.

                 File Name: Exporter.Export.txt
                 Contents:
                    {
                    	"command": "export",
                    	"account": "default",
                    	"amount": 100,
                        "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.

  • Test Design:
  • Tests to come.

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

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.

PayForwarder

The job of the PayForwarder is to send CloudCoins to the RAIDA's PayForward service so they can be sent to another person via a communication broker. The PayForward will need to use the RAIDA's PayForward Protocol.

Configuration

The Service will need parameters for:
order_number (Maybe Generated by the receiver and given to the sender.
com_broker like bank.cloudcoin.global
method like bank,email or facebook(only bank is supported now
from_email like Sean@Worthington.net
to_account_name_or_number like 16225354 (Maybe number provided by the receiver)
total_to_send like 385 (amount in CloudCoins)
change_to_com_broker like bank.cloudcoin.global
change_to_account_name_or_number like depository
memo=We love Pay Forward!

Testing

In order to test it, you can actually send CloudCoins to your self.

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: Showcoins.showcoins.txt
                 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

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.vault.txt
                 Contents:
                From Bank folder to Vault
                {
                    "command":"toVault",
                    "account":"2i2iu",
                    "passphrase":"kdjfkj98uv98udijijkerer",
                    "cloudcoin":"all" or "cloudcoin":"56987" //specified amount
                }
                        
                From Vault folder to Bank (or Fracked)
                {
                    "command":"fromVault"
                    "account":"2i2iu",
                    "passphrase":"kdjfkj98uv98udijijkerer",
                    "cloudcoin":"all" or "cloudcoin":"56987" //specified amount
                }
    
             
  • 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

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.