ristic.png”>
Este é um editorial de opinião de Shinobi, um educador autodidata no espaço Bitcoin e apresentador de podcast de Bitcoin orientado para tecnologia.
Grande surpresa, os Bitcoiners estão discutindo furiosamente sobre uma proposta conjunto de alterações a ser incluído na próxima versão do Bitcoin Core. O opt-in replace-by-fee (RBF) é um recurso da política de mempool que foi proposto em 2015 para fornecer aos usuários uma ferramenta para lidar com picos rápidos nas taxas que fazem com que suas transações fiquem bloqueadas sem confirmação no mempool por longos períodos de tempo.
Obviamente, isso será um problema para qualquer uso do Bitcoin se o volume de transações crescer em média para ser consistentemente maior do que o número de transações que podem ser processadas no blockchain, então, a menos que você pense que isso nunca acontecerá esta é uma funcionalidade necessária na rede.
A substituição de transações foi realmente incluída e possível na versão original do software antes de Satoshi Nakamoto desaparecer. Ele acabou desativando o recurso porque a maneira como ele o implementou originalmente criou um vetor para ataques de negação de serviço contra nós. Sua implementação permitiu a substituição de qualquer transação sem pagar uma taxa mais alta, o que essencialmente permitiria que os usuários enviassem uma transação e começassem a transmitir uma quantidade irrestrita de substituições para a rede. Isso obviamente permitiria o spam de nós com grandes quantidades de dados que não exigiam prova de trabalho e aumentaria proibitivamente o custo de execução de um nó.
Ao longo dos anos, algumas diferentes propostas para uma substituição de transação renovada e mais segura esquema foram discutidos. Vamos rapidamente passar por tudo isso.
Full RBF
A variante mais simples de RBF. Qualquer transação pode ser substituída desde que a substituição da transação original esteja pagando uma taxa maior do que a que está substituindo. Dessa forma, as transações são todas substituíveis, mas a exigência de pagar uma taxa mais alta cada vez que você substituir uma evita um spam infinito de novas versões dos nós de sobrecarga de transações.
First-Seen-Safe RBF
Esta proposta permite que todas as transações sejam substituídas no mempool, com uma ressalva especial; todas as saídas da transação original também devem ser incluídas na transação de substituição, incluindo a saída de alteração. Ainda exige o aumento da taxa para substituir uma transação, mas a exigência de manter as mesmas saídas significa que você precisa adicionar uma nova entrada e uma segunda alteração de saída, porque nenhuma das saídas originais pode ser alterada. Isso resulta em transações maiores que precisam pagar mais em taxas totais para garantir que a substituição esteja pagando uma taxa de taxa mais alta.
RBF atrasado
Aqui havia uma proposta para permitir que qualquer transação fosse substituída no mempool, mas somente após um certo número de blocos ter passado desde que o nó viu a transação original. A ideia era que isso permitiria que transações travadas em ambientes de taxas altas fossem substituídas e confirmadas mais rapidamente, mas o atraso de tempo em que poderia ser substituído impediria tentativas de gastos duplos com confirmação zero.
Opt-In RBF
Isto é o que foi implementado em 2016, conforme definido em BIP 125. As transações só podem ser substituídas se definirem um sinalizador específico na transação optando pela substituição, ou se um de seus ancestrais o fez no caso de uma cadeia de transações não confirmadas, para permitir que as pessoas que recebem fundos saibam se uma transação não confirmada será ou não substituível no mempool.
A grande controvérsia hoje é que a próxima versão do Core, 0.24, está definida para introduzir um sinalizador completo de política de mempool RBF. O que isto significa? Ele dará aos usuários uma opção configurável para alterar sua política de mempool local de RBF opt-in para RBF completo; por padrão, a opção ficará desativada (os nós estarão usando RBF completo). Então, por que as pessoas estão bravas com essa mudança? As empresas que aceitam transações de confirmação zero dependem da maioria dos mempools dos nós que se recusam a substituir as transações que não optaram pelo RBF por um sinalizador de transação. Eles fazem isso conectando taticamente seu nó a um grande número de outros nós espalhados por toda a rede. Isso permite que eles detectem muito rapidamente a presença de uma transação de gasto duplo na rede, pois isso deve ser feito quase imediatamente se uma transação não for sinalizada como RBF para ter uma boa chance de chegar aos mineradores. Também vale ressaltar que todas as empresas da rede não podem fazer isso sem sibilar efetivamente. Essas empresas afirmam que o RBF completo”quebra”seu modelo de negócios de uso do RBF. Alguns até criticaram os desenvolvedores principais por”forçar”uma mudança que afeta negativamente esses negócios.
A realidade simples é que o gasto duplo foi e sempre será possível, opt-in RBF ou RBF completo não faz nada para mudar isso. Além disso, simplesmente criar uma opção para alterar sua própria política de mempool local (que está desativada por padrão) não está ditando a mudança para ninguém, é uma opção dada aos usuários para fazer uma escolha por si mesmos. No final do dia, quando se trata de quais transações serão realmente incluídas no próximo bloco, os únicos mempools que importam são os dos mineradores. Os mempools de nós de usuários individuais não são nada além de uma cadeia de armazenamento de memória com o objetivo final de propagar todas essas transações não confirmadas para os mineradores para que possam ser incluídas em um bloco eventualmente.
A política do Mempool é usada como uma espécie de mecanismo de segurança suave para evitar ataques de negação de serviço em nós e proteger os usuários de dar um tiro no pé com transações e scripts complicados. Muitos tipos de transações são válidos por consenso, podem ser incluídos em um bloco, mas não serão retransmitidos pela política de mempool padrão dos nós. No entanto, isso não impede que um determinado usuário transmita uma transação que seria ignorada por nós na rede diretamente para um minerador.
Esse é o cerne da questão. Basta que os mineradores configurem uma API para enviar transações diretamente a eles, o que muitos já têm, e as restrições das políticas de mempool na rede não importam. Você pode simplesmente dar uma transação diretamente aos mineradores e ignorar todas as regras sobre quando algo pode ser substituído no mempool de outros nós. Pense nos incentivos disso – se há dinheiro a ser feito minerando uma certa classe de transações, mas os mempools em toda a rede não os retransmitem, o que você faria como minerador? Basta aceitá-los diretamente. Quanto mais o subsídio reduz e as taxas de transação crescem como porcentagem da receita do minerador, mais inevitável se torna que os mineradores apenas aceitem diretamente substituições que pagam taxas mais altas se os nós da rede não os retransmitirem indiretamente. É inevitável.
Esta mudança não altera a política de mempool padrão para o Bitcoin Core, ela simplesmente apresenta uma opção para um operador de nó individual alterar sua política de mempool local, se assim o desejar.
E devo acrescentar, esta é uma opção que sempre esteve disponível se os usuários optassem por modificar seu cliente. Tudo o que ele faz é fazer uma escolha que sempre esteve disponível para os usuários mais simples de fazer. Os incentivos inevitavelmente levam ao estado em que todas as transações serão substituíveis se os mineradores agirem de maneira economicamente racional – é inevitável. A única questão da questão é se o software deve refletir esses incentivos, de forma a permitir que usuários individuais decidam por si mesmos qual política usar para seu mempool, ou as pessoas devem apenas sentar e deixar a propagação de transações centralizar em torno da submissão direta aos mineradores eles mesmos?
O resultado final é o mesmo, mas esperar que os mineradores gravitem para enviar transações diretas terá consequências muito negativas. Isso teria implicações de privacidade para as pessoas que transmitem transações para a rede e poderia ter consequências muito negativas para a capacidade dos usuários de decidir qual taxa pagar por uma transação. Se grandes porções de transações pendentes não forem mais divulgadas publicamente pela rede, os usuários terão uma visão incompleta de quem eles estão oferecendo para inclusão em um bloco. Os mineradores podem até mentir sobre a distribuição de taxas para incentivar os usuários a pagar mais do que precisam.
A única desvantagem real de disponibilizar essa opção é que o RBF completo pode não funcionar de forma consistente se apenas uma pequena parte da rede, incluindo mineradores, optar por ativar o RBF completo. No entanto, isso fundamentalmente não é diferente em termos de transição do que a atualização para o SegWit. Durante esse período de transição, os nós não atualizados não retransmitiriam as transações do SegWit porque eram incapazes de validá-las, portanto, durante esse período, houve a mesma dinâmica de propagação sendo inconsistente até que um número suficiente de usuários fosse atualizado. Mas, em última análise, isso não mudou o fato de que a atualização era uma decisão para usuários individuais.
Em última análise, combater a RBF total é apenas negar a realidade dos incentivos na rede. Nada está sendo ditado a ninguém, uma opção de configuração é simplesmente apresentar aos usuários individuais uma escolha a ser feita por eles mesmos. Acho estranho que, simultaneamente, tantas pessoas estejam ignorando a realidade dos incentivos para argumentar que um meio inseguro de receber pagamentos pode ser mantido seguro, desafiando os incentivos, assim como as pessoas estão argumentando que os usuários de software não devem ter permissão para escolher como para configurar seu próprio software.
Meu nó, minhas regras, certo?
Esta é uma postagem de convidado de Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.
