fix balance check in server logic
[epoint] / README
diff --git a/README b/README
index 7117329..e621ae8 100644 (file)
--- a/README
+++ b/README
@@ -1,14 +1,98 @@
 This is the source code repository of the epoint transaction service.
 
-Latest version should be available at
+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
+-----
+
+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 update weekly
+       ./all.bash
+(see http://golang.org/doc/install.html for details)
+
+to build and install epoint (into $GOROOT/bin) run
+       make
+
+
+Contact
+-------
+
+epoint@nsz.repo.hu - list address
+epoint+subscribe@nsz.repo.hu - subscribe
+epoint+help@nsz.repo.hu - get help
+
+
+About
+-----
+
+The goal of the epoint service is to provide secure and efficient
+bookkeeping of transferrable debt denominated in currencies that
+are issued by the anonymous clients of the system themselvs.
 
-This project is about redesigning the ePoint Transfer Protocol.
-Description and source code of the old design can be found at the
-epointsystem.org website:
+The central bookkeeping is designed to be auditable by any client
+and proofs can be constructed in case of errors.
+
+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 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:
        https://www.epointsystem.org/trac/epoint_issuer
        https://www.epointsystem.org/trac/website
 
+
+Overview
+--------
+
+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
+draft documents. A draft specifies the drawer (the client who
+transfers the debt), the beneficiary (the new holder of the
+debt), the issuer (the client who owes) and an integer amount
+that is transferred. The draft is signed by the drawer.
+
+Drafts with different issuers are independent, the debt of
+different issuers are denominated in different currencies and
+cannot be mixed.
+
+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.
+
+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.
+
+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.