Witness Data

Anna otrzymała Bitcoin i chce teraz zapłacić Piotrowi. Poprzednia płatność utworzyła wyjście: zapis kwoty oraz warunków późniejszego wydania. Nowa transakcja odwołuje się do niego swoim wejściem. Samo stwierdzenie, że monety należą do Anny, nie wystarczy. Przy zwykłej płatności portfel tworzy podpis, który można sprawdzić bez ujawniania klucza prywatnego. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Klucz prywatny to tajna wartość liczbowa służąca do utworzenia takiego podpisu. W SegWit takie dane przedstawia się jako witness wejścia. Obecność podpisu nie dowodzi jeszcze jego poprawności. [1] [4] [5]

Pomyśl o różnicy między wymaganiem „pokaż ważny dokument” a dokumentem rzeczywiście okazanym. W Bitcoin nie rozstrzyga człowiek: zgodność sprawdzają reguły. Witness program jest częścią warunku zapisanego w poprzednim wyjściu, a jego wersja określa sposób oceny. Witness dostarcza dopiero nowa transakcja wydająca to wyjście. Technicznie jest to uporządkowana lista danych dla każdego wejścia. Nie jest automatycznie wykonywalnym programem ani kopią wszystkich niewydanych monet. [1] [7]

Witness może ujawnić podpis, klucz publiczny lub użyty skrypt, czyli program opisujący warunki wydania. Klucz publiczny służy do sprawdzania podpisów i nie musi być tajny. To nie zaszyfrowana skrytka. Klucz prywatny zostaje u ciebie: służy do podpisywania, a nie wysyłania do sieci zamiast podpisu. Ani witness, ani opublikowany podpis nie zastępują Seed Phrase, słów do odzyskiwania portfela. Gdy utracisz klucze i kopię zapasową, sama publiczna historia płatności nie przywróci możliwości podpisywania kolejnych przelewów. [1] [3] [4]

Eksplorator bloków to aplikacja do wyszukiwania transakcji i bloków w danej sieci. Eksplorator może pokazać wtxid obok txid. Oba są hashami, krótkimi odciskami dokładnego zapisu danych, obliczanymi przez dwukrotne użycie SHA-256. txid korzysta z zapisu bez witness, a wtxid z pełnego zapisu z witness. To nie adresy odbiorcy ani dwie różne płatności. Bez witness używany jest pierwotny format i identyfikatory są takie same. W Bitcoin Core v29.0 polecenie decoderawtransaction podaje pełny identyfikator w hash, a dane witness wejścia w txinwitness. [1] [7] [8]

Kolejna transakcja może wskazywać poprzednią jeszcze przed jej potwierdzeniem. Gdyby ktoś zmienił jej identyfikator samą modyfikacją danych podpisu, wskazanie przestałoby pasować. Zmiana wyłącznie witness nie zmienia txid, co pomaga protokołom z zależnymi transakcjami, takim jak Lightning Network. Nie oznacza to niezmienności całej transakcji. Inne pola lub starsze wejścia bez SegWit nadal mogą wpłynąć na txid, a zmieniony witness musi spełniać odpowiednie reguły weryfikacji. [1] [6]

Witness jest przesyłany z pełnym zapisem transakcji, a po włączeniu do bloku stanowi część jego danych. To nie darmowy magazyn poza łańcuchem. Bajt dodany przez serializację witness wnosi 1 WU, a bajt podstawowy 4 WU; WU to jednostka wagi. Full Node samodzielnie sprawdza reguły i potrzebuje odpowiednich danych do weryfikacji wydania. Mniejsza waga nie pozwala pomijać wymaganych kontroli ani nie oznacza, że dane nie zajmują miejsca. [1] [7]

W starszym formacie dowody wydania zapisywano w scriptSig. Natywny SegWit wersji 0 wymaga pustego pola: dowody są w witness. Istnieje też wariant opakowany w P2SH, starszy sposób płacenia na warunek określony hashem skryptu. W nim scriptSig musi zawierać dokładnie umieszczenie odpowiedniego witness program, bez dowolnych dodatkowych instrukcji. Dowody pozostają w witness. Ten sam cel może mieć różne zapisy, więc sama nazwa pola nie wystarcza do interpretacji. [1] [5]

P2WPKH przedstawia podpis i klucz publiczny. Węzeł sprawdza zgodność hasha klucza z pierwotnym warunkiem i ważność podpisu. P2WSH umożliwia warunek określony hashem całego skryptu. Ostatni element witness to witnessScript, którego hash musi odpowiadać programowi w wyjściu. Wcześniejsze elementy dostarczają danych początkowych do wykonania skryptu, na przykład podpisów. BIP 143 określa budowę podpisywanej wiadomości dla tej wersji, w tym wartość wydawanego wyjścia. Samo odczytanie danych nie dowodzi spełnienia warunków. [1] [2] [5]

Taproot używa natywnego witness wersji 1 i rozróżnia wydanie ścieżką klucza oraz skryptu. Przed wyborem ścieżki odkłada się ewentualny annex, specjalne pole dodatkowe; jego dane nadal liczą się do wagi i są objęte podpisem. Gdy zostaje jeden element, interpretuje się go jako podpis ścieżki klucza. Ścieżka skryptu ujawnia użyty skrypt i control block, dane dowodzące jego związku z poprzednim wyjściem, a nie nowy blok łańcucha. Ewentualne wcześniejsze elementy dostarczają danych skryptowi. Reguł wersji 0 nie można po prostu przenieść na ten przypadek. [3] [5]

Zobowiązanie kryptograficzne (commitment) to odcisk wiążący dane z ich konkretną treścią. Gdy wymagane jest takie zobowiązanie do danych witness, BIP 141 wiąże je z resztą bloku poprzez Coinbase Transaction, pierwszą transakcję przeznaczoną na nagrodę górnika. Drzewo hashy wtxid daje korzeń podsumowujący dane. Dla transakcji nagrody używa się w tym drzewie zerowego wtxid. Korzeń łączy się z zarezerwowaną wartością długości 32 bajtów i dwukrotnie hashuje; wynik zapisuje się jako zobowiązanie w jej wyjściu. Jeśli żadna transakcja nie ma witness, zobowiązanie jest opcjonalne. Łączy publiczne dowody, ale nie jest kopią kluczy ani zamiennikiem weryfikacji. [1]