Wyobraź sobie, że ktoś wysłał ci bitcoina z niską opłatą, a płatność wciąż nie ma potwierdzenia. Jeśli portfel obsługuje dla niej CPFP, możesz utworzyć następną transakcję, choćby na inny własny adres. Pierwotna to rodzic, a nowa — dziecko: wydaje wyjście utworzone przez rodzica, czyli kwotę z warunkami wydania. Aby zebrać opłatę dziecka, górnik potrzebuje również rodzica. Pierwotna płatność się nie zmienia; większa suma opłat może pomóc w potwierdzeniu, lecz nie gwarantuje jego terminu.
Anna czeka na 100 000 sat. Skrót sat oznacza satoshi, najmniejszą jednostkę bitcoina. Płatność jest już widoczna, ale nadawca wybrał niską opłatę i transakcja nie trafiła jeszcze do bloku. Portfel Anny pozwala wydać to niepotwierdzone wyjście. Anna tworzy z niego nową transakcję na własny adres i proponuje wyższą opłatę. Nie płaci nadawcy ani specjalnemu serwisowi: ponosi zwykłą bitcoinową opłatę transakcyjną. Górnik nie może potwierdzić nowej transakcji bez pierwotnej, ponieważ w sprawdzanym łańcuchu brakowałoby potrzebnego wyjścia. Rodzic musi być potwierdzony wcześniej albo umieszczony przed dzieckiem w tym samym bloku, wraz z innymi niezbędnymi niepotwierdzonymi przodkami. W drugą stronę to nie działa: rodzic może zostać potwierdzony bez dziecka. [3] [5]
Weźmy prosty przykład bez innych niepotwierdzonych przodków. Rodzic ma 200 vB i płaci 200 sat. Wirtualny bajt, vB, jest miarą rozmiaru wyliczaną z wagi transakcji; sat/vB mówi, ile satoshi przypada na taką jednostkę. Dziecko ma 100 vB, a Anna płaci za nie 2 800 sat. Jeśli dziecko ma tylko jedno wyjście, z otrzymanych 100 000 sat pozostanie jej 97 200 sat. Łącznie transakcje płacą 3 000 sat za 300 vB, czyli 10 sat/vB. Samo dziecko oferuje 28 sat/vB, ale górnik musi dołączyć również transakcję nadrzędną z niską opłatą. Patrzenie wyłącznie na wysoką stawkę dziecka pomija tę zależność. To przykład obliczenia, nie zalecana stawka na dziś; rzeczywiste rozmiary i potrzebną łączną opłatę sprawdza portfel. Inni niezbędni przodkowie zmieniają rachunek. Szczegół dla zaawansowanych: przy lokalnym przyjmowaniu pakietu wcześniej przyjęte transakcje nie są liczone ponownie, a węzeł — program sprawdzający i przekazujący transakcje — może korzystać ze zmodyfikowanych opłat. Pokazana tam stawka nie musi więc odpowiadać prostemu wspólnemu wyliczeniu dla górnika. Zmodyfikowana opłata jest lokalną wartością używaną przez węzeł przy podejmowaniu decyzji; nie zmienia opłaty rzeczywiście płaconej przez transakcję. [3]
CPFP nie jest przyciskiem pozwalającym każdemu przyspieszyć cudzą transakcję. Musisz móc wydać jedno z wyjść rodzica i spełnić jego warunki, w tym złożyć podpisy. Anna może to zrobić jako odbiorczyni; nadawca może mieć do dyspozycji wyjście zwracające resztę własnych środków, zwane change. Sam widok kwoty w eksploratorze lub Watch-only Wallet nie wystarcza. Watch-only Wallet służy do obserwowania płatności, ale sam nie przechowuje kluczy prywatnych potrzebnych do wydania środków. Portfel musi również obsługiwać wydawanie niepotwierdzonego wyjścia. Przed podpisaniem sprawdź, które wyjście wydajesz, dokąd trafią środki, ile pozostanie i jaka będzie łączna opłata. Przy małym wyjściu opłata może pochłonąć znaczną część jego wartości. [5]
Replace-by-Fee (RBF) tworzy nową konfliktującą transakcję, która ma zastąpić pierwotną. Wydaje co najmniej jedno wspólne wejście, ale nie musi mieć dokładnie tego samego pełnego zestawu wejść. CPFP zachowuje pierwotną płatność i jej identyfikator, dodając kolejną transakcję. W RBF trzeba spełnić warunki wejść zamiennika; w zwykłym CPFP — warunki wyjścia pierwotnej płatności. Dlatego odbiorca może skorzystać z CPFP, choć nie może podpisać zamiennika nadawcy. Wysłanie innej, niezależnej płatności z wysoką opłatą nie pomoże: dziecko musi rzeczywiście zależeć od oczekującej płatności. [3]
Wyższa wspólna stawka daje górnikowi lepszy powód, by wybrać obie transakcje, lecz nie rezerwuje miejsca w następnym bloku. Mogą nadejść lepiej opłacone transakcje albo pakiet nie dotrze do części górników. Obserwuj więc potwierdzenia pierwotnej płatności i dziecka. Informacja o przyjęciu przez węzeł nie oznacza jeszcze potwierdzenia w bloku. Jeśli nadawca zastąpi pierwotną płatność przez RBF, dziecko odwołujące się do starego wyjścia nie przyłączy się samo do innej, nowej transakcji; trzeba będzie ponownie ocenić sytuację. Utworzenie dziecka nie zmienia też niepotwierdzonego wpływu w pewną płatność. [3]
Dalsze części wyjaśniają reguły dla osób chcących pogłębić temat lub korzystać z własnego węzła. Mempool to lista oczekujących transakcji konkretnego węzła, a nie jedna kolejka całej sieci. Pakiet to grupa transakcji zgłoszonych razem. Warto oddzielić trzy decyzje: czy transakcja jest poprawna, czy węzeł ją przyjmie i czy górnik ją wybierze. Konsensus określa poprawność transakcji i bloków. Polityka mempoola określa lokalne przyjęcie i rozgłaszanie, a reguły górnika wybór do bloku kandydującego. CPFP nie zmienia konsensusu. Ekonomicznie korzystny pakiet może nie spełniać lokalnych reguł, a jego przyjęcie przez jeden węzeł nie zobowiązuje innych węzłów ani górników. [3] [5]
Sposoby wspólnego przekazywania rodzica i dziecka rozwijają się. Package CPFP oznacza ocenianie powiązanych transakcji jako pakietu. RPC to polecenie do komunikacji z węzłem; minrelaytxfee określa jego minimalną stawkę dla zwykłego przekazywania transakcji. TRUC to szczególny tryb transakcji z ograniczonymi zależnościami między przodkami i potomkami. Poniższa historia dotyczy wskazanych wersji Bitcoin Core. Bitcoin Core 26 dodał RPC submitpackage i pakietowy CPFP: potomek mógł pomóc transakcji nadrzędnej poniżej dynamicznej minimalnej stawki mempoola, lecz wtedy nie poniżej minimalnej stawki przekazywania. To ograniczenie nie jest ponadczasowe. Core 31 pozwala w obsługiwanym pakiecie przekazywania z jedną transakcją nadrzędną i jednym potomkiem także na transakcję nadrzędną poniżej minrelaytxfee, w tym z zerową opłatą, również dla transakcji spoza TRUC; inne niepotwierdzone transakcje nadrzędne potomka muszą już być w mempoolu. Lokalne przyjęcie nadal nie gwarantuje jednakowego rozgłaszania w całej sieci. [1] [2]
Węzeł nie może przyjmować dowolnie rozległych sieci zależności. Przodek jest potrzebny przed inną transakcją, a potomek wydaje wyjścia dalej w takim łańcuchu zależności. WU oznacza jednostki wagi transakcji, natomiast topologia opisuje ich połączenia. Te techniczne ograniczenia należą do polityki określonej wersji węzła. Limity chronią pamięć, zasoby procesora i przepustowość. Starszy Core ograniczał liczby i rozmiary przodków oraz potomków; Core 31 zastąpił te limity mempoola limitami połączonych klastrów. Odrębne limity pakietów pozostają: dokumentacja Core 31 podaje najwyżej 25 transakcji i całkowitą wagę 404000 WU. Waga nie jest rozmiarem wirtualnym. Niewłaściwa topologia, konflikt lub niespełnienie lokalnych reguł dotyczących akceptowanych form transakcji (standardowość) może zablokować CPFP nawet przy wystarczającej opłacie. [2] [3]
Powiązanych oczekujących transakcji nie zawsze da się oceniać ekonomicznie osobno. Cluster Mempool pozwala rozpatrywać połączone grupy. Cluster oznacza całą połączoną grupę, a mniejsza grupa przetwarzana podczas wyboru transakcji to chunk. Nie są to fragmenty już potwierdzonych bloków. Bitcoin Core 31 używa Cluster Mempool: klaster tworzą transakcje połączone relacjami transakcja nadrzędna–potomek w dowolnym kierunku. Domyślne limity to 64 transakcje i 101 kB wirtualnego rozmiaru na klaster; można je konfigurować. Kolejność uwzględnia grupy wydobywane razem, zwane chunks, oraz ich stawki opłat. Historyczny CPFP carveout pozwalał na ograniczony wyjątek od limitu potomków; Core 31 go usunął i nie można w ten sposób obejść limitu liczby transakcji klastra. [2] [4]
Polecenia z tej części nie są zamienne. Test może tylko opisać wynik; zgłoszenie pakietu może już rzeczywiście przyjąć i rozesłać podpisane transakcje. Pole vsize oznacza rozmiar wirtualny. Zwykły portfel może obsługiwać te szczegóły za użytkownika. W Core 31 RPC getmempoolentry dla transakcji w mempoolu tego węzła pokazuje opłaty, vsize, zależności i dane chunku; getmempoolcluster wyświetla powiązany klaster. RPC testmempoolaccept przeprowadza lokalny test bez przyjęcia ani rozgłoszenia; przy wielu transakcjach przodkowie muszą poprzedzać potomków, a transakcje nie mogą kolidować ani ze sobą, ani z mempoolem. RPC submitpackage rzeczywiście przedkłada obsługiwany pakiet do przyjęcia do mempoola i rozgłaszania, nie jest tylko testem. Sprawdzaj wyniki poszczególnych transakcji, wersję i konfigurację; żaden wynik nie gwarantuje uwzględnienia w wydobytym bloku. [2] [6] [7] [8] [9]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Replace-by-Fee (RBF), Transaction Fees, Fee Rate, Mempool, Transakcja, UTXO. Do tego hasła prowadzą również odsyłacze z Change Address, Potwierdzenie, Podwójne wydanie, Fee Rate.