From 29a432447760712a45fe3b09fd47eddfe6b4b535 Mon Sep 17 00:00:00 2001 From: nsz Date: Thu, 12 Jan 2012 09:56:27 +0100 Subject: [PATCH] fix overview in README --- README | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/README b/README index 92accab..fe52aa2 100644 --- a/README +++ b/README @@ -55,11 +55,8 @@ Description about that design is at the epointsystem.org website: Overview -------- -An epoint server is a large billboard, where clients can publish -draft documents (acknowledging debt, "i owe you") - -Draft documents are digitally signed by the clients and the -clients are identified by their public key. +An epoint server is a large billboard, where clients can place +draft documents (acknowledging debt, "i owe you"). Any client can issue debt (issuer), and a client holding the debt (holder) can transfer parts of it to any other client using @@ -86,12 +83,15 @@ given time. All the balances together give 0. The main purpose of the server is to make it easy to check the current balance of a client. -To achieve this the server needs to store all the drafts and the -public keys of the clients so the drafts are verifiable. The -ordering of the drafts matters when the constraints are checked -so the server must keep track of the balances in such a way that -there is no ambiguity. It must be easy to audit the server and -prove if it does not calculate the balances properly. This is -done using server signed certificates declaring the balance of -a client after each change and referencing related documents -(draft, previous certificates) with cryptographic hash. +The server stores all the drafts and the public keys submitted +by the clients so the drafts are verifiable. The ordering of the +drafts matters when the constraints are checked so the balances +are maintained in such a way that there is no ambiguity. Every +change to a balance is recorded in the form of a server signed +certificate. The certificate declares the new balance with a +timestamp and references documents (draft, other certificates +and keys) required to verify the claim. The ordering is +guaranteed by using cryptographic hash references. The hash +chain of documents makes it possible to audit the system and the +signatures allow the construction of proof if the server makes +mistakes. -- 2.20.1