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
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 08:34:56 (6 years 4 mons 2 days 14:39:00 ago)
Am 05.09.2014 15:51, schrieb Dominic Tarr:
> jorg,
>
> The short answer is no; secure-scuttlebutt is eventually consistent so
> you cannot easily enforce invariants like that.
>
> On the other hand, computers are fundamentally eventually consistent
> because of the finite speed of light.
> So, you are always building layers of consistency on top of eventually
> consistent layers, so there is probably a way you could do this.

This sentence feel to me as if you where taking owls to Athens.  I 
completely agree with you here.
With an exception in the subjunctive in the last half sentence: BALL's 
database replication is eventually consistent too and the invariant I 
wrote about is precisely what the next (agreement) layer at top of it 
provides.

> There is *probably* a way to do it, but I think that life is easier if
> you embrace things like eventually consistency and
> design things to work with those principles instead of attempting to
> box them into something they arn't.
>
> The feed in secure scuttlebutt is verifiable - just by using simple
> crypto primitives (hashes and signatures) it's possible to verify that
> they gave you the correct data, even if it was via a third party. You
> do not have to trust them to not fiddle with the data because they
> could not do that and avoid detection. But you *do* need to trust them
> to pass on the data when they should.

This is the point at which I call for the agreement layer and active 
replication.  Devices are down or disconnected for all sort of reasons.  
But only at a certain probability.  Keeping them up at about 2/3rd of 
the time is usually easy enough.  At this point a peer not passing data 
when they should can not avoid detection either.

> There is no straightforward or
> general way to cryptographically prove that they did indeed perform a
> such as relaying your data for you, hence we need to calculate a trust
> value.

Still this calculation of "trust value" I did not find.  Or did not 
understand.  I'm always interested in such things.

> The thing you seem to be describing is certainly quite complex,

Actually it's not.  Undergrad CS students took usually about three days 
interactive discussion to grasp the idea and a few weeks to build usable 
applications.  But is seems to be endless hard to get the same results 
using written documentation.

The payment system (current draft) for instance is here
http://ball.askemos.org/A876f1fe6998ca9d43f2e66c11a3f0d4a
that is, this is one wallet of it. You want to log in using "public" to 
find the actual thing.  It's controlled by a single (though having 
80kLOC large) source file: 
http://ball.askemos.org/Aa176138e655369f8c01c3044ced70cfc
(be sure to read that in whitespace preserving source mode, do NOT let 
the browser mangle it and skip XML comments).

> and currently we are focusing on figuring out how to design much
> simpler things that do not require consistency.

I see.  I filed a note to self for SSB under eventually consistent DB 
layer.  You see: Askemos does NOT depend on BALL as an implementation.  
I'm always eager to replace as much of our code with things from 
elsewhere until we can run our stuff without any reference to our code.  
THAT would be the implementation independence I strive for (and take 
away much of the burden of maintaining the code during my days as an old 
man – not there yet).

/Jörg

>
> Dominic
>
>
>
> On Thu, Sep 4, 2014 at 6:45 AM, Jörg F. Wittenberger
> <Joerg.Wittenberger@softeyes.net> wrote:
>> Am 03.09.2014 01:25, schrieb Paul Frazee:
>>> For some interesting reading, I'll refer you to Dominic's project,
>>> https://github.com/dominictarr/secure-scuttlebutt.
>>>
>>>
>> Got one question here: this seems to replicate data.  Does it protect
>> against malicious updates too?
>>
>> To illustrate: I'm currently working on some simple payment system. (I
>> picked "payment system" because that's something everyone understands
>> without explanation of the app's purpose; however it's only an
>> application which requires the features to be demonstrated.)
>>
>> It works like this:
>>
>> * Every "wallet" is a (sqlite) database holding a balance table of two
>> columns: amount and currency. (Together with some user interface.)
>> * Users can create orders (documents) to transfer some amount to some
>> other wallet. The receiver can either accept or reject.
>>
>> (There is more, like maintaining nick names for wallets.  But those are
>> irrelevant at this point.)
>>
>> The important point: the wallet must make sure that it no order exceeds
>> the senders balance and no receiver can accept the same order twice.
>> (The total the currency must not change.)
>>
>> Having a eventually consistent database is not enough here: we can't
>> trust the peer to store a correct value.
>>
>> Our solution is rather simple.  Each wallet is replicated (tolerating
>> byzantine faults) at several notaries.
>>
>> For a small world (like 5-20 peers) this could be *all* peers, to
>> simplify the situation for the time being.  Now members of the group can
>> readily use it.  Any attempt to cheat does not work.
>>
>> However: This can not transfer money beyond the boundaries of the
>> group.  (An incoming order would be signed by many notaries.  To no
>> effect: the group would only trust those notaries in the receivers set
>> and reject the order if the intersection of senders and receivers
>> notaries is too small.)
>>
>> For a larger world byzantine replication does not work, because it comes
>> at quadratic communication cost.  Instead we would create "virtual
>> banks": groups of individuals each running a peer and *contracted* (as
>> in "having signed a legal contract") to keep it mostly online and
>> prevent fraud.  Such a group could be used as an intermediary between
>> wallets running at too disjoint groups.
>>
>>
>> So if I wanted to build applications like that one on scuttlebutt...
>> possible?  How would I make sure the wallet is always correct?
>>
>>
>> Best
>>
>> /Jörg

: