Random Images



img src="http://www.ideje.hu/TitleServer/img1.gif"
  • Power user uses her own key to sign transaction requests for the Title Server
  • Web user is not too paranoid about security. She contacts her cyclos via https secure web interface. Cyclos stores her key, and signs transaction requests for the Title Server
  • If operators of a Title Server advertise only a relay (eg. Tor hidden service), not a direct address, than cyclos must also use that for communication (has no other choice)
  • DHT is Distributed Hash Table storage. Can be used by any parties to store crypted data, such as crypted transaction logs, certificates, etc...
    • in an extreme case, even sensitive data, such as the sequence-numbers of tokens (normally stored physically safe by the Title Server) could be stored  (encrypted, indexed) in DHT. In Such case Title Server only needs a few bytes of secure tamperfree storage and still able to know everything it needs for  decisions: its own secret key, and a 6 byte transaction-sequencecounter.
  • Helper Server can store replica of the primary database, and help several requests:
    • eg. calculate balance
    • find tokens for the transfer of a certain amount, so that as many token-ranges as possible can be merged with the existing token-ranges of the recipient
    • operators might get help from the Helper Server(s!) when they recover service in case of a Title Server failure
    • some Helper Servers might not be advertised

Title Server rules
- Tokens
There are 2^64 tokens in the token ID space. Theoretically each of them has its own properties and each property of each token can be changed individually. In practice, operations are carried out on a range of tokens. The TS also stores a range of tokens with identical parameters in a single storage record.
- Currencies
Every currency has an Issuer (UID), a nomination unit and a set of rules. Rules are instructions for the TS. A typical rule is:
“the Issuer can buy back bonds of this currency (C1) with C2 currency at a rate of R”
This means that such a transaction can be initiated by the Issuer alone.
Currencies have their own range in the global ID space. For example, if the range 1000000..1999999 is assigned to C1, then C1(100..199) is 1000100..100199 in the global ID space.
- Atomic transactions
Most transactions involve checking certain conditions and modifying multiple token ranges if the conditions are fulfilled. To ensure atomic transactions, every token has a sequence number that is increased every time the token is modified. Users involved in the transaction can request the status of their tokens from the TS, check the initial conditions and the sequence numbers. These numbers are then included in the token modification request, which is then signed by all involved parties. The TS carries out the modifications only if the sequence numbers are still the same and the signatures are present for all users whose tokens are modified.
- LETS example
LETS (Local Exchange Trading System) is an already popular way of creating community money. We provide a way to operate a LETS within a secure electronic system and also to connect different LETS communities. When operating many LETSystems, auditing the total issued amount of one person is important. Every LETS wants to make sure that its members do not have a debt more than MAX1 towards its other members and also that they do not have a debt more than MAX2 towards ANY OTHER LETS members. The later is possible with locking the tokens, as shown below.
· a new member sells his/her own Cm currency (not more than MAX1) to the LETS and receives LETS money (Cl).
· during the above transaction a lock is put on the token ID range MAX2..END of Cm. (this range should be unissued) The lock reference range (LRS..LRE) of the sold Cm tokens is set to this locked range while the “LOCKED” counter of the locked range is increased by one. This means that no more than MAX2 units of Cm can be issued to any LETS while the lock is active, and the lock can be deactivated when the Issuer buys back all of the Cm units sold to the LETS.
· a Cm unit owned by the LETS means that the member owes the LETS. A Cl unit owned by the member means that the LETS owes the member. So trading Cm for Cl generates no debt in either direction, it creates a credit limit to the member. (a classical LETS always keeps its balance on zero)
TS commands example: (L=LETS  A,B=members  MAX1=1000  MAX2=2000)
1. L member A gets a 1000 unit credit limit
Check if owner of Ca(0..999) is A (A requests token status)
Check if owner of Ca(2000..END) is A (A requests token status)
A sends the results to L
Check if owner of Cl(4000..4999) is L (L requests token status)
L sends the results to A
They create a token modification request (including the current sequence number of these tokens):
Set owner of Ca(0..999) to L
Set owner of Cl(4000..4999) to A
Set lock range of Ca(0..999) to Ca(2000..END), increase the lock counter of Ca(2000..END)
Both A and L signs this request and they send is to the TS
2. A pays 10 units of LETS currency to B
A requests token status of Cl(4000..4009)
A sends the certificate of initial status to B
Creates a token modification request (including the current sequence number of the token):
Set owner of Cl(4000..4009) to B
A signs the request and sends it to the TS
When the TS has replied with the certificate of owner modification, A sends it to B
- “Digital Coin” example
When a company needs a loan for production, alternatively to getting bank loans or selling shares of itself, it can sell pieces of its future production. A way of monetizing future production is described in Paul Grignon’s “Digital Coin Proposal”. We also believe that monetizing future production is a good idea. Together with connected LETS communities it might create a nationwide/global community currency system that helps fair business.
· The bonds backed by a specific product are given a unique currency ID
· Of course the buyer of such a bond wants to know the issued amount of bonds for a specific product. The TS can give a digitally signed certificate about the total issued amount.
· If the bonds are bought back in the same order they were sold in, the owners of the bonds don’t have to care about the amount issued after their purchase

TODO: detailed Title-Server atomic transactions (with exact conditions and error codes. Success code should be 0).

TODO: details of integration with cycles.org.
  • cycles.org is a "user-friendly" frontend for token-transactions (markets, community-currencies).
  • Title-Server is essential to protect against over-issuance (make it detectable)
  • Title-Server is essential to protect against database corruption or operator (or cracker-intruder) tweaks (make it detectable)
  • Title-Server will issue proper, signed certificates of the transactions, the necessary data about every token effected. These certificates, when compared to the issued amount (serialnumbers), or compared to other transactions (serialnumber, sequencenumber) reveal problematic behaviour
    • we'll operate a "collision detection service" (CDS) where users, or servers can submit some data about their transactions. Likely direct serialnumbers and sequencenumber, but only hashed other data. Some CDS might only accept signed transaction certificates. When CDS detects collisions, it will warn the users that submitted the 2 transactions. If original transaction certificates not yet available, it will ask for them to see if malfunction happened (if non-signed certificates were uploaded, those might not match real data, so they do not prove anything, but still might be a useful indication for the users). CDS is a simple web-database application, running on ordinary webserver.
  • Title-Server allows someone to operate his own keys. Easy-going users can authorize a service, especially for small sums. This way they lose some, but not all security, malfunction and overissuance-detection features.

The extremely strict security recommendations (dedicated hw, no-OS) only applies to Title-Server.

The  extremely strict security recommendations do NOT apply to the host running cyclos.org (or other user-friendly service).

The  extremely strict security recommendations do NOT apply to the host running a a "collision detection service" CDS. CDS could be a redundant network (similar to bittorrent) or "data subscription", so any member of a given LETS can set up his CDS and subscribe for data to detect misbehaviour (collision).


Without Title-Server, someone must see every (plaintext) detail of ALL transactions (not just his) to be able to detect overissuance ( everyone must see every transactions), which encourages fraudulent behaviour (banker's invented income-tax to - just the oppositve of claims - tax the poor and let the huge wealths untaxed ). With ripple or opencoin.org, overissuance is undetectable.

Implementation notes:

Title-Server internal data storage seems to require rtrees for some operation, not btrees. Eg. serialnumber is one key, (owner, serialnumber ) is another, compound key. Sqlite might be used to make this easier.

Even if sqlite is not used, abstraction of the "get_data_from_storage()" is essential so

  • it can be easily refactored later
    • adding a suitable backed database engine
    • or writing a highly efficient implementation from scratch
  • different DB implementations can be easily swapped, and compared (regression-tests, benchmarks, "stress-tests")
 A remarkable feature of TitleServer is to (during preparation of a transaction) find_tokens( value, ownerID )
  • value: total value of tokens
  • ownerID: that are preferrably the exact neighbor of (or close to) tokens owned by ownerID. This makes merging of token-ranges more frequent
 The exact neighbor condition is trivial. The close to requires a "neighbor metric" metric( ownerID1, ownerID2) practically for which the triangle inequality hold. Possible solutions:
  • lower Hamming distance preferred. In other words, the distance in a hypercube (edges to travel). The drawback is that the operation cost is the length of the whole key, vs. just the first few bytes (3..4 bytes on avarage) for the other proposals.
  • lower abs(ownerID1 - ownerID2). Another trivial metric. Not sure if migration is as efficient as the hamming.
  • lower (ownerID1 - ownerID2). The above, without the abs(). Not sure if this works well at all.
  • ...
  • possibly the DHT-s and bittorrent research has come up with something, a data-proximity "migration" solution

Note that all the TitleServers involved in a currency should use the same neighbor metric for that currency. However, for different currencies, neighbor metric can be different.



Created by: Fefe. Last Modification: 2009-06-01 (Mon) 17:10:42 CEST by cell.