xpub nie jest adresem Bitcoin ani kluczem podpisującym. Eksportuje węzeł drzewa BIP32, dzięki czemu portfel watch-only lub serwer płatniczy generuje niższe klucze i adresy publiczne. Posiadacz zwykle nie może wydawać środków, lecz widzi gałąź; znaczenie adresów zależy też od derivation path i script policy.
BIP32 przedstawia rozszerzony klucz publiczny jako punkt publiczny K połączony z 32-bajtowym chain code c. Serializacja zawiera także version bytes, depth, parent fingerprint i child number. xpub nie jest pojedynczym adresem, lecz węzłem hierarchii z danymi pozwalającymi kontynuować jego gałąź publiczną.
CKDpub łączy parent public key, chain code i indeks przez HMAC-SHA512. Dla indeksów 0–2³¹−1 tworzy child public key i nowy chain code, więc portfel online generuje adresy receive i change bez sekretu podpisującego. Wyprowadza wyłącznie potomków eksportowanego węzła, nie rodzeństwo ani przodków.
Indeksy hardened zaczynają się od 2³¹ i zapisuje się je apostrofem lub h. Ich obliczenie wymaga danych prywatnych, więc CKDpub z parent xpub nie działa. Portfele zwykle utwardzają purpose, coin type i account, a następnie eksportują account xpub, oddzielając inne konta hardened.
Serializacja BIP32 ma 78 bajtów: wersję, depth, parent fingerprint, child number, chain code i 33 bajty key material. Base58Check daje 111 znaków; publiczny mainnet zaczyna się xpub, testnet tpub. Prefiks wynika z version bytes, a nie z odrębnego rodzaju klucza kryptograficznego.
xpub nie mówi, czy klucze tworzą skrypty P2PKH, wrapped SegWit, native SegWit, Taproot czy multisig, a bez key origin ścieżka może być niejasna. SLIP-0132 wprowadził ypub, zpub i inne wersje jako wskazówki; descriptor jawnie zapisuje script, fingerprint, path, xpub, wildcard i checksum.
Posiadacz account xpub może obliczyć wszystkie nieutwardzone receive i change public keys tej gałęzi i łączyć ich transakcje oraz salda. Przekazanie go aplikacji księgowej lub publicznemu block explorer tworzy trwały widok konta i może powiązać dane sieciowe albo tożsamość z historią on-chain.
Sam xpub zwykle nie podpisuje. Krytyczny wyjątek BIP32: parent xpub wraz z private key jednego nieutwardzonego potomka pozwala odzyskać parent private key i pozostałą gałąź. Dlatego xpub chroni się jako dane wrażliwe, a granice account wykonuje jako hardened.
Portfel watch-only obserwuje xpub, buduje niepodpisaną transakcję i przekazuje ją urządzeniu podpisującemu. Sklep generuje unikalne adresy bez przechowywania xprv. Ogranicza to bezpośrednią kradzież po włamaniu na serwer, nie obserwację; adres odbiorczy nadal należy sprawdzać na zaufanym ekranie.
W multisig własny seed nie opisuje całego portfela: dokładne odtworzenie wymaga public keys cosignerów, threshold, script type i danych derivation. Descriptor przechowuje policy precyzyjniej niż luźne xpuby. Ośmioznakowy master fingerprint pomaga dopasować klucze, lecz nie dowodzi tożsamości i może kolidować.
Przed importem ustal network, account, derivation path, oczekiwany script type, gałęzie receive/change i zakres indeksów. Porównaj xpub lub descriptor na zaufanym urządzeniu, wyprowadź kilka adresów i sprawdź je w portfelu źródłowym; nie używaj zewnętrznego explorera bez świadomej zgody na utratę prywatności. Źródła: BIP 32 — Hierarchical Deterministic Wallets; BIP 380 — Output Script Descriptors General Operation; SLIP-0132 — Registered HD Version Bytes; Bitcoin Core — Output Descriptors; Trezor — What Is a Public Key (XPUB)?.
Pełniejszy obraz uzyskasz, czytając to hasło razem z HD Wallet, Watch-only Wallet, Prywatność w Bitcoinie, Derivation Path, Bitcoin, Output Descriptor. Do tego hasła prowadzą również odsyłacze z HD Wallet, Cold Storage, Watch-only Wallet, Output Descriptor.