The FrostWire Bitcoin integration has been nominated as Bitcoin project of Winter 2014 - vote now: https://bitcointalksearch.org/topic/bps-bitcoin-project-of-the-season-winter-2014-winner-bitwasp-251087
Topic: Bitcoin + BitTorrent integration discussion. (Read 3464 times)
The FrostWire Bitcoin integration has been nominated as Bitcoin project of Winter 2014 - vote now: https://bitcointalksearch.org/topic/bps-bitcoin-project-of-the-season-winter-2014-winner-bitwasp-251087
A question for you Matt (and other bitcoin core devs reading)
Instead of the Micropayments idea, I read that Bitcoin transactions have inputs and outputs and an associated script. If this script returns 0, then the receiving parties don't receive the BTC, however, if the script returns != 0, then the other party does receive the BTC. I was wondering there, if these scripts could be used as contracts between a BitTorrent client that wants to download faster than the rest, It would first look for Bitcoin enabled peers in the swarm, and then start a bitcoin transaction with a script that would serve as a contract, I'm still not sure at which point the scripts are executed, perhaps they could be a function of time offset, but the idea is that the bitcoin paid data transfer could start once the seeders have the contract in hand, once the data is in the hands of the leecher (say a chunk, or maybe even the whole torrent has finished), the leecher would appear in the swarm as a new seed (and perhaps this could be used in the script so the script would return != 0 and the funds can be "released" to the outputs in the transaction).
Instead of the Micropayments idea, I read that Bitcoin transactions have inputs and outputs and an associated script. If this script returns 0, then the receiving parties don't receive the BTC, however, if the script returns != 0, then the other party does receive the BTC. I was wondering there, if these scripts could be used as contracts between a BitTorrent client that wants to download faster than the rest, It would first look for Bitcoin enabled peers in the swarm, and then start a bitcoin transaction with a script that would serve as a contract, I'm still not sure at which point the scripts are executed, perhaps they could be a function of time offset, but the idea is that the bitcoin paid data transfer could start once the seeders have the contract in hand, once the data is in the hands of the leecher (say a chunk, or maybe even the whole torrent has finished), the leecher would appear in the swarm as a new seed (and perhaps this could be used in the script so the script would return != 0 and the funds can be "released" to the outputs in the transaction).
This wouldn't work for two reasons, one scripts are not yet enable, and also contracts don't work like that. I would say micropayments channel is the best way to go in this situation.
Do you have repo where this all being done? A bitcoin branch area? I don't see it in the official frostwire repo.
Hi Matt, good to see you here 
you're absolutely right, this is one of my main concerns, specially with years of experience taking support tickets from our users I see many people somehow managing to delete their wallets no matter how hard we make it for them. But then I saw the Electrum wallet and how you can regenerate your wallet with a seed, can bitcoinj do something like this?
A question for you Matt (and other bitcoin core devs reading)
Instead of the Micropayments idea, I read that Bitcoin transactions have inputs and outputs and an associated script. If this script returns 0, then the receiving parties don't receive the BTC, however, if the script returns != 0, then the other party does receive the BTC. I was wondering there, if these scripts could be used as contracts between a BitTorrent client that wants to download faster than the rest and some seeding peers in the swarm which support bitcoin for data.
FrostWire would first look for Bitcoin enabled peers in the swarm, and then create a bidding bitcoin transaction with a script that would serve as a contract, I'm still not sure at which point the scripts are executed, perhaps they could be a function of time offset, but the idea is that the bitcoin paid data transfer could start once the seeders have the contract in hand, once the data is in the hands of the leecher (say a chunk, or maybe even the whole torrent has finished), the leecher would appear in the swarm as a new seed (and perhaps this could be used in the script so the script would return != 0 and the funds can be "released" to the outputs in the transaction).
I bet there's still a lot there that I haven't gotten right, please correct me in whatever I'm wrong, I'm still very new to the bitcoin protocol.
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...).
you're absolutely right, this is one of my main concerns, specially with years of experience taking support tickets from our users I see many people somehow managing to delete their wallets no matter how hard we make it for them. But then I saw the Electrum wallet and how you can regenerate your wallet with a seed, can bitcoinj do something like this?
A question for you Matt (and other bitcoin core devs reading)
Instead of the Micropayments idea, I read that Bitcoin transactions have inputs and outputs and an associated script. If this script returns 0, then the receiving parties don't receive the BTC, however, if the script returns != 0, then the other party does receive the BTC. I was wondering there, if these scripts could be used as contracts between a BitTorrent client that wants to download faster than the rest and some seeding peers in the swarm which support bitcoin for data.
FrostWire would first look for Bitcoin enabled peers in the swarm, and then create a bidding bitcoin transaction with a script that would serve as a contract, I'm still not sure at which point the scripts are executed, perhaps they could be a function of time offset, but the idea is that the bitcoin paid data transfer could start once the seeders have the contract in hand, once the data is in the hands of the leecher (say a chunk, or maybe even the whole torrent has finished), the leecher would appear in the swarm as a new seed (and perhaps this could be used in the script so the script would return != 0 and the funds can be "released" to the outputs in the transaction).
I bet there's still a lot there that I haven't gotten right, please correct me in whatever I'm wrong, I'm still very new to the bitcoin protocol.
No, it was created for distributed domain name resolution. It doesn't seem like a good fit for torrent indexing to me.
I know, it's only kind of similar.
Quote
The Bittorrent DHT is also based of Kademlia. It just hasn't been officially extended to include search functionality. It's actually extremely simple to add basic search functionality. Look at the "get_peers" query. What the "get_peers" query does is send the torrent info hash to other peers who then basically say "yeah, I've got that" or pass the query on to their neighbour if they haven't. That replicates the tracker functionality.
In order to add search functionality, you need to send keywords to a peer and ask them if they have a torrent with any of those keywords in the torrent title of any of the file/folder names. Any peers with the required torrents would then send back a list of dictionaries with they keywords being keys and the info hashes found from that keyword being the values.
In order to add search functionality, you need to send keywords to a peer and ask them if they have a torrent with any of those keywords in the torrent title of any of the file/folder names. Any peers with the required torrents would then send back a list of dictionaries with they keywords being keys and the info hashes found from that keyword being the values.
I got the impression it was a deliberate decision, perhaps for legal reasons. Technically it's almost trivial to do.
Quote
The problem with DHT search is how to deal with the most popular keywords.
Anything caching and replication cannot solve?
There's nothing illegal about searching for keywords. It's just that nobody could get it working good enough with the protocol. Basically, the problem is that searching for popular keywords would cause a DDoS attack on those unlucky enough to get assigned to handling that keyword due to the way the DHT works. Caching and replication could solve the problem but would require a modified DHT that's also backwards compatible.
Here's a paper on DHT search that might be of some use to you guys, http://infinite-source.de/az/whitepapers/keyword%20search/search-with-bloomfilters.pdf
No, it was created for distributed domain name resolution. It doesn't seem like a good fit for torrent indexing to me.
I know, it's only kind of similar.
Quote
The Bittorrent DHT is also based of Kademlia. It just hasn't been officially extended to include search functionality. It's actually extremely simple to add basic search functionality. Look at the "get_peers" query. What the "get_peers" query does is send the torrent info hash to other peers who then basically say "yeah, I've got that" or pass the query on to their neighbour if they haven't. That replicates the tracker functionality.
In order to add search functionality, you need to send keywords to a peer and ask them if they have a torrent with any of those keywords in the torrent title of any of the file/folder names. Any peers with the required torrents would then send back a list of dictionaries with they keywords being keys and the info hashes found from that keyword being the values.
In order to add search functionality, you need to send keywords to a peer and ask them if they have a torrent with any of those keywords in the torrent title of any of the file/folder names. Any peers with the required torrents would then send back a list of dictionaries with they keywords being keys and the info hashes found from that keyword being the values.
I got the impression it was a deliberate decision, perhaps for legal reasons. Technically it's almost trivial to do.
Quote
The problem with DHT search is how to deal with the most popular keywords.
Anything caching and replication cannot solve?
The DHT just replaces the tracker functionality, not the indexer functionality.
Reading up on this I noticed that the eDonkey network does use the Kad DHT for both indexing and tracking. I'm not sure if trying to build indexing functionality on top of the blockchain is a better solution. It is true that Namecoin was designed precisely for a form of distributed indexing.
No, it was created for distributed domain name resolution. It doesn't seem like a good fit for torrent indexing to me.
The Bittorrent DHT is also based of Kademlia. It just hasn't been officially extended to include search functionality. It's actually extremely simple to add basic search functionality. Look at the "get_peers" query. What the "get_peers" query does is send the torrent info hash to other peers who then basically say "yeah, I've got that" or pass the query on to their neighbour if they haven't. That replicates the tracker functionality.
In order to add search functionality, you need to send keywords to a peer and ask them if they have a torrent with any of those keywords in the torrent title of any of the file/folder names. Any peers with the required torrents would then send back a list of dictionaries with they keywords being keys and the info hashes found from that keyword being the values.
The problem with DHT search is how to deal with the most popular keywords.
The DHT just replaces the tracker functionality, not the indexer functionality.
Reading up on this I noticed that the eDonkey network does use the Kad DHT for both indexing and tracking. I'm not sure if trying to build indexing functionality on top of the blockchain is a better solution. It is true that Namecoin was designed precisely for a form of distributed indexing.
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.
Any updates on this?
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.
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?
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?). 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.
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.
Thank you for your input 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 .
Hey Gubatron, it's nice to see your post on Bitcointalk.
I'm willing to contribute to a bounty on this.
I'm willing to contribute to a bounty on this.
I got chills reading this post, man. Could change the world.
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
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/
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.
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.
Jump to: