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.


Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-03 11:31:11 (4 years 11 mons 16 days 12:28:00 ago)

I've got a question:

Am 02.08.2014 01:07, schrieb Adam Ierymenko:
I just started a personal blog, and my first post includes some thoughts I've wanted to get down for a while:


In this blog post you wrote:

> I designed the protocol to be capable of evolving toward a more decentralized design in the future without disrupting existing users, but that's where it stands today.

My situation: we wrote a p2p network for replicating state machines with byzantine fault tolerance.

That would be a kind of a "global database no single individual controls"; I actually like you "blind idiot god" term.  We always thought of it implementing some "general will" like the legal system in a constitutional state.  Not so different, isn't it?

So far we concentrated on building a practical, working system (e.g., self-hosting).  The networking layer is just a plug in.  And the default plugin was always intended to be replace with state-of-the-art implementations.  It will probably not scale and hence we never tested how it scales.  When looking at zerotier I'm asking: could this possibly be a transport plugin?

What we need:

A) Our identifiers are self-sealing.  That is, they are required to match some hash of the (initial) content and 4 more predefined meta data elements.  (We need this to prove their correctness; like in Ricardian Contracts etc.)

So we'd need to register one such identifier per peer in a DHT.

B) We need some kind of byzantine (Paxos alike) protocol, which is capable to convey hash verifying agreement on the proposed update.  (This is slightly more than most paxos implementations provide, since those are for some reason beyond me, designed to TRUST the origin of an update.)  Fortunately we have this code.  So what we really need is "network traffic" between peers identified by some key.

In understand that zerotier provides (B).  But since I see "some kind" of "noise" as identifier in zerotier, I'm unsure how easy it would be to get (A) too.

Further I take you "capable of evolving" as a warning: how far does the implementation deviate?




As you are sharing my reservations wrt. Bitcoin while at the same time looking for trust and accountability you might want to look at how those alternatives compare.  The 51% of hash power is just one way.  Byzantine agreement requires 67% of traitors.  However the latter are *well known* and contractually bound.  Advantages: a) speed: transactions take a fraction of a second over WAN, b) privacy: data lives precisely where you expect it to be and is not leaked elsewhere.  Downsides: Bitcoin is open-join.  Anybody can participate.  With Askemos you get close-join.  Like WhatsApp: the owner needs to accept the other party before messages are taken.

Actually I'm currently gathering more info towards a fair comparison.  Comments welcome: