Development ideas for EpointSystem
See also: TokyoIssuer and MultiIssuerArchitecture and OpenCDK (PGP-library implementation built in libgcrypt and zlib)
- The very old C (epointsystem) issuer is at: http://epoint.cvs.sourceforge.net/viewvc/epoint/epoint/redcent
- https://www.epointsystem.org/trac/vending_machine/browser/hotspot/trunk/epoint/luasrc/epoint/protocol.lua
- It depends on lpeg (lua parsing expression grammar).
- These 194 lines (incl. comments and blanks) are a fairly complete client-side implementation of ePoint protocol
Epoint issuer transaction fee
- requires advertisement of transaction fee: max N epoints taken by the issuer +p ppm (proportional fee). Can be 0 of course.
- with 0 fee, trust in the service can be expected to be low, suspicion will grow. A fair fee (for this sensitive data and transaction type) is better than totally free. Also DOS attack becomes more likely. Even without DOS, the innocent will pay the actions of bastards, not good.
- without this in the specs, widespread use of the protocol will suffer. Some other (likely worse) protocol will spread
- auditing transactions must consider this fee (of course)
Epoint_Issuer functionality proposal - postponed because issuer obligation is an existing substitute for this:
MD, with restricted destination. The given MD can only be transferred (exchange, merge or split requests) to within a given set of destinations.
- customer Cecil deposits (N units, CUR currency) to an MD.
- According to contract between Cecil and Service provider "Serv", Serv is allowed to "withdraw" M units every month, by transferring to an account of its own.
- Cecil is also allowed to withdraw any remaining currency.
- If they can transfer to any destination, there can happen a dispute where 3d party cannot decide who stole the money. If the server only allows withdrawing to certain, predefined destinations, it is always clear (the Cecil-Serv contract can detail who is who) where the money went.
Similar functionality can be implemented by an external agent, with more complex, more trusted parties needed.
The best semantics to implement it is constraints in the RAND. RAND can already have constraint, like
- "transfer must be signed with secret key matching ... pubkey",
- actually, epoints can NOT have this constraint currently. Obligations are used for this.
- "transfer destination can be ... or ... or ..." could be another constraint
- there could be a generic constraint-evaluator on ANY field.
Issuer service protection against DOS / transaction Flooding
- epoint birth(time): when certificate was signed
- maturity: as in the certificate
- value: as in the certificate
- delay: defined as (maturiry - birth) unless there is an explicite field in the certificate. Measured in seconds.
- maxdelay: maximum delay is function of value (length in bits). Eg. maxdelay= 65536 / (1+log2(value)) suggested. For value==1 that is maxdelay=65536 (18 hours), for value=1mill epoints (~1000 EUR) that is 0.75 hours.
- for every transaction where now - birth >= maxdelay we reset delay to 1 second.
- otherwise increase actual delay by a multiplication factor (this results in an exponentially growing service time for attacking clients). Multiplication factor can be between *1.1 ... *2 (possibly higher for lower value). But no higher than maxdelay.
- in case of a split or merge, either the original or the resulting value can be used (we'll fix this during implementation)
- clients that request exchange before the maturity time, or otherwise bad requests can (and in case of a high load SHOULD) be penalized by slower service, or in extreme case firewall rule.
The growing delay does provide some protection against some DOS attacks. However, an issuer transaction fee (defined per issuer, defaulting to 1 epoint - could be configured and advertised 0 of course, which also maintains compatibility with old vending machines) would be much more motivation for high-grade issuer services (and competition). This simple allowance of advertised transaction fee would be very easy to follow (during transactions and audit).
Auditing transaction log change
The actual set of valid epoint RANDS (with some filter criteria according to value, MD, etc...) should be separated from retired (redeemed) RANDS. Having this type of "everything is out in the wild" is not an advantage, but a clear disadvantage.
However, any party must be able to verify his own transactions (he gets receipts, which she will save in her vault).
Consider
- having a salt for each SRL nr
- putting hash(SRL nr, salt) in the signed document
- sending the salt to client outside the signed document (attached to after signo)
This way anyone could retreive old transaction log entries by (SRL nr, salt), but not just by the obvious SRL nr. Rethink if this is really useful or not (if there is a simpler method). Perhaps just hiding the SRL log and making an "actual snapshot of valid RANDs" is easier (no protocol change, clients not effected)
Sticking cheat proof on keyserver is a good method in any case.
Small https CGI for RAND => MD conversion (note: the other dir should not be practical ;-)
Useful for developers during verification / debugging. Should not be necessary for ordinary users.
- RAND=hT4dDqukjYfb ; echo $RAND | base64 -d | sha1sum
- as a result you get the MD of the epoint: dfef898e04ffea9009a55b441ce07718f8893200
This actual EPT was value 4, see the birth at https://www.epointsystem.org/issuer/CERT21983.asc
Value: 4 EPT
ID: DFEF 898E 04FF EA90 09A5 5B44 1CE0 7718 F889 3200
Note that the issuer uses capital case for the hex letters A-F (as in the specification).
How to avoid "traditional" RANDs altogether?
Any accusation about a RAND transaction is unauditable/undefeatable. A third party can in no way tell if B.Gates, the master of desktop spyware stole the RAND, or the issuer. Of course the media will accuse the issuer, and the desktop user will also tend to think the problem is on the other end.
- If one really needs to pass value with short codes, he can make a keypair from the short code.
- Yes, we do have that technology (called multi-use rands) and we actually use it at Libri. It does still not protect against Bill Gates, though.
- There is no bullet-proof way to protect the user from Bill Gates (without a display-capable added HW like a cellphone), but it protects the issuer service from false accusations
- The other problem with it is that the accepting machine needs to be quite powerful to do public key crypto. With simple rands, it only needs to calculate a hash function, which is much faster. Of course, it is less and less of a problem as time goes by.
- "accepting machine needs to be do public key crypto" .... is there any "accepting machine" (in use or planned) that does not do PKI already ?
- old cellphones are having problems with PK crypto. A payment transaction would take a minute with those (e.g. Nokia 3410)
- But anyway, this development is definitely on our roadmap.
- And most of it is already implemented. An additional benefit with such key-seeding rands is that you can actually charge back value.
- Here's the relevant source: https://www.epointsystem.org/trac/vending_machine/browser/pubterm/trunk/epoint-dsatool
- It's a self-contained command-line utility written in C.
- dsatool is nice! One minor thing: when compiled with paranoid option, maybe we could mlock() after checking if it is possible
BRAINSTORMING on Distributed administration of transactions
One problem of current ePoint implementation is that it puts the burden of publishing the debt on the issuer. This might be possible to improve on.
Note: we agreed that "It's good to keep thinking on this, but I really think an obligation based issuer is the best way to use the wallets and market with - initially". So consider this as 3d generation issuer concept.
- latest concept was to update keyserver pubkey on updateAI (not at each emit "issuing")
- maybe it can be loosened to update key on each emit. That means everyone publishes the amount of emitted currency (debt) on her pubkey on keyservers. (this changes on each emit)
- during normal spending (currency transfer), some authorative administration point is updated (the balance, the serialnr, and some state-hash). naturally, the receiving party always verifies that
- the source account is registered for that currency
- the published state-hash matches the presented detailed transaction list for that account
- the given transfer is listed in the detailed transaction list
- unfortunately, without the issuer's signature, it can be extremely costly to tell a fake anon account (where funds originated fraudulently) from an honest anon account
- if, instead of 1 currency, a basket of member-currencies is traded each time (possibly including some currency of all authorized emitting members), that might make traceback easier, but the cost of normal transactions go up considerably. Even worse, instead of 1 issuer, it might end up having m issuers (not a big 'gain').
epointsystem's note: The basic idea is that for any debt of A to B and B to C, C should have the right (but not the obligation!) to exchange a C to A endorsement to a newly issued A to C debt. (???)
- Is this now very close to the ripplepay.com concept ? Does it not bare the same fundamental flaw that the risks (of someone overspending) grows if someone has many connections (the risk should not grow or decrease instead).
Maybe some way of limiting could make this work. Eg. they try to get an issuer's signature within N trans (otherwise the recipient is less and less likely to accept) (epointsystem: Of course!)
Suska is implemented this way (in paper notebooks):
- Every emit account is a notebook.
- every transaction is booked in both party's notebook (with + and - sign)
- Each notebook has lines (entries). The sum of + and - transactions in the system (in all notebooks) is 0.
- The sum of each notebook > -limit
Extras could be introduced in the electronic version:
- non-emit notebooks could be introduced (where sum>=0).
- I find it likely that in the electronic system each "notebook" needs to store the sequence of state (a hash of it) in an authoritive place.
- if not keyserver network, than eg. Twitter is certainly capable of handling all transactions.
- that way it cannot present stateA and stateA' (with different spent items) to different parties
Note that when receiving currency transfer from a non-emit account, one has to do an extreme amount of lookups to get certain that all the funding was originally born on real emit account (eg. it can be traced back to emit account , or some other way).
If the issuer (or any authoritive way of publishing) publishes (signed) latest (balance, state-hash) values for each (currency,pubkey) key, than it all becomes easy to maintain auditability and see that a certain spending is authorized. Note that most pubkeys are anonymous (like a CH bank account), while emit pubkeys are not anonymous, of course.
Distributed (cloud) administration of issued currencies
What will a wallet verify exactly when recieving a payment ?
- Eg, wallet creates a "take" transaction referring to the (hash of) "give" transaction.
- If the wallet can get one of the "trusted" administration servers sign the "take", than it can consider "paid" ?
- Of course, to catch bogus administration servers, it can randomly (and to add a reference which is part of the time-stamping protocol) lookup past transaction when it has available network capacity, or via agents.
But how / when to add a trusted administration server to the cloud ? (trackerless torrent DHT ?)
Removing the trust from a node is easy decision: when it fails to service a hash-lookup or when it is catched to sign bogus transactions (double-spending, no sufficient funds, take without relevant give, or disobeying issueing self-constraints).
IssuerInsideTheMarket
Most of the transactions involve digitalmarket. There seems to be little point at all to withdraw tokens from ALL markets (but it makes sense to move between markets). In a possible implementation, every member would issue with her pubkey (via keyserver) dedicated to the market it goes to. A transaction within a market would not result in pubkey update. Moving token from market M1 to market M2:
- getting cert from market M1 that issued tokens there < L1.
- Than sticking that cert to pubkey, declaring and signing L2 for M2, than presenting that to M2.
- from than on, upto L2 amount can be traded on M2 (but only L2 on M1)
Essentially:
- currency: a set of pubkeys and emit limits (authorized issuing keys, currency "members")
- also some legal contract, keysigning certs, hash of scanned IDs, whatever......
- emitting pubkey: via the keyserver it publishes the intended total issued amount, and the actual limit for each (currency, market fpr) tuple. When the limit goes down for a certain market, the certificate signed by the market must be present also.
- actually, for each currency, technically 2 currencies are issued:
- the "local currency" accepted by members only (this would likely stick to a certain "home" market, not moved to other markets),
- and the "connectivity currency" that is used in market offers to exchanges to other currencies. The latter would sometimes migrate between markets.
- after each member issues some connectivity currency to a market, on the market it becomes and indistinguishable amount (not titled with the issuing member's key). The market must be auditable: to see that the amount in circulation matches the amount issued there.
Issuer++ 2010-10-31 meeting
- obligation => obligation transfer required (in the JAVA issuer too)
- market draft must be made to match
- in the future, we want a small-footprint obligation based issuer.
- possibly in Lua (+C of course): Anytime you bootup a Tokyo Tyrant server you can tell it to load arbitrary Lua code alongside which will then be evaluated at runtime if the client requests it. From there, the developer of the extension has full access to the incoming request and the underlying Tokyo Cabinet database, allowing us to inject arbitrary functionality. See TokyoTyrant
- Tokyo Tyrant + Lua ACID properties: atomic operation by read/write locking by record (in Lua or memory hash). Write-ahead-log and shadow paging.
