I have been lurking around here for the past few days, so I thought I would sign up and make a post. I realise this post does not really belong in this forum, however I also realise that 1) it will be moved to an appropriate forum (where I cannot currently post) 2) it will raise my post count to 1, so four hours later I'll be able to go to the forum it's been moved to and post.
Though I have a bit of casual knowledge about cryptography (from reading about PGP, Bitcoin etc over the years), I'm certainly not an expert. Nor have I done any programming in years (and even then it was only amateur). This idea therefore is not fully formed (I literally only dreamt it up a few hours ago). I am only giving a very rough notion with many flaws, in order to generate some constructive discussion about whether something like this might be in any way viable, or if it is not doable at all.
The idea is not purely crypto-currency, though it does involve crypto-currency as a core element (and the non-crypto-currency bit involves P2P, decentralisation, crytography etc. anyway), so I thought I would post it here. The idea is a decentralised cloud storage network ("swarm storage" I'll call it) which relies on a new cryptocurrency whose value is pegged to a unit of storage in the swarm. I'll call that cryptocurrency "SwarmCoin" for now, for want of a better name (though the "Coin" moniker unhelpfully suggests it's another Bit-clone altcoin, which it isn't). SwarmCoin allows users to buy storage space on the network in a decentralised way.
A while ago I became aware of a distributed (but not decentralised) swarm storage solution called SymForm (
http://www.symform.com). Users can either buy storage from the company, or can get some storage for free by allocating some of their own hard-drive space for use by the swarm. At the moment they offer 1GB of free swarm storage for every 2GB of hard-disk space sacrificed. They also require that anyone donating disk-space to the cloud be constantly connected to the cloud (the service is aimed more at businesses). I don't know on their system how many different nodes a file is distributed to, but I would imagine it would be at least two. This means that if you donated two gigs to the swarm, getting one free, and you used that whole gig, then your gig of data would be held by at least two nodes taking up at least two gigs of the swarm's capacity and thus cancelling out (or even negating) your two gigs contribution. If everyone used up their allowance to the max, there wouldn't be enough space to go around, and that's not even including the people who pay for storage without contributing any disk space! The reason that their business model works of course is that by and large users DON'T use up all their allowance - there is
excess liquidity in terms of storage space so they are able to offer a multiplier of 0.5 for free to everyone donating space, as well as selling space on top of that.
In the system I am proposing, which should be fully decentralised, nodes will not have near 100% uptime, so files will need to be distributed across a much larger number of nodes, and the effective storage capacity of the network will not simply be the sum of all donated storage, therefore the amount of excess liquidity could be much lower - it would likely take some testing on a real or pseudo-real network to get a good idea of how much liquidity we could afford to lose. Every node that donated x amount of storage capacity would receive k*x free. Because the nodes in our network won't (likely) be "always on", we measure donated/used storage in
gibibytehours rather than just gibibytes. And nodes would receive their free storage in the form of SwarmCoins (SWC). For ease of demonstration, I will assume that 1SWC = 1GiBh, though in practice it might be better pegged to a different number of GiBh (or MiBh, TiBh etc.) This free storage (in the form of SWC) is a node's reward for providing capacity to the network (just as tx fees and new coins are miners' reward in bitcoin for processing transactions). They can either use the SWC for storage themselves, or sell them for fiat, bitcoin or whatever at an exchange. [There is one obvious issue this could cause, see below #1].
I shall now explain how the system will work: each SWC is made up of a pair of keys, one "public" and one "private", with a certain hash of the public key being the "address". I shall loosely call both this hash and the associated key-pair
the address. Each address in the swarm functions like an account: all the files uploaded by the same address are linkable to each other, but files uploaded by different addresses with the same owner are not (necessarily). When a user uploads a file to the cloud, he first chooses an address (that he owns) to upload it with. The file is encrypted using some keypair the user owns (could be the address but not necessarily). Then a (non-encrypted) header is generated which contains meta-data, including a
file id (which identifies the file amongst all the files uploaded by this address) and a
version number (which identifies the file amongst its revisions). The header also includes the address's public key (or perhaps just the short address if it's possible to verify a signature with just the hash). The encrypted file is appended to the non-encrypted header, and the whole thing is signed with the address's private key. Only the owner of the private key used to encrypt the file can access its contents, keeping files on the storm secure. If the user wants to replace the file with a newer modified one, he encrypts the new one, creates a header using the same address and file id but a greater version number than the old file, signs it with the same address and broadcasts it. When any node that is hosting the old file picks up a file with the same address and file id but a greater version number, it checks the signature of the new file against the public key from the header of the old file (which must be exactly the same as the public key in the header of the new file anyway) and if it's valid, then whoever broadcast the new file must control the address that uploaded the old file so the node can be sure this is a genuine revision by the owner and can replace the file it's storing. If the owner of a file wishes to delete it from the swarm, they could broadcast a header with no file appended, with the same address and file id and a greater version number than the file to be deleted. Nodes would not keep empty headers with no file content so would just delete the file. As files would associated with addresses which would also hold SWC, the values held by these addresses would deplete at a rate of 1SWC per hour for every gibibyte of storage used (assuming 1SWC = 1GiBh). These depleted coins could either be divied up proportionally amongst the nodes that actually contributed towards the hosting as an extra reward (on top of the reward they get simply for making that capacity available) or else could simply be destroyed (or could reward miners for processing transactions).
The mechanics of the P2P network, deciding which nodes should host which files and how those files are sent to those nodes is little beyond me at this present moment (as I say, the idea has just come to me). But that is not really the discussion I want to have right now. What I'd rather focus on is the viability of a crypto-currency system to allow decentralised purchasing of swarm storage as well as providing rewards to those lending storage capacity. How could and how should it be implemented? One thing is obvious: the value of the SWC needs to be such that users feel sufficiently rewarded for sacrificing their hard-disk space (this may also include large data-centres capable of starting their own centralised cloud if they wished), whilst also giving good, competitive value for money - if it's alot cheaper to buy storage from a cloud, then there will be no demand for the swarm (and thus no demand for swarmcoin, and thus no real reward for those sacrificing hard-disk space, and therefore the whole thing collapses). This problem is COMPLETELY different from the one that Bitcoin (and many altcoins) aim to solve; bitcoin creation is done in such a way that supply increases at a predictable rate for a limited period, then stops so that there is never any inflation. The challenge here is completely different, therefore the normal "coins created by mining" formula can't just apply. As I have said repeatedly, this is a brand new idea I haven't had time to properly consider in depth, so I haven't yet come up with any elegant solution to currency value problem, but I would be very interested to see some discussion.
So in order for this to be viable, we need some suggestions on how coins are created, how transactions are processed (should the tried and tested miners + tx fee model be rolled out here, or is there a way we could force everyone donating capacity (and thus receiving rewards) to also process some transactions?) Should there be a bunch of coins pre-created and held in reserve by a "federal bank" that will release and buy-back coins to keep the value stable to begin with (protecting against speculative investors, market shocks etc.) that could eventually commit suicide, after which point the coin would obey strictly mathematical laws? Perhaps the coin's value shouldn't be strictly pegged to a unit of storage, and node operators can set their own minimum prices for storage?
Also it would be great to hear if anyone has any ideas about how one could mathematically implement a mechanism that causes coins to decay as storage is used, or cause coins to be created/redistributed when storage is donated. This system would likely require a radically different infrastructure from Bitcoin/most altcoins.
#1 - returning to the paragraph above where I was talking about contributors being given their "free storage" reward in the form of SWC that they could sell: the problem this would cause is that it makes peoples unused storage capacity transferable; meaning that people can sell their unused storage capacity rather than just leaving it unused, reducing the extra liquidity of the system to zero (or less) unless there is some incentive to hold coins rather than redeeming them. However, the fact that storage is sold in gibibytehours (or similar) means that coins will not all be "redeemed" simultaneously - someone who buys enough to store 1GiB for 1 month will redeem his coins 1 per hour for a month, meaning he will be "holding onto" some of the coins for up to 1 month minus 1 hour. There could be a security vulnerability if an attacker uploaded files simultaneously with multiple addresses, "redeeming" too many SWC at once - though the network would need to have some sort of provisions in place for dealing with excessive demand.
#2 - there might also be a (theoretical) issue with the fact that SWC (albeit their exact method of creation is not yet defined), at least those "produced" as rewards, reflect
past network capacity rather than current capacity, so if the network were to shrink there might be issues.
These last two points particularly have been fairly rushed; I'll try and think more about them and solutions and perhaps come up with small-network examples. Sorry for the very raw (and vague) nature of the idea, but I thought it might generate some interesting/useful discussion. IF (and that's a big if) there is anyway something even remotely like this could be viable, the next step might be to consider swarm-processing, decentralised file publishing/web hosting - but let's not run before we can walk (if in deed we can walk at all).
Sorry about the length of this (and the vagueness in parts), I am rather tired
