The reason why we have published this before it is finished is because we want to be really open in all regards.
We want to attract thinkers to discuss all the flaws we may encounter in the hard road to make this incredible and big project to success.
Please contact us at http://talk.bitcloudproject.org
Bitcloud is a new protocol based on the ideas of Bitcoin, Mediaglobin, and Tor.
Users adhering to this protocol will be able to:
- Upload any file to the Bitcloud net and make it available to anyone.
- Download and stream the content to anyone.
- Select which moderator you want to use, from anyone.
- Earn money from advertising or disable advertising completely.
Nodes adhering to this protocol will be able to:
- Generate and earn profitable income in relation to the bandwidth they share.
- Select what content they cache and serve by selecting moderators.
Moderators adhering to this protocol will be able to:
- Approve and categorize user content.
- Approve or ban nodes.
- Earn profitable income throughout advertising.
Any person can become a user, a node and/or a moderator at any time. In addition to this, there will be client applications which serve as an interface to the general protocol named Bitcloud. We are presenting Wetube as the primary interface for our first version, but programmers can make any kind of interface, providing that they follow the rules described in this protocol.
The Bitcloud blockchain can be independently accessed for money transactions, so external wallets without using the main interface are perfectly feasible.
Bitcloud works by following a special set of premises refered as laws. The laws in the software ensure that the system is running smooth without spammers and selfish serving, so everybody can trust the system. These laws are initially imposed by the programmers and can dynamically change over versions.
The entire system can be fully scriptable in real time using simple to use and parse lambda expressions, so advanced users and programmers can tweak and modify the way in which they are connected to the Bicloud net, embed actions into web pages, use in their internal programs (in any language), etc. Nodes can be accessed in real time by their owners with full control to the entire running system. We are looking forward an incredible level of flexibility in where all users can review and enhance the living (running) network.
Our original idea is to make Bitcloud available for general use without requiring special tools or software. The first interface for Bitcloud will be Wetube, which is a collection of scripts running in the browser.
In addition, bandwidth is free for users.
This will allow a whole new possibilities for mainstream adoption not possible with actual p2p protocols. Just to cite some:
- Embedable in webpages by the insertion of a JS script acting as a very thin layer between users and nodes.
- Accessible from external languages, and easy integration with any kind of program.
- Mobile applications that work out of the box without wasting bandwidth and resources.
- Rapid access without having to earn rights like in kademlia and bittorrent.
Bitcloud separates the layer of selecting material from the storage itself, and allows nodes to select which moderators to adhere.
Because nodes are totally free to choose moderators, determining who is storing the content in the long term becomes a very fuzzy thing.
In addition, a node can also include protected content (the source and destination cannot be determined) which they can serve at the same time than unprotected content, so only direct access to the node can conclude into liability. But because source and destination cannot be determined, finding such a node becomes extremely difficult. This improves protection compared to Tor.
- The Bitcloud Cryptographic Law (BCL) is a serie of “laws”, and there are “judges” in such a way that workers in the net judge other workers and emmit “verdicts”. Consensus in the verdicts enforce the appliance of the law in the form of rewards and penalizations, and store them in the Blockchain and Node Pool.
- The Bandwidth Law is the law ensuring that nodes route traffic from users to the Bitcloud net to get/post content. Nodes are paid for doing so, by generating money. See Unprotected Routing section
- The Dispersion Law ensures that no one tries to cheat the system. It does so by dispersing the connections from user to nodes and nodes to other nodes.
- Storage Law ensures that nodes store guarantied content.
- Service law ensures that nodes don’t deny service.
- We use our own language for control commands and objects.
- Money transactions are stored in the blockchain.
- Node states and verdicts are stored in the Node Pool.
A worker is basically any entity that is a user, a moderator or a node. We encapsulate this into a general class because all workers have some variables in common, like the alias or the public-key. Then we derive the specifics workers from this class.
User:
class Worker {
alias
private-key
public-key
banned?
banned-time
protected?
IP
}
Worker --|> Node
Worker --|> Moderator
Worker --|> UserIs usually the name or nick chosen by the worker. _TODO We have to think if we want to implement our own ID system or use an existing one like Keyhotee or Namecoin_.
The private key of the worker used to sign actions. Normally this variable is only available in the computer of the worker and nowhere else.
Is generated from the private key and is used for all wallet operations plus to verify signatures in the judges and enforcement (see below).
Is t when the enforcement rutine determines so. A banned worker cannot use the Bitcloud for a specific period of time defined in banned-time.
Is t if the worker enters into a special mode in which all the content it uploads, moderates or stores is encrypted and enrouted protected (the IP cannot be determined). More below.
The actual IP of the node. NULL if protected.
Nodes are the primordial base for the Bitcloud network and most of the work is done there.
Nodes run the program bitcloud. This program maintains a cache of files served and provides the necessary bandwidth for the Client Applications to work.
Nodes also do the important work of providing Proof of Bandwidth so the cloud runs consistently and everyone generates the money they only deserve.
Like it happens with Bitcoin, a block reflecting all the transactions are generated once every 10 minutes. This block represents the consensus of the Bitcloud net about the operations made in itself since the last block. It contains all the money transactions made, including the ones generated by the nodes by bandwidth sharing. In order to preserve space, it does not contain all the details of the nodes states nor any content at all.
The blockchain is the chained collection of all blocks generated since the born of Bitcloud. It’s contents are perpetual and immutable.
In addition, there will be a Node Pool. This pool is regenerated every 10 minutes after a new block is generated and contains the state of all nodes. When regenerated, all nodes apply the rules under the section Proof of Stake to it, to ensure that every node meets the rules and no one tries to take advantages over the rest.
The nodes store the content in the form of a cache pointing to moderators, as defined in the variables.
- Moderators do have a list of contents and/or users to which they are attached.
- Nodes select a list of moderators they want to be adhered to.
- Nodes store the content for the moderators
Moderators can’t ever select Nodes. See Moderator Class for more details.
Note: anyway we can implement a kind of query that a moderator can send to a node asking for storage in exchange of money, and the node is free to accept or deny.
class Node {
dns-name
max-download-speed
max-upload-speed
max-space
signature
accepted-coins
moderators
preferential-moderators
cloud-moderators
content-waiting-for-approval
protected?
shutdown-date
}
Worker -right-|> NodeAre the variables that define how much the owner of the node wants to share, expressed in Mb/s.
Is in Mb and it is the maximum size to allocate for the files cache. When the space occupied by the cache pass this variable, the least requested files are deleted.
Refers to the public key of the node, used to sign transactions in the BCL routines.
Is a list of accepted coins for exchange. For example `’(BTC LTC)`. If a node accept BTC, it must run the bitcoind daemon.
Is a list of normal moderators for which the content is accepted to be cached. The content cache can vary, so a node can automatically select the content to be cached in function of the number of requests. If this variable is NIL, the node becomes unmoderated and caches everything that goes through.
Is a list of moderators whose content is always going to be cached entirely. This is useful for moderators that also own nodes.
A list of moderators for cloud personal storage. These moderators put a price for content storage. This content is guaranteed to be stored until 1 year has passed since the user paid, or until the user deletes it or the moderator stops supporting the user.
Note: the sum of the space required by the moderators in **cloud-moderators** and **preferential-moderators** should be less than **max-space**. bitcloud daemon should log a warning if that happens, and POS policies could ban the node.
A list of contents uploaded from the users that are waiting for the approval of the moderators adhered to this node.
How much time this node is going to wait for the approval on any moderator adhered to this node. Passed that time the awaiting content is deleted from the cache. Minimum time allowed is 12 hours. Defaults to 48.
Whether the node IP is protected and the content in the local cache is encrypted with the private key of the node. But this has some downsides, the most important is that data is routed throughout many nodes, adding costs in bandwidth and latency.
When is the node going to be shut down automatically. Useful for protected nodes that serve delicate content.
Moderators are crucial to the well-working of the Bitcloud. Their main tasks are:
- Approve user content. The user select a list of moderators to which s/he wants to adhere, the moderator receives the request and decides if the user meets his/her requirements.
- Categorize. A moderator properly corrects tagging of the content s/he receives from the user.
- Advertising. Advertisers select which moderators they want to adhere, and ads are only shown in the content approved by that moderator. Moderators are paid for this, and they put the price. A part of this price goes to the publisher.
As a vital an important imposed limitation: moderators cannot choose which nodes to adhere, but nodes can choose any moderators they want. This is a way to avoid censorship because any node can store any content that the owner wants. This is also a good way for nodes to make money without having to be approved by anyone. An advantage for moderators: they don’t have to have the technical skills to maintain a node, and do everything from the user interface, as the maintainer of the node can be another person, or even a rented pre-configured node from an ISP.
class Moderator {
contents
trusted-users
supermoderators
advertisers
ads-price
ads-share-to-users
tags
}
Worker -right-|> ModeratorThis is a list of contents that the moderator has been approved. Nodes who have selected this moderator have the obligation to maintain a cache with the files this moderator approves.
Users are the ones that obtain the benefits from the services of nodes and moderators, because they are who send and receive the content.
The use of the system must be transparent to the user. S/he should be able to connect using his/her client or browser without having to do anything special and without requiring any technological expertise.
class User {
votes
wallet
favorites
moderators
history
updloads
}
Worker -right-|> UserAll the workers need an alias.
There are 2 kind of aliases:
- Anonymous, it is the same as its public key, generated from a private key that only the worker knows. Length must be checked to ensure randomness.
- Registered. The worker pays a quantity for a name, and that name is attached to his public key in the Blockchain for ever.
Every worker owns a private key. A public key is generated from the private key.
The private key is never sent in any way. The worker is responsible for all the security matters of managing this key.
The public key of nodes working for the current period is published in the Node Pool.
Money transactions affecting the public keys of any worker are published in the Blockchain.
Most communications between users and nodes are done using the well understood and easy to use HTTP network protocol as a base. We choose to use HTTP because it is enough for our requirements and because it is widely available.
We choose the default 80 port for communications, with the option for nodes to select any other alternatives. The reason to use this port is that people behind a firewall can still access the complete net without the typical restrictions. Most ISPs prioritize this port over the rest, making it the fastest and more reliable port. Also, censorship becomes much more difficult.
Nodes wanting to use the 80 port for other purposes (like for example a classical web server) can use any of the Unix tools available to route domains, like for example nginx.
We don’t use any p2p low level protocol like Bittorrent because we need very fast access with the less possible lag. It also happens that many ISP actually censor Bittorrent protocol. In addition, using simple HTTP will simplify the protocol very much.
We are also supporting the serving of static web pages stored in the nodes outside of the Bitcloud, in the official Bitcloud server program. These pages are considered a wrapper for Bitcloud. The purpose of this is to allow nodes to become entry points for users:
- To allow the users to download a full featured client.
- To allow the users to connect “hot” using a JavaScript client.
- To allow nodes to provide informational static content only relevant to that node. For example, a TV channel, a book editor, a corporate web. They can embed content from Bitcloud in those static pages.
- To publish the statistics of the node in real time to the WWW.
NOTE: those static pages are considered to be out of the Bitcloud, except if the content is embed (and only for the content), so they don’t apply to the law of Bitcloud, nor to its benefits.
In addiction to this, nodes can install their own HTTP server (like Apache) and serve dynamic pages using local routing facilities like nginx.
We don’t need to resolve node names because content is provided to the users by simply requesting it to the nodes s/he connects to.
Each content is signed by a user and a moderator. The workers only have to request the content matching the hash of the content, and the routing routines are in charge of finding the nodes having it.
Every new node must register into the network and provide the necessary details specified in the Node class.
Every user is connected to a randomly selected collection of 4 nodes. Dispersion Law.
The user running a full featured user client can find those 4 nodes directly. Typically the client will have a collection of trusted nodes already coded in, and they can obtain the rest of the available nodes from any of them.
The users running a thin client in JavaScript in the browser do obtain the script from an Entry Point.
Both clients act as full workers and are governed by the laws. If a user do use a corrupted client that tries to cheat the system, it is penalized and/or banned by applying all the laws affecting users. Service Law.
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).
Example graph:
:User: <-down-> (User Router) : Request Content
node Node1 {
(Node Router) as NR1
}
NR1 <-up-> (User Router)
node Node2 {
(Node Router) as NR2
}
NR2 <-up-> (User Router)
node Node3 {
(Node Router) as NR3
node Final3 as "Final Node C"
}
NR3 <-up-> (User Router)
node Node4 {
(Node Router) as NR4
}
NR4 <-up-> (User Router)
node Final1 as "Final Node A"
node Final2 as "Final Node B"
NR1 <--> Final1
NR2 <--> Final1
NR2 <--> Final2
NR2 <--> Final3
NR3 <--> Final3
NR4 <--> Final3The 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 select 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, it 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 agrees (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 an specific node.
All nodes are enforced to accept protected content routed, even if they are not protected themselves. Nodes cannot know what is the content being routed because it is multi-layered encrypted.
We use a routing process similar to Tor Onion hidden services, optimized to our purposes.
cloud "Cloud of Nodes" as MN {
node "<color:red>PROTECTED NODE B</color>" as pnode
node "MiddleNodeA" as mnodeA
node "MiddleNodeB" as mnodeB
node "MiddleNodeC" as mnodeC
node "MiddleNodeD" as mnodeD
node "MiddleNodeE" as mnodeE
node "MiddleNodeF" as mnodeF
}
node Node1 {
node "<color:red>PROTECTED NODE A</color>" as pnode2
(Node Router) as NR1
NR1 <--> pnode2
}
node Node2 {
(Node Router) as NR2
}
node Node3 {
(Node Router) as NR3
}
node Node4 {
(Node Router) as NR4
}
NR1 <.down.> mnodeA
NR2 <.down.> mnodeB
NR3 <.down.> mnodeC
NR4 <.down.> mnodeD : "<b>multi-layer encrypted data</b>"
(User Router) as RS
RS <-down-> NR1
RS <-down-> NR2
RS <-down-> NR3
RS <-down-> NR4
:User: <-down-> RS : Request protected content
mnodeA <--> mnodeF
mnodeF <--> pnode
mnodeB <----> pnode
mnodeC <-> mnodeD
mnodeD <--> mnodeE
mnodeE <--> pnode- 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 Prrotected 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 moderator 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 send back the content encrypted with the public key inside the request, so only the user can know what is the content.
- 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 other 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.
The mission of the User Router is to find the fastest route to a solicited content, whether it is protected or not.
It must be coded in the user interface and must respect the BCL in order for the user to not be banned.
Its principles are simple, and should be easy to code in any language, even JavaScript for the browser.
(*) -down-> "Ask Entry Point for random nodes"
--> ===AN===
-down-> "Ask Node1"
-down-> ===Sync===
===AN=== --> "Ask Node2"
-down-> ===Sync===
===AN=== --> "Ask Node3"
-down-> ===Sync===
===AN=== --> "Ask Node4"
-down-> ===Sync===
-down-> "Select Fastest"
-down-> "Download/Upload/Stream"
if "is quality ok?" then
--> [low quality] "Inform low quality to other nodes"
else
----> [high quality] "Inform high quality to other nodes"
-down-> (*)
endif
"Inform low quality to other nodes" --> "ask to the next fastest"
-> "Download/Upload/Stream"
"Inform low quality to other nodes" ..> [no more nodes] "<color:red>ERROR</color>"Bitcloud is a very complex distributed database and certainly cannot be satisfactory operated without a proper language.
We choose a similar query language to SQL, but using s-exprs or lambda expressions so it is easier to parse, use and expand. We provide many convenient forms and functions so user interface designers can extensively take advantage from them.
Any command is visually constructed by first specifying the name and then their parameters, all between parenthesis, this way:
(command value1 :param2 value2 :param3 value3)
All parameter names are prefixed with a :.
The first value doesn’t need a parameter name because it is the fundamental parameter for the command.
The rest of the parameters are named, and in fact their positions doesn’t matter at all.
Values can be of type:
- strings, surrounded by ””:
(search "wetube") - numbers inserted directly
(search "wetube" :show-results 50) - single strings or symbols, they are the same as strings but used for
just one word:
(search 'wetube) - literal lists prefixed by a ‘ and followed by parenthesis and values
separated by spaces:
(search 'wetube :moderators '(modA modB)) - booleans which are just t or nil:
(verdict t :reward 1.23) - output from other commands surrounded by parenthesis without the ‘:
(search 'wetube :moderators (search-moderators 'mod :protected t))
In addition to commands, we also use lambda expressions to form the format of objects, mainly used for return values from commands, blockchain transactions and Node Pool states.
(object value1 value2 :slot1 slot-value1 :slot2 slot-value1)
In contrast to commands, an object may have any number of unnamed values. It can be the case that some objects just don’t have any predefined slots.
Named slots are always at the end of the lambda list to avoid confusion.
It is better seen as examples:
(verdict t :reward 1.23) (results )
Mostly because they are easy to parse, extensible, and easy to construct lists in. We are using a lot of lists and we must provide a way to effectively manage them. Another advantage is that we can also use the same language for the the object and command formats.
Other alternative would be: a combination of SQL constucts and JSON objects, but that would be harder to think and parse, and would require bigger programs for small clients like JavaScript embedded scripts.
We provide many utility functions and constructs so workers can do very advanced queries to nodes.
Compression is very easy to implement for lambda expressions and happens in real time when storing the blockchain in a file. We just need to assign a constant binary number for every tag and store that number instead of full names. Numbers can be stored in a fixed size 64 bit floating point format.
In addition, there should be a second compression pass using the standard LZO libraries, available for all the languages.
The Cryptography Law, also called Proof of Stake in more simple projects, is the law of Bitcloud - what governs it - providing the rules in the form of algorithms executed by the nodes and clients in real time.
Each rule must be applied for every node or client in the net. Appliance to every rule is rewarded in the way described in the rule. Non-compliance results in penalization.
This fine equilibrium ensures that every node does the work correctly and there are no abuses.
Like in the real world, here there are laws, judges and rule enforcers. The main difference is that here all nodes and clients are the judges and the rule enforcers, so the law coming in the form of computer algorithms is applied by the consensus of the entire Bitcloud net.
We have named every rule with an easy to remember name, so workers of the system can refer to them when talking to other workers and non technical people.
Basically, the law is applied by judging (checking) that every node and client is doing the work as it should, so, when asked, it should answer with the truth of what is asked. If it is found that the node or client is lying, it is penalized or banned, and its transactions rejected are not included in the blockchain.
Laws are written in the source code in the form of generics and the corresponding methods. A method is a specific application of a generic. For example, for the generic of the Law of Bandwidth there are going to be several methods for judging nodes, users and moderators.
This is a subprocess of the general sync process, as described in the Nodepool section.
(*) -right-> [sync process] select workers to judge
-right-> judge workers
-right-> enforce verdicts
-right-> [freeze pool process] (*)The return of those functions is always a verdict, in the form of lambda expression, so it is easy to parse from scripts[fn:1]:
(verdict t :reward 0.2345)
(verdict nil :penalization 1.3 :ban 6)The first var is t or nil indicating if the verdict is favorable or not. The rest indicates the properties of the verdict, to be applied by the enforce generic.
The purpose of it is to certificate (sign) the verdict and write it in the Node Pool State when appropriate. When there is general consensus (for example, 80% or more of the workers agree with the verdict), the current Block is frozen and added to the Blockchain, and the Node Pool State is regenerated using relevant parts of the old data for the new start.
- All nodes must be in sync of time with the official world time
at GMT with a maximum variation of 10 seconds. Clients are not
forced.
(defgeneric judge-time (worker)) - Check is made sending a request to the other node and comparing
to the actual date in the moment of sending the request.
(defun request-time (node))Function returns `(get-universal-time)` of the other node.
- No reward for appliance.
(verdict t) - Penalization of 1 MAC (X) for every 10 seconds out of sync on
each block generation. Ban for Y periods if it is 30s or more
or the node hasn’t got enough money to pay penalization. All
operations of the node for the current block are rejected (Z)
only if time variation is bigger than 30s.
(verdict nil :penalization X :ban Y :reject Z)Y is 1 for one time ban. Y is 6 if the node persists. Y is 144 if it persists even more. Y (1,6,144)
- All nodes must write the correct dates in all connections and
associated transactions.
(defgeneric judge-timestamps (node connection)) - Check is made looking at the states written by the node in the pool. All dates must be correctly dated within the period of the block being analyzed.
- No rewards for appliance.
(verdict t) - Immediate penalization of 1 MAC and ban for Y (6, 144,
288). Reject all transactions.
(verdict nil :penalization 1 :ban Y :reject 'all)
- All workers must answer in less than X seconds to any query or **sync** function. Recommended constant for now: 600ms.
- No rewards for appliance.
(verdict t) - Ban X(1,2,6,144) if slow or saturated connections.
(verdict nil :ban X)
https://github.com/wetube/bitcloud/blob/master/proof-of-bandwidth.org
DRAFT: Workers must answer to queries exactly as they are supposed to answer. The worker informs to all other connected workers about how things are going on in its relation to the connected worker. Verdicts are written in the Node Pool as always. If it is found that a node denies service to another worker, penalization happens. No reward for appliance.
Ensure randomness when selecting nodes. We must provide a way to assign random nodes to concrete user IPs, and they can’t change for the time that a block is generated, to avoid users requesting many random nodes in a short period of time.
This law also must forbid the connection of users to nodes using correlative IPs to avoid the “bulk IP attack”. Example: 123.123.123.X being X the correlative IPs.
At the same time we can optimize by connecting to geographically closer nodes by prioritizing the assignment of certain nodes, for example those matching the mask 255.0.0.0. Only applicable if there are sufficient nodes inside the mask to assure certain randomness.
Being discussed here: http://talk.bitcloudproject.org/index.php?topic=10.0
We use a Blockchain in order to store all money transactions, including the ones comming from the nodes for Bandwidth sharing.
We are not using the Blockchain to store any information related to the content at all. If we do so, very soon the Blockchain would become very big. For such things, we use the Node Pool.
We can’t use an existing Blockchain from another coin like Bitcoin for the simple reason that we must generate the money from bandwidth sharing. But we are providing exchange facilities that could be inserted in a user interface like Wetube.
Block1 : Born
Block1 -> Block2
Block2 -> Block3
Block3 -> BlockN
BlockN -> LastBlock
LastBlock -> [*] : Block being madeA new block is generated once every 10 minutes after the Node Pool is synced and signed.
In order to avoid some scalability issues, there is a process of simplification that happens for data stored in the blockchain from certain time backwards. This process removes all transaction data except the amount of money owned by every account when due-date arrives.
The Nodepool contains all the information relevant to the nodes, and it is constantly calculated in real time.
This is the interface for the node (not the users) so the administrator can see and tweak values in real time.
With not so much modifications, this DA could also provide social content with characteristics competing to those of centralized private sites like Facebook and Twitter.
[fn:1] In order to make things easy for system administrators and programmers, we are using lambda expressions. These are simple expressions enclosed into parenthesis with the action in the first position. It is actually very easy to translate from jason-format to lambda expressions. We choose lambda expressions because they need less space and are faster to parse and write.
[fn:2] Renting a server or VPS is very cheap today.