Printable View
Just after I finished implantation of simple Java tracker.
https://blog.libtorrent.org/2020/09/bittorrent-v2/
Interesting !Quote:
libtorrent-2.0 has just been released with a few major new features. One of them is support for BitTorrent v2.
Most of the specification work of BEP 52 was done by the8472. The libtorrent support for bittorrent v2 was mostly implemented by Steven Siloti. BiglyBT also has an implementation of BitTorrent v2 to be released in the near future.
Noob here...Where v2 is better than v1? or which issues under v1, v2 is trying to solve? Google says it's efficiency asscioated improvements eg. torrent file size, and hashing algorithm changes. Anything else big change? At v1 now, upload and download statistics of a peer rely on reporting of its own, whcih makes cheating relatively easy. do v2 improve on this?
And just after I wrote this post :wtongue:Quote:
Originally Posted by illusive
Note how bencoding is still used in v2. It must have been a good and fast choice for its time, but I really resent the fact it's not used by anything outside BitTorrent, and therefore very few parsers and editors for it exist. JSON would probably be better, but as they want to maintain backwards compatibility (which I fully agree with), their hands are tied on this regard.Quote:
Originally Posted by anon
Here's an easy to understand[citation needed] summary.Quote:
Originally Posted by JohnareyouOK
- All usage of the SHA-1 hash function is replaced by SHA-256, since a collision for the former was found three years ago, and therefore it is expected to become more insecure as the processing power available to potential adversaries (e.g. fake torrent uploaders) increases, even if no other vulnerabilities were discovered. Existing tracker and DHT implementations expect the 160-bit length of SHA-1, so the extra 96 bits are discarded to maintain compatibility with BitTorrent v1. Since its bigger digest size isn't the only factor making SHA-256 more secure, this is an acceptable compromise, and does not preclude the possibility of future extensions to accept full-length hashes.
- The use of hash trees makes .torrent files smaller (not life-changing, but nice), allows detecting bad data on a per-block basis (pieces are divided in 16 KB blocks irrespective of their size) which means faster detection of "bad" peers and less wasted bandwidth, and most importantly, since there's a hash tree for each file, it will now be possible to find and share identical files across different swarms with 100% reliability. This last bit of functionality has been attempted over the years, notably by BiglyBT's swarm merging but also in BitComet, Shareaza and TuoTu, yet since all we had to work with were (potentially non-unique) file names and sizes, it relied on assumptions and a little luck. This should improve retention by, in principle, allowing those who have the same files on different torrents to transparently cross-seed to each other, and is a very welcome change as far as I'm concerned. I'm not sure how much private trackers would like such a thing, as it would cause mismatched traffic reports on the torrents involved, similar to what occurs when people cross-seed incorrectly by adding multiple announce URLs and then get banned for "fake upload"... but clients could simply disallow it for torrents with the private flag set.
- Path names inside metadata are deduplicated. For torrents with tons of small files across many subdirectories (unpacked games, image sets) this should result in a big performance boost: smaller .torrent files and less stuff to parse.
- There will be much less leeway regarding non-standard piece sizes or representations of bencoded data, in the interest of following the specification as tightly as possible and avoiding undefined behavior (gray areas), but this is not something that most people will be affected by or even notice.
As for your last question, some background first. The relationship between private trackers and the people who "make" BitTorrent is somewhat complex. Obviously, private torrents are officially supported by BEP-0027, and there is some degree of cooperation between tracker staff and client developers and protocol designers (see the GitHub issues for BiglyBT or qBittorrent regarding whitelists or ghostleeching, for example). Yet at the same time, ratio systems are seen by the latter group as an afterthought that only happens to work more or less well; I mean, it's a small miracle that traffic stats are reported in the first place, since they didn't originally have any specific purpose. And developers don't and shouldn't want to allow a tiny "elite club" to dictate which direction BitTorrent should follow, since statistically speaking, all private tracker peers put together only make a small fraction of the total. Or, as a BiglyBT lead programmer has stated with regards to our Extreme Mod:
Therefore, I don't expect any changes regarding how traffic is reported or peers are authenticated for the foreseeable future.Quote:
I'm not sure what you want us to do about it. We didn't write it, we don't promote it, we can't stop people from using it. Perhaps they could figure out a way to just detect the mod version and only ban that? (unlikely I know)
But if that's the reason, then they must have banned qBittorrent because of its leecher mod too?
If No, then why haven't they? Why single only BiglyBT out when every other open source client has this problem?
There is a solution that would make everyone happy:
Have the tracker owners write up a tracker/peer spec that is spoof-proof and all clients that want to use those trackers can implement it. No more client blacklists or whitelists needed, no more inspecting each new client version for approval -- either the client follows the spec and thus the rules and they are allowed, or they don't follow the spec, and they are banned.
There's more stuff, but I have typed enough for today :gninja:
That's explained so much clear! I didn't know until today private tracker's birth was based on a coincidence, traffic stats are reported, which would have likely never happened.
But another question has surfaced as to why eMule seems to be less hot lately than it was a decade ago, especialy considering that traffic stats reporting was deliberately designed in eMule and hard to cheat. these history stories seem interesting, I'm gonna find some info about. Thanks anon!
While there's been a relative reversal of this due to the recent coronavirus pandemic and lockdowns, all methods of filesharing are "less hot" than they were ten years ago. As it turns out, a large demographic of people resorted to piracy simply because it was easier and faster than acquiring content legally. Netflix, Spotify et al. managed to seize it fairly well with their low flat rate prices, large collections and ease of use. Of course, with streaming services, you never own the content you're paying for, are susceptible to tracking, have to run proprietary software and DRM, and anonymous payments are not possible. But I guess this isn't a perfect world...Quote:
Originally Posted by JohnareyouOK
Anyway, the eD2k network in particular, despite its large size, always had a somewhat niche appeal. If you didn't live in Spain, Italy, or the Asian countries where it held a dominating presence, you were more likely to use it as a last resort for finding obscure stuff and with the understanding that downloads would take time. Also, its dwindling servers had a more central role, as they supplied both peers and search results (but a lot of people ditched them entirely in favor of Kad, so it's not really clear whether their steady disappearance is cause or consequence of diminished interest on the network, or neither).
Damn anon, you caught that reply on github huh. It made me LMFAO :D
Have another. Apparently we're a reliable source on these matters.
https://github.com/leighmacdonald/mi...cs/CHEATERS.md
Note that there was this one Portuguese tracker which did create their own specification and client...
http://www.sb-innovation.de/showthread.php?t=20766
http://www.sb-innovation.de/showthread.php?t=31061
Nice ! , We have a lot of work to do :smile: