Sky Wallet

From CloudCoin Wiki
Jump to: navigation, search

This is an application that is distributed across 25 Clouds so that it has data supremacy. It is a private ledger although it could be made public. It is pseudo anonymous. There are accounts that are represented by GUIDs. Each account has a password that also must be a GUID. The RAIDA Bank allows you to do everything that a normal bank can do. You can open an account. recover passwords, store bank statements, deposit, withdraw, transfer and make payments. You can also make change.

There is a table that stores all the Registry. There are offline files called the Vaults. The Registry is managed by the Teller. The Vaults are managed by the Vault Teller.

All Services

All these services have a header which is not encrypted and a body that is encrypted. All bodies start with a four byte challenge that is a random number generated by the client. The server decrypts the body, reads the challenge and returns a MD5 hash (truncated to 4 bytes) with the Response. Note that the MD5 hash is located in the Response header and is not encrypted. Note: The Response Header will be not be encrypted (first 8 bytes) The Response Body Master Ticket will be encrypted using the same encryption key.

Any Call that requires the Owner ID and the AN do not use the CloudCoin AN table but instead use the ID AN table. This is a table with just ID coins.

ENCRYPTION: The communications are encrypted using ID coins and not CloudCoins.

Service Done on RAIDA Done in GO
[Deposit](https://github.com/worthingtonse/RAIDAX/blob/main/Skywallet.md#-deposit-) ✔ ✔
[DepositPANG](Skywallet.md#-deposit-pang) ✔ PHASE II
[Withdraw](Skywallet.md#-withdraw) ✔ ✔
[Transfer](Skywallet.md#-transfer-) ✔ ✔
[Balance](Skywallet.md#-balance) ✔ ✔
[Show Coins by Denomination](Skywallet.md#-show_coins_by_denomination-) ✔ ✔
[Show Coins by Type](Skywallet.md#-show_coins_by_type-) ✔ TODO
[Show Change](Skywallet.md#-show_change) ✔ ✔
[Show Register](Skywallet.md#-show-register) ✔ ✔
[Break](Skywallet.md#-break) ✔ ✔
[Break in Bank](Skywallet.md#-break-in-bank) ✔ ✔
[Join](Skywallet.md#-join) ✔ TODO
[Join in Bank](Skywallet.md#-join-in-bank) ✔ TODO
[Show Statement](Skywallet.md#-show-statement) ✔ ✔
[Delete All Statements](Skywallet.md#-delete-all-statement) ✔ ✔
[Show Payment](Skywallet.md#-show-payment) ✔ ✔
[Sync Responder](Skywallet.md#-sync_responder) ✔ ✔ N/A
[Sync Owner Add](Skywallet.md#-sync_owners_add) TODO ✔
[Sync Owner Delete](Skywallet.md#-sync_owners_delete) ✔ ✔
[Change Coin Type](Skywallet.md#-change_coin_type) ✔ TODO
[Upgrade Coin](Skywallet.md#-upgrade-coin) TODO TODO

DEPOSIT

Deposit takes CloudCoins from a user's local account and puts it into a CloudBank account. The service authenticates the coins and puts them into the Registry and then adds money to the user's ledger. The RAIDA Bank must send a POWN request to the RAIDA to finish the transaction. This service must use transactions so that money is never added to a user's account unless the coins are first authenticated and placed in the Registry.

If someone deposits to owner #2, those coins are marked coin type public (code 4)

Note value
Coin Type As specified by the user. Coin Type 4 is Public Change. Coin Type 00 is Anonymous.
Transaction Type Deposit 00
Amout Add up the values of each coin. Amount of coins sent Time Stamp The user's stamp or the servers stamp if the user's stamp is off by five minutes.

NOTE: The Owner (OW) comes from the ID table and the SNs come from the CloudCoin table.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
OW OW OW // Owners account
ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID //GUID of the transaction
YY MM DD HH mm SS //Client's time stamp. Must be in UTC.
CT //Coin Type.(Allways 00 for Anonymous)
TY //Will always be 00.
ST ST ST ST.....//Fix length Meta Data Stipe up to 50 bytes.
E3 E3
Response body if all passed Response body if all failed: Response body if mixed with passes and fails:
no Response body no Response body MS

DEPOSIT PANG

This is the same as Deposit except that instead of sending ANs it sends an AN genertor seed.

If someone deposits to owner #2, those coins are marked coin type public (code 4)

Note value
Coin Type As specified by the user. Coin Type 4 is Public Change. Coin Type 00 is Anonymous.
Transaction Type Deposit 00
Amount Add up the values of each coin. Amount of coins sent
Time Stamp The user's stamp or the servers stamp if the user's stamp is off by five minutes.

NOTE: The Owner (OW) comes from the ID table and the SNs come from the CloudCoin table.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG
SN SN SN
SN SN SN
SN SN SN
SN SN SN
OW OW OW // Owners account
ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID //GUID of the transaction
YY MM DD HH mm SS //Client's time stamp. Must be in UTC
CT //Coin Type.(Always 00 for Anonymous)
TY //Will always be 00.
ST ST ST ST.....//Fix length Meta Data Stipe up to 50 bytes.
E3 E3
Response body if all passed Response body if all failed: Response body if mixed with passes and fails:
no Response body no Response body MS


WITHDRAW

Before this is called, you must call the show registry command so you can coordinate the download of CloudCoin with the same serial numbers. Removes CloudCoins from a bank and puts them on the local machine. The user will be authenticated. The Balance of their account will be checked against the requested account.

The service must check authenticate the user and then check that the amount in the balance is greater than or equal to the users balance. The The bank will take the users PAN and send it to the RAIDA.

The SN should be deleted from the Coin Table. The SN in the AN table should have its AN changed to a AN generated by the seed (PANG)

Note value
Coin Type Anonymous 00
Transaction Type Withdraw 01
Amount Add up the values of each coin. Amount of coins sent Time Stamp The user's stamp or the servers stamp if the user's stamp is off by five minutes.

Request with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG PG //PAN Generator will be used for all SNs. Client should send a different PG to each RAIDA otherwise the coin is compromised
ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID //GUID of the transaction
YY MM DD HH MM SS //Client's time stamp Must be in UTC
TY //For future. Will always be 01.
ST ST ST ST.....//Fix length Meta Data Stipe up to 50 bytes.
E3 E3

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

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

1 + 1632435 + 9195C7A60CF0471BBE9B66144F5681C5 and then running an MD5 hash against that. 

PAN = MD5( "116324359195C7A60CF0471BBE9B66144F5681C5");

Response body for four coins:

Response body if all passed Response body if all failed: Response body if mixed with passes and fails:
no Response body no Response body MT MT MT MT MT MT MT MT MS
Note value
Coin Type Anonymous 00
Transaction Type Withdraw 01
Amount Add up the values of each coin. Amount of coins sent Time Stamp The user's stamp or the servers stamp if the user's stamp is off by five minutes.

TRANSFER

Removes CloudCoin from one account and puts it in another

If someone transfer to owner #2, those coins are marked coin type public (code 4)

Request with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW // From this account
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
OW OW OW // New owners account
ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID //GUID of the transaction
YY MM DD HH MM SS //Client's time stamp Must be in UTC
TY //There will be two transactions created. One for the sender and one for the receiver. The sender has 03 and the receiver has 02.
ST ST ST ST.....//Fix length Meta Data Stipe up to 50 bytes.
E3 E3

Response body for four coins:

// No body, just a status of All Pass or a status of "failed to authenticate"

=BALANCE+ Shows the number of each denomination that a user has in their account.

Request with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
E3 E3

Response body Version 0:

TO TO TO TO //Total Sum of face values of all notes
DN DN DN //Count of 250s
DN DN DN //Count of 100s
DN DN DN //Count of 25s
DN DN DN //Count of 5s
DN DN DN //Count of 1s

Response body Version 1:

TO TO TO TO //Total Sum of face values of all notes

Response body Version 3: //Used in Bitcoin Connect

TO TO TO TO //Total Sum of face values of all notes
DN DN DN //100
DN DN DN //10
DN DN DN //1
DN DN DN //0.1
DN DN DN //0.01
DN DN DN //0.001
DN DN DN //0.0001
DN DN DN //0.00001
DN DN DN //0.000001
DN DN DN //0.0000001
DN DN DN //0.00000001 (Satashi)
Code Meaning
64 Failed to Authenticate
250 Success
251 Failure

SHOW_COINS_BY_DENOMINATION

Shows all the serial numbers of the specified denominations.

Page 0 is records 1-16,000 (The 16,000 should be a variable called SHOW_COINS_BY_DENOMINATION_MAX )

Page 1 is records 16,001-32,000

Etc..


Request with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
DN //Denomination 0x01 = 1, 0x0A = 5, 0x64 = 25, 0xF0 = 100, 0xFF = 250
PG //Page Number
E3 E3

ERRORS: Incorrect Denomination. Response body for four coins ENCRYPTED. There will not be any more than 16,000 returns:

SN SN SN
SN SN SN
SN SN SN
SN SN SN ...

Note: Only 16,000 notes can be returned at a time. The lowest 16,000 SNs will be returned if page number = 0. The second batch of 16,000 coins will be returned if SN=1. And so on. The coins must be randomized and sent in random order to protect against decryption.


SHOW_COINS_BY_TYPE

Shows all the serial numbers of the specified Coin Type.

Page 0 is records 1-16,000 (The 16,000 should be a variable called SHOW_COINS_BY_DENOMINATION_MAX )

Page 1 is records 16,001-32,000

Etc..


Request with four coins:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
CT // See the Coin Type Table
PG //Page Number
E3 E3

Response body for four coins ENCRYPTED. There will not be any more than 16,000 returns:

SN SN SN
SN SN SN
SN SN SN
SN SN SN ...

Note: Only 16,000 notes can be returned at a time. The lowest 16,000 SNs will be returned if page number = 0. The second batch of 16,000 coins will be returned if SN=1. And so on. The coins must be randomized and sent in random order to protect against decryption.


SHOW_CHANGE

Show change service returns the serial numbers of CloudCoins that are in the specified account's "public" coin type. This allows the client to request to make change from 25 different RAIDA but use the same Serial Number. Otherwise, every RAIDA could return a different SN and all the coins would be counterfeit.

Shows only the coins that are smaller than the denomination specified.

It uses the "show_coin_max" variable to decide how many coins to show.

Default value for show_coin_max is 150 coins.

150 of each denomination in acceding order from smallest to highest.

150 250s

150 100s

150 25s

150 5s

150 1s

Request:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW //the owner in the Coin Owner's Table that has coins of type "public change" 04.
BR //The denomination of the coin that will be broken (1, 5, 25, 100 or 250)
E3 E3

Response body for four coins:

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

Note: Only 16,000 notes can be returned.


SHOW REGISTER

Show Register returns the serial numbers of a small number of the coins in a Sky Wallet. The lowest SNs are chosen.

The call return 150 of the lowest serial numbers from each denomination. The request included a BR (Biggest Returned) that tells the RAIDA what is the biggest denomination it should return. If you send a BR code of 250, the RAIDA should send you 150 of all denominations. The idea is that if you are trying send 3 CloudCoins then you only need to see the 1s denomination. So you would use a BR code of 0x01. If you are trying to break a 100 note then you only need 1s, 5s and 25s. So you can use a BR code of 25.

BR Code 250s Returned 100s Returned 25s Returned 5s Returned 1s Returned Total Notes Returned Total Bytes
250 150 150 150 150 150 750 2,250
100 0 150 150 150 150 600 1,800
25 0 0 150 150 150 450 1,350
5 0 0 0 150 150 300 900
1 0 0 0 0 150 150 450

The serial numbers are selected from the database Order By Lowest to Highest serial number. But, the the SNs are sent to the caller in Randomized order so that the numbers cannot be cracked when encrypted. Request:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW // The Owner ID
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN //The owner's AN
BR //The denomination and below of the coins that will be returned (1, 5, 25, 100, 250 for all of them)
E3 E3

Response body for four coins Encrypted:

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

BREAK

Take one CloudCoin note that is on the user's hard drive and turns it into many smaller notes. The caller must suggest which SNs it would like to receive as change. This means that in order to get change, the caller must use the "ShowChange" service to supply a list of SNs that it expects to get in return. As a rule, it can be required that the client always ask for change as follows:

The program must ensure that the coins that will be returned are of type "public change" 04.

Transaction Type: Broke to make change (04)

Coin Type: Coins put in the public change get coin type public change (04) Coin put in the user's wallet get the same coin type as the coin that was broke.

250:
100x2
25x1
5x4
1x5
100:
25x3
5x4
1x5
25:
5x4
1x5
5:
1x5
WARNING: Client should send a different PG to each RAIDA otherwise the coin will be stolen by any RAIDA admin.

Request. Depending on what will be broke.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SN SN SN //The Serial Number of the Coin that will be broke.
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN //The AN of the coin to be broke.
OW OW OW //The ID of public change account found in the Owner Table
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN //The serial numbers of all the coins that are in the public change account that will be needed tgo break the coin.
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN **** //The number of serial numbers will be different for each denomination
E3 E3
  1. Authenticate the coin to broken from the AN table.
  2. Make sure the public change account owns the serial numbers that the client wants have returned by confirming the Coin Owners Table.
  3. Add up the denominations of the Serial numbers to make sure they add up to the coin that will be broken.
  4. Change owner of the coin to be broken. First add the coin to the public change account in the Coin Owner Table. 2nd Put a random AN in the AN table for the coin to be broken.
  5. Delete the serial number from the Coin Owner's Table.
  6. Change the ANs of the change coins to the the PAN Provided by the client.


ERRORS:

70: Break: Coin to be broken was counterfeit.
72: Break: Public Change account specified does not own the coins to be change.
74: Break: Denominations of the Change do not add up to the coin to be brokent.
76: Break: Cannot Break a one.


Response body for four coins:

//Status success. Otherwise an error code like "Change Coins not in public change Account"


BREAK IN BANK

Take one CloudCoin note that is on the user's Skywallet Account and turns it into many smaller notes. The caller must suggest which SN it wants to turn into change and which SNs it would like to receive as change. This means the caller must know the SNs that are available in its account by calling SHOW COINS BY DENOMINATINO. The caller must also use the "ShowChange" service to supply a list of SNs that it expects to get in return. As a rule, it can be required that the client always ask for change as folows:

The program must ensure that the coins that will be returned are of type "public change".

Transaction Type: Broke to make change (04)

Coin Type: Coins put in the public change get coin type public change (04) Coin put in the user's wallet get the same coin type as the coin that was broke.

250:
100x2
25x1
5x4
1x5
100:
25x3
5x4
1x5
25:
5x4
1x5
5:
1x5

Request. Depending on what will be broke.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW //The Skywallet Owner's Account Number.
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN //The AN of the Owner's account.
SN SN SN //The Serial Number of the Coin that will be broke.
PO PO PO //The ID of public change account found in the Owner Table Right now it is SN #2
SN SN SN //The serial numbers of all the coins that are in the public change (in SN #2) account that will be needed tgo break the coin.
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN //The number of serial numbers will be different for each denomination
E3 E3
  1. Authenticate the owner with the OW and AN in ID Coin AN table.
  2. Make sure the public change account owns the serial numbers that the client wants have returned by confirming the CloudCoin Owners Table.
  3. Make sure the coin to be broke exists in the caller's Skywallet.
  4. Add up the denominations of the Serial numbers to make sure they add up to the coin that will be broken.
  5. Change owner of the coin to be broken. First add the coin-to-be-broken to the public change account in the Coin Owner Table.
  6. Delete the serial number from the Coin Owner's Table of the coin-to-be-broken.
  7. Change the owner of the Change coins from the public change server to the caller.


ERRORS:

77: Break in bank: Owner Coin was not authentic.
78: Break in bank: Coin to be broken did not exist.
79: Break in bank: Public Change account specified does not own the coins to be change.
80: Break in bank: Denominations of the Change do not add up to the coin to be brokent.
81: Break in bank: Cannot Break a one.

Response body for four coins:

//Status success. Otherwise an error code


JOIN

This takes many smaller notes and exchanges them for one big note. The number of notes provided must add up to either 250, 100, 25 or 5. This is almost exactly like Receive except that instead of providing authentication, coins are provided instead.

The user must specify the big coin that they hope to get in return. This helps the server check to see if it has that change. There are five return: 250,100,25 and 5 ( 1 is not a type).

The program must ensure that the coin that will be joined is of type "public change" 04.

Transaction Type: Joined ( 05 )

Coin Type: All coins sent to be joined with get "public change" (04)

Coins received that are larger will get the same coin type as those that were joined. (the first coin)

Request. Depending on what will be Joined.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW //The ID of public change account
SN SN SN //The coin to be returned from the public change
PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN //The new AN of the coin returned
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN //The Serial Number of the Coin that will be joined.
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN //The number of coins will be variable and so ends with 3E 3E.
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN ...
E3 E3

Response body for four coins:

//Status success. Otherwise an error code like "Change Coins not in Account"

ERRORS:

80: Join: Failed to Authenticate note to be joined
82: Join: Coins to be sent to public change did not add up.
84: Join coin was not of type "public change"



JOIN IN BANK

This takes many smaller notes in a Skywallet and exchanges them for one big note from a public change account. The number of notes provided must add up to either 250, 100, 25 or 5. This is almost exactly like Receive except that instead of providing authentication, coins are provided instead.

The user must specify the big coin that they hope to get in return. This helps the server check to see if it has that change. There are five return: 250,100,25 and 5 ( 1 is not a type).

The program must ensure that the coin that will be joined is of type "public change" 04.

Transaction Type: Joined ( 05 )

Coin Type: All coins sent to be joined with get "public change" (04)

Coins received that are larger will get the same coin type as those that were joined. (the first coin)

Request. Depending on what will be Joined.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW //The Skywallet Owner's Account Number.
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN //The AN of the Owner's account.
SN SN SN //The Serial Number of the Coin in the public change that will be given to the caller.
PO PO PO //The ID of public change account found in the Owner Table Right now it is SN #2
SN SN SN //The serial numbers of all the coins that are in the client's skywallet that will be sent to the public change server
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN //The number of serial numbers will be different for each denomination
E3 E3

Response body for four coins:

//Status success. Otherwise an error code like "Change Coins not in Account"

ERRORS:

80: Join: Failed to Authenticate note to be joined
82: Join: Coins to be sent to public change did not add up.
84: Join coin was not of type "public change"

SHOW STATEMENT

Allows the user to read statements. The user can specify how many rows they want to download. They can also specify the date that should start to download.

Request

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
RW //Number of rows * 100. So 0x01 means return 100 rows. 00 Means max rows.
YR //The Year 00 = 2000. 255 = 2255. Time must be in UTC
MM //month
DY //Day of the Month
RT //Return Code. 00=stripe 01=mirror, 11 = 2nd mirror, FF Stripe, Miorror and 2nd Mirror
ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID //Reserved for Future Use. Put random numbers.
E3 E3

Response body for three Records:

CB CB CB CB //Current Balance
ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID //GUID
TT //Transaction type
AM AM AM AM //Amount
BL BL BL BL //Balance
TS TS TS TS TS TS //Time Stamp
ME ME ME ME ME ME ... ME ME // Fixed 50 bytes for memo.
ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID //GUID
TT //Transaction type
AM AM AM AM //Amount
BL BL BL BL //Balance
TS TS TS TS TS TS//Time Stamp
ME ME ME ME ME ME ... ME ME // Fixed 50 bytes for memo.
ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID //GUID
TT //Transaction type
AM AM AM AM //Amount
BL BL BL BL //Balance
TS TS TS TS TS TS//Time Stamp
ME ME ME ME ME ME ... ME ME // Fixed 50 bytes for memo.

Response body if there are no statements:

Show Statements: No Statements found. Staus Code: 120

//Nothing in body if there is no statements.

Format for the Memo

NOTE: This is perfect code for XSS attacks. So clients must make sure it is not JavaScript. The memo can contain additional information than just the memo. The memo is written in toml. There is one general heading g that covers some basic info. There is another header for ATM transactions.

[g] //Heading for general
d=This is the description //Description or memo
i=https://server.tld.com/page/some.png //Icon Url of an image that can be put in the bank statment
r=https://url.of.com/page/some.html //Receipt Url of a page that can be linked to in the statment (like to a receipt)
a=Link text for the url //The text that will be shown in the anchor tag as a hyperlink.
s=sean.skyvault.cc //skyvault of who is initiating the transaction
[a] //header for ATMs. This may not be used right now.
usd = 100 //United States Dollar
tid = P3WFMghh24NWkTwX3eNyag //Transaction ID
m = 1155544 //merchant ID
t = 4454 //terminal ID
s = 5225 //Store ID
qr= XXXXxX //QR verification Code
imei = 552245145 //Mobile Device IMEI
p = 18005459154 //Phone Number
e = Add anything to put in the memo here.

DELETE ALL STATEMENT

Allows the user to delete all statements that they have. This is for privacy.

Command # 131.

Request Body:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
E3 E3

Response body for three Records:

//No Body. If successful, it will return a status code of: 195


SHOW PAYMENT

Allows anyone with a statement's GUID to read about that transaction. This is used so that senders, receivers and observers can know that a transaction has taken place.

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

Steps:

Generate a 33 digit hexidecimal character string as the spacers code like: "3E 02 32 51 0C 48 EF 39 92 3B C4 83 48 47 9B 0C D3" Each hexidecimal number represents the length of one of the random arrays of hexidecimal numbers. Turn the 16 byte Key ID into a 32 character hexidecimal string. For example "CB CF 19 A0 C3 E3 F0 2F ED 42 29 82 98 89 58 9A" Weave the spacers and the GUID hex characters together. If the first spacer is three, there will be three random hex numbers first. The Key CBCF19 and the Spacer 3EFE320C2 becomes "XXX-C-XXXXXXXXXXXXXX-B-C-XX-F-XXX-1-XX-9-XXXXX". The 'X's are random hexidecimal numbers between 0 and 15. It is ok to pad the last number with a random hex if the number is not even. Note: Each hex character in the Spacer Hex's String generates that number of random characters. So if the Spacer string starts with 'A' then ten random numbers will added, then the first character of the Key ID. The if the second character of the spacer key is 'E' then 15 random numbers will be added as space between the next characther in the key 'B'. 'S's shown below are Random Hexidecimal numbers. There will be between zero and 15 random numbers between each key's hex.


Note that every 'X' is a random hexidecimal number between 0 and F.

Spacer Key GUID Array to Add to String
3 XXX
C XXXC
E XXXCXXXXXXXXXXXXXXX
B XXXCXXXXXXXXXXXXXXXB


Request Body That Pads The GUID in spacers to help with Encryption

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
SP SP SP SP SP SP SP SP SP SP SP SP SP SP SP SP //spacers
RR Rc RR RR RR RR RR RR RR RR bR RR RR RR RR RR RR RR Rc RR RR RR RR RR RR RR Rf RR R1 RR 93 RR RR RR RR RR RR eR // Hash of key embedded in spacers
R1 RR RR RR RR bR R6 RR RR RR RR RR 5R RR R4 RR RR RR Rf RR RR RR RR Re RR RR 5R
RR RR RR RR Rb fR RR RR RR RR RR RR fR RR RR RR RR R3 RR RR RR R9 RR RR RR RR RR Re RR bR RR RR RR RR RR Rf
RR RR RR R3 RR RR Ra RR RR RR RR RR RR RR R9 RR RR R5 RR RR RR RR R4 RR RR RR R7 RR RR 8R RR RR RR RR fR //May need padding at the end by one random R

Request Body:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
RR RR RR RR RR RR RR RR // eight bytes of random numbers
ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID //GUID
RR RR RR RR RR RR RR RR //eight more bytes of random numbers

Response body for four coins:

TT //Transaction type
AM AM AM AM //Amount
TS TS TS TS //Time Stamp
OW OW OW //Account that received the transfer (got paid)
SE SE SE //Optional sender (For future use) if it is a transfer into. If they are all zeros then the sender is annonymous. If all 00 it means sender was annonymous.
ME ME ME ME ME ME 00 00 ... //Memo ends with two null characters.


SYNC_OWNERS_ADD

Allows the owner a skywallet account to tell the RAIDA that it is missing coins (in its Coin Owner's table). The RAIDA will then check with other RAIDA to see if the coins are truley missing. If so, the RAIDA will add them.

This service is "Fire and Forget" and the client does not need to wait for the process to end. This service allows for 21,500 coins to be registed as needing to be added.

Uses Coin ID 0.

Request saying that five SNs need to be added to the owner's account.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN //Serial number that should be added to the owner's account
SN SN SN
SN SN SN
SN SN SN
SN SN SN ...MAX COINS ARE 21,500.
E3 E3

Response body for coins:

//Response back with code working 0x60

Algorithm to sync by adding records to the transfer table.

The client tells the RAIDA that it is missing some coins that it should have in the Owner's table. The RAIDA must check with other RAIDA to see if it is true. If it is true that the RAIDA is missing rows, it will add the rows it is missing.

  1. RAIDA receivese a request.
  2. RAIDA Authenticates user.
  3. RAIDA responds that it is "Working" so the client knows the RAIDA will work on it. RAIDA quits the socket.
  4. The RAIDA confirms that the requesting owner (OW) does not have the coins the client specified in its Owner's table. A list of coins that are reported missing and also not in the owners table is created.
  5. The RAIDA chooses 9 other RAIDA at random.
  6. The missing coins list is sent to each of the 8 random RAIDA's SYNC_TRANSFER_ADD_RESPONDER service.
  7. When you get the Responses, each RAIDA will return the "Coin Type" of the serial numbers you sent.
  8. You will then analyze each serial number to see if the coins types from the eight random RAIDA match.
  9. Coin type 255 means it is missing. If the majority return that the coin type is 255 then the coin will not be added to the owner's account in the owner's table. Otherwise, the serial number will be added to the Owner's table and get the coin type that is the mode (The coin type that is specified the most).
  10. The Transfer Table is then checked to see if the same coin is also owned by a different owner. If it is then that row is deleted. Each coin can only be owned by one owner.

ERRORS

When the SYNC_TRANSFER_ADD tries to contact its neighbours and fails. These fails need to be recorded in the error log.

SYNC_RESPONDER

This is only used by RAIDA to talk to other RAIDA.

Maxium coins that can be accepted in one request is 30,000.

Uses Coin ID 0.

Only RAIDA can call this service. To very that the service is being called by another RAIDA, the first OW OW OW will be an id coin that only a RAIDA can own.

There are special ID serial numbers 0 through 25,000.


RAIDA ID COIN OWNERSHIP

RAIDA Number Starting ID Ending ID
0 0 999
1 1000 1999
2 2000 2999
3 3000 3999
4 4000 4999
5 5000 5999
6 6000 6999
7 7000 7999
8 8000 8999
9 9000 9999
10 1000 10999
11 11000 11999
12 12000 12999
13 13000 13999
14 14000 14999
15 15000 15999
16 16000 16999
17 17000 17999
18 18000 18999
19 19000 19999
20 20000 20999
21 21000 21999
22 22000 22999
23 23000 23999
24 24000 24999

Request to verify four coins in the Coin Owner / Transfer table.

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW //The ID coin of the account whose serial numbers are being asked to check
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN... //Up to 21,500 Serial numbers
E3 E3


Response body for four coins:

CT CT CT CT CT ... //One Coin Type for every serial number requested. If the type is 255, it means that serial number was not in the RAIDA's owners table for that owner.

Algorithm

  1. Check to see if the owner provided has the serial numbers provided. If yes, add that SN's coin type to the list of SNs that will be returned otherwise add the empty coin type of 255.


SYNC_OWNERS_DELETE

Allows the owner to tell the RAIDA that it should delete.

Request:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW //The ID coin of the account whose serial numbers should be deleted
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
SN SN SN
SN SN SN
SN SN SN ....// As many as 21,500 Coins can be deleted.
E3 E3

Response body for four coins:

//Status 0x60 working on it.

Algorithm: The service will simply delete the records in the owners table that the owner has requested to be deleted (assuming that the owner really owns them).

  1. Authenticate the client.
  2. Tell the client that the RAIDA is working on it and close the connection.
  3. Delete any rows in the Coin Owner's table that the user says to delete AND belong to that user.

CHANGE_COIN_TYPE

Allows the user to change the type of coins. This may be from public change to general or from general to some type of earmark.

Request

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
OW OW OW
AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN
NT //New type
SN SN SN
SN SN SN
SN SN SN
SN SN SN ...
E3 E3

Response Header status will be either ALL PASS, ALL FAIL or MIX. 241,242,243

//Statu if All Pass or All fail. If Mixed it will have: MS MS MS..

Example Response if good | bad | mixed

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH no Response body | MT MT MT MT MS


UPGRADE COIN

Command number 215. Allows the user to exchange coins from the old RAIDA to the new RAIDA.

NOTE: The client should download a ID coin first to use for encryption.

This command can only process 330 notes at one time.

The Super RAIDA will need to have the IP address of the Legacy RAIDA. This IP address will be kept in a file called "LegacyRAIDA_IP.txt". This IP will allow the SuperRAIDA to find the Legacy RAIDA and be able to contact it without going through CloudFlare.

The user will go to the old RAIDA and get an Old style 22 byte ticket. Super RAIDA 1 will need a ticket from Legacy RAIDA 1. Every RAIDA will need to send tickets to their corresponding RAIDA ID.

When the Legacy Responds, it will send the serial numbers associaed with the ticket and destroy those SNs on the Legacy RAIDA.

The Super RAIDA will then issue a special ticket that has a number of new coins assoicated with it. The new coins are calculated by deviding the amount of old coins that were authentic devided by 85.125 and rounded down.

Table Exchange Tickets

Column Bytes Description
Ticket ID 4 The ticket that will be sent to the calling client
Number of New Coins 2 bytes This is the number of legacy coins devided by 85.125 rounded down.

Then the RAIDA will examine the starting serial number (SS) that the client sent. The RAIDA will then go to that serial number and look to see if that serial number has been used. If the MonthsFromStart is zero then it has not been used. The RAIDA will examine every Serial Number starting with the SS and accending and will send the client the first 2000 coins that are open. So if the user sends the RAIDA a starting SN of 5,566,552 then the RAIDA will look to see if that serial number is open. If it is open then it is added to the list of serial numbers that will be returned. If it is not open it will conitue to look at the SS++. It will do this until it has 2000 SNs.

If the coins are contigues, the status will be status 213 Coins coins contigure. In this case only one serial number will be returned. Otherwise it will return status 214 serail numbers not contigues and there will be 2000 sns returned. If the SS is within 2,000 from 16,777,216 then the open serial numbers will wrap around starting with SN zero,

If the ticket returns no serial numbers from the RAIDA, then the status will be: ere Ticket not found.

Request:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK //22 byte ticket from Legacy RAIDA
SS SS SS//This is the Starting Serial Number
E3 E3

Response if rerturned SNs Contigues (Status 213)

TK TK TK TK
SN SN SN

Response if rerturned SNs Not Contigues (Status 214)

TK TK TK TK
SN SN SN
SN SN SN
SN SN SN
SN SN SN ...//up to 2000 Serial Numbers.

Algorithm

  1. Super RAIDA receives the Legacy 22 byte ticket and then sends the Ticket to the Legacy RAIDA by calling the old RAIDA's "Coin Converter" program. The coin converter program runs on port 30100 on is written in 'C' langage. It is able to talk to the MySQL database on the Legacy RAIDA.
  2. The Coin Converter on the Legacy RAIDA checks the ticket table. Then it responds with a bunch of bytes ( 3 for each Serial Number). The Coin Converter will change the network that the old coin was on from 1 to 2
  3. If there is a Response, count the number of serial numbers returned. If they are 255, 323, 320, 326 or 317, look at the chart below.
  4. If they are not those numbers above, total value of the SNs that are received from the Legacy RAIDA are totaled, devided by 85.125 and rounded down.
  5. The RAIDA will create a ticket number that is associated with the number of coins they will get and put that into a table.
  6. The RAIDA will respond with a status and 2000 serial numbers that are open and available which are directly above the Starting SN sent my the client.


Instances where the coins should be rounded up.

Notes Sent Denomination of the same type Amount to give them
255 1s 3
323 5s 19
320 25s 94
326 100s 383
317 250s 931

CLIENT: The client should send these amount of coins to allow the client to escape costs due to round-downs.


Coin Claim

The coin claim gives the user coins based on how many coin the ticket is worth. The client sends one byte (CT) to tell if the serial number are Contigues. 0x00 = false; 0x01 = true; If the serial numbers are Contigues then only the first one is listed in the request. Otherwise all serial numbers that the client wants will need to be listed by the client.

Request

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
TK TK TK TK //22 byte ticket from Legacy RAIDA
CT // Either 0x00 or 0x01 for true
PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN PN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN
SN SN SN //The number of serial numbers will be different but will be no more than 330 serial numbers.
E3 E3

Response Header status will be either Status:

Ticket not found

Everything is good and all serial numbers used (Sucess)

Fail: Not all ser

ALL PASS (241), ALL FAIL (242), MIXED (243)

Response body if all passed Response body if all failed: Response body if mixed with passes and fails:
no Response body no Response body MS

For the mixed, 1 means the Serial Number was there and was used, 0 means the serial number was not there and not used.

Coin Converter

This is a program that runs on the legacy RAIDA and listens only for requests to convert coins. It uses a standard header. However the encryption key is not included. The SuperRAIDA and the Coin Converter will both have a file called "UpgradeCoinKey.txt". These files will have the same key in them that will be used to encrypt the conversation. No ID or SN are needed since there is only one key. .

legacy_raida.bin

//All ip addresses of legacy and port number. six bytes per row. 4 forIP and 2 for port.


EXAMPLE BODY OF REQUEST:

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK TK // 22 byte Ticket

The reply will contain the standard header.

Response Status: No Ticket 245

Success: 250

EXAMPLE BODY OF REPLY: Shows seven serial numbers returned. The number is divisable by 3 bytes.

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

If the RAIDA cannot find that ticket then it will return status 245: Ticket did not exist.

Algorithm

  1. Super RAIDA receives the Legacy 22 byte ticket and then sends the Ticket to the Legacy RAIDA by calling the old RAIDA's "Coin Converter" program. The coin converter program runs on port 30100 on is written in 'C' langage. It is able to talk to the MySQL database on the Legacy RAIDA.
  2. The Coin Converter on the Legacy RAIDA checks the ticket table. Then it responds with a bunch of bytes ( 3 for each Serial Number). The Coin Converter will change the network that the old coin was on from 1 to 2
  3. If there is no Response from the Coin Converter, the client will need to fix the coin using the Fix Frack Service on the SuperRAIDA..
  4. If there is a Response, all the SNs that are sent will have their ANs set based on the seed given by the PAN Generator. The MonthsFromStart will be set to the current month.
  5. The client will get a responce.

REPORT LOST

Alows the user to tell us about coins they lost so that we can help them get the back.

Request

CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH CH
TS //Month From Start that the coins where lost. Month 1 is Jan 2020.
SN SN SN //Serial numbers of coins lost
SN SN SN
SN SN SN
SN SN SN ...
EM EM EM ....EM EM EM EM //These are 256 bytes that are fixed. They hold the user's email address. They should have null characters at the end.

We still need to work out how this will be stored. Probably in a folder of the month lost on the hard drive. Then by email address.

APPENDIX

Transfer Services

Mode Name Purpose Authenticates? Requires Owned sns Requires Change SNs Requires Pans? Requires tags? Requires PANG
2 Echo Gets No No No No No Encrypted
16 View Receipt Generates the A No No No No No Yes
11 Show Change Ge ne No No Yes No No Yes
8 Send Gen e No yes No No Yes Yes
9 Send Again Gener No yes No No Yes Yes
0 Break Pas Yes No Yes Yes Yes Yes
3 Join Used Yes No Yes Yes No No
6 Receive Envelope PAed w. Yes No No No Yes Yes
7 Rename Tag Same Yes No No Yes Yes Yes
10 Show Generates Yes No No Yes Yes Yes
13 Show Coins with Tag Gen Yes No No Yes Yes Yes
14 Show Tags Generate Yes No No Yes Yes Yes
12 Show Transfer Balance Gener Yes No No Yes Yes Yes
14 Verify Payment Generates the Yes No No Yes Yes Yes
14 Sync Transfer Generates t he Yes No No Yes Yes Yes
14 create statement Generates t he Yes No No Yes Yes Yes
14 Read Generates t he Yes No No Yes Yes Yes
14 Update Generates t he Yes No No Yes Yes Yes
14 Delete Generates t he Yes No No Yes Yes Yes
13 Transfer Generates the ANs Yes Yes No Yes Yes Yes
5 Receive U s Yes Yes No Yes Yes Yes
4 Join in Ban k Yes Yes Yes No No No
1 Break in Ba Yes Yes Yes No No Yes

Process for Detection (all modes)

Step Name view Receipt Show Change Send Send Again Break Join Receive Envelope Rename Tag Show
0 Listen for Request ■ ■ ■ ■ ■ ■ ■ ■ ■
1 Receive Request ■ ■ ■ ■ ■ ■ ■ ■ ■
2 Validate Request Header ■ ■ ■ ■ ■ ■ ■ ■ ■
3 MD5 Hash Challenge ■ ■ ■ ■ ■ ■ ■ ■ ■
4 Respond with Validation Errors ■ ■ ■ ■ ■ ■ ■ ■ ■
5 Decrypt Body ■ ■ ■ ■ ■ ■ ■ ■ ■
6 Authenticate ANs. Count 24 ■ ■ ■ □ ■ ■ ■ ■ ■
6 Read transfer table based on owner ■ ■ ■ □ ■ ■ ■ ■ ■
6 Read transfer table based on tag ■ ■ ■ □ ■ ■ ■ ■ ■
6 Read transfer table based on coin sn ■ ■ ■ □ ■ ■ ■ ■ ■
6 Read if sns exists in transfer ■ ■ ■ □ ■ ■ ■ ■ ■
6 Create record in transfer table ■ ■ ■ □ ■ ■ ■ ■ ■
6 Update record in transfer table ■ ■ ■ □ ■ ■ ■ ■ ■
6 Delete record in transfer table ■ ■ ■ □ ■ ■ ■ ■ ■
6 Put random guid in ans table ■ ■ ■ □ ■ ■ ■ ■ ■
6 Put specified guid in ans table ■ ■ ■ □ ■ ■ ■ ■ ■
10 Encrypt Response ■ ■ ■ ■ ■ ■ ■ ■ ■
11 Respond to Request ■ ■ ■ ■ ■ ■ ■ ■ ■
12 Put Master Ticket in Ticket Table ■ ■ ■ ■ □ ■ ■ ■ ■
13 Generate PANs if necessary □ □ □ □ □ ■ ■ ■ □
14 Add email hash to PANs □ □ □ □ □ ■ ■ ■ □
15 Change ANs with PANs ■ □ □ □ □ ■ ■ ■ □
16 Go back to Listening ■ ■ ■ ■ ■ ■ ■ ■ ■

Alternative Denominations

CloudCoin P2:

Denomination Count Total Value Starting SN Ending SN
.01 1,000,000 10,000 1 1,000,000
.10 3,000,000 300,000 1,000,001 4,000,000
1.00 6,000,000 6,000,000 4,000,001 10,000,000
10.00 500,000 5,000,000 10,000,001 10,500,000
100.00 29,700 2,970,000 10,500,001 10,529,700
470,284 0 10,529,701 11,000,000
20,000 0 11,000,001 11,020,00
11,020,000 14,280,000 1 11,020,00
Denomination Start SN End SN Count Total Value
1 2,097,152 1 2,097,152 2,097,152
5 2,097,152 2,097,153 4,194,304 10,485,760
25 2,097,152 4,194,305 6,291,456 52,428,800
100 8,388,608 6,291,457 14,680,064 838,860,800
250 2,097,152 4,194,305 16,777,217 524,288,000
Total 16,777,216 1 16,777,216 1,428,160,512

ID Coin Roles

Each ID coin has roles. These are the Purple Role, Blue Role and Green Role.

Service Owner Administrator Reporter Synchronizer
[Withdraw](Skywallet.md#-withdraw) 💜 💛 ❌ ❌
[Transfer](Skywallet.md#-transfer-) 💜 💛 ❌ ❌
[Balance](Skywallet.md#-balance) 💜 💛 💙 💚
[Show Coins by Denomination](Skywallet.md#-show_coins_by_denomination-) 💜 💛 💙 ❌
[Show Coins by Type](Skywallet.md#-show_coins_by_type-) 💜 💛 💙 ❌
[Show Register](Skywallet.md#-show-register) 💜 💛 💙 ❌
[Break in Bank](Skywallet.md#-break-in-bank) 💜 💛 💙 💚
[Join in Bank](Skywallet.md#-join-in-bank) 💜 💛 💙 💚
[Show Statement](Skywallet.md#-show-statement) 💜 💛 💙 ❌
[Sync Owner Add](Skywallet.md#-sync_transfer_add) 💜 💛 💙 💚
[Sync Owner Delete](Skywallet.md#-sync_transfer_delete) 💜 💛 💙 💚

Administrator Policies

Policy Description Bytes Encoding
Allow Transfers Specifies the number of transfers that the Admin can make each day. 3 0x000000 = no transfers. 0xFFFFFF means 16.7 Millon.
Allow Withdraws Specifies the number of transfers that the Admin can make each day. 3 0x000000 = no transfers. 0xFFFFFF means 16.7 Millon.
Times Active Times that Transfers and Withdraws are allowed 12 Every bit represends a 15 minute period 96 bits for each 15 minutes in a day. All zeros means all nothing
White List Lists Accounts that can be transfered to. Up to 30. 90 If the first three bytes are 0x000000 then there are no restrictions. Otherwise 3 bytes per SN.
Maxiumum Daily Transfer Amount Amount of CC that can be transfered in a day 3 If zero it means not restricutions. Otherwise the number will be less than 16 million.
Maxiumum Daily Withdraw Amount Amount of CC that can be transfered in a day 3 If zero it means not restricutions. Otherwise the number will be less than 16 million.
Maxiumum Transfer Amount Amount of CC that can be transfered in a day 3 If zero it means not restricutions. Otherwise the number will be less than 16 million.
Maxiumum Withdraw Amount Amount of CC that can be transfered in a day 3 If zero it means not restricutions. Otherwise the number will be less than 16 million.
Number of daily Transferes Allowed The minimum amount of CC that must remain in the wallet 3 If zero it means not restricutions. Otherwise the number will be less than 16 million.
Number of daily witdhraw Allowed The maxium number of withdraws allowed 3 If zero it means not restricutions. Otherwise the number will be less than 16 million.
Number of daily witdhraw Allowed The maxium number of withdraws allowed 3 If zero it means not restricutions. Otherwise the number will be less than 16 million.
Retrieved from "http://www.cloudcoinwiki.com/index.php?title=Sky_Wallet&oldid=640"