Question about decentralized dropbox

So lets say we create a decentralized dropbox.

4 people are apart of this network.

1 person pays 10 ether to upload an mp3 file to the network.

The other 3 people are paid 1 ether a day to host encrypted pieces of the file.

What happens after 4 days? Does the file stop getting hosted since there is no ether left to incentive people to help store the file?


  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    I think it kind-of depends on how you implement the thing. the decentralized dropbox example by paying out once a block to anyway who can prove that he has a random part of the file. Note that it is just a proof of concept.

    Following that model, the incentivizing stops once it runs out. I think that is generally too. You could keep 'i-owe-you's, but that is just a promise. Of course, anyone can fund the dropbox, and people might have their own reasons to hold it. After all, they do for bittorrent and freenet. (that is the answer, now for some rambling)

    One thing about it is that it pays only once i.e. it is a race to the blockchain, and the miner can probably choose who wins. It is just a proof of concept, of course, but i am sure there is a better solution to that. Could try use the scores of msg.sender or tx.origin, but that just leads to pubkey mining.(Sybil attack) Could try using balances, but with msg.sender i think you might still be able to Sybil attack using chains of contracts passing ether along different contracts, which then have the high balance using the same ether over and over again. Not with tx.origin, but still, it doesnt make sense to what we're trying to do, you either hold the file or dont, it doesnt matter if you're rich or not..

    Registering doesnt seem to solve it either, as someone can just as easily register twice..

    Another problem is that the example doesnt implement anything to actually get at the data. And if it did, and it was within a minute,(the block time) people that obtained the data that way could play for payment too.

    So from what i know, it isnt worked out that far yet. For that is accessed a lot, approaching it from paying for serving the data might be better.
  • aatkinaatkin Member Posts: 75 ✭✭
    edited May 2014
    We've talked quite a bit about using MaidSafe, TAHOE-LAFS etc, for storing large encrypted files. As an old timer, I had an idea yesterday. Why not encrypt and store the files on Usenet in an newsgroup with nzbd indexing? In some cases the retention would be 7000 days (some providers), the cost to upload/download could be cheap/free and borne by the uploader/downloader in terms of the relationship between the user the the Usenet provider.

    I realized this is centralized/federated, but there are a *LOT* of Usenet servers out there, and you can start your own using open source. Just a thought. In the very old days people did back things up to Usenet, share photos and discuss. Now it's mostly for leeching movies etc.

    I guess store the nzbd file in the blockchain, or instead maybe a gzip of it to save space. Or maybe we could store .torrent files in the chain?

    So we'd have a registry contract which contains filesharing members' ETH address and GnuPG public key. The filesharing contract would hold an array of [address, gzip nzbd] or [address, GnuPG encyrpted nzbd]. The actual files would be available on Usenet in GnuPG encrypted to the GnuPG key of the addressee.

    Some of the glue to make this work is already open source and written. What do you think? Are there serious problems with this approach?
Sign In or Register to comment.