Micropayments

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 ckzurück © 1996-2019 Lutz Donnerhacke @ IKS GmbH Jena Saturday | 24.Aug.2019