CPFP não altera nem substitui a transação pai não confirmada. Acrescenta uma transação filha cuja taxa pode incentivar economicamente a inclusão do pai num bloco. A filha exige que o pai tenha sido confirmado antes ou esteja antes dela no mesmo bloco. O resultado depende da taxa conjunta por byte virtual, da possibilidade de gastar a saída do pai, das regras do nó e da escolha do minerador.
CPFP mantém a transação pai com uma taxa baixa e gasta a sua saída numa transação filha com uma taxa por byte virtual mais elevada. Enquanto o pai não estiver confirmado, incluir a filha exige também o pai e os outros antepassados não confirmados necessários. O minerador pode assim receber as taxas conjuntas; pode, contudo, confirmar apenas o pai sem a filha. [Bitcoin Core v31.0 — Package mempool acceptance] [Bitcoin Developer Guide — Transactions]
Para um par simples sem outros antepassados não confirmados, some as taxas do pai e da filha em satoshis e divida pela soma dos seus tamanhos virtuais em vB. O resultado é uma taxa em sat/vB, não uma taxa total. Uma taxa mais elevada na filha só ajuda se a taxa conjunta por byte virtual for competitiva; outros antepassados necessários alteram o cálculo. A aceitação local de pacotes não volta a contar transações já aceites no mempool e pode utilizar taxas ajustadas, pelo que o seu valor nem sempre coincide com este cálculo simples do ponto de vista do minerador. [Bitcoin Core v31.0 — Package mempool acceptance]
O CPFP comum exige a possibilidade de gastar pelo menos uma saída do pai. O remetente pode utilizar a saída de troco, ou change; o destinatário pode utilizar a sua saída de pagamento. É necessário satisfazer as condições de gasto, incluindo as assinaturas exigidas. O simples facto de visualizar ou examinar a saída não confere essa autoridade. [Bitcoin Developer Guide — Transactions]
RBF cria uma substituição em conflito que partilha pelo menos uma entrada gasta com a transação original; o conjunto completo de entradas não tem de ser idêntico. CPFP mantém o pai e acrescenta uma filha. RBF exige satisfazer as condições das entradas da substituição, enquanto o CPFP comum exige as condições de gasto da saída do pai. São intervenções diferentes no grafo de transações. [Bitcoin Core v31.0 — Package mempool acceptance]
O consenso determina a validade das transações e dos blocos. A política do mempool determina a aceitação local e a propagação; as regras do minerador determinam a seleção para o bloco candidato. CPFP não altera o consenso. Um pacote economicamente vantajoso pode não cumprir as regras locais, e a sua aceitação por um nó não vincula os restantes nós nem os mineradores. [Bitcoin Core v31.0 — Package mempool acceptance] [Bitcoin Developer Guide — Transactions]
O Bitcoin Core 26 acrescentou a RPC submitpackage e o CPFP por pacote: a filha podia ajudar um pai abaixo da taxa mínima dinâmica por byte virtual do mempool, mas então não abaixo da taxa mínima de retransmissão. Esta restrição não é intemporal. O Core 31 permite, no pacote de retransmissão suportado de um pai e uma filha, um pai abaixo de minrelaytxfee, incluindo taxa zero, também para transações fora de TRUC; outros pais não confirmados da filha já têm de estar no mempool. A aceitação local continua a não garantir a mesma propagação por toda a rede. [Bitcoin Core 26.0 release notes] [Bitcoin Core 31.0 release notes]
Os limites protegem a memória, a CPU e a capacidade de transmissão. Versões anteriores do Core limitavam as quantidades e os tamanhos de antepassados e descendentes; o Core 31 substituiu esses limites do mempool por limites de clusters interligados. Os limites específicos de pacotes mantêm-se: a documentação do Core 31 indica no máximo 25 transações e um peso total de 404000 WU. Peso não é tamanho virtual. Uma topologia incorreta, um conflito ou uma violação das regras de standardness pode bloquear CPFP mesmo com uma taxa suficiente. [Bitcoin Core 31.0 release notes] [Bitcoin Core v31.0 — Package mempool acceptance]
O Bitcoin Core 31 utiliza Cluster Mempool: um cluster é formado por transações ligadas por relações pai–filha em qualquer direção. Os limites predefinidos são 64 transações e 101 kB de tamanho virtual por cluster; são configuráveis. A ordenação considera grupos minerados em conjunto, chamados chunks, e as suas taxas por byte virtual. O antigo CPFP carveout permitia uma exceção limitada ao limite de descendentes; o Core 31 removeu-o, pelo que não é possível contornar desta forma o limite do número de transações do cluster. [Bitcoin Core 31.0 release notes] [Bitcoin Core v31.0 — Mempool terminology]
Uma taxa conjunta por byte virtual competitiva pode aumentar a probabilidade de confirmação, mas não reserva espaço no próximo bloco. A procura de espaço nos blocos, a propagação das transações e a escolha do minerador em causa podem mudar. CPFP é uma ferramenta para aumentar o incentivo através das taxas, não uma garantia do prazo de confirmação. [Bitcoin Core v31.0 — Package mempool acceptance]
No Core 31, a RPC getmempoolentry mostra taxas, vsize, dependências e dados do chunk; getmempoolcluster mostra o cluster relacionado. A RPC testmempoolaccept realiza um teste local sem aceitação nem difusão; para várias transações, os antepassados têm de preceder os descendentes e as transações não podem entrar em conflito entre si nem com o mempool. A RPC submitpackage apresenta efetivamente um pacote suportado para aceitação no mempool e propagação; não é apenas um teste. Verifique os resultados de cada transação, a versão e a configuração; nenhum resultado garante a inclusão num bloco minerado. [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]
Para ter uma visão mais completa, leia este verbete junto com Replace-by-Fee (RBF), Taxas de transação, Fee Rate, Mempool, Transação, UTXO. Também há referências a este verbete em Saída de troco, Confirmação, Gasto duplo, Fee Rate.