Können böswillige Zahler den Zahlungsempfänger in Zcash deanonymisieren?

tl;dr Alice kann Zahlungen offenbaren, die sie an Bob geleistet hat. Sie kann keine Zahlungen offenlegen, die andere an Bob geleistet haben, oder was (wenn überhaupt) Bob mit der von Alice gesendeten ZEC macht.

Das Aufdecken des Urbildes der Notenzusage beweist nur, dass Alice das Urbild kennt. Es beweist nicht, dass Alice die Transaktion gesendet hat, da der Beweis wiederholbar ist: Einmal aufgedeckt, kann jeder die Zufälligkeit nehmen und Daten notieren und sie jemand anderem zeigen.

Damit Alice jemandem beweisen kann, dass sie die Transaktion gesendet hat, kann sie Folgendes tun:

• Schreiben Sie eine Nachricht, die Folgendes enthält:
  • Der private Schlüssel esk, der verwendet wird, um die Notiz (Zufälligkeit und Wert) an Bob zu verschlüsseln.
  • Bobs Zahlungsadresse.
  • Ein von der Person Alice gewählter Challenge-String überzeugt.
• Signieren Sie die Nachricht mit dem privaten Schlüssel , der dem joinSplitPrivKeyentspricht, der joinsplitPubKeyursprünglich zum Signieren der Transaktion verwendet wurde.

Die signierte Nachricht ist ein Beweis dafür, dass Alice derzeit Zugriff darauf hat joinSplitPrivKey(weil die Abfragezeichenfolge frisch ist). Unter der Annahme, dass dies joinSplitPrivKeynie offenbart wird, ist Alice nicht von der Person zu unterscheiden, die die Transaktion erstellt hat (dh entweder sie oder jemand mit ihren Ausgabenschlüsseln hat die Zahlung vorgenommen). Dies nennen wir eine Zahlungsoffenlegung , und so würden Sie beispielsweise einer Börse (oder einer Streitbeilegungsstelle eines Drittanbieters) nachweisen, dass Sie sie tatsächlich bezahlt haben.

Was Sie beschreiben, ist im Grunde das gleiche Problem, das Messaging-Apps mit End-to-End-Verschlüsselung haben: Jemand mit beabsichtigtem Zugriff auf die Daten kann diese versehentlich oder absichtlich preisgeben. Das Entfernen dieses potenziellen Datenschutzlecks würde per Definition bedeuten, dass Alice einige oder alle Details über ihre eigenen ausgehenden Transaktionen nicht sehen kann, was entweder ein Widerspruch ist (im Zcash-Modell muss Alice in der Lage sein, eine Verpflichtung aus ihrem Pre-Image zu berechnen, um um gültige Transaktionen zu erstellen) oder ein völlig unbrauchbares Zahlungssystem!

Beachten Sie jedoch, dass Alice, obwohl sie beweisen kann, dass sie eine Transaktion an Bob gesendet hat, nichts darüber preisgeben kann, was Bob mit der erhaltenen Notiz macht (weil sie Bobs Ausgabenschlüssel nicht hat und daher den Nullifikator nicht berechnen kann, der dies tun würde zum Zeitpunkt des Verbringens aufgedeckt werden). Alices Fähigkeit, Informationen preiszugeben, ist auf Informationen beschränkt, die sie jemals sehen konnte.

Um die Antwort von @str4d zu ergänzen, finden Sie hier Links zu öffentlicher Dokumentation und Diskussion der Zahlungsoffenlegungsfunktion:

• Selektive Offenlegung und abgeschirmte Anzeigeschlüssel - Zcash-Blog
• Offenlegung von Zahlungen (experimentelle Funktion)
• Eine Einführung in die Offenlegung von Zahlungen in Zcash - Gareth Davies

Beachten Sie, dass Bob, wenn er sich wegen dieser Möglichkeit Sorgen gemacht hätte, Alice eine eindeutige Adresse hätte geben können, um ihn zu bezahlen, sodass eine aufgedeckte Zahlung an diese Adresse nicht mit seinen anderen Adressen verknüpft werden könnte. Dies wird in Abschnitt 3.1 der Protokollspezifikation vorgeschlagen.

In Sapling gibt es eine neue Funktion namens „diversifizierte Zahlungsadressen“, die diese Nutzung effizienter macht: Bob kann jedem potenziellen Zahler eine eindeutige diversifizierte Adresse geben und kann die Blockchain dennoch so effizient nach eingehenden Zahlungen durchsuchen, wie er es getan hätte nur eine Adresse. Wir planen, dies in das Zcash-Äquivalent von BIP 32 (Hierarchical Deterministic Addresses) zu integrieren, sodass alle mit einer Brieftasche verbundenen Geheimnisse mit einem einzigen Seed gesichert werden können.