CPFP (Child Pays for Parent)

Anna espera receber 100 000 sat. A abreviação sat significa satoshi, a menor unidade de bitcoin. Ela já vê o pagamento, mas o remetente escolheu uma taxa baixa e a transação ainda não entrou num bloco. Sua carteira permite gastar essa saída não confirmada. Anna cria com ela uma nova transação para um endereço próprio, oferecendo uma taxa maior. Ela não está pagando ao remetente nem a um serviço especial: paga uma taxa normal de transação Bitcoin. Um minerador não pode confirmar a nova transação sem a original, pois a saída que ela gasta não existiria na cadeia em validação. A mãe precisa ter sido confirmada antes ou aparecer antes da filha no mesmo bloco, junto com outros ancestrais não confirmados que sejam necessários. O contrário não é exigido: a mãe pode ser confirmada sem a filha. [3] [5]

Vamos usar um exemplo simples, sem outros ancestrais não confirmados. A mãe tem 200 vB e paga 200 sat. O byte virtual, vB, mede um tamanho derivado do peso da transação; sat/vB indica quantos satoshis são oferecidos por essa unidade. A filha tem 100 vB e Anna paga 2 800 sat por ela. Se a filha tiver apenas uma saída, dos 100 000 sat recebidos restarão 97 200 sat. Juntas, as transações pagam 3 000 sat por 300 vB: 10 sat/vB. A filha sozinha oferece 28 sat/vB, mas o minerador também precisa incluir a mãe, cuja taxa é baixa. Olhar apenas para o número alto da filha ignora essa dependência. É um cálculo ilustrativo, não uma recomendação de taxa para hoje; a carteira verifica os tamanhos reais e a taxa total necessária. Outros ancestrais necessários mudam a conta. Um detalhe avançado: na aceitação local de um pacote, transações já aceitas não são contadas novamente e o nó — programa que verifica e retransmite transações — pode usar taxas modificadas. O valor por unidade mostrado nesse contexto pode não coincidir com o cálculo conjunto simples para um minerador. A taxa modificada é um valor local usado nas decisões do nó; ela não altera a taxa realmente paga pela transação. [3]

CPFP não é um botão que permite a qualquer pessoa acelerar uma transação alheia. É preciso poder gastar uma saída da mãe e cumprir suas condições, incluindo as assinaturas. Anna pode fazer isso como destinatária; o remetente talvez possa usar uma saída que devolve seus fundos restantes, chamada change. Apenas ver um valor num explorador ou numa Watch-only Wallet não basta. Uma Watch-only Wallet acompanha pagamentos, mas não guarda as chaves privadas necessárias para gastar os fundos. A carteira também precisa permitir o gasto da saída não confirmada. Antes de assinar, confira qual saída está gastando, para onde o dinheiro irá, quanto restará e qual será a taxa total. Se a saída for pequena, a taxa pode consumir uma parte considerável de seu valor. [5]

Replace-by-Fee (RBF) cria uma nova transação conflitante para substituir a original. Ela gasta pelo menos uma mesma entrada, mas não precisa repetir exatamente todo o conjunto de entradas. CPFP mantém o pagamento original e seu identificador, acrescentando outra transação. Para RBF, é preciso cumprir as condições das entradas da substituta; para um CPFP comum, as de uma saída do pagamento original. Por isso, o destinatário pode conseguir usar CPFP mesmo sem poder assinar a substituição do remetente. Enviar outro pagamento independente com uma taxa alta não ajuda: a filha precisa realmente depender do pagamento pendente. [3]

Uma taxa conjunta maior por unidade dá ao minerador um motivo melhor para incluir as duas transações, mas não reserva espaço no próximo bloco. Podem chegar transações que pagam mais, ou alguns mineradores podem não receber o pacote. Acompanhe, portanto, as confirmações do pagamento original e da filha. A informação de que um nó aceitou a transação ainda não é uma confirmação em bloco. Se o remetente substituir o pagamento original por RBF, a filha que aponta para a saída antiga não pode se ligar sozinha à nova transação, que é diferente; será necessário reavaliar a situação. Criar uma filha também não transforma um recebimento não confirmado em pagamento garantido. [3]

As próximas seções aprofundam as regras e o uso de um nó próprio. Mempool é a lista de transações pendentes de um nó específico, não uma fila única de toda a rede. Um pacote é um grupo de transações apresentado em conjunto. É importante separar três decisões: se a transação é válida, se o nó a aceita e se um minerador a escolhe. 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 demais nós nem os mineradores. [3] [5]

As formas de transmitir mãe e filha juntas evoluem. Package CPFP significa avaliar transações relacionadas como um pacote. Um RPC é um comando para interagir com o nó; minrelaytxfee identifica sua taxa mínima por unidade para a propagação comum. TRUC é um regime especial de transações com relações limitadas entre ancestrais e descendentes. A história abaixo se refere às versões indicadas de Bitcoin Core. O Bitcoin Core 26 acrescentou a RPC submitpackage e o CPFP por pacote: a filha podia ajudar uma mãe com taxa por byte virtual abaixo do mínimo dinâmico do mempool, mas então não abaixo da taxa mínima de retransmissão. Essa restrição não é permanente. O Core 31 permite, no pacote de retransmissão suportado de uma mãe e uma filha, uma mãe com taxa por byte virtual abaixo de minrelaytxfee, incluindo taxa zero, também para transações fora de TRUC; as outras transações-mãe não confirmadas da filha já precisam estar no mempool. A aceitação local continua sem garantir a mesma propagação por toda a rede. [1] [2]

Um nó não pode aceitar redes de dependências de qualquer tamanho. Um ancestral é necessário antes de outra transação; um descendente gasta saídas mais adiante nessa cadeia de dependências. WU significa unidades de peso da transação, e topologia descreve como elas se conectam. Esses limites técnicos pertencem à política da versão correspondente do nó. Os limites protegem a memória, os recursos do processador e a capacidade de transmissão. Versões anteriores do Core limitavam as quantidades e os tamanhos de ancestrais e descendentes; o Core 31 substituiu esses limites do mempool por limites de clusters interligados. Os limites específicos de pacotes permanecem: 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 o descumprimento das regras locais sobre formas de transação aceitas (standardness) pode bloquear CPFP mesmo com uma taxa suficiente. [2] [3]

Transações pendentes ligadas entre si nem sempre podem ser avaliadas economicamente de forma isolada. Cluster Mempool permite ao nó considerar grupos conectados. Um cluster é o grupo conectado inteiro; um grupo menor processado durante a seleção de transações é um chunk. Não são pedaços de blocos já confirmados. O Bitcoin Core 31 utiliza Cluster Mempool: um cluster é formado por transações ligadas por relações mãe–filha em qualquer direção. Os limites padrão 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 o removeu, portanto não é possível contornar desta forma o limite do número de transações do cluster. [2] [4]

Os comandos desta seção não são intercambiáveis. Um teste pode apenas descrever um resultado; enviar um pacote pode realmente aceitar e propagar transações assinadas. O campo vsize informa o tamanho virtual. Uma carteira comum pode cuidar desses detalhes pelo usuário. No Core 31, a RPC getmempoolentry mostra, para uma transação presente no mempool desse nó, 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 ancestrais devem preceder os descendentes e as transações não podem entrar em conflito entre si nem com o mempool. A RPC submitpackage apresenta de fato 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 em um bloco minerado. [2] [6] [7] [8] [9]