nsz Git - epoint/blob - README

   1 This is the source code repository of the epoint transaction service.
   2
   3 Source
   4 ------
   5
   6 web:
   7         http://nsz.repo.hu/epoint
   8 git:
   9         git clone git://nsz.repo.hu:45100/repo/epoint.git
  10
  11
  12 Build
  13 -----
  14
  15 epoint-server depends on a patched version of the latest go source
  16 to get it (see http://golang.org/doc/install.html for details) run
  17         hg clone https://go.googlecode.com/hg/ go
  18         cd go/src
  19         hg patch path/to/epoint-server/patches/*.diff
  20         ./all.bash
  21
  22 to build and install (into $GOROOT/bin) run
  23         make
  24
  25
  26 Contact
  27 -------
  28
  29 epoint@nsz.repo.hu - list address
  30 epoint+subscribe@nsz.repo.hu - subscribe
  31 epoint+help@nsz.repo.hu - get help
  32
  33
  34 About
  35 -----
  36
  37 The goal of the epoint service is to provide secure and efficient
  38 bookkeeping of transferrable debt denominated in currencies that
  39 are issued by the anonymous clients of the system themselvs.
  40
  41 The central bookkeeping is designed to be auditable by any client
  42 and proofs can be constructed in case of errors.
  43
  44 To convert between the various currencies a currency market can
  45 be used that is outside of the scope of the epoint service.
  46
  47 The agreements and authentication methods between the issuers and
  48 holders of debt is outside the epoint system as well.
  49
  50 This project originates from the ePoint Transfer Protocol.
  51 Description about that design is at the epointsystem.org website:
  52         https://www.epointsystem.org/trac/epoint_issuer
  53         https://www.epointsystem.org/trac/website
  54
  55
  56 Overview
  57 --------
  58
  59 An epoint server is a large billboard, where clients can place
  60 draft documents (acknowledging debt, "i owe you").
  61
  62 Any client can issue debt (issuer), and a client holding the
  63 debt (holder) can transfer parts of it to any other client using
  64 draft documents. A draft specifies the drawer (the client who
  65 transfers the debt), the beneficiary (the new holder of the
  66 debt), the issuer (the client who owes) and an integer amount
  67 that is transferred. The draft is signed by the drawer.
  68
  69 Drafts with different issuers are independent, the debt of
  70 different issuers are denominated in different currencies and
  71 cannot be mixed.
  72
  73 The balance of a client with respect to an issuer is the
  74 agregate value of all the drafts that transfer debt of the given
  75 issuer to or from the given client.
  76
  77 An important constraint of the system is that a holder cannot
  78 transfer more debt than its balance. Such drafts are invalid and
  79 must be rejected. If the issuer is the drawer of a draft then
  80 there is no such constraint. The balance of the issuer is <=0
  81 and the balance of a holder of the issuer's debt is >=0 at any
  82 given time. All the balances together give 0.
  83
  84 The main purpose of the server is to make it easy to check the
  85 current balance of a client.
  86
  87 The server stores all the drafts and the public keys submitted
  88 by the clients so the drafts are verifiable. The ordering of the
  89 drafts matters when the constraints are checked so the balances
  90 are maintained in such a way that there is no ambiguity. Every
  91 change to a balance is recorded in the form of a server signed
  92 certificate. The certificate declares the new balance with a
  93 timestamp and references documents (draft, other certificates
  94 and keys) required to verify the claim. The ordering is
  95 guaranteed by using cryptographic hash references. The hash
  96 chain of documents makes it possible to audit the system and the
  97 signatures allow the construction of proof if the server makes
  98 mistakes.