Ein kryptographischer Angriff auf Zerocoin (und zwei kritische Implementierungsfehler)

In diesem Eintrag stellen wir einen kryptographischen Angriff auf Zerocoin vor (nicht zu verwechseln mit Zerocash!), welcher es dem Angreifer ermöglicht, Münzen ehrlicher Benutzer zu „verbrennen“, sie also unbrauchbar zu machen. Im Zuge dessen entdeckten wir ebenfalls zwei kritische Implementierungsfehler in der Bibliothek, welche Zerocoin implementiert. Diese Fehler ermöglichen zum einen die Erschaffung von Geld aus dem Nichts und zum anderen den Diebstahl von Münzen ehrlicher Benutzer. Diese Bibliothek wird von mehreren Kryptowährungen verwendet (Zcoin, PIVX, SmartCash, Zoin und Hexxcoin). Falls Sie eine dieser Währungen besitzen, finden Sie in unseren „FAQ für Benutzer“ weitere Informationen.In der breiten Öffentlichkeit wird oftmals angenommen, dass Kryptowährungen die gleichen Eigenschaften haben wie physische Währungen und insbesondere, dass Kryptowährungen wie z.B. Bitcoin anonym seien. In der Regel entspricht dies jedoch nicht den Tatsachen. Obwohl Benutzer in den meisten Fällen nicht gezwungen werden, ihre Identität preiszugeben, stehen alle Transaktionen öffentlich einsehbar in der Blockchain. Außerdem geben Benutzer zumindest einen Teil ihrer Identität gegenüber den Menschen preis, mit denen sie interagieren. Diese beiden Tatsachen berauben die meisten Kryptowährungen zumindest zum Teil ihrer Anonymität.Eine der Technologien zur Verbesserung der Anonymität ist das kryptographische Verfahren „Zerocoin“, welches in mehreren anonymen Währungen verwendet wird. In diesem Artikel werden mehrere Sicherheitsprobleme von Zerocoin und dessen Implementierung aufgezeigt. Diese Probleme führen zu Schwachstellen in Zcoin, PIVX, SmartCash, Hexxcoin und Zoin. Obwohl wir die Entwickler dieser Währungen vor einiger Zeit bereits informiert haben, haben nicht alle Entwickler die Sicherheitslücken geschlossen.

Zerocoin
Zerocoin wurde ursprünglich von den Kryptographen Ian Miers, Christina Garman, Matthew Green und Aviel D. Rubin in einer wissenschaftlichen Arbeit vorgeschlagen und verschiedene Entwickler haben diese Technologie in der Praxis gebracht. Ein weiteres Verfahren wurde von Jens Groth und Markulf Kohlweiss entwickelt, welches die gleiche Funktionalität liefert und vermutlich eine bessere Effizienz besitzt. Jedoch wird dieses Verfahren noch nicht in der Praxis eingesetzt.

Der Grundgedanke
Der Grundgedanke von Zerocoin ist Anonymität durch zwei Operationen „Mint“ und „Spend“ zu erreichen. Die Operation „Mint“ erzeugt dabei eine „zerocoin“ unter Verwendung einer „öffentlichen Münze“ und einem geheimen Schlüssel zu dieser Münze. In allen bisher erwähnten Währungen ist es möglich mit Hilfe von Mint eine reguläre Münze der Basiswährung (z.B. eine hexxcoin) „aufzugeben“ und eine neue zerocoin zu „schürfen“. Mint ermöglicht damit den Austausch zwischen einer Münze der Basiswährung und einer zerocoin.

Die zweite Operation „Spend“ ist zum Ausgeben einer Münze gedacht. Möchte jemand seine zerocoin ausgeben, so muss dieser einen Beweis erbringen tatsächlich die Münze zu besitzen (formal gesehen den geheimen Schlüssel zu kennen) und die Ausgabe der Münze zu autorisieren. An dieser Stelle kommt die Anonymität ins Spiel: Der Beweis zum Besitz der Münze ist ein sogenannter zero-knowledge Beweis. Dabei handelt es sich um eine kryptographisch Technik, die versteckt, welche zerocoin aus der gesamten Blockchain ausgegeben wird. Der Beweis zeigt, anstatt zu veröffentlichen welche Münze genau ausgegeben wird, nur, dass eine Person berechtigt ist eine von sämtlichen geschürften zerocoins in der Blockchain auszugeben.

Mehrmalige Ausgabe (double-spending) verhindern
Die vorangegangene Erklärung erweckt den Eindruck, dass double-spending, also die mehrfache Ausgabe von einer Münze, sehr einfach möglich wäre. Wenn ein Verifizierer der Transaktion nicht weiß, welche zerocoin tatsächlich ausgegeben wurde, wie kann er überprüfen, dass die verwendete zerocoin nicht bereits verwendet wurde?

Dieses Problem wird gelöst, indem jede zerocoin eine Seriennummer zugeordnet wird, von der angenommen wird, dass sie einmalig ist. Diese Seriennummer muss nur veröffentlich werden, wenn eine Münze ausgegeben wird zusammen mit dem Beweis, dass die Seriennummer wirklich zur ausgegebenen Münze gehört. Dank dieses Mechanismus‘ können sich Verifizierer alle vorangegangenen Seriennummern merken und eine neue Transaktion damit abgleichen. Trat die Seriennummer einer Transaktion bereits früher auf handelt es sich um einen double-spend und ist folglich ungültig.

Ein denial-of-spending Angriff auf Zerocoin
Ein „denial-of-spending Angriff“ versucht ehrlicher Benutzer an der Ausgabe ihrer Münze zu hindern. In beiden vorgeschlagenen Zerocoin Schemata wird eine geschürfte Münze als öffentlicher Bitstring dargestellt, welcher selbst ein Commitment zur Seriennummer ist, aber diese Seriennummer zum Zeitpunkt des Schürfens versteckt. Um mit hoher Wahrscheinlichkeit die Einzigartigkeit der Seriennummer sicherzustellen, sollten Benutzer diese Seriennummer zufällig wählen. Nichtsdestotrotz kann ein Angreifer diese frei wählen, wenn er eine neue Münze schürft.

Dies führt zu folgendem Angriff: Eine ehrliche Person möchte eine Münze ausgeben und schickt zu diesem Zweck ihre Transaktion inklusive der Seriennummer an das Netzwerk. Ein Angreifer, von dem wir annehmen, dass er Kontrolle über das Netzwerk des Opfers besitzt, blockiert nun die Nachricht mit der Transaktion und sorgt so dafür, dass sie die Knoten im Netzwerk der Kryptowährung nicht erreicht. Danach schürft der Angreifer eine neue gefälschte zerocoin mit der Seriennummer, welche in der abgefangenen Transaktion veröffentlicht wurde. Der Angreifer kann nun diese Münze zusammen mit der Seriennummer ausgeben.

Sobald die Transaktion des Angreifers vom Netzwerk bestätigt wurde, speichern die Knoten die Seriennummer als verwendet. Damit kann die ehrliche Münze nicht mehr ausgegeben werden. Wenn ein ehrliche Benutzer diese Seriennummer an das Netzwerk verschickt, wird die Transaktion als double-spend abgewiesen, da die Seriennummer bereits vom Angreifer verwendet wurde. Durch diesen Angriff wird eine ehrliche Münze „verbrannt“, da sie auch in Zukunft nicht mehr ausgegeben werden kann.

Praktische Durchführung des Angriffs
Bei der tatsächlichen Durchführung treten verschiedene Probleme zu Tage:

• Ein Angreifer muss in der Lage sein den für eine Ausgabe der Münzen notwendigen Netzwerkverkehr seines Opfers zu blockieren bzw. zu unterbrechen. Häufig ist dafür eine privilegierte Stellung des Angreifers innerhalb des Netzwerks nötig. Vorstellbar wäre in etwa, dass es sich bei dem Angreifer um den Internet Service Provider (ISP) des Opfers oder um deren Tor exit node handelt, falls Tor verwendet wird. Ferner ist es dem Angreifer nützlich selbst ein Miner im Netzwerk zu sein.
• Sollte es einem Angreifer nicht möglich sein den Netzwerkverkehr seines Opfers zuverlässig zu blockieren so könnte es ihm passieren, dass die Transaktion des Opfers vor seiner eigenen von der Blockchain übernommen wird. Geschieht dies, so ist die Münze des Angreifers wertlos und der Angriff schlägt fehl.
• Die schnellere Übernahme der Transaktion des Angreifers in die Blockchain wird noch verkompliziert dadurch, dass eine geschürfte Münze je nach konkreter Implementierung des Consensus Protokolls frühestens einen Block später ausgegeben werden kann. Um dies zu verhindern kann es für einen Angreifer notwendig sein über einen längeren Zeitraum die Netzwerknachrichten zu blockieren. Auch wenn die Realisierung des Angriffs technisch nicht einfach ist, dürfen wir uns nicht darauf verlassen, dass niemand versucht den Angriff auszuführen.

Wirtschaftliches Interesse an der Durchführung des Angriffs
Der Angriff ermöglicht es, die Münzen einer ehrlichen Partei zu verbrennen. Der finanzielle Vorteil eines Angreifers könnte nun darin liegen, dass der Ruf der Währung durch die Veröffentlichung des durchgeführten Angriffs Schaden nimmt. Wettete ein Angreifer vorher auf das Fallen der Währung und veröffentlicht den Angriff, nachdem er einige Opfer fand, so führt diese Veröffentlichung zu einem Wertverlust und dank der Wette für ihn zu einem Gewinn.

Beweisbare Sicherheit
Beide Zerocoin Verfahren sind beweisbar sicher, d.h. für beide Schemata existieren korrekte mathematische Beweise für die Erfüllung verschiedener Sicherheitseigenschaften. Ebenso entspricht die verwendete Implementierung für Seriennummern genau dem Design. Warum haben wir für eine „beweisbar“ sichere Konstruktion einen Angriff gefunden? Das Problem liegt in der Definition der Sicherheitseigenschaften selbst bzw. genauer in der mathematischen Definition von dem, was „sicher“ bedeutet. Existiert etwa eine Definition die sicherstellt, dass eine zerocoin nicht gestohlen werden kann, so gibt es keine Definition die verlangt, dass eine zerocoin nicht verbrannt werden kann. Diese Definition wurde vergessen.

Problembehebung
Das Problem lässt sich beheben indem die Seriennummer nicht mehr ein zufällig gewählter Bitstring, sondern ein neuer zufälliger öffentlicher Schlüssel eines Signaturverfahrens ist. Zusätzlich zum bisherigen Beweis muss nun zum Ausgeben einer Münze die Transaktion auch noch unter diesem Schlüssel signiert werden. Damit kann ein Angreifer zwar weiterhin die Seriennummern sehen und auch Münzen mit dieser Seriennummer erzeugen, jedoch kann er die Transaktion mit der Seriennummer nicht signieren, da er den privaten Schlüssel nicht kennt.

Research paper
Den skizzierten Angriff haben wir ebenfalls in unserer Publikation beschrieben.

Weitere Probleme
Bei der Analyse des Programmcodes von libzerocoin wurden zwei weitere kritische Implementierungsfehler aufgedeckt. Diese betrafen nicht das Zerocoin Schema selbst, sondern Unzulänglichkeiten in der Implementierung der Bibliothek libzerocoin, welche in allen zuvor erwähnten Währungen als eigenständige Kopie verwendet wird.

An dieser Stelle muss gesagt werden, dass libzerocoin von den Autoren des Zerocoin papers selbst als erster Prototyp geschrieben wurde, welche mit mehr als deutlichen Warnungen die Sicherheit und Unfertigkeit für eine Verwendung in der Praxis (siehe https://github.com/Zerocoin/libzerocoin#warning) betreffend versehen ist. Wir sind der Meinung, dass es unverantwortlich ist eine solche Implementierung ohne ein ausführliches Code Audit zu verwenden.

Beide Unzulänglichkeiten wurden unabhängig von uns ebenfalls von den Entwicklern von PIVX entdeckt und gemeldet, welche libzerocoin einem ebensolchen Audit unterzogen und die Fehler behoben, bevor sie es in der Praxis verwendeten.

Inflation
Das erste dieser Implementierungsprobleme betraf die Handhabung von Seriennummern. Eine Seriennummer ist ein Element einer endlichen Gruppe, d.h. eine Zahl modulo einer größeren Zahl N. In der Implementierung wurde nicht überprüft, ob die Seriennummer die eindeutige „kleinste“ positive Darstellung einer solchen Zahl ist. (Zum Beispiel sind 3 und 13 zwei verschiedene Darstellung der gleichen Zahl modulo 10, wobei die Zahl 3 aber die eindeutige „kleinste“ positive Darstellung dieser Zahl modulo 10 ist.) Hier gilt es zu bedenken, dass die Seriennummer verwendet wird um eine mehrfache Ausgabe der gleichen zerocoin zu verhindern. Insbesondere funktioniert der der zero-knowledge Beweis des Besitzes unabhängig von der Darstellung der Seriennummer. Damit kann die gleiche zerocoin mehrfach mit verschiedenen Darstellungen der gleichen Seriennummer ausgegeben werden. Dies ermöglicht es einem Angreifer Geld aus dem Nichts zu kreieren und eine Inflation der Währung herbeizuführen. Das Problem kann behoben werden indem jegliche Transaktionen mit Seriennummern, welche nicht im Bereich [0;N-1] liegen, vom Netzwerk abgelehnt werden.

Ein sehr ähnliches Problem trat in der Vergangenheit bei Cryptowährungen auf, welche auf einem Protokoll namens CryptoNote basieren, z.B. Monero; der Unterschied im Problem lag nur in den verwendeten Gruppen: Im ursprünglichen Zerocoin Schema wird eine Restklassengruppe verwendet, in CryptoNote eine Gruppe einer elliptischen Kurve.

Ungenügend signierte Transaktionen
Das zweite Problem betrifft die Signierung einer Transaktion, die von Spend erzeugt wird. Im ursprünglichen Zerocoin Schema wird eine s.g. „Signature of Knowledge“, eine Spezialform eines zero-knowledge Beweises verwendet, welche zusätzlich zum Beweis auch als digitale Signatur fungiert. In libzerocoin hingegen erfasste diese Signatur nicht den Hash der Transaktion, die signiert wird. Dies ermöglicht es jedem außenstehenden Betrachter, welcher eine valide Transaktion an eine Adresse A abfängt, diese Transaktion in eine Transaktion umzuändern, die statt an A an eine andere Adresse B sendet. Damit kann ein Angreifer das Geld stehlen, indem er als B eine seiner eigenen Adressen verwendet.

FAQ für Benutzer

Welche Kryptowährungen sind betroffen?
Zcoin, PIVX, SmartCash, Zoin und Hexxcoin waren durch den denial-of-spending Angriff verwundebar. Zum jetzigen Zeitpunkt (12.04.18) sind Zcoin und Zoin noch immer verwundbar.

Zcoin, SmartCash, Zoin und Hexxcoin waren von den ungenügend signierten Transaktionen betroffen. Nach unserem besten Wissen wurde der Fehler in allen Währungen behoben.

Zcoin, SmartCash, Zoin und Hexxcoin waren von Inflation durch aus dem Nichts erzeugte Münzen betroffen. Nach unserem besten Wissen wurde der Fehler in allen Währungen behoben.

Wir weisen darauf hin, dass wir die Patches, die im Moment in Verwendung sind, nicht selbst überprüft haben. Unsere Aussagen zur nicht mehr vorhandenen Verwundbarkeit von Währungen bezüglich bestimmter Attacken beruht einzig und allein auf Aussagen der Entwickler.

Ist mein Geld sicher?
Bitte stellen Sie zuallererst sicher, dass Sie die neueste Version Ihres Wallets verwenden. Diese kann jeweils von den Seiten der Projekte heruntergeladen werden; zum jetzigen Zeitpunkt sind dies Version 0.13.5.7 für Zcoin, Version 3.0.6 für PIVX, Version 0.13.1.5 für Zoin, Version 1.1.1 für SmartCash und Version 4.0.3.0 für Hexxcoin. Besitzen Sie unausgegebene zerocoins in ZCoin oder Zoin (in der graphischen Oberfläche im „Zerocoin“ Tab), so empfehlen wir im Moment auf eine Verwendung zu verzichten, selbst wenn Sie die zum Zeitpunkt dieses Artikels neueste Software verwenden. Die Verwendung ist erst sicher, wenn weitere Reparaturen und/oder entsprechende Forks auf den Blockchains vorgenommen wurden.

Wir empfehlen allen Entwicklern der betroffenen Kryptowährungen und Wallets ein Verlautbarung bezüglich ihrer Pläne zur Reparatur der verbleibenden Probleme zu veröffentlichen. Bitte kontaktieren Sie im Zweifelsfall die Entwickler und nicht uns.

SmartCash and Hexxcoin disabled all features related to Zerocoin. Also, PIVX disabled all features related to Zerocoin for a planned upgrade. As a result your unspend zerocoins are not at risk if you use SmartCash, Hexxcoin or PIVX. However this means that these minted zerocoins cannot be accessed, at least not at the moment. The SmartCash team seems to refund owners of unspent mints, please contact them for support. The Hexxcoin team told us that they plan a fork to enable the Zerocoin features again after applying the appropriate fixes. The PIVX is working on a larger upgrade for their Zerocoin implementation and will enable the Zerocoin features again after the upgrade.

SmartCash und Hexxcoin haben alle zu Zerocoin gehörenden Features deaktiviert. Ebenso hat PIVX seine Zerocoin Features für ein geplantes Upgrade deaktiviert. Damit sind alle nicht ausgegebenen zerocoin in SmartCash, Hexxcoin und PIVX sicher. Auf der anderen Seite bedeutet dies aber auch, dass im Moment kein Zugriff auf die Münzen besteht. Anscheinend erstattet das Team von SmartCash den Benutzern unausgegebene zerocoin zurück; bitte kontaktieren Sie diese für weitere Unterstützung. Das Hexxcoin Team teilte uns mit, dass sie gedenken, die Zerocoin Features nach entsprechender Durchführung von Reparaturen wieder aktivieren würden. PIVX arbeitet im Moment an einem größeren Upgrade für die Implementierung von Zerocoin und wird die entsprechenden Features nach dem Upgrade wieder aktivieren.

Sollten Sie Fragen haben, wenden Sie sich bitte direkt an die Entwickler der Wallets und nicht an uns.

Wurden die Entwickler der Währungen informiert?
Als wir die Verwundbarkeit durch den denial-of-spending Angriff entdeckten kontaktierten wir Zcoin, da uns zu diesem Zeitpunkt nur Zcoin als Implementierung von Zerocoin bekannt war. Das Team von Zcoin engagierte Tim Ruffing aus unserer Gruppe um an den Patches zu arbeiten. Während dieser Zeit stellten wir fest, dass weitere Währungen von der Angriffsmöglichkeit betroffen waren, nämlich PIVX, SmartCash, Zoin und Hexxcoin. Wir meldeten uns nach der Entdeckung ebenfalls bei diesen Teams und entschuldigen uns einige Teams später benachrichtigt zu haben — uns waren diese Währungen nicht bekannt und wir wollten sicherlich nicht eine Währung anderen gegenüber bevorzugen.

Wurde der Fehler ausgenutzt? Wie viel Geld ist betroffen?
Durch den Inflationsbug wurde laut den Entwicklern von Zcoin 17000 Zcoins aus dem Nichts generiert und laut den Entwicklern von SmartCash 2.1 Millionen SmartCash erzeugt. Die Entwickler von Zoin und Hexxcoin teilten uns mit, dass in ihren Währungen jeweils der Fehler nicht ausgenutzt wurde.

Wir haben diese Zahlen nicht überprüft, möchten jedoch jeden interessierten Leser ermutigen selbst mit Hilfe der Blockchains die Zahlen zu überprüfen.

Uns ist nicht bekannt, dass einer der anderen zwei Angriffe in der Praxis durchgeführt wurde. Sollte dies doch geschehen sein, so gibt es keine öffentlichen Aufzeichnungen in der Blockchain dazu.

Ich brauche Hilfe. An wen kann ich mich wenden?
Bitte wenden Sie sich für technische Hilfe an die Entwickler Ihrer jeweiligen Kryptowährung, nicht an uns.

Sollten Sie Fragen oder Anmerkungen haben, die von allgemeinem Interesse sind, oder das Gefühl haben, dass sich ein Fehler in den Artikel eingeschlichen hat, können Sie sich natürlich gerne an uns wenden. Sollten Informationen veraltet sein sehen Sie bitte davon ab uns deshalb zu kontaktieren, da wir nicht beabsichtigen, diesen Artikel bei Veränderungen zu aktualisieren.

Was kann aus diesen Fehlern gelernt werden?
Unserer Meinung nach reduziert es sich auf folgende Punkte, von welchen keiner eine neue Erkenntnis darstellt:

• Beweisbare Sicherheit ist kein Allheilmittel und benötigt extrem viel Erfahrung. Selbst akademische Veröffentlichungen mit ausgefeilten Sicherheitsmodellen und Beweisen bieten keine vollkommene Garantie für die Sicherheit eines kryptographischen Schemas. Wenn Kryptographie in der Praxis verwendet werden soll ist zusätzlicher Aufwand von Nöten, wie er zum Beispiel mit Zcash betrieben wurde.
• Man sollte keine Krypotgraphie verwenden, welche man nicht versteht. Leider scheint dies in der Welt der Kryptowährungen weit verbreitet zu sein. Kryptographie ist schwer und der Teufel steckt im Detail. Daran ändert auch die Tatsache nichts, dass im Moment viele neue Projekte und Firmen im Bereich der Kryptographie arbeiten und neue Erfindungen und Anwendungen von Kryptographie diese einfach erscheinen lassen.
• Man sollte keine Bibliotheken, welche mit großen überdeutlichen Hinweisen zur Sicherheit kommen, verwenden.

Gibt es andere Währungen, welche libzerocoin verwenden?
Soweit wir wissen, sind nur die bereits erwähnten fünf Währungen von unseren Entdeckungen betroffen. Auch wenn wir uns bemüht haben, einen Überblick zu gewinnen, können wir nicht garantieren, dass wir nichts übersehen haben. In der Tat gibt es noch eine weitere Währung, welche libzerocoin verwendet. Dabei handelt es sich um Zerovert, welche jedoch ein toter Vorgänger von Zcoin ist.

Insbesondere erschwert eine allgemeine Übersicht, dass hunderte andere Kryptowährungen, z.B. Regalcoin und Abjcoin, den ursprünglichen Code von libzerocoin in ihre eigene Codebasis übernommen haben. In der Tat brachte eine Suche in Github über 1600 Repositories mit markanten Codefragmenten (um diese Suche anzusehen muss man auf Github eingeloggt sein). Es scheint, dass diese Repositories alle sehr ähnlich sind, auch wenn wir sie nicht einzeln überprüft haben. In allen wurde der Code von libzerocoin auskommentiert, weshalb es sich um falschen Alarm handelt und keine der Währungen von den Problemen betroffen ist.

Uns ist nicht bekannt, ob diese Repositories tatsächliche Kryptowährungen mit einigen laufenden Knoten darstellen oder nicht. Wir gehen davon aus, dass diese Repositories alle von einem automatisierten Werkzeug erzeugt wurden, wobei uns nicht klar ist, weshalb eine nicht verwendete Kopie von libzerocoin eingebunden ist. Es besteht die Möglichkeit, dass das Werkzeug in Verbindung zu einem Service Provider, welcher behauptet Entwürfe für Kryptowährungen zu verkaufen, steht. Diese Entwürfe enthalten „ICO Websites“ und „einen einzigartigen Genesisblock sowie Source Code und fertig kompilierte Clients für Windows und Linux“. Unser Verdacht beruht darauf, dass die Website Regalcoin als Beispiel aufführt, wir haben uns jedoch nicht weiter damit beschäftigt und könnten falsch liegen.

Ich habe den Vortrag gesehen, welcher behauptete, dass die denial-of-spending Angriffsmöglichkeit bereits behoben worden wäre?
Ja, Tim aus unserer Gruppe hielt einen Vortrag auf der Genesis London Conference 2018. Zu diesem Zeitpunkt gingen wir fälschlicherweise auf Grund von Unterhaltungen mit den Entwicklern von Zcoin davon aus, dass die Verwundbarkeit in Zcoin bereits behoben worden wäre und Zoin dieses Update bereits übernommen hätte. Später waren wir dann überrascht davon, dass die Fehler in Zcoin noch nicht vollständig behoben sind (und damit auch nicht in Zoin), was im Gegensatz zu dem steht, was wir in unseren Unterhaltungen mit den Zcoin Entwicklern verstanden haben.

In PIVX war die Situation eine andere: Bei PIVX war uns bekannt, dass das Problem noch nicht behoben ist, wir vergaßen jedoch, dies auf den Folien zu vermerken. Bitte entschuldigen Sie uns, falls dieser Fehler Verwirrung gestiftet haben sollte.

Besteht eine persönliche, geldwerte oder sonstige Verbindung zu den Währungen?
Niemand aus unserem Team besitzt oder besaß Werte der erwähnten Währungen oder investierte auf andere Weise. Die Entwickler von Zcoin beschäftigten Tim von den Autoren als Berater für kryptographische Fragen nach unserem Hinweis um in erster Linie an einer Überarbeitung für libzerocoin zu arbeiten, welche den denial-of-spending Angriff beheben und weitere Probleme lösen sollte. Der Vertrag wurde kurz nach Fertigstellung beendet. Zoin bot uns einen Bug Bounty als Belohnung dafür an, dass wir sie kontaktierten und ihnen die Lösung ihres Problems erklärten. Bisher haben wir die Belohnung nicht angenommen, werden dies aber in Zukunft unter Umständen tun.

Tim Ruffing, Sri Aravinda Krishnan Thyagarajan, Viktoria Ronge und Dominique Schröder

—
Tim ist Doktorand an der Universität des Saarlands, Sri Aravinda Krishnan, sowie Viktoria sind Doktoranden an der Friedrich-Alexander-Universität Erlangen-Nürnberg. Alle Doktoranden werden betreut von Prof. Dr. Dominique Schröder, dem Inhaber des Lehrstuhls für Angewandte Kryptographie an der Friedrich-Alexander-Universität Erlangen-Nürnberg.