LoginRandom Images |
TitleServerDocumentationimg src="http://www.ideje.hu/TitleServer/img1.gif"
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.
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
A remarkable feature of TitleServer is to (during preparation of a transaction) find_tokens( value, ownerID )
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:
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.
|
Powered by TikiWiki CMS/Groupware