PSBT v2

Anna i Jan chcą wspólnie zapłacić jedną fakturę. Każde z nich dokłada część środków i podpisuje transakcję na własnym urządzeniu. Muszą wymienić zgodny projekt, a nie klucze prywatne. Klucz prywatny to tajna liczba, której portfel używa do tworzenia podpisu cyfrowego autoryzującego wydanie środków. Do przekazywania projektu służy PSBT: robocza koperta z transakcją i dodatkowymi informacjami. Wejścia wskazują wcześniejsze kwoty, które zostaną wydane; wyjścia określają nowe kwoty oraz warunki ich późniejszego wydania. Pierwotny PSBT v0 przechowuje ten szkielet w ustalonej globalnej transakcji bez podpisów. W v2 wejścia i wyjścia można uzupełniać stopniowo, zgodnie z odpowiednimi zasadami. Zaletą jest wspólne budowanie, nie swoboda przepisywania tego, co ktoś już podpisał. [1] [2]

Anna nie musi czytać wszystkich pól technicznych. Powinna jednak na zaufanym urządzeniu podpisującym sprawdzić rzeczywistego odbiorcę, kwotę, opłatę i ewentualną resztę wracającą do jej portfela. Ten ostatni element łatwo przeoczyć: nie wolno uznać cudzego wyjścia za własną resztę. Urządzenie musi zweryfikować dane UTXO, czyli jeszcze niewydanych wyjść, oraz zgodność ich warunków z podpisywaną transakcją. Ścieżka wyprowadzania klucza opisuje kroki, dzięki którym portfel uzyskuje konkretny klucz ze swojego klucza głównego. Samo podanie takiej ścieżki nie dowodzi własności. Urządzenie musi też prawidłowo odczytać SIGHASH, ustawienie określające części transakcji chronione podpisem. Podpisanie nie wymaga dopisywania do przekazywanego pliku klucza prywatnego ani Seed Phrase, słów służących do odzyskania portfela. [2] [4]

Informacja, że aplikacja lub urządzenie obsługuje PSBT, nie potwierdza jeszcze obsługi v2. Trzeba sprawdzić cały przebieg: utworzenie, import, podpisanie i przekazanie wyniku z powrotem pomiędzy konkretnymi programami i urządzeniami. PSBT v0 i v2 nie są bezpośrednio zamienne. Konwersja do v0 wymaga zbudowania niepodpisanej transakcji i dostosowania pól do reguł tej wersji; zmiana samej liczby nie wystarczy. Również Taproot, nowszy sposób określania warunków wydawania wyjść Bitcoina, nie jest tym samym co v2. BIP 371 opisuje jego dane do podpisu dla obu wersji PSBT. Niewielka próba całej ścieżki potwierdza zgodność danego zestawu, a nie poprawność wszystkich przyszłych płatności. [1] [3]

Wersja formatu pliku i wersja transakcji Bitcoin oznaczają różne rzeczy. W v2 pole PSBT_GLOBAL_VERSION musi zawierać 2, a stare pole PSBT_GLOBAL_UNSIGNED_TX musi być nieobecne. Odrębne obowiązkowe pole PSBT_GLOBAL_TX_VERSION określa wersję samej transakcji. Obowiązkowe są również liczby wejść i wyjść. Dzięki temu informacje znajdują się przy poszczególnych elementach, zamiast zmuszać program do szukania ich także we wspólnym szkielecie. Jeżeli twórca przekazuje dalsze budowanie innym uczestnikom, BIP 370 wymaga odpowiednich znaczników zmian oraz wersji transakcji wynoszącej co najmniej 2. Nadal jest to format roboczy, a nie nowe reguły konsensusu sieci. [1]

Każde wejście wymaga TXID, identyfikatora wcześniejszej transakcji, oraz indeksu konkretnego wydawanego z niej wyjścia. Sam TXID nie wystarczy, bo transakcja może mieć wiele wyjść. Każde nowe wyjście zawiera kwotę w satoshi, najmniejszych jednostkach Bitcoina, i scriptPubKey, skrypt określający warunki wydania. Dodanie elementu musi też zmienić odpowiednią globalną liczbę. Opcjonalne pole sequence zawiera dodatkową wartość sterującą wejścia; przy jego braku używa się 0xffffffff. Te dane konstrukcyjne opisują sposób złożenia transakcji. Nie zastępują informacji o wartości i warunkach wydania UTXO, potrzebnych urządzeniu do bezpiecznej oceny podpisu i opłaty. [1]

Załóżmy, że Jan musi dodać kolejne wejście. Program nie może uznać tego za dozwolone tylko dlatego, że ma dostęp do pliku. W PSBT_GLOBAL_TX_MODIFIABLE bit 0 wskazuje możliwość zmian wejść, a bit 1 możliwość zmian wyjść. Bit 2 sygnalizuje podpis SIGHASH_SINGLE, który łączy wejście z wyjściem na odpowiadającej mu pozycji. To powiązanie musi zostać zachowane także przy dodawaniu następnych elementów. Dlatego podmiot budujący transakcję analizuje konkretne podpisy i ich ograniczenia. Znaczniki przekazują informacje współpracującym programom; nie obchodzą podpisu kryptograficznego i nie sprawiają, że niepoprawna zmiana staje się poprawna. [1]

Niektóre wejścia wymagają, aby transakcja mogła zostać użyta dopiero po określonej wysokości bloku albo granicy czasowej. Blok to grupa transakcji zapisana we wspólnej historii sieci; jego wysokość wskazuje pozycję w łańcuchu. Wspólne pole nLockTime musi przyjąć typ wymagania zgodny ze wszystkimi wejściami. Wybiera się największą wymaganą wartość tego typu; jeśli możliwe są oba typy, pierwszeństwo ma wysokość bloku. Wysokości i czasu nie porównuje się więc jak dwóch zwykłych liczb. Gdy żadne wejście nie ma wymagania, obowiązuje globalna wartość zastępcza, a przy jej braku 0. Wejścia ze sprzecznym wymaganiem nie wolno dodać. Jeżeli istnieją już podpisy, nowe wejście nie może także zmienić obliczonego nLockTime. Same te pola nie gwarantują spełnienia wszystkich reguł blokad czasowych. [1]

Każdy podpis ogranicza kolejne modyfikacje. BIP 370 wymaga wyłączenia zmian wejść, gdy podpis nie używa SIGHASH_ANYONECANPAY, oraz zmian wyjść bez SIGHASH_NONE; przy SIGHASH_SINGLE trzeba zaznaczyć konieczność zachowania pary. Nazwy te oznaczają różne zakresy ochrony podpisem, a nie ustawienia do przypadkowego przełączania przez początkujących. Kiedy wszystkie wejścia są gotowe, finalizacja składa wymagane dane podpisów, a ekstraktor tworzy z pól transakcję w formacie sieciowym. Dopiero wysłanie pozwala węzłom ją ocenić, a górnikowi umieścić w bloku. Anna i Jan rozróżniają więc projekt, podpisany wynik i potwierdzoną płatność: samo przekazanie PSBT nie jest podpisaniem ani potwierdzeniem. [1] [2] [4]