OpenCoin - open questions

What are the requirements for the "next" prototype?

There already is a proof-of-concept. The main purpose of the next prototype is to serve as a show case to demonstrate the feasibility of our technology.

• Available for Android and iPhone. If possible and Ubuntu, Windows and MacOS too.
  
• Easy to install
• Good user experience. That includes that some crypto operations (e.g. for token transfer) are reasonable fast. Though other operations (e.g. coin generation) could be ok to be slower, maybe in the background.
• There should be a reasonable chance that it is not programmed for the bin only, but that it could develop into a full, stable client, at least for some platforms.
  
• Protocol-level secure, in particular proper crypto libs with a good entropy source so that e.g. blinding factors cannot be guessed. But not necessarily secure against trojans or hard core side-channel attacks.
  
  

What development framework shall we use?

Given that we want a multi-platform client without really having developer resources, the most promising path is HTML5+JS+CSS. Possible frameworks and libraries:

• PhoneGap [1] (now called "Cordova") and its plugins [2]
  
• Stanford Javascript Crypto Library [3]
  

There are some hurdles, and we need to evaluate whether we can overcome them with the above stack:

• Security: Do we have access to cryptography-grade randomness? [4]
  
• Performance: are coin creation/blinding, unblinding, transfer, and redemption quick enough to not impact user experience negatively? We need to test.
  
• Storage: Do we have permanent, secure local storage for the wallet? "secure" = accessible only for the client, but not from a server and other local apps
  

How do we encode signed data structures?

OpenCoin makes heavy use of "signed data structures", usually dictionaries: coins, key certificates, CDDs etc. Unfortunately, abstract data structures cannot be signed, only specific serialisations of data structures.

There are two obvious solutions to this:

1. Have a non-ambiguous (bijective) serialisation, so the same dictionary results always in the same hash and signature. An example is BitTorrent's Bencode.
   Advantage: human readable
   Disadvantage: not that common as JSON
   
2. Once the data structure is serialised and signed, this particular serialisation becomes part of the data structure (just like the the signature) and cannot be altered any more. An example is JSON Simple Sign. This result in non-plain encoded tokens and messages.
   Advantage: unambiguous approach
   Disadvantage: not human readable
   
3. Define rules how to serialise JSON (easy to get it wrong and therefore quite ambitious) [7]. Such as 1) remove whitespaces, 2) bring all elements in lexicographic order 3)...
   Advantage: human readable
   Disadvantage: need to develop unambiguous rule set
   
4. Blow up the JSON Simple Sign blobs and embed the original JSON dictionary too. (not very elegant)
5. JSON-LD "The difference between regular JSON and JSON-LD is that the JSON-LD object above uniquely identifies itself on the Web and can be used, without introducing ambiguity, across every Web site, Web service and JSON-based database in operation today. The secret lies in the @context, which instructs Linked Data-aware processors on how to interpret the JSON object." JSON-LD contains a normalized form as well.
   

We are thinking of making the OC protocol encoding 'agnostic'. What i mean is that OC peers can choose from different encodings with pre-defined labels (e.g. "OC-BENCODE"), with one encoding (probably some JSON flavor) being mandatory to support. Pretty much like the cipher-suites.

Enabling Various Tarife Schemes

Ausserhalb der CDD, oder vielleicht als Verweis auf eine externe Datei behandeln. D.h. es gaebe ein Feld 'payment_options' was auf 'http://opencent.org/payment_options.json' verweisen wuerde, wobei die Datei vom Format 'http://opencoin.org/payment_definitions/v1' waere. Im wesentlichen scheint es aber so, dass ausschlieslich die Transaktion 'Muenztausch' zwingend im Wallet behandelt werden muss - der Rest kann evtl. eh auserhalb stattfinden

Change/Replacement of Crypto Algorithm

Einen Algorithmuswechsel wuerde man entweder durch eine neue CDD oder neue Attributszertifikate machen.

References and links

• [1] Apache Cordova (ex "Callback", ex "PhoneGap") 
• [2] Cordova plugins (still called "PhoneGap plugins")
• [3] Stanford Javascript Crypto Library
  

• [4] SJCL Random()

• http://crypto.stackexchange.com/