Segregated Witness (SegWit) foi ativada no Bitcoin. A partir de hoje, todos os nós do SegWit na rede Bitcoin estão aplicando as novas regras, marcando a maior atualização do protocolo Bitcoin até o momento.
Mas a ativação não foi fácil, e não veio rápido.
Este é uma visão do longo caminho até ativar a SegWit.
O Problema
As transações Bitcoin consistem em duas partes principais. Uma parte é “dados básicos da transação”. Isso cobre quais bitcoins estão sendo movidos e para onde eles estão sendo movidos, assim como alguns outros dados. A segunda parte é chamada de “testemunha”(witness). Isso 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 bitcoin.
É essa assinatura que traz uma pequena complicação. No que é referido como o “erro de maleabilidade”, as assinaturas do Bitcoin podem ser ligeiramente alteradas por qualquer um, mesmo após essas assinaturas serem criadas e sem invalidar as assinaturas. Isso, por sua vez, significa que a aparência de toda transação, e mais especificamente o identificador de transação, pode ser alterada por essas transações de retransmissão na rede Bitcoin ou por mineradores que incluem transações em blocos.
Isso não precisa ser um grande problema em si mesmo. As transações ainda são válidas e moverão os bitcoins do mesmo local para o mesmo local, em todas as mesmas condições. No entanto, complica a criação de transações mais recentes dependendo de transações não confirmadas: novas transações precisam saber o identificador de transação em que confiam. Isso, por sua vez, torna ainda mais difícil a criação de certos protocolos de segunda camada (second-layer protocols) no topo do Bitcoin, como canais de pagamento bidirecionais.
A Ideia
A idéia geral de resolver o erro de maleabilidade por “separar” dados de assinatura de outros dados da transação acontece a vários anos.
Já em 2012, os colaboradores do Bitcoin Core, Russell O’Connor, Matt Corallo, Luke Dashjr e Gregory Maxwell, bem como o moderador do Bitcointalk “Theymos”, discutiram o problema nos canais de desenvolvimento do IRC Bitcoin – mas naquela época eles não não viam uma maneira sustentável de colocar na rede Bitcoin.
Um ano depois, em agosto de 2013, a questão resurgiu, já que os contribuintes do Bitcoin Core, Peter Todd e Gregory Maxwell, estavam tendo discussões semelhantes no IRC. Mas agora, os dois estavam avançando com suas idéias para combater a maleabilidade. “Estou falando de fazer a [totalidade] dos scriptsig em grande parte [separar]”, escreveu Maxwell. “Eu mesmo sugeriria usar como [ID da transação] a transação sem os scriptsigs”.
Mais um mês depois, Maxwell e, desta vez, o conhecido criptógrafo Dr. Adam Back discutiram o problema de maleabilidade no IRC mais uma vez. Agora, Back sugeriu a computação da ID da transação, omitindo a assinatura. No entanto, Maxwell comentou: “obter as sig para fora do txid poderia ajudar, mas isso seria uma mudança muito profunda e duradoura … e é realmente complicado tornar seguro”.
Sidechain
Em agosto de 2014, a empresa de tecnologia blockchain Blockstream foi fundada pelo mesmo Adam Back e Gregory Maxwell, bem como pelo empresário 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 alternativas que podem ser efetivamente vinculadas ao Bitcoin.
No início de 2015, os engenheiros da Blockstream decidiram implementar uma nova característica no protótipo sidechain da empresa, o Elements, que foi anunciado publicamente em junho desse ano. Este recurso resolveria conclusivamente o problema de maleabilidade na sidechain – separando os dados das transações base dos dados das transações ‘witness’ em diferentes estruturas de dados.
O nome desse novo recurso era, naturalmente, Segregated Witness.
Tamanho do Bloco
Tecnicamente desde outubro de 2010, mais concretamente desde fevereiro de 2013 e, finalmente, publicamente, entrou em cena até o outono de 2015: a disputa do limite do tamanho do bloco.
O ex-desenvolvedor principal do Bitcoin Core, Gavin Andresen, e o desenvolvedor principal do Bitcoin, Mike Hearn, em particular, acreditavam que o limite de tamanho de bloco de 1 megabyte do Bitcoin deveria ser aumentado com um hard fork, uma mudança de protocolo incompatível que exigiria que quase todo o ecossistema Bitcoin atualizasse. Nenhuma tarefa fácil – ainda mais porque não havia um consenso de toda a comunidade para essa mudança.
Independentemente disso, no verão de 2015, Andresen e Hearn anunciaram que avançariam com seus planos, usando o software alternativo Bitcoin XT. A natureza polêmica do esforço colocou a comunidade e a indústria de desenvolvimento da Bitcoin em um estado de emergência.
Em uma tentativa de resolver a divisão e potencialmente ajudar a descobrir uma resolução para a disputa de tamanho de bloco, duas conferências (ou oficinas) foram rapidamente organizadas na segunda metade de 2015: Scaling Bitcoin Montreal e Scaling Bitcoin Hong Kong.
O Soft Fork
Uma das propostas de escala mais promissoras apresentadas em Montreal foi a Lightning Network, uma sofisticada solução de escala de segunda camada que foi detalhada em um white paper por Joseph Poon e Thaddeus Dryja apenas meses antes. O único problema: esta solução exigiria uma correção de maleabilidade. E neste momento, a maioria ainda pensou que a SegWit não poderia ser implementada no Bitcoin sem um hardfork.
Mas não o contribuidor Bitcoin Core Luke Dashjr.
Em outubro de 2015, entre as duas conferências do Scaling Bitcoin, os colaboradores do Bitcoin Core Eric Lombrozo, Pieter Wuille, Wladimir van der Laan e Luke Dashjr discutiram um novo modelo potencial para soft forks no IRC. Durante este bate-papo, Dashjr apontou que o mecanismo proposto não funcionaria para todos os potenciais soft forks, como um soft fork para a 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 início.
Para implantar SegWit com um soft fork, os dados da ‘witness’ tiveram que ser colocados em uma nova parte de um bloco do Bitcoin. E a “âncora” para todos esses dados da ‘witness’ (a “Merkle root”) teve que ser movida para uma parte um pouco convencional de um bloco Bitcoin: a transação da moeda que recompensa mineradores com novas moedas.
Embora não convencionais, os colaboradores do Bitcoin Core, ao longo dos dias e semanas que se seguiram, também perceberam que esse método abriu um “bônus” interessante. Ao criar uma nova parte de um bloco Bitcoin para os dados witness, o tamanho de bloco do Bitcoin poderia ser aumentado de tal forma que os nós não atualizados não notariam. Isso pode realmente aumentar o tamanho do bloco do Bitcoin sem aumentar o limite de tamanho de bloco existente do Bitcoin.
Apenas algumas semanas antes da segunda oficina do Scaling Bitcoin, vários contribuidores do Bitcoin Core achavam que, finalmente, encontraram pelo menos uma solução temporária para a disputa do limite de tamanho do bloco. A SegWit efetivamente aumentaria o limite de uma maneira compatível com o atraso, ao mesmo tempo que corrigiria o bug de maleabilidade de longa data, permitindo soluções de escala mais avançadas, como a Lightning Network.
Uma solução de ganho para todos os lados – ou ao menos foi o que eles pensaram.
A Apresentação
Segregated Witness como um soft fork foi apresentado pela primeira vez por Pieter Wuille em dezembro de 2015, na segunda edição das oficinas do Scaling Bitcoin em Hong Kong. Muitos ouviram pela primeira vez sobre a proposta, e inicialmente pareceu ser recebido com entusiasmo.
Pouco depois de esta segunda edição do Scaling Bitcoin ter terminado, Gregory Maxwell propôs o que se tornou conhecido como o roteiro de escala, que apresentou o SegWit como uma peça central. Este roteiro foi aprovado rapidamente pela equipe de desenvolvimento do Bitcoin Core, bem como por outros desenvolvedores e usuários no ecossistema Bitcoin.
A Crítica
Mas, apesar da excitação inicial, a Segregated Witness também teve seus críticos.
As preocupações com a atualização do protocolo proposto variaram. Jeff Garzik, o ex-contribuidor do Bitcoin Core – que logo depois encontrou sua própria empresa de desenvolvimento Bloq – não considerou o SegWit uma solução de escala de curto prazo suficiente. O programador da Bitcoin XT, Mike Hearn, enquanto isso, não estava convencido com a proposta: ele descartou a solução como um “truque contábil” e desistiu completamente do desenvolvimento do Bitcoin pouco depois.
Jonathan Toomim, desenvolvedor do software alternativo Bitcoin Classic, argumentou que a proposta era “feia e estranha”, sugerindo que seria melhor implementado com um hard fork. Até o contribuidor do Bitcoin Core Peter Todd teve suas preocupações, em particular relacionadas à mineração.
A maioria dessas questões foram consideradas solúveis, pouco convincentes ou valendo a compensação pela equipe de desenvolvimento do Bitcoin Core em grande escala, no entanto. O desenvolvimento da atualização do soft fork começou.
O Desenvolvimento
Mesmo que uma versão da Segregated Witness já tenha sido implementada na Elements, o código da versão principal do Bitcoin ainda não foi escrito, não só porque precisava ser implementado como um soft fork, mas também porque o SegWit para Bitcoin iria desfrutar de um variedade de novos recursos não presentes na Elements: por exemplo, o “desconto na witness” necessário para aumentar o tamanho do bloco, a nova compatibilidade para a rede peer-to-peer e muito mais.
A proposta concreta de melhoria do Bitcoin para a SegWit, BIP141, foi autoria de Pieter Wuille, o CEO da Ciphrex, Eric Lombrozo, e o colaborador independente do Bitcoin Core, Johnson Lau. No início de janeiro de 2016, no meio de um acalorado debate sobre a escalabilidade, esses e outros colaboradores do Bitcoin Core lançaram uma rede de teste dedicada inicialmente para a atualização do protocolo, que foi denominada SegNet. Outras duas semanas depois, este testnet foi levado a público para que a comunidade de desenvolvimento Bitcoin mais ampla experimentasse. 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 comentários da comunidade de desenvolvimento do Bitcoin, corrigindo erros, melhorando a base de códigos em conformidade e lançando várias outras iterações da SegNet.
Enquanto isso, os colaboradores do Bitcoin Core também chegaram à indústria Bitcoin, que, ao longo do tempo, levou a uma lista cada vez maior de empresas e projetos que se comprometeram a apoiar a SegWit.
Em junho, o código da SegWit contou 4.743 linhas de código (incluindo o código de teste) e propôs a remoção ou modificação de 554 linhas existentes no código do Bitcoin Core. Depois de mais revisões de vários contribuidores, o líder mantenedor do Bitcoin Core, Wladimir van der Laan, fundiu-o no “ramo principal” da Bitcoin Core no final daquele mês.
As Reuniões
Ao mesmo tempo em que a SegWit estava sendo desenvolvida, as tensões sobre o tamanho do bloco na comunidade de Bitcoin voltaram a aparecer. Desta vez liderado pela Bitcoin Classic, várias empresas de Bitcoin e mineradores pareciam determinadas a fazer um fork para 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 colaboradores do Bitcoin Core, operadores de pool de mineração e outros membros da indústria de Bitcoin reuniram-se para discutir a questão da escala.
O encontro levou a um acordo que passou a ser conhecido como o “Consenso da Mesa Redonda” (ou o “Acordo de Hong Kong”). Os colaboradores do Bitcoin Core presentes na reunião concordaram em trabalhar em um limite de tamanho de bloco, que seria proposto ao time de desenvolvimento do Bitcoin Core e à comunidade Bitcoin mais ampla. Os mineradores, por sua vez, concordaram em executar um lançamento da SegWit no momento em que tal fork fosse lançado em uma versão do Bitcoin Core. A crise parecia ter sido evitada – mesmo que rapidamente se tornasse claro que nem todos estavam felizes com o acordo.
Vários meses depois, um grupo ainda maior de contribuidores do Bitcoin Core e operadores de pool de mineração se reuniram na Califórnia. Os colaboradores do Bitcoin Core presentes nesta reunião deixaram convencido de que a SegWit seria ativada pelos mineradores.
O Lançamento
Cerca de seis meses de atraso no cronograma inicial – o lançamento foi originalmente definido para abril – A SegWit foi oficialmente apresentada em outubro de 2016, na versão Bitcoin Core 0.13.1. A atualização do protocolo também foi implementada em várias outras implementações 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 por cento dos mineradores (por hash power) tiveram que dar suporte ao SegWit para ativar na rede Bitcoin. Esta sinalização de mineração deveria começar em 15 de novembro. Enquanto isso, os usuários foram encorajados a atualizar seus clientes, o que, ao longo do tempo, muitos o fizeram.
Com base nas reuniões com operadores de pool de mineração, bem como uma convicção geral de que a SegWit seria uma benção para Bitcoin, muitos esperavam que o soft fork fosse ativado rapidamente.
A Política
Mas não foi isso que aconteceu. Vários participantes do Consórcio da Mesa Redonda de Hong Kong discordaram sobre o que eles realmente assinaram.
O CEO da Bitmain, Jihan Wu, em particular, indicou que ele só estaria disposto a ativar a SegWit se a equipe de desenvolvimento do Bitcoin Core também implementasse um hard fork para aumentar o limite do tamanho do bloco em sua base de código. Outros pools de mineração, incluindo F2Pool, HaoBTC e bitcoin.com, também não apresentaram suporte para o soft fork.
Além disso, emergiu um novo grupo de mineração chinês: ViaBTC. Com laços estreitos com a Bitmain, o ViaBTC sozinho obteve força suficiente de hash para bloquear sozinho a ativação da SegWit. E seu operador, Haipo Yang, posicionou-se como um crítico firme da atualização do protocolo proposto.
A ativação do SegWit parecia longe.
O UASF
Em fevereiro de 2017, um pouco mais de três meses após o lançamento oficial da SegWit, uma nova oportunidade se apresentou.
O desenvolvedor pseudônimo “Shaolinfry”, que já havia contribuído para o Litecoin, lançou uma nova proposta na lista de discussão de desenvolvimento do Bitcoin e no popular fórum bitcointalk.org: um “soft fork ativado pelo usuário” ou “UASF”.
Shaolinfry argumentou em seu e-mail que o mecanismo de ativação do poder hash que se tornou o padrão para soft forks nunca pretendia ser um “voto”. “A metodologia de sinalização é amplamente mal interpretada para significar que o poder de hash está votando em uma proposta e parece difícil corrigir esse mal entendido na comunidade em geral “, escreveu.
Shaolinfry propôs uma alternativa: um soft fork ativado pelo usuário (UASF). Em vez da ativação do poder de hash, um soft fork ativado pelo usuário teria uma ativação em um dia específico, onde os nodes começam a ser executados em um tempo predeterminado no futuro. “Enquanto um UASF for implementado por uma maioria econômica, isso deve obrigar a maioria dos mineradores a seguir (ou ativar) o soft fork.
A ideia gerou imediatamente o zumbido em todos os fóruns e mídias sociais do Bitcoin. E quando o antigo COO da BTCC e o proponente da SegWit, Samson Mow, criou um fundo de recompensa para o desenvolvimento de uma implementação de software UASF, parece que a proposta poderia se tornar uma realidade.
A Tecnologia Patenteada
Na primeira semana de abril de 2017, Gregory Maxwell deixou cair o que era amplamente considerado uma revelação na lista de desenvolvimento do Bitcoin.
Maxwell afirmou ter engenharia reversa de um chip ASIC especializado em mineração e descobriu que incluiu tecnologia patenteada da AsicBoost. Além disso, Maxwell revelou que o uso encoberto da tecnologia seria incompatível com uma versão soft da SegWit. “Uma incompatibilidade ajudaria um longo caminho para explicar alguns dos comportamentos mais inexplicáveis de algumas partes no ecossistema de mineração”, observou.
Embora nenhum fabricante ASIC específico tenha sido mencionado no e-mail de Maxwell, a Bitmain reconheceu que implementou a tecnologia patenteada em seus chips de mineração – embora negasse ter usado isso no mainnet do Bitcoin.
De qualquer forma, para alguns usuários, a revelação adicionou ao desejo de ter o soft fork da Segregated Witness ativado na rede Bitcoin. E, como a ativação do poder de hash pareceu ainda menos provável agora, um soft fork ativado pelo usuário era cada vez mais como a solução para conseguir isso.
A proposta BIP148
Pouco depois de propor a idéia geral de um UASF, Shaolinfry e cerca de uma dúzia de outros membros da comunidade Bitcoin abriram um canal UASF no slack do Bitcoin Core.
O canal tornou-se um ponto central de discussão e organização para a iniciativa. O “dia D” foi escolhido, inicialmente para 1 de outubro, depois mudou-se para 01 de agosto para melhor explicar o suporte de poder de hash potencialmente baixo. Shaolinfry escreveu uma proposta concreta de melhoria do Bitcoin: BIP148. O fundador da Open Dime, Rodolfo Novak, também estabeleceu um site informativo para promover a ideia.
O plano inicial era obter exchanges e outras empresas a bordo com o UASF. Se essas empresas apoiassem a proposta e aplicassem o soft fork, seria um longo caminho para conseguir uma maioria econômica desejada.
Mas o UASF não ganhou o nível de tração que alguns dos proponentes esperavam. Enquanto uma série de empresas e alguns desenvolvedores pareciam estar a bordo com o BIP148, nenhuma grande exchange ou outras empresas declararam apoio, e alguns até falaram contra a iniciativa.
E, até meados de abril, Gregory Maxwell, na lista de discussão de desenvolvimento da Bitcoin, afirmou que ele acreditava que BIP148 também era uma má idéia. Saindo de um dos mais respeitados e influentes contribuidores do Bitcoin Core, sua rejeição da iniciativa teve um impacto: esta versão de um UASF parece estar perdendo todo o impulso.
Em vez disso, alguns começaram a trabalhar em uma UASF alternativa: BIP149.
As Altcoins
Muitas altcoins baseiam-se na base de código do Bitcoin. Isso significa que o código SegWit, embora desenvolvido para Bitcoin, é amplamente compatível com essas criptomoedas alternativas. Sem surpresa, portanto, várias altcoins decidiram implementar o SegWit. O primeiro a ativar foi Groestlcoin já em janeiro de 2017.
Mas outras moedas estavam lutando. Litecoin, Vertcoin e Viacoin pareciam ter sido capturadas no jogo político do Bitcoin. Essas moedas dependiam dos mesmos mineradores que Bitcoin, em grande parte, e a maioria não estava sinalizando o suporte para a atualização.
Isto foi alegadamente devido a problemas técnicos ou outros motivos declarados, mas, como o desenvolvedor líder da Viacoin, Romano, observou: “Parece mais provável que eles desejem abster-se de ativar a SegWit em altcoins porque isso lhes daria ainda menos motivo para impedir a ativação no Bitcoin”
Em abril de 2017, essa atitude levou o criador do Litecoin, Charlie Lee, a defender um soft fork ativado pelo usuário na “sua” moeda. Sua iniciativa foi recebida com entusiasmo entre os usuários do Litecoin; Não demorou muito para que os mineradores de Litecoin, Lee e outros membros do ecossistema de Litecoin organizassem uma reunião on-line. Em troca de alguns compromissos da Lee, os mineradores concordaram em ativar o SegWit. ShaolinFry e outros consideraram o esforço do UASF um sucesso.
O Acordo de Nova York
Enquanto isso, o debate sobre o tamanho dos blocos prosseguia. 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. Paralelamente ao Wu da Bitmain, em particular, o projeto parecia estar se dirigindo para um potencial (e controverso) hard fork.
Essa ameaça e a possibilidade de uma “divisão” na blockchain do Bitcoin foi motivo para o fundador e CEO da DCG, Barry Silbert, organizar uma reunião antes da Consensus Conference 2017 em Nova York. Inicialmente anunciado em uma lista de e-mail privada para empreendedores de Bitcoin e outros membros proeminentes da indústria, a reunião reuniria um pedaço significativo da indústria Bitcoin, incluindo mineradores – embora, notavelmente, não contribuintes do Bitcoin Core.
O resultado dessa reunião é tipicamente referido como o “Acordo de Nova York”. Os participantes concordaram sobre o que consideravam um compromisso entre aqueles que queriam aumentar o tamanho de bloco de Bitcoin com um hard fork e aqueles que preferiam a SegWit. Com base em uma ideia originalmente proposta pelo fundador da RSK Sergio Demian Lerner, a SegWit seria ativado em condições específicas, enquanto também haveria um hard fork para duplicar o “limite de tamanho dos blocos” do Bitcoin.
A Minoria Intolerante
Enquanto o BIP148 UASF parecia ter perdido muito vapor em favor do BIP149, nem todos desistiram dessa primeira proposta de UASF completamente.
Shaolinfry propôs o conceito sob o pressuposto de que seria apoiado por uma maioria econômica e pensou que deveria ser abortado antes do ‘dia D’ de outra forma. Mas um grupo de usuários no canal do slack UASF tinha uma ideia diferente. Alguns deles – incluindo o desenvolvedor Bitcoin Core e Bitcoin Knots, Luke Dashjr – estavam contemplando ativar o soft fork independentemente do que o resto do ecossistema Bitcoin faria. Mesmo que fossem minoria, e mesmo se eles efetivamente se transformassem em uma nova altcoin, eles iriam avançar com a atualização.
Por volta de meados de maio, Alphonse Pace vinculou essa determinação a um conceito de jogo teórico descrito pelo estatístico e autor Nassim Nicholas Taleb: a “minoria intolerante”. Em suma, essa ideia pressupõe que mesmo uma minoria econômica possa obrigar os mineradores a ativar o soft fork da SegWit. Eles perderiam desnecessariamente um pedaço de sua “base de clientes” (usuários Bitcoin) caso contrário.
Aparentemente alimentado pelo escândalo da AsicBoost, a ativação do SegWit sobre Litecoin e o descontentamento com relação ao Acordo de Nova York – e desta vez apoiado pela teoria dos jogos – o suporte ao BIP148 começou a fazer bola de neve em algo de um fenômeno viral em redes sociais e blogs mais uma vez.
Vários artigos discutiram o potencial crescente do UASF e muitos debates sobre isso aconteceram nas redes sociais, seguindo os canais do YouTube, e outras plataformas de discussão. Enquanto isso, Eric Lombrozo também jogou seu peso atrás do esforço, e os chapéus UASF distribuídos por Samson Mow tornaram-se a raiva. Inspirado pelo nome de código de uma versão eletrônica do Wallet, o 1 de agosto foi apelidado de “Dia da Independência do Bitcoin”.
O único problema: os métodos de ativação do BIP148 e do 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 Sacada
Foi o engenheiro da Bitmain Warranty, James Hilliard, que veio ao resgate. Hilliard propôs uma solução ligeiramente complexa, mas inteligente, que tornaria tudo compatível: Ativação da SegWit, conforme proposto pela equipe de desenvolvimento do Bitcoin Core, o UASF BIP148 e o mecanismo de ativação do Acordo de Nova York. Seu BIP91 poderia manter o Bitcoin inteiro – pelo menos durante a ativação da SegWit.
Enquanto a maioria dos mineradores ativar o BIP91 antes de 1 de agosto, todos os nodes do Bitcoin devem permanecer parte da mesma rede. Era uma janela de tempo relativamente pequena, uma vez que a solução só foi proposta até o final de maio, mas Jeff Garzik, principal colaborador do Acordo de Nova York, adotou a proposta e planejou lançar o cliente de software resultante desse acordo semanas antes do dia 1 de agosto. Era possível.
A Ativação
Em meados de julho, os mineradores de Bitcoin perderam sua janela para ativar o SegWit através do método proposto pela equipe de desenvolvimento do Bitcoin Core a tempo de serem compatíveis com o BIP148. Como resultado, os mercados ficaram agitados com uma possível “divisão” entre uma cadeia BIP148 e uma cadeia não BIP148. No intervalo de apenas uma semana, o preço do bitcoin caiu de cerca de US$ 2500 para US$ 1900.
Possivelmente assustado por esses movimentos do mercado, a comunidade de mineração de Bitcoin começou a sinalizar rapidamente o suporte para o BIP91, mesmo antes do cronograma estabelecido pelo Acordo de Nova York. E no dia 20 de julho, dez dias antes do ‘dia D’ para ativação, o BIP91 deu ‘lock in’. E foi ativado um pouco mais de dois dias depois.
Com o BIP91 ‘locked in’, era apenas uma questão de tempo antes e acontecer o mesmo com a SegWit.E isso aconteceu em 9 de agosto.
Bitcoin “oficialmente” ativará SegWit após outro período de carência de duas semanas.
A Adoção
O passo final para Segregated Witness é, naturalmente, a adoção real do usuário. Como o SegWit apenas ativou no momento da publicação deste artigo, é impossível saber com que rapidez e quanto a atualização será efetivamente utilizada. Alguns críticos, talvez mais notadamente Garzik, prevêem que a adoção generalizada pode levar até um ano ou até mais. Outros, incluindo uma série de desenvolvedores de carteiras, pensam que podem utilizar o recurso dentro de semanas, ou já estão preparados. E outras tecnologias que dependem da atualização, como a Lightning Network, mas também Merkelized Abstract Syntax Trees (MAST), swaps atômicos, assinatura de transações mais rápidas para carteiras de hardware e TumbleBit no modo processador de pagamento, também estão em vários estágios de desenvolvimento .
Tem sido um longo caminho, mas qualquer um que quer usar a SegWit agora pode fazer, começando hoje.
*Texto escrito por Aaron van Wirdum.