Package Relay pozwala węzłom Bitcoin wspólnie przekazywać i oceniać powiązane, niepotwierdzone transakcje. Przydaje się, gdy pierwsza oferuje za małą opłatę, ale kolejna, wydająca jej wyjście, dodaje dość dla obu. Nadal obowiązują reguły ważności i lokalne zasady węzła; ocena pakietu nie gwarantuje potwierdzenia.
Anna czeka na płatność w bitcoinie. Nadawca ustawił niską opłatę, a od tego czasu wzrósł popyt na miejsce w blokach. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. Węzeł to program, który sprawdza transakcje i bloki oraz wymienia dane z innymi uczestnikami sieci. Niektóre węzły nie przyjmują więc transakcji do swojego mempoolu, lokalnego zbioru niepotwierdzonych transakcji. Anna chciałaby dopłacić za pomocą kolejnej transakcji. Ta jednak wydaje monety, o których nadejściu odrzucający węzeł jeszcze nie wie. Package Relay pomaga pokonać tę przeszkodę: dostarcza węzłowi potrzebny kontekst, aby nie musiał oceniać wyłącznie pierwszej transakcji z niską opłatą. [1] [6]
Pierwszą transakcję nazywamy rodzicem, a tę, która wydaje jej wyjście, dzieckiem. Anna może utworzyć dziecko, jeśli potrafi spełnić warunki wydania wyjścia rodzica, czyli konkretnej kwoty dostępnej do dalszego wydania. Może choćby przesłać otrzymane monety na inny własny adres i część przeznaczyć na opłatę. To CPFP (Child Pays for Parent): wyższa opłata dziecka może pomóc w potwierdzeniu obu transakcji. Package Relay pomaga w przekazaniu i ocenie; samo nie płaci, niczego nie podpisuje i nie daje dostępu do cudzych monet. [1] [5]
Załóżmy, że rodzic ma 200 vB i opłatę 200 sat, a dziecko 100 vB i 1300 sat. vByte (vB) mierzy wirtualny rozmiar transakcji, zwykle używany przy obliczaniu opłat; sat to mała jednostka bitcoina. Razem płacą 1500 sat za 300 vB, czyli 5 sat/vB. Nie jest to zwykła średnia stawek 1 i 13 sat/vB. Zakładamy tylko te dwie jeszcze nieprzyjęte transakcje, bez innych niepotwierdzonych przodków i lokalnych korekt opłat. Węzeł nie liczy ponownie transakcji już przyjętych; znaczenie ma dokładny zestaw ocenianych zależności. [5] [3]
Wejście dziecka wskazuje wyjście rodzica. Wspólna ocena może mieć sens, ale nie pozwala pominąć brakującej historii monet. Na liście każdy uwzględniony rodzic występuje przed dzieckiem; to porządek topologiczny. Podpisy i pozostałe reguły ważności nadal są sprawdzane. Podpis cyfrowy potwierdza autoryzację płatności za pomocą klucza prywatnego, czyli tajnej wartości liczbowej, bez ujawniania tego klucza. Dwie transakcje wydające te same monety nie stają się zgodne dzięki dodatkowej opłacie. Limity liczby, rozmiaru i struktury pakietu ograniczają też pracę węzła: nie pozwalają przesłać dowolnie długiego łańcucha transakcji. [5] [3] [7]
Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Dostarczenie oznacza, że węzeł otrzymał dane. Przyjęcie oznacza dodanie transakcji do mempoolu według jego zasad. Potwierdzenie wymaga umieszczenia w bloku. Każdy węzeł ma własny mempool; sukces na jednym nie mówi, co zrobił sąsiad. W Bitcoin Core 28.0 wspólna stawka może przekroczyć zmienne minimum zatłoczonego mempoolu, ale zasadniczo nie znosi osobnego minimum przekazywania. W tej wersji istnieje wyjątek dla TRUC Transactions, specjalnie ograniczonego typu transakcji. Nawet bardzo drogie dziecko nie uratuje więc każdego rodzica. [2] [5] [8]
BIP 331 autorstwa Glorii Zhao opisuje uzgadnianie obsługi oraz komunikaty do pobierania informacji o przodkach i samych transakcji. Jest to szersza propozycja. Bitcoin Core 28.0 dokumentował ograniczone łączenie jednego rodzica z jednym dzieckiem za pomocą istniejącego protokołu sieciowego. Lokalny interfejs programistyczny RPC przyjmował też dziecko z kilkoma niezależnymi rodzicami, ale nie oznaczało to takiej samej obsługi przekazywania między węzłami. Te szczegóły dotyczą wskazanej wersji; dla innej sprawdź jej dokumentację i możliwości sąsiedniego węzła. [1] [2]
Polecenie submitpackage w Bitcoin Core 28.0 przekazuje przygotowany pakiet lokalnemu węzłowi. Oczekuje dziecka i jego niepotwierdzonych rodziców, którzy nie zależą od siebie nawzajem, z dzieckiem na końcu. Czytaj package_msg razem z poszczególnymi tx-results. Węzeł może przyjąć część pakietu: błąd nie cofa automatycznie wszystkiego, co już przyjął. Nawet ogólny sukces nie dowodzi rozprzestrzenienia w sieci ani potwierdzenia. To nie uniwersalna usługa przyspieszania płatności: wymaga poprawnie zbudowanych transakcji, a nie samych adresów. [3]
W osobnym środowisku testowym testmempoolaccept sprawdza przyjęcie bez rozgłaszania. Jeśli inna transakcja zawiedzie, może brakować allowed, ponieważ danej transakcji nie zweryfikowano w pełni. Wywołanie testowe i submitpackage nie mają też całkowicie identycznych warunków. Zapisz wersję, ustawienia, zależności, rozmiary i opłaty oraz osobno obserwuj przyjęcie przez inny węzeł. Transakcje Lightning Network z ograniczonym czasem nadal wymagają szybkiej reakcji: Package Relay samo nie usuwa przeciążenia, nieregularnych odstępów między blokami ani pinningu, czyli celowego używania zasad mempoolu do utrudniania podniesienia opłaty. [4] [2] [1]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network, vByte. Do tego hasła prowadzą również odsyłacze z CPFP (Child Pays for Parent), Gloria Zhao, Cluster Mempool, TRUC Transactions.