Warum können Adressen kürzer als 34 Byte sein?

Der Wiki-Eintrag auf Adresse sagt:

Einige Bitcoin-Adressen können kürzer als 34 Zeichen sein (theoretisch nur 27) und dennoch gültig sein. [...] Diese kürzeren Adressen sind einfach gültig, weil sie für Zahlen stehen, die zufällig mit Nullen beginnen, und wenn die Nullen weggelassen werden, wird die codierte Adresse kürzer.

In Ordnung, aber laut diesem Diagramm lautet eine Hauptnetzwerkadresse:

Base58Check(00 ++ RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)) ++ checksum)

Als nächstes schauen wir uns den Eintrag für Base58Check an und wir sehen, dass Schritt 4 ist:

4) Behandeln Sie die Ergebnisse von Schritt 3 – eine Reihe von Bytes – als eine einzige Big-Endian-BigNumber und wandeln Sie sie mit normalen mathematischen Schritten (BigNumber-Division) und dem unten beschriebenen Basis-58-Alphabet in Base-58 um. Das Ergebnis sollte so normalisiert werden, dass es keine führenden Nullen zur Basis 58 enthält (Zeichen „1“).

Die erste seltsame Sache - wenn es als einzelne Big-Endian-Zahl behandelt wird, sollte das Voranstellen des Hauptnetzwerkbytes 00keine Wirkung haben? Da dies das höchstwertige Byte ist, wäre es wie Schreiben 00123statt 123in normaler Schreibweise, oder?

Zweite seltsame Sache - wenn das Ergebnis normalisiert werden sollte, um keine führenden Nullen zu haben, bedeutet das nicht, dass die Ausgabe niemals irgendwelche 1s enthalten sollte? Schritt 5 scheint dazu im Widerspruch zu stehen

5) Das führende Zeichen '1', das in base58 einen Wert von Null hat, ist für die Darstellung eines gesamten führenden Nullbytes reserviert, da es, wenn es sich an einer führenden Position befindet, keinen Wert als ein Basis-58-Symbol hat. Es kann eine oder mehrere führende '1's geben, wenn dies erforderlich ist, um ein oder mehrere führende Nullbytes darzustellen. Zählen Sie die Anzahl der führenden Null-Bytes, die das Ergebnis von Schritt 3 waren (bei alten Bitcoin-Adressen wird es immer mindestens eins für das Versions-/Anwendungsbyte geben; bei neuen Adressen wird es nie welche geben). Jedes führende Null-Byte wird im Endergebnis durch ein eigenes Zeichen „1“ dargestellt.

Es scheint, dass Schritt 4 alle möglichen führenden Bytes entfernt hätte. Sollte dies jedoch nicht der Fall sein, und aus irgendeinem Grund nicht mit dem vorangestellten 00Byte, sollte eine Adresse nicht mehrere führende Einsen haben, z. B. 11175tWpb...anstatt einfach kürzer zu sein, z . B. 175tWpb...?

BEARBEITEN: Ok, es scheint, dass es heißt, dass die gegebene Nutzlast Xnormalisiert base58(X)wird, um die Nullen zu entfernen, und dann stellen Sie 1jedem führenden Byte von ein voran X, nicht base58(X). Es stellt sich immer noch die Frage, warum Adressen kürzer sind, anstatt mehrere 1s zu haben. Ist es so, dass das RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY))zufällig nie zu viele führende 0s hat (die als 1s vorangestellt würden), während base58(RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)))dies der Fall ist (und sie aus dem Endergebnis herausgeschnitten werden)?

Antworten (1)

Ja, es können mehrere führende „1“-Zeichen vorhanden sein, und jede „1“ steht für ein führendes Null-Byte. Dies führt zu einer kürzeren Adresse, da normalerweise jedes Base58-Zeichen etwas weniger als 6 Informationsbits darstellt, aber ein führendes Null-Byte genau 8 Informationsbits enthält.

Zum Beispiel ist die kürzeste Adresse, die Sie haben können, 1111111111111111111114oLvT2 (entspricht einem 160-Bit-Hash von 000000000000000000000000000000000000000). Es hat 21 führende "1"-Zeichen, die genau 21 führende Null-Bytes darstellen (der Hash, dem eine weitere 00 vorangestellt ist).

Nein, es gibt kürzere Adressen. Siehe diese Antwort: bitcoin.stackexchange.com/a/36948