[---]
Have you considered to integrate this into a Torrent client? Including someking of Proof of Bandwith?
Include what into a Torrent client...? I don't understand.
I mean if somehow we could do a proof of sharing, based either on bandwidth or disk space ...
Compared to maid and storj (which are just pumped IPOs at this moment, non-mineable and with no utility), BURST makes no promises this will be at all possible.
Proof of Being Reliable Storage And Not Just Someone Faking It is very, very difficult to do in reliable fashion. So far, all proposals to do this in decentralized fashion are technobabble than anything sound.
The Storj Whitepaper was released officially today at
www.storj.io/storj.pdfThey also have the access plans posted at
www.storj.io/earlyaccessfor some users the bandwith used is much more of a concern than storing large amounts of data. Because of this, I suspect any system like storj will have users who are willing to honestly store and provide verifications for the data they are storing, but will be unwilling to transfer this data when requested, as the bandwith used is more valuable to them than than transfer fee.
I think this can be mitigated if a file is seen as just a collection of sectors, and these sectors are distributed evenly around the network (of course multiple times). that way, if someone requests 1GB of data from the system, each individual storing data will only have to provide a few sectors of that large request, because hundreds or thousands of storers are servicing the request. The individuals storing data would store bits and peices of many different things, and would just have an ongoing stream of requests they had to service. In fact, the payment could easily be for serving requests instead of for storing in the first place. Then it pays more to serve the most requested stuff, or it gets more expensive to store stuff noone wants to request. thus, the most requested stuff gets more agressively duplicated, and the network can respond quicker.
[/quote]
The other problem would be efficiently handling the transfer payments. As retrieving a file may require retrieving many shards which may need to be transferred from multiple users each, handling payment by traditional means could result in a massive amount of transactions.
[/quote]
That is correct. if every sector hit incurs a fee that must be handled via a (blockchain) transaction, then we would have a lot of transactions of very small fees. suppose that a transaction somehow generates a unobfuscable hash, then that hash (if low enough) could be proof of winning something similar to a block. So you don't earn on every sector served, but each time you have the chance of winning a reward. Theoretically the one serving that sector might - if he won - just get his hand on all transaction fees since last block, or all filesystem related transaction fees. This way, we don't have to keep track on serves, only on requests (which is bad enough, as every request for a file would lead to an entry in a block as i see it). However if filesystem reads are paid in burst, that would certainly put a floor on the burst price. In fact, it would probably make us all quite rich, as demand for burst would likely go through the roof, as storage became == burst. If we can get as far as making the storage truly decentralized and truly anonymous an encrypted end to end on all levels, then the burst storage price could easily rise well above harddisk price.
