Package Relay permite que os nós do Bitcoin transmitam e avaliem juntas transações relacionadas ainda não confirmadas. Isso ajuda quando a primeira oferece uma taxa insuficiente e outra, que gasta sua saída, acrescenta o necessário para ambas. A validade e as regras locais do nó continuam obrigatórias; avaliar um pacote não garante confirmação.
Anna espera um pagamento em bitcoin. O remetente escolheu uma taxa baixa e, desde então, aumentou a procura por espaço nos blocos. Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. Um nó é um programa que verifica transações e blocos e se comunica com outros participantes da rede. Alguns nós recusam a transação em seu mempool, o conjunto local de transações não confirmadas. Anna gostaria de acrescentar uma taxa por meio de outra transação. Mas esta gasta moedas cuja chegada o nó que rejeitou a primeira ainda desconhece. Package Relay ajuda a superar essa dificuldade: leva o contexto necessário ao nó para que ele não avalie apenas a primeira transação, de taxa baixa, isoladamente. [1] [6]
A primeira transação é chamada de pai; a que gasta sua saída, de filho. Anna pode criar um filho se conseguir cumprir as condições de gasto de uma saída do pai: um valor específico disponível para gastar. Ela poderia enviar as moedas recebidas para outro endereço próprio, destinando uma parte à taxa. Isso é CPFP (Child Pays for Parent): a taxa maior do filho pode favorecer a confirmação de ambos. Package Relay ajuda na entrega e na avaliação; não paga a taxa, não assina nada e não dá acesso às moedas de outra pessoa. [1] [5]
Suponha um pai de 200 vB com taxa de 200 sat e um filho de 100 vB com 1300 sat. O vByte (vB) mede o tamanho virtual da transação, normalmente usado no cálculo de taxas; sat é uma pequena unidade de bitcoin. Juntos pagam 1500 sat por 300 vB, ou 5 sat/vB. Não é a média simples das taxas individuais de 1 e 13 sat/vB. Consideramos somente essas duas transações ainda não aceitas, sem outros ancestrais não confirmados nem ajustes locais de taxas. O nó não conta novamente transações já aceitas; importa o conjunto exato de dependências avaliado. [5] [3]
Uma entrada do filho aponta para uma saída do pai. Avaliá-los juntos pode fazer sentido, mas não permite ignorar o histórico que falta. A lista coloca cada pai incluído antes do filho; isso se chama ordem topológica. Assinaturas e todas as demais regras de validade continuam sendo verificadas. Uma assinatura digital comprova a autorização de um pagamento por meio de uma chave privada, um valor numérico secreto, sem revelar essa chave. Duas transações que gastam as mesmas moedas não se tornam compatíveis por uma taxa adicional. Limites de quantidade, tamanho e estrutura do pacote também restringem o trabalho do nó: não autorizam uma cadeia arbitrariamente longa de transações. [5] [3] [7]
Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. Entrega significa que o nó recebeu os dados. Aceitação significa que colocou as transações no mempool conforme suas regras. Confirmação exige inclusão em um bloco. Cada nó tem seu próprio mempool; o sucesso em um não mostra o que o vizinho fez. No Bitcoin Core 28.0, a taxa conjunta pode superar o mínimo variável de um mempool congestionado, mas geralmente não elimina o mínimo separado de retransmissão. Essa versão tem uma exceção para TRUC Transactions, um tipo sujeito a restrições especiais. Portanto, um filho que pague muito não resgata qualquer pai. [2] [5] [8]
O BIP 331, de Gloria Zhao, descreve a negociação de suporte e mensagens para solicitar informações sobre ancestrais e as próprias transações. É uma proposta mais ampla. O Bitcoin Core 28.0 documentou o pareamento limitado de um pai com um filho pelo protocolo de rede existente. Sua interface local de programação RPC também aceitava um filho com vários pais independentes, mas isso não implicava suporte equivalente à retransmissão entre nós. Esses detalhes valem para essa versão; em outra, confira a documentação e as capacidades do nó vizinho. [1] [2]
O comando submitpackage do Bitcoin Core 28.0 entrega um pacote preparado ao nó local. Espera um filho e seus pais não confirmados, sem dependências entre esses pais, com o filho no final. Leia package_msg junto com cada tx-results. O nó pode aceitar parte do pacote: um erro não desfaz automaticamente tudo o que já foi aceito. Mesmo um sucesso geral não prova propagação pela rede nem confirmação. Não é um serviço genérico de aceleração de pagamentos: exige transações corretamente construídas, não apenas endereços. [3]
Em um ambiente de testes separado, testmempoolaccept verifica a aceitação sem transmitir. Se outra transação falhar, allowed pode estar ausente porque a transação em questão não foi totalmente validada. O teste e submitpackage também não têm condições exatamente iguais. Registre versão, configurações, dependências, tamanhos e taxas, e observe separadamente a aceitação em outro nó. Transações de Lightning Network com prazo continuam exigindo uma reação a tempo: Package Relay sozinho não elimina congestionamento, intervalos irregulares entre blocos nem pinning, o uso deliberado das regras do mempool para dificultar o aumento da taxa. [4] [2] [1]
Para ter uma visão mais completa, leia este verbete junto com Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network, vByte. Também há referências a este verbete em CPFP (Child Pays for Parent), Gloria Zhao, Cluster Mempool, TRUC Transactions.