P2P filesharing client featuring BTC micropayments?

[Fakeman]

I'm not sure if someone has thought of this already, but say somebody creates or modifies an existing file sharing program (e.g. a torrent client) to incorporate a BTC client. Basically you would bribe seeders with micropayments per % of the file or directory to let you jump the queue over those who bid less (or nothing). The seeder could also set a minimum bid to download. This would provide much more of an incentive to seed rare/old files, and would provide an alternative to mining for those with a lot of storage space but insufficient GPU power to mine. Of course those who host copyrighted files would have to worry about lawsuits etc, but such people take the same risk anyway for no financial gain. In light of that it might make sense to choose a platform that already incorporates some security features.

Disclaimer: I don't personally have any coding skills or much understanding of the technical details of how to do this.

[1714178831]

1714178831

[1714178831]

1714178831

[1714178831]

1714178831

[Fakeman]

Bad idea? Wrong forum? Help me out here.

[kokjo]

BAD IDEA! file sharing is only ethical as long seeders does not profit from it. /opinion

better idea: make btc donations, to movies you like, and give it to the media industry.
then you can argue that the media industry profit from file sharing, and it is un-ethical of them suing file shares.

and its the wrong forum, find some pirate forum next time.

[Fakeman]

So this is not the right forum to propose software projects relating to bitcoin?

[Sukrim]

I already thought of this, but rather using Mining shares as micropayments, so the adoption rate can be lower.

The only hurdle I still see is how to reliably shape traffic in clients.


My idea is a Vuze plugin that includes a Java-OpenCL (GPU/CPU) miner, a (list of) pool(s) and worker accounts there and a small rpc server to relay the getworks. Also a little bit of extra communication would be neeed to check if someone else has this plugin.

After this, you could then offer for example 1 kB/s guaranteed upstream for 1 hour to any IP that submits a valid share (maybe even with an IP address as "user", so someone can use a different IP to mine for his server or something). Your upload bandwidth could also be proportionally split between everyone who submitted a share recently (timing out after ~ 1 hour again).

Advantages:
Miners are open source and NO wallet or client is needed
Instant "transactions"(!) - no need to wait ~10 minutes to start downloading
No copy-pasting of addresses, all mining etc. can be done automatic by the plugin in the background
Micropayments are otherwise not really possible in BTC (1 difficulty1 share is worth ~0.000035 BTC currently afair)
There's no need to know anything about Bitcoin if you just want to gain better speeds. If you want to offer this traffic sharing to others too, all you need is an account on a pool and a wallet (if there are automatic payouts + PPS like with eligius that's it already!)


Edit:
Filesharing != loading movies

[joepie91]

BAD IDEA! file sharing is only ethical as long seeders does not profit from it. /opinion

better idea: make btc donations, to movies you like, and give it to the media industry.
then you can argue that the media industry profit from file sharing, and it is un-ethical of them suing file shares.

and its the wrong forum, find some pirate forum next time.

It's pointless to try and kill a discussion about something controversial like filesharing.

It exists, it's part of almost everyones life in one way or another, deal with it. Don't try to shut up discussion about it, rather engage in conversation. Keeping quiet about something has never solved a problem.

This discussion is Bitcoin-related, so I don't see how it doesn't fit on here.

[kokjo]

So this is not the right forum to propose software projects relating to bitcoin?

i think it should be in a pirate forum, i does self pirate alot.
what you are talking about is using bitcoin as a normal currency, which i am very happy about.
but my opinion about what should and should not be on this forum is:
things that are bitcoin related: clients, experimental-exchanges, e-wallets, blockexplore, and that kind of stuff.
and not what uses bitcoin as a normal currency, you should go out to other forum and bring bitcoin to them.

spread the coins, do not keep them in this forum.

[kokjo]

and its the wrong forum, find some pirate forum next time.

It's pointless to try and kill a discussion about something controversial like filesharing.

go spread the bitcoin to the pirate forums! im a sharer too:D

[mouse]

Regardless of the p2p aspect, you need to consider what is meant by 'micropayment'.

Normally when sending BTC there are no transaction fees. However, micropayment BTC is not 'normally'. BTC is designed to stop 'spammy' transactions, and it quite likely that micropayments in a p2p filsharing application will look 'spammy'.

Sources of fees:
Amount of BTC
Depending on which version of the client (and others) you are running, the minimum amount you can send is either 0.01 or 0.005 BTC, before you incur a fee of the same value.

Transaction size
In an application like you are proposing people will naturally send and receive many small payments. When trying to spend these coins they are added up and will make the size of the transaction large. A fee is always required for large transactions and are based on the size in kilobytes. Remember a standard fee is either .01 or .005 depending on your client version.

If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.
If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.

Number of confirmations
If coins are quickly respent (highly likely given people who share a lot of files) they will have very low number of confirmations. This will push them back in the priority list of free transactions, meaning you may have to wait a long time for them to confirm, unless you pay more fees. Waiting a long time means you cant spent them, hindering those who share a lot of files.

Read about transaction fees here:
https://en.bitcoin.it/wiki/Transaction_fee

In short, I don't think that BTC will be usable for very small microtransactions. However, is *may* work ok with much larger blocks of data, however you will still need to work out an agreement where the user really does get the data they paid for if they pay first, or the user honors their agreement to pay after they get the data, if they download first. I can't see how you'd enforce this.

[Fakeman]

Would some of those problems potentially be solved by starting a new blockchain especially for the purpose (Filecoin?) That might also address the "bad press for bitcoin" issue to some degree. Will have to read up on BTC transaction fees as I have only a very vague grasp of the behind the scenes workings. Sukrim's proposal of paying by mining rather than coins is also interesting and seems to keep things simpler in some ways.

Another thing that could be interesting would be an automated system for paying someone in coins or mining shares to recode a video file in a lower resolution not available elsewhere on the network already (e.g iPod format). The transcoding could also be done by powerful GPUs. Say I have a decent GPU but my ISP charges huge amounts for net traffic. I then use the GPU to mine and pay someone who has the high res version to transcode, enough that the GPU time he spends is earning him more than he would just mining directly.

[Sukrim]

In short, I don't think that BTC will be usable for very small microtransactions. However, is *may* work ok with much larger blocks of data, however you will still need to work out an agreement where the user really does get the data they paid for if they pay first, or the user honors their agreement to pay after they get the data, if they download first. I can't see how you'd enforce this.

As I wrote, solved shares from mining are worth very small (if PPS: fixed) amounts of Bitcoin and are obtainable by anything with a CPU. It's unfair towards mobile phones and people with very weak GPUs though, but that's life.

You could also accept BTC additional to mining shares (to have some kind of small credit) which could be ok for small stuff as well.

[Fakeman]

The more I think about it, your proposal might easily be the most practical way of getting this working.

[mouse]

I also like your idea, but I don't think it's as easy as that. I'm assuming that the system can be used for sharing copyrighted material. This might not be agreeable with the pool operators. Also, your essentially pushing the cost of transaction onto the pools who have to support very large amounts of client and all that communication all submitting tiny amounts of shares. I imagine they might start bringing new policies to counter this.

But I could be completely wrong.

[Fakeman]

That's a good point, but would there be a way for each seeder to operate sort of a sub-pool so that any pool they are ultimately submitting shares to doesn't have to deal with those details?

[kokjo]

when seeders get profit from sharing files, they will very angry.
seeding should be non-profit. the btc should go to the movie industry as a optional donation.

it is ethical wrong that someone else is gaining profit, for other peoples work.
i have no problem with non-profit file sharing. i seed my self. (not much 70kb/s)

[Sukrim]

I also like your idea, but I don't think it's as easy as that. I'm assuming that the system can be used for sharing copyrighted material. This might not be agreeable with the pool operators. Also, your essentially pushing the cost of transaction onto the pools who have to support very large amounts of client and all that communication all submitting tiny amounts of shares. I imagine they might start bringing new policies to counter this.

But I could be completely wrong.

A pool operator wouldn't see what you are really doing there. All he sees is some getworks requested by you and the answers being fed back from you. If it is really YOU who is solving them or anyone else is undetectable (and also irrelevant).

Some pools already require you to have a certain balance before paying out, do payouts automatically after reaching a certain treshhold etc.

My system would give a bit more trust to the pools (which they anyways have, usually) and use them as a "virtual wallet" collecting these tiny amounts of BTC and storing them until they get paid out in a bigger transaction.

A system like this would also be great for seeding more rare content. Just solve a few shares for me and I'll seed these critical missing pieces again to the swarm even though the torrent might not be on high priority atm.

That's a good point, but would there be a way for each seeder to operate sort of a sub-pool so that any pool they are ultimately submitting shares to doesn't have to deal with those details?

Yes, all you need to do is to fetch a getwork JSON object from a pool, offer it to anyone else who connects to you and send the reply(s) back to the pool. As soon as the pool accepts the share, you also send the "accepted" message to the person mining for you and credit him accordingly. There are already a few implementations for exactly this case available (to seamlessly switch between pools for example and provide failover, monitor your own miners etc.) and proven. All that needs to be added is a different/additional consequence of a submitted share (not just incrementing a counter to paint a graph but also to change a switch in a eMule/BitTorrent/traffic shaping client).

the btc should go to the movie industry as a optional donation.

Could be done easily as well, if you want to do that... As I usually don't load anything that concerns anyone in the movie industry via BitTorrent (unless they contribute to the Linux Kernel or World of Warcraft substantially) I personally would do it STRICTLY optional, but what you do with the money acquired after all is your own business.

[Fakeman]

It's also worth noting that content creators who already accept bitcoin donations and distribute by torrent could use a system like Sukrim's to get paid by people who might not otherwise donate "real" money and have no real interest in getting set up to mine for themselves.

[Sukrim]

It does not even have to be by torrent! My big dream is a Bitcoin financed Rapidshare alternative without any arbitrary limitations like waiting time between downloads, no segmented downloads etc.

There would be a free portion of the available bandwidth and everyone who submits shares or buys credits can then get an additional certain bandwidth for a certain time guaranteed (for example: 1 share = 1 kB/s for 1 hour).

Just pay for the bandwidth you want to have either via Bitcoin or mining shares (can even be accumulated over time) and start downloading right away. As the really expensive part is anyways traffic, you could even offer bindings to (at least) BitTorrent and ed2k via magnet links, if some people prefer P2P. Both protocols also can download via HTTP afaik, so the same system would work there as well (you can choose to pay for a seeder just for you).

As the whole thing should be Bitcoin financed, there would be no need for ads or other stupid stuff. It might even be possible to throw together a nice GUI for a miner that is hardwired to that site!

The only thing I'm missing currently are easily scriptable QoS/traffic control/traffic shaping programs (which run on other platforms than Linux too...). The best I found till now seems to be http://www.freenet.org.nz/python/pyshaper/ - maybe you know some alternatives? I'd be especially interested in having a more "integrated" approach, ideally a general python module/library. Shaping would most likely need to be done anyways just for outgoing transactions.

[joepie91]

It does not even have to be by torrent! My big dream is a Bitcoin financed Rapidshare alternative without any arbitrary limitations like waiting time between downloads, no segmented downloads etc.

There would be a free portion of the available bandwidth and everyone who submits shares or buys credits can then get an additional certain bandwidth for a certain time guaranteed (for example: 1 share = 1 kB/s for 1 hour).

Just pay for the bandwidth you want to have either via Bitcoin or mining shares (can even be accumulated over time) and start downloading right away. As the really expensive part is anyways traffic, you could even offer bindings to (at least) BitTorrent and ed2k via magnet links, if some people prefer P2P. Both protocols also can download via HTTP afaik, so the same system would work there as well (you can choose to pay for a seeder just for you).

As the whole thing should be Bitcoin financed, there would be no need for ads or other stupid stuff. It might even be possible to throw together a nice GUI for a miner that is hardwired to that site!

The only thing I'm missing currently are easily scriptable QoS/traffic control/traffic shaping programs (which run on other platforms than Linux too...). The best I found till now seems to be http://www.freenet.org.nz/python/pyshaper/ - maybe you know some alternatives? I'd be especially interested in having a more "integrated" approach, ideally a general python module/library. Shaping would most likely need to be done anyways just for outgoing transactions.

This... actually sounds feasible.