Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Workspace / Priorities [German]

Priorities [German]

Prio 1: Basisleistungen

  • synchrones Interface zw. Peers bzw. zw. Peer und Issuer, z.B. REST
  • Clientperformance in JavaScript testen/evaluieren/abschaetzen
  • OpenGL Nutzung im Client insb. Javascript
  • Datencontainer Encoding (z.B. XML, JSon, Bencode)
  • Protokoll inkl. Versionsangabe um Zukunftsfaehig zu sein
  • Schluesselwechsel ermoeglichen
  • Algorithmenwechsel ermoeglichen
  • Ist Mechanismus zum Schluesselrueckruf noetig?
  • asynchrone Transaktionen (zwischen Peers) im eigentlichen OC Protokoll ermoeglichen (nicht der eigentliche Transportmechanismus)
  • Angriffsszenarien auflisten

 

Prio unklar

  • Walletverschluesselung (mit Passwort). Kein Protokollbestandteil jedoch vielleicht trotzdem diskutierenswert.
  • Gebuehren bei Muenzwechsel, Transaktionen etc.
  • vorgesehene Erweiterbarkeit des Protokolls
  • Out-of-protocol Transaktionen: (die folgenden Themen haengen alle irgendwie zusammen:
    • ECC
    • Kurzformat der Muenzen
    • Zusatzfall: Geld bei Peer "abholen" (Das hatte Joerg als "Internet ATM" bezeichnet)
    • Muenzverschluesselung mittels symmetrischem Passwort oder public Key zur out-of-protocol Uebertragung. Oder auch fuer in-protocol Uebertragung anstelle oder zusaetzlich zu SSL?!
  • Lucre's paper describes several ways how to guarantee that the issuer
  • does not embed any traceable information in the coin. Do we want to integrate any of those features? See:
  • http://anoncvs.aldigital.co.uk/lucre/theory2.pdf
  • Blind Coins Ansatz mit dem Link auf JavaScript client Anwendungen (siehe Joergs Email) aufgreifen?
  • URL des Mint in CDD aufnehmen?
  • Da Blanks durch den Client generiert und deren Inhalt vom Issuer/Mint nicht verifiziert werden kann ist es moeglich dass ein boeswilliger Client eine falsche Denomination in die Muenze schreibt. Eine Verifikation beim empfangenen Client muss dies beruecksichtigen und darf diesem Wert nicht vertrauen sondern muss stattdessen den Muenzwert ueber den Mintkey ermitteln. Birgt dies unintuitive Verifikation ein Risiko und sollte als Konsequenz der Wert einer Muenze nicht in der Muenze selber gespeichert werden?

 

Prio 2

  • QR Code
  • Transaktionsmechanismus fuer asynchrone P2P Transaktionen (z.B. Jabber)
  • Fair Exchange
Add comment

You can add a comment by filling out the form below. Plain text formatting. Comments are moderated.

Question: What is 10 + 4 ?
Your answer: