So the only way to check if a node is storing the correct data is to download the whole thing?  I was trying to think of a way that the uploader could continually validate that the nodes are holding the proper data.  Keeping a decently long index of random pieces of the file would enable the uploader to check only a particular part of the file.  If the seeder returns that particular random part of the file correctly, then it can be assumed that they still have the whole file intact.  Then, the next day, try a different random part of the file, etc.  As long as a sufficiently long index is kept (maybe, a few bytes of data for each day that they want to be able to continue checking), then the uploader should be able to continually verify.

Is that overkill?

That's why I think a central entity needs to be involved to manage payments.  Otherwise, hosts would have to rely on the reputation of the uploader to ensure file seeds are paid.

I think you're a bit confused about how torrenting actually works.

There would be no concept of users on the seeding side, only files and payments.  The site would organize the torrents available, and show how much (currently) a seeder would be paid per day to host a particular file, assuming no change in the current number of seeders of the file.

Again, torrenting is a pull operation, not a push operation.  A seeder would have to request to download a file from the uploader in order to download it - the uploader couldn't push a file onto the seeder's system.

I think torrent software is usually set up by default to seed anything that is downloaded.  In fact, it usually seeds the portions of the file it has WHILE downloading.

Essentially, this is how it would work:
1) An uploader wishes to back up encrypted group of files b1.rar.
2) The uploader creates a .torrent file for b1.rar.
3) The uploader funds his account at service.com with 1 BTC, and states that he will pay 0.01 BTC/day split between all users seeding b1.rar.
4) Various users visit service.com, notice the uploader's proposal, and downloads the .torrent file.  This .torrent file tells their computers where they can download pieces of b1.rar (which would be from all seeders - note that the uploader is a seeder as well).
5) The hosts start seeding the full file as soon as it is fully downloaded.
5) Once the uploader is satisfied with the number of hosts seeding replicas of his file, he takes his file offline and no longer seeds it.
6) Service.com automatically pays out 0.01 BTC/day split between all users seeding b1.rar, with random data integrity checks to ensure they have the complete file.  If 5 users are seeding b1.rar by the end of day 1, then service.com pays out 0.002 BTC to each of them.

Eh, I've had some experience with VPN's, and my experience has shown that they are complicated to set up and maintain, they are somewhat unreliable, and they do not allow some requisite features necessary for this type of project (i.e., allowing continuation of file transfer after interruption).  Plus, allowing anyone into your file system, even if it seems to be contained, is a rather glaring security hole.  And I am uncertain that multiple VPN connections can be made at the same time without consequence.

Here's why I think torrenting would work well:
- After multiple hosts have the files, it reduces the load on any single host to make additional copies of the data.
- It already allows resuming interrupted downloads, managing download speeds and bandwidth usage, etc.
- No security holes or issues.
- It is scalable - if someone wants their data to be ULTRA safe, they can pay such a ridiculously large sum of money on a daily basis to each person seeding the file that hundreds or maybe thousands of people will host said file to "get in on the money".
- If using VPN's, the hosts couldn't just allow anyone to download from them, as they wouldn't want to put their VPN information out in public.  This would mean that the burden of creating additional copies of the original content would lie with the uploader.  What happens if the uploader no longer has the content, and one of the hosts decides to move on to other files?  With torrenting, this would be fine - a host might decide it is economical to start seeding a particular torrent, and download from the other hosts already seeding the content.  With VPN's, the uploader would have to re-download the information from one of the VPN's, then reupload it to a new one.
- Torrenting is already cross-platform without any special configuration.

I don't see VPN's working well unless hosts were willing to allow anyone to download from their VPN-hosted files.  In which case, why use a VPN at all, and not a more standard FTP or HTTP protocol?

I'll emphasize this point again though:  Torrenting reduces the load of any particular host, as it (more or less) evenly splits the load between all seeders.  If a new person wants to download a particular file, and 5 hosts are already seeding it, then each host only has to use bandwidth equal to 1/5 of the total size of the file.  With VPN, FTP, or HTTP, there is no easy way to split up the load between different hosts.  With torrenting, it is automatic.

Bittorrent doesn't already do what I want, because it provides no incentive for other people to hold my backups.  But, adding incentive for other people to hold my backups make torrenting a very viable platform.  Also, there is no reason that torrent technology cannot be used for 1 host just as easily as thousands.

Right, and that's certainly a huge benefit.  But in the early days of prosper.com, most investors lost money DESPITE diversifying their funds across many different loans.  For example, if they invested in the D-class loans with an interest payout of 22%, prosper.com had an average default rate on their D-class loans of greater than 22%, losing the investor money no matter how much they diversified.

I'm a Windows user, as is my sister.  I suppose I have just not heard of whatever this built-in file sharing capability Windows has though.  Unless you are talking about local area network shares (mapped drives and all of that)?  I've never heard it touted as a good way to share files publicly on the internet though - that seems insecure and a way to make yourself ripe for abuse, if it is even possible.

Also, remember, this isn't about my sister.  I could find a number of solutions for her, including giving her one of my hard drives to use (though it wouldn't be as safe as having multiple people store it online).  This is about finding a general-purpose low-cost online storage solution.

I think it'd be great - but how would you prevent defaulting?

Prosper.com is USD-based peer-to-peer lending.  You should familiarize yourself with their history, problems, and how they overcame them before attempting a BTC equivalent.  Their biggest problem early on was the default rate exceeding the interest rate paid to the lenders.  They overcame that problem by doing credit checks and better digging into people's financial histories to give a more accurate picture to potential lenders.

In my opinion, you'll have to either do credit checks on the people asking for loans, or do insanely high interest rates to protect against defaults (which would likely only further aid the number of defaults happening).

I still don't see a good reason to deviate from a popular and known platform (torrenting) to something that doesn't even exist yet (Windows Shares?).  That's just making things more complicated for the sake of making things more complicated.

Regarding software development, well, this is only idea exploration at this point.  I am getting close to the point where I'd feel comfortable with dropping some coin on a programmer developing the idea though.

I'd argue that everyone will NOT be an upload point, and that as the popularity of it grows, the connection will be slower.

Think about it.  Say a new movie file is to be played 30-60 seconds from now, and there are 10 users watching the channel.  Where does that movie file come from initially?  A central server?  Ok, so the users download from the central server, then, progressively, from each other, as they each download different parts of the file and subsequently share those parts with each other.

Now say there are 10 million users watching the channel.  The movie file still (initially) has to come from a central server, but this time, you have 10 million people bombarding it with a request for the same file at the same time.  You could potentially build up a beefy enough bank of servers to handle all of those requests, but then would it be any different from simply streaming the same content to everyone without torrenting?  Certainly, as the file is downloaded, the clients can increasingly rely on each other for the missing pieces, but you'd still have the initial problem of everyone trying to download from the central server all at once.

So, to fix it?  I'd say that the average show needs an hour or two of "seed time" before it could be shown.  This would give plenty of time to decentralize the content from the point of origin (which could very well just be someone's home computer anyway), and even if many clients came online just before the show started, they should have plenty of seeds to download it from quickly.

TL:DR; Serving content on a near-instant basis would be difficult due to initial centralization of said content.  It would be better to wait for a while after making said content available before showing it.

Right, he's working on verifying his account here (newbie jail), then will be able to answer more questions and potentially take orders.

This is the part I am really unsure of.  I know IP addresses identify torrent clients, but beyond that, I am not sure what other information they can make public about themselves or request from others.  Gladamas seemed to indicate that it would be easy to attach a Bitcoin address to a particular torrent seeder, but I don't know the specifics about how that would work.

I'll try to poke holes.  I haven't read the entire proposal, but I'll start with this:  I am already used to using Netflix streaming, which provides low-cost on demand streaming of enough content that I don't think I'll ever get bored with it.  Why would I want to switch back to something that's "on a schedule", so to speak?

Also, where will all of this video be stored?  A tiny raspberry pi-like device cannot possibly hold more than a handful of shows at a time, so there must be some sort of central server that stores all of the past and future shows on it?  I would also argue that the devices would have to start downloading future shows WELL in advance of the show actually starting, since most people do not have a very fast connection.  1.5 mbps might be just enough to stream in real-time from a central server, but streaming torrent-style couldn't be close to real-time on such a connection.

Yes, you are exactly right - pull instead of push.  The uploader would volunteer the data to be copied as a torrent, and the hosts could download said data at will, as long as it is up.  Many of the more hardcore hosts would likely find a way to automatically download new data that meets a certain criteria (i.e., current payout above $0.0X/day).  An alternative might be automatic download of all new torrents by the Service, until another host picks it up, allowing the uploader to effectively "push" out the new data whenever they like.

The nice thing about using a torrent protocol for the base of a project like this is that torrents are already very widely used and understood by many of the people.  Perhaps even more importantly is that the group that understands torrenting the most is the group that is most likely to have lots of hard drive space, and (potentially) lots of extra hard drive space.

I suppose the one thing I am most interested in at this point is more detail on how Bitcoin addresses can be tied to hosts.  Gladamas touched on it, but I am not enough of a programmer to understand how it might work.

You have to step away from what torrent is used for right now, and look at how it can be used.  It can be used to easily give multiple hosts copies of the same data, which is exactly what we want when looking to make backups of said data.  There will still be demand for these backup files to be downloaded via torrent, but the demand will only exist among the original uploader (potentially), and those who wish to seed it to gain a portion of the daily fee paid by the uploader.

I agree there is a difference between a just-in-case copy of data vs an only copy of data.  But how does that have anything to do with your previous post about selling parts of movies via torrent?

The data in my sister's case is raw files from older wedding photoshoots and such - files that she will likely never need to touch again.  But, better than deleting them entirely would be finding some method of cheap online storage until she can buy some extra storage space.  So, it wouldn't be the end of the world if they were somehow lost forever (since the only other option is to simply delete them at this point anyway to make room for newer photos), but she'd still like to keep them, if possible.

Certainly, though, I believe a service like this would be used more for "just in case" copies of data than anything else.

I'd be fine with doing some testing/trials.  I am not a regular torrent user, so I really know only minimal amounts about it, but I do know enough to click on some menus and create/seed a torrent.

The "escrow" address (as labeled by blockchain.info) is not added as a firstbits address at this point in time.  All other addresses involved in a multisig transaction would be added as firstbits addresses.

Good stuff.   

That's quite a large tangent from the idea of backing up personal files, markm.  Perhaps a good discussion for another thread though. 

Right now, I do not have a good method of offsite backups.

Wouldn't you have to keep some data on hand to make sure the checksum or hash matched?  In other words, what would be the difference between checking small bits of data vs checking a checksum of small bits of data?

Sounds like it is possible to tie a bitcoin address to a particular seeder then!

He said around $8 for the bulbasaur, though I'm not sure if that includes shipping costs or not.

Thanks!  I'm sure if the original uploader wanted the specifics to be known, they could add that in the description, right?