Prinzip
Bei einer Geldübergabe wechselt der Eigentümer
einer Münze. Bei Micropayments kommt nun erschwerend hinzu, daß die zu
zahlenden Geldmengen pro Transaktion extrem klein sind und der
Transfervorgang allein durch die notwendige Rechenzeit bei der
Münzüberprüfung - ganz zu schweigen von den
Kommunikationkosten beim Kontakt zum Logfile - mehr
kostet, als der zu transferierende Betrag.
Eine Möglichkeit das Problem zu lösen besteht darin, eine Münze in
Scheiben zu zerlegen, die leicht auf Konsistenz zu prüfen und billig zu
übertragen sind. Sind alle Scheiben übertragen, so ist der Empfänger im
Besitz der Münze und der Transfer vollständig.
Wird der Transfer vorzeitig abgebrochen, so ist sicherzustellen, daß die
Münze aus der Verfügungsgewalt des Zahlenden verschwunden ist, und der
Empfänger ein Anrecht auf den Teilbetrag nachweisen kann, auch, wenn dies
von einem zahlungsunwilligen Kunden verweigert wird. Es genügt, wenn der
Empfänger die in sich konsitenten Münzscheiben beim Schuldern der
Schuldverschreibung (oder beim Inkassodienst) geltend machen kann.
Realisierung
Eine gültige Münze wird mit dem Passwort zusammen gehashed (Anwendung
einer Einwegfunktion). Die Münze und der Hash werden zusammen wieder
gehashed, ... usw. bis die gewünschte Anzahl von Hashes vorliegen. Im Logfile trägt der aktuelle Eigentümer analog zur Geldübergabe die alte Münze, das alte Passwort, die
neue Münze, die Anzahl der Hashes und den letzten erzeugten Hashwert ein.
Damit ist die Münze als solche nicht mehr einzahlbar, sondern nur noch die
entsprechenden Hashes der einzelenen Scheiben.
Der zukünftige Empfänger der Micropayments erhält den die neue Münze und
den letzten Hashwert. Diese prüft er und lehnt sie möglicherweise ohne
Angabe von Gründen ab, wenn sie ihm nicht zusagt. Nimmt er an, so kann der
Zahlungsverkehr beginnen. Zu diesem Zeitpunkt hat er noch keine Möglichkeit,
den Zahlungsverkehr zu seinen Gunsten zu beweisen.
Mit dem Erhalt der ersten Scheibe (dem vorletzten Hash), prüft er diesen,
indem er die erhaltene Münze mit dem frisch erhaltenen Hash zusammen hashed
und den davor erhaltenen Hash herausbekommen muss. Stimmt dieser Test nicht,
so verweigert er die Leistung, da er eine ungültige Zahlung erhielt. Mit
Eingang der ersten Zahlung sicher er sich den Anspruch auf die Gesamtzahlung
durch einen Eintrag im Logfile, der aus der Münze,
dem vorletzten Hash und der Verschlüsselung dieses Eintrages besteht.
Derjenige, der das Passwort zu dieser Verschlüsselung kennt, hat Anspruch
auf die Gesamtzahlung.
Alle weiteren Zahlungen erfolgen durch Übertragen von weiteren Scheiben
(Hashwerten), die auf die gleiche Art geprüft, jedoch nicht im Logfile
eingetragen werden.
Wird die letzte Scheibe übertragen, so erfolgt eine Übertragung des
Passwortes der Münze selbst. Der Empfänger kann jetzt analog zu einer
gewöhnlichen Geldübergabe die Rechte an der Münze
erlangen. Dazu trägt er in das Logfile die Münze, deren Passwort, den
verschlüsselten Eintrag des vorletzten Hashes, das dazugehörige Passwort und
die neue Münze ein.
Endet die Zahlung bevor alle Streifen übertragen worden, so trägt der
Empfänger im Logfile das Ende des Mircopayments ein.
Er überträgt dazu einen Eintrag bestehend aus der Münze, dem verschlüsselten
Eintrag des vorletzten Hashes, dem dazugehörigen Passwort, dem letzten
übertragenen Hashwert und der Verschlüsselung der Münze und des letzten
Hashwertes. Sollte die Übertragung von Scheiben fortgesetzt werden, so kann
er in gleicher Weise einen neuen Zwischenstand dokumentieren.
Liegt ein dokumentierter Zwischenstand vor, so kann der Münzbesitzer sein
Münze in genau diesen Zwischenstand und den Restbetrag spalten. Mit dieser gespaltenen Münze kann er den
Empfänger bezahlen.
Lehnt ein Münzbesitzer die Zahlung ab, so kann er den betreffenden Betrag
der Münze selbst nie wieder ausgeben, da ihm dazu das Passwort für die
Verschlüsselung des Zwischenstandes fehlt.
|
zurück