Is it possible that two different seeders that are seeding the same file and provide all other metadata in the torrent file in the same exact manner will produce, by definition, the same info_hash for the torrent.
In this hypothetical everything is the same. The file name, the size of the pieces, the same everything. Just two different people on two different computers, perhaps in two different parts of the world?
Unless I’m not reading your post correctly (yes, it’s very late, where I am), that is exactly how bittorrenting works.
Everyone that is part of the swarm is sharing the exact same content (including the info_hash)… if this was not so, none of the pieces would get past the hash-checks and the task(s) would never complete. Geographical location of each peer’s computer is not relevant to the completion of any specific task.
I suspect you didn’t ask the question you meant to ask, somewhere in there. Instead of two seeders, I suspect you meant two torrent-creators.
This is not a new idea or question in the field, about which guys do doctoral dissertations.
The bittorrent info-hash calculation includes the date and time, down to the second, at which the torrent was created.
While it is theoretically possible that two files could have the same hash value (known as a “hash collision”), cryptographic hash functions are designed so that the probability of this event is a practical impossibility – even if an expert is intentionally looking to find two files with the same hash value. In other words, you are much more likely to be probed by aliens than to find a hash collision between two torrents.
I don’t think this is true kluelos. The infohash is made from only the files you download so if two people make torrents with the exact same material, byte for byte, they will have the same infohash. I’ve had it happen even on private torrents and because of this I’ve found a bug in uTorrent. I found that if I make torrent 1a and upload it to tracker X, then start it and seed it with utorrent, then make torrent 1b using the same source files, upload it to tracker Y, then when I load it in utorrent it will tell me the torrent already exists and ask if I want to combine the trackers. If I decline, the torrent won’t load, if I affirm, it will load two private trackers in one torrent and send the total of ALL upload to both (all) trackers. End result is ratio cheating, unintentional perhaps, but still cheating nonetheless.
I’ve repeated this several times and even posted in utorrents forum to ask them. They didn’t seem concerned, just simply acknowledged that it will send the total upload for all trackers independently to each, so if you have 5 trackers and upload 1gb to each, it will report 25gb upload (5x5gb). I this person reported 5gb upload to one of these trackers that didn’t even have 5gb downloaded, the person would be banned.
Bitcomet introduced a patch for this and when it is forced to combine private trackers due to identical infohash, it will only use the first. If that tracker doesn’t work, it will clear the entire peer list before switching. As far as I know bitcomet is the only client to address this problem.
Its in the release notes, back around 112ish I think.
A workaround (tested to work by me) is to make the torrents with different piece sizes and so the hashes will be different and the client will recognize them as two different torrents. Although this will not be possible if the torrents are already made by others with the same piece size.
And if you’re asking if a seeder from a torrent will help those from the other torrent, it’s theoretically possible by LTSeeding (BitComet proprietary protocol) but only on public torrents. LTSeeding is done file by file, no matter where it comes from, as long as both are public torrents and the peers use BitComet with LTSeeding enabled.
If you research bittorrent info-hash creation, you’ll discover that the infohash is created from the .torrent file – and does not include data from the contents other than indirectly. (Yeah, this took me by surprise too.) The date and time of creation are included in the info-hash calculation, as are the tracker names and ports.
But wait, you think … I did. Then I thought again. Yes, that information CAN be changed. But what about …
Exactly. When is the hash of the .torrent. ever checked? Never.
When I went back and looked, I realized that I had never been told any different. I had just been guilty of making faulty assumptions.
I tested your theory in BitComet and uTorrent and that’s simply not how it’s implemented.
First I made a torrent from BitComet’s executable with a piece size of 32KB and the two open bittorrent trackers
udp://tracker.openbittorrent.com:80
udp://tracker.publicbt.com:80
and another one with only the first tracker and the info hash was identical to the first(6897dc14837fbf9dd5ac882083d52a131230953b). I made a third torrent file with both of the above trackers in the same order as the first and with a different piece size and the info hash was different (0ac0d368d885b223357d2aee77e02076447cd4b3). It was added automatically in BitComet and I added it manually in uTorrent as another task with the same name successfully. I repeated the first task at a later time and the hash was again identical, so the time stamp is also irrelevant.
Try all this yourself and you’ll see.
Guys, just throwing in some water on the fire here… 
The INFO-HASH is called that way because it creates a hash ONLY from the INFO section (dictionary) of the .torrent file.
If you check the specs for BitTorrent you’ll see that the **Info dictionary **contains only these keys:
piece length
pieces
private
and then for,
single-file torrents:
name
length
md5sum
or for multiple-file torrents:
name
file
length
md5sum
path
So,** only these** are the values which should be identical in order for the hashes to be identical.
I haven’t done much testing on this (I’ll leave that to you :)) but it doesn’t seem to be any different so far, from what I’ve read in this post (i.e. other data doesn’t seem to also be taken into account when deriving the info-hash).