Cryptocurrency with Royal Network, Decentralized Trusted Party and Automated Smart Contracts

Abstract

Confidence coin, in short Coco, is an upgrade to the cryptocurrency technology, it replaces P2P network with Royal Network and using a special block encoding that together allows blocks as big as Gigabytes of data. It offers micro and macro transactions via Decentralized Trusted Parties. It also increases users privacy and helps government regulators to protect the system from illegal trades and fraudulent activities. Coco upgrades smart contracts to Automated Smart Contracts that allow automatic payments. And it has a leadership organization, founded by Coco system itself with a single purpose of making Coco great.

Claims

1. A cryptocurrency system

2. A system in claim 1 with a Rosyl Network as shown in drawing 1, a network with a method for reaching a consensus for adding and removing nodes using a predefined maximum number of nodes, a PN, comprising: core nodes, and; nodes who wish to join the network, outer nodes; The outer nodes have information about how to connect to the core nodes; The outer nodes get block information from the core nodes to start mining blocks; the outer nodes and the core nodes are mining blocks; the outer nodes send their mined blocks to the core nodes; core nodes who mined a block and core nodes who received a block from outer nodes send it to the rest of the core nodes; when a new block is mined, the nodes who mined the last PN blocks become the core nodes and the core nodes who did not mine any of the last PN blocks removed from the network.

3. A system in claim 1 with a method for uniquely mapping wallet addresses to unique consecutive multibyte integers as shown in drawing 4 comprising: a block of a blockchain of the cryptocurrency system; the first block in the blockchain, a genesis block; a plurality of transactions appearing in the block; a plurality of wallet addresses appearing in at least one of the block transactions, and; a mapping information; Wallet addresses in transactions are uniquely mapped to unique consecutive multibyte integers, starting from the last mapping integer in the previous block and starting from a small predefined number in the genesis block, making all the future references to the mapped wallet addresses in the current block and next blocks to use the multibyte integers.

4. A method in claim 3 where the mapping information only contains the wallet addresses while the unique multibyte integer is equal to the last such integer from the previous block and a predefined small integer in the genesis block, plus the row number as shown in drawing 5.

5. A system in claim 1 with a method for aggregating similar transactions in a block by writing a header that includes transaction type and transaction features as shown in drawing 6.

6. A method in claim 5 with a feature of encoding the transaction amount with a multibyte floating point

7. A method in claim 5 with a feature of having the transaction fees to be a predefined value and not write it to the block

8. A method in claim 5 with 1 to 1 transaction type wherein there is only one sender and receiver

9. A method in claim 5 with 1 to many transactions with same balance type wherein there is only one sender and at least two receivers, that are receiving the same amount from the sender, so the amount is only specified once in the transaction.

10. A method in claim 5 with 1 to many transactions with different balances type wherein there are only one sender and at least two receivers that receive a unique amount from the sender

11. A system in claim 1 where wallets balance is returned to circulation after the wallet wasn't used for a predefined time

12. A system in claim 1 where transactions expire and become invalid after a predefined time

13. Claim 12 where time is calculated using the block count in the blockchain

14. A cryptocurrency system wherein a predefined portion of a reward from mining a block is sent to a predefined wallet.

15. A cryptocurrency system as shown in drawing 7, with a plurality of wallets wherein each wallet can allow and disallow one other wallet at a time to make transactions on its behalf comprising: A plurality of wallets; trust, a permission of a wallet to another wallet to make transactions on its behalf; a plurality of wallets who received trust from other wallets, DTPs; blockchain where the information about trust is stored; update transaction, a transaction made by a DTP on behalf of at least two wallets that trust it, between them self, wherein the wallets addresses and their new balances, and; DTP storage system, a system controlled by a DTP that saves all the transactions made by wallets who trust it between them self via it; wallets grant trust to a DTP, and; making all its future transactions to other wallets who trust the DTP via the DTP storage system; while the DTP periodically aggregate all the transactions in its DTP storage system; makes an update transaction with total amount of wallets balances equal to the total amount of those balances prior to the update transaction, and; remove all the saved transactions from its DTP storage system.

16. A system in claim 15 where wallets are not allowed to make transactions by them self while trusting a DTP

17. A system in claim 15 where wallets request to disallow a DTP is granted only after at least one of the following condition is met the DTP is making an update transaction; after a predefined time

18. Claim 17 where time is calculated using the block count in the blockchain

19. A cryptocurrency system with smart contracts that executes after each new block, Automated Smart Contracts comprising: Automated Smart Contracts wherein each Automated Smart Contract comprising: Model, a readable and writable data, and; Script, a set of commands that executes the Automated Smart Contract and can perform any of the following actions: Read data from the blockchain, including Models of other Automated Smart Contracts, modify its own Model, move coins from the wallet that created it to other wallets, and deactivate it self, and; blockchain; With each new block added to the blockchain, all Automated Smart Contracts are executed

20. Claim 19 where the Automated Smart Contracts move coins only after a predefined block count as it's specified in the automated smart contract

21. Claim 19 where the Automated Smart Contracts move coins only after a predefined time as it's specified in the automated smart contract

22. Claim 19 where the Automated Smart Contracts move coins only after a transaction is made to a predefined wallet as it's specified in the automated smart contract

Description

DETAILED DESCRIPTION

[0046] At first, I will describe the structure and the encoding of the components in the system, and then I will show the flow that will demonstrate the connection between the components.

System Structure

[0047] Look at drawing 1. The system is built from pools and wallets.

pools are the core nodes in the Royal Network. Their number is limited to 200, and each of them can have an unlimited amount of wallets connected to it. Each wallet communicates with only one pool. [0048] The pool is responsible for the creation of blocks, and broadcasting transactions. pool maintains the system model in a database that has all the information of the blockchain, such as wallets balances, Automated Smart Contract and more. [0049] The wallet is the client-side program. It's responsible for the creation of wallet public and private keys, making transactions and mine coins. It communicates with the pool to fetch wallet balance, broadcast a transaction or submit a mining job.

Wallet Address

[0050] Wallet encryption is done using Curve25519, for its fast processing speed and a short signature, only 64 bytes. Curve25519 public key is a wallet address.

Block Encoding

Base Types

Multibyte IntegerMI

[0051] There are several ways to implement multibyte integers, in Coco they are at most 4 bytes big-endian of data where the first 2 bits of the first byte are used to represent the byte length of the integer, see drawing 2 for details.

Multibyte Floating PointMFP

[0052] There are several ways to implement multibyte floating points, in Coco they are numbers in a range of 0-10.73741823 inclusive, those numbers are multiplied by 100,000,000, rounded using Floor and encoded into at most 4 bytes MI as described above.

Hash

[0053] 32 bytes computed using SHA-256

Signature

[0054] 64 bytes signature computed with Curve25519

Block Structure

[0055] 1. Header [0056] 2. Lists [0057] 3. Footer

Header Structure

[0058] 1. Block IdIncremental MI value starting from 94 [0059] 2. DifficultyHash [0060] 3. Core version UUID16 bytes universally unique integer [0061] 4. Pool domain address [0062] a. Domain byte length MI [0063] b. UTF-8 formatted domain address [0064] 5. Transaction fees8 bytes floating point value the total transaction fees [0065] 6. Smart contract fees8 bytes floating point value the total smart contract fees [0066] 7. RewardMI block reward [0067] 8. Reward IdMI, the wallet id to where 99% of the Reward, transaction fees, and smart contract fees will be sent [0068] 9. Leadership reward idMI, the wallet id of the leadership organization where 1% of the block reward will be sent [0069] 10. Smart contract executionHash [0070] 11. Previous blockHash of the previous block

Footer

[0071] 1. Job Id1 bytesA blob value that the pool generates to prevent mining collisions between the miners of the pool [0072] 2. Mined date8-byte integer, milliseconds epoch time [0073] 3. Blob8 byte or random data that the miners use to manipulate the block hash [0074] 4. Block hashHash, the solution to the hash collision problem within the block difficulty

Lists Structure

[0075] Each list has the below structure [0076] TypeMI list type [0077] Block idMI block id [0078] Features1 Byte feature bitmask [0079] CountMI, number of items in the list [0080] items body

List Types

[0081] The possible values for list types [0082] 1. 1 to 1 Transaction [0083] 2. 1 to many Transactions with same balance [0084] 3. 1 to many Transactions with different balance [0085] 4. Smart Contracts [0086] 5. Smart Contracts applications [0087] 6. Trusts [0088] 7. DTP: Balance update [0089] 8. List group [0090] 9. Addresses list

List Features

[0091] The possible values for list features [0092] 1. Microtransaction: If on the coin transactions amount will be encoded with MFP. if off the amount will be 8 bytes floating point. [0093] 2. Default transaction fee: If on the transaction fees will be a hardcoded value and will not appear in the transaction if off the transaction fees will be encoded with MI [0094] 3. Trusted signature: If on the signature will be omitted. Only valid in Lists group

1 to 1 Transaction

[0095] Sender signature [0096] Sender id, MI [0097] Receiver Id, MI [0098] Amount as specified in the feature bitmask [0099] Transaction fees as specified in the feature bitmask
1 to Many Transactions with Same Balance [0100] 1. Sender signature [0101] 2. Sender idMI [0102] 3. Receivers countMI [0103] 4. ReceiversEach is [0104] 1. Receiver idMI [0105] 5. Amount as specified in the feature bitmask [0106] 6. Transaction fees as specified in the feature bitmask
1 to Many Transactions with Different Balance [0107] 1. Sender signature [0108] 2. Sender idMI [0109] 3. Receivers countMI [0110] 4. ReceiversEach is [0111] 1. Receiver idMI [0112] 2. Amount [0113] 5. Transaction fees as specified in the feature bitmask

Automated Smart Contracts Creation

[0114] CreatorIdMI wallet id of the contract creator [0115] Model data sizeMI model data byte size [0116] Model dataModel data size bytes [0117] script sizeMI script size [0118] scriptMI script size bytes [0119] Creator signature

Automated Smart Contracts Copy Creation

[0120] CreatorIdMI wallet id of the contract creator [0121] Automated Smart Contracts Id, MI [0122] Creator signature

Trusts

[0123] Sender id, MI [0124] DTP wallet id, MI [0125] Termination hours time, MI. A value of zero indicates to start termination [0126] Sender signature

DTP: Balance Update

[0127] DTP idMI [0128] UpdatesEach is [0129] Id-MI [0130] Balance as specified in the feature bitmask [0131] DTP signature

List Group

[0132] DTP id [0133] ListsFrom the lists above [0134] DTP signature

Addresses List

[0135] Public key wallet addresses

Wallet Transaction Encoding

[0136] The wallet uses a simpler encoding structure. The pool will convert it to block encoding structure in such a way that it's possible to convert it back to the wallet encoding structure. The validation of wallet signature needs to be done using wallet encoding structure. [0137] Amount8 bytes floating point value [0138] Block hashThe Hash value of the last known block. [0139] Sender public key32 bytes, the pool will replace it with wallet id, so the wallet does not need to maintain addresses database. [0140] Receivers list countInteger number of the receivers [0141] For each receiver [0142] Receiver wallet public key32 bytes [0143] Amount8 bytes Floating point value the amount sent to that receiver [0144] Transaction fees8 bytes floating point value, fee amount for this transaction [0145] Signature64 bytes

Mining Process

[0146] This is a step by step process to compute a block hash [0147] I. Compute SHA-256 of the first two parts of the block: Header, Lists [0148] II. Generate job id 16 bytes [0149] III. Concatenate the results from step I and II and compute SHA-256 of them [0150] IV. Concatenate the current time step(8 bytes milliseconds epoch time) with the result from ii and compute SHA-258 of them [0151] V. Compute SHA-256 of the blob [0152] VI. Take the result of V, it's 32 bytes, sum every 4 bytes to one as seen in Drawing 3, so you get 8 bytes and convert it to Java long type [0153] VII. Use the previous result(Step VI) to pre-seed a Java.Util.Random and compute random.nextInteger(5) [0154] VIII. Use the previous result(Step VII) to select a hashing algorithm from the list below and use it to compute the blob hash again [0155] 0. MD5 [0156] 1. SHA-1 [0157] 2. SHA-384 [0158] 3. SHA-512 [0159] 4. MD5 [0160] IX. Concatenate the result from step IV, V and VIII and compute SHA-256 from them [0161] X. If the result from IX is smaller than the difficulty submit a new block, otherwise go back to step IV and try a different blob

Mining Flow

[0162] 1. Wallet(Miner) request a mining job from the Pull, the Miner, provides its wallet address. [0163] 2. The Pull generates a JobId. It will be used later to reward the Miner. [0164] 3. The Pull completes steps I to III of the Mining process. [0165] 4. The Pull sends the Miner the result of step III along with JobId and pulls difficulty. [0166] 5. The Miner continue the mining process from step IV, each time it solves the block with difficulty provided by the pool, it performs step 6 [0167] 6. The Miner submits to the pool a solution of the block under the pool difficulty, it sends JobId, blob and Mining Time. [0168] 7. The pool calculates the block hash based on the data received from the Miner. [0169] If the hash solves the block under pools difficulty, it adds one reward point to the Miner [0170] If the hash also solves the block under the block difficulty, the Pull submits a new block and share the reward with all the miners based on the reward points. The pool also keeps some of the rewards as a service fee for the miners. [0171] 8. The pool responds to the miner with the same response as in step 3 to keep the miner up to date with the new blocks that been discovered by the system.

[0172] To summarize it, the Miner will continuously keep mining and periodically send hash solutions to the pool, for each such solution the pool will reward the miner and when the solution is good enough also to solve the block, the pool will submit new block.

[0173] Each time the Miner is communicating with the pool, it will be updated with the most recent block data so it will mine the right block.

[0174] Also, note that in case the Miner had pending reward points from the pool, but another pool solved the block, the reward points will be lost, Miners only get a reward for the blocks they solve.

Joining Royal Network Flow

[0175] In case a new pool would like to join the Royal Network, let's call it pool A, it must first mine a block by its own. To help those pools, the pools provide a protocol where the new pool sends its domain to some other pool, let's call it pool B, pool B replies than with a hash code of step one in the mining process where the domain address is pool A domain.

[0176] The incentive for B to implement this protocol is that it keeps its wallet id as the reward address for the block A will mine.

Block Validation Flow

[0177] Once a block was discovered it will go through the below process of validation.

[0178] In the below validation tests new block refers to the block that been tested and Current block refers to the last block in the blockchain.

Block Hash Test

[0179] The test pass if and only if the new block hash is smaller than the new block difficulty

Mined Date Test

[0180] The test pass if and only if the tested date is before the current date and within 3 min of it. The current date is the date when the test started or the connection with the peer who provided the new block was established.

Block Id Test:

[0181] if the new block id is smaller or equal to the current block id the test fails [0182] If the new block id is greater by more than one, it can only happen when the new block was received from another pool. The pool will go into recovery mode. It will back up the database, drop it and rebuild it from the pool who sent the block. If the recovery process fails, it will fail this test and restore the database from the backup. [0183] If the new block is greater by one from the current block the test will pass.

Difficulty Test

[0184] The expected difficulty is calculated based on the last ten blocks in the blockchain, the test pass if and only if, the new block value match this value.

Core Version Test

[0185] The core version is a hardcoded value. It is used to force hard forks in the system. The test pass if and only if, the new block value match this value.

Pool Domain Address Test

[0186] One of the testers wallets issues a random protocol request to the provided domain, and the response is tested to be valid.

Reward Test

[0187] The test pass if and only if the tested reward amount matches the expected amount

Reward Id Test

[0188] The test pass if and only if the reward Id is a registered wallet id save in the database

Previous Block Hash Test

[0189] The test pass if and only if the new block previous block hash equals to the current block hash

Leadership Reward Id

[0190] The test pass if and only if the leadership reward id matches the hardcoded value

Transactions+Transactions Fees Test

[0191] The test pass if and only if the below conditions are true [0192] All transaction signatures are unique and valid [0193] There is no wallet with a negative balance in the system [0194] The transaction fees in the new block match the expected value [0195] The total amount of coins in the system wasn't changed

Automated Smart Contracts+Automated Smart Contracts Fees Test

[0196] A file is created. [0197] For each each command to move coins coming from Automated Smart Contracts, one line is being written to the file, it contains the information of the amount being transferred and its destination. [0198] Then file Hash is being calculated using SHA-256. [0199] The test pass if and only if the below conditions are true [0200] Calculated hash value match Automated Smart Contracts execution hash value [0201] Automated Smart Contracts fees in the new block match the expected value [0202] The total amount of coins in the system wasn't changed

DTP Flow

[0203] DTP publish its wallet and ask users to sent trust transactions to it with some minimum termination time. [0204] Users sent trust transaction to DTP from their wallet app. [0205] Periodically the DTP makes update transactions to match users balance in DTP to their balance in Coco.

[0206] In case DTP needs to make transactions to wallets that did not entrust it, it still can do it in an efficient way using the List Group transaction. The List Group transaction using the same encoding as done in the block and can contain multiple lists inside it, from any type, while the DTP only required providing just one signature, it's own.

Transaction Flow

[0207] Users feel in the transaction details as listed below [0208] Full amountWill be encoded as 8 bytes integer [0209] At least one recipient's wallet address [0210] Fees: User can either specify a nondefault fee amount or leave it blank to use default fees [0211] The wallet sends a prepare transaction request to the pool [0212] The pool calculate transaction fees and validate the transaction, in case the transaction is valid the pool respond with the full transaction details otherwise it sends the reason why the transaction was invalid [0213] The wallet presents to the user the entire transaction with the exact mining fees [0214] The user can choose to approve or discard the transaction, in case the user accepts it the wallet submit the transaction to the pool [0215] The pool validate the transaction and broadcast it to the other pools [0216] Eventually one of the pools mine the transaction to the block [0217] In case of no pool mine the transaction it will expire after six blocks

Block Reward Flow

[0218] The block reward is calculated as follow:

[0219] 250floor(block Id/3188)

[0220] The reward starts from 250 coins and every 3188 blocks the reward is reduced by one coin until it reaches 0. The first block id starts from 94. It makes the total coins in the system to 100,000,000 coins.

[0221] After the reward reaches 0, the formula will be changed to the one below: min(Total lost coins, 50)

[0222] Every block reward will be 50 coins until the lost coins are consumed.

[0223] The lost coins are coins collected with the below process:

[0224] After the first block, after three years of the last run, starting five years from the first block, the process will run and delete all the wallets who haven't made any transactions for the previous three years, and the DTP didn't update their balance for the last three years. Their balance will be added to lost coins.