Bitcoin as a file-sharing currency?

[Anonymous]

we [ought to] pay [for] relatively large pieces at once. But whom to pay then and how much? And when?

[...]

The only solution I see is to encrypt all chunks from each client with some key that only uploader knows.

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 

[1715016100]

1715016100

[1715016100]

1715016100

[1715016100]

1715016100

[1715016100]

1715016100

[1715016100]

1715016100

[mizerydearia]

we [ought to] pay [for] relatively large pieces at once. But whom to pay then and how much? And when?

[...]

The only solution I see is to encrypt all chunks from each client with some key that only uploader knows.

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.

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

[Anonymous]

we [ought to] pay [for] relatively large pieces at once. But whom to pay then and how much? And when?

[...]

The only solution I see is to encrypt all chunks from each client with some key that only uploader knows.

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.

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.

The Apps SDK introduces a web-based extensions framework for µTorrent to allow for easy extensibility by 3rd party developers through a simple API, without compromising the renowned "lightness" of the client.

"Apps" consist only of HTML and Javascript packaged together and displayed using an embedded browser window after being added to the client. Apps for µTorrent is a new kind of file with a ".btapp" suffix that anyone can make.

Apps for µTorrent can access all the functionality of the client so developers can:

    * Offer a simple and more integrated way for consumers to find and download different types of content
    * Integrate with external programs which can provide services like BitTorrent-specific anti-virus
    * Offer UI for a broad range of applications that simplify the experience or extend functionality

[eurekafag]

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

<...>

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.

<...>

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 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.

[FreeMoney]

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.

[Anonymous]

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

<...>

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.

<...>

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 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.

That is more like rapidshare than bittorrent.

[eurekafag]

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?

[Anonymous]

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.

[harding]

We SHOULDN'T pay for little chunks. Just think how such micropayments would overload the entire bitcoin network. Read these fee rules especially the block size part.

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.

[eurekafag]

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.

[FreeMoney]

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.

[theymos]

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.

[harding]

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.

[eurekafag]

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.