Ich habe die ganze Nacht mit jemandem gestritten: „Kann diese Privacy-Chain die Aufsicht passieren?“ — und heute Morgen beim Code-Review festgestellt, dass Dusk die Antwort längst eingebaut hat.
Guter Wurf, die Story mit der großen Welle ist echt klasse—BTC steigt ja richtig gut!
Gestern Nacht habe ich mit einem Freund über Compliance bis um zwei Uhr geredet. Er hat an einer Sache festgenagelt: „Die Kombination aus ZK und UTXO—damit können Prüfinstanzen überhaupt nicht arbeiten, und die Aufsicht wird es nicht akzeptieren.“ Ich habe ihn dann mit Phoenix’ selektivem Disclosure-Konzept abgefertigt. Er hat nur noch geantwortet: „Kann man den Code per One-Click in Excel exportieren?“ und dann einfach aufgelegt.
Diese Aussage hat mich eine Weile richtig in der Luft hängen lassen.
Als ich aber am Morgen die Dokumentation durchging, fiel mir ein Detail auf, das ich vorher nicht so beachtet hatte: Phoenix’ View-Key-Mechanismus—der Schlüssel wird in zwei Teile aufgesplittet: einen zum Anzeigen und einen zum Ausgeben. Erstere kann man Dritten geben, damit sie deine zugehörigen Transaktionen scannen und identifizieren können. Letztere verbleibt für immer bei dir. Was bedeutet das? Die Prüfenden können den View Key nutzen, um zu verifizieren, ob du gegen Regeln verstoßen hast oder ob du zu viel überwiesen hast—aber sie können dir keinen einzigen Cent wegnehmen.
Damit wird „Nachweisbarkeit“ für Compliance und „Unantastbarkeit“ für die Vermögenssicherheit mit nur einem Schlüsselkonzept getrennt und gelöst. „One-Click-Excel exportieren“ als sein Beispiel ist tatsächlich ein echtes Bedürfnis—die Aufsicht diskutiert nicht mit dir über kryptografische Ideale, sie will etwas, das man ausdrucken und für die Akte ablegen kann. Das Spannende an Phoenix’ Design ist: Es behandelt „Privacy“ und „prüfbar“ nicht als Gegensätze, sondern baut mit dem View Key eine Brücke dazwischen: Du darfst sehen, was man sehen soll—aber das, was man nicht herausgeben sollte, lässt sich nicht einfach mitnehmen.
Auch das Nullifier-Mechanismus verdient eine kurze Erwähnung: Für jede private Transaktion wird ein eindeutiges Zerstörungskennzeichen veröffentlicht, statt direkt offenzulegen, welche Note gerade ausgegeben wurde. Prüforganisationen können bestätigen, dass diese Transaktion tatsächlich stattgefunden hat und nicht doppelt ausgegeben wurde—aber sie sehen nicht, wer wie viel an wen überwiesen hat.
Natürlich darf man die Rechnung nicht zu voll machen: Wenn der View Key an Dritte delegiert wird, können sie deine Zahlungsinformationen sehen—und das ist an sich bereits ein Vertrauens-Aufwand. Wem man das zeigt, wie man es danach verwahrt und ob es geleakt wird, kann das Protokoll nicht kontrollieren.
Aber zumindest ist die Richtung richtig: Privacy muss nicht zwangsläufig gegen die Aufsicht arbeiten. Die eigentliche Frage lautet nie „Geht das überhaupt compliant?“, sondern „Welchen Preis hat Compliance?“ Phoenix’ Antwort lautet—der Preis kann eine einzelne Read-Only-View-Key sein, statt dass das ganze Konto nackt herumliegt.
@Dusk $DUSK #dusk
Guter Wurf, die Story mit der großen Welle ist echt klasse—BTC steigt ja richtig gut!
Gestern Nacht habe ich mit einem Freund über Compliance bis um zwei Uhr geredet. Er hat an einer Sache festgenagelt: „Die Kombination aus ZK und UTXO—damit können Prüfinstanzen überhaupt nicht arbeiten, und die Aufsicht wird es nicht akzeptieren.“ Ich habe ihn dann mit Phoenix’ selektivem Disclosure-Konzept abgefertigt. Er hat nur noch geantwortet: „Kann man den Code per One-Click in Excel exportieren?“ und dann einfach aufgelegt.
Diese Aussage hat mich eine Weile richtig in der Luft hängen lassen.
Als ich aber am Morgen die Dokumentation durchging, fiel mir ein Detail auf, das ich vorher nicht so beachtet hatte: Phoenix’ View-Key-Mechanismus—der Schlüssel wird in zwei Teile aufgesplittet: einen zum Anzeigen und einen zum Ausgeben. Erstere kann man Dritten geben, damit sie deine zugehörigen Transaktionen scannen und identifizieren können. Letztere verbleibt für immer bei dir. Was bedeutet das? Die Prüfenden können den View Key nutzen, um zu verifizieren, ob du gegen Regeln verstoßen hast oder ob du zu viel überwiesen hast—aber sie können dir keinen einzigen Cent wegnehmen.
Damit wird „Nachweisbarkeit“ für Compliance und „Unantastbarkeit“ für die Vermögenssicherheit mit nur einem Schlüsselkonzept getrennt und gelöst. „One-Click-Excel exportieren“ als sein Beispiel ist tatsächlich ein echtes Bedürfnis—die Aufsicht diskutiert nicht mit dir über kryptografische Ideale, sie will etwas, das man ausdrucken und für die Akte ablegen kann. Das Spannende an Phoenix’ Design ist: Es behandelt „Privacy“ und „prüfbar“ nicht als Gegensätze, sondern baut mit dem View Key eine Brücke dazwischen: Du darfst sehen, was man sehen soll—aber das, was man nicht herausgeben sollte, lässt sich nicht einfach mitnehmen.
Auch das Nullifier-Mechanismus verdient eine kurze Erwähnung: Für jede private Transaktion wird ein eindeutiges Zerstörungskennzeichen veröffentlicht, statt direkt offenzulegen, welche Note gerade ausgegeben wurde. Prüforganisationen können bestätigen, dass diese Transaktion tatsächlich stattgefunden hat und nicht doppelt ausgegeben wurde—aber sie sehen nicht, wer wie viel an wen überwiesen hat.
Natürlich darf man die Rechnung nicht zu voll machen: Wenn der View Key an Dritte delegiert wird, können sie deine Zahlungsinformationen sehen—und das ist an sich bereits ein Vertrauens-Aufwand. Wem man das zeigt, wie man es danach verwahrt und ob es geleakt wird, kann das Protokoll nicht kontrollieren.
Aber zumindest ist die Richtung richtig: Privacy muss nicht zwangsläufig gegen die Aufsicht arbeiten. Die eigentliche Frage lautet nie „Geht das überhaupt compliant?“, sondern „Welchen Preis hat Compliance?“ Phoenix’ Antwort lautet—der Preis kann eine einzelne Read-Only-View-Key sein, statt dass das ganze Konto nackt herumliegt.
@Dusk $DUSK #dusk