#dusk $DUSK @Dusk
Ich habe nachgesehen, wo Dusk tatsächlich „enthüllen gegenüber autorisierten Parteien“ umsetzt. Gefunden habe ich etwas, das kleiner ist als der Ausdruck vermuten lässt. Jede Phoenix-Notiz hat einen Besitzer, und dieser Besitzer hält einen View Key. Teile ihn, und wer ihn in der Hand hat, kann jetzt jede Ausgabe, die zu dir gehört, erkennen — plus den Wert auf verschleierten Notizen entschlüsseln. Das ist die Zugangskontroll-Schicht. Ende.
$DUSK #dusk @Duskfoundation — soweit ich das aus der eigenen Spezifikation des Keys beurteilen kann, ist es einfach ein Skalar und ein Punkt. Kein Feld für eine Rolle, kein Geltungsbereich, keine Ablaufzeit, die eingebacken wäre. Nichts, was die Chain dazu bringen würde, einen Regulator anders zu behandeln als einen Geschäftspartner oder einen neugierigen Ex-Mitarbeiter. Wenn diese Unterscheidung existiert, dann steckt sie nicht im Key selbst.
Was sich für mich geändert hat: „selektive Offenlegung“ klingt wie ein Feature der Richtlinie. Tatsächlich gibt es dort Schlüsselverwahrung (Key Custody). Das Protokoll gibt Besitzern einen Hebel — teilen oder nicht — nicht eine Berechtigungs-Engine. Ob die richtige Partei diesen Key bekommt, aus dem richtigen Grund, ist eine Prozessfrage, die vollständig außerhalb der Chain liegt.
Als Nächstes will ich prüfen: Gibt das Teilen eines View Key die vollständige Notizhistorie des Besitzers in einem Rutsch frei, oder kann Dusk es auf eine einzelne Transaktion beschränken? Im Moment lesen sich die Dokumente „alles oder nichts“, aber ich möchte das mit der tatsächlichen Wallet-Implementierung abgleichen — nicht nur mit der Architekturseite.
Ich habe nachgesehen, wo Dusk tatsächlich „enthüllen gegenüber autorisierten Parteien“ umsetzt. Gefunden habe ich etwas, das kleiner ist als der Ausdruck vermuten lässt. Jede Phoenix-Notiz hat einen Besitzer, und dieser Besitzer hält einen View Key. Teile ihn, und wer ihn in der Hand hat, kann jetzt jede Ausgabe, die zu dir gehört, erkennen — plus den Wert auf verschleierten Notizen entschlüsseln. Das ist die Zugangskontroll-Schicht. Ende.
$DUSK #dusk @Duskfoundation — soweit ich das aus der eigenen Spezifikation des Keys beurteilen kann, ist es einfach ein Skalar und ein Punkt. Kein Feld für eine Rolle, kein Geltungsbereich, keine Ablaufzeit, die eingebacken wäre. Nichts, was die Chain dazu bringen würde, einen Regulator anders zu behandeln als einen Geschäftspartner oder einen neugierigen Ex-Mitarbeiter. Wenn diese Unterscheidung existiert, dann steckt sie nicht im Key selbst.
Was sich für mich geändert hat: „selektive Offenlegung“ klingt wie ein Feature der Richtlinie. Tatsächlich gibt es dort Schlüsselverwahrung (Key Custody). Das Protokoll gibt Besitzern einen Hebel — teilen oder nicht — nicht eine Berechtigungs-Engine. Ob die richtige Partei diesen Key bekommt, aus dem richtigen Grund, ist eine Prozessfrage, die vollständig außerhalb der Chain liegt.
Als Nächstes will ich prüfen: Gibt das Teilen eines View Key die vollständige Notizhistorie des Besitzers in einem Rutsch frei, oder kann Dusk es auf eine einzelne Transaktion beschränken? Im Moment lesen sich die Dokumente „alles oder nichts“, aber ich möchte das mit der tatsächlichen Wallet-Implementierung abgleichen — nicht nur mit der Architekturseite.