Bitcoin Forum

So I was reading this http://torrentfreak.com/harvard-develops-p2p-client-that-uses-bandwidth-as-currency/  about how one particular filesharing system is attempting to use bandwidth as a "currency."  I'm wondering if we could modify a p2p bittorrent client to use bitcoin as the internal currency and start using it amongst ourselves?  If it's successful, I think it would have the potential to turn viral.

I envision something like this:

• In addition to merely seeding a file, you specify a "wager" in btc that that file will be popular.
• So essentially you are betting that your file will "earn" more btc than your wager
• Initially the flow of btc is OUT from you to the first downloaders.  Yes, the downloaders are pretty much being "paid" to download and seed your content.
• Then, once your wager "thresh hold" is reached the flow of bitcoins reverses and comes back to you. 
• Hopefully earning you more than you originally wagered, or if your content sucked or had a virus, you probably took a loss

I know that there are some holes in this plan, but what I'm proposing here is that we put our heads together and see if bitcoin can be a better file-sharing currency than anything else out there.  If so, I think something like this could take off.

It's not a secret that most of BT traffic is illegal and violates copyrights. If people will make money on such things it will give copyright holders more reasons to blame BT. It should be discussed though.

Paid separately for downloading and uploading or paid after both are accomplished? Or paid more for each kb they send? Paid by whom? The second generation of downloaders? Just trying to figure how incentives will work.

It seems to me that a simple system would just be, pay whoever seeds the file you want and then charge anyone who wants a file you have.

I'd rather like a distributed file storage system to use bitcoins to pay/earn for/by the bandwidth and diskspace you provide to it, then filesharing that pays, you'd still need "the good files" that everyone wants to "make some coins".

zooko mentioned here (http://bitcointalk.org/index.php?topic=890.0), that there are already people working on integrating bitcoin into tahoe-lafs.

would be very cool if you could just set up a storage-node and earn coins by just providing some space and bw.

Yes, simply when you start to download a file you either randomly pay one of or split the payment among the feeds. Then if/when you become a feed you get at least a chance of getting paid back if the file is downloaded further.

Feeds have could have the option of whether they don't want to feed freeloaders or just give priority to paying down loaders.

Maybe paying smaller payments for partial files down to single blocks would be better, then cheaters would get less and be easier to detect and control. (Cheating feeders could take your payment then not feed you. Cheating freeloaders might promise to pay at the end of the download then not do so)

"Mainstream" users want a more-selection, less expensive, just as fast variant of iTunes.  Frankly, I don't think an illegal filesharing site can scratch that itch and stay in business for long (I'm curious to see how long mulve.com lasts).

If it could, I think a bitcoin-revenue-sharing business model would work well-- "We'll give you 50% of the revenue from any downloads of stuff you upload"  (and "we" charge x-bitcoins-per-download).

But I think even if such a service existed there would still be a bunch of people who refuse to pay a bit-penny for downloads.  But I agree with lfm-- I think many of them would be willing to pay indirectly for downloads; you just have to tell them that they're paying for "X gigbytes of premium bandwidth" or something...

I think that picking incentives and making it incredibly easy are the crucial aspects.  Ideally I would want most of the bitcoin transactional stuff hidden from users.  Additionally, if designed correctly it could be a "zero sum game" for most uses:

• Seeders of good content get their bitcoins back
• Seeders of bad content lose their bitcoins to power users/early adopters
• Normal users (not power users) download for free like normal.  They pay/receive an equal number, canceling out.
• Some users may decided boost their download speed by merely upping their bid

I also agree with gavin's point that the mainstream is looking for something easy like iTunes, yet with more selection and no rules.  This could do that if we were smart.

If you expect it to become a "zero sum game" for most users anyway,
what is it good for?
Why should users want to use bitshare, instead of bittorrent, if there's actually no difference?

Most people spend about what they make each year. It is still worth using a system of paying and getting paid in order to allocate resources effectively.

I'm impressed by how well BT works honestly, but I could imagine a faster system with even more diverse content and less wasted time/bandwidth on crappy downloads. I think giving the right incentives to host content that people want and to only download things that you actually want OR think others will pay you to host.

You've hit the nail on the head here.  Prices are a great way to incentivise appropriate allocation and also weed out desirable vs undesirable information.  So the big question is, can we structure it such that it works on top of BT?  Will the incentive be strong enough for people to migrate over to bitcoin compatible BT clients? I would ;)

If they see that bitcoin is supporting "piracy", they might be more keen to try to shut down bitcoin.

Well, it's only a matter of time before some crypto-currency is used for the "shady areas" of the internet.  IMO we may as well seize the moment and have that currency be bitcoin, since we already have the exchanges in place ;).

The only question is: who will develop the infrastructure? It seem like a lot more work than creating a simple web-service.

Anyone who wants to take 1% of millions of small transactions.

Not a real answer. I mean somebody who will actually do it.

Aarrgh Matey!  That's the spirit!  Spoken like a true pirate! ;)

Hey, we forgot the important thing here — a transaction fee. If everybody would pay 0.000001 per Kb (for example) it will overload blocks with trash and cause large tx fee. So we'd pay relatively large pieces at once. But whom to pay then and how much? And when? If we pay in advance to some clients to DL appropriate number of megabytes they can send you some chunks and then just shut down their clients. If you pay after download... you may not to pay at all because you already have the file. It's not good, too.

The only solution (well, not the best but better than all mentioned) I see is to encrypt all chunks from each client with some key that only uploader knows. So you download for free the entire file first but can't use it because you have no keys. Then you pay uploaders and they provide you with keys. To make it all trusted there may be key mediums established that everybody trust. Keys of uploaders are put to that medium site for every DL session and every downloader separately to prevent downloading by many, buying one set of keys and exchanging them. We don't care about exchanging the resulting file because we don't sell content, only our own bandwidth and cheating on wasting bandwidth without paying would be technically impossible. The medium holds nothing but keys and can't use it itself because it can't get the encrypted traffic which these keys are for. It just takes, holds and gives them (maybe) charging some fee for its service.

Another questionable part is torrent files. We can't use it for download check because checksums of chunks will be different in the each session. Even if we download from the same seed twice we'll get different chunks due to different session keys (which we don't know before we pay). The proposed solution is to distribute standart torrent files and find seeds using trackers or DHT (with its infohash). Then our client decides which chunks download from each of seeds and sends them crypting request. Every seed calculates partial torrent by encrypting requested chunks with its session key and sends back such a part. Our client builds them together and gets a new encrypted torrent. Then we download as usual verifying chunks against encrypted torrent and it should match of course. At last the client contacts the medium payment site and shows addresses and sums for all seeds that participated. You pay, get the keys, decrypt the file and enjoy!

Proposed scheme would require some modifications to bittorrent clients. But it's better than developing one from scratch. Moreover such clients may support both regular free downloads and paid ones and even combine them! For example, you can set in preferences that you accept paid seeds and then your original torrent file gets modified with checksums of encrypted chunks (which you DL from paid seeds) while others are left untouched. Also you would have the possibility to redownload chunks from another seed if the original has left for any reason. Then all that chunks you've already downloaded from that seed are dropped (but others aren't) and the crypting request is sent to another seed or maybe to one of that you're already downloading from. Bad for that one who left — he won't get paid but you also will waste bandwidth.

The only problem left that I see for now is flooding and false requests. Somebody who doesn't like this system may start requesting files and cause lots of load on seeds with no paying in exchange. They would encrypt chunks and send them getting nothing in exchange. This will result in dissatisfaction and leaving the system. Maybe something like peerblock and global fraudlists will help. Who knows. Or maybe you'd pay to the medium in advance before starting download and if you don't finish in several days then your money will be divided between seeds who posted their keys to the medium. And the participating seeds would be chosen via medium by your client requests (seeds also check the medium to ensure that you paid enough first). So your client and seeds clients can't connect to each other if medium don't accept you both.

I guess the old poor ratio system is obsolete. It's easy to cheat on and download without uploading. But even this old system stimulates to seed on non-open trackers (sometimes they aren't closed at all i.e. there is ratio but also anonymous downloads exist). Imagine what it would be with money rewards for seeding!

You're welcome to discuss this wall of text and geek delirium.

Thanks for the very detailed post!  This was precisely the discussion I was trying to bring to light.  I think some of the solutions you have proposed could work.  Additionally, I see this as potentially generalizable to all information, not just files.  But let's stick with file-only just to keep the discussion on track.

The bottom line is that this system at least has the potential to reward originality.  A well known musician might post a music video on there, and because he is trusted and supported, lots of people could choose to seed his video (without modifying it from its original format).  However, a dj or someone else might want to modify the file format (or overlay some new beats).  That new file is then, again original content.  The DJ can seed his new original content and if he has many followers they would seed it as well.

There's no way around the fact that information travels quicker and quicker these days, and I would assert that the more popular information is, the less original it is, and therefore the marginal value of it is also less.  I think by focusing on rewarding originality with an embedded pricing system we would have a system that could cut the crap.

Ahoy!!!
 
It looks like there are some open-source bitcoin clients, the developers of which, would be willing to create add-ons and features for a bounty.  Whether they will do it for a bitcoin bounty is unknown at this point.  However, if we want it done in a timely manner we might want to pay them in USD.  I'm not near as capable as some of you guys from a coding perspective, but I would consider investing/donating to a project like this.

A paid freenet model would go viral. Along with a file sharing/uploading project I propose the bitcoin community gets together and hires out the swarm to a paid distributed computing project . This idea can be seen working here - https://www.gomezpeerzone.com/Program.aspx (https://www.gomezpeerzone.com/Program.aspx) . As people contribute cpu power to the swarm they can earn bitcoins rather than dollars. I know most of us have switched off generation as it is no longer profitable so if there is a way to put the combined power of the bitcoin community to use it might bring in more users.

How I see this working is there would be a client everyone could download and this uses your spare cpu cycles to earn bitcoins. Or another idea is to charge people to store their encrypted data on the swarms hard drives. There might be a monthly fee that users would be charged for this that is distributed amongst all contributors based on the storage they allocate. Companies might want to hire the swarm as a distributed server for their projects or something. If the data is all encrypted no one user could ever know what it contains.

When you seed on Bit Torrent today, you get no guarantee that the person you're sharing with will share with anyone else--yet the system works just fine.  I think we can extend this hopeful principle to a payment system.

Abby begins seeding a file to a swarm of two other people, Ben and Crissy.  Abby's uses a BitCoin-enhanced Bit Torrent client which, when it makes the initial connection with a leech, sends a fresh Bit Coin address.[1]

Ben doesn't use BitCoin, so his client ignores the extraneous BitCoin address and downloads like a regular leach. 

Crissy, on the other hand, also uses a BitCoin-enhanced client and she sets up her client to send 0.01 BTC for every MiB received.  Her client notices Abby's BitCoin address and sends payments there in the ratio Crissy specified.  After uploading her first MiB to Crissi, Abby's client notices the incoming payments and correctly attributes them to Crissy--and from then forward prioritizes uploads to Crissy.

Now lets say another user enters the swarm--Daniel.  Daniel uses a BitCoin-enhanced client too and he's in a big hurry to download the file, so he sets his client to pay 1 BTC for every MiB.  Abby's client will soon notice Daniel's greater payments and will prioritize uploads to Daniel first and Crissy second; Crissy's client will also prioritize uploads to Daniel over Ben.

In summary, BitCoin-enhanced Bit Torrent clients upload like normal Bit Torrent clients until they receive BTC; then they prioritize uploads to whichever client pays the best.  How do they know who pays the best?  They simply divide the total number of bytes uploaded to that person by the total number of BTC received from that person.  (Later implementations may want to use a moving average to react quicker to changing conditions.)

-Dave

[1] The fresh BitCoin address is so the client can correctly attribute all incoming payments to their originator's Bit Torrent client.

That is an impressive post!

Are you able to develop this idea into an actual implementation?

This would work on freenet as well  ;D

This is good idea.  I suggest, however, writing plugins for existing Bittorrent clients rather than writing a new client or forking an existing client.

utorrent has just released an sdk for developers to create apps http://www.utorrent.com/developers (http://www.utorrent.com/developers).

NO. That's what my post was all about. We SHOULDN'T pay for little chunks. Just think how such micropayments would overload the entire bitcoin network. Read these fee rules (http://www.bitcoin.org/wiki/doku.php?id=transaction_fee) especially the block size part. If this scheme will be implemented we'll end up with high fees because of blocks overloading with 0.01BTC txs. That's why I propose payments per entire large chunk set from the single uploader. And guaranteeing that with encrypting and trusted key store.

Exchanges like MtGox can handle many transactions "off the books" of bitcoin and settle officially later. It might make sense to do that here too.

So you send coins to someone first, do some downloading, speeding up certain files by offering payments, and the site moves the credit out of your account and into the uploaders, but doesn't send it to them until they click "Pay Me" or whatever.

That is more like rapidshare than bittorrent.

On rapidshare you download from one and only source. Here your client select which chunks to download from each of uploaders (there may be lots of them with various prices set so you can choose). Then you download as in regular BT except that chunks sources are preselected. In original BT sources are chosen on the fly because some peers may leave and some others with better speeds come in. But that's because people have no real incentive to seed (except the common sense of course). If they are granted money they'll seed their best to get them.

Another problem came in my mind. What if the seeder provide the medium with the wrong key? You'd send the payment and get that wrong key and the whole download will be broken then. Well, not the whole but the encrypted part with the key you don't have. For now I don't know how to check validity of that key. Maybe it's possible if the seeder sends not only the key to the medium but also partial torrent witch checksums of chunks he wants to seed. But that's obvious that checksums of encrypted chunks aren't equal to encrypted checksums of plain chunks. Are there any cryptotechniques to check key validity having the checksums of blocks and checksums of encrypted blocks?

I imagine a seed escrow would keep the coins untill it gets the all clear.

Thanks for the link.  I hadn't read that before.

It appears to me that the BitCoin network can't handle more than about 30,000 transactions an hour.  I bet there's much more than 30,000 Bit Torrent downloads an hour most days, so even paying for big chunks--even paying for whole files!--can't persist for long.

Transaction fees, when they appear, will probably motivate people to use different payment processors for small transactions.  They might use centralized trusted third parties like FreeMoney suggests, but for something under government scrutiny like Bit Torrent, I think people will want to use a decentralized currency--something like BitCoin.

The solution, I think, is to build support for multiple BitCoin networks into the BitCoin-enhanced Bit Torrent clients[1].  The main BitCoin network will be akin to gold; the next network might be akin to silver; the next, copper; etc... 

In the example story I gave, Abby would simply send a BitCoin address for each network she supported.  Chrissy and Daniel would pay using networks which didn't charge transaction fees.  Exchange rates would allow Abby to compare Chrissy and Daniel's contributions in absolute terms.

-Dave

[1] I agree with mizerydearia that this should be implemented as a plugin where possible.

I think we shouldn't create more networks. It will mess the system. If this system become widely used then transactions will be slower because without the fee they won't be included in the block and will wait until the next one generated. I guess it will be a queue of txs. And if you care about the speed you may pay the fee to let your tx be included in the nearest block generated. The biggest problem (judging by the wiki) is that nodes which aren't generating don't know about the block size and don't know whether they should pay the fee for the transaction to be processed. I think it should be corrected that way so all nodes count txs in all cases and calculate the block size. For now looking through the chain there are few txs per block (1-3) and it's not a problem. When (if) the payment flow become really big all those fee stuff would be implemented and explained clearly to the user.

Non-generating nodes don't know the current block size you mean? Even generating nodes don't know what the current block size will end up being, so I don't think that's much of an issue. Non-generators do know the size of recent blocks, so they can guess about as well as generators.

Generators use the size of their own temporary block, which is likely to be very near the actual blocksize. Non-generators always assume the blocksize is 1 kB.

Satoshi has said that non-generators will look at recent block sizes if it becomes a problem.

Upon reconsideration, I think there is a way that is simpler, less specific, and much more useful. It would support paying for downloads not just on BitTorrent but any protocol--HTTP, FTP, Gnutella, and others.

How it works: The uploader uses traffic shaping to assign downloaders' IP addresses into several pools. Each of these pools is allocated a maximum amount of bandwidth they may use. For example:

• Abby sets pool 0 to include all downloaders who haven't paid yet.  She gives them up to 25Kbs.
• She sets pool 1 to include downloaders who paid 0.01 to 0.04 BTC.  She gives them up to 50Kbs.
• She sets pool 2 to include downloaders who paid 0.05 BTC or more.  She gives them unlimited bandwidth.  (Unlimited by Abby; her link speed or her ISP limit the connection, of course.)

It doesn't matter to Abby whether her downloaders are downloading from her BitTorrent client, her Web server, her FTP server, or any other service she provides.  She also doesn't have to count bytes sent; all she needs to do is keep a simple mapping of IP addresses to payments received.

Even better, Abby can join together with Ben. They both agree to use the same IP address pools with the same bandwidth limits and to split the incoming payments. (Though more complicated arrangements are possible.) More people might join Abby and Ben. A large uploader syndicate would decrease the need to make frequent small BitCoin payments.

How hard is this to implement?  On Linux, the traffic shaping should be easy[1]; a simple service could let downloaders request a BitCoin deposit address from uploaders[2]; and the simple service would also poll the BitCoin daemon[3] to see which payments have been received and then move those IP addresses to the appropriate pool.

Comments welcome.

-Dave

[1] Famous last words? Also, I have no idea how hard traffic shaping is on other platforms, especially Windows.

[2] Perhaps the service should require incoming requests contain a hashcash token to reduce the chance of DoS attacks.  You don't want some 12 year-old asking you to generate 10 billion BitCoin keypairs.

[3] Though I'd love to see GavinAndresen's in-progress monitoraddress postback request implemented for this.

The problem is NAT'ing addresses. It's pretty common in Russia so if two clients are using the same external IP there is no way to determine who is who judging only by that address. Don't forget that IPv4 addresses are running out soon.