That's why I called it simple - service.com would only issue challenges + try to connect via BitTorrent to the seeds. If there is a checksum error or not even a torrent client running, no money for them! The hassle for downloading the torrent files + keeping them is hopefully enough though to let them really seed as well.
Ideally, other clients/downloaders would report from whom they loaded how much. This data unfortunately cannot be trusted though and I still can't really think of anything how to make it trustworthy.
Edit:
Maaaaaybe you can trust "I have loaded x MB from ..." data if the person claiming this can also solve checksum riddles. It would still be trivial for seeders though to solve these riddles and claim high upload rates from some random clients.
Topic: [IDEA] Dirt cheap online storage - page 3. (Read 14494 times)
Even using a verification client wouldn't stop the upload speed problem though. Also, how would the verification client know that the file was being seeded? Or is that why you are calling it a simpler version?
Why couldn't the uploader be responsible for knowing what parts of the file needs to be checksummed? Perhaps some piece of software could be downloaded that automatically creates a checksum index with random parts of the file. That index could be uploaded to service.com, then service.com periodically requests each seeder to provide a checksum of one of those particular indexes.
Because that file could be sent to someone collaborating with the uploader (Seeder X) who doesn't really download the data but now has every possible answer to the challenges. He would only get the money for the files from the uploader, but maybe also some rating as "that awesome seed that has 0 CRC errors + stores multiple TB for theat uploader" that would probably be part of the platform too.I wouldn't throttle transfers from symform to symform people checking on my upload capacity, only to anyone else - so if they check me out, I'm that 1 MB/s upstream candidate they always want to see. If anyone else actually wants their data though, good luck with that!
Symform can't trust complain reports of these clients that I'm slow, otherwise I could write a client that complains about anyone else and rate these down.
About markets - this could very well be automated. Just set a price you're comfortable storing data at or a price you'd like to charge at least and let the service handle the rest. The hard part is really enforcing these contracts and making sure they are followed, from both sides.
A simpler version that can be done without handing too much risk to service.com but that should still be fairly secure would be to hand the random checksumming still to the uploader (which in return however could provide that data to be used to fake seeds). Uploaders then send a torrent file (or better: magnet link) + a file with the random checksums to service.com, send some BTC + give a timespan of how long this file shall be seeded.
These things (magnet link + BTC pledged) then get published + a verification client, that has to run and that handles the checksumming part (can/should be open source) can be loaded. In the verification client, seeders enter their payout address + a treshhold (say 1 BTC) and similar to mining pools, as soon as their balance reaches the treshhold, they get their money. Also if they don't seed anything for 14 days, and their balance is above "bitdust" levels (say 0.005 BTC?) they get their remaining balance. Service.com only has magnet links and random checksum data and doesn't require any data from it's users other than payout addresses + IPs (for connection checks).
This could be used for any kind of P2P network actually, BitTorrent, eMule (ed2k), several of the anonymous networks like WASTE...
Prices would set themselves because it would be something like: "I offer 1 BTC over 1 month to all the people seeding this torrent". Every hour there's a test for anyone claiming to seed that file by service.com: A random checksum challenge + trying to check out if a bittorrent client is running and seeding the file in question (yes, one can lie about that, but at least it takes some effort). If these 2 criteria are fulfilled, 1/720 BTC (there's 720 hours in a month) gets split between all seeds. If they reach a point where they don't earn enough, they'll just drop out. There can be live public stats and maybe even bonuses/penalties for people (not) failing checksum tests.
I suspect that compliance discovery is far more of a challenge than price discovery.
I will probably have to take symform up on their offer if as their online chat support said they will have Linux compatibility in a few months, even though they are not open source.
The idea of throttling the connection to them seems not too bad an attack since if one does not actually provide fast speed then one can simply be paid in slow speed access to one's own data. By paying the storage nodes "in kind", service.com can measure what "kind" they actually are and reciprocate with the same "kind".
Maybe bitcoins could be awarded for "performance above and beyond the norm" or somesuch though folk not planning to strive to be among the very best maybe wouldn't bother trying in such a setup.
It was mentioned in the Tahoe-LAFS thread that only the three fastest nodes would be asked for blocks of a file set at 3-copies redundancy. Just as mining got more and more concentrated into the hands of those building the most powerful rig-farms maybe pretty much everyone whose offered space isn't directly on major internet backbones simply would end up never being asked for a copy thus being largely irrelevant backwaters.
-MarkM-
I will probably have to take symform up on their offer if as their online chat support said they will have Linux compatibility in a few months, even though they are not open source.
The idea of throttling the connection to them seems not too bad an attack since if one does not actually provide fast speed then one can simply be paid in slow speed access to one's own data. By paying the storage nodes "in kind", service.com can measure what "kind" they actually are and reciprocate with the same "kind".
Maybe bitcoins could be awarded for "performance above and beyond the norm" or somesuch though folk not planning to strive to be among the very best maybe wouldn't bother trying in such a setup.
It was mentioned in the Tahoe-LAFS thread that only the three fastest nodes would be asked for blocks of a file set at 3-copies redundancy. Just as mining got more and more concentrated into the hands of those building the most powerful rig-farms maybe pretty much everyone whose offered space isn't directly on major internet backbones simply would end up never being asked for a copy thus being largely irrelevant backwaters.
-MarkM-
We have been trying it, and see what has happened so far: no concrete offers of bitcoins or fiat to any of those who have space available so far, resulting in continuing water-cooler and/or back-room-engineer chatter about various proposed engineering or marketing tweaks that might or might not result in more or better offers of actual money sooner/faster.
In other words: we already have at least one terrabyte on offer, we already have lowered its price to $1/month per 100 gigabytes, and we still have no concrete offers from anyone to buy a month at that price even stipulating it is on a terrabyte disk dedicatable to the purpose that can become dedicated to the purpose if/when in fact anyone actually decides that purpose suits his or her purpose and presents coin to follow through on it.
All you've proved is that a market for the manual negotiation of storage contracts does not exist. I don't believe that was the original intent of the OP.In other words: we already have at least one terrabyte on offer, we already have lowered its price to $1/month per 100 gigabytes, and we still have no concrete offers from anyone to buy a month at that price even stipulating it is on a terrabyte disk dedicatable to the purpose that can become dedicated to the purpose if/when in fact anyone actually decides that purpose suits his or her purpose and presents coin to follow through on it.
The set of people who are willing to sell excess hard drive space when the required effort is just install the software and keep their computer online is larger than the set of people willing to haggle for it on an online forum. The same applies to people on the buy side. If you'd been actually reading my posts you would have noticed that is a large part of my thesis of why Mojo Nation failed. The market mechanism needs to be automated or else there will either be a lack of price discovery or price discovery will be so difficult that nobody will bother to use the software.
Here's another other question: Is slow downloading a huge issue for people making backups? If I back up 50 GB's, then my hard drive crashes the next day and I lose everything, is it that big of a deal if it takes me until the next day to recover all my goods? For a business, certainly, backups would be crucial to retrieve ASAP. But I don't think this is a solution that businesses would (or should) be interested in anyway. Just something to think about... I really don't have any solutions to seeders capping the download rate besides users reporting it though.
Why couldn't the uploader be responsible for knowing what parts of the file needs to be checksummed? Perhaps some piece of software could be downloaded that automatically creates a checksum index with random parts of the file. That index could be uploaded to service.com, then service.com periodically requests each seeder to provide a checksum of one of those particular indexes.
Why couldn't the uploader be responsible for knowing what parts of the file needs to be checksummed? Perhaps some piece of software could be downloaded that automatically creates a checksum index with random parts of the file. That index could be uploaded to service.com, then service.com periodically requests each seeder to provide a checksum of one of those particular indexes.
For popular "files snatch and leave" is more of a problem, slow seeds are more of a problem with files that have only few seeds to begin with. If you upload pictures of that sister to a handful of people and they all decide they would rather seed other files faster, there's no chance for you to get these back quick enough.
Symform and others deal with this by dispersing files wide enough that this doesn't matter (you can afford to load a few tiny parts slowly while you're busy downloading from seeds that are not jerks).
Yes, something to ensure seeds just have the file might already be enough, as the bandwidth might be anyways cheap compared to the cost for storage and too popular files can be dropped as you said. If it isn't though, we have a problem. It might be enough though, especially for initial seeding of a potentially popular torrent. These tend to violate copyright laws sometimes though...
This is actually really a problem for service.com, as it MUST be the only one knowing in advance which parts of the file shall be checksummed and what the sums are. This means service.com has to have every file on it's HDDs at least once. This means, files either have to be encrypted with a key not known to service.com (similar to one click hosters) or filtered by service.com.
10 US cent per GB per month would be ~42 Satoshis per minute by the way, so cheaper rates (e.g. 2 satoshis for 1 minute of seeding 1 GB) are possible and feasible at least. 1 Bitcoin would then seed a bit more than 1 TB for 1 month. Maybe a bit too cheap, but offering a market for that might anyways quickly establish prices.
Symform and others deal with this by dispersing files wide enough that this doesn't matter (you can afford to load a few tiny parts slowly while you're busy downloading from seeds that are not jerks).
Yes, something to ensure seeds just have the file might already be enough, as the bandwidth might be anyways cheap compared to the cost for storage and too popular files can be dropped as you said. If it isn't though, we have a problem. It might be enough though, especially for initial seeding of a potentially popular torrent. These tend to violate copyright laws sometimes though...
This is actually really a problem for service.com, as it MUST be the only one knowing in advance which parts of the file shall be checksummed and what the sums are. This means service.com has to have every file on it's HDDs at least once. This means, files either have to be encrypted with a key not known to service.com (similar to one click hosters) or filtered by service.com.
10 US cent per GB per month would be ~42 Satoshis per minute by the way, so cheaper rates (e.g. 2 satoshis for 1 minute of seeding 1 GB) are possible and feasible at least. 1 Bitcoin would then seed a bit more than 1 TB for 1 month. Maybe a bit too cheap, but offering a market for that might anyways quickly establish prices.
@ Cobra - it is similar, but again, doesn't solve the case for people who have extra storage and don't want to store files, or people who don't have extra storage and want to store files. It is very similar to the idea markm was throwing around earlier about trading storage though.
@ Sukrim - do you really think masses of people downloading from the hosts would be a problem? I figured that for popular and public files, people would just use traditional torrent methods - the paid torrents would likely only be necessary for unpopular files, or files that no one would otherwise want.
But, if it would be a problem, instead of making it much more complicated, perhaps the amount of bandwidth used on a particular torrent simply goes into the decision-making process that leads a host to keep or drop a particular torrent in favor of another. If, at the end of a 24 hour period, the host finds that one particular torrent consuming 1 GB of space has consumed 5 GB of bandwidth, they might consider the bandwidth to be an unreasonable expense compared to the daily payment of the file hosted, and drop that torrent. Or, they might write up a rule that if a particular torrent exceeds twice its size in bandwidth in any 24 hour period, then drop the torrent. Or if it exceeds five times its size in bandwidth in a month, then drop it. Etc, etc.
Of course, such an analysis and response is passive, but would be a lot easier to implement than special coins and double-metric pricing.
@ Sukrim - do you really think masses of people downloading from the hosts would be a problem? I figured that for popular and public files, people would just use traditional torrent methods - the paid torrents would likely only be necessary for unpopular files, or files that no one would otherwise want.
But, if it would be a problem, instead of making it much more complicated, perhaps the amount of bandwidth used on a particular torrent simply goes into the decision-making process that leads a host to keep or drop a particular torrent in favor of another. If, at the end of a 24 hour period, the host finds that one particular torrent consuming 1 GB of space has consumed 5 GB of bandwidth, they might consider the bandwidth to be an unreasonable expense compared to the daily payment of the file hosted, and drop that torrent. Or, they might write up a rule that if a particular torrent exceeds twice its size in bandwidth in any 24 hour period, then drop the torrent. Or if it exceeds five times its size in bandwidth in a month, then drop it. Etc, etc.
Of course, such an analysis and response is passive, but would be a lot easier to implement than special coins and double-metric pricing.
Symform doesn't seem to meter bandwidth provided, so I could just offer some storage, download fragments and rate-limit the port they use in my router to 1 KB/s. In reality I gain online space for that but don't contribute anything meaningful to the network.
Their approach looks actually quite similar to tahoe or Wuala (back when they were P2P) or the japanese P2P sharing system "perfect dark".
Just like BitTorrent they depend on user's generosity and/or not too many freeriders. Once you bring money (even "internet funny money" like bitcoin) into that equation, it could be an explosive mix...
Their approach looks actually quite similar to tahoe or Wuala (back when they were P2P) or the japanese P2P sharing system "perfect dark".
Just like BitTorrent they depend on user's generosity and/or not too many freeriders. Once you bring money (even "internet funny money" like bitcoin) into that equation, it could be an explosive mix...
I'm not sure if anyone has seen this site before http://www.symform.com/join-the-revolution/how-symform-works/ The concept seems very similar to what the end result should be here but without the central controlling authority. It would be something or progress if a company like this would agree to compensate users in BTC for contributing drive space, granted they do not have the need to store files in the cloud in the capacity they are sharing.
I am excited to see where a project like this may end up, it seems like the perfect companion for use with BTC.
I am excited to see where a project like this may end up, it seems like the perfect companion for use with BTC.
Maybe a system like this should include a share ratio though - something like "1 MB hosted can generate up to 5 MB upload during the last 7 days, after that you can shape or even deny access" with higher ratios obviously costing more. This would address the "storage vs. hosting" issue, as hosted files have to be stored somewhere and stored files need to be hosted to be available on demand. The difference is that hosted files will probably have a lot more traffic but might be smaller than the other way round.
To circumvent the traffic meter issue, it might be possible to split payments in 2 parts:
1 part for storage (checked via checksums from service.com) paid by service.com
1 part for traffic, measured by downloaders and paid by service.com
The downside would be that downloaders also require an account + deposit at service.com as well as some traffic metering software - the upside would be that there can be no (useful) faking of traffic, as the downloader simply says "I loaded 12 MB from node 1, 16 MB from node 2 and 100 MB from node 3". If he wouldn't run the metering software, he wouldn't be able to get unshaped downloading speed in the first place, the only thig he could do is to lie about ratios (like he loaded 100 MB from node 1 and 12 MB from node 3 in reality) or nodes (he loaded nothing from node 3), but both of these scenarios would not benefit the downloader and he'd have to pay anyways for traffic consumed.
The implementation could be like this that a downloader says at service.com that he wants to download 100 MB of files. Service.com runs a bitcoin-style block chain (probably with faster blocks and not publicly mined) and transfers a number of 1 MB "coins" to the user and charges his account for this. As the user downloads (seeds can check that he actually has some money by requesting a message signed by the private key of the address that holds the coins), the metering software sends out DL-coins to the seeders' addresses. This way they can see after some time, that the user is really paying up and trustworthy, so he should be able to quickly build up trust within the swarm. It's even possible to gain back some money for the user, by seeding the file himself while loading and publishing a seeder address.
Once the download is complete, the user can transfer remaining DL-coins back to service.com (there should be some slight overprovisioning to account for CRC errors, rounding errors etc.) and gets some BTC back to his account there or he just accumulates them for the next time.
Seeds can do the same (redeem DL coins for a fixed price or bandwidth).
The balance of BTC stored at service.com can be requested at any time, service.com would act similar to a mining pool nowadays (collecting lots of tiny transactions of some value - mining shares - and paying out aggregated payments to reduce blockchain spam and bitdust issues).
1 DL-coin could for example be equal to 1 satoshi, this way conversion would be easy and there would be no decimal point numbers for people to worry about.
Why have different coins, not BTC?
* no block chain spam
* nano/picotransactions (1 MB of traffic is far below the treshhold for transaction fees)
* quicker confirmation times (you don't want to wait for an hour until you can see that the leecher is really paying up)
* centralized mining allows for a "1 block = 100% confirmed" style of mining but it could still be expanded more easily for more than 1 service provider compared to a pure server solution
What would be the risk for seeders?
* Some leecher shows that he owns 1000 MB worth of download, starts loading and after a few MB still doesn't pay anything. Solution: Traffic shape him until he pays up (confirmation times would be likely a few seconds or so, so not much to be wasted)
What's the risk for leechers (downloaders)?
* A seeder sends bougs data. Solution: Don't pay after getting the data
* A seeder is too careful and wants to see you pay other seeders first, before offering any data and you can't pay anyone else since they all are too cautious. Solution: Probably people will register seeders for the purpose of giving some MB away and then seeing if you pay up - the big advantage for that is that you are then likely to be a preferred seed by the leecher and can earn more through the traffic. Maybe it can be possible to detect such situations by service.com (simply act as leecher and ask seeds if they are fine with offering files in advance) and flag such files as opportunities to be grabbed. This is somehow an unsilved issue and depends on the ecosystem of seeders that arises... the monetary risk of handing out a few MB for free is however probably smaller than the potential profit on being the first seed on the list.
To circumvent the traffic meter issue, it might be possible to split payments in 2 parts:
1 part for storage (checked via checksums from service.com) paid by service.com
1 part for traffic, measured by downloaders and paid by service.com
The downside would be that downloaders also require an account + deposit at service.com as well as some traffic metering software - the upside would be that there can be no (useful) faking of traffic, as the downloader simply says "I loaded 12 MB from node 1, 16 MB from node 2 and 100 MB from node 3". If he wouldn't run the metering software, he wouldn't be able to get unshaped downloading speed in the first place, the only thig he could do is to lie about ratios (like he loaded 100 MB from node 1 and 12 MB from node 3 in reality) or nodes (he loaded nothing from node 3), but both of these scenarios would not benefit the downloader and he'd have to pay anyways for traffic consumed.
The implementation could be like this that a downloader says at service.com that he wants to download 100 MB of files. Service.com runs a bitcoin-style block chain (probably with faster blocks and not publicly mined) and transfers a number of 1 MB "coins" to the user and charges his account for this. As the user downloads (seeds can check that he actually has some money by requesting a message signed by the private key of the address that holds the coins), the metering software sends out DL-coins to the seeders' addresses. This way they can see after some time, that the user is really paying up and trustworthy, so he should be able to quickly build up trust within the swarm. It's even possible to gain back some money for the user, by seeding the file himself while loading and publishing a seeder address.
Once the download is complete, the user can transfer remaining DL-coins back to service.com (there should be some slight overprovisioning to account for CRC errors, rounding errors etc.) and gets some BTC back to his account there or he just accumulates them for the next time.
Seeds can do the same (redeem DL coins for a fixed price or bandwidth).
The balance of BTC stored at service.com can be requested at any time, service.com would act similar to a mining pool nowadays (collecting lots of tiny transactions of some value - mining shares - and paying out aggregated payments to reduce blockchain spam and bitdust issues).
1 DL-coin could for example be equal to 1 satoshi, this way conversion would be easy and there would be no decimal point numbers for people to worry about.
Why have different coins, not BTC?
* no block chain spam
* nano/picotransactions (1 MB of traffic is far below the treshhold for transaction fees)
* quicker confirmation times (you don't want to wait for an hour until you can see that the leecher is really paying up)
* centralized mining allows for a "1 block = 100% confirmed" style of mining but it could still be expanded more easily for more than 1 service provider compared to a pure server solution
What would be the risk for seeders?
* Some leecher shows that he owns 1000 MB worth of download, starts loading and after a few MB still doesn't pay anything. Solution: Traffic shape him until he pays up (confirmation times would be likely a few seconds or so, so not much to be wasted)
What's the risk for leechers (downloaders)?
* A seeder sends bougs data. Solution: Don't pay after getting the data
* A seeder is too careful and wants to see you pay other seeders first, before offering any data and you can't pay anyone else since they all are too cautious. Solution: Probably people will register seeders for the purpose of giving some MB away and then seeing if you pay up - the big advantage for that is that you are then likely to be a preferred seed by the leecher and can earn more through the traffic. Maybe it can be possible to detect such situations by service.com (simply act as leecher and ask seeds if they are fine with offering files in advance) and flag such files as opportunities to be grabbed. This is somehow an unsilved issue and depends on the ecosystem of seeders that arises... the monetary risk of handing out a few MB for free is however probably smaller than the potential profit on being the first seed on the list.
Markm, we haven't been trying anything. This is simply a discussion. The fact that there are MANY services out there providing user backups for X dollars a month proves that the market exists and is very real. The fact that many people here are willing to offer their extra space for much lower prices than the existing services proves that the potential for P2P paid backups is real.
Sukrim, good thoughts, sounds like we're thinking very similarly about the challenges and practicalities of making something like this a reality. You have more knowledge about torrenting protocol than I do though.
Markm, I have no idea what you are talking about with regards to sigs and offering storage. I'll say it once again: paid torrented backups are NOT about people offering hosting - it is about uploaders offering files along with regular payments to keep those files seeded.
Sukrim, good thoughts, sounds like we're thinking very similarly about the challenges and practicalities of making something like this a reality. You have more knowledge about torrenting protocol than I do though.
Markm, I have no idea what you are talking about with regards to sigs and offering storage. I'll say it once again: paid torrented backups are NOT about people offering hosting - it is about uploaders offering files along with regular payments to keep those files seeded.
For now I think the pick and choose offers type of market makes more sense than an automatic-matching market.
The forum's longevity made me think aha, maybe the folk running this thing might not be too awful a choice to pick if one of the offers on the market / on the table was one of theirs.
As to this SgtSpike chap, hey, lemme go see if he has a .sig, I honestly don't remember, having not even been motivated to look and see yet. Hey he lists a website! I wonder if that has been there ever since I or he arrived at this forum and I simply never noticed? Interesting. Maybe that is a sample of some storage he manages. I wonder if he hosts it from on-site or at an off-site-hosting provider...
As to whether you would get paid, why would anyone even consider paying you in the first place? Oops, I haven't noticed whether you have a sig either yet alone inspected it. Why would I? How much space are you offering at what price? Personally I am not looking to buy, I have onsite storage that, to others, is offsite so am more interested in swapping than buying.
-MarkM-
EDIT: I am moving more and more toward regarding "storage" and "hosting" as very different services. "Hosting providers" are basically selling publication, not storage. Maybe it is kind of like the difference between a warehouse that stores your books and a bookshop that displays/sells them to the public...
The forum's longevity made me think aha, maybe the folk running this thing might not be too awful a choice to pick if one of the offers on the market / on the table was one of theirs.
As to this SgtSpike chap, hey, lemme go see if he has a .sig, I honestly don't remember, having not even been motivated to look and see yet. Hey he lists a website! I wonder if that has been there ever since I or he arrived at this forum and I simply never noticed? Interesting. Maybe that is a sample of some storage he manages. I wonder if he hosts it from on-site or at an off-site-hosting provider...
As to whether you would get paid, why would anyone even consider paying you in the first place? Oops, I haven't noticed whether you have a sig either yet alone inspected it. Why would I? How much space are you offering at what price? Personally I am not looking to buy, I have onsite storage that, to others, is offsite so am more interested in swapping than buying.
-MarkM-
EDIT: I am moving more and more toward regarding "storage" and "hosting" as very different services. "Hosting providers" are basically selling publication, not storage. Maybe it is kind of like the difference between a warehouse that stores your books and a bookshop that displays/sells them to the public...
Torrents break the files into regular and specific piece sizes, and hash each piece with SHA-1. The list of hashes is included in the .torrent file. This is my understanding based on the wikipedia article on bittorrent.
True, these hashes can't be used for testing though, as they are public knowledge already.To request seeds for a torrent file, you send the SHA1 hash of the whole list of SHA1 hashes (and some other data - looks kinda similar to the bitcoin block header) called "info hash" to a server called "tracker" and state that you either have these files available or that you want to have a list of IPs who have these files.
All trackers know is that infohash "abc123" is seeded by IP 1.2.3.4:1337. They know nothing about file names, how big the files are, if 1.2.3.4 even HAS the file or is a jerk pretending to and they have no means to verify any of this. They are just plain stupid databases on the internet. This gets more and more replaced by DHTs nowadays, which are in the end just a distributed database, meaning some nodes feel responsible for the infohash "123456" and others for "654321" and you get your data from these nodes instead of a central server.
As it would be near impossible to include monetary transactions into the bittorrent protocol itself, we'd rather need to extend it and just use it for transport.
Modifications would have to include:
Ability to allow, traffic shape or ignore hosts on-the-fly based on if they are paying or freeriders.
Central trusted element (service.com) - I'm not 100% sure if it can be distributed without having a server yourself that constantly does these integrity checks. It could be distributable in that sense though, that there are multiple services to choose from and you can host one yourself (just like torrent trackers but with a lot more bandwidth requirements)
Something to verify upload speed. This is the biggest question mark for me, as it would be trivial to have a central server that downloads files from nodes to check on their speed - but it would be trivial for them to just grant this single node the high speed, everyone else has to live with 1 kb/s.
@markm:
How could I make sure that any of these offers floating around are actually worth even the 1 USD/month/100Gb they ask? Going offline, not offering any significant bandwidth, destroying data, taking a run with the money...
On the other hand, how would I deal with the fact that if I offered to host 100GB for 1 USD/month it might be the case that I never get paid or have to deal with 100s of GB upload because suddenly I'm hosting the newest season of Game of Thrones for the whole internet...
We have been trying it, and see what has happened so far: no concrete offers of bitcoins or fiat to any of those who have space available so far, resulting in continuing water-cooler and/or back-room-engineer chatter about various proposed engineering or marketing tweaks that might or might not result in more or better offers of actual money sooner/faster.
In other words: we already have at least one terrabyte on offer, we already have lowered its price to $1/month per 100 gigabytes, and we still have no concrete offers from anyone to buy a month at that price even stipulating it is on a terrabyte disk dedicatable to the purpose that can become dedicated to the purpose if/when in fact anyone actually decides that purpose suits his or her purpose and presents coin to follow through on it.
So here we sit chattering about various ways the offer can be manipulated, dressed up, elaborated as to precisely what protocols could be deployed for accessing it if a customer has a preference as to what protocol they would prefer to use to access it and so on and so on and so on.
We could firm it up further maybe by getting more details about other swathes of disk, in case the problem preventing firm bids from coming in happens to be not wanting their data to be hosted on a Windows machine, or doubt as to your technical and systems-administration competence to accommodate a request that FTP be the means of access or for NFS mount to be possible or some such technical concern.
Presumably some among us can provide RetroShare based access if some customers would prefer that?
For blocks, chunks, spans, files, collections etc small enough to be threaded through a needle/bottleneck the size of a gmail account, likely some could provide access-via-email if that would be more attractive. Lets maybe just ask each customer how exactly they want to deliver their data to a storage-facility and how exactly they would like to recover it from a storage-facility, and see if we are able to comply with the customer's requirements? How many gigs do the prospects-so-far want to store and by what protocol do they want to deliver it and retrieve it?
If all their preferred methods are vapourware, then basically they are saying they do not actually want to store any data at this time, they prefer to wait until some hypothetical Year of Condensation rolls around. If so, fine, when the coin materialises to seed the vapour sufficiently to cause condensation we can take this up again, meanwhile I see a vapour trail over in a Tahoe-LAFS thread, nice chatting with y'all.
-MarkM-
EDIT: Hey, anyone else noticing this forum is still here after all this time? Heck even when it got shot down over that bitcoin.org that didn't lose the data, did it? Or did it? How much damage, if any? (Lost posts? Lost user-accounts?) Its nice having this free storage to store my posts.
In other words: we already have at least one terrabyte on offer, we already have lowered its price to $1/month per 100 gigabytes, and we still have no concrete offers from anyone to buy a month at that price even stipulating it is on a terrabyte disk dedicatable to the purpose that can become dedicated to the purpose if/when in fact anyone actually decides that purpose suits his or her purpose and presents coin to follow through on it.
So here we sit chattering about various ways the offer can be manipulated, dressed up, elaborated as to precisely what protocols could be deployed for accessing it if a customer has a preference as to what protocol they would prefer to use to access it and so on and so on and so on.
We could firm it up further maybe by getting more details about other swathes of disk, in case the problem preventing firm bids from coming in happens to be not wanting their data to be hosted on a Windows machine, or doubt as to your technical and systems-administration competence to accommodate a request that FTP be the means of access or for NFS mount to be possible or some such technical concern.
Presumably some among us can provide RetroShare based access if some customers would prefer that?
For blocks, chunks, spans, files, collections etc small enough to be threaded through a needle/bottleneck the size of a gmail account, likely some could provide access-via-email if that would be more attractive. Lets maybe just ask each customer how exactly they want to deliver their data to a storage-facility and how exactly they would like to recover it from a storage-facility, and see if we are able to comply with the customer's requirements? How many gigs do the prospects-so-far want to store and by what protocol do they want to deliver it and retrieve it?
If all their preferred methods are vapourware, then basically they are saying they do not actually want to store any data at this time, they prefer to wait until some hypothetical Year of Condensation rolls around. If so, fine, when the coin materialises to seed the vapour sufficiently to cause condensation we can take this up again, meanwhile I see a vapour trail over in a Tahoe-LAFS thread, nice chatting with y'all.
-MarkM-
EDIT: Hey, anyone else noticing this forum is still here after all this time? Heck even when it got shot down over that bitcoin.org that didn't lose the data, did it? Or did it? How much damage, if any? (Lost posts? Lost user-accounts?) Its nice having this free storage to store my posts.
There's no "chaching" when you download or view a file. The very definition of seeding means that the host is making the file available for download 24/7, no strings attached.
I don't see how it is possible to give free storage, since no central agency is offering storage of any kind. The onus to store the files is on the seeders, and they would have little incentive to give free storage to anyone when they can receive paid storage instead.
The problem with setting up a free network is that it would not be a reliable test to find out how a paid network would fare. Uploaders and seeders would act completely differently in a paid market than in a free one.
Some people may decide to drop out of hosting other people's files, but that's the beauty of doing it via torrent and splitting the customer fee between the hosts - if one host drops out, then it is likely profitable for another host to take his place, which is done quickly and efficiently via downloading bits of the file from all the other hosts currently hosting a particular person's backup files.
Why not just try it and see what happens?
I don't see how it is possible to give free storage, since no central agency is offering storage of any kind. The onus to store the files is on the seeders, and they would have little incentive to give free storage to anyone when they can receive paid storage instead.
The problem with setting up a free network is that it would not be a reliable test to find out how a paid network would fare. Uploaders and seeders would act completely differently in a paid market than in a free one.
Some people may decide to drop out of hosting other people's files, but that's the beauty of doing it via torrent and splitting the customer fee between the hosts - if one host drops out, then it is likely profitable for another host to take his place, which is done quickly and efficiently via downloading bits of the file from all the other hosts currently hosting a particular person's backup files.
Why not just try it and see what happens?
TL;DR lets demonstrate and/or provide everyone's free 1 to 5 gigs for [life?!?] first like the professionals do, then see if that is enough proof of capability to attract paying customers.
It should eventually start to look attractive, but only once it has been running long enough to see how many copies one should actually have it keep in order to have a reasonable certainty the data will survive X span of time and so on.
Many among "the competition" give one to five gigabytes for life to all comers, without embarrasing their offer with bandwidth limits let alone dangerous-sounding nickel and dime buildup of charges as bandwidth k'ching k'ching k'ching hits your purse every time the data is actually viewed/delivered.
If we start by setting up a stable, useful "free" network based on sharing, people will be able to simultaneously audition as prospective storage nodes and observe for themselves how many copies of a file need to be out there to make that file's survival likely, then once we have real statistics on how many copies it takes people will have some figures from which to start computing how much someone would have to pay for one surviving copy in order to start with enough copies that there will actually be at least one surviving copy.
If prospective storage-providers are not confident enough that they stand ready to store files reliably for months or years to actually do so long enough to build up the confidence of prospective customers, how likely are they to actually do it once they have money in hand and some other short term scheme to try for a few days that seems to them to make it worthwhile to wipe all customer data to make space for the new scheme, whether it be a cute new automatic-pornsite-builder or yet another spam-the-search-engines-site generator or gosh knows what else that might look like a quicker buck than waiting for a storage customer's next periodic payment of storage fees?
Heck maybe they'll decide they can crack captchas if they fill that space with every captcha image all currently popular captcha generators generate, I am talking about bottom-feeders but a huge fraction of them are likely to go try to scam someone else somewhere else rather than wait out a several month assessment period and by the time such a span of time passed they would very likely have moved on to some other seemingly game-able project or crowd that might offer an easier, faster buck.
Meanwhile, I see the Bounty for adding Accounting to Tahoe-LAFS (preferably or requiredly bitcoin accounting) thread has been revived...
-MarkM-
It should eventually start to look attractive, but only once it has been running long enough to see how many copies one should actually have it keep in order to have a reasonable certainty the data will survive X span of time and so on.
Many among "the competition" give one to five gigabytes for life to all comers, without embarrasing their offer with bandwidth limits let alone dangerous-sounding nickel and dime buildup of charges as bandwidth k'ching k'ching k'ching hits your purse every time the data is actually viewed/delivered.
If we start by setting up a stable, useful "free" network based on sharing, people will be able to simultaneously audition as prospective storage nodes and observe for themselves how many copies of a file need to be out there to make that file's survival likely, then once we have real statistics on how many copies it takes people will have some figures from which to start computing how much someone would have to pay for one surviving copy in order to start with enough copies that there will actually be at least one surviving copy.
If prospective storage-providers are not confident enough that they stand ready to store files reliably for months or years to actually do so long enough to build up the confidence of prospective customers, how likely are they to actually do it once they have money in hand and some other short term scheme to try for a few days that seems to them to make it worthwhile to wipe all customer data to make space for the new scheme, whether it be a cute new automatic-pornsite-builder or yet another spam-the-search-engines-site generator or gosh knows what else that might look like a quicker buck than waiting for a storage customer's next periodic payment of storage fees?
Heck maybe they'll decide they can crack captchas if they fill that space with every captcha image all currently popular captcha generators generate, I am talking about bottom-feeders but a huge fraction of them are likely to go try to scam someone else somewhere else rather than wait out a several month assessment period and by the time such a span of time passed they would very likely have moved on to some other seemingly game-able project or crowd that might offer an easier, faster buck.
Meanwhile, I see the Bounty for adding Accounting to Tahoe-LAFS (preferably or requiredly bitcoin accounting) thread has been revived...
-MarkM-
Except for one person who wanted to be counted in on both sides of the fence, I had the impression all the interest was in getting money for their space, not in paying others for use of others' space.
-MarkM-
If that's the case, then anyone who does use the space will get it extremely cheaply, attracting attention and (likely) more customers. People who are paying $125/month on Amazon S3 to store 1 TB of data can now store the same data split among 5 hosts for $25/month? It starts to sound attractive...-MarkM-
Free market at work.
Except for one person who wanted to be counted in on both sides of the fence, I had the impression all the interest was in getting money for their space, not in paying others for use of others' space.
-MarkM-
-MarkM-
Maybe you missed all the responses in the beginning of this thread, which said, "I'd be interested!"
If nothing else, it'd be an interesting experiment.
I think the treasure idea is kind of silly myself though. I wouldn't take it seriously. As a host, how would I know that there is actually a treasure there, and the uploader isn't just falsely stating as much? Or how would I know that the uploader didn't make a copy of the private key holding the treasure, and once he gets bored, he'll just withdraw it himself?
If nothing else, it'd be an interesting experiment.
I think the treasure idea is kind of silly myself though. I wouldn't take it seriously. As a host, how would I know that there is actually a treasure there, and the uploader isn't just falsely stating as much? Or how would I know that the uploader didn't make a copy of the private key holding the treasure, and once he gets bored, he'll just withdraw it himself?
Jump to: