Eine Prüfung einer Kryptowährungsbrieftasche bietet einem Dritten (dem „Prüfer“) die Möglichkeit, die Transaktionen dieser Brieftasche einzusehen und den korrekten aktuellen Kontostand zu berechnen, ohne das Recht, Geld auszugeben.

Der Artikel beschreibt verschiedene Möglichkeiten, eine solche Möglichkeit im Kryptowährungsprotokoll CryptoNote 2.0 [ 1 ] bereitzustellen , in dem die Prüfung nur teilweise implementiert ist: Mithilfe eines Verfolgungsschlüssels können Sie eingehende Transaktionen erkennen, aber um ausgehende Transaktionen zu erkennen, benötigen Sie einen vollständigen Satz von Schlüsseln.

Das Material richtet sich an Leser, die mit dem Thema Blockchain und „klassischen“ Kryptowährungen sowie mit den Grundlagen der Kryptographie auf elliptischen Kurven vertraut sind.

Inhalt

1.
2.
3. CryptoNote
4. 1/3. Bytecoin Auditable Coins
  4.1. tx.version < amethyst, legacy address
  4.2. tx.version ≥ amethyst
  4.3. tx.version ≥ amethyst, legacy address
  4.4. tx.version ≥ amethyst, amethyst address
  4.5. CryptoNote Bytecoin Amethyst
5. 2/3. CryptoNote Anton Sokolov
6. 3/3.
7.

1.

CryptoNote?

Seltsamerweise haben die meisten, die sich für Blockchain-Technologie interessieren, nichts über CryptoNote gehört, und dies trotz der Tatsache, dass diese Technologie die Basis für mehr als 300 Gabeln geworden ist, von denen die berühmteste Monero ist.

Im Jahr 2014 erschienen Erwähnungen in der Kryptowährungsumgebung [ 2] über ein Projekt namens Bytecoin. Das Projekt war keine Abzweigung von Bitcoin oder einem anderen Open-Source-Projekt und hatte eine völlig neue Codebasis, was für diese Zeit äußerst ungewöhnlich war. Das Hauptkonzept bestand darin, eine Datenschutztechnologie namens CryptoNote zu implementieren. Die Privatsphäre wurde durch zwei Mechanismen gewährleistet: Stealth-Adressen und Mischen von Eingaben unter Verwendung einer Ringsignatur (zu dieser Zeit auch als "Mixer in der Blockchain" bezeichnet). Da Zcash zu dieser Zeit nur theoretisch existierte, erwies sich die Technologie als sehr wettbewerbsfähig und verursachte eine große Resonanz in der Kryptowährungs-Community.

Bald gelang es einer Gruppe von Enthusiasten, die Interesse an einer der ersten Gabeln dieser Technologie zeigten und dann die Initiative in dieser Gabel ergriffen, mit ihren energischen Aktionen, die größte Aufmerksamkeit sowohl in der Community als auch bei den Investoren auf die Technologie zu lenken. Diese Gabel hieß BitMonero [ 3 , 4 ], wurde aber bald in Monero umbenannt.

In Zukunft entwickelten sich beide Projekte - Bytecoin und Monero - auf technologisch unterschiedliche Weise: Wenn Bytecoin ein geschlossenes anonymes Projekt blieb, wurde Monero zu einem großen Community-gesteuerten Projekt mit einer sehr großen Anzahl von Teilnehmern und Entwicklern. Beide sind jedoch eine Entwicklung der CryptoNote-Technologie.

Das Konzept der Prüfung und ihre Anwendung

Im Gegensatz zur klassischen „pseudonymen“ Blockchain wie Bitcoin, bei der jeder durch Scannen der Blockchain die Salden einer beliebigen Adresse in einer privaten Blockchain, insbesondere in CryptoNote, trivial berechnen kann, ist diese Aufgabe ohne zusätzliches Wissen kaum möglich. Erstens gibt es dank der Technologie der Stealth-Adressen keine Verweise auf Adressen in der Blockchain (diese Eigenschaft wird normalerweise als Anonymität bezeichnet ). Zweitens ist es aufgrund der Tatsache, dass die Transaktionseingabe dank der Ringsignatur nicht eine bestimmte Ausgabe der übergeordneten Transaktion anzeigt, sondern im allgemeinen Fall die Menge der wahrscheinlichen Ausgaben anzeigt, auch nicht möglich, die Bewegung von Geldern zu verfolgen (diese Eigenschaft wird als Nichtrückverfolgbarkeit bezeichnet ).

Nach dem traditionellen Verständnis der privaten Kryptowährung sind diese Eigenschaften erforderlich. In besonderen Fällen möchte der Brieftaschenbesitzer jedoch möglicherweise den Verlauf seiner Transaktionen und den aktuellen Kontostand der Brieftasche an Dritte weitergeben und gleichzeitig die Unmöglichkeit garantieren, Geld von Dritten auszugeben. Dies kann beispielsweise für den Austausch, die Interaktion mit Regulierungsbehörden oder Kontrollbehörden erforderlich sein. Darüber hinaus kann dies für verschiedene Fonds wichtig sein, die für eine bestimmte Personengruppe transparent oder vollständig öffentlich sein möchten.

Formal gesehen bedeutet eine Prüfung von Geldbörsen für einen Dritten (den „Prüfer“) die Möglichkeit, die Transaktionen dieser Geldbörse einzusehen und den korrekten aktuellen Kontostand zu berechnen, ohne das Recht zu übertragen, Geld auszugeben. In der Originalversion von CryptoNote wurde die Prüfung nur teilweise implementiert: Mithilfe eines Verfolgungsschlüssels können Sie eingehende Transaktionen erkennen. Um ausgehende Transaktionen zu erkennen, benötigen Sie einen vollständigen Schlüsselsatz.

Über den Autor und den Zweck der Veröffentlichung

Der Autor dieses Materials ist einer der Hauptentwickler des Zano-Projekts - eines Projekts, das auf CryptoNote basiert und seit mehreren Jahren mit denselben Händen entwickelt wird, die den ursprünglichen Technologiecode geschrieben haben.

Unser Team erwägt nun, dem Projekt ein Wallet-Audit hinzuzufügen und Untersuchungen zu diesem Thema durchzuführen, um die beste Option auszuwählen. Der Autor möchte den Lesern in diesem Artikel die Ergebnisse einiger dieser Studien vorstellen.

2. Grundlegende Informationen zur Kryptographie auf elliptischen Kurven

Das CryptoNote-Protokoll verwendet eine elliptische Kurve aus dem digitalen Signaturschema ed25519 mit öffentlichem Schlüssel [ 5 ].

Erinnern Sie sich an die Hauptparameter dieser Kurve und geben Sie zusätzliche Definitionen an.

1. Eine große Primzahl wurde behoben $$$q = 2^{255}-19$.
   $$$F_q$ $$$q$.
2. $$$F_q$, $$$E/F_q$:
   $$$−x^2+y^2= 1 +dx^2y^2$
   $$$d = −121665/121666$ ( $$$F_q$ ).
   $$$x$ $$$y$.
3. , : $$$F(A, B) = C$, «», , , ( [6]). , , , , $$$E(F_q)$.
   ( ): $$$\# E(F_q)=2^cl$, $$$= 3$ () $$$l=2^{252}+27742317777372353535851937790883648493$.
4. $$$(x, y)$. , , $$$y$, 256- .
   $$$x$-, (. ), , , $$$y$-.
5. $$$G = (x, −4/5)$. $$$y$-, x .
6. (. . 3) $$$G$ $$$n$ ($$$*$, ) , $$$\mathbf{G}$, , $$$E(F_q)$:
   $$$\#\mathbf{G} < \#E(F_q)$,
   
   $$$\#\mathbf{G}=l=2^{252}+27742317777372353535851937790883648493$.
7. $$$X$ — , $$$\mathbf{G}$:
   $$$X \in \mathbf{G}$
8. $$$x$, , $$$X$ — , :
   $$$X = x*G, x \in [1; l-1]$
   , (. ), 256- .
9. - $$$H$ ( cn_fast_hash). 32- :$$$H:\{0, 1\}^* \to [0,2^{256}-1]$
10. - $$$H_s$ ($$$s$ scalar) , , .. :
    $$$H_s:\{0,1\}^* \to [1; l-1]$
    $$$H_s$ $$$H$:
    $$$H_s(x)= H(x) \mod (l-1) + 1$
11. - $$$H_p$ ($$$p$ point — ) $$$\mathbf{G}$, , :
    $$$H_p:\{0,1\}^* \to \mathbf{G}$
    - , -, 256 (. . 4), -, $$$\mathbf{G}$ (. . 6).
    $$$H_p$ $$$H(H(...H(x)...))$ , $$$X \in \mathbf{G}$.
    CryptoNote , ge_fromfe_frombytes_vartime, [7].
    , 256 $$$\mathbf{G}$ :
    $$$to\_point : [0,2^{256}-1] \to \mathbf{G}$
    CryptoNote - $$$H_p$ :
    $$$H_p(x) = to\_point( H(x) )$

3. CryptoNote

Erinnern Sie sich daran, wie das Geld gesendet und der Saldo in der Originalversion des Protokolls berechnet wird.

Alice, die Geld an Bob sendet, bildet die Ergebnisse ihrer Transaktion wie folgt (Abb. 3.1).

1. Bob hat ein Paar private Schlüssel $$$(v, s)$. Es berechnet seine Adresse als ein Paar übereinstimmender öffentlicher Schlüssel$$$(V, S)$ und veröffentlicht es oder sendet es an Alice.
2. Alice wählt einen zufälligen geheimen Transaktionsschlüssel $$$r$ und berechnet den öffentlichen Schlüssel $$$R = r G$das schreibt in das spezielle Feld zusätzliche Transaktionen.
3. Für jede Ausgabe berechnet Alice die Stealth-Adresse (einmaliger Zielschlüssel):
   $$$P_i = H_s(rV, i)G + S$wo $$$i$ - Seriennummer des Ausgangs.
4. Alice unterschreibt und sendet die Transaktion.

Beobachter von Drittanbietern, der Stealth-Adressen analysiert $$$P_i$kann nicht sagen, ob eine bestimmte Ausgabe für Bob bestimmt ist, und kann nicht einmal feststellen, ob unterschiedliche Ausgaben mit Schlüsseln vorgesehen sind $$$P_i$ und $$$P_j$an einen Empfänger.

Um das Geld anzunehmen, analysiert Bob alle Transaktionen in der Blockchain wie folgt (Abb. 3.2).
5. Verwenden Sie Ihren privaten Schlüssel $$$v$Bob berechnet für jede Ausgabe $$$P’_i = H_s(vR, i)G + S$ (Wo $$$i$ - Seriennummer des Ausgangs, $$$S$- Bobs öffentlicher Ausgabenschlüssel).
Wenn$$$P’_i = P_i$Dies bedeutet dann, dass er der Empfänger dieser Ausgabe ist und diese ausgeben kann, indem er den entsprechenden geheimen Schlüssel berechnet. Daher erhöht Bob das Guthaben seiner Brieftasche um den Wert dieser Ausgabe.

Um die Ausgabe auszugeben, ist Bob der Empfänger von und sendet Carol-Münzen. Er verhält sich wie folgt.

6. Bob benutzt seine geheimen Schlüssel $$$(v, s)$berechnet den privaten Schlüssel $$$x_i = H_s(vR, i) + s$ zur Stealth-Adresse $$$P_i$d.h. so, dass $$$P_i = x_i G$.

7. Bob berechnet das Schlüsselbild:$$$I = x_i H_p(P_i)$und schreibt es, den Nennwert und einen Link zur entsprechenden Ausgabe in die Eingabe seiner Transaktion für Carol.
Es ist zu beachten, dass erstens nur der Besitzer des geheimen Ausgabenschlüssels das Schlüsselbild berechnen kann$$$s$ (Die Richtigkeit wird durch eine Ringsignatur bestätigt), und zweitens kann ein Dritter das Schlüsselbild nicht binden $$$I$ und entsprechende Stealth-Adresse $$$P_i$.

8. Bob reduziert das Guthaben seiner Brieftasche um den Nennwert der in Absatz 6 verwendeten Ausgabe.

9. Bob bildet die Ausgaben in der Transaktion für Carol gemäß den Absätzen. 2-3. Dann unterschreibt die Transaktion und sendet.

Angenommen, Bob hat die gesamte Geschichte seiner Operationen verloren, besitzt aber immer noch seine geheimen Schlüssel$$$(v, s)$Anschließend kann er den Transaktionsverlauf wiederherstellen und seinen aktuellen Kontostand wie folgt berechnen (Abb. 3.4).

10. Bob scannt die gesamte Blockchain und analysiert alle Transaktionen auf das Vorhandensein von an ihn gerichteten Ausgaben (siehe Absatz 5).

11. Wenn Sie einen solchen Ausgang finden$$$P_i$Bob erhöht das Gleichgewicht seiner Brieftasche um den Wert des Nennwerts.
Verwenden Sie dann Ihren geheimen Ausgabenschlüssel$$$s$ berechnet den entsprechenden geheimen Exit-Schlüssel $$$x_i$ (S. 6) und Schlüsselbild $$$I$(Absatz 7). Dann schreibt Schlüsselbild,$$$P_i$und andere Zahlungsdaten in einer Tabelle.

12. Wenn Bob beim weiteren Scannen der Blockchain in der Eingabe einer Transaktion das Schlüsselbild in der Tabelle findet, bedeutet dies, dass diese Transaktion einmal von Bob gebildet wurde. Daher reduziert er das Guthaben seiner Brieftasche um den Wert des Einstiegswertes.

Auf diese Weise stellt Bob das aktuelle Gleichgewicht seiner Brieftasche wieder her.

Bitte beachten Sie, dass Dan, wenn er einen externen Prüfer erhält, einen geheimen Schlüssel von Bob erhält$$$v$Dann kann er Bobs eingehende Transaktionen in der Blockchain jedoch ohne geheimen Schlüssel erkennen $$$s$Er kann die ausgehenden Transaktionen von Bob nicht erkennen, was bedeutet, dass er auch den korrekten Saldo berechnet. Wie später gezeigt wird, kann Den bei direkten Ausgaben des Exits durch Bob ohne Mischen eine solche Transaktion als Bobs ausgehende Übertragung identifizieren, aber im allgemeinen Fall kann dies nicht durchgeführt werden.

Damit das Gleichgewicht der Bobs Brieftasche zu berechnen, müssen Sie die beiden geheimen Schlüssel kennen$$$(v, s)$.

Wenn Bob Auditor Dan seine beiden privaten Schlüssel gibt$$$(v, s)$Dies wird gleichbedeutend sein mit der Überweisung der Gelder selbst, da Den besitzt $$$s$wird in der Lage sein, sie auszugeben. Daher ist eine vollständige Prüfung der Brieftaschen nach dem ursprünglichen CryptoNote-Protokoll nicht möglich.

In den folgenden Abschnitten werden Optionen zum Ändern des Protokolls mit dieser Funktion betrachtet.

Beachten Sie, dass der geheime Schlüssel der Transaktion$$$r$Es ist sinnvoll, Alice zu speichern (was bei einigen Implementierungen des Protokolls der Fall ist). Wer weiß$$$r$ kann für einige Transaktionen prüfen, ob die Ausgabe relevant ist $$$i$ diese Transaktion an die angegebene Adresse $$$(V, S)$Wiederholen Sie einfach die Berechnungen aus Abschnitt 3:

$$$P’_i = H_s(rV, i)G + S$

und Vergleichen des Ergebnisses mit $$$P_i$.

Alice kann diese Tatsache zum Beispiel nutzen, um zu beweisen, dass sie das Geld an Bob überwiesen hat.

Zieladresse berechnen$$$(V, S)$ beim Verlassen, sogar wissend $$$r$Es ist unmöglich.

4. Option 1/3. Bytecoin überprüfbare Münzen

Zum Zeitpunkt seines Erscheinens war Bytecoin die erste und einzige Implementierung des CryptoNote-Protokolls, daher war es durch alle im vorherigen Abschnitt beschriebenen Funktionen und Einschränkungen gekennzeichnet.

Am 7. Februar 2019 veröffentlichten Entwickler ([ 20 ]) Version 3.4.0 von Amethyst, die eine Reihe von Verbesserungen und Änderungen an CryptoNote enthält, die wir nun betrachten werden. Die meisten Informationen in diesem Abschnitt wurden durch Analyse des Quellcodes von Bytecoin erhalten, da keine offizielle Dokumentation bereitgestellt wurde.

Im Rahmen dieses Artikels war die interessanteste Änderung die Möglichkeit für normale Brieftaschen, spezielle Kopien zu erstellen - Auditable Wallet (AW), die zwei Eigenschaften haben:

1. AW kann kein Geld aus der Hauptbrieftasche ausgeben.
2. Die AW-Balance stimmt immer mit der Balance der Hauptbrieftasche überein. Es ist nicht möglich, das Gleichgewicht der Hauptbrieftasche so zu ändern, dass das Gleichgewicht von AW nicht beeinträchtigt wird.

Nur die Brieftaschenadressen neuer Versionen, die sogenannten Amethystadressen, verfügen jedoch über eine solche Funktionalität. Die Abwärtskompatibilität wird mit vorhandenen Adressen und Konten bereitgestellt, die jetzt als Legacy-Adressen bezeichnet werden. Die Implementierung der neuen Funktionalität wurde nur bei Transaktionen der neuen Version möglich, da die Entwickler das Format der Ausgaben geändert haben. Daher verteilen Bytecoin-Netzwerke derzeit sowohl Transaktionen im alten als auch im neuen Format. Transaktionen des neuen Formats unterstützen auch zwei Arten von Adressen: Amethyst und Legacy. Letztendlich haben wir also drei Optionen für kryptografische Schemata:

1. tx.version <Amethyst, Legacy-Adresse;
2. tx.version ≥ Amethyst, Legacy-Adresse;
3. tx.version ≥ Amethyst, Amethystadresse.

Betrachten wir sie genauer.

4.1. tx.version <Amethyst, Legacy-Adresse

Dies ist das ursprüngliche CryptoNote-Schema, jedoch mit deterministischer Generierung. $$$r$.

Brieftaschenkonto durch geheimen Schlüssel dargestellt.$$$s$ und Hash $$$v_s$. Geheimer Ansichtsschlüssel$$$v$ deterministisch erzeugt als Funktion von $$$v_s$.

Der geheime Schlüssel$$$r$ Transaktionen werden jetzt nicht zufällig ausgewählt, sondern mit berechnet $$$v_s$::

$$$r = H_s(h_t, v_s)$wo $$$h_t = H(tx.inputs, tx.version)$

Dadurch sind keine privaten Schlüssel mehr erforderlich. $$$r$ im lokalen Speicher für zukünftige Anforderungen, da für jede Transaktion, die jemals an die Blockchain gesendet wurde, ein solcher Schlüssel mit berechnet werden kann $$$v_s$.

Der Brieftaschenbestand wird ähnlich wie in der ursprünglichen CryptoNote (siehe Abschnitt 3) berechnet, dh es ist ein geheimer Ausgabenschlüssel erforderlich, um ausgehende Zahlungen zu berücksichtigen$$$s$.

Wenn alle Adressen, die jemals in die Brieftasche übertragen wurden, in der lokalen Brieftasche gespeichert sind , ist es möglich, den korrekten Kontostand ohne geheimen Ausgabenschlüssel zu berechnen$$$s$ auf die folgende Weise:

1. Alice scannt Transaktionen in der Blockchain und verfolgt eingehende Zahlungen mithilfe eines geheimen Ansichtsschlüssels $$$v$, wie in Abschnitt 3 beschrieben, und erhöht das Gleichgewicht.
2. Außerdem geht Alice für jede Ausgabe jeder Transaktion alle Adressen durch $$$(V, S)$ zu denen jemals Überweisungen getätigt wurden und berechnet werden:
   $$$P’_i = H_s(rV, i)G + S$
   Wenn $$$P’_i = P_i$, dann ist diese Ausgabe Alices ausgehende Zahlung an die Adresse $$$(V, S)$ und es reduziert das Gleichgewicht.

Also berechnet Alice den Saldo nur mit $$$v_s$ und $$$v$.

Offensichtlich ist dieses Verfahren unzuverlässig und unpraktisch, da das Fehlen der Adresse, an die die Übertragung tatsächlich durchgeführt wurde, in der angegebenen lokalen Speicherung zu einer Überschätzung des Gleichgewichts führt. Daher ist es eher von theoretischem Interesse.

4.2. tx.version ≥ Amethyst

Wie oben erwähnt, hat Bytecoin seit Version 3.4.0 von Amethyst das Format von Transaktionen geändert. Wenn tx.version ≥ amethyst ist, haben die Transaktionsausgaben ein anderes Format.

Jetzt enthält jede Ausgabe zusätzlich zu der Menge und dem öffentlichen Schlüssel P _i auch einen zusätzlichen öffentlichen Schlüssel Q _i (im Code als angegeben encrypted_secret) und ein zusätzliches Byte, das den verschlüsselten Adresstyp, Amethyst oder Legacy enthält (auf den im Code Bezug genommen wird) encrypted_address_type). 4.2.

Somit erhöhte sich die Größe jeder Ausgabe um 33 Bytes.

Für jeden Ausgang i wird der Adresstyp wie folgt codiert und decodiert: wobei:

encrypted_address_type(i) = (H(oi) & 255) xor address_tag



$$$o_i = H(h_t, v_s, i)$(im Code als angegeben output_seed),

address_tag ist 0 für Legacy-Adressen und 1 für Ametyst-Adressen.

4.3. tx.version ≥ Amethyst, Legacy-Adresse

Das Brieftaschenkonto wird auch durch einen geheimen Schlüssel dargestellt. $$$s$ und Hash $$$v_s$auf deren Grundlage ein geheimer Ansichtsschlüssel deterministisch generiert wird $$$v$.

Alice schickte Geld an Bob an seine Adresse$$$(V, S)$bildet die Ausgaben seiner Transaktion wie folgt:

  1. Berechnet$$$h_t = H(tx.inputs, tx.version)$, dann für jeden Ausgang $$$i$:
  2.$$$D_i = H_s(h_t, v_s, i)G$(im Code als angegeben output_shared_secret)
  3.$$$P_i = S + H_s(D_i, h_t, i)G$
  4. $$$Q_i = H_s(h_t, v_s, i)V$ (dabei $$$Q_i = v D_i$jedoch Ansichtsschlüssel $$$v$Empfänger unbekannt)
  5. Paar$$$(P_i, Q_i)$ - öffentliche Ausgangsschlüssel $$$i$.

Um das Geld anzunehmen, analysiert Bob alle Transaktionen wie folgt.

  6. Berechnet für jede Transaktion$$$h_t = H(tx.inputs, tx.version)$, dann für jeden Ausgang $$$i$:
  7.$$$D_i = v^{-1} Q_i$
  8. $$$S’ = P_i — H_s(D_i, h_t, i) G$
  9. Wenn $$$S’$ entspricht dem öffentlichen Schlüssel $$$S$Bob, dann ist dieser Ausgang für ihn bestimmt und er erhöht das Gleichgewicht seiner Brieftasche um den entsprechenden Nennwert.

Um die Ausgabe auszugeben, ist Bob der Empfänger von und sendet Carol-Münzen. Er verhält sich wie folgt.

  10. Verwenden Sie Ihre geheimen Schlüssel$$$v$ und $$$s$berechnet den geheimen Teil $$$P_i$::
    $$$D_i = v^{-1} Q_i$
    $$$x_i = s + H_s(D_i, h_t, i)$ist das leicht zu sehen $$$P_i = x_i G$(siehe Absatz 3).
  11. Bob berechnet das Schlüsselbild:$$$I = x_i H_p(P_i)$und schreibt es, den Nennwert und einen Link zur entsprechenden Ausgabe in die Eingabe seiner Transaktion für Carol.
  12. Bob reduziert das Guthaben seiner Brieftasche um den Wert der verwendeten Ausgabe.
  13. Bob bildet die Ausgaben in der Transaktion für Carol gemäß 1-5. Dann unterschreibt die Transaktion und sendet.

Ein Merkmal dieses Schemas ist im Gegensatz zu CryptoNote, dass jeder, an den Alice ihren geheimen Hash überträgt$$$v_s$kann die Empfängeradresse berechnen $$$(V, S)$für jede Alice-Transaktion:

  14.$$$D_i = H_s(h_t, v_s, i) G$
  fünfzehn. $$$S = P_i — H_s(D_i, h_t, i) G$
  Sechszehn. $$$V = H_s(h_t, v_s, i)^{-1} Q_i$

Das Problem in diesem Fall ist jedoch die Aufgabe zu bestimmen, welche Transaktionen Alice generiert und gesendet hat. Ohne diese Informationen in p.p. 14-16 für beliebige Transaktionen werden beliebige nutzlose Daten erhalten, die von realen Adressen nicht zu unterscheiden sind$$$(V, S)$. Der Codierungsalgorithmus kann dabei hilfreich sein encrypted_address_type, da dieses Feld nach der Decodierung für Alice-Transaktionen nur gültige Werte enthält$$$\{0, 1\}$. Leider können akzeptable Werte auch willkürlich erhalten werden, und ein solcher Fall kann nicht unterschieden werden.

Da in diesem Schema die Berechnung des Schlüsselbildes auch die Kenntnis des geheimen Ausgabenschlüssels erfordert$$$s$Dann bleibt das Prüfungsproblem, dh die Berechnung des genauen Saldos der Brieftasche ohne Übertragung der Rechte zum Ausgeben von Geld, ungelöst.

4.4. tx.version ≥ Amethyst, Amethystadresse

Konstante h

Die Operation dieses kryptografischen Schemas erfordert die Einführung einer neuen Konstante - des Punktes $$$H$Gruppenelement $$$\mathbf{G}$und die Reihenfolge des Punktes $$$H$Unbekannt. Mit anderen Worten, dies ist ein fester öffentlicher Schlüssel, dessen geheimer Teil garantiert unbekannt ist und dessen Wahrscheinlichkeit vernachlässigbar ist:

$$$H = yG$wo $$$y$Ist eine unbekannte Nummer.

Zum Beispiel können Sie einstellen$$$H$wie in [ 8 ] vorgeschlagen:

$$$H = H_p(G) = to\_point( cn\_fast\_hash(G) )$

Bytecoin-Entwickler berechnen die Konstante nicht, sondern setzen sie numerisch, ohne die Art ihres Ursprungs anzugeben :

bytecoin / src / crypto / crypto_helpers.hpp, Zeile 67

constexpr P3 H{ge_p3{{7329926, -15101362, 31411471, 7614783, 27996851, -3197071, -11157635, -6878293, 466949, -7986503},    {5858699, 5096796, 21321203, -7536921, -5553480, -11439507, -5627669, 15045946, 19977121, 5275251},    {1, 0, 0, 0, 0, 0, 0, 0, 0, 0},    {23443568, -5110398, -8776029, -4345135, 6889568, -14710814, 7474843, 3279062, 14550766, -7453428}}};

Eine Suche nach dieser numerischen Sequenz ergab jedoch ([ 9 ]), dass sie dieselbe Konstante wie in Monero für RingCT verwenden, deren Berechnungsmethode und deren Rechtfertigung in [ 8 ] berücksichtigt wurden .

Weil der$$$H$ gehört zur Gruppe $$$\mathbf{G}$, dann können wir das sagen $$$H$ bringt auch eine Gruppe hervor $$$\mathbf{G}$als Basispunkt $$$G$.

Es bedeutet das$$$\forall x \in [1,p-1], xH \in \mathbf{G}$

Mehrere nicht verknüpfbare Adressen

In der ursprünglichen CryptoNote wurde jeder Brieftasche (dh einem Satz geheimer Schlüssel) eine öffentliche Adresse zugeordnet, über die Geld überwiesen wurde.

Das betrachtete Schema ermöglicht das Generieren einer unbegrenzten Anzahl öffentlicher Adressen auf demselben Satz geheimer Schlüssel. Dabei:

1. Adressen werden deterministisch aus dem anfänglichen Satz von Geheimnissen erzeugt;
2. Diese Adressen können nicht miteinander verbunden werden, d.h. Ein externer Beobachter kann nicht berechnen, dass er zum selben Konto gehört.
3. Überprüfung eingehender Transaktionen und Abrechnung $$$N$ Mehrere Adressen sind rechnerisch einfacher als das Überprüfen $$$N$ Konten im üblichen Schema.

Brieftaschenkonto durch geheimen Schlüssel dargestellt. $$$s$ und Hash $$$v_s$sowie im vorherigen Schema. Basierend auf dem Hash$$$v_s$ Jetzt wird nicht nur ein geheimer Ansichtsschlüssel deterministisch generiert $$$v$, aber auch einen zusätzlichen geheimen Prüfschlüssel $$$a$.

Das Erzeugen der i-ten Adresse erfolgt wie folgt (Abb. 4.4.2).
  1. Berechnet $$$\delta = H_s(A + sH, i)$ und $$$\Delta = \delta G$
  2. $$$S = A + sH + Δ$
  3. $$$V = vS = v(A + sH + Δ) = v(A + sH) + δV$
  4. Paar $$$(V, S) = (v S, S)$ ist ein $$$i$Die öffentliche Adresse dieses Kontos.

Beachten Sie, dass es für die Berechnung ausreicht, die folgenden Werte zu kennen:
  •$$$A$
  • • $$$V$
  • • $$$s H$
  • • $$$v (A + s H)$

Mengen $$$s H$ und $$$v (A + s H)$ werden beim Erstellen eines Kontos berechnet und gelten als sicher in dem Sinne, dass Sie nicht rechnen können, wenn Sie sie kennen $$$s$ oder $$$v$.

Generierte Adressen werden lokal in einem für die Feldsuche optimierten Container gespeichert.$$$S$.

Bildung von Exits beim Senden von Geldern

Alice schickte Geld an Bob an seine Adresse $$$(V, S)$ bildet die Ausgaben seiner Transaktion wie folgt (Abb. 4.4.3).
  1. Berechnet $$$h_t = H(tx.inputs, tx.version)$, dann für jeden Ausgang $$$i$:
  2.$$$P_i = H_s( H_p(h_t, v_s, i), h_t, i )^{-1} S$
  3. $$$Q_i = H_s( H_p(h_t, v_s, i), h_t, i )^{-1} V + H_p(h_t, v_s, i)$
  4. Paar $$$(P_i, Q_i)$ - öffentliche Ausgangsschlüssel $$$i$.

Buchhaltung für eingehende Zahlungen

Um das Geld anzunehmen, analysiert Bob alle Transaktionen wie folgt (Abb. 4.4.4.).

1. Für jeden Ausgang $$$i$Verwenden eines geheimen Ansichtsschlüssels $$$v$Bob berechnet:$$$K = H_p(h_t, v_s, i) = Q_i — v P_i$( output_shared_secretim Code)
2. $$$S’ = H_s(K, h_t, i) P_i$
3. Danach versucht er zu finden $$$S’$in Ihrer Adressliste. Wenn es findet, bedeutet dies, dass dieser Ausgang Geld an Bob überweist. Es erhöht das Guthaben für die entsprechende Adresse.

Dies bedeutet, dass Sie in diesem Schema zusätzlich zur Liste der Adressen oder Schlüssel zum Generieren des Schlüssels den geheimen Ansichtsschlüssel kennen müssen, um eingehende Zahlungen korrekt zu berücksichtigen $$$v$.

Bildung ausgehender Zahlungen

Einen Ausweg verbringen $$$i$Welcher Bob der Empfänger ist und die Münzen an Carol sendet, verhält er sich wie folgt.

1. $$$K = H_p(h_t, v_s, i) = Q_i — v P_i$( output_shared_secretim Code)
2. $$$x_i = H_s(K, h_t, i)^{-1} (a + \delta)$
3. $$$X_i = x_i G + H_s(K, h_t, i)^{-1} s H$
4. Berechnet das Schlüsselbild $$$I = x_i * H_p(X_i)$
5. Bob reduziert das Guthaben in Bezug auf seine Adresse $$$S = H_s(K, h_t, i) P_i$ um den Nennwert des entsprechenden Ausgangs.
6. Bob generiert Transaktionsausgaben, signiert sie und sendet sie.

Es ist ersichtlich, dass zur Berechnung des Schlüsselbildes nicht nur die Kenntnis des geheimen Ansichtsschlüssels erforderlich ist $$$v$, aber auch $$$a$.

Ein wichtiges Merkmal dieses Schemas ist die Fähigkeit, ein Schlüsselbild zu berechnen (und daher seine ausgehenden Zahlungen, also die Saldoberechnung, zu berücksichtigen), ohne einen geheimen Ausgabenschlüssel zu verwenden$$$s$.

Offenlegung der Adresse des Prüfempfängers

Wie beim vorherigen können Sie mit diesem kryptografischen Schema Empfängeradressen aus Transaktionsausgaben extrahieren, wenn der geheime Hash des Absenders bekannt ist $$$v_s$.

Dies geschieht wie folgt (Abb. 4.4.5).
Angenommen, Alice hat bestanden $$$v_s$ und $$$s H$Carol. Dann Carol:

1. Geheime Schlüssel wiederherstellen $$$v$ und $$$a$, wird Alices Adressliste wiederherstellen.
2. Scannt die Blockchain für jede Ausgabe. $$$i$ Bei jeder Transaktion wird festgestellt, ob es sich um eine eingehende Zahlung handelt
   $$$S’ = H_s(Q_i — v P_i, h_t, i) P_i$
   unter den Adressen von Alice.
3. Wenn es findet, erhöht Carol das Guthaben der entsprechenden Adresse und mit $$$a$ und $$$v$, berechnet das Schlüsselbild (siehe oben) und speichert es lokal.
4. Wenn das Schlüsselbild von Alice unter den Transaktionseingaben gefunden wird, bedeutet dies, dass es sich bei dieser Transaktion um die ausgehende Zahlung von Alice handelt. Carol stellt die Empfängeradressen für alle Ausgaben dieser Transaktion wieder her:
   $$$S = P_i H_s(H_p(h_t, v_s, i), h_t, i)$
   $$$V = (Q_i — H_p(h_t, v_s, i)) H_s(H_p(h_t, v_s, i), h_t, i)$
   und reduzieren Sie den Saldo der entsprechenden Alice-Adresse um den Wert des Eingabewerts.

Wenn Sie einen Teil der Kontodaten preisgeben, können Sie Dritten unterschiedliche Zugriffsebenen auf Informationen gewähren.

So erstellen Sie eine Liste Ihrer Adressen:
  •$$$A$
  • • $$$V$
  • • $$$s H$
  • • $$$v (A + s H)$

So erfassen Sie nur eingehende Zahlungen:
  •$$$A$
  • • $$$v$
  • • $$$s H$

Zu prüfen, d.h. Berechnen Sie den Kontostand an Ihren Adressen, ohne die Adressen der Empfänger preiszugeben:
  •$$$a$
  • • $$$v$
  • • $$$s H$

Zu prüfen, d.h. Berechnen Sie den Kontostand an Ihren Adressen und geben Sie die Adressen der Empfänger an:
  •$$$v_s$
  • • $$$s H$

4.5. Vergleichen von CryptoNote- und Bytecoin-Amethyst-Transaktionssignaturen

Datenstrukturen und Signaturgrößen

Wie oben erwähnt, mussten Bytecoin Amethyst-Entwickler für die Implementierung der Möglichkeit, Brieftaschen zu prüfen, ohne einen geheimen Ausgabenschlüssel preiszugeben, die Größe der in jeder Transaktionsausgabe übertragenen Daten erhöhen: Im Vergleich zum ursprünglichen Protokoll werden ein öffentlicher Schlüssel und 1 Byte übertragen, um den Adresstyp zu identifizieren. Insgesamt 33 Bytes pro Ausgabe.

In CryptoNote wird jede Transaktion für eine Transaktion separat signiert. Für jeden öffentlichen Schlüssel$$$P_i$ Von einigen Ausgaben, auf die sich diese Eingabe bezieht, wird ein Skalarpaar in die Signatur geschrieben $$$(r,c)$Gesamtgröße von 64 Bytes. (Ein Eintrag kann sich auf mehrere Exits beziehen, von denen nur einer echt ist, und der Rest dient dazu, die Übertragung zu anonymisieren.)

Wenn also die Transaktion$$$N_{inputs}$ Eingänge, auf die sich jeder bezieht $$$N_{mixins}$ Ausgaben kann die Gesamtgröße der Signatur in Bytes ausgedrückt werden als:

$$$S = 32 * 2 * N_{mixins} * N_{inputs}$

Die minimale Signaturgröße für eine Transaktion beträgt 64 Byte (eine Eingabe, die eine Ausgabe direkt ausgibt).

In Bytecoin Amethyst wird die gesamte Transaktion signiert und die entsprechende Datenstruktur ist kompliziert (Abb. 4.5.1).
Für jede Transaktionseingabe eine Periode, zwei Skalare und eine andere $$$N_{mixins}$Skalare. Eine weitere Signatur wird ebenfalls zur gesamten Signatur hinzugefügt. Insgesamt kann die Gesamtgröße der Signatur in Bytes wie folgt ausgedrückt werden:

$$$S = 32 * ((3 + N_{mixins}) * N_{inputs} + 1)$

Die minimale Signaturgröße für eine Transaktion beträgt 160 Byte (eine Eingabe, die eine Ausgabe direkt ausgibt).

Es ist ersichtlich, dass beide Funktionen proportional zum Produkt wachsen$$$N_{mixins} * N_{inputs}$

Um den Unterschied in den Transaktionssignaturgrößen deutlicher zu vergleichen, berechnen wir sie für die charakteristischsten Werte $$$N_{mixins}$ und $$$N_{inputs}$ und machen Sie eine Tabelle (Abb. 4.5.2).
Wie Sie leicht sehen können, gibt es in einer Situation, in der es keine Vermischung der Ergebnisse gibt und eine direkte Verschwendung von Geldern ($$$N_{mixins} = 1$) oder wenn ein Ausgang gemischt wird ($$$N_{mixins} = 2$) Ist die Signaturgröße von Bytecoin bis zu 150% größer als die von CryptoNote.

Beim Mischen von zwei Ausgängen ($$$N_{mixins} = 3$) Die Größe der Signaturen in dem einen und dem anderen Schema stimmt praktisch überein.

Mit einer weiteren Erhöhung der Anzahl gemischter Ausgaben ist die Größe der Bytecoin-Signatur kleiner.

Es ist erwähnenswert, dass Bytecoin-Entwickler mit der Veröffentlichung von Version 3.4.0 Amethyst zur Erhöhung der Anonymität die Mindestanzahl gemischter Ausgaben auf 3 festgelegt haben [ 10 ]. Unter solchen Umständen ist die Bytecoin-Signatur kleiner.

Die Komplexität der Signaturüberprüfung

Neben der Größe der Ringsignatur, die sich direkt auf die Größe der Blockchain auswirkt, ist ein weiteres wichtiges Merkmal die rechnerische Komplexität ihrer Verifizierung. Es bestimmt so wichtige Parameter des Kryptowährungssystems wie beispielsweise die Geschwindigkeit der Synchronisation mit dem Netzwerk neuer Knoten und die Rechenlast des Netzwerks mit einem großen Transaktionsfluss.

Die Komplexität der Signaturüberprüfung für CryptoNote und Bytecoin kann praktisch einfach verglichen werden, indem einfach ein Test geschrieben wird, der eine große Anzahl von Signaturen mit den angegebenen generiert und anschließend überprüft$$$N_{mixins}$ und $$$N_{inputs}$Da wir jedoch später in diesem Artikel die Schemata betrachten werden, die noch nicht in der Praxis implementiert wurden, sondern nur theoretisch vorgeschlagen werden, ist es logisch, diese Schemata anhand der Anzahl der verwendeten kryptografischen Operationen mühsam zu bewerten und empirisch zu bewerten.

CryptoNote und Bytecoin verwenden mehrere grundlegende Grundelemente (siehe Abschnitt 2). In der Tabelle in Abb. 4.5.3. Die typische Laufzeit der am häufigsten verwendeten Grundelemente wird auf einem modernen Middle-End-Computer mit einem Core i5-6500-Prozessor angegeben (zum Vergleich wurde der in Microsoft Visual Studio 2017 kompilierte ursprüngliche Quellcode mit allen möglichen Geschwindigkeitsoptimierungen verwendet).
Die Ergebnisse der Tests in Bytecoin und CryptoNote stimmen gut überein. Es ist leicht zu erkennen, dass der größte Beitrag durch die Multiplikation des Skalars mit einem Punkt und in geringerem Maße durch das Verfahren zur Berechnung des Hashs geleistet wird$$$H_p$, während die Operationen des Hinzufügens von zwei Punkten und des Berechnens einer Hash-Funktion $$$H_s$wird die Komplexität nicht wesentlich beeinflussen.

Betrachten Sie das Verfahren zur Überprüfung der CryptoNote-Ringsignatur (Abb. 4.5.4, das Verfahren zur Signaturerstellung wurde in [ 1 ] ausführlich erläutert und wird hier nicht berücksichtigt).
Wie bereits erwähnt, wird in CryptoNote jede Transaktionseingabe separat signiert und jede Eingabe wird auch separat überprüft. Daher überprüft der Verifizierer für jede Transaktionseingabe die entsprechende Zeile (in der Abbildung) der Signatur wie folgt.

1. Für jedes Wertepaar $$$r_j$ und $$$c_j$ mit Schlüsselbildeingabe $$$I$ und öffentlicher Schlüssel $$$P_j$ Von der nächsten Ausgabe, auf die sich diese Eingabe bezieht, werden die Werte berechnet:$$$L_j = r_j G + c_j P_j$
   $$$R_j = r_j H_p(P_j) + c_j I$
   (In diesem Fall läuft der Index j von 0 bis $$$N_{mixins}$)
2. Der Betrag wird berechnet $$$c$ von allen $$$c_j$.
3. Der Hash wird berechnet $$$c`=H_s(tx\_prefix\_hash, L_0 ... L_n, R_0 ... R_n$)
   Wo tx_prefix_hashist der Hash des Präfixteils der Transaktion (ohne Signatur)?
4. Gleichheit geprüft $$$c` = c$. Wenn dies der Fall ist, wird die Ringsignatur als gültig angesehen.

Lassen Sie uns die Anzahl der skalaren Multiplikationsoperationen durch Punkt- und Hash-Berechnungen schätzen $$$H_p$.

Jede Berechnung$$$L_j$ und $$$R_j$erfordert zwei skalare Multiplikationen. Anzahl der Paare$$$L_j, R_j$ entspricht der Anzahl der zu mischenden Ausgänge $$$N_{mixins}$für jeden Eintrag. Deshalb haben wir:

$$$O(*) = N_{inputs} * 4 * N_{mixins}$

In diesem Fall die Hash-Funktion $$$H_p$ einmal pro Berechnung verwendet $$$R_j$daher:

$$$O(H_p) = N_{inputs} * N_{mixins}$

Betrachten Sie nun den Algorithmus zur Überprüfung der Ringsignatur in Bytecoin Amethyst (Abb. 4.5.5).
Die gesamte Signatur wird vollständig auf alle Eingaben gleichzeitig überprüft. Es passiert so:

1. Der Präfix-Hash der Transaktion wird (ohne Signatur) in den Hash-Puffer geschrieben.
2. Für jeden Eintrag $$$i$ (Unterschriftenzeile in der Abbildung):
3. Berechnet $$$H_s$ gemäß allen Daten des Hash-Puffers wird das Ergebnis mit dem Wert verglichen $$$c_0$Eine Unterschrift gilt als gültig, wenn die Gleichheit eingehalten wird.

Lassen Sie uns die Anzahl der skalaren Multiplikationsoperationen durch Punkt- und Hash-Berechnungen schätzen $$$H_p$.

Jede Berechnung$$$Y_j$ und $$$Z_j$ erfordert zwei skalare Multiplikationen plus Berechnung $$$X$erfordert drei skalare Multiplikationen. Anzahl der Paare$$$Y_j, Z_j$ entspricht der Anzahl der zu mischenden Ausgänge $$$N_{mixins}$für jeden Eintrag. Deshalb haben wir:

$$$O(*) = N_{inputs} * (3 + 4 * N_{mixins})$

In diesem Fall die Hash-Funktion $$$H_p$ einmal pro Berechnung verwendet $$$Z_j$ und einmal zur Berechnung $$$B$ für jeden der Eingänge daher:

$$$O(H_p) = N_{inputs} * (N_{mixins} + 1)$

Um die rechnerische Komplexität beider Algorithmen anhand von Standarddaten visuell zu vergleichen, führen wir die folgende Metrik ein. Addieren Sie die Anzahl der skalaren Multiplikations- und Berechnungsoperationen$$$H_p$ mit Gewichten proportional zur charakteristischen Zeit, die benötigt wird, um diese Operationen abzuschließen:

$$$O(total) = 130 * O(*) + 15 * O(H_p)$

Vergleichen Sie dann die relativen Ergebnisse für CryptoNote und Bytecoin in Prozent (Abb. 4.5.6).
Wie Sie sehen können, ist die Überprüfung der Bytecoin-Signatur viel zeitaufwändiger.

Wie oben erwähnt, wurde in Bytecoin aus Version 3.4.0 Amethyst zur Erhöhung der Anonymität die Mindestanzahl gemischter Ausgaben auf 3 [ 10 ] festgelegt, sodass der schlechteste praktische Wert 25% (theoretisch) nicht überschreitet.

Zusammenfassen:

1. Die Größe jeder Ausgabe wird durch den öffentlichen Schlüssel erhöht $$$Q$ - 32 Bytes.
2. Die Größe der Ringsignatur variiert im Vergleich zur Größe der CryptoNote-Signatur in Abhängigkeit von der Anzahl der gemischten Ausgänge (bei einer großen Anzahl stellt sich heraus, dass sie geringer ist):
   $$$S = 32 * ((3 + N_{mixins}) * N_{inputs} + 1)$
3. Die Komplexität der Berechnungen ist höher als in CryptoNote und hängt erheblich von der Anzahl der zu mischenden Ausgänge ab:
   $$$O(*) = N_{inputs} * (3 + 4 * N_{mixins})$
   $$$O(H_p) = N_{inputs} * (N_{mixins} + 1)$

5. Option 2/3. Audit Studies bei CryptoNote von Anton Sokolov

Im Herbst 2019 wurde auf Medium.com eine Reihe von Aufsätzen [ 11 , 12 , 13 , 14 , 15 , 18 ] zum Prüfungsproblem in CryptoNote und möglichen Lösungen für dieses Problem veröffentlicht, die von Anton Sokolov verfasst wurden . Es werden theoretisch mehrere Optionen zum Ändern des ursprünglichen Protokolls in Betracht gezogen, um die Prüfaufgabe für einen Dritten zu lösen.

Wir betrachten den letzten von ihnen [ 15 ] als den am besten optimierten. Wir werden es als "AS" abkürzen.

Hinweis: Aus Gründen der Konsistenz werden Ausgabenschlüssel weiterhin mit Buchstaben gekennzeichnet$$$s$ und $$$S$, Schlüssel in Buchstaben anzeigen $$$v$ und $$$V$, trotz der Tatsache, dass in den Originalwerken verwendet werden $$$b$, $$$B$ und $$$a$, $$$A$ beziehungsweise.

Ausgabebildung

Das Brieftaschenkonto wird durch einen Satz von drei geheimen Schlüsseln dargestellt, nicht durch zwei, wie in CryptoNote $$$\{v, s, d\}$: Ansichts-, Ausgaben- und Prüfschlüssel.

Eine Sammlung von drei öffentlichen Schlüsseln$$$\{V, S, D\}$repräsentiert die öffentliche Adresse dieses Kontos.

Alice sendet Geld an die Bohne und verhält sich wie folgt (Abb. 5.1).

1. Bob veröffentlicht seine Adresse, damit Alice seine öffentlichen Schlüssel kennt $$$V$, $$$S$ und $$$D$.
2. Wie CryptoNote wählt Alice einen zufälligen geheimen Transaktionsschlüssel aus $$$r$ und berechnet den öffentlichen Schlüssel $$$R = r G$das schreibt in das spezielle Feld zusätzliche Transaktionen.
3. Für jede Ausgabe berechnet Alice nicht eine, sondern zwei Stealth-Adressen $$$P$ und $$$T$. Die erste wird ähnlich wie CryptoNote berechnet:
   $$$P = H_s(r V) G + S$
   Der zweite ist anders:
   $$$T = H_s(r D) D$
   Die Seriennummer der Ausgabe wird in der Originalarbeit nicht verwendet. Es ist jedoch anzunehmen, dass dies zur Vereinfachung erfolgt und in der Praxis eines der Funktionsargumente ist $$$H_s$ ähnlich wie CryptoNote (siehe Abschnitt 3).
4. Alice unterschreibt und sendet die Transaktion.

Ein externer Beobachter kann nicht binden $$$P$ und $$$T$ mit Bobs Adresse.

Erfassung eingehender Zahlungen und Bildung von Inputs

Um Geld anzunehmen und auszugeben, verhält sich Bob wie folgt (Abb. 5.2).

1. Verwenden Sie Ihren privaten Ansichtsschlüssel $$$v$Bob Stealth-Adresse $$$P$ vergleicht jede Ausgabe mit einem Punkt:
   $$$P’ = H_s(vR)G+S$
   (Dieser Schritt ähnelt CryptoNote.)
2. Wenn die Gleichheit erfüllt ist, bedeutet dies, dass diese Ausgabe an Bob adressiert ist. Er erhöht sein Gleichgewicht um den Wert der Nennleistung.
3. Übertragen Sie gegebenenfalls die erhaltenen Gelder von Carol, Bob, mit ihren geheimen Ausgaben- und Prüfungsschlüsseln $$$s$ und $$$d$berechnet zwei Schlüsselbilder:$$$I$ und $$$\ddot I$. Das erste ähnelt CryptoNote:
   $$$I = x * H_p(P)$
   und optional:
   $$$t = H_s(dR)d$
   $$$\ddot I = t H_p(P)$
   Dann schreibt er sie, den Nennwert und einen Link zur entsprechenden Ausgabe in die Eingabe seiner Transaktion für Carol.
4. Dann bildet Bob die Transaktionsausgaben für Carol, reduziert sein Guthaben proportional zu den ausgegebenen Ausgaben, signiert die Transaktion und sendet.

Wie Sie hier wie in CryptoNote sehen können, besitzt der Dritte - der Auditor - nur einen geheimen Ansichtsschlüssel $$$v$kann nur eingehende Überweisungen erkennen.

Prüfung

Wenn der Prüfer auch einen geheimen Prüfschlüssel hat $$$d$Dann kann er Bobs ausgehende Zahlungen erkennen und seinen Saldo wie folgt berechnen:

1. Für jede eingehende Zahlung berechnet der Prüfer ein zusätzliches Schlüsselbild und merkt sich dieses $$$\ddot I$ im lokalen Speicher:
   $$$t = H_s(d R) d$
   $$$\ddot I = t H_p(P)$
   
2. Wenn in den Eingaben einer der Blockchain-Transaktionen ein zusätzliches Schlüsselbild $$$Ï$Wenn es mit einem der gespeicherten übereinstimmt, bedeutet dies, dass diese Transaktion Bobs ausgehende Zahlung ist. Der Prüfer reduziert den Saldo um den Nennwert des entsprechenden Eingangs.

Somit hat der Auditor einen Schlüsselsatz $$$\{v, S, d\}$wird in der Lage sein, Bobs eingehende und ausgehende Übertragungen in der Blockchain zu erkennen und sein korrektes Gleichgewicht wiederherzustellen. Gleichzeitig kann der Abschlussprüfer kein Geld ausgeben, weil ohne geheimen Ausgabenschlüssel$$$s$ Er kann das Hauptschlüsselbild nicht berechnen $$$I$.

Das Problem ist behoben.

Ringsignatur

Mit den Ideen aus [ 16 ] gelang es dem Autor, die Größe der Signatur im Vergleich zu CryptoNote zu reduzieren: Jetzt wird für jede Eingabe nur die Signatur gespeichert$$$N_{mixins} + 1$ Skalar (Abb. 5.3).
Somit wird die Signaturgröße fast halbiert.

Berücksichtigen Sie die rechnerische Komplexität der Überprüfung. Das Signaturüberprüfungsschema ist in Abb. 1 dargestellt. 5.4.
Dieser Algorithmus ist in seiner Struktur dem in CryptoNote verwendeten sehr ähnlich (siehe Abb. 4.5.4). Die Prüfung wird für jede Eingabe separat durchgeführt und besteht in der sequentiellen Berechnung der Werte$$$u_j$, $$$L_j$, $$$R_j$, $$$c_j$für alle Ausgänge, die zum Mischen in diesem Eingang verwendet werden. Infolgedessen ist der Zyklus von$$$c_j$ sollte schließen und den Wert $$$c_{n+1}$ muss passen $$$c_0$In diesem Fall gilt die Unterschrift als gültig.

Die rechnerische Komplexität des Algorithmus wird durch sechs skalare Multiplikationsoperationen und eine Berechnung der Hash-Funktion bestimmt$$$H_p$ zur Iteration die Nummer, die das Produkt ist $$$N_{inputs} * N_{mixins}$.

Vergleich mit CryptoNote nach Daten und Rechenlast

1. Die Größe der Adresse erhöht sich um 50%, weil Die Adresse repräsentiert jetzt eine Sammlung von drei öffentlichen Schlüsseln:$$$\{V, S, D\}$nicht zwei $$$\{V, S\}$.
   Die codierte Darstellung der Adresse erhöht sich um ungefähr das Gleiche: Beispielsweise benötigt eine Standard-Zano-Adresse mit zwei öffentlichen Schlüsseln 97 Zeichen:
   

   ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2nP4HxSPDpuLHvizpwj2q99bmz7t

   
   Eine ähnliche Zano-Adresse mit drei öffentlichen Schlüsseln hat eine Länge von ca. 141 Zeichen:
   

   ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2nP4HxSPDpuLHvizpwjcenhnGbhpJFLk8vkhJywHCcht4d9EKA7CHHav1H6QPpB1cLsTvPfj

2. Die Größe jeder Ausgabe wird um eine zusätzliche Stealth-Adresse erhöht $$$T$ - 32 Bytes.
3. Die Größe jeder Eingabe wird durch ein zusätzliches Schlüsselbild erhöht $$$\ddot I$ - 32 Bytes.
4. Die Größe der Ringsignatur ist kleiner als in CryptoNote:
   $$$S = 32 * (N_{mixins} + 1) N_{inputs}$
5. Die Komplexität der Berechnungen ist höher als in CryptoNote:
   $$$O(*) = N_{inputs} * 6 * N_{mixins}$
   $$$O(H_p) = N_{inputs} * N_{mixins}$

6. Option 3/3. Audit durch die Ausgangsmischgrenze

Überlegen Sie sich eine andere Möglichkeit, die Überwachung in CryptoNote zu implementieren.

Mix_attr-Ausgabeattribut

Im Zano-Projekt, dem Nachfolger von CryptoNote, verfügt die Transaktionsausgabe über ein zusätzliches 8-Bit-Attribut mix_attr und eine Kernelregel, die die Verwendung von Ausgaben beim Mischen abhängig von ihrem Wert einschränkt.

Die Struktur der Ausgänge von CryptoNote und Bytecoin (Abb. 4.2) können wir nun auf diese Weise ergänzen (Abb. 6.1.).
Die Kernel-Regel, die das Mischen gemäß mix_attr einschränkt, lautet:

1. mix_attr = 0, . . — -.
2. mix_attr = 1, , , .
3. mix_attr ≥ 2, , mix_attr.

Das Hauptmerkmal dieser Innovation ist Absatz 3, der es ermöglicht, die Unrückverfolgbarkeit (Unrückverfolgbarkeit von Bindungen) zu erhöhen, indem Situationen beseitigt werden, in denen der bereits beim Mischen verwendete Output direkt vom Eigentümer ausgegeben wird (dies wurde ausführlich in [ 19 ] beschrieben).

Im Zusammenhang mit diesem Artikel werden wir jedoch an Punkt 2 interessiert sein, dh an einer Situation, in der mix_attr = 1 und die auf diese Weise markierte Ausgabe nur direkt ausgegeben werden können. Diese Einschränkung ist in Abb. 2 dargestellt. 6.2.
Da Ausgabe 2 mix_attr = 1 hat, kann sie unabhängig von ihren Attributwerten mix_attr nicht mit anderen Ausgaben gemischt werden. Es kann nur direkt als Ausgabe # 0 ausgegeben werden.

Mit dieser Funktion können Sie ein Audit organisieren.

Audit mit mix_attr = 1

Wie in Abschnitt 3 erwähnt, erhält Auditor Dan nach dem ursprünglichen CryptoNote-Protokoll einen geheimen Schlüssel von Bob $$$v$Er kann eingehende Transaktionen erkennen, ausgehende Transaktionen jedoch nicht. Daher ist eine genaue Berechnung des Saldos nicht möglich.

Da Dan jedoch vollständige Informationen über Bobs nicht ausgegebene (UTXO) Exits hat, kann er die Tatsache verfolgen, dass sich eine Transaktion in seinen Eingaben auf Bobs UTXO bezieht. Wenn Sie das Mischen anderer Ausgaben verwenden, kann Den nicht feststellen, ob diese Transaktion die Ausgabe von Bob ausgibt, was durch die Verwendung einer Ringsignatur erreicht wird. Wenn jedoch keine Mischung erfolgt und Bobs UTXO direkt ausgegeben wird, kann der Prüfer Dan sicher sein, dass es sich bei dieser Transaktion um Bobs ausgehende Zahlung handelt. Dies ist die Idee dieses Schemas.

Angenommen, Alice sendet eine Transaktion an Bob und Bob möchte, dass Auditor Dan sieht, dass Alice das Geld erhalten hat und dass sie es ausgegeben haben, als Bob beschlossen hat, es auszugeben.

Das Arbeitsschema sieht wie folgt aus (Abb. 6.3).

1. Bob erzählt Alice seine öffentliche Adresse $$$(V, S)$und fordert sie außerdem auf, das Attribut mix_attr in allen an ihn gerichteten Ausgaben auf 1 zu setzen (siehe unten, wie dies technisch implementiert werden kann).
2. Bob gibt Auditor Dan seinen geheimen Ansichtsschlüssel $$$v$.
3. Alice sendet Bob eine Transaktion mit dem üblichen CryptoNote-Schema. In den an Bob adressierten Ausgaben setzt sie mix_attr = 1.
4. Dan scannt alle Transaktionen in der Blockchain und sucht mit Bobs geheimem Ansichtsschlüssel nach jedem Exit $$$P_i \stackrel{?}{=} P’_i = H_s(v R, i) G + S$ (Wo $$$i$ - Seriennummer des Ausgangs, $$$S$- Bobs öffentlicher Ausgabenschlüssel). Wenn Gleichheit gilt, wird diese Ausgabe an Bob adressiert.
   Den stellt sicher, dass mix_attr == 1 ist, fügt diese Ausgabe der Liste hinzu und erhöht das Gleichgewicht um den Wert der Ausgabe.
5. Dan überprüft auch alle Eingaben aller Transaktionen. Wenn sich eine der Eingaben auf Bobs UTXO aus der Liste bezieht, bedeutet dies, dass diese Transaktion die ausgehende Zahlung von Bob ist. Aufgrund der Einschränkung mix_attr = 1 kann der Eingang keine anderen Ausgänge mischen, was bedeutet, dass er Bobs Ausgang direkt ausgibt, und Den kann sicher sein, dass dies Bobs ausgehende Zahlung ist. Den reduziert den Saldo um den Wert des Eingangs.

Auf diese Weise kann Den das korrekte Guthaben von Bobs Brieftasche berechnen, ohne Zugriff auf seinen geheimen Ausgabenschlüssel zu erhalten $$$s$.

Schaltungsmerkmale

Feature 1. Es ist wichtig, dass die sendende Partei (Alice) mix_attr beim Senden einer Transaktion auf 1 setzt. Wenn Alice dies nicht tut, kommt das Geld zu Bob, aber in Zukunft kann Den nicht klar sagen, ob Bob es ausgegeben hat oder nicht, da jeder andere Benutzer diese Ausgabe zum Mischen verwenden kann.

Eine Lösung besteht darin, einen speziellen Adresstyp einzuführen, der dieselben zwei öffentlichen Schlüssel enthält$$$(V, S)$aber anders verpackt als der Standard. Alice, die Geld an eine Adresse dieses Typs sendet, weiß, dass für die entsprechenden Ausgaben mix_attr = 1 gesetzt werden muss.

Feature 2. Die Verwendung von Adressen eines speziellen Typs verpflichtet Alice nicht, den gewünschten Attributwert für die Ausgaben festzulegen. Sie kann Geld senden, ohne dies zu tun. Dies wird jedoch sofort von Bob und dem Wirtschaftsprüfer Dan bekannt gegeben.

Merkmal 3. In diesem Schema wird die Prüfungsfähigkeit zum Preis der größtmöglichen Verringerung der Rückverfolgbarkeit erreicht. Dies stellt kein besonderes Problem dar, wenn die Prüfungsmöglichkeit einer unbegrenzten Anzahl von Personen zur Verfügung gestellt wird. Beispielsweise kann ein Wohltätigkeitsfonds eine Spendenadresse zusammen mit einem geheimen Ansichtsschlüssel veröffentlichen, sodass jeder als Prüfer fungieren und den aktuellen Kontostand seines Geldbeutels berechnen kann. Es ist wichtig, dass in diesem Fall die Anonymität eingehender Übertragungen für CryptoNote Standard bleibt (eine große Anzahl von$$$N_{mixins}$) Die Anonymität ausgehender Zahlungen wird jedoch durch die Unfähigkeit eingeschränkt, beliebige Ausgaben zu mischen.

Es ist anzumerken, dass in dem Fall, in dem die Prüfungsmöglichkeit einem engen Personenkreis zur Verfügung gestellt wird, im Gegensatz zum obigen Beispiel eine Verringerung der Nichtrückverfolgbarkeit ein unerwünschter Effekt sein kann.

Die großen Vorteile dieser Option sind die einfache Implementierung und das Fehlen einer zusätzlichen Belastung für Berechnungen und Daten.

7. Fazit

Wir haben drei Optionen untersucht, um die Möglichkeit der Durchführung eines Audits zum CryptoNote-Protokoll hinzuzufügen: Bytecoin Amethyst, das theoretische AS-Schema von Anton Sokolov und die Verwendung von mix_attr (mit MA bezeichnet).

Die relative Änderung der Ringsignaturgröße für alle Optionen außer Bytecoin (BCN) ist unabhängig von$$$N_{inputs}$daher überlegen $$$N_{inputs} = 1$ (Minimum) und $$$N_{inputs} = 3$ (Abb. 7.1).
Hinweis. $$$N_{inputs}$ - die Anzahl der Einträge in der Transaktion, $$$N_{mixins}$- die Anzahl der Ausgaben, die jeder Transaktionseingabe zugeordnet sind. Wenn$$$N_{mixins} > 1$Dies bedeutet, dass sich jede Eingabe auf mehr als eine Ausgabe einer anderen Transaktion bezieht , um die Unverfolgbarkeit zu erhöhen , und es unmöglich ist festzustellen, welche real ist.

Das beste Ergebnis zeigt die AS-Schaltung, die die Größe der Ringsignatur in einem weiten Bereich der Anzahl der zu mischenden Ausgänge verringert ($$$N_{mixins}$) Bytecoin liefert auch gute Ergebnisse, wenn$$$N_{mixins} \ge 3$ (Wie bereits erwähnt, wurde in Bytecoin Amethyst eine Mindestanzahl eingeführt, um die Rückverfolgbarkeit zu erhöhen $$$N_{mixins}$gleich 3).

Das MA-Schema bietet keine Verbesserungen in der Größe der Ringsignatur.

Vergleichen wir nun die Mühsamkeit des Verfahrens zur Überprüfung der Ringsignatur. Dazu verwenden wir die oben erwähnte Metrik, nämlich die Summe der Operationen des Skalarprodukts und die Berechnung der Hash-Funktion$$$H_p$ mit Gewichten proportional zu ihrer Laufzeit auf einem typischen modernen Prozessor:

$$$O(total) = 130 * O(*) + 15 * O(H_p)$

Wir haben das folgende Bild (Abb. 7.2).
Mit direkten Ausgaben von Geldern ($$$N_{mixins} = 1$) AS- und Bytecoin-Schemata erfordern erheblich mehr Berechnungen, um die Signatur zu überprüfen.

Beim Mischen von Ausgängen ($$$N_{mixins} > 1$) Das Bytecoin-Amethyst-Schema scheint AS vorzuziehen, die zuletzt in Betracht gezogene MA-Option bleibt jedoch unübertroffen.

Lassen Sie uns das Endergebnis unter Berücksichtigung von Faktoren wie einer Vergrößerung der Adresse, Ein- und Ausgängen von Transaktionen zusammenfassen (Abb. 7.3).
Bytecoin behält die Länge der Adresse bei, die für den Endbenutzer günstig ist, während das Anton Sokolov-Schema sie um 50% erhöht. Dies wirkt sich nicht direkt auf die Blockchain-Größe aus (obwohl die Absenderadresse in verschlüsselter Form beispielsweise in zusätzlichen Transaktionen übertragen werden kann, wenn letztere dies wünscht) und auf die Komplexität der Berechnungen, hat jedoch keinen wesentlichen Einfluss auf die Benutzerfreundlichkeit. In dem MA-Schema bleibt die Adressgröße gleich 64 Bytes, es ist jedoch eine Möglichkeit erforderlich, Prüfadressen von normalen zu unterscheiden.

Zu den Überwachungsoptionen für Bytecoin und AS gehört das Hinzufügen eines Punkts (32 Byte) zu jeder Transaktionsausgabe. Die Eingabegröße bleibt jedoch nur für Bytecoin unverändert.

Es ist auch erwähnenswert, dass das Bytecoin-Amethyst-Schema seit langer Zeit im Code implementiert ist und nach dem Fehlen von Meldungen über Probleme, die seit seiner Implementierung aufgetreten sind, in der Praxis gut getestet wurde. Es war jedoch nicht möglich, die öffentliche Beschreibung in strenger Form zu finden, weshalb es keine formalen Beweise für ihre Richtigkeit gibt.

Im Gegensatz dazu wird das AS-Schema streng beschrieben und zur Diskussion in der Krypto-Community vorgeschlagen [ 17 ].

Das MA-System verfügt nicht über einen streng beschriebenen formalen Beweis, erscheint jedoch aufgrund seiner extremen Einfachheit unnötig.

Literatur

1. Nicolas van Saberhagen, CryptoNote v 2.0
2. Bytecoin Ankündigung auf bitcointalk.org Forum
3. Bitmonero-Ankündigung auf bitcointalk.org
4. Bitmonero-Repository auf Github
5. Bernstein et al. "Ed25519: Hochgeschwindigkeits-Hochsicherheitssignaturen"
6. Patient null, « »
7. Shen Noether, «Understanding ge_fromfe_frombytes_vartime»
8. Shen Noether, MRL, «Ring confidential transactions»
9. , H Monero
10. Bytecoin blog — Auditable coins
11. Anton Sokolov, «Cryptonote auditability. How to append a wallet balance audit.»
12. Anton Sokolov, «Discussion for the auditable wallets Variant 1 and 2»
13. Anton Sokolov, «The unlinkable auditable Variant 3»
14. Anton Sokolov, «The auditable variant 4. Memory efficiency and security question.»
15. Anton Sokolov, «Multi-signature with LSAG. One more memory efficient approach to auditable wallets.»
16. Abe, Ohkubo, Suzuki, «1-out-of-n Signatures from a Variety of Keys» (AOS)
17. Anton Sokolov, «Cryptonote auditability and efficient scheme for anonymous key vector proof»
18. Anton Sokolov, „Praktischer Ansatz zum Anhängen von überprüfbaren Brieftaschen an die Cryptonote“
19. "Boolberry löst CryptoNote-Probleme"
20. "Bytecoin Amethyst Stable Release Erweiterte technische Beschreibung"