#dusk $DUSK Heute habe ich mit einem Freund per Sprachnachricht über die Privatsphäre-Mechanismen von @Dusk diskutiert – und wir sind uns gestritten. Halbwegs mitten im Streit hat die andere Seite einfach aufgelegt. Ich stand allein da, starrte zwei Sekunden aufs Handy, aber mein Kopf war überraschend ruhig, und ich blätterte nebenbei in den technischen Notizen, die ich früher gespeichert hatte.
Gestritten wurde über das alte Thema, ob man bei Privatsphäre für die Benutzerfreundlichkeit Kompromisse machen soll. Die andere Person sagte: „Zero-Knowledge-Proofs kann man auf dem Handy sowieso nicht sinnvoll berechnen; wenn normale Leute es aus Bequemlichkeit machen wollen, müssen sie am Ende ihre Privatsphäre aufgeben.“ Damals habe ich darauf nicht richtig reagiert. Später, als ich weiter darüber nachdachte, fand ich die Einschätzung selbst aber problematisch – sie setzt stillschweigend voraus, dass man als Nutzer die gesamte Rechenlast für Privatsphäre selbst tragen muss. In dem Phoenix-Design gibt es jedoch eigentlich schon eine Lücke.
Bei Phoenix ist der Schlüssel keine einzelne Einheit, sondern in zwei Teile zerlegt: einen View Key (Ansichtsschlüssel) und einen Spend Key (Ausgabeschlüssel). Mit dem View Key kann man scannen und erkennen, welche Transaktionen zu dir gehören und wie hoch der Betrag ist, aber man kann nicht den privaten Schlüssel ausrechnen, der nötig ist, um die Coins auszugeben – weil die andere Hälfte an Informationen fehlt. Das bedeutet, du kannst den Job „Transaktionen identifizieren, die mir gehören“ an einen Dritten auslagern: Er sieht zwar, was du erhältst, kann aber dein Vermögen nicht wegnehmen. Das Rechnen für die ZK-Proofs ist zwar rechnerintensiv, aber auch dieses kann man über ein ähnliches Delegationsmodell auslagern, ohne dass man seinem eigenen Handy die ganze harte Last aufbürden muss. $BTC
Damit wird ein altes Problem eines Privacy-Protokolls ziemlich elegant gelöst: Früher hatte man immer das Gefühl, Privatsphäre und Benutzerfreundlichkeit seien ein Entweder-oder – entweder du trägst die Kosten selbst oder du gehst quasi unverschlüsselt durchs Leben. Diese Designaufteilung trennt „wer sehen darf“ und „wer ausgeben darf“ konsequent. Dadurch sinkt die Einstiegshürde.
Aber diese Rechnung kann ich nicht komplett glattziehen: Delegiertes Scannen öffnet aktiv eine Tür – dass Außenstehende sehen können, dass du Geld einnimmst. Wem man delegiert, ob dieser Dritte vertrauenswürdig ist, und vieles weitere ist dann wieder eine eigene Vertrauensfrage, die das Protokoll selbst nicht automatisch kontrollieren kann. Bequemlichkeit und Angriffsfläche scheinen wie auf einer Wippe immer auf der einen oder anderen Seite zu landen.
Wenn du an meiner Stelle wärst: Würdest du so eine „Scan-Berechtigung“ delegieren, um dafür eine leichtere Bedienbarkeit zu bekommen? Wo würdest du deine Grenze ziehen? Schreib’s in die Kommentare.
$DUSK #dusk @Dusk
Gestritten wurde über das alte Thema, ob man bei Privatsphäre für die Benutzerfreundlichkeit Kompromisse machen soll. Die andere Person sagte: „Zero-Knowledge-Proofs kann man auf dem Handy sowieso nicht sinnvoll berechnen; wenn normale Leute es aus Bequemlichkeit machen wollen, müssen sie am Ende ihre Privatsphäre aufgeben.“ Damals habe ich darauf nicht richtig reagiert. Später, als ich weiter darüber nachdachte, fand ich die Einschätzung selbst aber problematisch – sie setzt stillschweigend voraus, dass man als Nutzer die gesamte Rechenlast für Privatsphäre selbst tragen muss. In dem Phoenix-Design gibt es jedoch eigentlich schon eine Lücke.
Bei Phoenix ist der Schlüssel keine einzelne Einheit, sondern in zwei Teile zerlegt: einen View Key (Ansichtsschlüssel) und einen Spend Key (Ausgabeschlüssel). Mit dem View Key kann man scannen und erkennen, welche Transaktionen zu dir gehören und wie hoch der Betrag ist, aber man kann nicht den privaten Schlüssel ausrechnen, der nötig ist, um die Coins auszugeben – weil die andere Hälfte an Informationen fehlt. Das bedeutet, du kannst den Job „Transaktionen identifizieren, die mir gehören“ an einen Dritten auslagern: Er sieht zwar, was du erhältst, kann aber dein Vermögen nicht wegnehmen. Das Rechnen für die ZK-Proofs ist zwar rechnerintensiv, aber auch dieses kann man über ein ähnliches Delegationsmodell auslagern, ohne dass man seinem eigenen Handy die ganze harte Last aufbürden muss. $BTC
Damit wird ein altes Problem eines Privacy-Protokolls ziemlich elegant gelöst: Früher hatte man immer das Gefühl, Privatsphäre und Benutzerfreundlichkeit seien ein Entweder-oder – entweder du trägst die Kosten selbst oder du gehst quasi unverschlüsselt durchs Leben. Diese Designaufteilung trennt „wer sehen darf“ und „wer ausgeben darf“ konsequent. Dadurch sinkt die Einstiegshürde.
Aber diese Rechnung kann ich nicht komplett glattziehen: Delegiertes Scannen öffnet aktiv eine Tür – dass Außenstehende sehen können, dass du Geld einnimmst. Wem man delegiert, ob dieser Dritte vertrauenswürdig ist, und vieles weitere ist dann wieder eine eigene Vertrauensfrage, die das Protokoll selbst nicht automatisch kontrollieren kann. Bequemlichkeit und Angriffsfläche scheinen wie auf einer Wippe immer auf der einen oder anderen Seite zu landen.
Wenn du an meiner Stelle wärst: Würdest du so eine „Scan-Berechtigung“ delegieren, um dafür eine leichtere Bedienbarkeit zu bekommen? Wo würdest du deine Grenze ziehen? Schreib’s in die Kommentare.
$DUSK #dusk @Dusk