Login

Redecentralize

We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.

We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.

Home

Parent
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-12 08:30:41 (5 years 2 mons 2 days 05:52:00 ago)

On Aug 5, 2014, at 11:11 PM, David Geib <trustiosity.zrm@gmail.com> wrote:

> I was thinking: does this almost reduce to the "hard AI problem?"

Detecting which nodes are malicious might not even be computable. It's the lack of verifiable information. Unless you have some trust anchors to create a frame of reference you can never tell who is defecting vs. who is lying about others defecting. And as I think about it, the only way to distinguish a targeted attack from a node being offline is to establish that it is online, which requires you to have a communications path to it, which would allow you to defeat the attack. So unless you can efficiently defeat the attack you can't efficiently detect whether one is occurring.

So I guess "detect then mitigate" is out. At least without manual intervention to identify that an attack is occurring.

I think you're ultimately right, and you've shifted my thinking just a little. The CAP theorem, while relevant, is probably not the central bugaboo. The central problem is trust.

What and who do you trust, and why, and how do you compute this?

The solution most of the Internet uses is for real-world political entities (corporations, governments, etc.) to create signing certificates. This is also the solution ZeroTier uses, more or less. Supernodes are designated as such because they're hard coded, which will soon be determined by a signing certificate that I plan to put somewhere very safe (and keep encrypted) when I'm done signing the topology root dictionary.

Trust without some centralized "god" somewhere is extraordinarily hard for the reasons you discuss. How do I trust? How do I compute trust? How do I cooperate with peers to compute trust while being sure these peers are not defecting.

If there is an answer, it's going to come from game theory.

Finally, on the subject of "manual intervention..."

That manual intervention must by definition take place over some other network, not the network in question, since the network being intervened with may be compromised.

It reminds me of Godel's incompleteness theorem. To intervene on behalf of a decentralized network requires that the conversation be taken somewhere *outside* that network. We see this with Bitcoin's response to GHASH.IO temporarily getting 51%. The response was rapid, and was coordinated via sites like Reddit /r/bitcoin and other things completely separate from the block chain.

This also makes me think more and more about hybrid systems where you've got multiple types of systems -- including both centralized and decentralized -- that back each other to create an "antifragile" network.

> The Bitcoin network solves the trust problem by essentially trusting itself. If someone successfully mounted a 51% attack against Bitcoin, nothing would be broken as far as the network is concerned. But that's not what *we*, the sentient beings that use it, want. We want the network to do "the right thing," but what's that? How does the network know what the right thing is? As far as its concerned, when 51% of the network extends the block chain that's the right thing... right?

Another way of putting this is that the Bitcoin users solve the trust problem by trusting the majority, where resistance to a Sybil attack comes from allocating votes proportional to computing power. Which works great until some entity amasses enough computing power to vote itself God. And you can do similar with other scarce or expensive things. IPv4 public addresses come to mind. Useful for banning trolls on IRC but if your attacker has a Class A or a botnet you're screwed.

Yep. It's one of the reasons I don't think Bitcoin in its present form is necessarily *that* much more robust than central banks and other financial entities.

Don't get me wrong. It's awesome, especially on a technical level, and it's clearly useful. I just don't think it's the absolute panacea that some think it is.

It has other issues too. A lot of people call it "anonymous virtual currency." It most certainly is not. That particular piece of Bitcoin evangelism is almost Orewellian in its doublespeak-iness. Bitcoin is the least anonymous currency ever devised. Every single transaction is recorded verbatim forever. Yes, the addresses can be anonymous but... umm... educate yourself about data de-anonymization with machine learning and data mining techniques. That's all I'm gonna say.

... and once one Bitcoin address is de-anonymized, you can now begin traversing the transaction graph and de-anonymizing others. If the geeky methods fail you you can always fall back on gumshoe detective work. "Hey dude, you sell Bitcoins on localbitcoin right? Who did you meet with on X date?"

> You could solve that problem pragmatically though by shipping with acceptable defaults. If a user wanted to change them they could, but they don't have to.

Right.

Maybe a good solution to the trust problem is exactly this:

Build in acceptable trust defaults, but let the user change them if they want or add new entities to trust if they want.

The challenge is making the *interface* and *presentation* of trust comprehensible to the user so the user understands exactly what they're doing and the implications of it clearly (without having to be an expert in PKI). Otherwise malware will game the user into trusting things they shouldn't. Of course you can never be totally safe from social engineering, but at least you should present the system in a way that makes the social engineers' job harder.

Complicated things like webs of trust are, I think, a no-go because they ask the user to solve the same non-computable trust problems a trustless network would have to solve except with lots of people and other entities. If something is non-computable for machines it is also non-computable for humans.

> One idea I've had is a hybrid system combining a centralized database and a decentralized DHT. Both are available and they back each other. The central database can take over if the decentralized DHT comes under attack and the decentralized DHT will work if the central system fails or is blocked (e.g. in a censorship-heavy country).

I've been considering doing federation similar to that. You have some node which is essentially a dedicated DHT node and a bunch of clients which use it as a gateway to access the DHT instead of participating themselves. So you have a lot of ostensibly related clients all using the same gateway and when they want to contact each other they get one hop access and no Sybil exposure. And if the gateway is down the clients can still participate in the DHT themselves so it isn't a single point of failure.

Yeah, that's basically the identical idea except in your model the centralized node(s) are the defaults and the DHT is fallback.

> Everything related to TUN/TAP on every platform is nearly documentation-free. :)

The Linux implementation never gave me any trouble. https://www.kernel.org/doc/Documentation/networking/tuntap.txt says how to create one and then you configure it the same as eth0.

Maybe the trouble with TAP-Windows is that it's idiosyncratic (to be kind) in addition to undocumented. Have you discovered any good way identify your TAP-Windows interface as something not to be molested by other TAP-Windows applications like OpenVPN? There is some language in the .inf about changing the component ID which seems to imply recompiling the driver and then probably needing a code signing key from Microsoft to make it work, but there has to be some less ridiculous way of doing it than that.

Umm... sorry to break this to you, but that's exactly what I did.

I had to do it anyway because I had to add a new IOCTL to the tap driver to allow the ZeroTier service to query multicast group subscriptions at the Ethernet layer. Windows has no such thing natively, while on OSX/BSD you can get it via sysctl() and Linux exposes it in /proc.

: