Hi,
I just have a look on Hydra booster which introduces a multi-peerIDed node with a same table/IP address and this changelog which introduce IP diversity in order to be resilient to sybil attacks.
If I merge both ideas, it creates some limitations for Hydra booster nodes because this type of node cannot be inserted multiple times into the routing table. Am I right ? Is it a good way to consider hydra booster ?
Yes that true.
However all that matter is that at least one hydra head is so bad that it end up in the zero bucket.
Which happen in most cases.
Here is the current 0 bucket on my server:
Bucket 0 (20 peers) - refreshed 31s ago:
Peer last useful last queried Agent Version
@ 12D3KooWHMEZhtHSzRFnFavoCtmCVAAtRqqaaFewiD4tQfQerbVf 37s ago 6s ago go-ipfs/0.13.0/c9d51bbe0
@ 12D3KooWKfSQwnSEMZ3FB45uE51JazgtF7Ac8MTckGMMnnABkpDx 60h58m41s ago 41s ago hydra-booster/0.7.4
@ QmQUinkcKDYAmUfVxreCN6tWvR6o7oTz9LtmwSYVNN9fYA 32m33s ago 4s ago go-ipfs/0.9.0/236f89018
@ 12D3KooWB79uM8MiwEtn3RCZLGAssa9SBaeKWr89zUjCytvjCXRG 21h25m41s ago 37s ago go-ipfs/0.7.0/
@ 12D3KooWBszbJcQut3gW8CYPNgXsECiiRCMGm17xUb4Lr2iKQZEh 99h34m1s ago 37s ago go-ipfs/0.13.0-dev/aa5336f
12D3KooWMZ5Eyj9unntzZjeDmeDasjWWERav7KvX5igYtBPyWzTw 4m46s ago 4m13s ago go-ipfs/0.10.0/64b532f
12D3KooWFPz7XLnitK9h3vdxk5WGiEkhYAtDbYDdNyB3fwfoyMMw 118h45m8s ago 4s ago go-ipfs/0.7.0/
12D3KooWLcKfQRj1MPoCTdXbafGPhKFWnXnRHj1R5ypcEAaNsDkD 37s ago 37s ago go-ipfs/0.7.0/
@ 12D3KooWE1yUXEwr2pT8NpGw3igGsBLuPochk4vAJgbyJfdTXouB 32m33s ago 4s ago go-ipfs/0.12.2/0e8b121ab
@ 12D3KooWM96X5F1Kzy87snMwzgeyncMH6a5R24MovrWUaLCn1XqV 281h29m12s ago 52s ago hydra-booster/0.7.4
@ QmTSugcq3XnRd6YbdwMynGPdH3tSaQV8ujjYyM4EjkqwNw 41s ago 37s ago go-ipfs/0.11.0/
@ 12D3KooWDKkYwctGQdTJJTnrHtSYNaaUwhB13r21PKpWaFFW5drg 395h27m33s ago 37s ago hydra-booster/0.7.4
@ 12D3KooWFExp2DmZcS2y5qDXftimt9hZmoCAmBhjMp1PDbxry51F 47s ago 4s ago go-ipfs/0.10.0/64b532f
@ 12D3KooWGtMtQPhM1hc49smv7ZMDrc4EwXsyrg1gypx3DE1TRy8Z 278h53m3s ago 4s ago go-ipfs/0.14.0-dev/b38bbfa
@ 12D3KooWSFbAi1xaXpszGfbgMe7FT2A5XnXQgYS4ZY6DrcFJNCea 4m33s ago 4s ago go-ipfs/0.7.0/
@ 12D3KooWSuV8o7g4v8y2AFYG5DCs3eQtB5ALQ48H3VMGpGGzVB1n 47s ago 4s ago go-ipfs/0.7.0/
@ 12D3KooWHKbMmS2Cc44wQW3XJjDN5UTewKX2HwX6DDSKYGLiRbPu 15h44m30s ago 4s ago go-ipfs/0.12.2/
@ QmV8QTSkPvFyUG33CRWCgT8f1UmE5e7WhuWMWvcCBMBSq2 41s ago 37s ago go-ipfs/0.11.0/
@ Qmd4bdd9X76zahVdMyjrLisWj5SazPJ9AJ7d1PpVyCoMA9 55s ago 4s ago go-ipfs/0.11.0/
@ 12D3KooWNHw5J8EoGBwNPabVhwtVXWVtp1VHqhKbeWVZ5x5w55Zg 49m30s ago 4s ago go-ipfs/0.10.0/64b532f
As you can see it has 3 hydra nodes.
You can also query the hydra IP diversity of your own routing table with this command:
ipfs stats dht | grep hydra | awk '{$1=$1};1' | cut -f2 -d' ' | parallel ipfs id {} 2>/dev/null | jq -r .Addresses[] | grep -v "127\.0\.0\.1" | cut -f3 -d'/' | sort | uniq -c
This gives me this result on the same server:
4 13.58.225.97
2 13.59.236.189
2 172.31.0.159
2 172.31.0.173
2 172.31.10.115
2 172.31.10.154
2 172.31.10.19
2 172.31.10.237
2 172.31.10.28
2 172.31.10.30
2 172.31.10.51
4 172.31.10.53
2 172.31.11.128
2 172.31.11.215
2 172.31.11.232
2 172.31.1.135
4 172.31.11.35
2 172.31.1.148
2 172.31.1.202
2 172.31.12.143
2 172.31.12.148
2 172.31.12.229
2 172.31.12.4
4 172.31.12.72
2 172.31.14.13
2 172.31.14.214
2 172.31.14.230
2 172.31.14.54
2 172.31.14.65
2 172.31.15.178
2 172.31.15.226
2 172.31.15.34
2 172.31.15.50
2 172.31.15.72
2 172.31.15.79
2 172.31.15.86
2 172.31.3.178
2 172.31.4.172
2 172.31.4.177
2 172.31.5.169
2 172.31.5.85
2 172.31.6.14
2 172.31.6.189
2 172.31.6.92
4 172.31.7.108
6 172.31.7.169
2 172.31.7.5
2 172.31.7.62
2 172.31.8.147
2 172.31.8.5
4 172.31.8.67
2 18.117.141.19
2 18.117.229.168
2 18.117.70.243
2 18.118.227.127
2 18.118.7.164
2 18.119.110.244
2 18.119.126.52
2 18.119.135.21
2 18.119.162.154
2 18.216.243.132
4 18.218.241.19
2 18.220.126.10
2 18.220.243.248
2 18.220.99.22
2 18.223.106.191
2 18.223.211.8
2 18.224.54.158
2 3.12.165.24
4 3.128.199.236
2 3.133.116.23
6 3.133.117.248
2 3.136.234.31
2 3.136.236.119
2 3.136.25.179
2 3.137.170.181
2 3.137.221.214
2 3.137.41.158
2 3.138.105.20
2 3.138.125.59
2 3.139.93.117
4 3.141.192.69
2 3.142.12.169
4 3.142.42.89
2 3.143.0.175
2 3.144.119.58
2 3.144.242.42
2 3.144.254.3
2 3.145.202.13
2 3.145.49.6
2 3.145.99.95
2 3.15.220.238
2 3.16.49.98
2 3.16.50.119
2 3.17.79.48
2 3.22.248.1
2 3.23.101.209
2 52.15.215.90
1 64:ff9b::12e0:369e
It’s very clear that most of them are AWS instances (172.31.*) but there is far more than one head.
The goal of IP diversity is to prevent eclipse attacks, where someone full get your node offline of the network easily (just by precomputing a few TiB of key pairs) which is still pretty relaxed.
Thanks for your response, what do you mean by “so bad” exactly ? That the XOR distance from your PeerID is really high ?
Yeah, the zero bucket is the first one, it’s the bucket with no matching bits.
It contains the 50% worst of the network (the 50% which have the first bit different from you).