#dusk $ACE $BTW $DUSK @Dusk
Was mich auf der Dusk Foundation ständig kratzen lässt, ist nicht die Phoenix-Übertragung.
Dieser Teil ist bereits abgeschlossen.
Es ist der ausgegebene Phoenix-Beleg, den der Auditor erst drei Monate später anfragt.
Schon gut.
Übertragung kommt an. Dusk’ Phoenix-Modell hält Absender, Empfänger, Betrag und Notiz-Verknüpfung abgeschirmt. Später wird genau diese Notiz erneut ausgegeben und geht in einen neuen Phoenix-Zustand über.
Ganz normal.
Dann trifft die Anfrage zur Berichterstattung ein.
Ich sehe förmlich, wie das Wallet-Team das aktuelle Phoenix-Guthaben öffnet und merkt, dass der ausgegebene Beleg, den sie nachweisen müssen, nicht mehr zur Live-Set von ausgebbaren Ausgaben gehört.
Also hat der Phoenix-Viewing-Key jetzt noch eine andere Aufgabe.
Nicht nur genug anzeigen.
Weit genug zurückreichen.
Aber nicht so weit, dass eine einzige alte Zahlung jede spätere Phoenix-Notiz und jede spätere Ausgabe in die Anfrage mitzieht.
Da fängt das Ganze an, richtig nervig zu werden.
Der Auditor will, dass der Betrag an diesen ausgegebenen Phoenix-Beleg gebunden ist.
Das Treasury hat den alten Rechnungszeitstempel.
Das aktuelle Wallet hat neuere verschlüsselte Notizen.
Die ursprüngliche Phoenix-Ausgabe ist bereits hinter neueren verschlüsselten Notizen begraben.
Auf Dusk bedeutet das Ausgeben einer Phoenix-Notiz: Sie wird aus dem live ausgebbaren Set entfernt, nicht aus der Phoenix-Historie, die ein Auditor später eventuell rekonstruieren muss. DuskDS kann den neueren Phoenix-Zustand ausgleichen, und Phoenix kann diese späteren Notizen weiter abgeschirmt halten, während der Viewing-Key trotzdem bis zur alten Ausgabe zurückreichen muss, ohne mehr spätere Phoenix-Notizen zu öffnen, als die Anfrage tatsächlich benötigt.
Ich würde diesen Umfang zweimal prüfen.
Denn eine angefragte ausgegebene Phoenix-Notiz klingt harmlos, bis der Viewing-Key anfängt, in spätere Phoenix-Ausgaben hineinzureichen, um sie zu erklären.
Toll.
Der Auditor hat eine alte Zahlung angefragt.
Das Wallet hat inzwischen drei neuere Phoenix-Zustände durchlaufen.
Und jetzt zieht der Dusk-Viewing-Key-Umfang die spätere Phoenix-Historie in Richtung einer Notiz, die das Wallet nicht einmal mehr ausgeben kann.
Alles klar..
Also: Was zeigt Dusk, wenn die Phoenix-Notiz, die auditiert wird, schon nicht mehr im live ausgebbaren Set ist?
#Dusk @Dusk
Was mich auf der Dusk Foundation ständig kratzen lässt, ist nicht die Phoenix-Übertragung.
Dieser Teil ist bereits abgeschlossen.
Es ist der ausgegebene Phoenix-Beleg, den der Auditor erst drei Monate später anfragt.
Schon gut.
Übertragung kommt an. Dusk’ Phoenix-Modell hält Absender, Empfänger, Betrag und Notiz-Verknüpfung abgeschirmt. Später wird genau diese Notiz erneut ausgegeben und geht in einen neuen Phoenix-Zustand über.
Ganz normal.
Dann trifft die Anfrage zur Berichterstattung ein.
Ich sehe förmlich, wie das Wallet-Team das aktuelle Phoenix-Guthaben öffnet und merkt, dass der ausgegebene Beleg, den sie nachweisen müssen, nicht mehr zur Live-Set von ausgebbaren Ausgaben gehört.
Also hat der Phoenix-Viewing-Key jetzt noch eine andere Aufgabe.
Nicht nur genug anzeigen.
Weit genug zurückreichen.
Aber nicht so weit, dass eine einzige alte Zahlung jede spätere Phoenix-Notiz und jede spätere Ausgabe in die Anfrage mitzieht.
Da fängt das Ganze an, richtig nervig zu werden.
Der Auditor will, dass der Betrag an diesen ausgegebenen Phoenix-Beleg gebunden ist.
Das Treasury hat den alten Rechnungszeitstempel.
Das aktuelle Wallet hat neuere verschlüsselte Notizen.
Die ursprüngliche Phoenix-Ausgabe ist bereits hinter neueren verschlüsselten Notizen begraben.
Auf Dusk bedeutet das Ausgeben einer Phoenix-Notiz: Sie wird aus dem live ausgebbaren Set entfernt, nicht aus der Phoenix-Historie, die ein Auditor später eventuell rekonstruieren muss. DuskDS kann den neueren Phoenix-Zustand ausgleichen, und Phoenix kann diese späteren Notizen weiter abgeschirmt halten, während der Viewing-Key trotzdem bis zur alten Ausgabe zurückreichen muss, ohne mehr spätere Phoenix-Notizen zu öffnen, als die Anfrage tatsächlich benötigt.
Ich würde diesen Umfang zweimal prüfen.
Denn eine angefragte ausgegebene Phoenix-Notiz klingt harmlos, bis der Viewing-Key anfängt, in spätere Phoenix-Ausgaben hineinzureichen, um sie zu erklären.
Toll.
Der Auditor hat eine alte Zahlung angefragt.
Das Wallet hat inzwischen drei neuere Phoenix-Zustände durchlaufen.
Und jetzt zieht der Dusk-Viewing-Key-Umfang die spätere Phoenix-Historie in Richtung einer Notiz, die das Wallet nicht einmal mehr ausgeben kann.
Alles klar..
Also: Was zeigt Dusk, wenn die Phoenix-Notiz, die auditiert wird, schon nicht mehr im live ausgebbaren Set ist?
#Dusk @Dusk
