X-Git-Url: http://nsz.repo.hu/git/?a=blobdiff_plain;f=README;h=e621ae80bdc0cf5dbe79e246a44f836c8bad83ad;hb=a6d3c7c07507062519a125e3f0f10d8a212fd483;hp=fed38094a262124a6ab8fbd6e24a2d1bba6d1c1b;hpb=8ca147172cc2ea4ad1033c9449fe1230e378e1f0;p=epoint

diff --git a/README b/README
index fed3809..e621ae8 100644
--- a/README
+++ b/README
@@ -1 +1,98 @@
-Server side code of the epoint transaction service.
+This is the source code repository of the epoint transaction service.
+
+Source
+------
+
+web:
+	http://nsz.repo.hu/epoint
+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.
+
+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.