Eine Transaktion Byte für Byte
Vollständige Zerlegung des Hex einer RingCT-Transaktion: jedes Feld, jede Funktion – mit echten und zufälligen Daten
Eine Monero-Transaktion besteht aus drei aufeinanderfolgenden Byte-Blöcken: dem Präfix (Inputs, Outputs, Extra), der RingCT-Basis (Gebühr, verschlüsselte Beträge, Commitments) und dem prunable Teil (Bulletproofs+, CLSAG, Pseudo-Outputs). Unten findest du ein Tool, das jede v2-Transaktion Byte für Byte zerlegt, die Txid berechnet, die Bilanz prüft und – mit einem View Key – „deine“ Outputs findet und ihre Beträge entschlüsselt. Bei einer zufälligen Transaktion zeigt es alle Geheimnisse, sodass du siehst, wie jede Funktion auf echte Zahlen angewendet wird.
Wie man die Bytes liest
Moneros Serialisierung ist einfach – keine Header oder Feldnamen, nur Werte hintereinander. Es gibt zwei Arten von Bausteinen:
- Varint – eine Ganzzahl variabler Länge: 7 Bit pro Byte, das oberste Bit bedeutet „es folgt noch ein Byte“.
0x02= 2,0x80 0x01= 128,0x80 0xb5 0x18= 400000. - Key / Punkt / Skalar – genau 32 Bytes, ohne Längenangabe. Auch Arrays von Punkten, deren Länge aus dem Kontext bekannt ist (z. B. CLSAGs
s, anhand der Ringgröße), kommen ohne Länge.
Der Parser muss das Format also im Voraus kennen: Der RingCT-Typ, der in der Mitte gelesen wird, bestimmt, wie alles danach zu lesen ist.
Welche Funktionen wo angewendet werden
| Feld | Berechnet von | Formel | Mehr |
|---|---|---|---|
| extra: R | Sender | R = r·G | Stealth-Adressen |
| output: P | Sender | P = Hs(8·r·A ‖ i)·G + B | Stealth-Adressen |
| View Tag | Sender | Keccak("view_tag" ‖ 8rA ‖ i)[0] | View Tags |
| ecdhInfo | Sender | v ⊕ Keccak("amount" ‖ Hs(8rA ‖ i))[0..8] | Pedersen |
| outPk | Sender | C = y·G + v·H, y = Hs("commitment_mask" ‖ Hs(8rA ‖ i)) | Pedersen |
| Ring | Wallet des Senders | 16 globale Indizes, Gammaverteilung über das Alter | Decoys |
| Key Image | Besitzer des Inputs | I = x·Hp(P) | Key Image |
| pseudoOuts | Sender | C̃ = y'·G + v·H, Masken so gewählt, dass Σ C̃ = Σ C + fee·H | RingCT |
| CLSAG | Besitzer des Inputs | ein Ring von Challenges über P_i und C_i − C̃ | Ringsignaturen |
| Bulletproofs+ | Sender | Beweis, dass 0 ≤ v < 2⁶⁴ für alle Outputs | Range Proofs |
Was ein Node mit diesen Bytes macht
- Er parst sie; jedes überzählige oder fehlende Byte führt zur Ablehnung.
- Er prüft, dass die Key Images neu sind und in der richtigen Untergruppe liegen.
- Er rekonstruiert aus den Offsets die 16 globalen Indizes und lädt Schlüssel und Commitments dieser Outputs aus seiner Datenbank.
- Er prüft die Bilanz
Σ C̃ = Σ outPk + fee·H– das macht auch das Tool unten. - Er prüft Bulletproofs+ und das CLSAG jedes Inputs.
Was die Wallet des Empfängers macht
- Sie nimmt
Raus Extra und berechnet das gemeinsame Geheimnis8·a·R(eine Operation pro Transaktion). - Für jeden Output: ein Hash → View Tag vergleichen; keine Übereinstimmung – Schluss.
- Übereinstimmung –
Hs(8aR ‖ i)·G + Bmit dem Output-Schlüssel vergleichen. - Der Output gehört uns – Betrag entschlüsseln, Maske rekonstruieren und
y·G + v·HgegenoutPkprüfen.
Das Tool zeigt all diese Schritte mit konkreten Zahlen.
Der Parser wurde mit der JSON-Dekodierung von monerod für echte Transaktionen der Typen 5 und 6 sowie eine Coinbase-Transaktion abgeglichen: Jedes Feld und die Txid stimmen überein. Der Knopf „echte Tx aus dem Mainnet“ lädt eine davon – vergleiche die Txid mit einem beliebigen Block-Explorer.
Wie wird eine FCMP++-Transaktion aussehen?
Das Transaktionsformat von FCMP++ kann sich vor dem Hard Fork noch ändern, deshalb gibt es hier noch keinen Byte-Parser dafür. Aus der aktuellen Implementierung ist die Gesamtstruktur aber klar – und sie ähnelt der heutigen überraschend stark:
| In RingCT | In FCMP++ | Funktionen |
|---|---|---|
| 16 Offsets pro Input | ein Verweis auf den Block, gegen dessen Baum der Beweis gebaut wird | Curve-Tree-Wurzel über alle Outputs |
Key Image I = x·Hp(P) | dasselbe L = x·Hp(O) | Doppelausgaben werden wie bisher erkannt |
Pseudo-Output C̃ | C̃ = C + r_c·G – Teil des rerandomisierten Tupels | Rerandomisierung |
| CLSAG pro Input | SA+L pro Input (ein paar Punkte und Skalare) | verallgemeinertes Schnorr |
| — | ein Mitgliedschaftsbeweis für die ganze Transaktion | Generalized Bulletproofs + Divisoren |
| 1-Byte-View-Tag, ECDH auf Ed25519 | 3-Byte-View-Tag, X25519, Janus-Anker | Carrot |
Rerandomisierung mit echten Zahlen siehst du im Tool. Sobald das Format feststeht, kommt hier auch eine Byte-Zerlegung von FCMP++-Transaktionen dazu.