CPFP не змінює і не замінює непідтверджену батьківську транзакцію. Він додає дочірню, комісія якої може економічно підтримати включення батьківської до блоку. Батьківська має бути підтверджена раніше або розміщена перед дочірньою в тому самому блоці. Результат залежить від спільної ставки, можливості витратити батьківський вихід, правил вузла та вибору майнера.
CPFP зберігає батьківську транзакцію з низькою комісією та витрачає її вихід у дочірній із вищою ставкою комісії. Доки батьківська не підтверджена, включення дочірньої потребує також батьківської та інших необхідних непідтверджених предків. Майнер може отримати їхні спільні комісії; саму батьківську можна підтвердити й без дочірньої. [Bitcoin Core v31.0 — Package mempool acceptance] [Bitcoin Developer Guide — Transactions]
Для простої пари без інших непідтверджених предків додай комісії батьківської та дочірньої в satoshi і поділи на суму їхніх віртуальних розмірів у vB. Результат — ставка в sat/vB, а не загальна комісія. Вища комісія дочірньої допомагає лише за конкурентної спільної ставки; інші необхідні предки змінюють розрахунок. Локальне прийняття пакетів не враховує повторно транзакції, вже прийняті до mempool, і може використовувати модифіковані комісії, тому показана ставка не завжди збігається з цим простим розрахунком для майнінгу. [Bitcoin Core v31.0 — Package mempool acceptance]
Звичайний CPFP потребує можливості витратити хоча б один батьківський вихід. Відправник може використати вихід решти, change; одержувач — свій платіжний вихід. Треба виконати умови витрачання, включно з необхідними підписами. Сам перегляд або перевірка виходу не надає таких повноважень. [Bitcoin Developer Guide — Transactions]
RBF створює конфліктну заміну, що має з оригіналом щонайменше один спільний витрачуваний вхід; увесь набір входів не мусить бути однаковим. CPFP зберігає батьківську і додає дочірню. Для RBF треба виконати умови входів заміни, для звичайного CPFP — умови витрачання батьківського виходу. Це різні зміни графа транзакцій. [Bitcoin Core v31.0 — Package mempool acceptance]
Консенсус визначає чинність транзакцій і блоків. Політика mempool визначає локальне прийняття та ретрансляцію; правила майнера — відбір до кандидатного блоку. CPFP не змінює консенсус. Економічно вигідний пакет може не відповідати місцевим правилам, а прийняття одним вузлом не зобов’язує інших вузлів чи майнерів. [Bitcoin Core v31.0 — Package mempool acceptance] [Bitcoin Developer Guide — Transactions]
Bitcoin Core 26 додав RPC submitpackage і package CPFP: дочірня могла допомогти батьківській зі ставкою нижче динамічного мінімуму mempool, але тоді не нижче мінімальної ставки ретрансляції. Це обмеження не є незмінним. Core 31 дозволяє в підтримуваній ретрансляції пакета з однією батьківською та однією дочірньою батьківську нижче minrelaytxfee, навіть із нульовою комісією, також поза TRUC; інші непідтверджені батьківські транзакції дочірньої вже мають бути в mempool. Локальне прийняття й далі не гарантує однакового поширення всією мережею. [Bitcoin Core 26.0 release notes] [Bitcoin Core 31.0 release notes]
Ліміти захищають пам’ять, CPU і пропускну здатність. Старі версії Core обмежували кількість і розміри предків та нащадків; Core 31 замінив ці ліміти mempool лімітами зв’язаних кластерів. Окремі пакетні ліміти залишилися: документація Core 31 вказує максимум 25 транзакцій і загальну вагу 404000 WU. Вага — не віртуальний розмір. Неправильна топологія, конфлікт чи порушення стандартності можуть заблокувати CPFP навіть за достатньої комісії. [Bitcoin Core 31.0 release notes] [Bitcoin Core v31.0 — Package mempool acceptance]
Bitcoin Core 31 використовує Cluster Mempool: кластер складається з транзакцій, пов’язаних відносинами батьківська–дочірня в будь-якому напрямку. Типові ліміти — 64 транзакції та 101 kB віртуального розміру на кластер; їх можна налаштувати. Порядок враховує групи, які майнять разом, — chunks — та їхні ставки. Історичний CPFP carveout дозволяв обмежений виняток із ліміту нащадків; Core 31 його скасував, і так обійти ліміт кількості транзакцій кластера не можна. [Bitcoin Core 31.0 release notes] [Bitcoin Core v31.0 — Mempool terminology]
Конкурентна спільна ставка може підвищити шанс підтвердження, але не резервує місця в наступному блоці. Попит на місце в блоках, поширення транзакцій і вибір окремого майнера можуть змінюватися. CPFP посилює комісійний стимул, а не гарантує час підтвердження. [Bitcoin Core v31.0 — Package mempool acceptance]
У Core 31 RPC getmempoolentry показує комісії, vsize, залежності та дані chunk; getmempoolcluster показує пов’язаний кластер. RPC testmempoolaccept виконує локальну перевірку без прийняття й розсилання; для кількох транзакцій предки мають передувати нащадкам, а транзакції не повинні конфліктувати між собою чи з mempool. RPC submitpackage справді подає підтримуваний пакет для прийняття до mempool і поширення, а не лише тестує. Перевіряй результати окремих транзакцій, версію та конфігурацію; жоден результат не гарантує видобутку. [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]
Для повної картини прочитайте також Replace-by-Fee (RBF), Комісії за транзакції, Fee Rate, Mempool, Транзакція, UTXO. На цю статтю також посилаються Вихід решти, Підтвердження, Подвійна витрата, Fee Rate.