X-Git-Url: http://nsz.repo.hu/git/?p=epoint;a=blobdiff_plain;f=README;h=e621ae80bdc0cf5dbe79e246a44f836c8bad83ad;hp=711732965474387d06f60baf4950878af9596a84;hb=HEAD;hpb=cdc9cc137454aedc1cdd06af75d3123fca3ddc3f diff --git a/README b/README index 7117329..e621ae8 100644 --- 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.