CPFP nie zmienia ani nie zastępuje niepotwierdzonej transakcji nadrzędnej. Dodaje potomka, którego opłata może ekonomicznie wspierać włączenie transakcji nadrzędnej do bloku. Potomek wymaga, aby transakcja nadrzędna była potwierdzona wcześniej albo znajdowała się przed nim w tym samym bloku. Wynik zależy od wspólnej stawki opłat, możliwości wydania wyjścia transakcji nadrzędnej, reguł węzła i wyboru górnika.
CPFP zachowuje transakcję nadrzędną z niską opłatą i wydaje jej wyjście w potomku z wyższą stawką opłat. Dopóki transakcja nadrzędna jest niepotwierdzona, włączenie potomka wymaga także jej oraz innych potrzebnych niepotwierdzonych przodków. Górnik może w ten sposób uzyskać ich wspólne opłaty; samą transakcję nadrzędną może jednak potwierdzić również bez potomka. [Bitcoin Core v31.0 — Package mempool acceptance] [Bitcoin Developer Guide — Transactions]
Dla prostej pary bez innych niepotwierdzonych przodków zsumuj opłaty transakcji nadrzędnej i potomka w satoshi, a następnie podziel przez sumę ich wirtualnych rozmiarów w vB. Wynikiem jest stawka w sat/vB, a nie łączna opłata. Wyższa opłata potomka pomaga tylko przy konkurencyjnej wspólnej stawce; inni wymagani przodkowie zmieniają obliczenie. Lokalna akceptacja pakietów nie wlicza ponownie transakcji już przyjętych do mempoola i może używać zmodyfikowanych opłat, więc jej wynik nie zawsze odpowiada temu prostemu obliczeniu z perspektywy górnika. [Bitcoin Core v31.0 — Package mempool acceptance]
Zwykły CPFP wymaga możliwości wydania co najmniej jednego wyjścia transakcji nadrzędnej. Nadawca może użyć wyjścia reszty, czyli change, a odbiorca swojego wyjścia płatności. Trzeba spełnić warunki wydania, w tym wymagane podpisy. Samo wyświetlenie lub sprawdzenie wyjścia nie daje takiego uprawnienia. [Bitcoin Developer Guide — Transactions]
RBF tworzy kolidujący zamiennik, który współdzieli co najmniej jedno wydawane wejście z pierwotną transakcją; cały zestaw wejść nie musi być identyczny. CPFP zachowuje transakcję nadrzędną i dodaje potomka. RBF wymaga spełnienia warunków wejść zamiennika, a zwykły CPFP warunków wydania wyjścia transakcji nadrzędnej. Są to odmienne zmiany grafu transakcji. [Bitcoin Core v31.0 — Package mempool acceptance]
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. [Bitcoin Core v31.0 — Package mempool acceptance] [Bitcoin Developer Guide — Transactions]
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. [Bitcoin Core 26.0 release notes] [Bitcoin Core 31.0 release notes]
Limity chronią pamięć, CPU 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 naruszenie standardowości może zablokować CPFP nawet przy wystarczającej opłacie. [Bitcoin Core 31.0 release notes] [Bitcoin Core v31.0 — Package mempool acceptance]
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. [Bitcoin Core 31.0 release notes] [Bitcoin Core v31.0 — Mempool terminology]
Konkurencyjna wspólna stawka może zwiększyć szansę potwierdzenia, lecz nie rezerwuje miejsca w następnym bloku. Popyt na miejsce w blokach, rozgłaszanie transakcji i wybór konkretnego górnika mogą się zmieniać. CPFP jest narzędziem zwiększającym zachętę w postaci opłat, a nie gwarancją czasu potwierdzenia. [Bitcoin Core v31.0 — Package mempool acceptance]
W Core 31 RPC getmempoolentry 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. [Bitcoin Core 31.0 release notes] [Bitcoin Core 31.0 — getmempoolentry RPC] [Bitcoin Core 31.0 — testmempoolaccept RPC] [Bitcoin Core 31.0 — submitpackage RPC] [Bitcoin Core v31.0 — Mempool RPC implementation]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Replace-by-Fee (RBF), Opłaty transakcyjne, Fee Rate, Mempool, Transakcja, UTXO. Do tego hasła prowadzą również odsyłacze z Wyjście reszty, Potwierdzenie, Podwójne wydanie, Fee Rate.