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.


Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-05 06:51:59 (6 years 1 mon 22 days 13:02:00 ago)

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.

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. 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

The thing you seem to be describing is certainly quite complex,
and currently we are focusing on figuring out how to design much
simpler things that do not require consistency.


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