MSTR Cat

Blockchain/Niveau II · Mechanik/2.1 Kryptographie/Lektion 6

Adressen und Kodierungen: Base58Check, Bech32, Bech32m

Das Alphabet der Fehler: von Base58Check zur BCH-Prüfsumme

MaterialienEine Block-Explorer-Oberfläche (z. B. mempool.space oder blockchain.com)Ein Texteditor zum Vergleichen der Längen von ZeichenkettenDie Spezifikationsdokumente BIP-173 und BIP-350

Neugier

  1. Warum macht die Änderung eines einzigen Zeichens eine Adresse fast immer ungültig, während manche Tippfehler dennoch durchrutschen?
  2. Wie kann eine Folge aus Buchstaben und Ziffern als Verweis auf ein bestimmtes Locking-Skript dienen, ohne dass dieses Skript in der Chain gespeichert wird?
  3. Was kann Bech32 bei Tippfehlern garantieren, das Base58Check nur unwahrscheinlich machen kann?

Erkunden

  1. Eine Adresse ist kein im UTXO-Set gespeichertes Objekt; sie ist eine menschenfreundliche Kodierung eines Output-Skripts. Die Chain speichert nur Bytes, doch Software übersetzt sie in Zeichenketten, die Menschen lesen und eintippen können. Diese Übersetzungsschicht muss Übertragungsfehler verhindern, denn eine vertippte Adresse, die dennoch gültig aussieht, kann Guthaben an die falsche Stelle senden. Satoshis ursprüngliches Design, Base58Check, begegnete dem mit einem Alphabet aus 58 Zeichen, das die visuell mehrdeutigen Zeichen „0“, „O“, „I“ und „l“ auslässt.
  2. Base58Check kodiert ein Versionsbyte, die Nutzdaten (etwa einen 20-Byte-Hash) und eine vier Byte lange Prüfsumme. Die Prüfsumme wird aus den ersten vier Bytes des doppelten SHA-256-Hashes der vorangehenden Daten abgeleitet. Legacy-Adressen vom Typ Pay-to-Public-Key-Hash (P2PKH) verwenden das Versionsbyte 0x00, wodurch Zeichenketten entstehen, die mit „1“ beginnen. Pay-to-Script-Hash (P2SH) verwendet das Versionsbyte 0x05, was Zeichenketten ergibt, die mit „3“ beginnen. Diese Struktur ermöglicht es Wallets, die Integrität einer Adresse zu prüfen, bevor sie sie akzeptieren.
  3. Segregated Witness (SegWit), im August 2017 bei Block 481.824 aktiviert, führte native Witness-Outputs ein, die eine neue Kodierung erforderten. Base58Check eignete sich schlecht für die längeren Datenstrukturen und die spezifischen Fehlermuster von SegWit. Pieter Wuille und Greg Maxwell schlugen Bech32 in BIP-173 (2017) vor. Es verwendet einen eingeschränkten Zeichensatz aus 32 Zeichen, Ziffern und Kleinbuchstaben ohne „1“, „b“, „i“ und „o“, wobei „1“ als Trennzeichen reserviert ist. Eine einheitliche Groß-/Kleinschreibung vermeidet Mehrdeutigkeiten und eignet sich für QR-Codes.
  4. Bech32-Adressen beginnen mit dem für Menschen lesbaren Teil „bc“ und dem Trennzeichen „1“, gefolgt von den Daten und einer sechsstelligen Prüfsumme. Diese Prüfsumme basiert auf Bose-Chaudhuri-Hocquenghem-Codes (BCH-Codes), die deutlich stärker sind als die aus SHA-256 abgeleitete Prüfsumme von Base58Check. Der BCH-Code garantiert die Erkennung jedes Fehlers, der bis zu vier Zeichen betrifft, und kann die Position von Tippfehlern oft lokalisieren. Native SegWit-v0-Adressen (P2WPKH und P2WSH) verwenden dieses Format und beginnen mit „bc1q“.
  5. Entwickler entdeckten später eine Schwäche im ursprünglichen Bech32-Polynom: Das Einfügen oder Löschen bestimmter Zeichenfolgen konnte eine gültige, aber andere Adresse ergeben. Um dies zu beheben, ohne bestehende v0-Adressen zu beeinträchtigen, führte BIP-350 (2020) Bech32m ein. Es ändert eine Konstante in der Prüfsummenberechnung, sodass Einfügungen und Löschungen dieser Art erkannt werden. Taproot-Adressen (SegWit-Version 1), im November 2021 aktiviert, verwenden Bech32m und beginnen mit „bc1p“.
  6. Testnet-Adressen verwenden das Präfix „tb1“ statt „bc1“. Der Datenteil kodiert das Witness-Programm: einen Hash eines öffentlichen Schlüssels oder Skripts bei SegWit-Version 0 oder einen 32 Byte langen, getweakten öffentlichen Schlüssel bei Taproot. Wenn Software einen QR-Code scannt oder eine manuelle Eingabe entgegennimmt, führt sie die BCH-Polymod-Funktion aus, um die Integrität zu prüfen. Öffnen Sie einen Block-Explorer und suchen Sie je eine Adresse jedes Typs: eine Legacy-P2PKH-Adresse, die mit „1“ beginnt, eine SegWit-v0-Adresse, die mit „bc1q“ beginnt, und eine Taproot-Adresse, die mit „bc1p“ beginnt. Notieren Sie ihre Längen und Präfixe.

Kernfakten

  • Base58Check verwendet ein Alphabet aus 58 Zeichen, lässt „0“, „O“, „I“ und „l“ aus und enthält eine vier Byte lange Prüfsumme, die aus doppeltem SHA-256 abgeleitet wird.
  • Legacy-P2PKH-Adressen beginnen mit „1“ (Versionsbyte 0x00), P2SH-Adressen dagegen mit „3“ (Versionsbyte 0x05).
  • Bech32, definiert in BIP-173 (2017), verwendet ein 32-Zeichen-Set sowie eine auf BCH basierende Prüfsumme, um Fehler zu erkennen, die bis zu vier Zeichen betreffen.
  • Native SegWit-v0-Adressen (P2WPKH/P2WSH) verwenden die Bech32-Kodierung und beginnen mit „bc1q“.
  • Bech32m, definiert in BIP-350 (2020), behebt eine Prüfsummenschwäche von Bech32 und ist für die SegWit-Versionen 1 bis 16 verpflichtend.
  • Taproot-Adressen (SegWit-Version 1) verwenden die Bech32m-Kodierung und beginnen mit „bc1p“.

Übung neun, sechs, drei, eins

9SammelnSuchen Sie in einem Block-Explorer 9 echte Bitcoin-Adressen: drei, die mit „1“ beginnen, drei, die mit „3“ beginnen, zwei, die mit „bc1q“ beginnen, und eine, die mit „bc1p“ beginnt.
6GruppierenGruppieren Sie die 9 Adressen nach Präfix, Länge und dem Skripttyp, den sie darstellen, in 6 Kategorien.
3VerdichtenReduzieren Sie die 6 Gruppen auf 3 grundlegende Unterschiede darin, wie diese Kodierungen mit Datenintegrität und visueller Mehrdeutigkeit umgehen.
1KristallisierenSchreiben Sie 1 Satz, der erklärt, warum der Wechsel von Base58Check zu Bech32 von der Mathematik der Fehlererkennung und nicht bloß von ästhetischen Erwägungen angetrieben wurde.

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

In der interaktiven Akademie öffnen →

EN PT ES ZH JA KO RU FR MS