Replace-by-Fee (RBF)

Anna enviou 20 000 sat, mas o pagamento continua pendente. A abreviatura sat significa satoshi, a menor unidade de bitcoin. A carteira oferece aumentar a taxa através de RBF. Num exemplo simples, a transação inicial gasta 50 000 sat: entrega 20 000 sat ao destinatário, paga 200 sat de taxa e devolve 29 800 sat a Anna como troco. A substituição pode continuar a pagar 20 000 sat ao destinatário, aumentar a taxa para 2 000 sat e devolver 28 000 sat a Anna. Estes valores explicam o mecanismo, não recomendam uma taxa atual. Antes de assinar, Anna verifica o endereço, o montante destinado ao destinatário e a nova taxa total. A carteira tem de conseguir assinar as entradas necessárias; poderá ser preciso voltar a ligar a carteira de hardware. A substituição tem outro txid, o identificador da transação, pelo que o destinatário poderá precisar de uma nova ligação para a acompanhar. Aumentar a taxa é diferente de criar um segundo pagamento independente com outros UTXO: ambos os pagamentos independentes poderiam ser confirmados, pagando duas vezes. [1] [2] [12]

Uma carteira pode mostrar um pagamento recebido antes da primeira confirmação. Chama-se zero-conf: o pagamento foi observado, mas ainda não consta de um bloco. Outra versão pode ser confirmada primeiro e a entrada apresentada pode desaparecer. Por isso, a indicação ‘RBF desativado’ não prova que o pagamento esteja assegurado. Entregar bens contra um pagamento não confirmado é aceitar conscientemente um risco comercial. Depois de incluída num bloco, RBF não pode reescrever a transação. Uma possível reorganização da cadeia é um risco diferente, razão pela qual se esperam mais confirmações nos pagamentos mais importantes. [1]

RBF não exige que se mantenha o destinatário original. A substituição pode aumentar a taxa e continuar a pagar à mesma pessoa, ou enviar os fundos para outro destino. Ambas as versões tentam gastar o mesmo UTXO: são tentativas em conflito, tecnicamente um Double Spend. O termo, por si só, não determina se existe fraude. Um atacante não pode, contudo, assinar livremente o pagamento de outra pessoa: a substituição tem de cumprir as condições de gasto, incluindo as assinaturas necessárias. Se a carteira oferece ‘cancelar’ através de uma substituição que paga a si próprio, está a tentar antecipar-se à transação original, não a garantir a sua anulação. [1]

RBF modifica a própria transação pendente. Child Pays for Parent (CPFP) mantém a original e cria uma nova que gasta uma das suas saídas. Para receber a taxa da nova transação, o minerador tem de incluir também a original, podendo avaliar a taxa conjunta por byte virtual. A nova transação chama-se filha e a original, mãe. Pode criá-la quem conseguir gastar a saída em causa, como o destinatário ou o remetente com o seu troco. As possibilidades dependem da carteira, das assinaturas necessárias e das relações entre transações. CPFP não substitui o pagamento original nem garante um prazo de confirmação. [2]

O Mempool não é uma fila única partilhada por todo o Bitcoin. Cada nó mantém a sua lista e as suas regras para aceitar e retransmitir transações pendentes. RBF pertence a essa política local, não ao consenso que determina a validade dos blocos. Um minerador pode, por isso, escolher uma transação em conflito válida que outro nó não guardava. Um Full Node verifica depois todo o bloco pelas regras do Bitcoin; a preferência anterior do seu mempool não determina o resultado. A aceitação de uma substituição por um nó não promete aceitação em todo o lado. [1] [6]

Para o utilizador, importam dois números diferentes: o custo total e o valor oferecido por unidade de tamanho da transação. Para um tamanho hipotético de 200 vB, 200 sat equivalem a 1 sat/vB; com o mesmo tamanho, 2 000 sat equivalem a 10 sat/vB. O byte virtual, vB, é uma unidade de tamanho derivada do peso da transação. Reconstruí-la pode alterar o tamanho, pelo que a carteira tem de recalcular também a taxa por byte virtual. A taxa total é um montante em satoshis; a taxa por byte virtual exprime-se em sat/vB. Numa substituição individual no Core 30, a taxa tem de cobrir a soma das taxas de todas as transações expulsas e ainda o custo calculado segundo incrementalrelayfee para o tamanho da substituição. A sua taxa por byte virtual tem de superar as das transações diretamente em conflito. Uma taxa por byte superior, por si só, ou o simples acréscimo de satoshis não basta; o Core 30 tem incrementalrelayfee predefinida de 0,1 sat/vB, mas a configuração do nó pode ser diferente. [2] [9]

Já pode haver outro pagamento pendente dependente do primeiro: alguém gasta uma saída da primeira transação, ainda não confirmada. Essas transações seguintes são chamadas descendentes. Se a transação-mãe desaparece, também elas deixam de poder ser utilizadas no mempool; o nó deve, por isso, considerar todo o grupo afetado. Substituir uma transação-mãe pode também expulsar do mempool os descendentes que gastam as suas saídas. Portanto, nem sempre se trata de comparar apenas duas transações. Numa substituição individual, o Core 30 limita a 100 a soma das contagens de descendentes das transações diretamente em conflito, incluindo essas próprias transações; este cálculo pode contar descendentes comuns várias vezes. As taxas e as relações no pacote podem, por isso, influenciar o sucesso da substituição. [2]

O nó também tem de impedir que alguém o sobrecarregue com o recálculo constante de substituições. Trata-se de proteção contra DoS, um ataque à disponibilidade do serviço. Um UTXO é uma saída ainda não gasta de uma transação anterior; uma entrada da nova transação faz referência a essa saída. As regras seguintes descrevem especificamente o Bitcoin Core 30, não uma lei imutável do Bitcoin. A política do Bitcoin Core 30 para uma única transação de substituição também limita novas entradas não confirmadas e o número de transações expulsas. A substituição tem de cumprir as regras locais sobre formas de transação aceites (standardness), além das regras de propagação e validade, não apenas gastar o mesmo UTXO. Os limites protegem a capacidade de processamento, a memória e a capacidade de transmissão; as regras de substituição de pacotes devem ser avaliadas separadamente consoante a versão do nó. O Core 31 mudou essa política com o Cluster Mempool, que avalia em grupos as transações pendentes ligadas entre si. Uma substituição precisa melhorar o chamado feerate diagram, que compara as taxas acumuladas com o espaço ocupado progressivamente. Outras condições continuam valendo, como uma taxa total suficiente e o valor adicional para propagar a substituição. Por isso, não aplique automaticamente os limites do Core 30 descritos acima a versões mais novas: confira as regras do seu nó. [2] [13]

Porque algumas carteiras ainda apresentam uma opção RBF? Os nós que aplicavam a política original opt-in RBF exigiam um sinal prévio a permitir a substituição. O Bitcoin Core 24 tornou full-RBF configurável sem essa condição, o Core 28 ativou-o por predefinição e o Core 29 removeu a opção mempoolfullrbf. Os detalhes do BIP125 abaixo explicam a sinalização original, não uma regra universal de todos os nós atuais. O BIP125 descreve um sinal opt-in explícito quando pelo menos uma entrada tem um valor nSequence inferior a 0xfffffffe, bem como a herança do sinal de um antepassado não confirmado. Trata-se de uma política histórica, não de uma condição de consenso. Full-RBF permite avaliar uma substituição mesmo sem esse sinal; a sua ausência não garante que um pagamento não possa ser substituído. [1] [3] [4] [5] [6]

Esta secção destina-se a quem opera o seu próprio nó. As RPC são comandos para consultar ou controlar o software; não é preciso conhecê-las para usar o botão de aumentar a taxa. A RPC getmempoolentry mostra o estado de uma transação que esteja no mempool desse nó; testmempoolaccept testa uma única transação candidata de substituição assinada face ao mempool atual e às regras do próprio nó, sem a difundir. O resultado não promete aceitação por outros nós nem inclusão num bloco minerado. O Core 28 ativou full-RBF por predefinição através de mempoolfullrbf; o Core 29 removeu essa opção. A RPC getmempoolinfo apresenta os parâmetros de taxas, mas o campo fullrbf está marcado como obsoleto no Core 30; verifique sempre a versão e a configuração concretas. [5] [6] [7] [8] [10] [11]