Bitcoin + BitTorrent integration discussion.

[mmeijeri]

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.

[Mabsark]

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.

[mmeijeri]

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.

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.

I got the impression it was a deliberate decision, perhaps for legal reasons. Technically it's almost trivial to do.

The problem with DHT search is how to deal with the most popular keywords.

Anything caching and replication cannot solve?

[Mabsark]

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.

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.

I got the impression it was a deliberate decision, perhaps for legal reasons. Technically it's almost trivial to do.

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

[gubatron]

Hi Matt, good to see you here

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.

[gweedo]

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

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.

[phelix]

The FrostWire Bitcoin integration has been nominated as Bitcoin project of Winter 2014 - vote now: https://bitcointalk.org/index.php?topic=251087.0