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://repo.or.cz/w/epoint-server.git
   8 git:
   9         git clone git://repo.or.cz/epoint-server.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 discuss@epointsystem.org
  30 TODO: mailing list
  31
  32
  33 About
  34 -----
  35
  36 The goal of the epoint service is to provide secure and efficient
  37 bookkeeping of transferrable debt denominated in currencies that
  38 are issued by the anonymous clients of the system themselvs.
  39
  40 The central bookkeeping is designed to be auditable by any client
  41 and proofs can be constructed in case of errors.
  42
  43 To convert between the various currencies a currency market can
  44 be used that is outside of the scope of the epoint service.
  45
  46 The agreements and authentication methods between the issuers and
  47 holders of debt is outside the epoint system as well.
  48
  49 This project originates from the ePoint Transfer Protocol.
  50 Description about that design is at the epointsystem.org website:
  51         https://www.epointsystem.org/trac/epoint_issuer
  52         https://www.epointsystem.org/trac/website
  53
  54
  55 Design
  56 ------
  57
  58 An epoint server is a large billboard, where clients can publish
  59 draft documents (acknowledging debt, "i owe you")
  60
  61 Draft documents are digitally signed by the clients and the
  62 clients are identified by their public key.
  63
  64 Any client can issue debt (issuer), and a client holding the
  65 debt (holder) can transfer parts of it to any other client using
  66 draft documents. A draft specifies the drawer (the client who
  67 transfers the debt), the beneficiary (the new holder of the
  68 debt), the issuer (the client who owes) and an integer amount
  69 that is transferred. The draft is signed by the drawer.
  70
  71 Drafts with different issuers are independent, the debt of
  72 different issuers are denominated in different currencies and
  73 cannot be mixed.
  74
  75 The balance of a client with respect to an issuer is the
  76 agregate value of all the drafts that transfer debt of the given
  77 issuer to or from the given client.
  78
  79 The main constraint is that a holder cannot transfer more debt
  80 than its balance. Such drafts are invalid and must be rejected.
  81 If the issuer is the drawer of a draft then there is no such
  82 constraint. The balance of the issuer is <=0 and the balance of
  83 a holder of the issuer's debt is >=0 at any given time. All the
  84 balances together give 0.
  85
  86 The main purpose of the server is to make it easy to check the
  87 current balance of a client with respect to an issuer at any
  88 given time.
  89
  90 To achieve this the server needs to store all the drafts and the
  91 public keys of the clients so the drafts are verifiable. The
  92 ordering of the drafts matters when the constraints are checked
  93 so the server must keep track of the balances in such a way that
  94 there is no ambiguity. It must be easy to audit the server and
  95 prove if it does not calculate the balances properly. This is
  96 done using server signed certificates declaring the balance of
  97 a client after each change and referencing related documents
  98 (draft, previous certificates) with cryptographic hash.