I thought bittorrent DHT did that, tied it to IP address. Now I'm digging in and finding out that it doesn't. What stops an attacker from randomly generating 160-bit node IDs until they get close to their target and eventually taking over a target? Apparently BEP42 fixes this but most does do not require it. I'm disheartened.

How many nodes are typically active in HyperDHT? Because if it is a lot smaller, it maybe that bittorrent DHT is still more secure on this aspect just by nature of it's size.

Reply to this note

Please Login to reply.

Discussion

Ignore that idiot, he neither understands Mainline, nor the tiny 30 ips DHT he is shilling for. Sad to be honest.

Go read BEP0042, recognise that he is a moron, and watch him insist on his soundbites for years to come 😅

you might be projecting, even if you dont see it.

...but you are known to be rude. We had that in the past. Quite hopeless 🤷‍♀️

Disheartened 😅 Holly shit it is so easy to spread lies.

Dude just go crawl the DHT and see how vanishingly small the number of nodes that don't enforce BEP0042 are. Also, it doesn't matter who doesn't enforce BEP0042, your node will, and that is all you need.

But after you enforce it, and make dht size estimate based on your routing table, you will still see +-8 million.

> Once enforced, responses to get_peers requests whose node ID does not match its external IP should be considered to not contain a token and thus not be eligible as storage target. Implementations should take care that they find the closest set of nodes which return a token and whose IDs matches their IPs before sending a store request to those nodes.

Ok. That sounds to me like it solves the not-everybody-upgraded problem nicely.

Not just that but nodes that don't have secure id, don't get added to nodes routing tables unless there is nothing better.

So when you iterate through your routing table to find the closest nodes, you are asking secure nodes and they respond with secure nodes.

And since the vast majority are secure now, insecure nodes get shadow banned effectively.

yes. of course... bittorrent DHT is larger, but HyperDHT is growing.

HyperDHT can already provide the same level of security at a frqction of bittorrent mainline dht size

Its true that BEP0042 is an improvement, but another big issue is the lack of holepunching capabilities.

Woth HyperDHT, every node in the network participates in helping with distributed holepunching to establish e2e encrypted direct connections between peers, even if they live on phones or end user laptops etc...

This allows apps run by end users to participate and is a vital feature.

It is why the keet messenger works.

Yes, HyperDHT is smaller. It is younger, so it naturally isnt as big, but for apl prqctical means it is as secure as Bittorrent DHT.

Now one advantage HyperDHT has is the distributed dynamic holepunching every DHT node participates in, because it allows end users and their apps to easily participate.

If a huge share of bittorrent nodes running on cloud providers like AWS, etc... then in theoretical scenarios like state level attacks, ...it doesnt help that there are millions of nodes.

The advantqge of hyperdht growing with end user adoption of apps makes it decentralized on an entirely different dimension, adding further resilience as well