Se o código atual já entrega com perfeição a solução para a dor que ele visava curar, qualquer mudança nele é de assimetria negativa.

Quem frequenta a bolha bitcoinheira do Twitter deve ter escutado a respeito do BIP 119. Mas a falta de informação sobre o tema ainda é o estado geral da maioria dos bitcoinheiros, que se encontram em uma posição de mais dúvidas do que certezas.

O BIP 119 é um assunto polêmico e o objetivo deste texto é tentar traduzir essa discussão para uma visão não-técnica sobre o tema. Afinal, o Bitcoin é de todos e não somente dos desenvolvedores, que são somente um dos grupos desse ecossistema. Levando isso em conta, segue abaixo uma síntese não-técnica sobre o tal BIP 119. 

O BIP 119

Um BIP (ou Bitcoin Improvment Proposal)  é uma proposta de melhoria para o bitcoin. O BIP 119 foi proposto por Jeremy Rubin em 2020 e recebeu alguma atenção, mas não chegou a mobilizar a comunidade.

No dia 17 de abril de 2022, Rubin anunciou que lançaria em breve uma compilação de software que implementa o OP_CTV (a melhoria proposta no BIP 119, também chamado de CTV) e um mecanismo para ativá-lo na rede já neste ano.

Na visão dele, o CTV representa uma atualização limpa, bem contida e sem problemas que forneceria ótimas funcionalidades na escalabilidade, defi, auto-custódia e privacidade do bitcoin e que já poderia ser implementada até o final de 2022.

Devido à falta de discussão e consenso sobre o assunto, isso pegou muitos de surpresa.

Qual a função dessa proposta de melhoria?

O BIP-119 introduziria o opcode OP_CHECKTEMPLATEVERIFY (CTV), que permite aos usuários criar transações que tenham uso restrito no futuro. Por exemplo, pode-se designar que determinados fundos só possam ser enviados para carteiras específicas. O OP_CTV verifica se o hash da transação de gastos corresponde ao valor fornecido na transação de 

armazenamento inicial. Isso se chama covenant ou convênio, que são, em poucas palavras, a implementação de smart contracts mais flexíveis na rede bitcoin.

Opiniões favoráveis

Esses covenants são limitados pelo hash de uma transação futura, em vez de chaves e assinaturas privadas, portanto, também podem ser úteis para canais de pagamento em que uma contraparte pode estar offline.

Outra aplicação possível é para controle de congestionamento, onde uma exchange pode precisar enviar uma transação em lote com muitas saídas, mas deseja esperar até que as taxas de transação sejam menores.

A mudança proposta no BIP 119 permitiria a criação de uma pequena transação de saída única que se compromete com uma transação de saída múltipla posterior quando o mempool estiver menos cheio.

Esses covenants também permitiriam aos usuários um armazenamento frio mais seguro, uma vez que com eles, mesmo que um atacante tivesse acesso às suas seeds, ele só poderia efetuar transações de acordo com as especificações que o usuário já havia deixado pré-programadas.

Por exemplo, talvez esse usuário tivesse programado que esse endereço só poderia enviar seus satoshis para outros endereços que o mesmo usuário controla, tornando o roubo dessas seeds praticamente irrelevante. 

Atualmente, o usuário pode fazer uma multisig 2 de 3 e espalhar as seeds em locais diferentes. Entretanto, essa forma de custódia ainda representa risco em relação as seeds.

Já com os covenants, o usuário passa a poder controlar para aonde vão seus fundos, ou a quantidade que satoshis que podem ser movidos por transação. O segundo caso pode ser considerado mais conveniente para o usuário final, reduzindo assim atritos na adoção do bitcoin. 

O CTV também permitiria a criação de canais mais seguros na rede Lightning, que poderiam ser abertos sem a interação direta entre os participantes. 

Opiniões céticas

A ideia dos covenants não é bem aceita por uma parcela da comunidade por diversos motivos.

As linhas de argumento contra a proposta variam entre criticas específicas a questão da fungibilidade e também criticas mais amplas sobre a proposta ainda ser pouco compreendida e que ela poderia gerar consequências de segunda ordem imprevistas.

Consequências de segunda ordem

Uma coisa que me chamou a atenção é que diversos desenvolvedores favoráveis a implementação do CTV estão bastante confiantes nas derivações técnicas relacionadas a ele.

Entretanto, vi pouco ser comentado sobre o que essas mudanças gerariam como consequência para o equilíbrio dos incentivos econômicos. Ou seja, como essa mudança afetaria a teoria dos jogos por trás do bitcoin? 

Porque o bitcoin é muito mais do que só um protocolo, então analisar qualquer proposta de melhoria baseado somente no código e as funcionalidades que a adição de novas linhas permitiria é uma escolha míope.

O bitcoin também é um alinhamento fino de interesses e incentivos diversos. Por conta deste alinhamento estar equilibrado que a melhor estratégia evolutiva no ecossistema do bitcoin é o altruísmo reciproco e não o parasitismo ou a predação.

Ou seja, mesmo que as ideias por trás do código da BIP 119 sejam válidas, se elas desalinhem incentivos e afetarem o equilíbrio entre os diversos membros do ecossistema elas serão deletérias. Mesmo que as funcionalidades possíveis sejam legais. 

Levar em conta as possíveis consequências de segunda ordem imprevistas pode ser resumido no pensamento “o que eu não sei que eu não sei é o que pode me prejudicar”.

Ou seja, é uma abordagem conservadora em que a pessoa reconhece a sua ignorância para determinados pontos de uma questão e tenta mitigar essa ignorância se mantendo atendo e paranoico, por saber que existem incertezas que podem gerar resultados inesperados. 

Um exemplo dessas consequências de segunda ordem possíveis é o que o John Carvalho chamou de granada de transações. Nessa visão, as mudanças da BIP 119 possibilitariam que exchanges não paguem taxas de transação no presente, mas sim repassem elas para os clientes no futuro.

Com isso, o CTV poderia criar, sem intenção declarada, uma espécie de “crédito de transação”. Ao invés da exchange pagar o preço da transação, ela pode  empurrar os “problemas de escalabilidade” com a barriga para o futuro.

Nesse cenário hipotético, exchanges inimigas do bitcoin conseguiriam desalinhar os incentivos econômicos da rede, o que é uma forma de ataque ao bitcoin.

E a tal granada de transações é somente uma das várias possibilidades que o CTV poderia vir a abrir e que ainda precisam ser muito mais debatidas e consideradas sob a ótica da teoria dos jogos.

Por conta disso, grande parte dos membros da comunidade estão céticos e gostariam de mais tempo para avaliar as questões de incentivos econômicos associados a essa proposta de melhoria.

Também existe todo um argumento sobre as vantagens da simplicidade em relação a complexidade. Nesse sentido, manter o código do bitcoin enxuto e simples garante a sua estabilidade e segurança, enquanto modificações desnecessárias introduzem incertezas. 

Fungibilidade

Mas… e o que é fungibilidade? Em poucas palavras, fungibilidade significa que algo pode ser trocado por outra igual de si mesmo, como exemplo, você pode trocar uma nota de vinte reais por outra com seu amigo, e isso não fará diferença.

Já ativos não-fungíveis são ativos que, embora da mesma classe, possuem diferença entre si. Por exemplo: dois filhos são amados pelos pais da mesma forma, mas eles são diferentes entre si e não são intercambiáveis. 

O argumento de que os covenants de modo geral e de que talvez o CTV (e por isso seria necessário mais debates e que o tema fosse amadurecido) em específico possa afetar a fungibilidade do bitcoin é reverberado por nomes influentes na comunidade, como Andreas Antonopoulos.

Para os defensores dessa visão, quando você passa a poder programar certas transações, uma consequência indireta é que você está permitindo o surgimento de listas negras de bitcoins.

Ou seja, seria possível marcar certos endereços e bitcoins. Para Antonopoulos “um exemplo muito simples seria o conceito de um cofre onde você diz que ‘se esse output for gasto, a transação que gastá-lo só pode enviar este dinheiro para um endereço específico’, como uma whitelist”.

Então, não é difícil imaginar que o CTV tenha potencial para afetar a fungibilidade do bitcoin, visto que uma função de listas de endereços e moedas, se existente, pode ser imposta pelos governos.

Se, do ponto de vista técnico, for possível censurar certas moedas e endereços, uma certeza é que os governos forçarão entidades reguladas a implementar essa censura, o que pode ser visto como um ataque ao bitcoin e sua fungibilidade. 

Na prática, isso significaria que o bitcoin poderia perderia parte da sua fungibilidade e que existiriam duas categorias de bitcoins: os que podem ser enviados a qualquer pessoa e os que só podem ser enviados a uma lista específica de endereços pré-aprovados.

Isso pode ser ótimo do ponto de vista de um indivíduo e terrível se isso essa característica for usada como vetor de ataque por governos e entidades. 

Considerando que para o bitcoin ter sucesso ele precisa ser o bem monetário superior em todas as características técnicas de bens monetários (durabilidade, divisibilidade, fungibilidade, portabilidade, verificabilidade, escassez e histórico), um ataque a qualquer uma dessas características técnicas pode representar, no longo prazo, a morte do bitcoin.

Sacrificar a fungibilidade não faz sentido em hipótese alguma e propostas de melhorias que a arrisquem devem ser vistas com extremo ceticismo. 

Vale notar que as características técnicas do CTV ainda nem são a parte considera polêmica pela comunidade.

O que fez com que muitos bitcoinheiros enxerguem essa proposta de melhoria como um ataque ao bitcoin era a maneira que seus proponentes queriam implementá-la. 

Polêmica com o Speedy Trial 

A forma proposta para a implementação do CTV é o “Speedy Trial”, mesmo mecanismo de implementação de atualização que foi utilizado em 2021 para a aprovação da atualização conhecida como Taproot. Entretanto, o Taproot, ou mais especificamente as BIP 340, BIP 341 e BIP 342 que o compunham, foram discutidos por anos pela comunidade e já havia um amplo consenso favorável a essa implementação. O assunto já estava maduro. 

Desta forma, o Speedy Trial do Taproot foi uma “mera formalidade” para a aprovação de algo que já era desejado pelos diversos membros do ecossistema do bitcoin. Para uma ativação via Speedy Trial, seria desejado que primeiramente houvesse amplo consenso entre: mineradores, exchanges, full nodes, fabricantes de full nodes, desenvolvedores e demais membros do ecossistema. 

Atualmente, entretanto, não há nada próximo de um consenso a respeito do CTV. 

Obter consenso é algo dificil e trabalhoso, porém sem ele nenhuma mudança deve ser implementada. Diferentemente do que diversos programadores acreditam, o bitcoin é e deve se manter difícil de ser atualizado e modificado. É exatamente essa característica que torna ele resistente a ataques.

No fundo, essa é uma discussão entre alta e baixa preferência temporal e o bitcoin é o que é por sempre ter adotado a abordagem de baixa preferência temporal. Ou seja, os bitcoinheiros buscam sempre o pensamento de longo prazo. Então ser difícil e trabalhoso atualizar o código do bitcoin é uma característica positiva, não um bug. 

Isso já deveria ter ficado claro a partir da guerra civil pelo tamanho dos blocos: quem havia alta preferência e queria que o bitcoin funcionasse como moeda em 2016-2017 acabou forkando a rede e criando o bitcoin cash.

O que esses atores do bitcoin cash  não contavam era com a funcionalidade e viabilidade técnica das soluções em camadas e o crescimento exponencial da rede Lightning. 

Em outras palavras: o pensamento de curto prazo tornou eles míopes para as possibilidades que o código do bitcoin já permitia ou poderia vir a permitir no médio prazo. 

Talvez seus motivos reais fossem outros, e se especula que na realidade foi uma tentativa de centralização e controle do bitcoin a partir do aumento do custo econômico de se rodar full nodes. Ou seja, ou os proponentes da mudança do tamanho dos blocos eram ingênuos, ou eles estavam sim atacando o bitcoin. 

Será que essa mesma situação está ocorrendo agora com o bitcoin? A verdade é que não sabemos.

No dia 02 de maio, Jeremy Rubin publicou um texto explicando que ele havia sido mal compreendido pela comunidade. No texto, ele comenta que estava apenas apresentando sugestões e pedindo feedbacks em relação à BIP 119 e ao Speedy Trial, não forçando uma rota específica para a implementação da melhoria.

Qual a dor que o bitcoin resolve?

No mundo do empreendedorismo, uma maneira útil de se visualizar a necessidade (ou falta de necessidade) de algum novo produto é perguntar qual a dor que ele resolve. Se for uma dor real e que todos enxergam, este produto provavelmente encontrará terreno fértil.

Mas se, por outro lado, poucas pessoas enxergarem essa dor, talvez este produto não possua demanda e seja inútil. Se a maioria das pessoas não enxerga a necessidade por um produto é porque ele não agradou o mercado, não existe demanda por ele. 

Essa questão existe desde os primórdios do bitcoin e que ainda não é bem compreendida por todos. Qual dor o bitcoin resolve? Por que o bitcoin foi inventado? O que o bitcoin realmente conserta? 

Todos entendem que o bitcoin nasceu para ser dinheiro fora do controle do estado. Alguns enxergam que a propriedade mais importante do dinheiro é ser um bom meio de pagamento, enquanto outros acreditam que a função de reserva de valor é a mais importante. 

Os proponentes do bitcoin cash estavam entre os que acreditavam que a função mais importante que o bitcoin precisaria exercer como um bem monetário era a função de meio de pagamento.

E o mercado decidiu que eles estavam equivocados. Uma breve comparação entre o tamanho de mercado do bitoin cash e do bitcoin mostra que a imutabilidade e confiança em uma camada base robusta são muito mais importantes que um meio de pagamento eficiente.

Na prática, já existem soluções centralizadas eficientes como o PIX, Picpay e Pagseguro como meios de pagamento eficientes, o que significa que existe pouca dor em relação a essa questão.

A principal dor que o bitcoin soluciona é a de ser uma reserva de valor confiável. O bitcoin foi criado para proteger os indivíduos da inflação causada pela emissão das moeda fiats e impedir que os governos se apropriem do fruto do trabalho dos indivíduos via inflação.

Usando a metáfora do Michael Saylor, antes do bitcoin, todas as formas de reserva de valor eram blocos de gelo derretendo, ou seja, não existia nenhuma forma de reserva de valor que não perdesse valor ao longo do tempo.

O ouro é facilmente confiscável e apresenta custo de armazenamento, os imóveis também apresentam altos custos associados, como os custos com manutenção e impostos.

 A confiança que o bitcoin seguirá exercendo esse papel de ser uma reserva de valor confiável vem da imutabilidade atribuída a ele, algo que o próprio Michael Saylor citou como um dos motivos que o levou a investir em bitcoin em 2020.

Em poucas palavras, qualquer coisa que ameace a característica de “reserva de valor confiável” deve ser vista com bastante ressalva pela comunidade. 

E qual dor o CTV resolve?

Essa é uma pergunta pouco presente na discussão sobre o BIP 119. Muitos desenvolvedores comentam da viabilidade técnica da sua implementação, mas pouco se fala sobre qual a real necessidade dessa “melhoria”. 

Ela é vital para o bitcoin? 

Qual é a dor que ela cura? 

Sem ela, o bitcoin falhará? 

Ou em outras palavras, pra que serve esse tal CTV?

Pegando um trecho da newsletter do Marty Bent, um bitcoinheiro americano conhecido na comunidade, que comentou sobre essa questão: “isso é completamente necessário agora? Houve discussão e revisão suficientes da proposta? Se sim e é considerado digno, como deve ser ativado na rede bitcoin? 

Eu acho que essas são funcionalidades que adicionariam utilidade para muitos usuários de bitcoin e gosto da ideia do OP_CTV, mas certamente não acho que seja um recurso que vai fazer a diferença para o bitcoin dar certo ou errado.”

Assumo que posso estar enviesado, mas ainda não consegui enxergar nenhuma dor concreta e comum aos usuários sendo solucionada por essa proposta de modificação. Conversando no Twitter sobre essa questão em específico, o que mais fez sentido para mim, foi a questão dessa melhoria tornar o armazenamento offline mais seguro.

Mas confesso que esse é um tema em que eu não tenho dor atualmente. Já me sinto seguro o bastante com a minha forma atual de custódia. Então é uma solução sendo oferecida para resolver um não-problema meu. E se é um não-problema, ele não precisa de solução. 

Isso ajuda a explicar porque tanto usuários da comunidade são contrários a ela: eles julgam que a BIP 119 não é necessária para que o bitcoin continue sendo a melhor reserva de valor do mundo. Em outras palavras, não há demanda por ela.

E, portanto, o risco não compensa. Especialmente se levarmos em conta o risco de se estabelecer um precedente de que mudanças que não possuem consenso sejam implementadas via Speedy Trial.   

A importância da imutabilidade

Um ponto que me chamou a atenção nessa discussão toda é como a cultura do Speedy Trial, ainda mais sem consenso amplo, é problemática e pode ser considerada um ataque ao bitcoin.

Para mim, a síntese do Marty Bent resume bem a questão da utilização do Speedy Trial e dos riscos associados: “Em retrospecto, parece que um mau precedente foi estabelecido quando o Taproot foi ativado.

Temo que normalizar uma rápida sucessão de soft forks via Speedy Trial seja uma ladeira escorregadia que pode levar a muitas mudanças desnecessárias no futuro. Essas mudanças podem causar uma degradação da integridade do bitcoin.” 

No meu ponto de vista, se existe uma maneira de atacar o bitcoin, essa maneira envolve subverter o consenso social que o envolve. A melhor maneira de fazer isso? Fragmentar a comunidade e o consenso a partir de uma sequência de temas que não são tão relevantes assim, como a avaliação da dor que o CTV soluciona demonstra. 

A criação de uma cultura no estilo Vale do Silício de “move fast and break things” (mova-se depressa e quebre as coisas) para solucionar dores pequenas dentro da comunidade bitcoinheira é algo que poderia facilmente ser coaptado por inimigos da rede.

E, mesmo sem ser coaptado por inimigos, esse pensamento já é deletério e permite que incertezas sejam adicionadas no código que já cumpre a sua principal função: ser uma reserva de valor confiável.

Na minha visão, as mudanças no bitcoin devem ser lentas, isso se é que elas devem existir, o que muitos acreditam não ser o caso.

Vale ressaltar que, assim como reputação e o cabaço, a imutabilidade não pode ser revertida a posteriori. Uma vez perdida a reputação, ela não será resgatável, o mesmo vale para o cabaço e para a imutabilidade. 

Não existe voltar atrás, então mesmo que o CTV fosse primordial, a falta de consenso para um Speedy Trial por si só já é o suficiente para me fazer acreditar que este é um precedente que não deve ser criado.

BIPs sem amplo consenso na comunidade não devem ir para Speedy Trial. Uma cultura que torna simples a utilização do Speedy Trial em propostas de melhoria sem um amplo consenso pode ser facilmente coaptada e se transformar em um vetor de ataque ao consenso social do bitcoin, uma maneira de fragmentar a comunidade. 

A ossificação do bitcoin

Existe um argumento na comunidade sobre a imutabilidade do bitcoin, conhecido como a “ossificação” do bitcoin. 

A ossificação de um protocolo refere-se a quando este protocolo se torna tão amplamente utilizado por um grande número de usuários, o que torna praticamente impossível o desenvolvimento contínuo deste protocolo, congelando-o no lugar. Em última análise, isso é um indicador de sucesso, pois implica que este protocolo obteve um domínio generalizado. 

Existe um debate sobre se é positivo que essa ossificação ocorra mais cedo ou mais tarde na vida do bitcoin.

Alguns argumentam que seria positivo que a ossificação ocorra mais cedo como forma de defesa contra mudanças maliciosas no protocolo principal do bitcoin, como a tentativa do SegWit2x ilustra.

Também existe a opinião oposta, que considera que outro vetor de ataque explorável seria paralisar e impedir mudanças benéficas no protocolo que podem permitir soluções ponto a ponto e autocustódia mais robustas nas camadas subsequentes.

No meu estágio atual de compreensão (que é baixo), eu pendo para o lado favorável a ossificação adiantada do bitcoin em detrimento da ossificação tardia. Isso porque acredito que a principal função do bitcoin é justamente a dor que ele já resolve.

Ou seja, o bitcoin foi feito para ser uma reserva de valor confiável, o que o código atual já entrega com perfeição. Então ossificar no atual estágio do código me parece positivo, visto que eu não vejo nenhuma mudança que possa agregar mais valor do que a dor que o bitcoin já solucionou: ser o bem monetário que age como uma reserva de valor confiável.

E, se o código atual já entrega com perfeição a solução para a dor que ele visava curar, qualquer mudança nele é de assimetria negativa. Ou seja, o risco de uma mudança causar alguma derivada de segunda ordem imprevista e indesejável já faz com que essa mudança não valha a pena. Mesmo que ela seja útil para diversas outras funções. 

A principal função do bitcoin é ser uma reserva de valor e ele já é perfeito para esta função, o resto é detalhe.