In jeder Versandstation ist der Abholcode jedes Mal anders – selbst wenn es immer noch derselbe Empfänger ist, sagt das System dir nicht: "Diese beiden Abholungen stammen von derselben Person".
Vor einiger Zeit habe ich für einen Nachbarn Pakete abgeholt und dabei festgestellt, dass das System der Paketstation ziemlich interessant ist: Dieselbe Person holt zweimal ab, aber die Abholcodes unterscheiden sich vollständig. Wenn die Angestellten scannen, sehen sie nur: "Diese Abholung ist für wen?" – nicht aber, ob diese Person zuvor schon einmal da war.
Später, als ich das Dusk-Phoenix-Transaktionsmodell nachgeschlagen habe, habe ich herausgefunden, dass diese Logik – "jedes Mal neue Codes, sodass Außenstehende keinen Zusammenhang herstellen können" – auch on-chain verwendet wird, und dort sogar noch konsequenter.
Bei Phoenix bekommt die empfangende Seite bei jeder einzelnen Überweisung nicht eine feste Adresse, sondern einen einmaligen "note public key" (abgekürzt npk). Der Absender berechnet diesen einmaligen npk, indem er den langfristigen öffentlichen Schlüssel des Empfängers nimmt und zusätzlich eine Zufallszahl verwendet. Der Empfänger kann anhand seines eigenen view key pro Transaktion prüfen: Wenn er den npk berechnen kann, dann ist diese Transaktion an ihn gerichtet. Der entscheidende Punkt ist: dieser npk ist jedes Mal anders. Selbst wenn dieselbe Person zehn Zahlungen erhalten hat, kann man für Außenstehende, die die Daten in der Blockchain scannen, nicht erkennen, ob diese zehn Zahlungen an denselben Empfänger gingen – denn es gibt schlicht keine wiederkehrende feste Adresse, die man zum Abgleich heranziehen könnte.
Dieses Design soll "unlinkability" (Nicht-assoziierbarkeit) lösen: Es geht nicht darum, dass man sieht, "dass du Geld erhalten hast" – sondern darum, dass diese zehn Zahlungen nicht zu der Beziehung zusammengemorpht werden können: "dass sie alle von derselben Person kommen". Außerdem unterstützt es Delegation: Nutzer können den view key separat an Dritte geben, damit diese für sie scannen, welche Transaktionen die eigenen sind, aber ohne die Berechtigung zu haben, Geld auszugeben. Diese Aufteilung ist ziemlich fein.
Einmalige Adressen klingen zwar sicher, bedeuten aber auch, dass die Prüf- und Berechnungsarbeit pro Transaktion größer ist als bei Modellen mit festen Adressen. Ob die Scan-Effizienz bei größerem Maßstab mithalten kann, hängt daher von den tatsächlichen Daten ab.
$DUSK
#dusk @Dusk
Vor einiger Zeit habe ich für einen Nachbarn Pakete abgeholt und dabei festgestellt, dass das System der Paketstation ziemlich interessant ist: Dieselbe Person holt zweimal ab, aber die Abholcodes unterscheiden sich vollständig. Wenn die Angestellten scannen, sehen sie nur: "Diese Abholung ist für wen?" – nicht aber, ob diese Person zuvor schon einmal da war.
Später, als ich das Dusk-Phoenix-Transaktionsmodell nachgeschlagen habe, habe ich herausgefunden, dass diese Logik – "jedes Mal neue Codes, sodass Außenstehende keinen Zusammenhang herstellen können" – auch on-chain verwendet wird, und dort sogar noch konsequenter.
Bei Phoenix bekommt die empfangende Seite bei jeder einzelnen Überweisung nicht eine feste Adresse, sondern einen einmaligen "note public key" (abgekürzt npk). Der Absender berechnet diesen einmaligen npk, indem er den langfristigen öffentlichen Schlüssel des Empfängers nimmt und zusätzlich eine Zufallszahl verwendet. Der Empfänger kann anhand seines eigenen view key pro Transaktion prüfen: Wenn er den npk berechnen kann, dann ist diese Transaktion an ihn gerichtet. Der entscheidende Punkt ist: dieser npk ist jedes Mal anders. Selbst wenn dieselbe Person zehn Zahlungen erhalten hat, kann man für Außenstehende, die die Daten in der Blockchain scannen, nicht erkennen, ob diese zehn Zahlungen an denselben Empfänger gingen – denn es gibt schlicht keine wiederkehrende feste Adresse, die man zum Abgleich heranziehen könnte.
Dieses Design soll "unlinkability" (Nicht-assoziierbarkeit) lösen: Es geht nicht darum, dass man sieht, "dass du Geld erhalten hast" – sondern darum, dass diese zehn Zahlungen nicht zu der Beziehung zusammengemorpht werden können: "dass sie alle von derselben Person kommen". Außerdem unterstützt es Delegation: Nutzer können den view key separat an Dritte geben, damit diese für sie scannen, welche Transaktionen die eigenen sind, aber ohne die Berechtigung zu haben, Geld auszugeben. Diese Aufteilung ist ziemlich fein.
Einmalige Adressen klingen zwar sicher, bedeuten aber auch, dass die Prüf- und Berechnungsarbeit pro Transaktion größer ist als bei Modellen mit festen Adressen. Ob die Scan-Effizienz bei größerem Maßstab mithalten kann, hängt daher von den tatsächlichen Daten ab.
$DUSK
#dusk @Dusk
