>>108570296
>Anonymous
Into the trash it goes. Now grow up

>>108570328
You don't see UDP packets to hundreds of fake DHT peers all using port 6881?

>>108570296
time to stress test some people

>>108570296
qrd?

okay but what can I do about it other than continue to run my node as usual.
people try to stifle the DHT all the time, let them waste their time. Don't all clients start to ignore them eventually?
Cool they spent however much it costs to stall people for like 2-30 seconds.

File: 6013312.png (406.5 KB)

406.5 KB PNG

>>108570296
>I found this thing.
>If you want to verify it install this proprietary application.
I'm not going to do that.

>>108570451
Try adding some magnets for most popular movies from rutracker without adding any trackers. Try some ubuntu torrents without trackers. You'd expect DHT to give you a lot of peers every time. Run Wireshark and check how many peers use port 6881. They haven't randomised the setup yet.

>>108570476
BTDigg and other DHT bots grabbing all announced torrents were slight inconveniences you imply. This allows full control of what you get from DHT with high probability. Attacking nodes make you send data to them, and to them only.
https://en.wikipedia.org/wiki/Sybil_attack

>>108570571
Are you aware of any other client that shows it as clear as in the op picture?

It also says BiglyBT shows DHT internals.

>>108570676
Let's make a list.

1. Tixati shows DHT peers. You can run the portable version for that test, and it can be deleted with all the data afterwards.

2. BiglyBT with Mainline DHT plugin shows peer addresses in tooltip. It's open source.

3. ???

4. ???

If you are a typical qBittorrent user, your DHT table is also full of fake peers, only you can't see that. A single number is supposed to indicate everything about DHT.

>using dht

BBT chads stay winning

File: 1757577781260430.png (49.9 KB)

49.9 KB PNG

>Anonymous from I2P

>>108571100
I seed unpopular torrents from sites that have been dead for almost two decades now. They slowly but steadily reached triple digit ratios. DHT made it possible.

>>108570328
Ironic.

>>108570296
Huh, interesting. Guess I'll null-route all those IPs and add a bunch of fake hashes to prevent this.
I thought that DHT had been strangely ineffectual lately.

hop on fopnu until they stop

>>108571344
>closed source
Fuck no

>>108571327
You don't have a static list of nodes to ban, they are switched each day. You also need to figure out which ones are fake. How would you do that?

>>108571133
run irc bot

xdcc-search.
com/want-a-bot

>>108571383
That's what the fake hashes are for as that document recommends. Basically, you're trying to bait them into telling you they know who has the data but they literally cannot since the hash isn't an actual torrent. Most clients will eventually get fed up with this situation and evict them from your DHT table.

for the occasional public magnet, PEX and udp://tracker.opentrackr.org:1337/announce are enough. DHT stays off, way too many connections/overhead

>>108570296
Hmmm SCOTUS just ruled on Sony vs Cox a few days ago. A hail mary case that tried to put the responsibility into internet providers hands. Lower courts found Cox liable but it was overturned.

>>108571404
if you need more: https://ngosang.github.io/trackerslist/trackers_best.txt

>>108570611
>do this
Isn't a rundown

>>108571058
>DHT table is also full of fake peers
fake peers are not a new thing they usually get banned by the client

>>108571133
How does that happen? Where do people get your torrent hashes from?

>>108571399
>get fed up with this situation and evict them from your DHT table.
yea, you'd experience a bit of delay

>>108571404
I've got more peers over dht.
Bad peers get banned, get the latest qbt and you should be fine.

>>108571622
btdigg

>>108571622
this thread is about DHT. DHT is a system that allows peers to find other peers without a central server, this includes finding torrents where the original site it was uploaded to has gone away, as remember that you can download torrent metadata (.torrent files) from any peer that has it rather than from a website, this is how magnet links work. this means a torrent can stay alive as long as someone, anyone, is seeding it

>>108570328
fpbp

>>108571133
Same I bring long dead torrents back to life and then seed. I'm using ancient utorrent 2.2.1.

>>108571771
You didn't answer the question though. There is no built-in functionality to just search by name in DHT. It's all just hashes. >>108571645 is the answer, but it is centralized system that basically does spying on global DHT network to be able to search like that. It also can be taken down by some stupid DMCA "circumvention" claims as recent github practice shows.

Idk how btdigg does it, but my guess would be that it just listens to DHT and tries to initiate downloading as many hashes it saw as possible to resolve the names of torrents. To be able to do this solo you will need to setup a bot running on your PC for a very long time until it builds up database of torrent names corresponding to hashes you've seen on DHT. Only then will you be able to search meaningfully by name.

>>108571960
you can do it with https://github.com/bitmagnet-io/bitmagnet

>>108571960
oh i see, you're asking how you "search" the DHT rather than generally how do you get hashes that are unlisted.
personally i run a bitmagnet instance, which is basically your own personal "btdig", that is it's a self-hosted DHT crawler with a webui and search engine. can't be taken down

>>108570611
>get default port
HOLY FUCKING SHIT DO NOT GOOGLE STANDARD TORRENT PORTS DONT DO IT BRO

File: 1747843311898711.png (376.4 KB)

376.4 KB PNG

>>108571968
That's a nice rec

File: webui-1.png (557.5 KB)

557.5 KB PNG

>>108571968
12 million, god damn

File: Screenshot_20260410_134050.jpg (348.1 KB)

348.1 KB JPG

>>108572338
How long did it take? I just started my.

>>108572361
it's from their site

>>108572361
i got up to 2 million after a week but it keeps getting corrupted in some way and the webui just stops showing up, trying to figure out why. first time it happened was because i ran out of space and the database didn't much like that, but subsequent times idk. i'm transferring it to a new machine so we'll see how it goes. i really like the idea especially for my servarr setup since most torrent sites these days are behind cloudflare which means they can't be used by such programs

File: Screenshot_20260410_135244.jpg (78.1 KB)

78.1 KB JPG

>>108572386
I started mine using podman-compose, changed yml a bit to use named volume. This way I can transfer volume around and recreate container from scratch however I want and data will still be there.

>>108571622
Anywhere? That's the whole point. You can find the hash on some ancient blog, add it, and wait for a couple of weeks to see if anyone appears.

Anonymous as in CIA?

>>108571609
There's a difference between torrent peer sending wrong data and DHT peer.

>>108572737
Read all later replies in the thread after the post you're repying to. You're confusing torrent files and magnet links with hashes btw. And what you describe is extremely rare. In 99.99% of cases torrent files and magnets are not reposted anywhere other than original tracker website they were posted on. So the way people find torrents from dead trackers is by using systems that reverse engineer DHT system itself like >>108571645 and >>108571968

>>108572057
I only know about a couple of ancient torrent clients that use the so-called standard port as default port, mostly as a joke, because IANA ports had been mostly irrelevant even in the early years of bittorrent. I guess you have never ever opened the peer connections tab to look at their addresses, and relied on helpful AI crap to teach yourself some nonsense, so eat shit.

Can someone give me a quick rundown of what's going on and is it a cause for concern?

>>108572386
>>108572420
i packed up and transferred the data to the other machine (friends' home server to my desktop over the internet) and just ran it now and it works, so not sure why it stopped working on my friends' machine
maybe it's just timing out or something, it really does not seem to like running from a hdd

>>108572770
> You're confusing torrent files and magnet links with hashes btw.
Are you, perhaps, of limited wit?

The only part of the magnet link you really need is the infohash. Here's a trick: paste
C8295CE630F2064F08440DB1534E4992CFE4862A
into your client, and get Ubuntu 25.10. Hashes and magnets are the same thing, and DHT is the global live database that turns them into potential peers and full metadata.

> In 99.99% of cases torrent files and magnets are not reposted anywhere other than original tracker website they were posted on.
Have you uses the Internet at all? Have you accidentally been castrated in the private tracker circlejerk? NyaaTorrens has had a lot of torrents that were re-uploaded from somewhere else, some in 2008, some yesterday. TokyoTosho is itself a database of torrents which came from other trackers. Half of the porn found in the BTDigg and on the ad-ridden link repost forums are public Pornolab torrents, and occasionally some files from original Pirate Bay appear.

Torrents are not tied to trackers, they exist independently. Even private torrents allow the user to set any tracker to find peers. You are free to exchange metadata through any communication channel that exist.

File: Screenshot 2026-04-10 575x468.png (99.6 KB)

99.6 KB PNG

>>108572931
>>108572386
at least now i have evidence of it taking about a week to get to 2 million. this last instance i just transferred ran a bit under a week and it's at 1.9 million entries, it was started on the 1st of april with a bit of downtime on the 3rd due to a "i forgot to start it again" issue. also worth noting this as it is has a 14.8GiB database, it's not very small so plan accordingly

File: 3837.jpg (28.8 KB)

28.8 KB JPG

>>108572880
nothing, its obviously a larp
>Hey fagets, while you were distro-hopping and arguing which media personality is the best to follow to learn what pathetic members of so-called Linux fan community should whine about in comments this week (by the way, they all suck compared to Level1News anyway)...

File: 1767517636581352.gif (3.6 MB)

3.6 MB GIF

>>108572973
Im getting the ick

>>108572386
Compiled offline databases with millions of torrents exist. No need to wait for people to send you some filtered scraps, just grab the whole thing.

Tixati has a couple of p2p channels that share all the torrents people could find in such databases, and a search function. Each one has so much data that it makes the program use more that a gigabyte of memory, and perform slower than Photoshop on a 486, so beware. You should probably use a portable installation for that, and not your main client.

BiglyBT has live swarm search over its own DHT. You don't need those crawlers, the torrents already fly by.

File: word-salad.jpg (68.5 KB)

68.5 KB JPG

>>108573067

>>108573099
> retard starts the program and carelessly clicks on everything without reading any descriptions
> retard complains on the forum that his system is just crawling, and there is no free memory left

> you warn the retard in advance
> retard starts to complain about that

>>108572763
Dht peer obtained via dht, another IP, what am I missing?

>>108572880
bad peers

>>108572057
>STANDARD TORRENT PORTS
no such thing

>>108573167
DHT peer is a node that participates in DHT traffic, not some peer with torrent data found using that DHT.

You are missing how DHT works.
https://bittorrent.org/beps/bep_0005.html

>>108571960
>There is no built-in functionality to just search by name in DHT.
BiglyBT lets you search the DHT using any of the metadata like file size, file name, etc.
It even let's you subscribe to a search so that it polls and aggregates results over time as new peers come online.

Works the same as things like btdigg and >>108571968
Where the client just scrapes and stores metadata.
This is how they implement swam-merging too.

>>108571399
They won't tell you anything. With “allowed” and “unknown” hashes, attacking nodes behave like any other node, they store announces, and respond to you with next step nodes or maybe even previously announced peers. With “disallowed” hashes, any attacking node instantly sends you addresses of other fake nodes, and each of them sends a dozen more. This ensures that you will not contact “less suitable” honest nodes that are naturally not as close to that key as fake nodes, and will not get correct peer data from them. It also poisons your node table, and for the next search you will probably contact those known closest fake nodes directly without even trying others.

Who's actually alerting the developers and the social media?

>>108570611
So this was a bot thread after all, this isn't an answer.

>>108574033
There is no point to explain it to someone who never learned to use a personal computer. You don't know where to look, and won't test anything anyway, you just want someone to entertain you. Please never start Wireshark, or you'll piss your pants the moment the packets start scrolling.

>>108574210
Another bot answer, how predictable! Now, if you would give me the apple pie recipe at once

>>108574216
You don't even have a torrent client, phoneposter.

I still don't get what the issue is
why do you keep reiterating the steps that I should take to verify and not the actual consequences of whatever the fuck is "happening"
Is it "fake peer spam, dht can't find torrents or download shit, dht is now useless"?

>>108570296
>muh anonymouse
This is not 2008 bro

File: tixati.ipfilter.24h.stats20250206.png (21.1 KB)

21.1 KB PNG

>>108570296
Nice to see someone else paying attention to the BT DHT. There's a lot of shenanigans going on there. What you see is a Sybil eclipse attack against your node_id, where the attacker sends a node_id with a common prefix length CPL > 31 bits to yours. I call it the Black Hole attack because it drags away your home bucket far from where it should be. It's done by DHT scrapers to collect all info_hashes that announce to you. It has been going on far more than 5 months, I have observed it since 2012. It's easy to counter by dropping all Queries/Responses with a CPL > 31, but this must be added by the client dev. I suggest you post about it on the Tixati forum; I will watch out for it. wt

>>108571415
Just a coincidence :^)

>>108574650
nigger there is a link in the OP if you had read it you'd know what's going on
t. just read it and no I will not explain it to you go fuck yourself

>>108570296
I love Russia. I will keep using ruTracker. Russia BaSed.

File: mariolord-mariolord14.gif (74.2 KB)

74.2 KB GIF

>>108575993
>>108576382

>>108571383
there are IPs that will just suck all of the connection they can. I would recommend banning these IPs in Alt+O --> Connection --> Manually banned IP addresses...

223.78.79.161

223.78.79.193

223.78.79.225

223.78.79.97

223.78.80.1

223.78.80.33

223.78.80.65

223.78.80.97

>>108576991
Range ban 223.64.0.0/11, you'll be happier for it.

File: tixati.ipfilter.6h16m.stats20260410.png (18.7 KB)

18.7 KB PNG

These four IPs from tixati.meta_vampires.ipfilter.dat hits ~2 times/s with no torrents running. Before with 256 torrents: ~6 times/s. Have not run and updated the filters in a year.

## 490/15 min
5.189.160.21

## 490/15 min
173.249.4.73

## 250/15 min
207.180.192.205

## 1112/15 min
207.180.192.206

>>108572338
>>108572361
>>108572386
You might be able to get 32.5 million faster by importing from these dumps for a bitmagnet predecessor called magnetico, I was going to try it when I bothered setting up a bitmagnet instance
https://tnt.maiti.info/dhtd/
https://github.com/DyonR/magnetico2bitmagnet

>>108571968
Can you make your torrent client use bitmagnet instead of its own DHT functionality so as to avoid duplicating DHT traffic?

>>108576781
Some posters there have already complained about their clients acting out and having zero peers.

Rutracker torrents are 100% known to any observer. They even collect them into a public database:
https://rutracker.org/forum/viewtopic.php?t=5591249

>>108577011
Way ahead of you

>>108570296
I read all of that, and i still don't get it. Are these fake DHT peers spying or serving malware? Please explain it like i'm 5, because clearly i'm fucking retarded.

>>108577282
Torrent clients know the hash that user provides, get the metadata from torrent file or peers, and need to find active peers in the live network.

Magnet databases are for users who don't know the hash, but need to find some with specific filenames or by some other criteria. They generally don't even need an internet connection.

>>108576781
Rutracker is basically banned in Russia, afaik. Same as rutor. Same as some others.
But yeah. You're not wrong for using it if you're not from Russia. And if you're from Russia, you use western stuff, like thepiratebay etc.
Hope you are not that retarded and can understand why.

>>108577457
You won't get a real response as this is an AI bot thread

>>108577011
>>108576991
> Abuse contact for '223.64.0.0 - 223.117.255.255' is 'abuse@chinamobile.com
Is it a chink botnet then? Heard some stuff was stolen from them. Maybe it's a reaction on petabytes of data somewhere on DHT?

>>108577525
Then AI has become sentinent. Because that's OC not available on the net. I have knowledge but have not posted about it before this thread.
My posts:
>>108575993
>>108577179

>>108575993
I've been using Tixati for a while, and DHT looked normal last year, 20-21 buckets, random peers. Maybe the difference is that I have a passive node behind NAT, and they only targeted nodes with dedicated IPs previously.

I would not mind simple crawling, DHT has already been public. Collecting the data at active nodes should have been enough, as they are meeting points for all requests from passive ones, which makes most of the network. Extending the manipulation to passive nodes was probably the preparation for denial of service attacks.

If you block fake nodes that are too close, they can easily switch to a bit more natural values. Repeat a couple of times, and they actually blend with the regular valid nodes. Having certain number of fake nodes in each bucket seems to be enough for manipulation.

Also, closest nodes are not required for inhibiting peer search. They seem to rely on having enough gate keeping nodes around each member of the network. When they see a request for unwanted hash, they instantly give you peers that point to nowhere. Given the number of hashes globally, they probably use some bloom filter for speed.

31.200.249.x peers currently use addresses from 185.16.215.x as proxies. Some time ago, they also used some hosting in Netherlands for that.

People who use popular clients like qBittorrent have no idea that the same happens to them, and that their DHT activity is totally owned.

>>108577953
>If you block fake nodes that are too close, they can easily switch to a bit more natural values.
Yes, that's already happening. It's what I call the Intrusive Neighbor attack, using a CPL between 18–31; it's very flaky and non-trivial to detect. But I'm working on a fix. Also using ut 2.2.1, which can output the current table in the Logger tab.

>>108577563
IDK if it's government or just proxies but for over a decade now any SSH server open to the internet gets hammered 24/7 by braindead bot attacks from 'residential' networks owned by China Mobile and Tencent.

>>108577457
DOI links point to research articles. At least skim trough them. Most often, you put them into Sci-Hub, but those are immediately available on university sites.

https://inria.hal.science/inria-00577043/document
http://www.cs.helsinki.fi/u/lxwang/publications/P2P2013_13.pdf
http://globule.org/publi/SDST_acmcs2009.pdf

https://arxiv.org/pdf/1412.0103
https://eli.sohl.com/2020/06/05/dht-size-estimation.html

Collection of user activity in DHT started ages ago. Copyright enforcers, torrent search engines, common geeks have all been doing that. You have to assume that any hash announcement or peer search your client does is seen by everyone. To limit the exposure, you must use private torrents (no DHT) or whitelist just the single IP address of your friend (i.e. ban the whole Internet to prevent any unwanted connections). Though if you already know the IP:port of a peer, you don't need DHT or trackers, you can add that peer manually. Tixati v3 protocol is also an option if all peers use it. Though the fact that certain users have requested the same hash and then exchanged unknown data can sometimes be damning by itself.

The recent change is denial of service attacks. You add a hit movie or series, fake nodes respond with junk instead of real addresses, your client concludes that no one in the DHT knows any peers for that hash, and there is no one to connect to.

Increased activity in Russia and China is logical. Both countries have a lot of everyday piracy, and in both countries media corporations want to turn non-paying consumers into paying ones. At least in Russia, studios and streaming services are in bed with Roskomnadzor, and basically guide its hand when they want new pirate apps, sites and services blocked. I suppose that the main targets of current attack are not users who watch peer connections and edit firewall rules, but common people with cheap Android TV boxes who get crappy sequential torrenting for dummies apps with movie posters.

>>108578276
If you control the channel to the outside world, you can pretend to be any address on the inside network without any cooperation from that real host. All the reply traffic gets to you first. GFW is known to use IP address spoofing,

>>108578135
I think it's just smooth transition. Some nodes always respond to everyone with 10 byte prefix match for the requesting node, some nodes respond with 9 byte match, some with 8 byte match, and so on. That's how these nodes get into every bucket. It doesn't stop at 18 bits, there are plenty of port 6881 nodes at high and root half buckets.

>>108578350
>The recent change is denial of service attacks. You add a hit movie or series, fake nodes respond with junk instead of real addresses, your client concludes that no one in the DHT knows any peers for that hash, and there is no one to connect to.
Have you tried another client than Tixati?! It has very good logging, but the DHT routing table maintenance is very weak.
I've seen no signs of Sybil Eclipse attacks against info_hashes in my research, only against node_ids. In practice, it's very hard to surround an IH. You only need one honest node, then PEX does the rest.

>>108578541
I think they know what they are doing, and have been steadily growing the network for months, probing and calculating the amount of paths captured on average. Targeting single not very popular client would be silly.

I think they don't jump at each and every opportunity. Temporary client with just a dozen of torrents gets the same DHT peers, but its searches are not crippled. Either they prefer the fattest users, or having a lot of undesired torrents naturally attracts too many of those nodes into your table. They can limit it by content or by user country to align with international licensing, and get money from each company in each region.

Or maybe they don't block anything, and it's just a random routing bug caused by excessive number of torrents.

The blocks are not 100% effective. If you have a lot of real nodes from previous successful searches, they are more likely to be chosen.

>>108578658
I think you overestimate their sophistication. Sybils don't keep state and don't have fuzzy logic, it's too expensive. They collect .torrent files and peer IPs to use for index sites or copyright trolling, using harmful methods simply because that's most efficient. They don't care to try to stop anything, because with DHT, trackers, and PEX, that's very hard and expensive to do.
Hope I don't sound dismissive, I'm very glad someone else knows about this. It's probably only you, me, and the attackers that do.

>>108578956
They have been just Sybil overseers for some time. Then DHT searches stopped working.

>>108578973
Hope you continue to dig deeper, post on the Tixati forum if you find anything interesting.
Try searching for "EBB3A" in the logs, that's a 512-byte deep rabbit hole.

File: f.png (39.2 KB)

39.2 KB PNG

>>108579015
Regular client search finishes with a list of 150-190 peers, and the client only tries the most suitable ones.

Under attack, you see this. There are three screens of failed nodes below, and their IDs seem to jump around far from the requested key deliberately to make your node check each one.

I did test Ubuntu torrents. Sometimes it works, sometimes it reports 0 peers. I don't think it could be an accident.

Porn torrents seem to be whitelisted.

>>108579174
> Porn torrents seem to be whitelisted.
Or not. But they seem to be the luckiest.

>>108579174
Have you checked the level 6 raw logs for what's happening?
If anyone has any questions about the BT DHT protocol, feel free to ask them here. I will be watching this thread.

>>>108579174
So, looking at the pic, I see nothing unusual. The search has found one peer, has got responses from 19 nodes, and announced to three. The number of nodes that have not responded is a bit high, but not unusual. Tixati has lousy maintenance.

>>108578276
I only started tinkering with hosting stuff on rented VPS servers over the last two years, and I’ve had this issue on all three servers I’ve rented during that time. I don’t know who the IPs belong to, but there were lots of Chinese IPs, as well as some from the EU and the US. I used fail2ban to automatically blocklist them after three failed password attempts.

>>108579320
The expected thing is happening.

During search for key AABBCCDD... fake node #1 responds with own ID that is derived from that key (AABBBBFF...), and provides a batch of nodes with similar IDs (AABBEE11..., AABBC566..., AABBDD00..., and so on) and either inaccessible or random addresses. When they all fail, the client asks the next closest node, fake node #2, which responds with a similar batch, repeat ad nauseam Once in a while they add a new fake node that is actually accessible to that list to continue this merry-go-round.

>>108579470
No, the list of failed nodes takes 3 more screens. The client gets a fake batch, tries to connect, they all fail. It gets another fake batch from another fake node, tries to connect, same. Normal searches do not produce such wall of fails, because some real nodes fail, and some respond with a number of closer nodes successfully. It results in a healthy mix and IDs slowly approaching the key.

>>108579597
As Tixati is closed source, I haven't seen the code, but from observations, it seems that it doesn't use a replacement cache like uT, libtorrent, or BiglyBT do. Also, it seems like it doesn't drop responses with an unexpected node_id.
Do you have the possibility to run only one torrent and then let an AI analyze the raw log?

>>108579597
This is actually interesting. Doesn't the fact that it replies and poisons the well with random addresses, create plausible deniability for anyone actually torrenting any pirated or otherwise illegal material *unless* the peer in question has been vetted as a real peer, that's *really* serving that material, by actually initiating download from them?

Which means this particular branch of enforcers hired by the media industry would be actively frustrating the efforts of the other branch of enforcers they hire to snoop out people and send them C&D notices? Basically making their work proportionally harder?

>>108581045
Letters rely on peer probing and test downloads. Moreover, these DHT nodes do not even reply, how would you argue that they facilitate storing any hash and peer information?

>>108579684
It can be seen in the logs that the same IP address and port sends different ids in response to each new hash you request, so there is no protection against that.

Not my problem. I'm a usenetchad.

>>108579174
For comparison, when you search for non-existing hash, or hash with no peers available, you see some failed nodes (probably behind NAT), and some OK ones that send actual replies that they don't know any peers for that hash.

Also, we have a new metadata collector who gives you peers with "dht-spy/1.0" for the client name. But they are open about it.

File: heh.png (25 KB)

25 KB PNG

Heh.

Let the capture run for 5 minutes, and check how many connections to DHT bots on port 6881 your torrent client makes compared to all other random UDP ports. You can exclude other processes in advanced settings.

>>108584445
Bump.

Anything I can do to waste the attackers time or money?
Acting like a honeypot or dummy or something.
I imagine just running a valid torrent client and sending valid DHT data is beneficial as well?
Surely they can't sustain the attack forever.

>>108585675
I don't think this is as expensive as you think. Getting 100-200 temporary IP addresses should be quite cheap in the era of botnets as a service. Traffic, on the other hand...

Let's say a random active client has 400-500 nodes in cache, and 20% of those are strategically implanted fakes by the attacker. Let's say the client generates 2-5 KB/s of outgoing DHT request traffic. Let's say we have 10 million bittorrent nodes on average. 20% of 2-5 KB/s time 10 million is 4-10 GB/s, so each node gets 1/100th to 1/80th of that, or 40-125 MB/s. Quite a lot of constant UDP traffic, but with rotation and distribution from 100 to 400 nodes you can fit into a typical hosting plan. Or maybe they probably get a lesser proportion of it.

Again, if they got funding from someone with deep pockets, it's not a problem at all.

What you should do in the perfect world is studying the DHT security papers, then finding the way to transition everyone to
https://www.bittorrent.org/beps/bep_0042.html
(to require attackers to allocate millions of IP addresses for large scale deception) and
https://www.bittorrent.org/beps/bep_0051.html
(to allow crawling cheaply without need for bots) in a steady but backward-compatible fashion. A lot of people run ancient clients, and won't change, they also need to have some charitable bandwidth from new versions, so there's a need for basic reputation system to check their behaviour.

>>108585675
Though if you already have a client with a lot of torrents running, adding N dozens of random non-existing hashes to keep you node cache constantly stirred is not an expensive precaution.

My conclusion is that simply collecting data on user activity passively is much easier, much cheaper, and everyone has been doing that just fine for years. There must be reasons for all that extra work on user manipulation.

It seems that a freshly installed client needs to be actively using DHT for many torrents for hours before fake nodes start to overcome the real ones.

Another description for those who are new to the topic:
https://www.cl.cam.ac.uk/~lw525/publications/security.pdf

AZDHT unaffected?

This is some simple, fast, coarse filter rules to keep away most Sybils
-----------------------------------------------------------------------

Don't Query nodes with a CPL~(node_id) > 31
Don't Query nodes with a CPL?t(node_id) > 31

Drop Queries with a CPL~(node_id) > 31
Drop Queries with an unexpected node_id for that ip+port

Drop Responses with an unexpected node_id for that ip+port
and if that Responder is in the routing table, evict it

No interaction with nodes that have a id beginning 
with 0x0000000000000000 or 0x3838383838383838

Only one entry in Table per IPv4/32 or IPv6/48
Only one entry in Bucket per IPv4/24 or IPv6/40

------

CPL~  = Common Prefix Length with my_node_id
CPL?t = Common Prefix Length with my Query target/info_hash

Unexpected node_id is one that's not the same as in our routing table 
or the one from a find_node/get_peers Response that initiated the contact.

Drop, not ban, incomming bad Queries, as they can be spoofed. 
Generaly banning should be avoided when a simple rule works, 
to save keeping state.

With CPL > 31, a false positive is highly unlikely and 
the consequence is negligible with the current U = ~2^22. 
When U exceeds 32M, it's time to consider a change, 
as when nearing 48M, it starts to go bad.

>>108571424
Thanks

>>108588696
if libtorrent adopts overall health of the network would improve

>check bot IPs
>they are mostly from pissrael
Every single fucking time.

>>108588696
In theory, node does not need any ID if it's not going to be involved in routing data for others, so probing nodes might use 00..00. In practice, there's a certain amount of users who run some third party or custom code, most likely non-bittorrent software using existing DHT to find peers, and they might not even initialise the ID. I've seen some hobbyist software projects like that.

On the other hand, libtorrent simply does not allow 00..00 as a valid torrent hash, so you can't do anything with it. at least from the user facing side.

Real nodes change their IDs once in a while, so there should be an allowed rate and retirement age to recover from accidental blocks.

>>108586302
Relevant BEPs have been wating for their turn for 10 years.

>>108589700
Are you aware that statistics can tell you how many samples you have to pick to confirm your hypothesis with a high enough chance?

File: s15.png (364.8 KB)

364.8 KB PNG

So uhmm, what the fuck can I do against this? I use sandboxed qbittorrent + ufw, am I good?
Is it related to iknowwhatyoudownload.com?

>>108590650
If you turn off DHT, it will not affect you at all, but even if not, the worst it can do to you is introduce long delays before new torrent downloads start. In theory it can cripple connectivity to extent of things being undownloadable through DHT. Shouldn't kill torrents that are tied to actual trackers if I understand correctly.

>>108570328
Here's your reply.

>>108590650
You can auto-add a bunch of open trackers to every torrent as a backup if you are affected. You are probably not affected if you have a small number of torrents, and see that DHT searches give you active peers. For now. Trackers won't help with peers that are not using those trackers, so we can't afford to lose the global DHT.

You can block all UDP traffic to and from port 6881 for your torrent client EXCEPT the bootstrap nodes (see qbittorrent sessionimpl.cpp#L130).
It is a blunt tool because not everyone on port 6881 is evil, and not all of the fake nodes use port 6881, and they obviously can all switch at any time, but at the moment it won't hurt the network that much.

If you use more powerful client that shows the DHT internals (or can write a DHT protocol filter for network traffic dumps or live nf_tables use), you can manually add obvious offenders to the blacklist. Attacking nodes switch IDs to the ones closest to you or the ones closest to the hashes you search. See the list above.

We can collect and compare the offending addresses. Of course, it is a cat and mouse game, but blocking a significant part of these significantly reduces their ability to block searches.

Tricks like requesting random hashes might or might not help to keep some connectivity intact.

Read the papers, they explain everything.

> Is it related to iknowwhatyoudownload.com?
Company A in Russia proudly announces that it collects All The Peers, and is ready to work with copyright holders. Soon after that, website B appears that lists the same thing, with English and Russian interface. Everyone else is silent. Is there some link, I wonder?

>>108591047

OR MAYBE...

You can simply run a secondary DHT implementation with a different ID on the same system (another torrent client with a couple of popular torrents/hashes without any data as bait), and simply ban every DHT peer that has switched IDs more than once in a certain period.

Both clients get some fake nodes from the attacker. These nodes have to fake their IDs to match the senders (that are different in two clients) or the hashes (that are different because you have many different torrents). We observe traffic for both clients, and detect all of the nodes with non-stationary IDs. We add them to the list with certainty.

To circumvent that, they would need to switch to independent fake node swarms for each new client port on the same IP address. Many of the ISP NAT addresses already have multiple users with torrent clients behind them, so it won't be that easy to figure out which ones are the probes.

>>108591290
Why has 4ourch3ng removed arrows from my post? Its ANSI character whitelist is insanely ancient and insanely insane.

>>108591290
It would be quite easy for clients to probe DHT nodes with search messages from a secondary port with a secondary ID once in a while. If some node switches its ID in response, or has switched its ID in response to previous searches, into the cart it goes.

The main performance gotcha of attacking nodes that they are stateless, and process incoming messages from anyone in the same fashion according to their roles. Synchronising client addresses and ports across the whole fake swarm to know when to pretend to have a similar ID and when not to would be a big problem.

>>108591465
Hey, that kind of differential analysis would be possible to implement quickly without large scale network changes. That's something concrete to offer as an option to client developers.

Though you probably need to use random ports for each test to prevent trivial detection of probes. And also there are users who don't have other ports forwarded, or ability to automatically forward random ports.

>>108570451
Schizobabble. DHT is fine.

>>108588070
Not likely, they generated node IDs based on network addresses since long time ago.

See getNodeID() in DHTUDPUtils.java

Which software (not Transmission, obviously) uses port 51413 in China?
e816faafb2941cef88b89a1bae4d09bf837c697c

install tshark. windows linux mac does not matter

> tshark -D
get the interface number to use after -i

> tshark -T fields -e ip.src -e bt-dht.bencoded.string -i 69 -f "udp dst port 12345" -Y "bt-dht" >lcap.txt
two field output redirected to text file. -i sets the interface. put torrent client port number after -f. -Y removes non dht packets

if you run two or more clients use
> tshark -T fields -e ip.src -e bt-dht.bencoded.string -i 69 -f "udp dst port 12345 or udp dst port 54321" -Y "bt-dht" >lcap.txt

append multiple capture files from different systems or different runs if needed

then grep sort uniq like kernighan showed you

File: hello.png (6 KB)

6 KB PNG

>>108593937
Delightfully devilish!

File: Screenshot_20260413-014642.YouTube.png (530.9 KB)

530.9 KB PNG

>>108593937

I like your words magic man.

>>108593937

so we get variable length lines like

1.2.3.4<tab>ip,r,id,abcdefabcdefabcdefabcdefabcdefabcdefabcd,nodes,token,7a...

because wireshark dht protocol dissector can't extract it for us

regular expression to grab ip and id is

s/(.*)\t.*id\,(.{40}).*/\1\t\2/

first we grab anything (dot-star) that comes before tab (backslash-t) using round brackets for the first capture group
then comes anything (dot-star) until letters "id" and comma (escaped)
then we grab next 40 characters (dot-repeat-40) using round brackets for the second capture group
everything else until the end of the line (dot-star) we don't need

output is first capture result (backslash-1) then tab (backslash-t) then second capture result (backslash-2)

and i already forgot what this mess does

to make sed understand this syntax, use -E. the dump has some error messages without id. to skip unmatched lines in the output, use the regular s/ / /p combined with -n trick

sed -E -n 's/(.*)\t.*id\,(.{40}).*/\1\t\2/p' long_cap.txt >short_cap.txt

on windows use double quotes instead of single

then the basics

sort short_cap.txt | uniq | cut -f 1 | uniq -c | sort

sort the lines to group all captured pairs together by ip
remove the repeating lines. now ips repeat only if they were seen with different ids
cut the first field before tab to get just ips
count the repeats of each one
sort to find the worst offenders

>>108595192

     10    144.76.175.153
     10    54.70.28.180
     10    54.77.218.23
     11    136.243.44.126
     11    138.201.21.237
     11    152.53.119.166
     12    114.16.196.15
     12    148.113.189.229
     12    54.194.124.68
     13    15.204.110.111
     13    195.170.172.38
     13    51.75.78.69
     15    54.36.168.16
     26    152.53.45.107
     32    95.111.226.204
     34    58.17.106.19
     62    216.39.249.244

ten minute catch. if you add some random hashes you'll instantly see nodes pretending to be close to each of them

nats or vpns or seedboxes can host multiple valid clients. don't mind the smallest numbers. the longer you run the dump the bigger the abnormalities

you can add ports to compare but it makes processing complicated. you better write some python parser with proper logic

I only have DHT enable for peers, PEX and local exchange are disabled. Didn't have any trouble downloading shows today. I'll add 223.64.0.0/11 to my blocked sites and just block 6881 outright. I also have never allowed inbound connections to my leech box. My seed box has DHT disable since it only is for private trackers.

>>108592687
>port number >50000
it's random

>>108595544
No, they all use the same port, announce the same hash, and don't reply to torrent protocol.

File: useless_graph.png (25.7 KB)

25.7 KB PNG

Activity distribution.

File: less_useless_graph.png (36.2 KB)

36.2 KB PNG

Same for >5 IDs.

Almost 250 extra active addresses for your blacklists.
https://paste.debian.net/hidden/2841a761

File: proxy_query.png (20.7 KB)

20.7 KB PNG

Three first months -25, I studied BT DHT attacks using Tixati logs and has since been developing mitigations.
My guess from given info is that OPs observed attack is mainly a result of Tixati's rather unique way of handling the routing table.
More of quantity rather than quality that other implementations do to curate the table.
The coarse filter rules I posted should hopefully be a fast fix if implemented.

I'm working on more mitigation methods. To do that, I would say that it's better to examine How attack is done, rather than Who and Why.
The rules should be simple and fast. Not fuzzy and demanding keeping a lot of state.
While ip filters can be 99% effective, they need to be kept up to date and most clients don't filter ips for the DHT.

Earlier posts:
>>108588696
>>108575993
>>108577179
>>108578541
>>108578956
wt

>>108589253
Hopefully, yes. LT does some of them already and other mitigations.
>>108590518
A Query without an id gets droped.
Many nodes using the same prefix, like 0000... or 3838... black hole the closest infohashes. They do a unintended eclipse attack.
An id change moves it half the universe on average, so it's unlikely to be relevant for the table again.

>>108575993
>I have observed it since 2012. It's easy to counter by dropping all Queries/Responses with a CPL > 31, but this must be added by the client dev
how does something like that happens for more than a decade and dev still ignore it? lmao

>>108597579
I was using ut221 and saw my DHT routing table being split to > 80 buckets. I reported it on IRC. In hindsight, Problem 1: I ran many hundreds of torrents so the cleanup loop couldn't keep up, devs usually only test with a handful, so the Sybil nodes got removed when they stopped answering. i.e. they didn't see what I did. Problem 2: My suggested solution, enforcing BEP-42, was heavily argued against by a former dev that most likely worked for copyright trolls.

sup nerds, is rTorrent still the goat

>>108597968
>enforcing BEP-42, was heavily argued against by a former dev that most likely worked for copyright trolls.
Oh I'm mad now. Collusion.

>>108597579
Take a look at provided references before posting.

Academics observed it since the late '00s.
Mitigation solutions were offered.
AzDHT has implemented many of those changes.

It is not devs who ignore it. It is YOU. P2P filesharing has lost the edge since the early '10s, and normies (REEE) moved to streaming and social networks mousetraps.

>>108596465
I don't mean the lack of ID field. I mean that some simple DHT operations work fine no matter what ID you send. Non-bittorrent software might use it that way.

Also, one potential problem with active probing from a second port is that it slightly increases the chance that someone points at your IP address as having too much activity. At the moment, there is a tiny but non-zero number of picky peers that reply with errors after you randomise your node ID, suspecting some malicious intent.

>>108598440
DHT hardening was first developed by emule devs when their Kad got under heavy attacks.
Academics mostly documented it in obtuse language.
BT DHT is simple and very robust.
A user won't notice that it takes 3s instead of 2 to receive the first peers,
or that the announce takes 90s to finish instead of 25 because of the Sybils.
Of course, it must be dealt with, there's a limit how much abuse the DHT can take.

Non-bittorrent software use of the DHT is of little consern to me.
> that someone points at your IP address as having too much activity.
What do you mean?!

An honest node should have a(pseudo)randomly generated id and rarely rotate it.
It must always Respond with the same id, but it is ok to do test Queries with another id.
A node should serve all Queries that's not malformed or harmful.
A node should be very picky what nodes it put in it's table. There's no rights to be in someone's table.
A changing id is a very strong indicator for a Sybil.
A node changing id will be evicted from the table, not banned.

How to break the Unix pipe driven development: add some non-ACSII or non-UTF-8 bytes, and make programs shit themselves. No one is checking process exit codes anyway.

Yes, ancient uTorrent 1.x versions announce torrent names in clear text in DHT traffic.

300+ addresses
https://paste.debian.net/hidden/0513e4b7

attacks on dht is nothing new
https://github.com/arvidn/libtorrent/issues/792
etc

thing is bittorrent.org has been abandoned by bittorrent/Rainberry inc, they used to be the benefactor of bittorrent protocol make sure that network is healthy now it has defacto turned into whatever arvidn implements to libtorrent

>>108599160
Keep in mind that this erotic role play nonsense is the reason you have to sell a kidney to try to get any new PC hardware.

>>108598975
> Academics mostly documented it in obtuse language.
Not reading the provided articles: confirmed.

> BT DHT is simple and very robust.
Not reading the provided articles: confirmed.

> A user won't notice that it takes 3s instead of 2 to receive the first peers,
> or that the announce takes 90s to finish instead of 25 because of the Sybils.
Some users notice that they don't get any peers at all. After any amount of time. This is the whole point of those attacks.

> What do you mean?!
We are talking about potential probing for bots changing IDs, and how often it could be performed to prevent other peers from seeing your address as having too many IDs.

> An honest node should have a(pseudo)randomly generated id and rarely rotate it.
Not reading the provided articles: confirmed.

Freedom to choose IDs is the original source of all insecurities. Basically, your scheme simply relies on everyone else being honest, which means no security whatsoever, and assumes that some global external force enforces it. However, there is no such force, nor there should be.

File: dht38383838.jpg (3.2 MB)

3.2 MB JPG

>>108599160
I can show the attack:

Bucket 0-8, 108-121 is mostly normal honest nodes
Bucket 24-65 are Sybils doing a node eclipse attack
Bucket 67-91 are nodes that harmfully uses ids starting with 38383838...

You should ask it to summarize the whole thread without hallucinating

File: file.png (59.3 KB)

59.3 KB PNG

>>108599518
ok i did, it just keeps telling me your gay & u mom gay
it doesn't want to pull the images from the thread tho so you might want to describe those better

>>108599253
> 300+ addresses
And there are still dozens more in the DHT table which are either stationary across the whole ID space, or rotate IDs very cautiously. But they still try to mess with your requests.

Traffic between each torrent user and bots is 2-10 packets each second, depending on how active you are. Average DHT packet size is 184 bytes, that's 0.35 to 1.6 KB/s per user or roughly 1-10 GB/s globally. Assuming 500 bot nodes, each might get up to 16 MB/s of constant UDP traffic. Most active ones probably need a lot more.

>>108599554
You fell in love with a text generator. It's like falling in love with a door knob. Seek psychiatric help now.

That toy did not “read” the thread, nor it “extracted” “important data”, nor it “explained” to you what you did not know. It's not a summary, it's just illiterate babbling.

Instead, it produced something to make you feel good. It's just a high tech wanking device. The industry does not invest in scientific breakthroughs, it wants to make a lot of money from easily manipulated idiots craving for new kind of drug that makes you ignore the outside world.

File: 22727958e8a9a31c26c24c016f85d101.jpg (300.7 KB)

300.7 KB JPG

>>108599689
honestly i'm hungover as fuck i can't read your schizo babble right now so a summary is the next best thing
i'll check back later
now have a miku pic faget

File: candle.png (1 KB)

1 KB PNG

I have noticed those candlestick events in DHT traffic some time ago. Maybe they try to purge real nodes from your client, or to probe how much effective rerouting they get.

>>108599365
> Not reading the provided articles: confirmed.
I'm sorry that you feel you're losing the argument, but you're right, I didn't read the provided articles.
Because I have already read them. I have read every paper I could find about BitTorrent and Kademlia.
The truth is that 80% of all papers are pure garbage. Of the non garbage papers, only 20% have something slightly useful or better.

For example, almost all papers about Kademlia (including the original), says that the search is a binary tree that takes log2(U) hops.
That is wrong. That's the worst case scenario.

This table shows the average scenario for truly random node_ids:

k=8
random:1+1+3.42 +1+3.42 +1+3.42 +1+3.42 +1+3.42 +1+3.42
   sum:    5.42    9.84   14.26   18.68   23.1    27.52
   hop:    0       1       2       3       4       5  ...  17  18
 worst:    1       2       3       4       5       6  ...  18  19

> Some users notice that they don't get any peers at all. After any amount of time. This is the whole point of those attacks.
...or is it just you using Tixati?! Have you tried another client yet?

> Basically, your scheme simply relies on everyone else being honest
You don't know anything about what I'm working on, because I have only posted fragments of it here.

>op still incapable of elaborating
Sigh... how long until mods delete this blatant bot thread?

>>108600089
OP is not wrong. There is a real issue with Sybils in the DHT, even if it's only Tixati that can't handle it right now.
I'm grateful that he brought attention to it, even if he is a bit butthurt.

>>108600024
>...or is it just you using Tixati?! Have you tried another client yet?
not him but tixati doesn't look like to implement bep-42 at least i can't find any indication that if it does.

>>108600232
No, Tixati doesn't implement bep-42, I think they should, but it's not the solution for this.

BEP-42 is ok for IPv4, but close to useless for IPv6, an attacker only need a few /48s to be able to generate any node_id it wants. Even the smallest ISP gets a /32

>>108600300
>IPv6
general torrent ecosystem completely disregards it, very much unloved. we still need to mess with NAT hole punching fuckery because of the lack of private tracker support etc

File: working as intended.png (11.2 KB)

11.2 KB PNG

>>108600024
> Because I have already read them. I have read every paper I could find about BitTorrent and Kademlia.
Was that during your Navy Seals training?

> The truth is that 80% of all papers are pure garbage.
It absolutely is if you try to ingest everything indexed by Google Scholar. You get endless stream of nonsense that someone in provincial Russia, India or China produced only to satisfy bureaucratic publishing requirements. Because in reality what we see as modern science is a giant bureaucratic machine. That's why scientists don't read “everything”, they rely on informal methods and personal sixth sense to find the real smart stuff.

In any case, the papers in this thread have pretty solid popular magazine level explanations that should be clear to newcomers.

> ...or is it just you using Tixati?!
Other clients I've tried connect to the same nodes. They don't suddenly get a different Internet.

Moreover, any client always uses the tables of the other nodes that it doesn't control on each hop. It seems that all those other qBittorrent nodes have a big mess inside their brains right now. If after 1-2 hops I only get nodes that deliberately send me lists in which not a single node work, and even after addition of a ban list for most obvious bots the searches still fail, how do you call that? I call that a successful control of the global DHT network, not just my client.

The poisoned non-working IDs are chosen to be both closest to the key (with many bytes matching between them, by pure coincidence), and in the nearby area. Both prevents the client from trying to contact real nodes it might accidentally know about. Among 200 or so attempts, the only replying nodes are our friends on 6881 and other ports, or random bystanders that know nothing about the hash.

It also implies that someone has bought a lot of servers all across the world just to screw a small amount of users.

> You don't know anything about what I'm working on
But I can always guess. ;-)

>>108600232
>>108600300
Speaking of pretending to know it all...

Network-dependent IDs, as in BEP-42, only work if everyone (or a significant part of the network) uses them. If you can't enforce it, at least as a factor for scoring, there is no point. And you can't, because no other clients enforce it. To solve that chicken-and-egg problem, you have to quickly upgrade the whole network to the new IDs (with some compatibility service for older clients who can also possibly be bots but not always).

>>108600573
It is possible that they don't target anything in particular, and just offer the service of disrupting the whole DHT for a certain time to anyone who might want it (sport streaming services, governments, etc.). That business model is even better: as long as you pay us, it won't work.

>>108600631
libtorrent prefers nodes that confirm to bep-42 by default.

File: 1744363681358621.jpg (208.3 KB)

208.3 KB JPG

>launch wireshark to check
>mfw it's true
I tried a dozen times and banned all suspicious IPs but I keep getting swarmed by these bots with ids similar to mine, is the only solution to disabled DHT which is the entire point of p2p?

>>108600573
It doesn't take very long to read and dismiss a bad paper. It often takes longer to find a free copy.

If you want to be taken seriously, don't just post your conclusions.
Post in easy to follow steps how you came to them.
No one will bother to try to reproduce what you done with so little information.

What I meant with enforcing bep42 was, only allow bep42 nodes in the table. Quoting myself:
> A node should serve all Queries that's not malformed or harmful.
> A node should be very picky what nodes it put in it's table. There's no rights to be in someone's table.
I can assure you, what I'm working on will be 100% compatible with legacy clients.

Almost all DHT instances are honest (~4M). Sybils are very few (max a few thousands), but have many ids.
But I don't assume a node is honest, I verify it.

>> You don't know anything about what I'm working on
> But I can always guess. ;-)
Yes, that's called straw-manning.
It seems like you don't want solutions, you only want to be angry.
Please, criticize what I have actually posted. I yearn it. Help me make it better.

>>108601103
What you can do is, document it well and create an issue for the client you use.

>>108570296
Still?

>>108601103
You can apply one of the lists here. Or better make your own, and compare. It is likely that the load is distributed, and different clients get different subsets of bots based on the address. That's a typical thing in high load, often even required.

The problem is that your local fixes don't fix other nodes, and you need them to find paths to the target.

Updated version

This is some simple, fast, coarse filter rules to keep away most Sybils
-----------------------------------------------------------------------
v:0.9.0

* Don't Query nodes with a CPL~(node_id) > 31
* Don't Query nodes with a CPL?t(node_id) > 31

* Drop Queries with a CPL~(node_id) > 31
* Drop Queries with an unexpected node_id for that ip+port

* Drop Responses with an unexpected node_id for that ip+port
 and if that Responder is in the Routing Table, evict it

* Don't Query or Respond to nodes that have an id 
 beginning with 0x00000000 or 0x38383838

* Only one entry in Table per IPv4/32 or IPv6/48
* Only one entry in Bucket per IPv4/24 or IPv6/40
* Only one entry in Bucket per node_id

* Don't split a Bucket if one of the halvs will be empty
  (except when boot-strapping the Table)

------

CPL~  = Common Prefix Length with my_node_id
CPL?t = Common Prefix Length with my Query target/info_hash

Unexpected node_id is one that's not the same as in our routing table 
or the one from a find_node/get_peers Response that initiated the contact.

Drop, not ban, incoming bad Queries, as they can be spoofed. 
Generally banning should be avoided when a simple rule works, 
to save keeping state.

With CPL > 31, a false positive is highly unlikely and 
the consequence is negligible with the current U = ~2^22. 
When U exceeds 32M, it's time to consider a change, 
as when nearing 48M, it starts to go bad.

>>108599276
>thing is bittorrent.org has been abandoned by bittorrent/Rainberry inc,
> they used to be the benefactor of bittorrent protocol make sure that network is healthy
> now it has defacto turned into whatever arvidn implements to libtorrent
This is so true, Arvid has in practice become the BDFL of the BitTorrent protocol,
even more unwilling to assume that role, than what Bram ever was.

Make BEP 42 a requirement instead of optional.

> Make BEP 42 a requirement instead of optional.
Not for participation; it must remain 100% compatible with legacy clients.
For entry in the Table, I prefer to wait and do a hardened revision: BEP-42bis.

>>108603308
It can break cgnat user connectivity.

>>108570296
why would you have DHT enabled?

File: 1755786383301687.png (929 B)

929 B PNG

>>108603571
Some people use public trackers.

I enabled BEP 42 in my client and my DHT nodes dropped from ~350-400 down to just 30-40. (it was down at like 10-15 for the first few minutes).

>>108603757
Yes, that's natural when you change your node_id.
Most of the nodes will be evicted, and then the Routing Table is rebuilt.
On average your node will move half the universe.

File: 1749855933737089.png (841 B)

841 B PNG

>>108603786
>>108603757
I went ahead and threw in Ubuntu to jump start the DHT nodes again.

Up to 80+ now.

I mostly use private trackers anyway so this isn't generally a concern for me.

Who cares?

It just creates a small delay in finding a good node/peers.

It's not like this is some malicious attack targeting torrent users, it just happens to be a super easy way to coordinate botnets too.

Torrent users are basically just caught in the middle of the botnet coordination swarms and have to sort through them to find a good torrent node. Once that node is found, though, you're back to torrenting like normal.

File: dht00000000.jpg (2.5 MB)

2.5 MB JPG

>>108599518
Another example of the attack:
Bucket 0 are nodes that harmfully use ids starting with 00000000...
Bucket 8-73 are Sybils doing a node eclipse attack
Bucket 101-122 is mostly normal honest nodes

Peers announced to info_hash: 0000...0000 peaked over 500 for a while

Using node_id 0x0 is common for toy-implementations,
but most of them are "sample_infohashes" spies/scrapers

You get a lot of traffic running a node close to 0000...
See the high "no quota" even though I have turned up dht.rate to 16KB/s
Normal is < 4KB/s

>>108603533
GOOD
fuck thirdies and eurotrash
ima turn this shit on as soon as i get home

>>108606017
American ISPs love CGNAT, so you're just shooting yourself in the foot.

mental illness and unwarranted self importance
if this was real it'd be on orange reddit

>>108606315
Not land line providers. Cell networks use cgnat, but those faggots were never gonna seed either, so fuck them too.

Updated:

This is some simple, fast, coarse filter rules to keep away most Sybils
-------
v:0.9.1

* Don't Query nodes with a CPL~(node_id) > 31
* Don't Query nodes with a CPL?t(node_id) > 31

* Drop Queries with a CPL~(node_id) > 31
* Drop Queries with an unexpected node_id for that ip+port

* Drop Responses with an unexpected node_id for that ip+port
 and if that Responder is in the Routing Table, evict it

* Don't Query or Respond to nodes that have an id 
 beginning with 0x00000000 or 0x38383838

* Only one entry in Table per IPv4/32 or IPv6/48
* Only one entry in Bucket per IPv4/24 or IPv6/40
* Only one entry in Bucket per node_id

* Don't split a Bucket if one of the halvs will be empty
  Only 'Good' nodes counts to initiate the split
  (except when boot-strapping the Table)

--

CPL~  = Common Prefix Length with my_node_id
CPL?t = Common Prefix Length with my Query target/info_hash

Unexpected node_id is one that's not the same as in our routing table 
or the one from a find_node/get_peers Response that initiated the contact.

With CPL > 31, a false positive is highly unlikely and 
the consequence is negligible with the current U = ~2^22. 
When U exceeds 32M, it's time to consider a change, 
as when nearing 48M, it starts to go bad.

Good Practices
--------------
* An honest node must have a (pseudo)randomly generated id
 and rarely rotate it. BEP-42 is recommended.
* A node must always Respond with the same id,
 but can do test Queries with a different id.
* A node should strive to serve all Queries
 that are not malformed or harmful.
* A node should be very picky what nodes it puts in its Table.
 There are no rights to be in someone's Table.
* A node changing id should be evicted from the Table, not banned.
 A changing id is a very strong indicator for a Sybil. 
* Drop, not ban, incoming bad Queries, as they can be spoofed. 
 Generally banning should be avoided when a simple rule works, 
 to save keeping state.

File: Tixati v3.42 Noodle Table.png (25.5 KB)

25.5 KB PNG

Another picture showing how the attack affects the Routing Table.
The 25 nodes in /28 are Sybils doing an Eclipse against the node_id.
The six empty Buckets are unnatural and a result of the attack.
The table should have ended with /21 having 4 nodes.
The expanded numbers in the first Buckets are explained in the paper:
Sub-Second Lookups on a Large-Scale Kademlia-Based Overlay
https://liamzebedee.com/distsys/papers/kademlia-stats.pdf


Thanks to OP for bringing this to attention.
As /g/ has lost intrest, I won't bump this anymore.
Feel free to ask about BitTorrent DHT/protocol, I will try to answer.
I will continue on Tixati's forum when this is archived.
wt

>>108607710
> and rarely rotate it
> rarely
Very scientific.

>>108602934
Internet people find out that age means something for the thousandth time.

Of course most of the people involved back then are older now, and they have no interest in jumping through hoops because someone has brought a bright idea that has been discussed numerous times.

Nothing stops a dedicated group of people from making a libtorrent fork with RGB lights, and implementing some extra features. The problem is that there is no such people, and everyone is waiting for the ancient wizards to solve any problem.

>>108570328
Anon...

check:
>>108608238
It's hard to do it on a scientific level in 2000 chars.
I can give you an exact time if you want: 6d1h38m8s

>>108608254
The BitTorrent protocol is in many aspects mature and final.
Hopefully emergent issues can be fixed.
New protocol features needs to be so independent that they can be
implemented in one client and still be advantageous.

Some list updates.
https://paste.debian.net/hidden/56c5e79a

> 195.191.244.0/23
> https://en.wikipedia.org/wiki/Trident_Media_Guard

Have they tried to resurrect each corpse of anti-file-sharing firm? The media industry seems really on the economic downturn if it is so focused on squeezing the opportunities for piracy all across the world.

If we know some obvious fake nodes, we can also detect stationary nodes (on both 6881 and other ports) that send us those as next hops. Unfortunately, real nodes can also relay them honestly. I guess fakes ones always send 8 of those.

Oh, wait.

Each failed search starts with the same attacking peers, even if their ID is not the closest to the key. Then the client is only getting manipulated, and never sees any real peers.

It seems that the top ones in each bucket are almost always chosen. I assume those are the oldest and most reliable. Of course bots always reply and become the most reliable!

Then, supposedly, hundreds of fake nodes in replies are used to purge real candidates from cache, and a dozen of replying bots ensure that they continue to be considered stable.

I wonder if libtorrent prefers stable nodes, too, then we have a mechanic to game.

I wonder if we can shake the tree somehow to prevent always going through the best (closest/oldest) nodes.

One option is to never use the same initial set of nodes in consecutive searches for the key.

Other is to never include potentially hostile nodes we have announced to into the table (unless the network is so small some of them are also previous hops).

Or maybe generally perform the drunkard search, and deliberately introduce a deviation to the search key that gets progressively smaller on each step. This would increase the amount of stationary nodes to cover all paths.

>>108599276
Helpful link in the comments moved to
https://github.com/the8472/mldht/blob/master/docs/sanitizing-algorithms.rst

>>108609623
> I wonder if libtorrent prefers stable nodes, too, then we have a mechanic to game.

    // this function is called every time the node sees
    // a sign of a node being alive. This node will either
    // be inserted in the k-buckets or be moved to the top
    // of its bucket.
    bool node_seen(node_id const& id, udp::endpoint const& ep, int rtt);

Aha?

Nope, it's just a potential promotion from the replacement cache to the main bucket. find_nodes sorts by distance to the target key.

>>108578350
Thanks for the explanation. Doesn't sound like too big of a concern tbqh.

>>108610379
libtorrent has preference for age, bep42, low rtt and uniform distribution of ids within the bucket

>>108610494
It decides where to add each new node based on that. They are recorded either to the real bucket, to its secondary cache, or nowhere at all. Existing working nodes are not replaced by new ones. Out of those, the initial nodes for search are chosen based on closeness only.

Therefore, the bots must be numerous enough to surround the key. It is possible that constant bombardment of temporary IDs still somehow encourages the client to skip the real nodes more often, and poisons the table with a slower rate.

>>108609623
The whole thing seems to be a combination of gateway fake nodes and bots surrounding real nodes to prevent them from learning about each other. Half of the failed nodes are actually banned.

But that only means a regular client is surrounded by a bubble, and random peers fall into random bubbles without learning about each other.

>>108608844

IMPORTANT: At least one of those addresses is a real user with real data running multiple clients. Do not rely on lists blindly.

>>108608844

At least one of those addresses is a real user/seedbox with real data running multiple clients at once. Do not trust the lists blindly, check your peer connections.

>>108610729
libtorrent also doesn't split a Bucket if one of the halves will be empty,
which saves it a bit compared to Tixati, that splits all the way down to Bucket /28. (Used to be /36).
Another difference is that libtorrent uses alpha = 3 or 4 (ie 3–4 parallel searches).
Tixati has alpha =~10, that makes it get a lot more Sybils when it searches.

File: 1757953660638800.png (741 B)

741 B PNG

>>108603808
>>108603757
got back up to 350+ 24 hours later

I got some good old blocklist setup in torrent client, this one in particular https://www.iblocklist.com/list.php?list=bt_level1 it doesn't cover these cunts right now but I expect it to do in the future.

>>108611876
The default is 25 searches at once. Some nodes even complain about giving them work too often.

https://news.ycombinator.com/item?id=47787620

upboat pls

man I'd rather pay the goytax than do all this shit

>>108577520
Russkies use a VPN, not sites they've never heard of

>>108612689
You don't even need a VPN, you can often fool the censorship boxes.
https://github.com/bol-van/zapret

>>108612597
These 25 searches are 25 parallel target/infohash lookups.
Alpha is outstanding Queries. (See original Kademlia paper)
So 25 lookups with a=10 is 250 outstanding Queries.
No wonder it hits rate limits.
The DHT uses Greedy algorithm.

>>108611746
>>108611799
4 chan was time warping, sorry.

>>108577520
Yes, I'm sure all these russkies on rutracker are expats or are simply foreigners using Google Translate to "fit in". Idiot.