4/29/2023 0 Comments Tribler anonymityThis is a vicious circle: Tribler users don't seed because no one pays them for seeding, because there is no incentive for Tribler users to download from other Tribler users. The result is, hidden seeding does not help with recuperating the bandwidth tokens user spent for anonymous downloads, further breaking Tribler token economy. The reason is: BitTorrent protocol prefers the □️fastest □️ seeds, but hidden seeding is always □slower □ than direct seeding. Unexpectedly, the seeding ratio of the hidden torrent will always be near-zero. When a Tribler starts seeding a torrent in "hidden seeding mode", the torrent will only be available through exit nodes. Receiving UDP over SOCKS is broken in Libtorrent One possible solution is to stop showing balances altogether and instead, show the user's relative ranking. There is another problem adding more complexity to the issue: when someone from outside the Tribler network exchanges traffic with a Tribler hidden seeder, or just an anonymous downloader, the traffic leaving the Tribler network will never be paid back, ultimately making the economy deflatory.Īnd no, the simple solution of prioritizing Tribler peers will destroy performance: instead of a hundred fast peers, we would use a single slow one. And negative numbers piss off people, incentivizing them to either stop using Tribler, or just regularly delete their identities to whitewash their balance. The result is, exit nodes become "supermassive black holes" of Tribler economy, constantly dragging regular users to a negative balance. Essentially, exit nodes act the role of super-seeds for the network, but they never spend their tokens. The problem is, 99.99% of seeds are non-Tribler, meaning that exit nodes pay no one. When Tribler downloads something through an exit node, the user pays it the corresponding amount of bandwidth tokens. Here are the reasons: □️ The exitnode blackhole problem □️ Token economyĬurrently, our token economy does not do anything useful, but instead just perplexes the users and annoys the developers. Supporting it will touch every part of Tribler codebase, as 20 bytes hashes size is hardcoded and expected everywhere. LibTorrent 2.0 is actively pushing BitTorrent 2.0 standard, which moves to a more secure, 32-byte SHA-256 hash. The problem is exacerbated by Libtorrent's bad performance when using uTP. The solution is to implement a shim IPv8 tunnels - SOCKS endpoint in a lower-level language. The reason is slow data exchange between Python lower-level libraries. The reason is Python copies strings on slicing, resulting in useless waste of memory and CPU cycles( solved). Performance is very, very bad compared to VPNs: we do 5 MBytes/s at best and 0,5 MBytes average for an overseeded torrent on a fast modern PC, while a typical VPN (such as Wireguard) will use the whole bandwidth available to the host (about 20-80 MBytes/s). Our anonymous tunnels code is implemented in Python (though the crypto library is low level). ![]() ![]() However, this could result in non-technical problems ©️ □♂️ □ Slow tunnels performance □ One solution to this problem could be caching or performing DHT requests on exit nodes on behalf of tunnel users. The result is half-dead impaired torrent info fetching and unreliable health info. The problem is Tribler DHT requests are all sent through exit nodes, which may look like a single node to DHT peers, triggering spam control. Different clients employ different criteria for detecting DDOS attempts. To solve this problem, BitTorrent libraries use spam control methods, blocking peers that send too many requests. Mainline DHT is susceptible to various types of attacks, including DDOS. □ DHT calls blocked over tunnels □īitTorrent uses Mainline DHT to find nodes that seed an infohash. Solutions for these are obvious, but we never put enough effort into these, because we never had enough qualified manpower. I inform you that all the low-hanging fruits are gone, only the hard ones remain. We tended not to tackle those in fear of bogging down our understaffed team, focusing on "low-hanging fruits" instead. ![]() Also, we've cut down on every non-essential feature, focusing development on two things only: metadata delivery and anonymous downloads.ĭuring this journey, we identified a number of technical and scientific problems that block the Tribler project from reaching its goals. We radically updated Tribler codebase, established a robust code architecture and brought code support up to industry standards. Over the last few years, we successfully solved every major technical problem inherited from previous Tribler dev generations.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |