------
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.git
Build
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
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:
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
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.