Wie werden die Bytes der bip32-Version in base58 konvertiert?

Konvertieren der Bytes der BIP32-Version - x04\x88\xad\xe4- von base256 in base58 und base58Check gibt 7irrXbzw. 1kz713TZjjuzurück.

Ich dachte, die Versionsbytes repräsentierten xprv. Was vermisse ich?

Ich verwende pybitcointools , falls das einen Unterschied macht.

Warum von base256? 0x04 0x88 0xAD 0xE4 sollte IMO direkt in base58 gehen.
@JonasSchnelli nur, weil die pybitcointools-Bibliothek es so definiert. Es macht keinen Unterschied, ob es als Hex codiert ist

Antworten (2)

Genau wie bei normalen Bitcoin-Adressen (oder irgendetwas, das mit Base 58 codiert ist), werden die Versionsbytes nicht selbst codiert. Wie im Abschnitt Serialisierungsformat beschrieben , gibt es 78-Byte-Nutzdaten, die versioniert und mit einer Prüfsumme versehen werden, bevor sie dann in Basis 58 codiert werden:

  • 4 Byte: Versionsbytes (Mainnet: 0x0488B21E öffentlich, 0x0488ADE4 privat; Testnet: 0x043587CF öffentlich, 0x04358394 privat)
  • 1 Byte: Tiefe: 0x00 für Masternodes, 0x01 für Level-1 abgeleitete Schlüssel, ....
  • 4 Bytes: der Fingerabdruck des Elternschlüssels (0x00000000, wenn Hauptschlüssel)
  • 4 Bytes: Kindnummer. Dies ist ser32(i) für i in xi = xpar/i, wobei xi der Schlüssel > - serialisiert wird. (0x00000000 wenn Hauptschlüssel)
  • 32 Bytes: der Kettencode
  • 33 Bytes: die Daten des öffentlichen Schlüssels oder des privaten Schlüssels (serP(K) für öffentliche Schlüssel, 0x00 || ser256(k) für private Schlüssel)

Es gibt keine Byte-zu-Zeichen-Zuordnung, wenn Sie eine Base58-Serialisierung einer Multibyte-Struktur durchführen. Es ist nicht so, dass 0x04 zu „x“, 0x88 zu „p“ usw. wird. Vielmehr wird die gesamte 86-Byte-Struktur (78 Nutzlast + 4 Version + 4 Prüfsumme) in etwas codiert, das mit „xpriv“ beginnt, wenn die 4 höchstwertigen Bytes der 86-Byte-Struktur sind [0x04, 0x88, 0xad, 0xe4].

Es funktioniert also nur für 78-Byte-Strukturen? Wenn ja, verstehe ich
@WizardOfOzzie Es ist wahrscheinlich, dass eine andere Sequenz von 4 Bytes eine 50-Byte-Struktur erhalten könnte, um beispielsweise mit xpriv zu beginnen, aber ja, genau diese Bytes wurden für eine 78-Byte-Struktur ausgewählt.
Ich versuchte und versuchte es erneut und es würde nicht funktionieren. Dann wurde mir klar, dass es nicht 78 sind, sondern 82 Bytes , wenn Sie die 4-Byte-Prüfsumme einbeziehen. In pybitcointools; changebase(TESTNET_PRIVATE + bytes(bytearray(78)), 256, 58) >>> 'tprv8ZgxMBicQKsPcsbCVeqqF1KVdH7gwDJbxbzpCxDUsoXHdb6SnTPYxdwSAKDC6KKJzv7khnNWRAJQsRA8BBQyiSfYnRt6zuu4vZQGKhCz4Jb. :)
@WizardOfOzzie, guter Punkt! Ich habe meine Antwort aktualisiert.
Zum späteren Nachschlagen: Alle Bytes der erweiterten Schlüsselversion von Bitcoin finden Sie unter electrum.readthedocs.io/en/latest/xpub_version_bytes.html

Um die obige Antwort zu ergänzen, enthält die Datei Bitcoin chainparams.cpp die folgenden Informationen, um die Einhaltung von BIP 32 zu unterstützen:

Hauptnetz:

base58Prefixes[EXT_PUBLIC_KEY] = boost::assign::list_of(0x04)(0x88)(0xB2)(0x1E).convert_to_container<std::vector<unsigned char> >();
base58Prefixes[EXT_SECRET_KEY] = boost::assign::list_of(0x04)(0x88)(0xAD)(0xE4).convert_to_container<std::vector<unsigned char> >();

Testnetz:

base58Prefixes[EXT_PUBLIC_KEY] = boost::assign::list_of(0x04)(0x35)(0x87)(0xCF).convert_to_container<std::vector<unsigned char> >();
base58Prefixes[EXT_SECRET_KEY] = boost::assign::list_of(0x04)(0x35)(0x83)(0x94).convert_to_container<std::vector<unsigned char> >();

Der Befehl bitcoin-explorer (bx) wird unten verwendet, mit dem drittschlechtesten Gehirn-Wallet-Seed der Welt. Außerdem wurde bx für die Verwendung von Testnet und nicht von Mainnet kompiliert. Konzentrieren Sie sich daher auf 04358394 für tprv und 043587cf für tpub , die in den folgenden Beispielen angezeigt werden.

% echo '0' | bx base16-kodieren | bx sha512 | bx hd-neutprv8ZgxMBicQKsPdcvudXaExR6Wdz5VgdjGeZHsw5bjnypoxrCxnYsyVq2v9cPTzDsnyLAL1v4Z2tM3Rp2AA6vv9WDbNBtui5QEZTWYucefZox

% echo '0' | bx base16-kodieren | bx sha512 | bx hd-neu | bx base58check-dekodieren

wrapper
{
    checksum 3287061687
    payload 3583940000000000000000004b0dc73821a026c0c71d07a7655968352b52d7e5896dd3907df121f914f9743900a6b53d2f0e384dc6ced2caeb36f0c9cc6f3ab0677f73c31aca87b62bbcc9fe78
    version 4
}

% echo '0' | bx base16-kodieren | bx sha512 | bx hd-neu | bx base58-dekodieren 04358394000000000000000004b0dc73821a026c0c71d07a7655968352b52d7e5896dd3907df121f914f9743900a6b53d2f0e384dc6ced2caeb36f0c9cc6f3ab0c9cc6f3ab038.92bcc6f3ab038b794ecc3

% echo '0' | bx base16-kodieren | bx sha512 | bx hd-neu | bx hd-öffentlichtpubD9nYDjxx7QwpsEhUiS7MDJ68p25nu9yxEt1AofKmEjmL3kozwA3z8G4Cm556YCYYJwfnix2GLVTtCHZq79R8UsRZBJVRPtD9HKNQBzDZVo4

% echo '0' | bx base16-kodieren | bx sha512 | bx hd-neu | bx hd-Öffentlichkeit | bx base58- 043587cfdecode 01cf633b1c00000000c023d310564ead16b50e678b2ff20e2d0a0f210fcf9c603ebd16f17d0510663802605d719a28b2707dcc9d7a2b804ba70242330e7010161aec4f86a0771d9909e504b705bf

Wie werden die Bytes der bip32-Version in base58 konvertiert?
AntwortenHierDatenschutz-Bestimmungen1y, 0v