Fazer RBF no Bitcoin Core significa substituir uma transação ainda não confirmada por uma nova versão que reaproveita as mesmas entradas e paga uma taxa maior, usando comandos como sendtoaddress com o opt-in habilitado e bumpfee no bitcoin-cli. Esse processo acontece inteiramente na mempool, que é a área de espera local de cada node, e nunca altera blocos que já foram confirmados. Neste guia técnico você vai reproduzir um Replace-By-Fee do zero em regtest, observar a transação original ser descartada da mempool e entender na prática por que pagamentos com zero confirmações não são considerados finais.
Este conteúdo foi escrito pelo professor Rafael Penna, colaborador da Bitcoin Coders, e é voltado para programadores e desenvolvedores. Se você ainda está chegando ao tema e quer uma visão introdutória, com a explicação do conceito e a lista de carteiras que suportam o recurso, vale começar pelo nosso guia sobre o que é e como usar o Replace-By-Fee. Aqui o foco é diferente, porque vamos direto para a linha de comando e para o comportamento da mempool, no mesmo estilo prático dos tutoriais de criação de transações no Bitcoin Core e de SegWit em Signet.
O que você vai aprender neste artigo
- Como iniciar um node em regtest e preparar moedas utilizáveis com
generatetoaddress. - Como criar uma transação substituível com opt-in RBF e inspecionar o campo
bip125-replaceablecomgetmempoolentry, tema que se conecta com a anatomia das transações e o modelo UTXO. - Como executar o replacement com o comando
bumpfeee observar a troca acontecendo na mempool comgetrawmempool. - Por que pagamentos com zero confirmações são arriscados e como um lojista pode ser enganado nesse cenário.
- A diferença entre o opt-in RBF da BIP125 e o Full RBF ativado por
-mempoolfullrbf=1. - Por que o RBF mexe apenas na seleção de transações da mempool e nunca no consenso, assunto que dialoga com as taxas de transação no Bitcoin Core.
O RBF (Replace-By-Fee) é um mecanismo que permite substituir uma transação ainda não confirmada por outra que paga uma taxa maior.
Na prática:
- duas transações tentam gastar o mesmo UTXO
- apenas uma delas poderá ser confirmada
- nodes podem preferir aquela que paga mais fee
Isso mostra um conceito importante:
mempool não é consenso.
Antes da confirmação, a transação ainda está competindo por espaço nos blocos.
Experimento com bitcoin-cli
Vamos iniciar um node em regtest:
bitcoind -regtest -daemon \\ -fallbackfee=0.0001 \\ -txindex=1
Agora criamos um endereço para mineração:
ADDR=$(bitcoin-cli -datadir="." getnewaddress)
Mineramos 101 blocos para gerar moedas utilizáveis:
bitcoin-cli -datadir="." generatetoaddress 101 $ADDR
Criamos dois endereços de destino:
DEST1=$(bitcoin-cli -datadir="." getnewaddress) DEST2=$(bitcoin-cli -datadir="." getnewaddress)
Criando uma transação substituível
Agora vamos enviar uma transação marcando ela explicitamente como substituível:
TXID=$(bitcoin-cli -datadir="." sendtoaddress $DEST1 1 "" "" true)
O último parâmetro (true) habilita o opt-in RBF.
Vamos verificar como a mempool enxerga essa transação:
bitcoin-cli -datadir="." getmempoolentry $TXID
Entre as informações retornadas, veremos:
"bip125-replaceable": true
Ou seja: o próprio node reconhece que essa transação pode ser substituída.
Observando a mempool
A transação ainda não está em bloco. Ela existe apenas na mempool:
bitcoin-cli -datadir="." getrawmempool [ "7f6c9a69639613b629951cda8ee8919825febf74865d475efb7d80392ec4a9cf" ]
Também podemos verificar:
bitcoin-cli -datadir="." gettransaction $TXID
Resultado:
{
"amount": 0.00000000,
"fee": -0.00000208,
"confirmations": 0,
...
}
Isso significa que ela ainda não faz parte da blockchain.
Fazendo o Replace-By-Fee na prática
Agora vem a parte principal. Vamos aumentar a taxa da transação usando:
bitcoin-cli -datadir="." bumpfee $TXID
{
"txid": "f914a40b545d1fa8d8fc029b007108f60fd7ccdacb5c04f1d16294b043e285f0",
"origfee": 0.00000208,
"fee": 0.00001249,
"errors": [
]
}
O Bitcoin Core irá:
- criar uma nova transação
- reutilizar as mesmas entradas
- aumentar a taxa
- substituir a antiga na mempool
Vamos observar novamente:
bitcoin-cli -datadir="." getrawmempool [ "f914a40b545d1fa8d8fc029b007108f60fd7ccdacb5c04f1d16294b043e285f0" ]
A transação original desaparece da mempool e a nova passa a ocupar seu lugar.
Nada mudou na blockchain. A única coisa que mudou foi:
- qual transação os nodes preferem minerar.
O risco do 0-conf
Esse experimento mostra por que pagamentos sem confirmação envolvem risco.
Imagine:
- um lojista aceita um pagamento imediatamente
- a transação ainda está sem confirmações
- o usuário faz RBF com uma taxa maior
- a nova transação envia os fundos para outro destino
Se a nova versão for minerada primeiro, a original desaparece definitivamente.
Por isso, transações com 0 confirmations ainda não são finais.
Confirmando a transação
Agora vamos minerar um bloco:
bitcoin-cli -datadir="." generatetoaddress 1 $ADDR
Depois verificamos a nova transação:
bitcoin-cli -datadir="." gettransaction "f914a40b545d1fa8d8fc029b007108f60fd7ccdacb5c04f1d16294b043e285f0"
Agora veremos algo como:
{
"amount": 0.00000000,
"fee": -0.00001249,
"confirmations": 1,
...
}
Neste ponto:
- a transação entrou em bloco
- virou parte da blockchain
- substituir ela se torna muito mais difícil
RBF atua na mempool, não no consenso
O ponto mais importante talvez seja este:
| Mempool | Blockchain |
|---|---|
| Local ao node | Compartilhada pela rede |
| Pode mudar rapidamente | Muito mais estável |
| Não possui consenso global | Define o consenso |
| RBF atua aqui | RBF não altera blocos confirmados |
O RBF não “desfaz” blocos. Ele apenas altera qual transação os nodes pretendem minerar antes da confirmação.
Full RBF
Tradicionalmente, o Bitcoin usa o chamado opt-in RBF, definido pela BIP125.
Nesse modelo, apenas transações marcadas como substituíveis podem sofrer replacement.
Mas alguns nodes hoje utilizam Full RBF:
-mempoolfullrbf=1
Nesse modo, qualquer transação conflitante com taxa maior pode ser aceita na mempool.
Esse tema continua sendo debatido no ecossistema Bitcoin, principalmente em relação a pagamentos instantâneos e políticas de mempool.
Por fim, uma transação sem confirmação ainda está em negociação com a rede. O RBF deixa isso explícito: antes do bloco, a mempool continua sendo um ambiente local, dinâmico e competitivo. É somente após as confirmações que uma transação começa a ganhar estabilidade probabilística dentro do consenso do Bitcoin.
Conclusão
Reproduzir o RBF na linha de comando deixa claro algo que muita documentação só descreve por cima, que é o fato de uma transação sem confirmação ser apenas uma proposta competindo por espaço dentro de um ambiente local e dinâmico chamado mempool. Para um desenvolvedor, dominar esse comportamento é o que permite construir carteiras, lojas e serviços que tratam o risco de zero confirmações com a seriedade que ele merece, em vez de assumir que todo pagamento recebido já está garantido.
Se você quer continuar nesse nível de profundidade, vale seguir pelos nossos guias sobre como estimar e ajustar taxas no Bitcoin Core, sobre a anatomia das transações e o modelo UTXO e sobre as novidades do Bitcoin Core na prática.
Para montar o ambiente do zero, o tutorial de instalação do Bitcoin Core com bitcoind e bitcoin-cli é o ponto de partida ideal, e quem quiser entender a outra ponta da propagação na rede pode ler o material sobre o Erlay.
Todo esse caminho faz parte da formação técnica gratuita da Bitcoin Coders.
Para quem quer ir direto à fonte oficial, o comportamento de RBF no Bitcoin Core que demonstramos aqui é definido pela especificação BIP125, mantida no repositório oficial das BIPs do Bitcoin, que descreve em detalhes as regras do opt-in RBF e as condições que um node aplica para aceitar uma transação como substituível.
Perguntas frequentes sobre o RBF no Bitcoin Core
Como fazer RBF no Bitcoin Core com bitcoin-cli
No Bitcoin Core você cria uma transação substituível e depois aumenta a taxa dela com o comando bumpfee no bitcoin-cli. O node gera uma nova transação que reutiliza as mesmas entradas, paga uma taxa maior e substitui a antiga na mempool. Em um ambiente de testes como o regtest, você pode acompanhar todo esse fluxo com getrawmempool e gettransaction, observando a transação original desaparecer e a nova ocupar o seu lugar antes de qualquer confirmação.
O que faz o comando bumpfee?
O bumpfee é o comando do Bitcoin Core que executa o Replace-By-Fee de forma automática. Ele cria uma nova versão da transação reaproveitando as mesmas entradas, aumenta a taxa paga aos mineradores e substitui a transação anterior na mempool. O retorno do comando mostra o txid da nova transação, a taxa original e a nova taxa, o que permite confirmar exatamente quanto a fee foi elevada.
Como criar uma transação substituível com opt-in RBF?
Ao usar sendtoaddress no Bitcoin Core, o último parâmetro define se a transação aceita substituição. Passando o valor true, você habilita o opt-in RBF previsto na BIP125. Depois disso, ao consultar a transação com getmempoolentry, o node mostra o campo bip125-replaceable como true, o que confirma que essa transação pode ser substituída enquanto permanecer sem confirmação na mempool.
Qual é a diferença entre opt-in RBF e Full RBF?
O opt-in RBF, definido pela BIP125, permite substituir apenas as transações que foram explicitamente marcadas como substituíveis pelo remetente. Já o Full RBF, ativado em alguns nodes com a opção -mempoolfullrbf=1, permite que qualquer transação conflitante com taxa maior seja aceita na mempool, mesmo sem a marcação de substituível. O Full RBF segue em debate no ecossistema, principalmente por causa do impacto sobre pagamentos instantâneos.
Por que uma transação com zero confirmações pode ser substituída?
Porque antes de entrar em um bloco a transação existe apenas na mempool, que é local e dinâmica. Um pagador pode criar uma nova versão com taxa maior que envia os mesmos fundos para outro destino, e se essa versão for minerada primeiro, a original desaparece para sempre. Por isso aceitar pagamentos com zero confirmações envolve risco, e a estabilidade só começa a existir depois que a transação entra em bloco e acumula confirmações.
Compartilhe em suas redes sociais:
Professor universitário, pesquisador em tecnologias digitais e colaborador voluntário Bitcoin Coders. Doutor em Educação em Ciências (FURG, 2015), Mestre em Computação (UFRGS, 2007) e Engenheiro de Computação (FURG, 2004). Realizou pós-doutorado na UFSC (2024–2025).
Curtiu esse artigo? Considere nos pagar um cafezinho para continuarmos escrevendo novos conteúdos! ☕
