TitleServer

• As of 2011, instead of the somewhat bloated (and troublesome to deploy, and impractical to verify that the underlying virtual machine is free of backdoors) java server, a go (cleanroom) implementation is made that supports arbitrary number of issued currencies:
  
  
  
  • git://nsz.repo.hu:45100/repo/epoint
  
  
  • OLD: previously at http://repo.or.cz/w/epoint-server.git
  
  
•  Deployed test-server http://epoint.vems.hu:8080/

Market-account patch was applied. Marcell ran some tests (including transferring different currencies to same key), but more tests will follow (do we have test-scripts ?).

Reason for this patch: we must be able to send DIFFERENT currencies to the market account. (otherwise the market would need to create, maintain and advertise an arbitrary number of accounts, one for each currency => this would make the system very complex, and make the Jan 9 demo impossible). This change does not make the transaction-server more complex at all (actually, releasing unnecessary restrictions makes the server simpler). See http://epoint.vems.hu:8080/certby/key/ ... and http://epoint.vems.hu:8080/certby/key.serial/ (btw, feel free to run tests in this instance) it's just the case that the

ABE0AEE05319313939A355EC1090AEEC462BBBFC_1414D6310970BE270131B0BE996EE26664E95662

differs from

80A0FCF69AFD9F4EF981FDD2BDDD69A3D20F775E_1414D6310970BE270131B0BE996EE26664E95662
because the issuer is different (serial=1..2..3 means different cert for these accounts). Globally speaking, the account is identified by transaction server, issuer, account (3 fingerprints).

Future effects:

• in the reports, the issuer and account will BOTH be present (like it is present in the draft, debit-cert and credit-cert already anyway !)
• short "request-payment" documents will NOT specify currency, only the target account and amount (so it can remain really short).
  • The wallet will use the DEFAULT currency for the target account. So the concept of DEFAULT currency (epoint-client h <default currency issuer>) is useful. But not a restriction, so the transaction-server will not need to care about that.

• posting data from key/1414...txt file: curl --data-urlencode "key@key/1414D6310970BE270131B0BE996EE26664E95662.txt"  http://epoint.vems.hu:8080/submit
  
  • Convenience source and key files for fefe: http://cell.dyndns.ws/del/go/  (also contains a small form.html patch so action="/submit"  (NOT "localhost:8080/submit"). Was prepared the following way:
  • git clone git://nsz.repo.hu:45100/repo/epoint  is the actual code (after that, git pull to update)
  • install go (hg clone https://go.googlecode.com/hg/ go), BUT
    
    • patch -p1 </svn/epoint-server/patches/sig.diff
    • patch -p1 </svn/epoint-server/patches/dsa.diff
    • above patches HAD TO be applied earlier, but apparently not needed if hg update -d 2012-01-16
      is used to build go from 2012-01-15 or 16th (not the release or the latest... openpgp location was changed in go upstream, split to separate library, that will need some syntactic changes)
    • export GOROOT=/svn/go/ ; export PATH=$PATH:$GOROOT/bin
    • git-dir/epoint-server$  . pkg/deps.sh ; make
    • echo secret | /svn/go/bin/genkey tesztpetak key.sec key.pub > key.fpr  (creates dsatool compatible keypair)
    • $GOROOT/bin$ epoint-server
      2011/12/31 14:25:44 start service on :8080, server key id: 8788569633F08B953C28146F003FFEBF481518C9
    • http://localhost:8080/form.html  will help with transactions: The curl command hint helped a lot. I had to submit in 4 steps: key1, key2, draft and debit documents (of course, after key1 and key2 belong to creation of accounts, only needed once; the actual transfer is made in 2 steps, this is for future scalability).
    • note, TODO: while the manual posting of the documents (keys, draft and debit certificate) worked, the ./epoint-client s /tmp/1_to_65BC did not work (said nothing just waited indefinitely). Needs fix
    • TODO: how to query balance ?
  • we are modifying the market to be compatible with currencies issued via the go epoint-server
    • debit-cert is NOT used by the market. The client/wallet must get a credit cert, and post that to the market
    • credit-cert (used for deposit to a market account) uses a different template, see below
    • draft-cert (used to withdraw from a market account) template, see below
    • LATER: for the go-server, (or any "multiissuer") a currency is identified by the transactionserverkeyfpr:issuerkeyfpr  fingerprint-pair. This can be stored in one field in the database, and usually handled as one ID (the currency_ID. Luckily the  byte[] IssuerFPR used all over the place inside the market is transparent), except during the signature verification: the transactionserverkeyfpr part will be  used for that.
    • The simplest way (~hack) now (assuming 1 multi-issuer server) seems to use CONSTANTIssuerFPR="8788569633F08B953C28146F003FFEBF481518C9" in L860: if (!FPRUtils.compareFPR(SignerFPR, CONSTANTIssuerFPR))....
      • the related go-issuer pubkey can be found on epoint.vems.hu:8080 but not always available.

At this point document creation and verification is very slow
that's where performance could be improved a lot

the server should be transaction safe now, although the implementation
is naive so performance could be improved

storage is naive as well but these are low priority problems

more pressing issues are:
proper startup handling (masterkey should sign the serverkey)
cross references between certs
maintaining a list of unreferenced certs
creating server "notice" certs periodically referencing all prev certs
create credit cert even if debit cert is not submitted
verify signature only when necessary (first item in a hashchain)
handle subkeys and alternate serverkeys
protocol test
server health/availability monitoring, diagnostics
conditional cert semantics (maturity, expiry date)

and the real issues are:
finalized protocol (denomination, key->issuer list lookup, tree sums for fast audit)
ddos protection (transaction cost logic, keyserver protection..)
error handling and reporting semantics (insufficient funds, bounces, network errors etc)
handling of fatal server errors, and submitted inconsistent documents
semantics of first cert, server status reports and other non-transactional documents
multi server issues (replication and scaling)
server administration/update without restart and restart mechanism
usability evaluation: long key.issuer id, various client errors (key handling issues etc)
Pwallet on linux
 http://ideje.hu/pwallet/pwallet_linux.jpg
 

SOLVED ISSUE:

With the "old" server, if we want to query the balance of an account, first we get the contents this file:

http://server:port/certby/key/XXX_YYY where XXX is the currency fingerprint and YYY is the fingerprint of the holder.

• see files in: http://epoint.vems.hu:8080/certby/key/ RENAMED TO http://epoint.vems.hu:1111/certby/key.issuer
  
  • This tells us the ID of the last creditcert, from which we can obtain the balance of the holder).
  • /certby/key.serial is also renamed (So we now have /certby/key.issuer.serial and /certby/key.issuer).

Also there's one more difference: /draftby/key.issuer.nonce (new server) <-> /draftby/key.nonce (old server)

The simplest transaction server allows only one transaction type: transfer of V tokens from A to B, see certificate examples below (from the epoint-server.git "go issuer").

• draft : (signed by A!) authorizes transfer of V tokens (originally issued by issuer key I) from A to B
• debit certificate: transaction server certifies the A-=V
• credit certificate: (only after the debit has been processed transactionally safely): transaction server certifies the B+=V
  • the reason for this "splitting" is scalability. This design allows dozens (or more: arbitrary number of) servers (even if servers are partitioned according to account keys, not the issuer's key), with N*billions of transactions / day total .

draft:

debit certificate:

credit certificate:

Answer to a Brasil guy about trading between Brasil and EU in community currency:

The base-technology is available http://www.epointsystem.org/
but educational materials will be required on how to use it (non-trivial) as a convertible community-created currency.
In short communities can create convertible non-inflating  liquidity (money). You will want to cooperate with private persons or company partners, at least 10-20 recommended per community. In the end someone in Brasil should also join circle who use similar currency who receive payments from abroad (possibly EU or best, from Hungary).
The end-result of the clearing system is that it's not necessary to use the fraudulent money supply for most transactions: internal inside the clearing system

• everyone can verify the total amount of the issued currency
• only the effected parties see transaction
• and everyone only sees their own balance
• not revealed to anyone else, even the database administrator, and especially authorities

If some individual or community depleted their liquidity, they might need to provide valuable goods or services or money to someone else with connectivity to the system.
Even if they transfer bank money (remember, as soon as the system catches up, with at least a few hundred parties per country, it's only a small percentage of total traffic), it's usually domestic, or even same bank or local geographical district.

One can imagine this way: you send payment to someone in Brasil domestically, not to EU. Those who want to pay from EU to Brasil send inside EU, and the slow and costly international transfers are bypassed in a large percentage.

Note that it's the only practical solution of the "economic depression", "mathematically unpayable debt" and many other related anti-social phenomena induced by the fraudulent money supply (banks creating money that someone else gives their values for, but banks profiting from getting real values when they spend the interest).

The money supply worldwide shrinks because of old loans being paid off. This shrinking can and does cause worldwide depression. (one can hear lotsof blabla about the reasons, drawing attention from the real, most significant reason of the money supply created by private banks fraud). This shrinking (unlike a hurricane) is not a natural phenomena, but engineered by the banking establishment. The idea is same as in 1929-1933: to make people accept losing their job, finally their homes and production assets (businesses) without understanding how money is being created (loaned into existence) and vanishes and the consequences.

Waiting for the banking establishment or politics (that caused the situation) to provide cure does not make sense. People need to use technology to create a money supply and learn to prosper with a shrinked amount of bank-created money, or even without bank-created money.

Read Daniel A. Nagy: "On Digital Cash-Like? Payment Systems" for an introduction to the topic. The paper details that anonymity (eg. David Chaum's anonymous digital payment with unauditable issued amount, that unncessarily exposes all users to fraudulent overissuing ) is not sufficient by itself for a widely acceptable payment system. In the beginning, our approach was same as Daniel A. Nagy's proposal (we independently came to the same conclusion). Later (but still before finding his paper) we made an improvement in the design, namely using digital signature instead of hash for the challange. This way if the Title Server is accused of hijacking some tokens (transferring to different recipient than that designated by the previous holder presenting the secret), the Title Server can prove that it acted fairly.

Any community can issue currency and make it convertible.

The technical challange is to make sure that no person can abuse the system and join several communities and max his credit limit in all of them. Some credit network systems like Ripple cannot limit the total credit of someone (only the credit on their direct links). People want a negative-balance limit for every member they (potentially) finance (eg. members of their LETS community).

Title Server provides technology for communities to issue tokens in a publicly auditable way, with this in mind. The same technology can also be used to issue tokens to monetize existing assets or near-future production or services (for which the final trading value will be determined by the market).

To solve the negative-balance limit , persons who want to be able to go negative, must register at notaries personally to prove their identities ("on the internet noone knows that you are a dog").

After that they can use their authenticated keys to part in communities. Only their issued token is limited. They can trade, give real values and receive and hold tokens pseudononymously (not identifiable to their personal identities). In other words

• only real human persons can go negative balance, and to a limited extent (no artificial entities, like companies, banks, governments, or non-human creatures - like cats - can go negative)
  • this prevents fraudulent parties to abuse the system and get values from the communities
• anyone or anything can go positive (no need to register personally to create identity and positive balance). They can handle the acquired tokens on their own (by using computers, possibly not internet-connected ones) if they like, or they can trust some service (either only for storage without knowing what is stored, or as authorized for signature)
  • noone is prevented from giving values to others

Title Server - DOWNLOAD sourcecode for a prototype commandline implementation in C (compiles under Linux or Windows)

• download the latest from http://www.ideje.hu/cc/ and unzip
  • alternatively the old (original) windowsonly version from  Title Server Demo , for this you need to LOG in (username=pub, pw=beer) and
• read the documents (rtf or txt version)
• run the example shell (or bat) script

Title Server DEVELOPMENT - OBSOLETE, because epointsystem issuer implements same functionality (+more), far ahead in development, and it just works.

• See TitleServerDocumentation (English) for more operation and software implementation details (how it works, and use cases)
• storage must improve
  • either by using the operating system and a directory structure to store branches of a balanced tree (or hash)
  • or using flat area (such as a partition, an SDcard or a huge datafile)
  • sqlite library?
    • it seems to me that it is suitable and convenient for our purpose
    • SQLite implements btree which we would implement anyways
    • it looks like a waste of time to not to use it, especially in the design stage, where the nature of queries might still change slightly

Please contribute your ideas, suggestions, code changes here !

• change %llu to %lld  in  fprintf(f,"NaVlld\n",ns_lrs,(*t).lrs); to display LockRefStart=-1  instead of LockRefStart=18446744073709551615
• binary storage inside hash (automatic hashbucket allocation, I assume growing around +8..32 MByte at a time is acceptable - wether it's stored in filesystem files or raw data on SDcard)

Canonical format

• The first "raw" version of the demo code chocked on linux when input had \r\n line-endings. We need some canonical format, that is insensitive  to whitespaces (including trailing  whitespace at the very end). Whitespace between key=value pairs can be any linending. It must be easily portable between  linux/windows/mac  in binary form, or with  copypaste, or text email.
  • If we allow "space" or "tab" between keys, than we cannot allow (or need to escape) these characters inside the values. Which does not seem necessary at the moment, but will likely be needed later. If we insist that key=value pairs are separated by some linending (that includes \n) that should be safe.
• insensitive to order of keys. It can be done by "sort by key". This is not essential.
  • actually, it would be nice to detect chopped input (lost beginning or end). Some trailing and leading text would be needed, like gnupg. The version number/data can go into the leading part. FYI gnupg writes this:

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

owGb......uyz...RBQA=

...
=KShD

Title Server implementation suggestions - English

Title Server technika description external link, OLD, abandoned (they cut write-access)

• We do NOT need denominations like 1,2,4,8,...256,512..... Handling the change would be unnecessarily complex. We can simply use a series of tokens, eg. with a 64 bit serialnumber identifier. To optimize storage and transaction decriptor size (network bandwidth), a series (range) of tokens like serialnumber=45..73 can be handled together. Such a range can be split at will. That means each token can have it's own property, but in practice they are handled with their neighbors most of the time. There are also cases for merging (when neighbor ranges are transferred to the same owner - often back to the issuer - the higher sequencenumber can be applied to both and ranges merged), so the number of data to store does not grow unreasonably
• for a live secure server (behind a communication webserver) it could be run inside grub bootloader  grub, GRUB wiki, grub netboot
  • the communication webserver cannot sign transactions, so data and entitle-ment is safe even if that gets cracked (cracking the communication server is equivalent of injecting noise or cutting communication to the line to the title-server

Title Server implementation suggestions - Hungarian (OLD notes)

• Title Server technikai részletek
  • nem kellenek cimletek. Egyszeruen számtartományokra vonatkozóan lehet tranzakciókat végezni. Tranzakciónként legfeljebb egy tartomány megbontása lehet szükséges. Amikor szomszédos tartományok egy tulajdonoshoz kerülnek, azokat egy tranzakcióban használva (átutalva ugyanannak) a Title Server összevonja azokat. A nagyobbik szekvenciaszám +1 lesz érvényes. Leggyakrabban akkor fordul elõ, amikor "redemption" történik, a kibocsátóhoz visszakerül. Egyfajta garbage collection történik, ami a "végtelenségig" szabdalódást megakadályozza (persze 1 tokennél jobban úgysem lehet osztani).

RipplePay - a community developing society-created (non-fraudulent) money