Extended Public Key (xpub) jest zgodny z BIP32, czyli regułami porządkowania kluczy w portfelu. Pozwala obliczać kolejne klucze publiczne w określonej części portfela, a przy właściwych regułach adresów — przygotowywać adresy odbiorcze i śledzić płatności. Wydawanie środków wymaga jednak podpisu cyfrowego, czyli kryptograficznego zatwierdzenia transakcji. Tworzy go klucz prywatny, którego xpub nie zawiera. Xpub nie zastępuje więc kluczy prywatnych ani Seed Phrase, kopii zapasowej portfela zapisanej jako ciąg słów.
Anna używa portfela sprzętowego i chce sprawdzać na telefonie, czy klient zapłacił. Przenosi do telefonu publiczną konfigurację wybranego konta, w tym xpub, ale żadnych kluczy prywatnych. Telefon działa wtedy jako Watch-only Wallet: obserwuje odpowiednie adresy, przygotowuje nowe i tworzy niepodpisaną transakcję. Wydanie pieniędzy nadal wymaga podpisu urządzenia z tajnymi kluczami. Podobnie sklep może generować różne adresy dla zamówień bez przechowywania kluczy do wydawania na serwerze. Ogranicza to skutki włamania, ale nie rozwiązuje wszystkiego: napastnik może pokazać klientowi własny adres do nowej płatności. [1] [5]
Zwykły adres Bitcoin dajesz osobie, która ma ci zapłacić. Xpub otwiera znacznie szerszy widok. Kto zna xpub konta i reguły jego adresów, może wyliczać adresy odbiorcze oraz adresy zwrotu reszty, a potem łączyć ich historie i salda. Dotyczy to wyprowadzalnej gałęzi, nie automatycznie wszystkich kont portfela. Serwis księgowy lub zewnętrzny eksplorator, któremu podasz xpub, może go zachować i obserwować przyszłe płatności. Odłączenie aplikacji nie cofa udostępnionej kopii. Do pojedynczej płatności zwykle wystarcza jeden adres; szerszy dostęp dawaj tylko wtedy, gdy ma rzeczywisty cel. [1] [5]
Portfel BIP32 tworzy drzewo kluczy z jednego punktu wyjścia. Gałąź oznacza tu grupę wyprowadzonych kluczy, nie część sieci czy łańcucha bloków. Z xpub można iść w dół tylko krokami non-hardened. Drugi rodzaj, Hardened Derivation, wymaga danych prywatnych i tworzy granicę, której sam xpub nie przekroczy. Typowy układ BIP44 stawia taką granicę przed każdym kontem. Eksport xpub jednego konta nie ujawnia więc sam z siebie pozostałych. Liczy się też głębokość eksportu: xpub samej gałęzi odbiorczej pozwala zobaczyć mniej niż xpub całego konta, który zwykle obejmuje też resztę. [1] [6]
Z tych samych kluczy publicznych można według różnych reguł utworzyć różne adresy Bitcoin. Wyjście transakcji to zapis kwoty i warunków, pod którymi można ją później wydać. Aplikacja musi znać typ wyjścia portfela, na przykład Native SegWit lub Taproot, oraz gałąź i numery kolejnych kluczy do wyprowadzenia. Prefiksy ypub i zpub według SLIP-0132 podpowiadają typ adresów, ale nie opisują całego portfela. Dokładniejszy jest Output Descriptor: tekstowy zapis kluczy i reguł tworzących adresy oraz warunki wydawania. Może zawierać pochodzenie klucza, ścieżkę wyprowadzania i sumę kontrolną wykrywającą literówki. Sprawdza ona zapis, nie wiarygodność nadawcy. Nie każdy descriptor jest wyłącznie publiczny: niektóre zawierają klucze prywatne, więc rozróżnij je przed udostępnieniem. [2] [3] [4]
Najpierw sprawdź sieć, wybrane konto, typ adresów i ścieżkę wyprowadzania, czyli instrukcje określające miejsce klucza w drzewie. Porównaj kilka adresów odbiorczych z pierwotnym portfelem, a w portfelu sprzętowym skorzystaj z zaufanego ekranu zgodnie z procedurą producenta. Zgodna nazwa konta nie wystarczy. Zerowe saldo po imporcie nie musi oznaczać utraty środków: możesz obserwować inne konto, inny typ adresów lub zbyt mały zakres ich numerów. Nie wpisuj z tego powodu słów odzyskiwania na przypadkowej stronie. Do samego podglądu szukaj eksportu publicznej konfiguracji, nie Seed Phrase ani xprv, czyli rozszerzonego klucza prywatnego. [4] [5]
Sam xpub nie jest kluczem podpisującym. BIP32 ma jednak ważną zależność: nadrzędny xpub, w dokumentacji parent xpub, razem z kluczem prywatnym potomka non-hardened pozwala obliczyć nadrzędny klucz prywatny. Dla dalszego potomka wszystkie kroki po drodze muszą być non-hardened, a obliczenie wymaga znajomości odpowiedniej ścieżki. Nie chodzi o kradzież przez samo poznanie adresu. Niebezpieczne jest połączenie ujawnionego publicznego podglądu z ujawnionym tajnym kluczem tej samej gałęzi. Atakujący może wtedy uzyskać też pozostałe klucze pochodzące od tego klucza nadrzędnego. Granice hardened oddzielają konta, ale nie chronią już ujawnionego klucza prywatnego. [1]
Portfel Multisig może wymagać dwóch podpisów z trzech kluczy. Nie wystarczy jednak wiedzieć, które dwa klucze potrafisz odzyskać. Odtworzenie właściwych warunków wydawania wymaga też danych publicznych pozostałych uczestniczących kluczy, ich układu, wymaganej liczby podpisów i reguł wyprowadzania. Obok tajnych kopii przechowuj więc konfigurację portfela, na przykład publiczny descriptor ze wszystkimi potrzebnymi xpub. Nie daje on prawa do wydawania, ale może być niezbędny do odzyskania dostępu. Master fingerprint, osiem znaków szesnastkowych oznaczających klucz początkowy, pomaga dopasować konfigurację. Nie jest unikalnym dowodem tożsamości: różne klucze mogą mieć ten sam fingerprint. [4] [5]
Klucz publiczny weryfikuje podpisy utworzone odpowiednim kluczem prywatnym. BIP32 dodaje chain code, wartość o długości 32 bajtów do wyprowadzania kolejnych kluczy. Razem tworzą rozszerzony klucz publiczny. Jego przenośny zapis zawiera też wersję i pozycję w drzewie: głębokość, fingerprint bezpośredniego rodzica i numer potomka. Nie jest to pełna ścieżka od pierwszego klucza portfela. Xpub nie jest zatem pojedynczym adresem odbiorczym ani hasłem konta i nie zawiera listy transakcji. Portfel obserwujący odnajduje je na łańcuchu dla odpowiednich adresów. [1]
Funkcja CKDpub z BIP32 bierze nadrzędny klucz publiczny, jego chain code i indeks potomka. Za pomocą HMAC-SHA512, obliczenia kryptograficznego na tych danych, przygotowuje następny klucz publiczny i nowy chain code. Publicznie wyprowadzalne indeksy mieszczą się od 0 do 2³¹−1. Indeksy hardened zaczynają się od 2³¹ i zwykle oznacza się je w ścieżkach apostrofem lub h; CKDpub z xpub nie potrafi ich wyprowadzić. Powtarzanie dozwolonych kroków tworzy potomków, nie rodzeństwo czy przodków eksportowanego klucza. Jeśli pojawi się rzadki nieprawidłowy wynik opisany w BIP32, implementacja przechodzi do następnego indeksu. Użytkownik nie musi liczyć tego sam; ważne jest poprawne przeniesienie konfiguracji. [1]
Przed zakodowaniem jako tekst standardowy zapis BIP32 zajmuje 78 bajtów: wersja 4, głębokość 1, fingerprint klucza nadrzędnego 4, numer potomka 4, chain code 32 i dane klucza 33. Base58Check dodaje sumę kontrolną i zamienia zapis na 111 znaków. Wersja publiczna głównej sieci zaczyna się od xpub, testowa od tpub; prywatne odpowiedniki od xprv i tprv. Tpub nie oznacza Taproot. Prefiks wynika z bajtów wersji i nie opisuje wszystkich reguł adresów. Podczas importu oprogramowanie musi też zweryfikować poprawność klucza publicznego, nie tylko jego pierwsze litery czy długość. [1] [3]
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.