Topic: Idea: Bitcoin payed P2P storage cloud. (Read 3032 times)
If you have the patience to program something like that GO!
Indeed, there are a lot of projects around dealing with this topic. They look very promising! Especially Freenet looks like what I had in my head, and this project is already over 12 years old!
I like the idea of the liquid market, but even beside Bitcoin, in my head it is not clear how 'accounting' of blocks can be done if it's truly P2P.
I mean if you just have 3 PCs synching each other while you made sure that always at least one is online. No money is needed for this scenario. The reference-counter of a block would be 3, but there is no central authority to count it. Other scenario: a public file (doesn't even need encryption) with high demand doesn't need to be duplicated in the network to the same amount. 4-5 duplicates would be enough to ensure reliability against data loss. So there seems to be a "user-counter" and a "storage-reference-counter". Don't know how the projects solve this though.
Money for storage sounds reasonable, but in detail? Should the download of data be payed? Then the holder of the data plays the 'game' of holding the data in the hope the owner will request it or throw away the blocks to make space for something else. The owner has to hope somebody still has the blocks. If it's important data and only one 'holder' has it....the price could be high!
I would prefer that providing storage would be payed, which is probably a function of size and time. Or even including transfer, so bandwith could be in the formula, too. But sounds already complicated.
I like the idea of the liquid market, but even beside Bitcoin, in my head it is not clear how 'accounting' of blocks can be done if it's truly P2P.
I mean if you just have 3 PCs synching each other while you made sure that always at least one is online. No money is needed for this scenario. The reference-counter of a block would be 3, but there is no central authority to count it. Other scenario: a public file (doesn't even need encryption) with high demand doesn't need to be duplicated in the network to the same amount. 4-5 duplicates would be enough to ensure reliability against data loss. So there seems to be a "user-counter" and a "storage-reference-counter". Don't know how the projects solve this though.
Money for storage sounds reasonable, but in detail? Should the download of data be payed? Then the holder of the data plays the 'game' of holding the data in the hope the owner will request it or throw away the blocks to make space for something else. The owner has to hope somebody still has the blocks. If it's important data and only one 'holder' has it....the price could be high!
I would prefer that providing storage would be payed, which is probably a function of size and time. Or even including transfer, so bandwith could be in the formula, too. But sounds already complicated.
This is how freenet works... just without the payment for storage, and you don't know who physicaly hosts your data.
I can just picture it now: every hard drive ever thrown out will make its way to wherever has the cheapest electricty and be connected to this p2p pay-for-storage cloud. Talk about wasting nothing 
somebody described something similar (but still slightly different) to your idea to me about 2-3 weeks ago.
Its definitely something I'd use!
Its definitely something I'd use!
There are bounties for people who can make the Tahoe-LAFS decentralized storage system accept payment in Bitcoin:
http://forum.bitcoin.org/?topic=2236.0
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Ostrom
http://forum.bitcoin.org/?topic=2236.0
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Ostrom
This is a commonly encountered idea... Go for it!
For more adventurous people, read gmaxwell's post about autonomous agents like StorJ providing P2P storage and also https://en.bitcoin.it/wiki/Agents
I have thought a lot about this, but don't want to deal with possible legal hassles of being the one who creates it. You should build it, or someone else. Whatever. I'd use it.
The way you integrate Bitcoin is by paying people for successfully delivering the file you previously stored. Then, you effectively create a market for data storage and retrieval latency.
If I want to back up my family photos so I don't lose them if my harddrive fails, I could pay 0.05 BTC, once a month, for someone in the cloud to deliver a complete set of blobs. By offering this prize once a month, you give them an incentive to hold onto the info.
If you want a rapid-accessible data-store, you could pay much higher rates to whoever can get the data to you first. If you offer > 1BTC per MB, you will get a lot of people storing the file, so they can hopefully be the first one to respond when a request for the data is sent out.
There are some other possible optimization to reduce trust and bandwidth requirements, like letting people send you a hash of the file with a custom salt every day (to prove they actually have it), or sending bitcoins directly to a private key generated from the hash of the file.
By creating a liquid data market, you would get people aggressively hosting and promoting copyright content (because pirates would prefer getting reimbursed), which would bring serious heat from the media industry. If you build the system well, the financial incentives for the pirates will make their innovation outpace the lethargic copyright lobby's efforts.
If you (or anyone else) wants to build something like this, PM me. I am happy to share more ideas about the subject.
The way you integrate Bitcoin is by paying people for successfully delivering the file you previously stored. Then, you effectively create a market for data storage and retrieval latency.
If I want to back up my family photos so I don't lose them if my harddrive fails, I could pay 0.05 BTC, once a month, for someone in the cloud to deliver a complete set of blobs. By offering this prize once a month, you give them an incentive to hold onto the info.
If you want a rapid-accessible data-store, you could pay much higher rates to whoever can get the data to you first. If you offer > 1BTC per MB, you will get a lot of people storing the file, so they can hopefully be the first one to respond when a request for the data is sent out.
There are some other possible optimization to reduce trust and bandwidth requirements, like letting people send you a hash of the file with a custom salt every day (to prove they actually have it), or sending bitcoins directly to a private key generated from the hash of the file.
By creating a liquid data market, you would get people aggressively hosting and promoting copyright content (because pirates would prefer getting reimbursed), which would bring serious heat from the media industry. If you build the system well, the financial incentives for the pirates will make their innovation outpace the lethargic copyright lobby's efforts.
If you (or anyone else) wants to build something like this, PM me. I am happy to share more ideas about the subject.
Just an idea, tell me if it's old or nonsense 
There are lots of cloud storages around, Dropbox, Google Drive etc. Also Bitcoin-payed like CrownCloud or Wuala. But Wuala is different, it is encrypting the data at client side (SpiderOak too, don't want to advertise). Still with their user-side encryption, they can de-duplicate the data. I found that really cool, let's imagine:
Imagine a "real" cloud storage, I mean a P2P network like eDonkey or BitTorrent. Your data is somewhere in the community, but it's safely encrypted! And a guy having loads of space, why should he share his drive with the network? Because he could get Bitcoins for it! On the contrary, someone wanting to store even more in the cloud than on the device could pay for it.
Technically I would split files into 4k chunks if it doesn't influence cryptography too badly, but deduplication would be better (lets say you changed few bytes in a 1gb file). The hash of it (MD5 or SHA1) gives the password for a symmetric encryption. The checksum of the encrypted blob again is used as an id to ask the network for data. Same data gets encrypted same way, thus deduplication possible. A "file" is basically the list of blob-ids and their passwords, symmetrically encrypted with your private global password.
I don't know yet how Bitcoin comes now into place. A payment to somebody to download some of the blobs sounds like spamming the blockchain with way too many transactions. Maybe a kind of pool would help?
Well but maybe there is just no market for a Open Source P2P storage, as the commercial ones are too many and too cheap..
There are lots of cloud storages around, Dropbox, Google Drive etc. Also Bitcoin-payed like CrownCloud or Wuala. But Wuala is different, it is encrypting the data at client side (SpiderOak too, don't want to advertise). Still with their user-side encryption, they can de-duplicate the data. I found that really cool, let's imagine:
Imagine a "real" cloud storage, I mean a P2P network like eDonkey or BitTorrent. Your data is somewhere in the community, but it's safely encrypted! And a guy having loads of space, why should he share his drive with the network? Because he could get Bitcoins for it! On the contrary, someone wanting to store even more in the cloud than on the device could pay for it.
Technically I would split files into 4k chunks if it doesn't influence cryptography too badly, but deduplication would be better (lets say you changed few bytes in a 1gb file). The hash of it (MD5 or SHA1) gives the password for a symmetric encryption. The checksum of the encrypted blob again is used as an id to ask the network for data. Same data gets encrypted same way, thus deduplication possible. A "file" is basically the list of blob-ids and their passwords, symmetrically encrypted with your private global password.
I don't know yet how Bitcoin comes now into place. A payment to somebody to download some of the blobs sounds like spamming the blockchain with way too many transactions. Maybe a kind of pool would help?
Well but maybe there is just no market for a Open Source P2P storage, as the commercial ones are too many and too cheap..
Jump to: