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:
 ------
 
 web:

-       http://repo.or.cz/w/epoint-server.git
+       http://nsz.repo.hu/epoint

 git:
 git:

-       git clone git://repo.or.cz/epoint-server.git
+       git clone git://nsz.repo.hu:45100/repo/epoint

 
 
 Build
 -----
 
 
 
 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
        cd go/src

-       hg patch path/to/epoint-server/patches/*.diff
+       hg update weekly

        ./all.bash
        ./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
 -------
 
        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
 
 
 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
 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:
 
 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
 
 
        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
 
 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.
 
 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
 
 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.