Bitcloud is a reputation-based system with rewards/penalizations applied to all the users. That’s the only way to go if we want to ensure a certain quality of service, and be paid for that.
In the case of Bitcloud, bandwidth is free for the users, but nodes generate money from it. When money is involved in an automated system, you must ensure that all parts are commited to their work.
The laws of Bitcloud are there to ensure an easy ramp to profitability, an incentive to keep availability and a short cutoff for reputation so workers stay relevant.
For example, the law of service could take in count the floating average of daily uptime, averaged across the past week, to enforce rewards by lowering the difficulty of mining bandwidth, or penalize with more difficulty and/or even with direct penalization for low quality service.
The laws are applied by judging QOS while routing and syncing. All nodes implied in any query or transaction are forced to judge the rest of the nodes while the service is being executed. Verdicts of actions are recorded in the Node Pool. When a new block is generated, consensus of the majority of the nodes enforce the verdicts found in the nodepool and sign rewards and penalizations directly in the blockchain. Other actions like banning persisting low quality nodes for a period of time are also feasible.
See unprotected routing in the main paper for now:
See protected routing in the main paper for now:
If we don’t provide the rules to ensure that somebody tries to cheat the system by connecting to itself, soon the system will be full of people serving themselves and gaining money out of thin air.
So we really need a random way of interconnecting workers. Even further, connection must be assigned, never chosen. Workers trying to connect to a non-assigned node must be penalized and even banned.
We could discriminate by IP, but that present many problems:
- Many users are behind proxies, with thousands of users behind them.
- If you ban an IP proxy, you ban thousands of potential users.
- You must forbid connections for correlative IPs in order to avoid the “bulk IP attack”, a form of sybil attack.
- Users can change IP easily.
- Botnets using millions of infected home computer can easilly success in attacking the system.
The classical Sybil attacks consist in the creation of millions of IDs in order to DDOS a system to obtain benefits or spam.
But what would happen if creating an ID becomes expensive? For example, it could take 1 day or 1 week to create a single name. Sybil attacks would not be a realistic thing because you can’t generate so many IDs to make viable such a thing.
So we introduce Mined Names, similar to Keyhotee and Namecoin.
Nodes and users willing to register a name are required to mine an ID before they can enter the system. This means we can discriminate by ID without having to worry about sybil attacks.
In addition to allow the registered entrance of the workers in the system, mined names are CA (certificate authorities) by themselves, capable of deriving (signing) other IDs. Anyway, derived IDs are not allowed for nodes or registered users in order to use the system. Only unregistered users can use them.
Anonymous unregistered users also require a pair of keys; do they require to be mining for 1 week before they can enter into the system? That would kill the whole idea of embeding content in webpages for universal access.
So we introduce Delegated IDs.
A node is free to generate any number of unregistered IDs from its own mined ID. Everytime an unregistered user use any of these keys, the net can identify the originating node.
Sybil attacks could be mitigated by putting a limit on the size of delegated IDs, where the increase in mining power of the node gained by adding a new delegated ID would decrease after a certain number of delegated IDs were added. Considering N the average number of delegated IDs per node in the entire cloud, 1 through N would each gain 1 vote towards enforcement of network activities and mining, testing the network, etc. After N, the weight would decrease in a logarithmic fashion and would eventually reach 0, losing mining power and confronting penalization in the form of ban for the node and all its derived IDs.
In other words, nodes trying to create more unregistered users (assigning delegated IDs to them) than the average of the net will considerably lower their profits for mining bandwidth.
This, combined with a way of detecting cross root CA intents of constant abuse results in a reliable way of mitigating Sybil attacks.
Now, one important flaw with this is that any malicious user could request many delegated IDs, potentially harming innocent nodes.
A possible solution may be the inclusion of captchas in the user interface of the unregistered users. So when an unregistered user is trying to download or view something, the answer to the captcha must be effectively provided in order to obtain a delegated ID. Cookies could be used in some way, so users are not disturbed with captchas all the time.
The assignment must be provided by an algorithm executed in all the participant nodes, and enforced by mutually judging actions and emitting verdicts in the nodepool, following these principles:
- Assignment is fixed for a defined period of time. For example, for the next 10 minutes of a certain connection, the worker cannot solicite a change for their assigned node.
- Connections cannot be made for workers sharing the same root CA (Certificate Authority). That is, workers and delegated IDs cannot connect to themselves, except when there is no reward for so.
- Encourage the connection between non-related CA workers by a logarithm decrease of the amount of profit while mining, determined by historical bandwidth statistics between them. Statistics are stored in the nodepool.