Watch-only Wallet pozwala przeglądać płatności i saldo, ale nie przechowuje kluczy prywatnych potrzebnych do wydawania środków. Może też przygotować płatność, którą musi podpisać inne urządzenie lub program. Dzięki temu masz podgląd na telefonie czy komputerze, a klucze trzymasz osobno. Sam napis watch-only nie mówi jednak, kto ma klucze ani czy wyświetlane dane są poprawne.
Alicja trzyma klucze w portfelu sprzętowym i chce sprawdzić wpłatę na telefonie. Przenosi więc do niego publiczną konfigurację portfela, a nie słowa odzyskiwania. Aplikacja rozpoznaje dzięki niej właściwe adresy i szuka ich płatności w sieci. Alicja widzi wpływ 20 000 sat, czyli najmniejszych jednostek bitcoina, i jego potwierdzenia, choć urządzenie podpisujące leży wyłączone w domu. Telefon nie uzyskał prawa do wydania tych pieniędzy. Podobnie sprzedawca może dać księgowej podgląd płatności, nie przekazując jej kluczy. Liczy się to, co faktycznie zaimportowano: wpisanie Seed Phrase, czyli słów pozwalających odtworzyć klucze, zniosłoby ten podział. [12]
Do aplikacji obserwacyjnej można dodać cudzy publiczny adres. Wyświetlana kwota nie dowodzi więc, że użytkownik może ją wydać, a tym bardziej spłacić wszystkie długi. Aplikacja sumuje znalezione UTXO, czyli niewydane wyjścia wcześniejszych płatności. Znajduje jednak tylko to, co pasuje do zaimportowanych danych i dostępnej historii. Brakujące adresy, niedokończone wyszukiwanie lub niewiarygodny serwer mogą dać niepełny obraz. Zero na ekranie samo w sobie nie oznacza utraty bitcoinów; najpierw sprawdź zakres obserwacji i źródło danych. [8] [9]
Gdy Alicja chce zapłacić, aplikacja wybiera dostępne UTXO i przygotowuje odbiorcę, kwotę oraz opłatę. Niewykorzystana część wejścia może wrócić do jej portfela jako reszta, czyli change. Dane można przekazać w PSBT, formacie częściowo podpisanej transakcji Bitcoin zdefiniowanym w BIP174. Oddzielne urządzenie otrzyma to, czego potrzebuje do podpisania, bez własnej bazy UTXO. Alicja musi na jego zaufanym ekranie sprawdzić rzeczywistego odbiorcę, kwotę, opłatę i resztę. Zainfekowana aplikacja może przygotować inną płatność niż zamierzona. Znaczenie ma też sighash, ustawienie określające, które części transakcji obejmuje podpis. Dopiero po sprawdzeniu i podpisaniu można rozgłosić końcową transakcję zgodną z zatwierdzoną propozycją i regułami portfela. [2] [10]
Rozszerzony klucz publiczny, czyli xpub, pozwala wyprowadzać kolejne klucze publiczne w określonej gałęzi portfela; sam nie podpisze płatności. Kto uzyska go wraz z regułami portfela, może jednak powiązać osiągalne adresy, dawne i przyszłe płatności oraz salda. To znacznie więcej niż jeden adres do jednej wpłaty. Cudzy serwer może poznać podobny obraz z powtarzanych zapytań aplikacji. Własny Full Node, który sam sprawdza blockchain, ogranicza udostępnianie danych; szyfrowane lub inne prywatne połączenie nie ukrywa zapytań przed serwerem docelowym. Eksportuj tylko potrzebne konto, ograniczaj kopie i chroń etykiety łączące adresy z nazwiskami lub celami płatności. [1] [13] [14]
Dalsze części to techniczna pomoc przy konfiguracji i odtwarzaniu portfela. Skrypt określa warunki wydania, a Output Descriptor zapisuje te reguły i dane do wyprowadzania adresów. HD Wallet tworzy drzewo kluczy z seedu, czyli tajnych danych początkowych służących do ich wyprowadzania. Wyprowadzanie non-hardened pozwala uzyskać kolejne klucze publiczne z xpub, natomiast hardened wymaga klucza prywatnego. Multisig dodaje ustaloną liczbę wymaganych podpisów. Import adresu obserwuje jego skrypt, nie przyszłe adresy odbiorcze i reszty. Klucz publiczny obejmuje różne typy skryptów tylko wtedy, gdy program jawnie je wyprowadzi. xpub konta pozwala wyprowadzać potomków non-hardened, ale nie określa P2PKH, SegWit, Taproot, gałęzi wewnętrznej ani progu podpisów Multisig. Uzupełnia to deskryptor. Eksportuj go z właściwego konta urządzenia podpisującego, z poprawną siecią i typem skryptu; nie zgaduj ścieżki wyprowadzania, czyli kolejnych kroków od klucza początkowego. [1] [4] [7]
Portfele HD zwykle oddzielają gałąź odbiorczą /0/* od wewnętrznej /1/* dla change, czyli reszty. Bez gałęzi wewnętrznej środki mogą pozornie zniknąć po wydaniu. Mały range, czyli zakres wyprowadzanych adresów, może ukryć wpływy. next_index określa następny generowany adres; rozbieżność między dwoma programami może prowadzić do ponownego użycia adresu. Utrzymuj zgodność aktywnych deskryptorów, zakresów i indeksów. Adres odbiorczy sprawdzaj na ekranie urządzenia podpisującego: złośliwy program może go podmienić mimo wiarygodnego salda. [6] [9]
Bitcoin Core w importdescriptors używa timestamp do określenia początku ponownego skanowania. now pomija dawną historię, a 0 żąda skanowania od Genesis Block. Liczą się też zakres range i dostępność starych bloków. active określa, czy deskryptor służy do generowania nowych adresów; internal oznacza wyjścia wewnętrzne portfela, na przykład resztę. Węzeł z przyciętą historią, który usunął stare bloki, aby oszczędzić miejsce, może nie mieć potrzebnych danych. Rescan tylko odnajduje istniejące transakcje. Zachowaj datę lub wysokość pierwszego użycia i porównuj odtworzenie ze znanymi adresami oraz transakcjami, nie tylko z zerem na ekranie. [9] [10]
BIP380 opisuje język zbiorów skryptów wyjściowych. Przykład wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum zawiera typ skryptu, odcisk klucza głównego, ścieżkę pochodzenia, klucz publiczny konta, gałąź, zmienny indeks i sumę kontrolną. To nie są poprawne dane do importu. Taproot używa tr() według BIP386; BIP389 dopuszcza wiele ścieżek w jednym zapisie. Suma wykrywa błędy przepisywania, nie potwierdza autora. Deskryptor z xprv zawiera tajny klucz i nie powinien trafić do koordynatora obserwacyjnego. [4] [5] [6] [7]
BIP32 opisuje ważny wyjątek: nadrzędny xpub wraz z kluczem prywatnym potomka wyprowadzonego wyłącznie krokami non-hardened pozwala obliczyć nadrzędny klucz prywatny. Sam xpub nie wystarcza; niebezpieczne jest to połączenie. Krok hardened powyżej eksportowanego konta zatrzymuje rozszerzenie ataku przez tę granicę. Nigdy nie wkładaj xprv, seedu ani kluczy prywatnych do portfela obserwacyjnego, jego bazy lub towarzyszących plików PSBT. [1]
Obserwacja Multisig wymaga progu podpisów, typu skryptu, xpub każdego współpodpisującego, pochodzenia i kolejności kluczy oraz obu gałęzi adresów. Jeden xpub nie wystarczy. Utrata deskryptora komplikuje odtworzenie nawet przy zachowanych seedach; inna kolejność lub opakowanie skryptu może dawać inne adresy. Sprawdź reguły i przykładowy adres na wszystkich urządzeniach podpisujących. Zachowaj deskryptor z sumą kontrolną lub standardową konfigurację, pamiętając, że ujawnia powiązania współpodpisujących. [4] [11]
Oddzielnie od kluczy prywatnych zachowaj deskryptory obu gałęzi, pochodzenie kluczy, sieć, datę lub wysokość utworzenia, zakresy, indeksy, etykiety i reguły Multisig. BIP329 przenosi etykiety, ale nie zastępuje deskryptora ani historii. Przetestuj odtworzenie w osobnym profilu lub sieci testowej: zaimportuj publiczną konfigurację, przeskanuj historię, porównaj stare adresy obu gałęzi i oczekiwane UTXO, przygotuj PSBT i podpisz ją właściwym urządzeniem. Przed rozgłoszeniem sprawdź wynik. Watch-only służy do obserwacji i przygotowania, nie daje uprawnienia do wydawania. [3] [9] [12]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Extended Public Key (xpub), Portfel, Cold Storage, Output Descriptor, PSBT, Bitcoin. Do tego hasła prowadzą również odsyłacze z HD Wallet, Cold Storage, Extended Public Key (xpub), Output Descriptor.