fix balance check in server logic

[epoint] / README

diff --git a/README b/README
index b4c986e..e621ae8 100644 (file)
--- a/README
+++ b/README
@@ -4,30 +4,31 @@ Source
 ------
 
 web:
-       http://repo.or.cz/w/epoint-server.git
+       http://nsz.repo.hu/epoint
 git:
-       git clone git://repo.or.cz/epoint-server.git
+       git clone git://nsz.repo.hu:45100/repo/epoint
 
 
 Build
 -----
 
-epoint-server depends on a patched version of the latest go source
-to get it (see http://golang.org/doc/install.html for details) run
-       hg clone https://go.googlecode.com/hg/ go
+first a recent go build is needed (at least weekly.2012-01-15)
+       hg clone http://go.googlecode.com/hg/ go
        cd go/src
-       hg patch path/to/epoint-server/patches/*.diff
+       hg update weekly
        ./all.bash
+(see http://golang.org/doc/install.html for details)
 
-to build and install (into $GOROOT/bin) run
+to build and install epoint (into $GOROOT/bin) run
        make
 
 
 Contact
 -------
 
-discuss@epointsystem.org
-TODO: mailing list
+epoint@nsz.repo.hu - list address
+epoint+subscribe@nsz.repo.hu - subscribe
+epoint+help@nsz.repo.hu - get help
 
 
 About
@@ -44,7 +45,7 @@ To convert between the various currencies a currency market can
 be used that is outside of the scope of the epoint service.
 
 The agreements and authentication methods between the issuers and
-holders of debt is outside the epoint system as well.
+holders of debt are outside the epoint system as well.
 
 This project originates from the ePoint Transfer Protocol.
 Description about that design is at the epointsystem.org website:
@@ -52,14 +53,11 @@ Description about that design is at the epointsystem.org website:
        https://www.epointsystem.org/trac/website
 
 
-Design
-------
-
-An epoint server is a large billboard, where clients can publish
-draft documents (acknowledging debt, "i owe you")
+Overview
+--------
 
-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
@@ -76,23 +74,25 @@ The balance of a client with respect to an issuer is the
 agregate value of all the drafts that transfer debt of the given
 issuer to or from the given client.
 
-The main constraint is that a holder cannot transfer more debt
-than its balance. Such drafts are invalid and must be rejected.
-If the issuer is the drawer of a draft then there is no such
-constraint. The balance of the issuer is <=0 and the balance of
-a holder of the issuer's debt is >=0 at any given time. All the
-balances together give 0.
+An important constraint of the system is that a holder cannot
+transfer more debt than its balance. Such drafts are invalid and
+must be rejected. If the issuer is the drawer of a draft then
+there is no such constraint. The balance of the issuer is <=0
+and the balance of a holder of the issuer's debt is >=0 at any
+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 with respect to an issuer at any
-given time.
-
-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.
+current balance of a client.
+
+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.