File: Unfiltered Measuring Node.png (57 KB, 1082x313)

57 KB PNG

Encircled with a red line to the right in the picture is the targets of Alexis and Lauren.

>What are Alexis and Lauren?
Alexis and Lauren are two closely related mitigation specifications.

>What is your goal?
My goal is to get Alexis implemented in as many clients as possible.
Then users can voluntarily choose to activate it.
This is also the easiest and fastest step to do anything about it.

>Why don't you do it yourself?
I could, but I don't think this is something I can decide on my own.

>Will this hurt the DHT?
No, not at all. This is fully compliant and business as usual for the DHT, barely measurable.

>Is it really that easy?
Yes. I did the math and it really surprised me. I doubled and triple-checked.

>Is it hard to implement?
No, not really. Most of it is already in place in a client.
Still, nothing is trivial to add.

>Why should I care?
If you answered yes to any of the questions in OP, you should.

>What can I do?
That is up to you. What I want you to do is convince client developers to implement it.

>Is the end really near for the DHT?
Yes, if nothing is done about it.
No, not at all, if some mitigations are done.

The Kademlia BitTorrent DHT protocol is very robust and still holds up well.

The problem is, there is very little hardening done in the clients.
Cause there has been little to no directly malicious sabotage done against it.

The things I've seen are scrapers that don't know or don't care about the harm they do.
Also some honest clients that unknowingly do harmful things.
One large implementation has a default YOLO setting allowing 5 packets/s per IP. 5/m would be OK.

I honestly don't know exactly how close it is, only that it is inevitable if nothing is done.
A collapse will come slowly, then suddenly.

>What if they stop spying and start to attack instead?
They could, but that would clearly cross the line into illegal territory.
A properly hardened DHT is extremely hard to take down.

>Are you a big fan of Gilmore Girls?
No.

File: The Alexis Trap.jpg (47 KB, 1000x563)

47 KB JPG

The Alexis Trap - Honeytrapping and Flushing out DHT spies
----------------------------------------------------------
v:alx0.9          Information Warfare

Alexis is a simple and low-effort technique to Honeytrap
and Flush out DHT spies by regularly generating a bogus info_hash
and Announce it to the DHT, then IP ban any peer that passes
a handshake for that info_hash.

After the announce interval, do a get_peers search again.
Any found peers that pass a handshake also get banned.

Exact details are up to the implementation and practical tests.
16 bogus info_hashes active at any time and
banning IP for 2^16s(18h12m16s) seems reasonable.

Alexis will block metadata downloading from the client for spies.
Alexis will flood spies with bogus info_hashes.
Alexis will shun spy peers/nodes from participating.

----------------------------------------------------------

A client running Alexis will block metadata downloading.

A modest few clients with Alexis are needed to flood the spies.

>The math:
>According to dht-spy there are ~90 000 new torrents per day.(~3750/h)
>If we want to flood them with a magnitude more bogus info_hashes,
>and drown out the real torrents from discovery,
>with an announce_interval of 16 minutes,
>we need 625 users with 16 info_hashes for 37500/h
>we need 10 users with 1000 info_hashes for 37500/h
>we need 1 server with 10 000 info_hashes for 37500/h

A majority of clients running Alexis will shun the spies.

16 info_hashes is like running 16 idle torrents, not noticeable.

File: The Lauren Bomb.jpg (189 KB, 750x1080)

189 KB JPG

!!!!!  Warning! - Don't DO THIS, it's not nice      !!!!!
---------------------------------------------------------
The Lauren Bomb - Evil Twin, Wreaking Havoc with Spy Data
---------------------------------------------------------
v:lrn0.9          Information Warfare

Lauren is Alexis' evil twin, generating bogus .torrents 
instead of info_hashes, where 6:pieces is filled with arbitrary 
rubbish in an otherwise legit-looking .torrent file, 
poisoning the data for the surveillance apparatus.

Disclaimer: I don't condone this and condemn it I will not.
It would be absolutely terrifble if someone made a 
Lauren Bombér assisted by an SGM - Slop Generator Model, 
sometimes called an LLM or Artificial Idiot.
---------------------------------------------------------

It's easy to see that a single madlad can vibe-code some script to make a client do this and have it up and running in less than an hour.
I don't encourage it. But I must confess, I would take great pleasure seeing the resolve rate crash down to zero on dht-spy today.

In the long run, that is not a solution. This needs to be done by a significant part of all running clients.

By the way, dht-spy makes up a whole 4.04% of my DHT traffic now.
What's worse, it hijacks the searches, leading them astray and then stealing the announces,
making them take longer and sabotaging my presence in the peer list.

>The Sybil node cries out in pain - "How can you do this to me, being deceptive and lying to my faceless? All the info_hashes I have sneakily collected are fake, all the metadata I have taken is garbage that I greedily feed my database with, making it useless!" - shaking its digit in impotent vengeance and despair.

what the fuck is this nigga sayin

I manually right click and ban all israeli peers

>>109527791
OK. I'm all for it, so just like, post the script man or the github with the source code to deploy.

File: Alexis and Lauren, Greenv(...).jpg (210 KB, 1024x759)

210 KB JPG

>>109528072
bro, it ain't that deep

>>109528083
Need to click a lot to get rid of this manually

>>109528106
Thanks for support. I want to get this into the clients. If you want to go ahead and script this, do so. I have chosen the community way.

File: Alexis and Lauren The DHT Team.jpg (173 KB, 692x1024)

173 KB JPG

Updated from: https://desuarchive.org/g/thread/108570296

This is some simple, fast, coarse Filter Rules to keep away most Sybils
v:coarse0.9.3

* Don't Query nodes with a CPL(my_id,node_id) > 31
* Don't Query nodes with a CPL(my_target,node_id) > 31
 and if the Query candidate is in the Routing Table, evict it

* Drop Queries with a CPL(my_id,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 halves will be empty
  Only 'Good' nodes count to initiate the split
  (except when bootstrapping the Table)

------

CPL = Common Prefix Length

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.
 Banning should be avoided when a simple rule works,
 to save keeping state.

>>109527791
I want to lick Alexis Bledel's forehead.

File: Alexis and Lauren Awkward.jpg (141 KB, 1024x759)

141 KB JPG

>>109531271
Eww

what brand of retardation is this

>>109531271
HHHHNNNGGGGG~~~ <3 <3 <3
imagine the forehead grease <3

>>109527791
Lauren Graham sexo

>>109527791
>The best is if it's in most clients, taking unnoticable resources.
Idk how active it is being developed today but you have a solid chance of getting this into qbittorrent-enhanced OP, you should open an issue about it. Far from being the most popular client but it's a start. The most encompassing solution is ofc libtorrent-rasterbar itself but idk how Arvid would take this.

>>109532341
I meant libtorrent, fuck

>>109532341
>>109532354
this would be a good idea once there's a true spec to adopt instead of "vibe code these rules pls make no mistakes"

DHT scrapers are a good alternative to tracker websites imo, i run a bitmagnet instance on my home server. everything in one place, no censorship, no cloudflare or captchas or api limits in the way of using it with other software like prowlarr/sonarr/radarr, etc.

your project directly hurts DHT scrapers, and probably hurts DHT in general. i get what you're trying to do, but i don't think it's helpful. it's hardly any different to all those fake tv show torrents i've been getting recently. not all automation is malicious, you know.

>>109527791
>Do you want to cut off the DHT as a source for "ISP letters"
this doesnt stop them, they dont index the DHT, they monitor known hashes
>Do you feel uncomfortable by having your IP exposed on IKnowWhatYouDownload or dht-spy?
if they stop indexing torrents from DHT and just monitor the ips, it doesnt stop them either

this only stops sites like btdig from being able to index torrents from DHT.

and in bittorrent v2 indexing is impossible anyway

>>109527791
No I am not helping any woman.

>>109528072
LLM slop

File: Alexis and Lauren going t(...).jpg (291 KB, 1290x1279)

291 KB JPG

>>109532341
Thanks for feedback. qbittorrent-enhanced adds a lot of stuff, some harmful and broken things that qBit don't for good reasons.

The name libtorrent is a mess.
There is BigTian libTorrent: Founded and maintained by Jari "rakshasa" Sundell(no) and used by rTorrent. Was first.
There is littleTian libtorrent: Founded by Tony "bascule" Arcieri(usa). Maintained by Arvid "hydri" Norberg(se) libtorrent.org(rasterbar AB, owned by Arvid)

File: Alexis and Lauren hates K(...).jpg (56 KB, 750x738)

56 KB JPG

>>109533852
>DHT scrapers are a good alternative to tracker websites imo
Agree, the original BTDigg was terrific. I have no problem with DHT-based search sites per se.
I dislike shaming sites like IKnowWhatYouDownload and dht-spy, but I can tolerate them for the sake of search sites.
I definitely don't think anyone's convenience is worth the fact that they can be used to find victims for "ISP letters".

>not all automation is malicious, you know.
Herein lies the big problem, it doesn't need to be malicious to be harmful.
And harmful it is. And not just a little, it's on a system-threatening level.

Today's numbers from my measuring node: dht-spy 4.08%, sample_infohashes 4.58%

dht-spy is taking a whole 4.08% of not only my DHT traffic, but also ~GLOBALLY.
What's worse, it hijacks the searches, leading them astray and then stealing the announces,
making them take longer and sabotaging the presence in the peer list. Delays 2-3x

sample_infohashes ~4.58% GLOBALLY, where approximately 2/3 is BitMagnet, 1/4 is id:0x0, 1/12 the rest.
So 3% for a few thousand BM don't seem to be much, especially as a sample_infohashes Query
is not at all as harmful as what dht-spy does.

Unfortunately, that's wrong. dht-spy downloads the metadata once. BM downloads it once EACH.
2000-5000 downloads, zero uploads puts a large strain on a lone seed sharing something rare.
I have had freaking 358 BM in my peer list for a bogus info_hash and they where max 15m old.
That is pure leeching. And only two rows from >>109527804

>your project directly hurts DHT scrapers, and probably hurts DHT in general.
How?
BM is not even collateral damage, even if it's a small share, it's still plenty harmful.

reminder rory was a whory, whom she took after her mother whorelai

File: Alexis and Lauren Really.jpg (216 KB, 634x1024)

216 KB JPG

>>109534054
>>Do you want to cut off the DHT as a source for "ISP letters"
>this doesnt stop them, they dont index the DHT, they monitor known hashes
It does what I said, "cut off the DHT as a source".
This makes it much harder for them, not impossible.
Don't let perfect be the enemy of the good.

They definitely use the DHT to find victims.
See pic in >>109527804
Trident media guard (TMG) is https://en.wikipedia.org/wiki/Trident_Media_Guard
Uses 195.191.244.0/24 https://bgp.tools/rir-owner/f4372f71-5e75-4a7e-a6bb-af32afe7ed08 *
As Hadopi is no longer enforced, it's only 0.2% nowadays.

tixati/contabo.peer_harvesters ~10%, is most likely Tecxipio, Germany
a large source of victims to "Urheberrechtsgesetz Abmahnung"

Both of them systematically "get_peers" scan a node with a list of info_hashes,
to harvest all peers registered on that node.

>and in bittorrent v2 indexing is impossible anyway
No, the BTvii sha256 info_hash is truncated to 160 bits to be indexable.
This was done against Bram's wishes and makes it ironically have the same exact
security margin, 2^160, as sha1 currently has against a preimage.
This makes the use of 256 bits in the rest of the protocol rather useless.

*added some more IPs to that filter now.

>>109531813
it's pure schizo posting.

File: Alexis and Lauren Mocking(...).jpg (157 KB, 992x663)

157 KB JPG

>>109531813
>>109535842
>>109539628

So let me get this straight, you announce a fake torrent on the network and whoever says they have it or wants it gets blocked for being a liar?

>>109540627
Simply put, yes.

File: 1770218949874132.png (1.29 MB, 1320x974)

1.29 MB PNG

you should consider instead of posting this on a mongolian basket weaving forum, you should take it to the actual forums, pull requests, and issues list for the related software, I'm sure the people at qbittorent and the tixati developer would be happy to implement a version of your feature if it helps the current state of DHT be less of a privacy nightmare

>>109538970
I'm just gonna say:


Jess was the best for Rory, Logan literally was there to pamper her like her Granddad did before.

>>109527791
>Do you want to cut off the DHT as a source for "ISP letters"
no
>Do you feel uncomfortable by having your IP exposed on IKnowWhatYouDownload or dht-spy?
no
>Do you want to get rid of "Transmission 2.2.1" false seeds, or the cavalcade of "BM 0.0.0.1" and "DS 1.0" vampiring metadata?
no
>Do you want to shun spy peers/nodes from participating in the swarm?
yes
>Do you want to save the DHT from being overwhelmed and a total collapse that is not so far away if nothing is done about it?
no