2010-02-xx Fefe implemented a working market in JAVA. Original specs:
https://www.epointsystem.org/trac/epoint_issuer/wiki/StockExchange - but some extensions, like the Quick (anonym) Offer exist in the sourcecode
- sourcecode is in https://www.epointsystem.org/svn/epoint_issuer/digitalMarket/branches/transcent/src/
- example shell-scripts https://www.epointsystem.org/svn/epoint_issuer/digitalMarket/branches/transcent/scripts
- quick-and-dirty "reference implementation" (also useful for testing !) using gpg, url-encode, wget, and base64 -d | sha1sum | awk '{print toupper($1)}'
- you'll need something like apt-get install tofrodos for unix2dos and gcc -Wall -o /bin/url-encode /svn/epoint_issuer/issuer/trunk/scripts/url-codecs/url-encode.c
- not yet reimplemented as a C library, but after it works in shell, it should be trivial. C-library will be necessary at some point. ( Anyone ?)
- related files and updated reference of market commands: www.ideje.hu/download/epointsystem/DigitalMarket/
- TODO: there should be a non-dated file in svn. Review it for completeness and correctness: https://www.epointsystem.org/svn/epoint_issuer/digitalMarket/market_commands_2010-03-21.txt
See DigitalMarketTests
2010-03-21 updates:
- http://epoint.vems.hu:8180/market/ (not localhost. web.xml update)
- TODO: not CET !!! use UTC in ALL transactions. (mark done when it passed tests !)
- TODO: if /market/account?U=<nonexistant user> return 404 error, not 500 (mark done when it passed tests !)
- TODO: real WAL (write-ahead-log) even in shell-scripts
- cat market/EC964C1A7E1681D70577770DF3666E9DBF97A9C4/url
- epoint.vems.hu:8180/market seems bad. Should contain FULL URL, including https or http
Most are done, but Fefe, check that the specs are uptodate, examples exist in docs. Mark done when they passed the tests !
Quick, anonym transaction was implemented also. see scripts/MarketQuickOffer.sh
(will not persist, if not immediately executed). We have N ept RAND at issuerA, need min M ept (of course as much as possible) to an issuerB ID. Reject case draft goes to IssuerA rejectID (different ID). Typically merchant requires M ept at issuerB to given ID.
- OLD: Cell's proposal for a more advanced functionality: min M, max M2 amount of issuerB epoints. (0,inf possible). If less than M possible, than reject. If more than M2 possible, than excess amount could go to the alternative "reject" ID at issuerA. If one wants to wave any excess sum, just use M2=inf (or a very large number)
Was implemented. TODO: review if market_commands.txt specs is complete, correct and matches the implementation !
- TODO: ask a lawyer: for legally correct market template for offer, and other...
Of course.
- TODO: if account partially depleted because of offer1, other offer2...offerN might need to be deleted or lowered (if no sufficient funds now).
It already works this way, offer limits are temporarily lowered in this case.
- Report currency amount for each issuer (cheaper than requesting each issuers individually)
- The account info command /market/account?U=<account key fpr> already does this.
Example:
Alice from LETS-A transfers to Bob from LETS-B, so Bob finally receives VALUE-B.
Detailed market_commands.txt and market_backup.zip halfway sourcecode snapshot under Files / Penz (register + log in).
- Bob MAY specify an MD-B destination in his signed invoice (which refers to LETS-B currency)
LETS-A and LETS-B have convertibilty contract with DigitalMarket
- LETS-A and LETS-B specify actual exchange-rates.
- LETS-A and LETS-B deposit a certain amount of connectivity-currency, and own LETS currency so DigitalMarket can maintain prompt-transfers according to rules
Between LETS systems they use Issuer-C connectivity currency.
- Alice makes a LETS-A currency payment to DigitalMarket, specifying VALUE-B, MD-B, as a target.
- DigitalMarket verifies
- validity,
- value, if it conforms to VALUE-B target.
- if LETS-A has "connectivity liquidity" to fulfil transfer. If contract allows, and specifies technical interface, than DigitalMarket can request connectivity currency from LETS-A on the fly. (to be developed later. Will be important when multiple DIgitalMarkets come to existance).
- (if all OK), DigitalMarket transfers VALUE-C connectivity-currency from LETS-A to LETS-B,
- and VALUE-B amount of LETS-B currency to MD-B destination
- preferrably in atomic transaction
- Bob verifies in his EpointSystemWebBalance that MD-B is received. He can transfer it to other destination if he likes.
See also:
CA->CB váltás (tranzakció példa két market együttműködésével, egyelőre magyarul, majd lefordítom, csak így könnyebb volt közben átgondolni):
CA, CB: LETS-devizák,
HA, HB: hashes for epoint_issuer A and B ("accounts")
CC: összekötő
LMA, LMB: LETS manager/market szerverek, szabványos market-felületet is biztosítanak, de CC-t csak másik LM-nek adnak.
Negotiations / preparations
- user küld egy offer requestet LMA-nak, hogy XA mennyiségű CA-ért mennyi CB-t tud adni, esetleg mennyi CA-ért tud XB mennyiségű CB-t adni. A request a következőket tartalmazza:
- CA, CB, ill. XA és/vagy XB (ha XA és XB is meg van adva, akkor fix arányt kér a user, nem a market ad legjobb ajánlatot, persze nyilván a nem azonnal végrehajtható tranzakciók esetén érdemes ilyet megadni)
- egyéb paraméterek (pl. részlegesen is végrehajtható-e).
- egy pubkey (lehet a user hétköznapi kulcsa is, vagy anonimitás igénye esetén egy tetszőleges kulcs)
- ha LMA-nak van elég CC-je, megkérdezi LMB-t (szintén offer request), hogy tud-e adni megfelelő mennyiségű CB-t (nem biztos, hogy LMB akar több CC-t venni, ill. lehet, hogy már csak a szabott árfolyamnál rosszabb arányban akar).
- visszaküld egy aláírt üzenetet (offer), ami a következőket tartalmazza:
- tranzakció sorozatszáma
- a tranzakció megvalósítható-e pillanatnyilag
- maga az ajánlat: (lehet garantálni az érvényességét egy-két másodperc erejéig, egyelőre nem lényeges kérdés)
- mennyi CA-ért mennyi CB-t tud adni (ha a request fix arányt tartalmazott, akkor az ajánlat is ezt tartalmazza)
- esetleges egyéb, a user által a requestben megadott paraméterek
- LMA által generált rand hash-e, amire a beváltandó összeget a user befizetheti, ha szeretné az adott feltételekket végrehajtani a tranzakciót
Start the market transaction
- user a kapott hash-re utalja a beváltandó CA-t, ezzel elfogadja a feltételeket (mindkét félnek van bizonyítéka)
- user üzenetet küld LMA-nak a befizetésről (amely tartalmazza a kibocsátószervertől kapott certificate-et)
- LMA megfelelő mennyiségű CC összekötőt hasonló módon elküld beváltásra LMB-nek
- user aláírt üzenettel:
- megad egy HB hash-t, ahova a beváltott CB-t kéri
- opcionálisan megad egy HA-t is, ha így tesz, azzal visszakéri az esetlegesen még beváltatlan CA-t is. Is this really needed ?
- LMA (ha még nem bonyolította le LMB-vel a CC->CB tranzakciót) küld egy hasonló üzenetet LMB-nek
- HB-nek azt adja meg, amit a usertől kapott
- ha a user megadott HA-t, akkor ő is megad, de ebből egy másikat, mert ide ő CC-t kap vissza, aminek arányában CA-t ad vissza a usernek
- a megfelelő mennyiségű CA-t természetesen zárolva tartja, amíg a CC->CB konverzió nem sikerül, persze a CB-t azelőtt is elkérheti LMB-től, mielőtt a user kérné tőle
- mivel ilyenkor CA és CC is áll, hosszabb várakozás esetén visszakérheti a CC-t LMB-től, majd szükség esetén újra megpróbálhatja beváltani
- a válaszüzenet:
- volt-e még beváltatlan CA
- ha volt és a user megadott HA-t, a kifizetés certificate-je (ha nem adott meg, akkor csak tájékoztató infó, hogy mennyi maradt, ez jelzi, hogy a tranzakciónak még nincs vége)
- CB kifizetés certificate-je (vagy jelzés, hogy nem volt még/már kifizetetlen CB)
A market az aláírt üzenetek fogadásához a kibocsátóból átemelt /secureMessage formátumot használja, a saját üzeneteit is hasonló, olvasható és géppel is feldolgozható, aláírt formában küldi.
A sorozatszám alapján a tranzakciókhoz tartozó tanúsítványokat megjeleníti, lezárt tranzakció esetén a visszautalás certificate-jei igazolják, hogy nem tartozik már semmivel.
Does it make sense to make a simplified CC-related internal transaction (to get something working fast) ? This would happen WITHOUT ANY HANDSHAKE, inside the same market, handling some deposits of all 3 currencies => No commuication between server. Possibly:
- CC from A to B (LETS-A's CC deposit--, LETS-B's CC deposit++ )
- CA to LETS-A (not LMA as this would happen inside the same market),
- CB to user
All this according to simple rules, limits and user request.
While there is only one market, this could work well. It's no big deal for LETS-A to provide some CA to the market (the max amount it is willing to sell), besides some CC.
When we can implement the communicated servers, and deploy several instances, we can encourage that method whenever appropriate.
OLD: Digital Market Meeting notes - extract (it was implemented and deployed since than; But code cleanup and more testing never hurts)
- The point is that different ePoint-compatible issues can be traded in an efficient exchange.
- They want to use it as a connecting vehicle between different LETS issuers but also for other purposes like trading commodities,
where the issues are warehouse receipts.
- It would be fun to revive ePint (a currency fully backed by beer, whereby the unit is a British Imperial Pint). It can also be used for trading money.
-
- The implementation is rather ugly at the moment, based on redcent code. Fefe promised to refactor the source in such a way that Janis' stuff, where used
without modifications, is referenced and his stuff is placed under a different namespace (something like hu.vems.epoint...). THEN it will be uploaded to our
SVN repository. If you want to take a look at the source as it is right now (or at any moment before the publication), he would be quite happy to send you a
tarball.
The specification of the protocol shall be uploaded to the wiki soon. It is very similar to the ePoint issuer protocol, actually. Fefe has shown it to us.
In order to make issuing various financial instruments easy, two little extensions to redcent have been proposed, and Cell offered €1000 EUR to Janis
for the implementation.
1. Redcent should be able to run an arbitrary number of issuers with different keys and base URLs.
2. There should be a web-based user interface for creating an issuer by uploading the private key, the service contract and the templates. In exchange
for ePoints, of course.
These should be implemented in an entirely separate fashion. We have agreed that the second thing is best NOT open-sourced at the beginning, just offered as a service. If Janis accepts Cell's offer of Euros, he will need to share the source with Cell, of course. Janis may, of course, decide to do and operate it
for profit by himself.
We have also had a very interesting discussion about the future of corporations in the brave new world of ePoints. Cell proposed to do share issues in
joint-stock corporations using our technology. I have respectfully disagreed, and given a brief intro (without going into details and without showing the
property registry) into the principles behind our little conspiracy (exclusive rights of control, nobody worse off by being a member, etc.). I think, I
succeeded in persuading the participants that it is a Pareto-improvement over traditional joint-stock corporations. But it is not clear how to trade
participation in public and how to attract (big crowds of) small investors to our structure (there is no obvious equivalent of a public offering except for
people buying up our ePoints as investment vehicles).
Fefe made an interesting proposal that I find very sensible: instead of offering shares in future revenues, corporations should offer future products to the
public. While almost identical, there are very substantial differences between the two and I think it requires some thinking. It echoes our ideas with Agnes
about digital purchase certificates of economic actors being the vehicle of collecting small investment. What Fefe adds to this is the ability of the
company to let the investors choose between specific and general economic activities to invest to (it can offer both general purchase certificates but
also certificates for particular goods, thus gaining valuable estimates of future demand -- a great idea!). I like this idea very much!
Cell gave us an informal presentation about the other projects he is working on in the area of autonomous energy production. The kind of stuff he might want to
collect investment for.
As action points, we agreed about
- - Fefe cleaning up the code in two week's time
- - Cell and Fefe deploying the market at one of their servers. Had done the same night.
