Bitcoin + BitTorrent integration discussion.

[gubatron]

Last week we started a conversation on the BitTorrent Developer community about the possibilities of integrating BitCoin on BitTorrent clients.
http://torrentfreak.com/bittorrent-client-devs-work-on-bitcoin-integration-131213/

Our initial intention was to start with something very simple which would allow BitTorrent users to send donations/tips to Content Creators willing to share their content on the BitTorrent network. We think this can be done simply by adding a new metadata field on the .torrent file which would specify the destination BitCoin address and optionally a suggested BTC amount.

It was easy to see that a lot more could be done when you put together an open P2P filesharing protocol along with an open P2P Cryptocurrency.

Immediatly the conversation evolved to the following:

1. "The trackers/index sites could tamper the .torrents to steal the donations, what about adding tracker donation support?"
So that meant an extending the "announce/scrape/update" BitTorrent Protocol message responses by BitTorrent tracker so they can also include their BitCoin addresses.

Then the conversation opened up to having a simplified BitCoin wallet in the BitTorrent client to simplify donations, this way the user doesn't need to leave the app to make a donation, and when that happens, a world of possibilities is opened up, the most interesting being:

2. BitTorrent + BitCoin as a technology toolset on which on-demand content delivery services (think a Netflix/Spotify competitor) could have solid building blocks to manage content delivery and billing, no matter the country on which customers are. All .torrents provided by the service would be tagged with Bitcoin addresses made specifically for each piece of content, and user account balances would be loaded in either Bitcoin (if the country allows) or in a local currency (and it's then up to the service provider to convert the local currency to BTC and keep everything uniform in Bitcoin deep in the system).

3. Seeding for Bitcoin. This is one of the most controversial ones, and Matt Blue (bitcoinj developer) suggested this could be achieved with Micro-payment channels
https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments - The idea is that when seeders announce themselves to trackers they send along their Bitcoin addresses, if a user is experiencing a slow download, the user can specify a certain amount of bitcoin to pay willing seeders for a unit of transfer (to be discussed, bittorrent chunk, byte, megabyte, transfer rate?). Seeders would see the bidding requests and send the pieces to the highest bidders, once the contract has been fullfilled between seeder and downloader, the seeder could request the earned BTC and not send another piece until the micropayment is received. In this process the tracker could also be involved as an escrow and get a small processing fee.

Point number 3 requires bringing experienced Core BitTorrent Protocol developers and Core BitCoin Procol developers together, I was suggested to bring the conversation over here for feedback.

Thanks for your time.
Angel.

[1715088777]

1715088777

[mmeijeri]

Maybe better integration with BitTorrent would be useful for initial downloads of the blockchain too.

[mmeijeri]

I like to dream that the various P2P networks will start sharing protocol layers. Micropayments for seeding would be an example, others have imagined similar things for routing between meshnets. All could use a common basic overlay layer that robustly exchanges addresses of nodes and broadcasts low latency messages.

[lightcoin]

OP - have you heard of the Bittunes project? Seems very much line with what you're proposing.

www.bittunes.org

[xkeyscore89]

This is a great idea and if implemented, would serve to further decentralize BTC.

[domob]

That sounds interesting!  The Namecoin community has also been discussing lately about possibilities for implementing a Torrent tracker / TPB-like directory of magnet links with Namecoin.  This would ensure censor-ship resistance for directories of Torrents (like a searchable directory of Wikileaks documents).  No one there is an expert about how Bittorrent works, but our understanding is that the DHT implementation used makes trackers in the classical sense irrelevant, but does not allow searching / browsing for Torrents whose magnet links are not yet known.  This is the piece that could be implemented by Namecoin.  This could possibly be coupled with BTC/NMC donations to monetise content, as you suggest.  You can take a look here: https://dot-bit.org/forum/viewtopic.php?f=5&t=1381

[phelix]

My prediction: In the not so distant future most home media distribution will take place via p2p systems with data uploaded by the creators themselves who get paid by donations (in addition to concerts an movie theater monetization).

Seriously, I don't see any other way it could happen. Industry #2: prepare for impact.

 

Explanation: Why would the creators themselves seed there hard work? If they don't the warez guys will get all the donations.

[williamj2543]

Maybe better integration with BitTorrent would be useful for initial downloads of the blockchain too.

Hey,
I don't think that would help much. From what I know the block chain isn't limited at all, and I think it would download at at leats 5 mb/s. Most torrent files will never get a speed above 5mb/s, and the max I have seen is 2.2mb/s. I think that it would just make things slower and more complicated.

[mmeijeri]

Last week we started a conversation on the BitTorrent Developer community about the possibilities of integrating BitCoin on BitTorrent clients.
http://torrentfreak.com/bittorrent-client-devs-work-on-bitcoin-integration-131213/

Do you have a link to the discussion itself? The link you gave points to an article about it, but not to the actual discussion.

[mmeijeri]

I don't think that would help much. From what I know the block chain isn't limited at all, and I think it would download at at leats 5 mb/s. Most torrent files will never get a speed above 5mb/s, and the max I have seen is 2.2mb/s. I think that it would just make things slower and more complicated.

I'm not familiar with the details, but see this thread:

[ANN] Bitcoin blockchain data torrent

[murfshake]

I got chills reading this post, man.  Could change the world.

[amincd]

Hey Gubatron, it's nice to see your post on Bitcointalk.

I'm willing to contribute to a bounty on this.

[Matt Corallo]

Then the conversation opened up to having a simplified BitCoin wallet in the BitTorrent client to simplify donations, this way the user doesn't need to leave the app to make a donation, and when that happens, a world of possibilities is opened up, the most interesting being:

In general, this is a bad idea. Holding Bitcoins on an individual's computer in nothing more than a file with the private keys on it is a terrible, terrible idea (think: malware, drive crashes, etc). Yes, its true that most desktop wallets do it today, but they're moving away from that direction (hardware wallets, offline cold storage, etc). If you move the wallet into a torrent client, you now have to put in as much effort as other wallet creators to ensure security (hint: thats a hard problem, and if you think users are going to listen to your instructions and only move some small amount into their torrent client, you havent met users...). Additionally, users may end up having to pay transaction fees to move bitcoins from their wallet to their other wallet (terrible UX, in fact, just making users move coins between applications itself is a terrible UX). There are better options, and wallets already expose the ability to make payments. As for more advanced features, I think we'll see those being exposed by the wallets to third-party applications (Bitcoin Wallet on Android will hopefully soon support any application opening up micropayment channels).

2. BitTorrent + BitCoin as a technology toolset on which on-demand content delivery services (think a Netflix/Spotify competitor) could have solid building blocks to manage content delivery and billing, no matter the country on which customers are. All .torrents provided by the service would be tagged with Bitcoin addresses made specifically for each piece of content, and user account balances would be loaded in either Bitcoin (if the country allows) or in a local currency (and it's then up to the service provider to convert the local currency to BTC and keep everything uniform in Bitcoin deep in the system).

I may be missing something, but I fail to see how integrating them directly allows for this more than simply using both does? Today, its relatively easy (well, ok, maybe not, but possible) to charge someone for access to your content and then allow downloads assisted by Bittorrent-style downloads (eg WoW).

3. Seeding for Bitcoin. This is one of the most controversial ones, and Matt Blue (bitcoinj developer) suggested this could be achieved with Micro-payment channels

Thats me, for reference.

https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments - The idea is that when seeders announce themselves to trackers they send along their Bitcoin addresses, if a user is experiencing a slow download, the user can specify a certain amount of bitcoin to pay willing seeders for a unit of transfer (to be discussed, bittorrent chunk, byte, megabyte, transfer rate?). Seeders would see the bidding requests and send the pieces to the highest bidders, once the contract has been fullfilled between seeder and downloader, the seeder could request the earned BTC and not send another piece until the micropayment is received. In this process the tracker could also be involved as an escrow and get a small processing fee.

Bitcoin doesn't generally support micropayments directly (ie you cant make one-off micropayments very easily without a trusted third-party). The micropayment channels implemented there depend on the idea that A has a long-term relationship with B where neither trust each other to provide service and thus A pays B in tiny increments as B provides service, adding up to some reasonably-seized payment (Bitcoin supports small payments, just not high-volume micropayments). Thus, really the only way to implement this is to have peers make micropayment channels between each other and pay for transfer as blocks/MB/whatever are provided. Not sure it would be worth it for average peers (too much transaction cost/overhead for many peers), but it may be interesting for high bw peers to provide payment as an option.

Point number 3 requires bringing experienced Core BitTorrent Protocol developers and Core BitCoin Procol developers together, I was suggested to bring the conversation over here for feedback.

While we are always open to collaborating, we (bitcoinj devs) hope that the micropayment implementation provided allows pretty well anyone to implement micropayment channels .

[amincd]

Thank you for your input Matt Corallo

[amincd]

https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments - The idea is that when seeders announce themselves to trackers they send along their Bitcoin addresses, if a user is experiencing a slow download, the user can specify a certain amount of bitcoin to pay willing seeders for a unit of transfer (to be discussed, bittorrent chunk, byte, megabyte, transfer rate?). Seeders would see the bidding requests and send the pieces to the highest bidders, once the contract has been fullfilled between seeder and downloader, the seeder could request the earned BTC and not send another piece until the micropayment is received. In this process the tracker could also be involved as an escrow and get a small processing fee.

Bitcoin doesn't generally support micropayments directly (ie you cant make one-off micropayments very easily without a trusted third-party). The micropayment channels implemented there depend on the idea that A has a long-term relationship with B where neither trust each other to provide service and thus A pays B in tiny increments as B provides service, adding up to some reasonably-seized payment (Bitcoin supports small payments, just not high-volume micropayments). Thus, really the only way to implement this is to have peers make micropayment channels between each other and pay for transfer as blocks/MB/whatever are provided. Not sure it would be worth it for average peers (too much transaction cost/overhead for many peers), but it may be interesting for high bw peers to provide payment as an option.

Correct me if I'm wrong, but aggregating payments through the tracker could reduce the number of micropayment channels needed, with the tracker having one payment channel to each seed, allowing payments from the tracker to the seeds, and each peer having a payment channel to the tracker, allowing them to pay the tracker, so that when a peer wants to pay a seed, he first pays the tracker, and the tracker then pays the seed, through the already existing payment channels.

Given the payment is made incrementally, the benefit for the tracker to steal the funds would be limited to the size of the increments. As soon as the tracker starts cheating (stops paying forward the peer's payment), the peer would stop making payments to the tracker. All the cheating tracker would get is the increment (1000 Satoshi or whatever), which could be less than the commission they would earn if they behaved honestly.

[Matt Corallo]

Correct me if I'm wrong, but aggregating payments through the tracker could reduce the number of micropayment channels needed, with the tracker having one payment channel to each seed, allowing payments from the tracker to the seeds, and each peer to could have a payment channel to the tracker, allowing them to pay the tracker, and then when a peer wants to pay a seed, he first pays the tracker, and the tracker then pays the seed, through the already existing payment channels.

Given the payment is made incrementally, the opportunity for the tracker to steal the funds would be limited to the size of the increments. As soon as the tracker starts cheating (stops paying forward the peer's payment to the seed), the peer would stop making payments to the tracker. All the cheating tracker would get is the increment (1000 Satoshi or whatever), which could be less than the commission they would earn if they behaved honestly.

True, that could be a potentially be a less expensive protocol. It is less neat and does remove some anonymity in payment, but its likely not realistically different given a hostile attacker trying to identify people. It does, also, require significant error-checking on all sides to handle various parties trying to rip each other off (using a different tracker, opening a p2p channel?).

[amincd]

Angel, what kind of assistance do you need to get Bitcoin integrated into the Frostwire client and/or torrent file, and which of the various ideas you touched on do you see holding the most potential?

[amincd]

I like to dream that the various P2P networks will start sharing protocol layers. Micropayments for seeding would be an example, others have imagined similar things for routing between meshnets. All could use a common basic overlay layer that robustly exchanges addresses of nodes and broadcasts low latency messages.

BTC would allow other P2P protocols like HTTP and Bittorrent to fully realize their potential. There's never been a digital p2p economic layer until now.

[mmeijeri]

Any updates on this?

[Mabsark]

That sounds interesting!  The Namecoin community has also been discussing lately about possibilities for implementing a Torrent tracker / TPB-like directory of magnet links with Namecoin.  This would ensure censor-ship resistance for directories of Torrents (like a searchable directory of Wikileaks documents).  No one there is an expert about how Bittorrent works, but our understanding is that the DHT implementation used makes trackers in the classical sense irrelevant, but does not allow searching / browsing for Torrents whose magnet links are not yet known.  This is the piece that could be implemented by Namecoin.  This could possibly be coupled with BTC/NMC donations to monetise content, as you suggest.  You can take a look here: https://dot-bit.org/forum/viewtopic.php?f=5&t=1381

Your understanding is correct. The DHT just replaces the tracker functionality, not the indexer functionality. I'm not sure how Namecoin could help with that part though. The indexing pretty much just needs a 20 byte info hash (usually in the form of a 40 char hex string, but it can be base32 as well) and a description. Note that the info hash is not the hash of a .torrent file, it's the hash of the value of the "info" key within that .torrent file, hence the name.

Turning an info hash into a magnet link is simple, just prefix the info hash with "magnet:?xt=urn:btih:", the other parameters are optional.

When you use a magnet link, only part of the corresponding .torrent file is downloaded - the info dictionary - which is the value of the info key previously mentioned.

That's pretty much all there is to know about magnet links.