Jump to content

BTIH Magnet URI support


Xilon

Recommended Posts

Azureus also supports magnet links for downloads, of the form magnet:?xt=urn:btih:IJBDPDSBT4QZLBIJ6NX7LITSZHZQ7F5I, which means you don't even need the .torrent file to start a download, instead Azureus will fetch the torrent from other peers on the DDB. The magnet link consists of the prefix magnet:?xt=urn:btih: and the base32() encoded SHA1 of the torrent's info dictionary (known as torrent-hash). Please note that's the base32-encoding of the torrent-hash's binary (20byte) representation, not the hexadecimal representation.

It seems that the mainline client doesn't support this feature but it would be great if uTorrent did. I don't think that this feature would be specific to Azureus's DHT implementation so it should be ok to implement it.

btw. since the btih is a bas32 encoded SHA1 hash does that mean that it would be the same as xt=urn:sha1 ? or is that sha1 a differently encoded? Because that would really make it easy to conver between sha1 and btih. This has no relevance to uTorrent though :P

Link to comment
Share on other sites

Wats up Xilon, great to see you here. You and Lee indirectly got me coming here as you really promoted uTorrent over at PeerWeb. I just like you also know the many uses of Magnet Uri's, and encourage uTorrent to support it. It's is a simple link, so a site saves some bandwidth from constantly uploading/ downloading a torrent file. I beleive mini-nova uses the Azureus Magnet link aswell, click it and Azureus automatically runs it.

Related Spec's and what not can be found here:

Magnet Spec

Link to comment
Share on other sites

btw. since the btih is a bas32 encoded SHA1 hash does that mean that it would be the same as xt=urn:sha1 ? or is that sha1 a differently encoded? Because that would really make it easy to conver between sha1 and btih. This has no relevance to uTorrent though :P

Because of the extensive use of urn:sha1: hashes to define an entire file rather than the info hash of a torrent (look at gnutella networks for examples), it is considered reserved for purposes of magnets, which is why urn:btih: is used instead.

Because of the current differences between the DHT implementations (mainline vs azureus) and the fact that µTorrent uses mainline's DHT, I wouldn't expect support for magnets for a while.

Link to comment
Share on other sites

  • 2 years later...
The magnet link consists of the prefix magnet:?xt=urn:btih: and the base32() encoded SHA1 of the torrent's info dictionary (known as torrent-hash).

So its impossible to find a torrent if you know only the "file-hash"??

Do one need to know the torrent-hash to find a swarm(if you know the file-hash)?

A good magnet link should consist of all the file-hashes one wants to download, thats the idea of magnet links... A "torrent-hash" only confuses ppl... and makes everything complicated again... its the same as having a torrent file... first you need to find a updated(torrents live approx 1 week) search engine to find a torrent containing the file you want...

And because torrents are short-lived a torrent-hash-magnet-link is worthless in one month... We need a decenteralised method to find torrents containing a specific file!!!!

Only then can we create a DB with good bitprints that works exactly as good next year as it works today...

Plz give me a link to a better place to discuss the concept of magnet links...

Maybe its a discussion in the torrent-spec forums on how to find torrents with the DHT when one know the file-hash.

Link to comment
Share on other sites

  • 4 weeks later...

It does... for TORRENTS. File-based hashing is not what uT does.

http://bittorrent.org/beps/bep_0009.html is the spec for which uT is able to get the torrent data to download the .torrent file without actually having downloaded it previously (useful in places where MIME type or general access to these files online is restricted. Please don't post in here again unless you have something else to contribute.

Link to comment
Share on other sites

  • 4 weeks later...

Hi,

can somebody give me a hint on how to set µTorrent up with magnet links from several websites? I've tried it the way it was meant for Azureus (see here), put the magnet protocol in the Windows registry and of course changed the path accordingly to the utorrent.exe, but that didn't do the trick. Whenever I then click a magnet link, µTorrent pops up with the error message (latter part translated from German, so it might be different in another Windows language):

µTorrent

Unable to load "magnet:?xt=urn:btih:<somehashhere>": The syntax for the file name, directory name or volume name is wrong. !

(The <somehashhere> part of course being the corresponding hash from the magnet URI)

Is there a way to make this work? For some torrents I could only find magnet links on certain websites, along with an "alternate download" link via usenext or alike or with a link to another torrent search website where that specific torrent was not available anymore.

Sure, it's a minor annoyance, especially since entering the magnet URI in "Add Torrent from URL..." menu does work, but it would still save some steps of copy&paste. :-)

Oh, yeah, µTorrent 1.8 built 11468 on WinXP SP2 in German.

Link to comment
Share on other sites

  • 9 months later...

A magnet link in base32 format does not start.

If I instead use the 40 character info hash all torrent data is fetched immediately and the download of the files begins.

I even tried adding a tracker in the base32 magnet. It finds 1000's of peers but never fetches the torrent data. (waited for hours and tried multiple times to confirm. The 40 char info hash started to download in 5 seconds every time as a comparison)

So there is possibly a small bug downloading the torrent data when using the base32 in the magnet.

Sorry for Swedish print screen:

http://img42.imageshack.us/img42/4244/magnetlinkbase32notstar.jpg

Link to comment
Share on other sites

Thats the thing, The index hash repeatedly started in about 5-10 seconds while the base 32 magnet for the same torrent never started. I waited more than 10 minutes each try. And I tried 5-7 times... I alternated my tests using base 32 first, then the 40 char string, then the base32 in case the peers was stored in cache between the different formats.

Thats why I suspected that a base 32 string is handled falsely internally. It finds a lot of peers but never get to download maybe because it tries to request the file using the base 32 string as the 40 char info hash. And that could be a classical error, using wrong data in a request.

But if it works for you maybe I was just (repeatedly) unlucky finding a peer that sent me the file.

This is no big deal, the correct magnet hash is the 40 char info hash(According to http://bittorrent.org/beps/bep_0009.html), and this one always worked for me.

Link to comment
Share on other sites

In any case thanks for the report. Unfortunately it looks OK here, with more comments maybe not. If you can find another instance of this, please feel free to share. Diligence helps keep things working especially with this round of dev coming closer to an end. Don't want something blocking either 1.8.3 or 1.9 line.

Link to comment
Share on other sites

  • 1 year later...

Huge bump here, but could it be possible to fetch all the data (name, comment, files in torrent, etc, etc) without starting to download it.

I use feature 'Don't start torrents automatically' but I would like to know what I'm downloading (in case of only the magnet) before it starts requesting pieces.

- Jeroen

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...