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.


Nicholas H.Tollervey [LibreList] Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches 2014-08-06 12:58:21 (6 years 7 mons 27 days 21:03:00 ago)
Hash: SHA1

On 03/08/14 13:56, Jörg F. Wittenberger wrote:
> Nicholas: does Drogulus have an idea about contracts?  Should I include 
> it in the comparison or does it not qualify?  I'm not sure. See here:
> http://ball.askemos.org/?_v=wiki&_id=1786
> Not related to Drogulus but to trustworthy (a.k.a. trustless) contract 
> handling, one more note.


Sorry, I missed this in the deluge of email that is my inbox. ;-)

Items stored in the drogulus are designed to stand on their own and be
self-verifiable through cryptographic signing.

An item stored in the DHT is a collection of named fields and associated
values (it's a JSON object):

* value - the actual value to store.
* timestamp - a UNIX timestamp representing when the creator of the item
thinks the item was created (so it's easy to work out the latest version
of an item given two candidates).
* expires - a UNIX timestamp beyond which the creator of the item would
like the item to expire, be ignored and deleted in remote nodes.
* name - a meaningful name given by the creator for the key.
* created_with - the version of the drogulus the creator used to
generate the item.
* public_key - the creator's public key.
* key - the SHA-512 value of the compound key (based upon the public_key
and name fields) used as the actual key on the distributed hash table.
* signature - a cryptographic signature generated using the creator's
private key with the fields described above.

The public_key field is used to validate the signature value. If this is
OK then the compound SHA-512 key is checked using the obviously valid
public_key and name fields.

This ensures both the provenance of the data and that it hasn't been
tampered with. Any items that don't pass the cryptographic checks are
ignored and nodes that propagate them are punished by being blocked. It
also confirms that the generated SHA-512 key for the item is correct
given the public_key and meaningful name ensuring no other entity may
set items with this unique key (assuming no key collision vulnerability
in the hashing function).

Does this make sense..?

Happy to answer questions and please remember, this is more an
experiment in code. I'm currently working on the drogulus on the
"rewrite" branch here:


Getting quite close to something releasable. ;-)

All the best,


Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/