Distributed Dropbox

hughht5hughht5 Member Posts: 9
edited February 2014 in Projects
I have been working on a bitcoin project for a distributed dropbox and I think it could fit in well with ethereum. The project is similar to the StoreJ idea, except none of the self replication and auto deployment is written yet.


Current features:
Option 1
- Users can upload a file and pay /MB /minute to store it. File is deleted after time expires.
- When someone downloads the file it uses 10 minutes of the storage time to reflect bandwidth costs.
Option 2
- Users can upload a file and specify a cost for people to download that file.
- When another user downloads the file they pay the fee to the uploader, and also an extra few % to keep the file online for longer. This means popular files pay for their own storage needs.
- Optionally for of the fee goes straight to the developer as a dividend.

- Once a file expires the btc fees are collected and put in a profits account (in bitcoind).

Missing features:
- Security is poor
- UI is practically non existent
- Needs ability to auto-deploy / self replicate.

Could it be written as a contract in ethereum with centralised or distributed storage?


  • VitalikButerinVitalikButerin Administrator Posts: 84 admin
    Yes, you can.

    From the white paper:

    8) Decentralized Dropbox. One setup is to encrypt a file, build a Merkle tree out of it, put the Merkle root into a contract alongside a certain quantity of ether, and distribute the file across some secondary network. Every day, the contract would randomly select a branch of the Merkle tree depending on the block hash, and give X ether to the first node to provide that branch to the contract, thereby encouraging nodes to store the data for the long term in an attempt to earn the prize. If one wants to download any portion of the file, one can use a micropayment channel-style contract to download the file from a few nodes a block at a time.
  • bdhuserbdhuser Member Posts: 7

    How do micropayments allow an incentive compatible file download?
    I took a look at them, and it wasn't immediately clear to me.

    Some incentive to offer the download would be needed, and therefore some price mechanism to select who does the transfer.

    Moreover, one needs some way of aligning incentives in exchanging the file content for the compensation, that seems difficult. The seeder must be prevented from sending garbage data, and the payer can only verify this after data transfer has been made it seems. Likewise, seeder doesn't want to send any data without assurance of getting funds.

    Am I missing something obvious where there is an easy solution to all of this?

  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Here i suggest a system basic idea: viewers of data send 'request' and 'accept' messages. Viewers have a contract, it has a minimum balance. Servers can send(part of) 'accept' to receive payment from those, or use part of the 'request' message to punish viewers that fail to provide the 'accept' bit, this punishment destroys coins on both sides.

    It is 'tested' with cll-sim, but big caveits, and not 'serious' at this point. Not sure if my understanding is well rounded enough. If servers might be DDOS-ed or something.
  • bdhuserbdhuser Member Posts: 7
    edited March 2014
    I am afraid I cant entirely follow the logic of the scheme you are describing, and I cannot read contracts at present.

    It seems however you are depending on blacklists some how, which suggests to me that the scheme is not perfect?

    If you can, perhaps you can explain specifically how the scheme overcomes the following problems.

    1. Guaranteeing that servers get paid if they send correct content.
    1. Guaranteeing that servers don't get paid if they don't send correct content.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Firstly there is a 'chance at payment' scheme to avoid transaction fees. So 'payment' is just probabilty of payment so you get paid on average. Servers would basically get the average, over many serves. (its not important to this discussion)

    1. They're not guaranteed.. They can punish by destroying coins; both their own and in the contract. It isnt in your interest to try it. The blacklist is just another approach. It is costly to viewers if they cannot use their contracts anymore as a set part of the contract wouldnt be extractable.
    2. If they're not serving the correct content, they wont get the accept message. They could go destroy viewer coins, but it also costs themselves. If the viewer can go other places, they may.

    I suppose it isnt 'rich guy' attack proof. Someone might try simply incurring the loss of ether, attacking particular viewers or particular servers. Hrmm.. pretty fucking obvious...

    See if i can think of a better way..
  • bdhuserbdhuser Member Posts: 7
    I get the first part, about payment to store over time, thats fine.

    How does a particular server gain the right to destroy coins? Why cant anyone just destroy the coins?
  • bdhuserbdhuser Member Posts: 7
    So after reading your idea a few times, Im still not sure, however, I was delighted to see that it seemed similar to an idea I came up with earlier today before posting.

    In my scenario, a viewer would post a request which included a large bond, potentially much larger than the reward to the server. Servers would see this request in the blockchain, and send a reply with their own bond of the same quantity. Now, the two bond amounts would only be released back to the two parties in the event that BOTH sign this transaction at some point. This way, a server has inncentive to send correct content, to get bond back, and reciever has inncentive to approve correct content, to get its bond back.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    The idea is that payment and punishment work the same way. 'Request' and 'accept' commands sent by viewers contain a signed message that the server can send to the contract.

    Contracts check the signature on the message, and could in principle respond arbitrarily. In this case the 'accept' message sends ether to the server, and the 'request' message sends 2*tx.value to a burn address. (so half of the servers coin is burned too) The blacklisting idea is just complementary.

    The one i coded up doesnt actually do the digital signature thing, btw. It pretends that you can just send a 'transaction as if from the viewer' which the server can put on the blockchain instead. I dont think that is true. The actual scheme also has to be resistant to replay attacks. (Btw, those messages might not end up on the blockchain due to the only-average-payout approach)

    The bond approach is very similar, i reckon. Essentially if both refuse to release the bond, the coin is destroyed on both sides there aswel.

    Btw, wonder if bitcoin could do the scheme i came up with.
Sign In or Register to comment.