PS: Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches
- Jörg F. Wittenberger
- 2014-08-07 @ 10:00
Am 07.08.2014 11:31, schrieb Jörg F. Wittenberger:
> BAIL: a mixture of XSLT, a python-style syntax (a.k.a. "sweet
> syntax"), a pure functional Scheme subset and SQLite. Very funny to
> work with, because each object has it's private table space - zero DB
> administration. However this language is certainly not the point.
Little off-topic: also funny is BAIL's take on parallelism. Tuns out
that is was a highly common pattern to read objects from via identifiers
returned by SQL queries and alike sources. This often requires high
latency network traffic. Therefore xslt:for-each and the alike
xsql:for-each evaluate their template for all selected values in
parallel. xsl:variable do syncing. The application programmer is never
Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches
- Nicholas H.Tollervey
- 2014-08-15 @ 16:46
-----BEGIN PGP SIGNED MESSAGE-----
On 07/08/14 10:31, Jörg F. Wittenberger wrote:
> Am 06.08.2014 13:58, schrieb Nicholas H.Tollervey:
>> Items stored in the drogulus are designed to stand on their own
>> and be self-verifiable through cryptographic signing.
> Thanks for your feedback.
> I see quite some interesting things in Drogulus.
> However I'm "sort of" skeptic when I read "crypto signing". This
> term is too generic and too often implies secret key crypto.
> However an important part of a signature is in these schemes hidden
> in the process: as a proof of integrity, we are interested in a
> hash over the object's content. This proof should hold even if the
> secret key was lost or published.
The drogulus uses public key cryptography (RSA) for signing digital
>> 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.
> When it comes to contracts, one might find it a good idea to define
> a slightly higher level hash function: extract (or attach) relevant
> information to assert provenance: creator, witness, time etc. and
> hash these together with the hash of the actual value.
So the creator (via their public key) and time of creation are all
constituent in creating the hash.
> Now if you take this hash as canonical identifier for the object,
> you can always proof it's integrity. See also:
> http://www.iang.org/papers/ricardian_contract.html for yet another
> explanation of the same concept.
Yes, that is correct.
> Question: Am I correct to understand that the "key" field serves
> this purpose?
It is, indeed a unique identifier for the item.
> I'm a bit concerned about the inclusion of some public_key here.
> This identifier should IMHO only cover non-repudiable, public (or
> semi-public) meta data. No private data an nothing one would ever
> want to change.
I'm not sure I understand you completely. The public key is required
in order for third parties to validate the signature (created with the
associated private key).
>> 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
>> Does this make sense..?
> Yes, quite a lot.
>> Happy to answer questions and please remember, this is more an
>> experiment in code.
> I fully understand that. See: in about 2000 I started coding
> around similar ideas. As the system majored, we ran into various
> additional ideas. Maybe some are interesting or inspiration:
> Once we have the DHT, what do we do with it? I'd like it to handle
> my conversation and business. Publications, private messages,
> archive+backup, calendar, notes etc.
Quite... the drogulus is supposed to be application agnostic.
> So I need an environment where I see agents (be them accounts
> representing human users or automated, autonomous processes)
> communicating via asynchronous, unreliable, unidirectional
> messages. That's how we observe human interaction in writing.
> Humans or juristic persons sending letters, registered mail etc.
Again, quite. Actually, it's not just humans - I've been reading quite
a bit of literature on insect interactions, communication and
behaviour. A good overview and a book I particularly enjoyed was
Deborah Gordon's "Ant Encounters - Interaction Networks and Colony
> Side note: Tuns out documents like contracts (which is what
> "business" boils down into) could seen as a finalized subclass of
> agents which just don't change state ever. However in practice a
> fuse mounted directory at my desktop is just yet another such
> agent, certainly changing state.
Hah... a trivial distributed "Dropbox" clone built with fuse is one of
my target "quick example" applications (a la "create a blog" for web
OK... I'm going to call a time-out. I've read the following but won't
comment simply because I'm about to leave to spend some time on a
remote Scottish island without internet (but I wanted to reply before
I left the relatively connected location of the mainland - I'm playing
I'll re-read what follows (which upon first reading is very
interesting) and reply in full when I'm back on dry land in about a
week's time. Many apologies, but I'm a sufferer of the intractable
> Next I need a dispute (or debug) mode. This must be deadly simple:
> "pull the network plug".
> At this point I still want to be sure I have all *my* data and can
> access it. (Sorry for the complication wrt. DHT design. ;-)
> Now we know that I have one copy of all data I *really* care about
> which I can physically secure.
> At this point we can ask how we may update automated agents.
> Sometimes they might just have a single owner, but often control is
> to be purposefully split. At this point the GET/PUT semantics are
> no longer enough. We need some kind of custom, version control
> alike check in script to be run to verify that the request is
> permitted and complete for this object. It looks like a good idea
> to have a type property in the agent object pointing to another
> (signed) object which holds the script code and important: human
> readable terms and conditions. The other object would be the
> contract governing the agents actions on incoming requests. No
> script object found: either no updates or locate script in the
> object itself.
> Now we need "trust but verify": since we must not allow any single
> human to control the agent, we can not allow a single computer to
> compute the update and then somehow copy the new state to other
> peers. After all the origin peer might be a traitor. We need
> autonomy from individual intent for these agents. Therefore we
> have several peers (notaries) commissioned to backup the process
> and verify proposed updates. Instead of blindingly accept any kind
> of update, those accept an update request and transform it into the
> actual update (or the script may reject the update for application
> defined reasons. So the script is run in a sandbox at each
> Let's care for a moment about privacy. Crypto always has a chance
> to break for many reasons. And crypto is in the way of autonomous
> automated agents and often in the way to the user too. Crypto
> relying on secret keys is great on the wire for data in transit.
> For data at rest, it's a risk increasing over time. Instead we
> ask: which peers do we commission to such an agent? This set
> should really be controlled by the users. (I.e., the update policy
> script *must* be able to deny changes.) This is a trust decision
> wrt. the person administrating the peer and the peer hardware and
> maybe more. Nothing technological means can judge; it's a judgment
> about those very means among more. Ergo: publications and messages
> may leave the commissioned set, private data will never.
> Eventually I wonder how much effort it would be to maintain those
> expire times. I don't want to do that manually. Maybe there could
> be an automated garbage collector? Establish a link structure from
> your user account and everything not reachable from any local user
> may be removed on this peer.
> For the script language: it should be first and foremost a
> "hashbang" type of a language: simple and often only used to start
> the real interpreter for the contract script at hand. However
> there is nothing bad about having a powerful language to be started
> that way. We had about ten developers of varying experience (from
> bachelors to full time contracted CS masters) in a working
> environment with close feedback test and develop atop of our
> prototype for several years while we where working on the
> underlying replication engine and feature. Too many features that
> is, see "fuse" before. In this time we grew quite a flexible
> language BAIL: a mixture of XSLT, a python-style syntax (a.k.a.
> "sweet syntax"), a pure functional Scheme subset and SQLite. Very
> funny to work with, because each object has it's private table
> space - zero DB administration. However this language is certainly
> not the point. The CoreAPI to control the DHT entries is much more.
> It's only seven required elements ad eight more to make it
> practical. http://askemos.org/index.html?_v=search&_id=1728 (the
> documentation is a little terse ;-)
> Do those ideas make sense to you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches
- Jörg F. Wittenberger
- 2014-08-15 @ 17:21
Am 15.08.2014 18:46, schrieb Nicholas H.Tollervey:
>> Question: Am I correct to understand that the "key" field serves
>> this purpose?
> It is, indeed a unique identifier for the item.
>> I'm a bit concerned about the inclusion of some public_key here.
>> This identifier should IMHO only cover non-repudiable, public (or
>> semi-public) meta data. No private data an nothing one would ever
>> want to change.
> I'm not sure I understand you completely. The public key is required
> in order for third parties to validate the signature (created with the
> associated private key).
May I ask: why does it have to be that way?
Experience teaches that public/secret key schemes need to be change over
time. We call them "circumstantial" for the dependency on a secret
being kept secret.
It would be IMHO much better if the proof would be possible even without
relying on PKI limited by such secrets.
Most signature schemes actually sign a hash of the underlying info
anyway. Why not expose it as an independent proof?
> Quite... the drogulus is supposed to be application agnostic.
(as is Askemos ;-)
>> So I need an environment where I see agents (be them accounts
>> representing human users or automated, autonomous processes)
>> communicating via asynchronous, unreliable, unidirectional
>> messages. That's how we observe human interaction in writing.
>> Humans or juristic persons sending letters, registered mail etc.
> Again, quite. Actually, it's not just humans - I've been reading quite
> a bit of literature on insect interactions, communication and
> behaviour. A good overview and a book I particularly enjoyed was
> Deborah Gordon's "Ant Encounters - Interaction Networks and Colony
No, don't do that to me! Ant's. Yes, sure I looked at those too!
>> Side note: Tuns out documents like contracts (which is what
>> "business" boils down into) could seen as a finalized subclass of
>> agents which just don't change state ever. However in practice a
>> fuse mounted directory at my desktop is just yet another such
>> agent, certainly changing state.
> Hah... a trivial distributed "Dropbox" clone built with fuse is one of
> my target "quick example" applications (a la "create a blog" for web
Want one? Takes a minute. ;-)
> OK... I'm going to call a time-out. I've read the following but won't
> comment simply because I'm about to leave to spend some time on a
> remote Scottish island without internet (but I wanted to reply before
> I left the relatively connected location of the mainland - I'm playing
> email catch-up).
See you soon.