Início Educação O longo caminho até o SegWit: como a maior atualização do protocolo...

O longo caminho até o SegWit: como a maior atualização do protocolo do Bitcoin tornou-se realidade

552
3
O longo caminho até o SegWit: como a maior atualização do protocolo do Bitcoin tornou-se realidade

Nota do redator: em agosto, será completado um ano da implementação do Segregate Witness, conhecido como SegWit. A maior e mais disputada atualização da rede do Bitcoin até hoje presenciou diversos percalços em seu caminho, mas já concentra 40% de todas as transações da rede. Para homenagear essa conquista da comunidade, a agência de notícias Bitcoin Magazine elaborou uma retrospectiva de todo o processo. E nós, do Criptomoedas Fácil, trazemos o conteúdo para os nossos leitores conhecerem a trajetória do primeiro ano do SegWit.

Enfim, o Segregated Witness (SegWit) foi ativado no Bitcoin. Desde então, todos os nós na rede Bitcoin estão aplicando as novas regras. Esse ponto marcou a maior atualização feita no protocolo do Bitcoin até hoje. Mas a ativação não foi fácil, e não foi rápida.

Esta é uma retrospectiva da longa estrada percorrida até a adoção plena do SegWit.

O problema

As transações na rede do Bitcoin consistem em duas partes principais. Uma parte são os “dados de transação de base”. Isso abrange quais bitcoins estão sendo movidos e para onde estão sendo transferidos, assim como alguns outros dados. A segunda parte é chamada de “testemunha”. Essa contém um pouco de código, com dados de assinatura criptográfica, o que prova que o proprietário de um bitcoin realmente queria gastar o seu Bitcoin.

São esses dados de assinatura que trazem uma ligeira complicação. No que é chamado de “bug de maleabilidade”, as assinaturas do Bitcoin podem ser levemente alteradas por qualquer pessoa, mesmo depois que essas assinaturas são criadas, e isso pode ser feito sem invalidar as assinaturas. Por sua vez, significa que a aparência de toda a transação – mais especificamente o identificador de transação – pode ser alterada por transações de retransmissão pela rede Bitcoin, ou por mineradores que incluem transações em blocos.

Isso não precisa ser um grande problema em si. As transações ainda seriam válidas e moverão os bitcoins do mesmo local para o mesmo local, sob todas as mesmas condições. No entanto, isso dificulta a criação de transações novas, que ficam na dependência das transações não confirmadas: novas transações precisam conhecer o identificador de transação em que elas confiam. Isso, por sua vez, torna significativamente mais difícil construir certos protocolos de segunda camada além do Bitcoin, como canais de pagamento bidirecionais.

A ideia

A ideia geral de resolver o bug de maleabilidade por “separar” dados de assinaturas de outros dados de transação vem de vários anos. Na verdade, vem de muito antes da implementação do SegWit.

Ainda em 2012, contribuidores do Bitcoin Core, como Russell O’Connor, Matt Corallo, Luke Dashjr e Gregory Maxwell, assim como o moderador do fórum Bitcointalk, “Theymos”, discutiram a questão nos canais de desenvolvimento do IRC Bitcoin – mas naquela época eles não viam uma maneira sustentável de conseguir esse aumento de escala na rede do Bitcoin.

Um ano depois, em agosto de 2013, a questão ressurgiu, uma vez que os colaboradores do Bitcoin Core, Peter Todd e Gregory Maxwell, estavam tendo discussões semelhantes no IRC. Mas agora, os dois faziam progressos em suas idéias para combater a maleabilidade. “Estou falando de tornar a [totalidade] das “scriptsig” amplamente [separadas]”, escreveu Maxwell. “Eu até sugeriria usar como [identificador da transação] a transação sem os scriptsigs.”

Um mês depois, Maxwell e, desta vez, o conhecido criptógrafo Dr. Adam Back estavam discutindo a questão da maleabilidade no IRC mais uma vez. Agora, Back sugeriu calcular o ID da transação omitindo a assinatura. No entanto, Maxwell comentou que “conseguir que a assinatura do txid poderia ajudar, mas isso seria uma mudança muito profunda e difícil, realmente difícil de garantir”.

A Sidechain

Em agosto de 2014, a Blockstream, empresa de tecnologia blockchain, foi fundada pelos mesmos Adam Back e Gregory Maxwell. Juntou-se a eles o empreendedor e investidor Austin Hill e vários desenvolvedores do Bitcoin Core, incluindo o Dr. Pieter Wuille. A empresa estava preparada para se concentrar em sidechains, blockchains alternativos que podem ser efetivamente atrelados ao Bitcoin.

No início de 2015, os engenheiros da Blockstream decidiram implementar um novo recurso no protótipo sidechain Elements, que foi anunciado publicamente em junho daquele ano. Esse recurso resolveria de forma conclusiva o problema de maleabilidade na cadeia lateral – separando dados de transação de base de dados de testemunha em diferentes estruturas de dados.

O nome desse novo recurso era, naturalmente, o famoso Segregate Witness. E o modelo da proposta foi exatamente o da foto abaixo.

A disputa pelo tamanho do bloco

A famosa disputa pelo aumento do tamanho do bloco não era nova: desde outubro de 2010 existiam conversas nesse sentido. Concretamente, desde fevereiro de 2013 e, finalmente, publicamente, entrando em cena na primavera de 2015, a disputa do limite de tamanho de bloco se tornou mais forte entre a comunidade.

O ex-desenvolvedor do Bitcoin Core, Gavin Andresen, e o desenvolvedor-chefe da Bitcoinj, Mike Hearn, em particular, acreditavam que o limite de tamanho de bloco de 1 megabyte do Bitcoin deveria ser aumentado com uma mudança de protocolo, que exigiria que quase todo o ecossistema Bitcoin fizesse uma atualização de compatibilidade. Uma tarefa nada fácil, ainda mais porque não havia consenso na comunidade para a implementação dessa mudança.

Independentemente disso, até o verão de 2015, Andresen e Hearn anunciaram que seguiriam em frente com seus planos, usando o cliente de software alternativo Bitcoin XT. A natureza controversa do esforço colocou a comunidade e a indústria de desenvolvimento do Bitcoin em um estado de emergência.

Em uma tentativa de resolver a divisão e potencialmente ajudar a descobrir uma solução para a disputa por tamanho de bloco, duas conferências foram rapidamente organizadas no segundo semestre de 2015: a Scaling Bitcoin Montreal, no Canadá, e a Scaling Bitcoin Hong Kong.

Uma das propostas de escalonamento mais promissoras apresentadas em Montreal foi a Lightning Network, uma sofisticada solução de segunda camada que foi detalhada em um whitepaper publicado por Joseph Poon e Thaddeus Dryja apenas alguns meses antes. O único problema: essa solução exigiria uma correção de maleabilidade.

O “Soft Fork”

Neste momento, os desenvolvedores ainda não tinham certeza se e como o bug de maleabilidade poderia ser corrigido. A maioria ainda achava que o Segregated Witness não poderia ser implementado na cadeia principal do Bitcoin sem uma divisão profunda da rede, o chamado hard fork.

Esse não era o caso do desenvolvedor e contribuidor do Bitcoin Core (e o mantenedor do Bitcoin Knots), Luke Dashjr.

Em outubro de 2015, entre as duas conferências Scaling Bitcoin, os contribuidores do Bitcoin Core, Eric Lombrozo, Pieter Wuille, Wladimir van der Laan e Luke Dashjr discutiram no IRC um potencial novo modelo para divisões da rede, o chamado soft fork. Durante esse bate-papo, Dashjr observou que o mecanismo proposto não funcionaria para todos os potenciais soft-fork, e citou o caso da SegWit.

Curiosamente, o que Dashjr considerou óbvio – a opção de implantar o SegWit como um soft fork – nem sequer foi considerado por outros. E mesmo Dashjr não pareceu perceber as implicações dessa possibilidade no começo.

Para implantar o SegWit como uma soft fork, os dados da testemunha tinham que ser colocados em uma nova parte de um bloco Bitcoin. E a “âncora” para todos esses dados de testemunhas (a “raiz Merkle”) teve que ser movida para uma parte pouco convencional de um bloco Bitcoin: a transação de moedas que recompensa mineradoras novas moedas.

Apesar de não convencionais, os colaboradores do Bitcoin Core, ao longo dos dias e semanas que se seguiram, também perceberam que este método abriu um interessante “bônus”. Ao criar uma nova parte de um bloco Bitcoin para os dados das testemunhas, o tamanho do bloco Bitcoin poderia ser aumentado de tal forma que nós não atualizados não perceberiam. Isso pode aumentar o tamanho do bloco do Bitcoin através da compressão das transações, o que faria caber mais transações em cada bloco, sem necessariamente aumentar o limite de tamanho de bloco existente do Bitcoin.

Poucas semanas antes do segundo encontro da Scaling Bitcoin, vários colaboradores do Bitcoin Core pensaram que poderiam ter encontrado pelo menos uma solução temporária para a disputa do limite de tamanho de bloco. O SegWit aumentaria efetivamente o limite de uma maneira compatível com versões anteriores, ao mesmo tempo em que corrigia o bug de maleabilidade de longa data, permitindo assim soluções de escalonamento mais avançadas, como a rede de descargas atmosféricas.

Uma solução que traria ganho para todos – ou assim pensavam seus proponentes.

A apresentação

O Segregated Witness – como um soft fork – foi apresentado pela primeira vez por Pieter Wuille em dezembro de 2015, na segunda edição do Scaling Bitcoin, em Hong Kong. Muitos ouviram pela primeira vez sobre a proposta lá, e inicialmente ela pareceu ser recebida com entusiasmo.

Pouco depois desta segunda edição ter terminado, Gregory Maxwell propôs o que ficou conhecido como o roteiro de escala, que incluía o SegWit como peça central. Este roteiro foi rapidamente endossado pela equipe de desenvolvimento do Bitcoin Core, bem como por outros desenvolvedores e pelos usuários no ecossistema Bitcoin. O consenso parecia ter sido atingido.

As críticas

Mas apesar do entusiasmo inicial, a mudança também teve seus críticos.

Preocupações sobre a proposta de atualização do protocolo variaram. Jeff Garzik, antigo colaborador do Bitcoin Core – que logo depois encontrou sua própria empresa de desenvolvimento, a Bloq – não considerou a solução de escalonamento de curto prazo suficiente para a SegWit. Mike Hearn, desenvolvedor líder do Bitcoin XT, não se convenceu com a proposta: ele descartou a solução como uma “contabilidade criativa” e abandonou completamente o desenvolvimento do Bitcoin, pouco tempo depois.

Jonathan Toomim, desenvolvedor do cliente de software alternativo Bitcoin Classic, argumentou que a proposta era “feia e desajeitada”, sugerindo que seria melhor implementada como um hard fork. Até o contribuinte do Bitcoin Core, Peter Todd, teve suas preocupações, em particular relacionadas à mineração.

A maioria desses problemas foi considerada solucionável, pouco convincente ou riscos que valiam a pena, pela equipe de desenvolvimento do Bitcoin Core. O desenvolvimento da atualização do soft-fork começou.

O desenvolvimento

Apesar de uma versão do Segregated Witness já ter sido implementada no Elements, o código para a versão principal do Bitcoin ainda não havia sido escrito, não apenas porque precisava ser implementado como um soft fork, mas também porque o SegWit para a rede principal teria um gama de novos recursos que não estavam presentes no Elements: por exemplo, o “desconto de testemunha” necessário para aumentar o tamanho do bloco, nova compatibilidade para a rede peer-to-peer e muito mais.

A proposta concreta de melhoria do Bitcoin para o SegWit, chamada de BIP141, foi de autoria de Pieter Wuille, do CEO da Ciphrex, Eric Lombrozo, e do colaborador independente do Bitcoin Core, Dr. Johnson Lau. No início de janeiro de 2016, em meio a um debate caloroso, esses e outros contribuidores do Bitcoin Core lançaram uma rede inicial de testes dedicados para a atualização do protocolo, que foi apelidada de SegNet. Mais duas semanas depois, esta rede de testes foi levada a público para que a comunidade de desenvolvimento do Bitcoin pudesse testá-la. E em março, a SegNet foi atualizada para suportar versões de teste da Lightning Network.

O desenvolvimento continuou nos próximos meses, recebendo feedback da comunidade de desenvolvimento do Bitcoin, corrigindo bugs, melhorando a base de código e lançando várias interações da SegNet(s).

Enquanto isso, os colaboradores do Bitcoin Core também procuraram a indústria Bitcoin, que com o tempo levou a uma lista cada vez maior de empresas e projetos comprometidos em apoiar o SegWit.

Em junho, o código já contava com 4.743 linhas de código (incluindo o código de teste) e propôs remover ou modificar 554 linhas existentes do Bitcoin Core. Depois de mais revisões de vários colaboradores, Wladimir van der Laan, principal mantenedor do Bitcoin Core, fundiu-o no “branch master” do Bitcoin Core até o final daquele mês.

Os encontros

Ao mesmo tempo em que o SegWit estava sendo desenvolvido, as tensões no tamanho dos blocos na comunidade do Bitcoin estavam mais uma vez esquentando. Desta vez, liderado pelo Bitcoin Classic, um número de empresas de Bitcoin e mineiros pareciam determinados a implementar um hard fork, a fim de aumentar o limite de tamanho de bloco para 2 megabytes.

No que talvez seja melhor descrito como uma reunião de emergência, mais uma vez em Hong Kong, vários contribuidores do Bitcoin Core, operadores de pools de mineração e outros membros da indústria se reuniram para discutir a questão da escala.

A reunião levou a um acordo que veio a ser conhecido como o “Consenso de Mesa Redonda Bitcoin” (ou o “Acordo de Hong Kong”). Os contribuidores do Bitcoin Core presentes na reunião concordaram em trabalhar em um hard fork de aumento do limite de tamanho de bloco, a ser proposto à equipe de desenvolvimento do Bitcoin Core e à comunidade como um todo. Os mineradores, por sua vez, concordaram em lançar uma versão do SegWit em produção no momento em que um hard fork fosse lançado em uma versão do Bitcoin Core. A crise parecia ter sido evitada – embora tenha ficado claro que nem todos estavam satisfeitos com o acordo.

Vários meses depois, um grupo ainda maior de colaboradores do Bitcoin Core e operadores de pool de mineração se reuniu na Califórnia. Os contribuidores do Bitcoin Core presentes nesta reunião se convenceram de que o Segregated Witness seria ativada pelos mineradores.

A liberação

Com cerca de seis meses atrasados em relação ao cronograma inicial – o lançamento foi originalmente previsto para abril – o SegWit foi oficialmente lançado em outubro de 2016, na atualização do Bitcoin Core versão 0.13.1. A atualização do protocolo também foi implementada em várias outras implementações do Bitcoin, como Bitcoin Knots e Bcoin.

Usando um método de ativação chamado “VersionBits” (BIP9), projetado para minimizar a interrupção da rede, 95% dos mineiros (por poder de computação) tiveram que sinalizar o suporte para que o SegWit fosse ativado na rede Bitcoin. Esta sinalização deveria começar em 15 de novembro. Enquanto isso, os usuários eram encorajados a atualizar seus clientes, o que, ao longo do tempo, muitos começaram a fazer.

Com base nas reuniões com os operadores de pools de mineração, bem como na convicção geral de que o SegWit seria uma grande melhoria para o Bitcoin, muitos esperavam que o soft fork fosse ativado rapidamente.

A política

Porém, não foi isso que aconteceu. Como se viu depois, vários participantes do Acordo de Hong Kong discordaram sobre o que eles realmente assinaram.

O CEO da Bitmain, Jihan Wu, em particular, indicou que só estaria disposto a ativar o SegWit se a equipe de desenvolvimento do Bitcoin Core também implementasse um fork para aumentar o limite de tamanho de bloco, em sua base de código. Outras pools de mineração, incluindo F2Pool, HaoBTC e bitcoin.com, também não sinalizaram suporte para o soft fork.

Além disso, surgiu uma nova pool de mineração chinês: a ViaBTC. Com laços estreitos com a Bitmain, a nova pool acumulou poder de processamento suficiente para, sozinha, bloquear a ativação do SegWit. E seu operador, Haipo Yang, posicionou-se como um firme crítico da proposta de atualização do protocolo.

A ativação do SegWit parecia mais distante do que nunca.

O UASF

Em fevereiro de 2017, pouco mais de três meses após o lançamento oficial do SegWit, uma nova oportunidade se apresentou.

O desenvolvedor pseudônimo “Shaolinfry”, cuja foto do avatar encontra-se acima, que havia contribuído anteriormente para a criptomoeda Litecoin, lançou uma nova proposta na lista de discussão de desenvolvimento do Bitcoin e no popular fórum BitcoinTalk: um “User Activated Soft Fork”, um soft fork ativado pelos usuários, que ficou conhecido pela sigla “UASF.”

Shaolinfry argumentou em seu e-mail que o mecanismo de ativação por poder de processamento, que se tornou o padrão para soft fork, nunca foi destinado a ser um “voto”. “A metodologia de sinalização é amplamente mal interpretada para significar que o poder hash está votando em uma proposta e parece difícil corrigir esse mal-entendido na comunidade em geral ”, escreveu ele.

Shaolinfry propôs uma alternativa: um soft fork ativado pelo usuário (UASF). Em vez da ativação do poder de processamento, um fork soft ativado pelo usuário teria uma “’ativação do dia de bandeira’ onde os nós iniciariam a aplicação em um tempo predeterminado no futuro.” Enquanto tal UASF for imposto por uma maioria econômica, isso deve forçar a maioria dos mineradores a seguir (ou ativar) o soft fork.

A idéia gerou imediatamente um burburinho nos fóruns e mídias sociais do Bitcoin. E quando o ex-COO da BTCC e fervoroso defensor da SegWit, Samson Mow, montou um fundo de recompensas para o desenvolvimento de uma implementação de software UASF, parecia que a proposta poderia se tornar realidade.

A tecnologia patenteada

Na primeira semana de abril de 2017, Gregory Maxwell revelou algo que foi amplamente considerado uma revelação bombástica na lista de discussão de desenvolvimento do Bitcoin.

Maxwell afirmou ter feito engenharia reversa de um chip especializado de mineração (ASIC) e descobriu que ele incluía a tecnologia patenteada AsicBoost. Além disso, Maxwell revelou que o uso secreto da tecnologia seria incompatível com uma versão do SegWit lançada por um soft fork. “Uma incompatibilidade seria um longo caminho para explicar alguns dos comportamentos mais inexplicáveis ​​de algumas partes do ecossistema de mineração”, observou ele.

Embora nenhum fabricante específico de ASIC tenha sido mencionado no e-mail de Maxwell, a Bitmain reconheceu que implementou a tecnologia patenteada em seus chips de mineração – embora tenha negado tê-lo usado na rede principal do Bitcoin.

De qualquer maneira, para alguns usuários, a revelação aumentou o desejo de ter o soft fork ativado na rede Bitcoin. E, como a ativação via poder de processamento parecia ainda menos provável agora, um fork ativado pelo usuário estava cada vez mais próximo de ser a solução para conseguir a ativação.

O BIP148

Pouco depois de propor a ideia geral de um UASF, Shaolinfry e cerca de uma dúzia de outros membros da comunidade Bitcoin abriram um canal UASF no canal do Bitcoin Core no Slack.

O canal se tornou um ponto central de discussão e organização da iniciativa. Uma data de sinalização foi escolhida, inicialmente para 1º de outubro, e depois movida para 1º de agosto, para melhor contabilizar o suporte potencialmente baixo de hash. Shaolinfry foi o autor de uma proposta concreta de melhoria do Bitcoin: BIP148. O fundador da Open Dime, Rodolfo Novak, também criou um site informativo para promover a ideia.

O plano inicial era conseguir que exchanges e outros negócios abraçassem o UASF. Se essas empresas apoiassem a proposta e aplicassem o soft fork, seria um longo caminho para a obtenção de uma maioria econômica desejada.

Mas o UASF não ganhou o nível de tração que alguns de seus proponentes esperavam. Embora algumas empresas e alguns desenvolvedores parecessem ter aderido ao BIP148, nenhuma bolsa importante ou outras empresas declararam apoio – algumas até se manifestaram contra a iniciativa.

E, em meados de abril, Gregory Maxwell na lista de discussão de desenvolvimento do Bitcoin afirmou que ele acreditava que o BIP148 também era uma má idéia. Vindo de um dos mais respeitados e influentes colaboradores do Bitcoin Core, sua rejeição à iniciativa teve um impacto: Essa versão de um UASF parecia estar perdendo todo o ímpeto.

Em vez disso, alguns começaram a trabalhar em uma alternativa UASF: BIP149.

As altcoins

Muitas altcoins foram criadas baseadas no código do Bitcoin. Isso significa que o código SegWit, embora desenvolvido para o Bitcoin, é amplamente compatível com essas criptomoedas. Não é de surpreender, portanto, que várias altcoins decidam implementar o SegWit. A primeira a ativar a melhoria foi a Groestlcoin, em janeiro de 2017.

Mas outras moedas estavam lutando. Litecoin, Vertcoin e Viacoin pareciam ter sido apanhadas pelo jogo político do Bitcoin. Essas moedas contavam com os mesmos mineradores do Bitcoin, em grande parte, e a maioria não estava sinalizando apoio para a atualização.

Supostamente, isso ocorreu devido a problemas técnicos ou outras razões declaradas, mas, como o desenvolvedor líder da Viacoin, Romano, observou: “Parece mais provável que eles evitem ativar a SegWit em altcoins porque isso lhes daria ainda menos motivos para impedir a ativação no Bitcoin.”

Em abril de 2017, essa atitude levou Charlie Lee, criador do Litecoin, a defender um soft fork ativado pelo usuário na moeda “dele.” Sua iniciativa logo fez sucesso entre os usuários da Litecoin. Não demorou muito para que os mineradores da Litecoin, Lee e outros membros do ecossistema da Litecoin organizassem uma reunião on-line, cujo resultado foi a Resolução da Mesa Redonda Global da Litecoin. Em troca de alguns compromissos de Lee, os mineiros concordaram em ativar o SegWit. Shaolinfry e outros consideraram o esforço do UASF um sucesso.

Dentro de uma semana após a ativação do SegWit na Litecoin, um usuário desconhecido fez um movimento ousado. Ele (ou ela) enviou 1 milhão de dólares na criptomoeda para um endereço protegido por SegWit, desafiando qualquer um a roubar os fundos, se pudessem. Até esta data, a recompensa permanece intocada, fortalecendo ainda mais a confiança na tecnologia.

O Acordo de Nova York

Enquanto isso, o debate sobre o tamanho do bloco continuava. Outro cliente de software para aumentar o limite de tamanho de bloco do Bitcoin por hard fork, o Bitcoin Unlimited, ganhou força entre a comunidade de mineração do Bitcoin. Recebendo o apoio particular de Jihan Wu, o projeto parecia estar caminhando para um potencial (e controverso) final.

Essa ameaça iminente e a possibilidade de uma “divisão” no blockchain do Bitcoin eram motivo para o fundador e CEO da DCG, Barry Silbert, organizar uma reunião antes da conferência Consensus 2017 em Nova York. Inicialmente anunciada em uma lista de e-mails privados para empreendedores do Bitcoin e outros membros proeminentes da indústria, a reunião reuniria uma fatia significativa da indústria Bitcoin, incluindo mineradores – embora, notadamente, não contribuíssem com o Bitcoin Core.

O resultado dessa reunião é normalmente chamado de “Acordo de Nova York“. Os participantes concordaram com o que consideraram ser um consenso entre aqueles que desejavam aumentar o tamanho do bloco do Bitcoin com um hard fork e aqueles que preferiam o SegWit. Com base em uma ideia originalmente proposta pelo fundador da RSK, Sergio Demian Lerner, o SegWit seria ativado sob condições específicas, enquanto também haveria um hard fork para dobrar o “limite de tamanho de bloco de base” do Bitcoin.

Mas, embora tenha sido suficiente para dizer que nem todos no ecossistema Bitcoin apoiaram o acordo, um problema específico se destacou em particular. As condições para a ativação do SegWit foram amplamente incompatíveis com as propostas pela equipe de desenvolvimento do Bitcoin Core, para as quais o código já era amplamente adotado pelos usuários do Bitcoin.

A minoria intolerante

Enquanto o BIP148 parecia ter perdido muito a favor do BIP149, nem todos desistiram completamente da primeira proposta.

Shaolinfry havia proposto o conceito sob a suposição de que seria apoiado por uma maioria econômica e achava que deveria ser cancelado antes do dia da sinalização. Mas um grupo de usuários no canal UASF do Slack teve uma ideia diferente. Alguns deles – incluindo o desenvolvedor do Bitcoin Core e do Bitcoin Knots, Luke Dashjr – estavam pensando em ativar o soft fork independentemente do que o resto do ecossistema do Bitcoin faria. Mesmo que eles fossem uma minoria, e mesmo que efetivamente criassem uma nova altcoin, eles seguiriam em frente com a atualização.

Por volta de meados de maio, Alphonse Pace ligou essa determinação a um conceito teórico de jogo descrito pelo estatístico e escritor Nassim Nicholas Taleb: a “minoria intolerante”. Em suma, essa ideia pressupõe que mesmo uma minoria econômica poderia obrigar os mineradores a ativar o soft fork da SegWit. De outra forma, eles perderiam desnecessariamente uma parte da sua “base de clientes” (usuários do Bitcoin).

Aparentemente alimentado pelo escândalo do AsicBoost, a ativação do SegWit no Litecoin e o descontentamento com relação ao Acordo de Nova York – e desta vez apoiado pela teoria dos jogos – o apoio ao BIP148 começou a se transformar em um fenômeno viral nas redes sociais e nos quadros de mensagens novamente.

Vários outros artigos discutiram o potencial crescente do UASF e muito debate sobre mídia social, canais do YouTube outras plataformas de discussão seguidas. Enquanto isso, Eric Lombrozo também jogou seu peso por trás do esforço, e chapéus UASF distribuídos por Samson Mow se tornaram a raiva. Inspirado pelo codinome de um lançamento da Electrum Wallet, o dia 1 de agosto foi apelidado de “Dia da Independência Bitcoin“.

O único problema: os métodos de ativação para o BIP148 e o Acordo de Nova York eram tão incompatíveis quanto o Acordo de Nova York com os métodos de ativação propostos pela equipe de desenvolvimento do Bitcoin Core.

A solução

Foi o engenheiro da Bitmain Warranty, James Hilliard, que veio em socorro. Hilliard propôs uma solução um pouco complexa, mas inteligente, que tornaria tudo compatível: ativação do SegWit conforme proposta pela equipe de desenvolvimento do Bitcoin Core, o mecanismo de ativação do BIP148 e do Acordo de Nova York. Seu BIP91 poderia manter o Bitcoin inteiro – pelo menos durante toda a ativação do SegWit.

Enquanto a maioria dos mineradores ativaria o BIP91 antes de 1º de agosto, todos os nós do Bitcoin deveriam permanecer como parte da mesma rede. Era uma janela de tempo relativamente pequena, uma vez que a solução só foi proposta no final de maio, mas Jeff Garzik, principal desenvolvedor do Acordo de Nova York, adotou a proposta e planejava liberar o software cliente resultante desse acordo semanas antes de 1º de agosto. E isso foi feito.

A ativação

Em meados de julho, os mineradores tinham perdido sua janela para ativar o SegWit através do método proposto pela equipe de desenvolvimento do Bitcoin Core a tempo de ser compatível com o BIP148. Como resultado, os mercados pareciam nervosos com uma potencial “divisão” entre uma cadeia BIP148 e uma cadeia não-BIP148. No espaço de apenas uma semana, o valor do Bitcoin caiu de cerca de US $ 2.500 para US$ 1.900, o menor valor em mais de um mês.

Possivelmente assustada com esses movimentos de mercado, a comunidade de mineração do Bitcoin começou a sinalizar rapidamente o apoio ao BIP91, mesmo antes do cronograma estabelecido pelo Acordo de Nova York. E em 20 de julho, dez dias antes do dia 1 de agosto, data marcada para a ativação do BIP148, o BIP91 foi bloqueado. Ele foi ativado um pouco mais de dois dias depois.

Com o BIP91 bloqueado, era apenas uma questão de tempo até que o próprio SegWit se fixasse. Isso aconteceu no dia 9 de agosto – o ponto sem volta foi alcançado em 8 de agosto.

O Bitcoin iria “oficialmente” adotar o SegWit após um período de carência de duas semanas.

A adoção

O passo final para a implementação do Segregated Witness seria, obviamente, a adoção real do usuário. Como o SegWit havia acabado de ser ativado, seria necessário um maior tempo para saber com que rapidez e quanto o upgrade será realmente usado.

Alguns críticos, talvez mais notavelmente Garzik, previam que a adoção generalizada pode levar até um ano ou até mais. Outros, incluindo vários desenvolvedores de carteiras e bibliotecas, acham que podem utilizar o recurso em semanas ou já estão preparados. E outras tecnologias que dependem do upgrade, como a Rede Lightning, mas também Merkelized Abstract Syntax Trees (MAST), swaps atômicos, assinatura de transação mais rápida para carteiras de hardware, o algoritmo de assinatura Schnorr mais eficiente e o TumbleBit no modo de processador de pagamento. em vários estágios de desenvolvimento também.

O fato é que a ferramenta demonstrou uma grande adoção, e hoje já representa 40% de todas as transações na rede do Bitcoin. A medida culminou numa maior redução de taxas, transações mais rápidas e no fim das longas filas de espera entre os blocos.

Tem sido um longo caminho, mas quem quiser usar o SegWit agora já é capaz de fazê-lo e aproveitar seus muitos benefícios.