X-Git-Url: http://nsz.repo.hu/git/?a=blobdiff_plain;f=README;h=e621ae80bdc0cf5dbe79e246a44f836c8bad83ad;hb=a6d3c7c07507062519a125e3f0f10d8a212fd483;hp=b4c986e148115848cffe5e7777e90ade4a206dd7;hpb=4c50dbc35a8e8946776e02b9c9caee9bcc2da9f6;p=epoint diff --git a/README b/README index b4c986e..e621ae8 100644 --- a/README +++ b/README @@ -4,30 +4,31 @@ 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 ----- -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 - hg patch path/to/epoint-server/patches/*.diff + hg update weekly ./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 ------- -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 @@ -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 -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: @@ -52,14 +53,11 @@ 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 @@ -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. -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.