Are IPs crawlable in the [full] as running SAFE Network?

I read this strange confession of a Bitcoin Classic DDoS man and he ended up waxing on about crawlable IP addresses, which allows his DDoS attack scripts to work constantly. There are few defenses from the perspective of an at home farmer, except of course “moving” farming operations. So I figured I’d bring up this topic in the context of the SAFE Network.

-edit-- [full] meaning when it’s fully functional, in operation, all BETA bugs have been resolved, and even Safecoin is being traded on the SAFE Network. Of course, if IPs are crawlable right now in the launcher app, V 0.0.1, then it will be in the full network version, but in case this changes, I thought I’d clarify this point in advance.

1 Like

As I understand it there will be competing DNS systems on SAFE as by default SAFE doesn’t use IPs so any DNS system has to be created on top of the SAFE network at the app layer. But I could be wrong about that.

So to answer your question IP addresses aren’t crawlable because there are no IP addresses to crawl on SAFE.

It sounds like he is being paid to attack Bitcoin XT

I wouldn’t attack Core because this is what I rely on. When I attacked XT I haven’t noticed any significant changes in bitcoin price. I don’t think that ddosing several forks will be harmful to main bitcoin infrastructure.


Just paid, I’m professional ddoser lol. Don’t know why someone want to bring it down. Maybe increasing block size will decrease miners profit? I’m using bitcoin a lot but don’t care about it’s politics too much, XT had too fast block size grow rate which looks unrealistic to me. I think BIP100 is okay since it allows voting and also bitcoin unlimited also seems like good idea and looks simpler for me. If classic will fork to 2mb blocksize and it would be not enough then what? Next hard fork? I think protocol should support miner voting by design.


Actually I created this idea for botnet control, where p2p will be only used as failsafe control channel if c&c server gets disabled.


Peers are selected randomly so it’s hard to replace some node’s peers with your, also those who need more like payment systems can rent 10 vps and get 10x more peers
I’m using udp flood and your server responds by icmp-unreachable packet because there is no listeners of udp port on your server


Yea, this is my crawler. Maybe it’s too intensive crawling. Banning it by ip is pointless it uses constantly renewable proxy list.

By the way, why all p2p networks like bitcoin allow crawling all ips so easily? Is there any solutions for p2p networks that doesn’t allow to crawl them easily?

I was thinking about it for some time and invented interesting p2p architecture that limits number of connected peers by design and peer can’t get ips of all network users, only his peers.

The idea is to replace ips by random hashes and reverse connection direction - peers connects to new peer. New peer connects to seednode and sends message that he wants more peers. Node hashes new peer’s ip with good random hash function and resends message to it’s peers who have hashes most similar to new peer’s hash.

So it should work like DHT in bittorent finding node which ip hash is most similar to new peer’s ip hash(hash function must have good avalanche effect to ensure distributed connectivity). And when that most similar node receives message it connects too new peer becoming his first peer.


We can limit maximum number of nodes by limiting number of hash functions that can be formed from one ip, for example new peer can send number only from 1 to N and new peer ip will be hashed like hash(ip, number) so when network is working like DHT it will always find nodes who’s ip hashes are most similar to these hashes and those nodes will become your peers.


Only up to N peers. The only way to collect all network ips with this design is to control pool of ips comparable with p2p network size and run nodes on them or to become node and log all messages of peer connect requests passing trough you (not very useful if main p2p part is on dynamic ips and should be slow without larger ip pool anyway) since ip hash is easily reversible by bruteforce/table, hm, actually ip need to be sent in peer connect request so similar node could know where too connect


Exact payment is a secret. Tens of thousands range.
My mitigation design requires network_size/max_peers controlled by attacker to collect most ips of network so it will be hard to collect all ips from one server. The problem for you is that I control botnet bigger than even Core’s network, so can easily crawl ips anyway with any peer limiting technique. Actually I created this p2p arch for this botnet, but haven’t implemented it jet


Such attacks are in tens of thousands range. 30-100$/day for simple sites on vps or shared hosting without antiddos, 100-500$/day for more advanced targets with antiddos clouds, it depends on how hard is to ddos it. Tens of thousands/month for advanced attacks, price depends on target, it consists from uplink bandwith cost (5-8k$ 10gig/month, this is what your ISP pays for internet), and my profit which includes cost of developing custom software (bitcoin crawler, game ddos with game packets, etc…)


It won’t help. I’m using dns amplification, this is not a connection, it’s not even tcp packets, it udp flood. It never gets processed by bitcoin node software, just dropped by OS kernel. It will completely fill your internet connection making node unreachable. The only way to mitigate it is filtering by your uplink ISP having bigger bandwidth. It’s pretty simple to filter it there


DNS Amplification, maybe will switch to syn flooding after some time. Several tens of servers. You can buy such servers with ip spoofing permitted on almost every serious hack forum, lot of “grey” ISP’s selling them.


My bot just collect’s ip’s from peerlist, it connects to every ip from that list and asks for version. If your report your version in any way then I can ddos your node, if you not then there is no way to distinguish it from core nodes


I not using botnet, but servers. Currently haven’t ipv6 spoofing tool, but will write one if there would be >200 ipv6 nodes


My anti-crawling architecture limits number of peers by design to some N so there is need to control network_size/N ips to crawl most of netowork ips. It wont help anyway since I control botnet larger than size even than Core’s network, so even limiting peer count by protocol design won’t help

IP addresses might not be ‘crawlable’ in the Google sense but an attacker will easily be able to track IP connections made during normal SAFE network operation and target those IPs for DOS attacks.

e.g. my safe_launcher is currently connected to two IP addresses;
[xxxx@nuc02 ~]$ sudo netstat -anp | grep safe tcp 0 0 xx.xxx.xxx.xx:yyyyy 46.101.12.6:5483 ESTABLISHED 10548/safe_launcher tcp 0 0 xx.xxx.xxx.xx:yyyyy 46.101.12.230:5483 ESTABLISHED 10548/safe_launcher

Looking at the source there is also a hard coded list of contacts / entry points.

Assuming that :5483 is the default listen port shodan.io and other netblock sweeping entities will ‘pick up’ SAFE vaults and will list them.

And this is all without even looking at the API yet to see if there is a way to request more introduction points / lists of nodes.

When the network is of a larger size and implemented then you will be able to see the nodes closest to you in XOR space and any others will be a hop(s) away.

Makes it lot harder than when the network is under test with some fixed IPs coded in and only 50 machines with vaults

4 Likes