Categories
- 17.3K All Categories
- 9.5K Mining
- 574 Pool Discussion
- 378 Promotional
- 1.4K General Project Discussion (non-technical)
- 485 Education
- 811 Protocol and Client discussion
- 170 web3-js
- 29 Whisper
- 16 Swarm
- 3 RLP
- 303 IoT & Hardware
- 1.2K Smart Contracts and Dapps
- 28 Serpent
- 359 Solidity
- 664 Projects
- 1.2K Reference clients code and builds
- 249 Eth & AlethZero- Cpp Implementation
- 471 Geth - Go Implementation
- 242 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 49 Mix
- 36 Other Implementations
- 170 Meetups
- 40 Other Events
- 226 Jobs & Skills
- 281 Press and Articles
- 75 Audio/Video
- 296 Ether Sale
- 1.2K Other Languages
- 96 Chinese
- 255 German
- 33 Italian
- 111 French
- 3 Hebrew
- 42 Japanese
- 75 Portugese
- 46 Romanian
- 185 Russian
- 231 Spanish
- 47 Turkish
- 125 Watercooler
Is there any ideas for a file storage contract?
proster
CETMember Posts: 2 ✭
Hi,
I'm thinking of a scheme where B gets paid to store a file* F for A until at least a time T.
For this to work, I'm thinking that it is needed for incentives for B to..
1) actually store the file until time T.
2) transfer the file to A on request.
I have a sketch for this, but my question is whether it is possible to remove the trusted third person from the scheme?
For 1), I'm thinking that a secret random nonce N is generated by a third party, C, and V=HASH(N+F) is calculated by C**. At time T, C reveals N to the world, and B can prove that he kept the deal to C by calculating V.
I haven't though through 2) yet, but I'm thinking it can be possible for A to initiate some kind of escrowed buy of F from B.
I hope this forum is the right place do discuss this or similar schemes.
Best regards,
proster
*) Or rather, a forward erasure coded encrypted N-of-M chunk of a file.
**) This is an unfortunate significant overhead, as F must now be transferred from A to C.
I'm thinking of a scheme where B gets paid to store a file* F for A until at least a time T.
For this to work, I'm thinking that it is needed for incentives for B to..
1) actually store the file until time T.
2) transfer the file to A on request.
I have a sketch for this, but my question is whether it is possible to remove the trusted third person from the scheme?
For 1), I'm thinking that a secret random nonce N is generated by a third party, C, and V=HASH(N+F) is calculated by C**. At time T, C reveals N to the world, and B can prove that he kept the deal to C by calculating V.
I haven't though through 2) yet, but I'm thinking it can be possible for A to initiate some kind of escrowed buy of F from B.
I hope this forum is the right place do discuss this or similar schemes.
Best regards,
proster
*) Or rather, a forward erasure coded encrypted N-of-M chunk of a file.
**) This is an unfortunate significant overhead, as F must now be transferred from A to C.
Best Answer
-
nejucomo
Member Posts: 40 ✭
Here's a thought on incentives:
Sally the storage provider will *store* a gigabyte for a smallish fee, and will *retrieve* a stored gigabyte for a sizable fee. Perhaps the retrieval fee raises over time on some curve to anticipate future costs/profit.
Sally's incentivized not to cheat, because the retrieval fee is where the profit is. The storage fee is more of a spam prevention.
This (simplistic) incentive structure assumes Sally is being used as a backup service, and since the main payment only happens on retrieval rather than periodically, the revenue model is a bit more like (inverted) insurance rather than a cloud service provider.
Maybe this incentive structure leads to simpler systems, without a need for tricky proofs-of-storage protocols, although I don't see why paying Sally a small fee to prove correct storage periodically wouldn't hurt, and it would probably help backup customers sleep better.
FYI, I'm an occasional contributor and fan of the Tahoe-LAFS storage system. There have been discussions about both proof-of-storage and integrating payment systems into Tahoe-LAFS over the years, which you might find on mailing list archives.
Answers
There is also maidsafe and other distributed hash table approaches. I am not sure what state this in, but i think it is an important part of web 3.0 as Gavin Wood forsees. I think such a future probably indeed does require that serving and holding data for other pays, preferably in a way that doesnt require a lot of co-ordination between providers and consumers, the better providers win out automatically. It would also be important that providers dont get too big positions of powers.
Even if we understood it, it isnt guaranteed their solution is the solution we should choose.
Tend to think that the dropbox example essentially does proof-of storage, but you have to figure out payment for servers on retrieval. And it has to work against both Sigil attacks of servers failing to deliver, and requesters attempting to not pay, or falsely claiming they did not receive data.
Dont know how things work, well, MAIDSafe claims they have it..