the Secure Scuttlebutt protocol uses a simple UDP broadcast to find peers on LAN. Besides that, nodes which have real IPs and are listening on the internet (we call them pubs) announce themselves on the feeds. So when you sync with your peers, you end up getting to know these servers as well. They are not guaranteed to stay online, and they are not needed for the system to work, they are just convenience to reduce the amount of hops. Some people been experimenting with “rooms” in SSB which helps connect people who are not in the same LAN and do not want to use “pubs”. None of the rooms or pubs is hard coded or crucial for the network to work. It is very resilient.
According to zmap it takes 45min to scan all of IPv4 on a Gigabit connection. That could be a slow but interesting way to reliably bootstrap the network in case of an attack.
The 45 mins scan advertised on the homepage is probably the result of a TCP SYN scan though. You’ll probably need to add an application layer scanner on top of that (zgrab?). Not sure how this will affect the overall latency of the scan :/
I used to do distributed systems resilience consulting for a few different blockchain projects. I never saw an anti-sybil mechanism that wasn’t easily gamable with relatively simple race conditions or a rich person splitting their account into many small ones to gain more votes for gaming whatever anti-concentration or democratic mechanisms the specific network is trying to incentivize. Can anyone today with a straight face say that this issue is addressed by a non-government/strong KYC mechanism?
I don’t have anything to add other than I’ve been down the same path and I agree, I haven’t seen anything that doesn’t ultimately end up with some form of governance/KYC. I do want a verifiable and trust-building solution to exist though.
The GNUnet project implements a Sybil-resistant DHT, and tries to prevent Sybil attacks on other layers as well. See this paper (PDF) and try searching for “sybil” if you’re interested.
GNUnet forces participants to calculate a small hash, basically bitcoin-style but cheap enough that the weakest “legitimate user” of the system can still do it. Maybe that’s fine for GNUnet, but once there are any sort of significant decision happening based on client participation, it becomes very difficult to make a system that can protect itself from a rich person forcing that decision to happen in a way that causes them to become even richer.
it is a central point of failure for the first time connecting to a DHT network, but subsequent connections can be initiated with previously found peers (some clients do this)
Not necessarily, there are certainly methods to not need bootstrap nodes as long as you can make some assumptions like “AWS IP space would have a node in it” and then scan likely IP spaces for nodes.
I tried a few decentralised chat clients a year back to see what they were like. I recall one program taking hours to find my other device (user). This wasn’t remarked well in the docs, it just mentioned you had to wait :P
Sidenote: I specifically remember the Tox clients. Voicechat was a feature I tested with a friend, but things kept breaking. Voice streams kept becoming one-way after random periods of time and transferring a file was unreliable and would make the voice stream become unreliable.
It would be interesting to have a look at how things are since then.
EDIT: other memories:
Ring: big browser app only, couldn’t get it to compile on my distro (Void). Website didn’t offer generic pre-built options, instead told me to use my package manager in my distro (of which only a few were listed). Hope it’s still not a giant webapp (electron?) thing.
Retroshare: feature-filled, didn’t fully test. Looked interesting, not much publicity.
Qtox and Utox had different/unique bugs.
Nothing beat or matched running a murmur server + using mumble in terms of convenience or reliability. Alas I’m annoyed about how many deps this software requires: half of Google IIRC, a pain to compile from scratch on distros that don’t package it (alpine?).
you’d be hardcoding a specific IP space to use, which could easily be blocked by a malicious ISP. if you don’t have access to IPv4, only IPv6, then you can’t scan the internet looking for a node either.
you hardcode some specific IP space to use first and blacklist problematic IPs, otherwise I don’t see how ISPs would go about blocking it. We’re talking /8 Spaces.
the Secure Scuttlebutt protocol uses a simple UDP broadcast to find peers on LAN. Besides that, nodes which have real IPs and are listening on the internet (we call them pubs) announce themselves on the feeds. So when you sync with your peers, you end up getting to know these servers as well. They are not guaranteed to stay online, and they are not needed for the system to work, they are just convenience to reduce the amount of hops. Some people been experimenting with “rooms” in SSB which helps connect people who are not in the same LAN and do not want to use “pubs”. None of the rooms or pubs is hard coded or crucial for the network to work. It is very resilient.
According to zmap it takes 45min to scan all of IPv4 on a Gigabit connection. That could be a slow but interesting way to reliably bootstrap the network in case of an attack.
I like the idea.
The 45 mins scan advertised on the homepage is probably the result of a TCP SYN scan though. You’ll probably need to add an application layer scanner on top of that (zgrab?). Not sure how this will affect the overall latency of the scan :/
I used to do distributed systems resilience consulting for a few different blockchain projects. I never saw an anti-sybil mechanism that wasn’t easily gamable with relatively simple race conditions or a rich person splitting their account into many small ones to gain more votes for gaming whatever anti-concentration or democratic mechanisms the specific network is trying to incentivize. Can anyone today with a straight face say that this issue is addressed by a non-government/strong KYC mechanism?
I don’t have anything to add other than I’ve been down the same path and I agree, I haven’t seen anything that doesn’t ultimately end up with some form of governance/KYC. I do want a verifiable and trust-building solution to exist though.
The GNUnet project implements a Sybil-resistant DHT, and tries to prevent Sybil attacks on other layers as well. See this paper (PDF) and try searching for “sybil” if you’re interested.
GNUnet forces participants to calculate a small hash, basically bitcoin-style but cheap enough that the weakest “legitimate user” of the system can still do it. Maybe that’s fine for GNUnet, but once there are any sort of significant decision happening based on client participation, it becomes very difficult to make a system that can protect itself from a rich person forcing that decision to happen in a way that causes them to become even richer.
Unfortunately the bootstrap node that DHT uses must be hardcoded and is a central point of failure.
Or just post the IP on a website and let a user copy-paste it. (Yes, I am aware of the difficulties of getting a user to do anything sensible ;-) )
that’s a good idea, sort of like how 8.8.8.8 is manually spread around as google’s open DNS.
the comparison to DNS is apt, DHT is a name resolution system similar to DNS.
DNS : names->ips :: DHT : hash->peers
Encode the IP address as base32 or a hashid or something and tell them it’s a secret code!
it is a central point of failure for the first time connecting to a DHT network, but subsequent connections can be initiated with previously found peers (some clients do this)
Not necessarily, there are certainly methods to not need bootstrap nodes as long as you can make some assumptions like “AWS IP space would have a node in it” and then scan likely IP spaces for nodes.
I tried a few decentralised chat clients a year back to see what they were like. I recall one program taking hours to find my other device (user). This wasn’t remarked well in the docs, it just mentioned you had to wait :P
Sidenote: I specifically remember the Tox clients. Voicechat was a feature I tested with a friend, but things kept breaking. Voice streams kept becoming one-way after random periods of time and transferring a file was unreliable and would make the voice stream become unreliable.
It would be interesting to have a look at how things are since then.
EDIT: other memories:
that’s still a hardcoded central point of failure, just one that is more robust against failures
It’s not that hardcoded, as long as some node is reachable on the internet without NAT traversal, you can establish connection to the network.
you’d be hardcoding a specific IP space to use, which could easily be blocked by a malicious ISP. if you don’t have access to IPv4, only IPv6, then you can’t scan the internet looking for a node either.
you hardcode some specific IP space to use first and blacklist problematic IPs, otherwise I don’t see how ISPs would go about blocking it. We’re talking /8 Spaces.
[Comment removed by author]
You can easily hardcode a fairly large list of bootstrap nodes. It compresses well.
and a malicious ISP could easily block all the nodes on that list
…or do DPI and block DHT traffic anyways. However, circumvention and obfuscation is out of the scope of the article.