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.
Every single user is connected to 4 nodes using the User Router coded in the interface. These connections are meant to both transfer the content and to apply the BCL (Bitcloud Cryptographic Law).
Even if the content is not protected, all communications are encrypted, in order for an external viewer to not be able to distinguish between protected and unprotected content.
Encription in the server end is also recommended.
The process (using the graph above as an example):
- The User Router finds 4 random nodes. This router is coded in the user interface. Dispersion Law
- The User Router asks the 4 nodes to find a route to the content. Service Law
- Nodes answer with route data. Service Law
- The User Router selects the fastest. The fastest is calculated in function of the data retrieved in the last point, and usually is a combination of bandwidth available and shortest distance. In the example, Node3 is the fastest because it happens to be also a Final Node for the requested content. The second fastest should be Node2 because it has more connections to nodes having the content. If the requested content is cached in any of the Nodes, it should be considered as fast as actually being a Final Node.
- Money is generated only in the User Router’s connected nodes, never in the Final Nodes to avoid short circuits. Only exception is when the Final Node is also one of the connected nodes. Bandwidth Law
- If a Final Node denies service, Service Law is applied.
- Optionally, connected nodes can cache the content so they don’t need to retrieve the content from the Final Nodes if the content is requested often.
- While the User is downloading/uploading the content, he must inform all the connected nodes about the quality of the connection. If quality is low, he can select another route from another node and denounce about the issue to the other nodes, so they can apply the law. See “User Router” section for a better explanation. Bandwidth Law
- If quality is low, an Investigation Process to find the culprit is executed. Culprit can be the Final Node, the connected Node, both, or none. Bandwidth Law - Check low quality culprit section.
- User is banned if he tries to abuse bandwidth or the law. Bandwidth Law - Abuse check section.
- Law is enforced when at least 3 of the 5 workers agree (the 5 workers are 1 user + 4 nodes).
When a content is marked as protected, the Bitcloud net protects both the IP and domain name of the node serving the content. The user requesting the connection is also protected. There is still a way for auditors to know that a certain computer is acting as a protected node, but will not be able to know what is the protected content that is serving. Even more, external auditors cannot distinguish between the content routed or served while analyzing the traffic to a specific node.
All nodes are enforced to accept protected content routed, even if they are not protected themselves. Nodes cannot know what the content being routed is because it is multi-layered encrypted.
We use a routing process similar to Tor Onion hidden services, optimized to our purposes.
- The user chooses a collection of 4 random nodes. Dispersion Law.
- The User Router (coded in the interface) asks the 4 nodes to find a route to the Protected Node, encrypting the request with the public key associated to the Protected Content, and adding its public key inside the encrypted request (so only the real Protected Node can know what is sent back). Service Law
- Each node tries to find a competitive route to the Protected Node and answer fast to the User. The way to do this is by sending the encrypted request to all the nodes it is connected to and wait for an answer. Service Law
- The Private Node is found when it is able to decrypt the request. Otherwise it is re-dispatched to all connected nodes.
- To protect itself, the Protected Node adds a random time (lag) of response to the request, equivalent to several searches. We recommend a random number between 1s and 5s. Once answered, the node must stick to that approximate lag, but can change it when requesting a different content for another publisher or when certain time has passed.
- There is the lucky possibility that a connected Node is also the protected one having the content (like Node1 in the graph). In that case the protected node adds the convenient lag time to protect itself.
- Meanwhile all nodes are attending other requests for other contents, so nobody knows if the other requests are actually part of the original request or not.
- The Protected Node always sends back the content encrypted with the public key inside the request, so only the user can know what the content is.
- The User Router chooses the fastest route.
- Only the User Router’s connected nodes generate any money, to avoid short circuit cheats. Bandwidth Law
- The User download/stream/upload the content throughout the fastest route. Bandwidth Law
- Meanwhile, the User informs the rest of the nodes about the quality of the connection. Bandwidth Law.
- If the quality is low, the User Router tries to change to another route Node while informing the issue. Bandwidth Law
- The selected node also enforces the Bandwidth Law and Service Law for the Middle Node it is connected to.
- Each Middle Node also enforces the Bandwidth Law for their connections.
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.