Making Money from P2P File sharing!
August 20, 2009 6:14 PM Subscribe
Do you know of any attempts to monetize peer-to-peer file sharing? That is to say if a user is sharing a file, she gets compensated for uploading bits of the file? I'm interested in knowing who's looking in to it and what kind of success they may have had.
I think the disparity between consumer download and upload rates is too large and with bandwidth is so cheap that you'll have be uploading for days/weeks to make any worthwhile money.
S3 is in the 10-15 cents per gig range. On consumer upload speeds (say 340kb up) that would be around 40 cents a day and would max out your line.
posted by wongcorgi at 6:28 PM on August 20, 2009
S3 is in the 10-15 cents per gig range. On consumer upload speeds (say 340kb up) that would be around 40 cents a day and would max out your line.
posted by wongcorgi at 6:28 PM on August 20, 2009
There are certainly closed invitation-only piracy communities where one must bring a certain quantity of (new) data to be eligible to join. There are for-pay piracy sources (of course) and I would not be surprised at all if somewhere someone used the former arrangement as a feeder for the latter.
posted by polyglot at 6:30 PM on August 20, 2009
posted by polyglot at 6:30 PM on August 20, 2009
Best answer: Game theory.
In addition to the reasons above, adding a payment system would create an incentive to game that system. Fixing this becomes even more complicated if you want to avoid central servers, which are a weak point for legal attacks (c.f., Napster).
Designing a decentralized payment system is problematic. Suppose I download a bunch of bytes from you, but because I'm a cheapskate I refuse to pay. How do you prove you actually sent me the bytes, and that I received them? If there's a central server, it becomes your word against mine to that authority. If there's no central server, then you eat the loss and refuse to do business with me in the future. However, in a P2P environment, there are so many participants that I can just move on to the next guy and rip him off. So maybe you want to communicate with other people about reputation, but how do you know how to trust? You need to build some kind of reputation system --- again, very difficult in a decentralized setting. This has been studied. And any time a centralized server is introduced, it becomes an attack surface for the RIAA and their friends.
Another problem: Payment latency. Suppose you're not worried about legal attacks, so you go with Paypal or some other centralized bank service. You need to use micropayments because that reduces the damage people can do by refusing to pay. This means Paypal needs to be able to handle literally billions of transactions per day. Transactions take time, but as a client, any deductions from your account would need to be serialized or rate-limited to prevent you from simultaneously making a million withdrawals before your balance is updated. This serialization of transactions becomes a tremendous performance bottleneck; as someone receiving payment, you need to wait for at least some of these transactions to complete before sending more packets, and this will seriously hurt the bandwidth of the overall system.
In the real world, commerce works in large part because the police and courts provide a strong incentive not to commit fraud. These things don't exist in a decentralized P2P setting, and it makes everything really really complicated.
posted by qxntpqbbbqxl at 7:06 PM on August 20, 2009 [1 favorite]
In addition to the reasons above, adding a payment system would create an incentive to game that system. Fixing this becomes even more complicated if you want to avoid central servers, which are a weak point for legal attacks (c.f., Napster).
Designing a decentralized payment system is problematic. Suppose I download a bunch of bytes from you, but because I'm a cheapskate I refuse to pay. How do you prove you actually sent me the bytes, and that I received them? If there's a central server, it becomes your word against mine to that authority. If there's no central server, then you eat the loss and refuse to do business with me in the future. However, in a P2P environment, there are so many participants that I can just move on to the next guy and rip him off. So maybe you want to communicate with other people about reputation, but how do you know how to trust? You need to build some kind of reputation system --- again, very difficult in a decentralized setting. This has been studied. And any time a centralized server is introduced, it becomes an attack surface for the RIAA and their friends.
Another problem: Payment latency. Suppose you're not worried about legal attacks, so you go with Paypal or some other centralized bank service. You need to use micropayments because that reduces the damage people can do by refusing to pay. This means Paypal needs to be able to handle literally billions of transactions per day. Transactions take time, but as a client, any deductions from your account would need to be serialized or rate-limited to prevent you from simultaneously making a million withdrawals before your balance is updated. This serialization of transactions becomes a tremendous performance bottleneck; as someone receiving payment, you need to wait for at least some of these transactions to complete before sending more packets, and this will seriously hurt the bandwidth of the overall system.
In the real world, commerce works in large part because the police and courts provide a strong incentive not to commit fraud. These things don't exist in a decentralized P2P setting, and it makes everything really really complicated.
posted by qxntpqbbbqxl at 7:06 PM on August 20, 2009 [1 favorite]
In support of qxntbabblebabble's comment, BakaBT has banned certain torrent clients because they cheat and lie.
posted by Chocolate Pickle at 8:16 PM on August 20, 2009
posted by Chocolate Pickle at 8:16 PM on August 20, 2009
Designing a decentralized payment system is problematic. Suppose I download a bunch of bytes from you, but because I'm a cheapskate I refuse to pay. How do you prove you actually sent me the bytes, and that I received them?
One approach:
Alice has some bytes that Bob wants. Bob agrees to pay 1¢ per byte (or whatever). Alice packages up the data and encrypts it. She sends the encrypted data to Bob. Bob sends the money to Alice. Alice sends the encryption key.
Another approach:
Alice sends Bob small packets of data. Bob sends 1¢ for each byte, immediately after he receives each packet of, say, 256 bytes, but before the next one is sent. So Alice sends Bob 1 packet of 256 bytes, he sends back $2.56. This continues until the transaction is complete.
Yet another approach:
Combine the two approaches above. Alice encrypts each packet of bytes. Bob pays after receipt of each packet. And Alice sends the key for each packet of bytes. This reduces the risk that Alice sends Bob garbage, and reduces the chances that Bob refuses to pay the final allotment.
There are other options I can imagine involving hashes to determine authenticity of goods. But, they wouldn't work on an wild P2P network, since so many different encodings of the same pirate material will be available, and few people really care what particular encoding they're getting so long as the content is what they asked for. However, if we're talking about the transfer of well-known content, then we'd have someplace to go there.
posted by Netzapper at 8:49 PM on August 20, 2009
One approach:
Alice has some bytes that Bob wants. Bob agrees to pay 1¢ per byte (or whatever). Alice packages up the data and encrypts it. She sends the encrypted data to Bob. Bob sends the money to Alice. Alice sends the encryption key.
Another approach:
Alice sends Bob small packets of data. Bob sends 1¢ for each byte, immediately after he receives each packet of, say, 256 bytes, but before the next one is sent. So Alice sends Bob 1 packet of 256 bytes, he sends back $2.56. This continues until the transaction is complete.
Yet another approach:
Combine the two approaches above. Alice encrypts each packet of bytes. Bob pays after receipt of each packet. And Alice sends the key for each packet of bytes. This reduces the risk that Alice sends Bob garbage, and reduces the chances that Bob refuses to pay the final allotment.
There are other options I can imagine involving hashes to determine authenticity of goods. But, they wouldn't work on an wild P2P network, since so many different encodings of the same pirate material will be available, and few people really care what particular encoding they're getting so long as the content is what they asked for. However, if we're talking about the transfer of well-known content, then we'd have someplace to go there.
posted by Netzapper at 8:49 PM on August 20, 2009
The recent buyers of The Pirate Bay are trying to monetize and legalize it
Personally, I don't think it has a snowball's chance in hell of working, but you can read about their plan.
posted by chrisamiller at 8:56 PM on August 20, 2009
Personally, I don't think it has a snowball's chance in hell of working, but you can read about their plan.
posted by chrisamiller at 8:56 PM on August 20, 2009
Alice has some bytes that Bob wants. Bob agrees to pay 1ยข per byte (or whatever). Alice packages up the data and encrypts it. She sends the encrypted data to Bob. Bob sends the money to Alice. Alice sends the encryption key.
Amy doesn't have the bytes that Bob wants, but Amy is also unscrupulous and lies to Bob and says that she does. Bob agrees to pay. Amy takes random crap and encrypts it and sends it to Bob. Bob sends the money.
1. Amy then sends the key, and Bob is frustrated to learn that he bought a digital barrel of sand.
2. Amy never bothers sending the key at all.
Ultimately someone has got to trust someone else. There isn't any way to avoid that. In normal commercial transactions we're willing to do so because the legal system is available to enforce it, but in illegal transactions there's no such protection.
It's even worse than the problem eBay has with trustworthiness, and they haven't found a perfectly satisfactory solution to that yet.
posted by Chocolate Pickle at 9:18 PM on August 20, 2009
Amy doesn't have the bytes that Bob wants, but Amy is also unscrupulous and lies to Bob and says that she does. Bob agrees to pay. Amy takes random crap and encrypts it and sends it to Bob. Bob sends the money.
1. Amy then sends the key, and Bob is frustrated to learn that he bought a digital barrel of sand.
2. Amy never bothers sending the key at all.
Ultimately someone has got to trust someone else. There isn't any way to avoid that. In normal commercial transactions we're willing to do so because the legal system is available to enforce it, but in illegal transactions there's no such protection.
It's even worse than the problem eBay has with trustworthiness, and they haven't found a perfectly satisfactory solution to that yet.
posted by Chocolate Pickle at 9:18 PM on August 20, 2009
Ultimately someone has got to trust someone else. There isn't any way to avoid that.
Yep. It's a game of whack-a-mole. You change the rules to remove one incentive to cheat, and accidentally create a new one. In this particular scenario, you might want to add on a new rule that says that Amy is going to send Bob a proof that the data she sent, when decrypted, matches the correct and expected hash. So she can't cheat him. But now Bob needs to trust a hash authority...
posted by qxntpqbbbqxl at 10:00 PM on August 20, 2009
Yep. It's a game of whack-a-mole. You change the rules to remove one incentive to cheat, and accidentally create a new one. In this particular scenario, you might want to add on a new rule that says that Amy is going to send Bob a proof that the data she sent, when decrypted, matches the correct and expected hash. So she can't cheat him. But now Bob needs to trust a hash authority...
posted by qxntpqbbbqxl at 10:00 PM on August 20, 2009
Or Bob could put his money in escrow, to be released only after he confirms the data. Which means he could receive the data but claim he did not, and rescind the escrow.
posted by Chocolate Pickle at 10:28 PM on August 20, 2009
posted by Chocolate Pickle at 10:28 PM on August 20, 2009
he could receive the data but claim he did not, and rescind the escrow.
Which he could do... even if it was the correct data.
posted by setanor at 11:26 PM on August 20, 2009
Which he could do... even if it was the correct data.
posted by setanor at 11:26 PM on August 20, 2009
Depending on how you define compensate, Bittorrent is a hedonistic protocol. You trade chunks with peers, and upload rates being a function of tit-for-tat and whatnot. Your reward for uploading is downloading.
Once you start paying people money for bandwidth, it's a whole different game. You absolutely must consider transaction costs, and comparative advantages. Consumer broadband is generally low upload and fairly expensive per dollar. Once you factor in making monetary payments to hundreds of people, I can't see that actually working.
The most clever monetization scheme I've seen was the Sharman Networks claiming to charge to rent out CPU cycles on computers running Kazaa. I think that went nowhere.
posted by pwnguin at 11:33 PM on August 20, 2009
Once you start paying people money for bandwidth, it's a whole different game. You absolutely must consider transaction costs, and comparative advantages. Consumer broadband is generally low upload and fairly expensive per dollar. Once you factor in making monetary payments to hundreds of people, I can't see that actually working.
The most clever monetization scheme I've seen was the Sharman Networks claiming to charge to rent out CPU cycles on computers running Kazaa. I think that went nowhere.
posted by pwnguin at 11:33 PM on August 20, 2009
I used to be part of one called Peer Impact. Basically, no one made very much money because there were a lot of people "seeding" the files and less downloading them. Even when you would help in some way with a download, the compensation was negligible compared to how much the song cost originally ($1).
posted by bradly at 12:21 AM on August 21, 2009
posted by bradly at 12:21 AM on August 21, 2009
my only experience with this sort of thing is peerimpact, but i didn;t like it much, never made any money off my uploads, but they did give me enough credit for 2 cd downloads to try it.
posted by vegetableagony at 8:11 AM on August 31, 2009
posted by vegetableagony at 8:11 AM on August 31, 2009
This thread is closed to new comments.
Rewarding people with money would have some pretty serious legal ramifications. Most trackers are skating on the edge of copyright law because they facilitate but don't participate in wholesale copyright violation. None of the copyrighted material passes through the tracker.
If they were to give money to their users for uploading, then they'd skate off into really thin ice legally. They would then be directly involved in copyright violation with no plausible deniability at all and could be sued.
There's also the serious question of where the money would come from. Advertisers are unlikely to be willing to finance such a scheme.
posted by Chocolate Pickle at 6:25 PM on August 20, 2009