"""""""""""""""""""""
[Absolutamente tudo o que você precisa saber para entender a treta do SegWit, SegWit2x, BIP144, BIP148 e amigos]
Eu sei, estou atrasado, mas confia no tio que ainda tem muita coisa para falar e muita gente que não sabe.
Estou escrevendo essa pequena postagem porque eu achava que sabia o que estava acontecendo de verdade nos forks – e eu fui provado errado. Estou a meses acompanhando fóruns gringos sobre as modificações e a quantidade de divergências, tanto filosóficas quanto técnicas, é tão grande que chega a ser difícil estabelecer os conceitos mais simples. Minha filosofia é o que está me mantendo acordado na madrugada de hoje para escrever essa postagem afim de evitar que mais pessoas caiam naquele limbo de não saber por onde começar a ler.
Ok, antes de começar a nossa versão TI das Kardashians, ficam algumas mensagens.
Antes de falar qualquer coisa sobre o SegWit2x, gostaria de dizer que o segundo capítulo da série Bitcoin Professional está 99,99% concluído e que ela não deve contemplar as transações dos forks que ocorreram nos últimos meses (relembro que o módulo 2 é sobre transações). Faço isso por 2 razões: a primeira é que o conteúdo está gigante (são 11 páginas do Word sem margem com fonte monoespaçada tamanho 11), e modifica-lo para atender ao SegWit2x levaria mais tempo (calculo o dobro) e mais palavras (possivelmente o dobro caso eu tivesse que explicar essa treta), e a segunda é que pretendo fazer as coisas em separado – um artigo para explicar a treta, um para explicar transações e outro para explicar as modificações das transações em relação ao SegWit. Este ultimo artigo deverá ser feito somente ao final da Série.
Eu tô tentando estudar o fork de maneira técnica e abstrata ao mesmo tempo. O objetivo do meu estudo foi – e ainda é – prover informação tanto para quem é das TI quanto para quem é das finanças. Isso pode ser considerado um erro pelos dois lados, uma vez que o nível de abstração dos dois por si só já é profundo o bastante para ser humanamente possível fazer isso e manter a boa qualidade na postagem.
O ato de fazer um “fork” – que essencialmente significa você pegar um programa e modifica-lo, diferente do “clone” que você não modifica nada – gera problemas gigantescos em tecnologias distribuídas e descentralizadas. Pode ser que um fork mantenha a compatibilidade com programas antigos que não queiram seguir o mesmo fork que você, pode ser que não (e em alguns casos por uma boa razão). Tudo isso transforma o ambiente da tecnologia em algo semelhante a política: é praticamente impossível não ter um lado, já que cada opção tem argumentos prós e contras. Eu tenho meu palpite sobre o que EU acho que está certo ou errado, outras pessoas têm os dela, mas aqui a minha tentativa é apresentar mais argumentos. Entretanto, eu vou deixar extremamente claro qual é a minha opinião quanto aos assuntos que vamos abordar.
[Treta parte 1 - A sociedade da Treta]
Antes de explicar a treta, vamos abordar conhecimentos básicos sobre o que vamos falar na treta. O primeiro desses conceitos é o conceito de Node (ou nó, na tradução em português). Eu poderia passar batido por esse conceito, mas notei que nos últimos dias tem rolado uma movimentação muito grande de novatos por aqui.
Imagine que você e um amigo seu decidam fazer compras no supermercado e, para agilizar as compras, ambos decidam se separar em partes diferentes do supermercado, cada um com seu carrinho. Para poder controlar as compras, os dois imprimem exatamente a mesma lista de compras e acordam enviar mensagens pelo celular toda vez que encontrarem um item da lista, afim de deixar as listas sincronizadas. As mensagens devem conter o nome e o preço pago no item da lista, em seguida cada um anota em sua lista de compras o que foi comprado e o preço. Ao final, espera-se que ambos tenham exatamente os mesmos dados na lista, correto?
Essencialmente é esse o conceito de um node de Bitcoin. Toda vez que alguém faz uma transação algum (ou alguns) nodes recebem essa transação e inserem ela na rede (através de mineradores, processo que não vamos falar nessa postagem). Em seguida, o consenso é feito e consequentemente os outros Nodes também confirmam aquelas transações em suas réplicas centrais das transações. Perceba que não existe nenhum “Node principal”, afinal o objetivo de um Node é ser mais um dentro de uma cadeia afim de garantir a descentralização da rede. Se um node morrer, grandes são as chances de nada acontecer.
Para que os nodes funcionem, existem alguns programas que executam funções relevantes a um node (como copiar outros nodes, como verificar transações realizadas naquele node, etc). Os conceitos que permeiam as Bitcoins são públicos e qualquer pessoa pode desenvolver um programa que siga esses conceitos para participar da rede, estando sujeito somente aos protocolos da própria internet para enviar e receber essas informações. Seria como levarmos em consideração o celular que você está usando para enviar as mensagens ao seu amigo no supermercado, ou seja, não faz muita diferença qual celular você esteja usando desde que ele cumpra bem as funções de enviar e receber as mensagens.
Existem várias interpretações do protocolo da Bitcoin em software, mas sem dúvidas a mais notável delas é o Bitcoin Core (projeto aqui https://bitcoin.org/en/bitcoin-core/ ). Seus desenvolvedores são anciãos devotos de Satoshi Nakamoto e sua biblioteca vem ficando cada vez mais robusta graças a exaustiva análise de cada modificação submetida para inclusão no software, em especial as análises relacionadas aos padrões do protocolo. No começo dessa treta toda, 2/3 dos nodes de BTC estavam rodando o produto da Bitcoin Core.
Agora imagine a seguinte situação: supondo que houvesse uma “falha” no protocolo da Bitcoin – no protocolo, e não na implementação do Bitcoin Core. De quem é a responsabilidade de corrigir essa falha? Se você disser que essa responsabilidade é de quem fez o protocolo, eu vou te dar uma resposta ignorante como “Tá, e dai?”, porque modificar um pedaço de papel sem modificar o código não muda absolutamente nada no mundo real – sem contar que até hoje não sabemos com certeza quem é o cara que fez o protocolo, o que tornaria ainda mais inútil essa discussão. Se você falar que a responsabilidade é dos desenvolvedores da Bitcoin Core, eu vou falar que você está dando muito poder a uma única instituição de falar o que é e o que não é o Bitcoin, centralizando a coisa toda e acabando com a oportunidade dos outros 1/3 do mercado de participarem de maneira consensual. Se você falar que a culpa é da comunidade, que não se atentou para isso, eu vou dizer que isso é verdade, mas que eles por si não poderiam fazer nada além de uma manifestação para que as demais entidades envolvidas (Tanto o Bitcoin enquanto protocolo, quanto o Bitcoin Core, quanto os demais entes) tomassem alguma providência em relação a isso. A comunidade até tentou resolver essa situação se adiantando (e criando uma nova moeda), mas o peso que o Bitcoin e o Bitcoin Core têm na filosofia é muito grande, sendo difícil competir.
E foi exatamente o que aconteceu, o protocolo tinha uma falha na hora de lidar com muitas transações. O problema era o seguinte: toda vez que uma transação era feita ela precisava ser enviada para um node e aguardar até que um bloco que incluísse aquela transação fosse minerado. Só assim essa transação começaria a se espalhar pela rede. O método em si é interessante, já que assim poderíamos garantir a integridade dos nodes de maneira independente e centralizada, mas havia um problema com isso.
Os dados de uma transação pesam, em média, algo próximo a 500 bytes (esse valor pode variar por razões que pretendo explicar no próximo artigo da Bitcoin Professional), e um bloco pode conter, no máximo, 1MB de tamanho, dividido em várias transações. Os blocos que forem enviados com mais de 1MB serão recusados por conta da regra do consenso (que existe para evitar que se incluam todas as transações em um único bloco, centralizando os pagamentos das taxas de mineração a quem tem mais poder de mineração, acabando mineradores menores). Um bloco, mesmo podendo colocar mais de 1800 transações a serem mineradas, e mesmo com os crescentes números de mineradores, estava ficando pequeno demais para que valesse a pena fazer transferências pequenas.
E os mineradores, nada bobos, estavam começando a aceitar somente fees grandes para poderem continuar minerando as transações que eram inseridas em seus blocos. Não seria mais possível transacionar valores pequenos, já que as tarifas e a demora não compensariam para quem receberia o dinheiro. Esse era o problema da escalabilidade do protocolo.
[ Treta parte 2 – Os dois hard forks ]
A solução do livre mercado era simples: Ora, se existe demanda, em breve vai existir oferta. Quer dizer, se está faltando poder de mineração, então novos mineradores vão surgir para faturar essa grana, certo?
Não foi bem o que aconteceu, já que moramos em um mundo onde o mercado raramente funciona como deveria. Os mineradores começavam a não aguentar a carga de transações e isso poderia prejudicar todo o ecossistema das Bitcoins. Essa responsabilidade tem de ser dividida com um monte de gente (mineradores, o Estado, os criadores do protocolo, quem não otimiza algoritmo de seleção de UTXOs, entre outros). Como ninguém dos outros setores deu uma resposta satisfatória, entraram em ação as propostas de mudança de protocolo. Desse modo, independente das vontades privadas, uma decisão precisava ser tomada ou todo mundo seria prejudicado.
A maneira de se implementar uma mudança no protocolo da Bitcoin é através de uma BIP (Bitcoin Improvement Proposal, ou Proposta de Melhoria do Bitcoin) no próprio BIP1 você pode consultar exatamente o que é um BIP e como ele funciona (https://github.com/bitc…/bips/blob/master/bip-0001.mediawiki). Como você pode ver na figura do fluxograma disponibilizado na página, cada BIP é executada após a anterior ser implementada, e assim elas vão ocorrendo.
Quem discordar de um BIP poderá fazer duas coisas, a primeira é criar uma moeda própria (o que muitos desenvolvedores estão fazendo), copiando o código de um node (sendo ele feito pelo Bitcoin Core ou não) e modificando de acordo com o seu gosto, ou fazer um fork baseado em uma moeda já existente, copiando os dados de quem tem uma moeda e entregando para o mesmo dono daquela chave privada na outra rede. Seria como clonar sua carteira, com a diferença que na nova carteira você terá uma flutuação diferente do dinheiro (outra cotação, outra moeda, tudo novo).
Praticamente todas as situações acima ocorreram. Teve gente criando moeda, fazendo fork e tentando mudar o protocolo. E foi assim que aconteceu.
[Quando a treta começou?]
Toda essa história começou quando se observou que a comunidade precisava de maneiras eficientes para realizar votações em relação as novas mudanças propostas nos BIPS. O primeiro BIP que propôs isso foi o BIP9, datado de 4 de outubro de 2010 (https://github.com/bitc…/bips/blob/master/bip-0009.mediawiki). Nesse BIP era possível que nodes e mineradores entrassem em consenso sobre algum determinado assunto modificando apenas um bit 0 para um bit 1, criando uma espécie de democracia dentro do mundo das Bitcoins. Quando uma votação fosse feita, os nodes e os mineradores seriam notificados (através de canais públicos e de empresas vinculadas a atividade dos nodes e mineradores) e as modificações dos bits deveriam acontecer durante um tempo, e ao final teríamos uma votação. Pieter Wuille, Peter Todd, Greg Maxwell e Rusty Russell foram os autores dessa BIP.
Passado um tempo, veio o BIP que causaria o começo de toda a novela que vemos hoje: o BIP141 (https://github.com/bitc…/bips/blob/master/bip-0141.mediawiki) . Proposto em 21 de dezembro de 2015, esse BIP tratava do SegWit – uma espécie de método para a correção do problema de escalabilidade do Bitcoin que otimizava o algoritmo para poder receber menos dados (e consequentemente incluir mais transações em um único bloco), sem que nada fosse perdido durante o processo. O SegWit – que significa Segregated Witnesses, traduzido para testemunha segregada devido a maneira que ele lidava com os dados de identificação da transação (saiba mais aqui https://segwit.org/understanding-segregated-witness-905cc71… ) - era um ataque direto a algumas políticas ineficientes que o protocolo das Bitcoins mantinha em relação aos dados de uma transação, como já foi mencionado lá em cima no texto. O que ele argumentava era que as transações poderiam ser bem menores se alguns dados fossem incluídos de maneira mais inteligente nas transações, em especial os dados relacionados a assinatura de uma transação, chamados de “dados testemunha”. Agora não seria mais necessário enviar pilhas de dados referentes a assinatura da chave privada junto a transação (e se você tem alguma dúvida sobre o que é uma chave privada, consulte o primeiro episódio da série Bitcoin Professional no link aqui ).
A proposta de modificação gerou um certo apelo na comunidade em relação a segurança de uma transação. Ora, menos dados em relação a assinatura poderiam significar uma segurança menos robusta, algo que a comunidade do Bitcoin Core não aceitava de maneira fácil. Você pode ler uma explicação bem interessante sobre como o SegWit poderia afetar a segurança no seguinte link https://www.quora.com/How-does-Segwit-affect-security-of-Bi…. Inclusive essa resposta é a síntese da visão do pessoal do Bitcoin Core da comunidade sobre o gênesis do SegWit.
Para aliviar a proposta, a proposta estava sendo feita através de um chamado “soft fork”, que é uma modificação no software menos abrupta e com maior capacidade de atender a pessoas que não queiram realizar dessa nova mudança (ao contrário do hard fork, que essencialmente muda a essência da coisa e mata quem não quer adotar as novas mudanças) (A capacidade de atender a versões mais antigas de um software se chama backward compatibility). Lembrando que estamos falando de tecnologia descentralizada, e quanto menos agressivos formos, melhor – ainda mais quando falamos de dinheiro.
A ideia era realizar uma modificação do tamanho do bloco para conter um maior número de transações a serem incluídas era boa, mas como fazer isso em um soft fork? Quer dizer, como modificar algo tão fundamental no protocolo das transações sem prejudicar quem não quisesse participar da brincadeira?
A solução encontrada foi a seguinte: fazer uma espécie de “engana bobo” para as transações que não fossem do SegWit. Uma transação iria conter sua primeira parte compatível com nodes non-SegWit, mas uma segunda parte referente aos dados do SegWit para poder aproveitar as outras funções. Por um lado, isso é bem interessante, pois evita que todo mundo precise realizar algum tipo de atualização sob o risco de perder o trabalho feito. Mas por outro, isso pode causar problemas sérios, como por exemplo o fato de ainda estarmos limitados a 1MB do tamanho do bloco sem o SegWit (mesmo podendo incluir transações a mais e consequentemente mais fees). Soa como uma solução temporária e que logo precisaria passar por um hard fork.
A proposta do BIP141, que teve a participação de Pieter Wuille (o mesmo que fez a BIP9), Eric Lombrozo e Johnson Lau, trazia mais uma novidade para dentro do protocolo além da mudança na quantidade de transações contidas em um bloco: as microtransações, que apesar de não serem um assunto novo no ramo das criptomoedas, era a primeira vez que um BIP estava propondo a inclusão.
Eu explico: a quatro anos atrás era possível ter uma transação com fee 0 ser incluída em um bloco (inclusive, vejam uma discussão histórica nessa postagem do Reddit sobre o assunto. Quem é trader hoje quase não acredita como era no passado https://www.reddit.com/…/question_about_microtransactions_…/), mas hoje até mesmo uma fee ridiculamente alta pode fazer com que uma transação leve dias até ser incluída em um bloco. O conceito de micro transações vem para resolver esse problema através de uma rede chamada Lightining Network (Saiba os detalhes em https://lightning.network/), que aceita uma espécie de blockchain paralela para executar pagamentos pequenos com fees absurdamente baixas. Ela também aceita que uma determinada rota seja adotada entre nodes diferentes afim de confirmar mais rápido uma transação para as duas pontas.
Essa mudança também foi recebida de maneira genericamente boa, mas a maneira de implementar o Lightining Network parecia errada por parte de alguns desenvolvedores. A maior argumentação era que uma proposta como a Lightining Network poderia acabar com o conceito da Blockchain original, uma vez que os mineradores poderiam inserir uma grande quantidade de transações em um único bloco, centralizando a maior parte das transações e acabando com o conceito proposto por Satoshi Nakamoto. Teríamos poucos players com um alto poder de mineração (possivelmente um conglomerado chinês) controlando todas as transações. Isso abre portas para ataques do tipo 51%, onde uma entidade com 51% do poder de mineração pode fazer o que quiser com o dinheiro mesmo sem ter o poder da chave privada (saiba mais aqui http://www.btcpedia.com/bitcoin-51-attack/ ).
Alguns desenvolvedores do Bitcoin Core viram que essas mudanças não poderiam ser feitas usando um soft fork. Foi o que motivou a saída deles do projeto do Bitcoin Core para inaugurar o Bitcoin Unlimited em 1 de agosto de 2017. Uma nova moeda feita através de um hard fork que modifica o protocolo original idealizado por Satoshi Nakamoto, fazendo as alterações que os desenvolvedores julgaram necessárias. Esse protocolo estabelece que cada bloco poderá ter até 8MB de tamanho e abandona completamente o SegWit por conta da segurança, já explicado anteriormente.
O fork da Bitcoin Unlimited teve duas causas principais além da simples discordância pela qual o Bitcoin Core estava passando. A primeira foi um relatório feito por grandes mineradoras chinesas a respeito do tamanho do bloco que eles acreditavam ser o mais adequado. Segundo o documento, o tamanho ideal seria de 8Mb para um bloco, e não valeria a pena gastar o esforço com um soft fork. Para esse pessoal, o Bitcoin Unlimited seria a saída correta.
Aqui vale um esclarecimento para evitar confusões: Bitcoin está para Bitcoin Core assim como Bitcoin Cash está para Bitcoin Unlimited. As pessoas costumam fazer uma “bitsopa” com esse monte de Bitcoins, e não é atoa. O maior problema dessa confusão é que a implementação do Bitcoin puro de Satoshi Nakamoto feita pela Bitcoin Core recebeu o nome de Bitcoin, ficando difícil distinguir o protocolo da moeda em si. Já a Bitcoin Unlimited facilitou: o protocolo é Bitcoin Unlimited e a implementação dela é a Bitcoin Cash.
Nós vamos passar por toda a história até o fork da Bitcoin Unlimited. Você vai entender exatamente o que aconteceu.
Existem outros argumentos contra o soft fork e o SegWit (e você pode encontra-los aqui https://medium.com/…/why-we-must-oppose-cores-segwit-soft-f… e aqui https://medium.com/…/why-we-dont-support-segwit-91d44475cc18)
No meio desse caminho, um acordo foi firmado para reforçar as ideias do SegWit, acordo que ficou conhecido como Acordo de Hong Kong (Hong Kong Agreement), feito em 21 de fevereiro de 2016, bem antes do surgimento do Bitcoin Unlimited, feito no Hong Kong’s Cyberport - uma espécie de centro de convenções voltado ao mundo digital -(veja mais sobre o acordo aqui https://medium.com/…/bitcoin-roundtable-consensus-266d475a6… ). Grandes nomes das Bitcoins estavam presentes no acordo, como a AntPool, Bitfinex, BTCC, Genesis Mining e vários desenvolvedores do Bitcoin Core, incluindo Johnson Lau, que também tem seu nome na lista dos autores do BIP141. Nesse acordo ficou resolvido o seguinte:
- O SegWit vai continuar sendo desenvolvido através de um soft fork, igual já estava sendo feito, com o lançamento esperado para 2 meses (no caso seria abril de 2016) e implementação em mais um mês (maio de 2016).
- A comunidade, juntamente ao pessoal da Bitcoin Core, vai desenvolver uma maneira segura de fazer um hard-fork das implementações do SegWit, apresentando uma proposta em até 3 meses depois do lançamento do SegWit (agosto de 2016).
- Depois disso, será feita uma votação. Caso a comunidade aceite o hard fork com 95% dos votos, possivelmente ela entrará no ar em julho de 2017 (aproximadamente 1 ano após a disponibilização do código).
Parecia uma boa ideia, realizada de maneira calma e pacífica em relação ao que havia sido feito. Só que houveram problemas na parte prática do acordo.
O primeiro problema é que uma galera mudou de lado poucos meses depois de ter assinado o acordo, sinalizando suporte ao Bitcoin Unlimited. Antpool e Bitmain foram alguns dos nomes que “viraram a casaca” para suportar um protocolo que fosse melhorado ao longo do tempo. A razão dessa mudança de lado possivelmente foi o que aconteceu com o Etherum e o Etherum Classic: a nova moeda muito provavelmente ultrapassaria a antiga de valor por ser mais evoluída e mantida pelos mesmos criadores da primeira.
O segundo problema era o título de representatividade que esses “agreements” teriam. Empresas grandes ficaram de fora de desse acordo, como a Poloniex e a Kraken, podendo sinalizar que algo estava errado. A parte interessante é que todo mundo, tanto quem estava e quem não estava no acordo, concordou que o BIP141 deveria ser executado com a backward compatibility.
O terceiro e maior problema foi que o BIP141 não recebeu a atenção que deveria receber. Era esperado que o código fosse ativado quando tivesse 95% de aprovação da rede, sendo que somente uma parte muito pequena dos mineradores e nodes entraram nessa briga de alguma forma, mesmo com o acordo firmado.
Existem muitas razões que pairam os motivos pelo qual o pessoal sabia da necessidade do SegWit mas estava abandonando o barco em relação a BIP141. Uma delas é a chance de que seria muito mais interessante para os mineradores aumentarem o tamanho do bloco por conta de um fator chamado ASIC BOOST, que essencialmente ia permitir que os donos das mineradoras grandes(em especial as grandes que deram para trás no Hong Kong agrément) faturassem muito mais dinheiro sem o segwit e minerando uma moeda nova, como o Bitcoin Unlimited (uma vez que aumenta o tamanho do bloco aumenta a centralização dos mineradores). Para se ter ideia do quão real é essa teoria, o protocolo da Bitcoin Unlimited através do Bitcoin Cash tem hoje mais hashpower do que a Bitcoin comum. Quanto tempo o Bitcoin Unlimited tem? Analise esse gráfico aqui e veja a queda absurda o hashpower da Bitcoin comum (aqui: https://blockchain.info/charts/hash-rate?timespan=1year) e cruze as datas com o lançamento da Bitcoin Cash (1 de agosto) e de sua valorização. Essencialmente os mineradores estão brigando pela centralização neles.
Vale lembrar que o Bitcoin Unlimited só foi lançado em 22 de julho de 2017, logo após os desenvolvedores perderem as esperanças no SegWit (e depois no SegWit2mb) para resolver o problema das transações.
Entre esse meio tempo, em 31 de março de 2017, surge a primeira proposta do que é hoje conhecido como SegWit2x. Essencialmente ele é uma combinação de um soft e um hard fork, com o objetivo de evitar que a comunidade se divida ainda mais e acabe resultando na proposta que veio a seguir. Se você quiser ler o e-mail que fala do SegWit2x – ou SegWit2 ou SegWit2mb, leia https://lists.linuxfoundation.org/…/…/2017-March/013921.html.
A proposta do SegWit2x era duplicar o tamanho do bloco para atender o interesse dos mineradores, e ao mesmo tempo facilitar para quem estava querendo manter-se no protocolo original, junto com o Bitcoin Core. A única coisa que o SegWit2x precisava era de testar a coisa toda.
Com o fracasso do BIP141, veio a bomba que dividiu por inteiro a comunidade: o temido BIP148 (https://github.com/bitc…/bips/blob/master/bip-0148.mediawiki) , de 22 de maio de 2017. Esse BIP era a proposta de implementação do “soft fork” – entre aspas e explico o porquê - pela Bitcoin Core apresentado anteriormente que essencialmente dizia “gostem vocês ou não, o protocolo precisa ser melhorado, e quem não concordar nós vamos fazer um fork e abandonar os blocos de vocês para quem quiser continuar nesse barco”.
Mas a ideia inicial não era fazer um soft fork na boa e manter o desenvolvimento pra todo mundo? O pessoal não falou lá no acordo de Hong Kong que o processo ia ser tranquilo? E o mais importante: O SOFT FORK NÃO IA GARANTIR A COMPATIBILIDADE ENTRE TODO MUNDO E SERÍAMOS TODOS FELIZES? O pessoal do Bitcoin Core pode fazer isso?
Treta. Vamos por partes.
Revisemos o plano inicial: Primeiro um soft fork de boas, depois que já tiver tudo testado, ai fazemos um hard fork para não dar problemas pra ninguém. O problema é que geral cagou pra essa ideia.
E o que estava sendo dito no BIP148: O bagulho é o seguinte, SegWit tá feito, vamos fazer um “soft fork” da seguinte forma: quem gostar do SegWit vai ficar no nosso time, e quem não gostar nós vamos chutar o pau da barraca pro desenvolvimento de vocês e vocês vão virar uma outra moeda (chamada Legacy BTC).
Teoricamente isso é um “soft fork” pra uns e um “hard fork” pra quem discordar do “soft fork”.E para poder fazer essa ativação, tem duas coisas:
- Durante o dia 1 de agosto e 15 de novembro de 2017, vai rolar a votação.
- Se 95% dos envolvidos votarem para fazer o SeqWit, ai vai ter a implementação pacífica dele e tudo seguirá seu rumo.
- Se mais de 25% e menos de 90% aceitarem o SegWit, então vai ter uma divisão em duas moedas.
- Menos de 25%, nada acontece.
E adivinhem o que aconteceu? Você acha que todo mundo ficou assustado e resolveu dar seu voto pró-segwit? Você acha que aconteceu igual a Coréia do Norte com 100% de aprovação para Kim Naka SegWit?
Não, aparentemente iam reprovar o BIP148 por insuficiência de votos. O mercado estava falando para o pessoal do Bitcoin Core ser mais agressivo na hora de propor uma mudança e menos agressivo no impacto que essa mudança iria causar. O apelido “vanilla aproval”, que essencialmente era uma zoeira com o fato do pessoal da Bitcoin Core pedir 95% de aprovação, ficava cada vez mais comum . A briga foi tão grande que era necessário fazer uma nova reunião e ver o que poderia ser feito para salvar a Bitcoin.
Em 22 de maio de 2017, surgiu a proposta do BIP91. Essencialmente essa proposta entendia que o SegWit em si não tinha sido aprovado por conta dos mineradores e do tamanho do bloco e por isso foi inserido o SegWit2mb. Ao contrário do BIP141 e do BIP148, o SegWit2x não tinha nem 6 meses de maturidade e estava sendo inserido em um BIP, pasme, UMA SEMANA ANTES DO INICIO DA VOTAÇÃO. A votação segundo o BIP deveria ser iniciada em 1 de junho de 2017 e deveria terminar em 15 de novembro de 2017.
Para poder resolver esse problema, uma nova reunião do consenso foi feita. Foi ai que rolou a segunda reunião do consenso: O New York Agreement, feito em 25 de maio de 2017, que colocou um pouco de lado o foco na descentralização do Bitcoin e propôs algumas mudanças na proposta do BIP148, entre elas:
- Aceitar a proposta do SegWit2x em detrimento do SegWit;
- Aprovar o SegWit2x com 80% ao invés de 95%;
- No caso, com a inclusão do SegWit2x, o bloco teria 2MB e não 1MB. Era um favorecimento singelo a centralização da mineração.
- Ativar um hard fork 6 meses após com a aprovação do SegWit2x.
O mais sinistro dessa reunião foi que ela conseguiu 83,5% de aprovação nas assinaturas. Empresas como Coinbase, Xapo apareceram nesse consenso, junto a várias outras no mercado. Dessa vez as coisas pareciam que iam andar – pelo menos para quem acreditava no SegWit2x.
Não satisfeito com o resultado da SegWit2x, foi feito em 22 de julho de 2017 o anuncio oficial da Bitcoin Unlimited. Criou-se a moeda com 8MB de bloco, 8 vezes mais transação na mão de quem tem um hashpower alto.
Passada toda essa história, vamos ao momento presente
Aconteceu ontem um soft fork do SegWit2x, onde os nodes e mineradores atualizaram suas caçambas para poder atender as novas transações. Tudo aparentemente está correndo bem e nenhum sangue foi derramado (ainda). Caso isso ocorra, o hard fork será suspenso. Caso não, dia 15 de novembro vai ter o hard fork incluindo o SegWit2x no protocolo padrão da Bitcoin Core.
Duas coisas que valem ser mencionadas: outros softwares de nodes já haviam sinalizado o suporte ao SegWit2x antes do Bitcoin Core. O que está ocorrendo aqui é que a representação oficial do protocolo de Satoshi Nakamoto vai oficializar o SegWit2x.
A segunda coisa é que ainda é necessário assistir o comportamento de outras empresas que não assinaram o acordo de Nova York para saber como elas vão se comportar após o hard fork. Muito provavelmente nada de mais vai acontecer, mas essa não é uma verdade absoluta.
Por fim, gostaria de deixar minha opinião formalizada:
Toda essa história é o exemplo de um algoritmo de PoW ruim, sem ASIC Resistence. A Bitcoin tem MUITO o que aprender com as novas moedas e logo logo vai passar por um corredor polonês de problemas por conta desse tipo de atitude.
Muitos das tretas que vimos aqui poderiam ter sido sanadas se mais coisas fossem feitas de maneira mais aberta. Eu tive um GIGANTESCO trabalho para reunir essas informações em um compilado que falasse da história citando datas e documentos originais. Tudo ainda é muito “meu mundinho e minhas regras”, especialmente na hora de propor os BIPS (o texto é ruim, confuso e muitas vezes não explica nada com nada).
Imagine uma sala de aula do Bitcoin e nas cadeiras estão sentados:
- O minerador, que é aquele badboy egoísta que só liga pra ele.
- O node, que é aquele cara descolado que “ta na pista pra negócio”.
- O pró-BIP141, que é o pacifista que houve John Lenon.
- O pró-BIP148, que é aquele cara que senta no canto e não fala com ninguém e que só abre a boca pra ver o circo pegar fogo.
- A SegWit, que é a paixão do BIP141.
- A SegWit2x que da uns pegas tanto no BIP141 quanto no BadBoy.
- O BIP61, que caiu de paraquedas na sala e todo mundo gosta dele.
- A Bitcoin Unlimited, que é a chacrede dos mineradores e taca o foda-se pra todo mundo.
- O Bitcoin Core, que é aquele nerd metido a manda chuva.
E eu, que não gosto de ninguém na turma porque acho que todo mundo tá errado nessa porra. Eu acho que todo mundo ai tem sua parcela de culpa e tem que se fuder igual.
Honestamente pra mim não é um problema ver o Bitcoin enquanto moeda falir se o Bitcoin enquanto filosofia vai se fortalecer.
Por mais que ache que toda essa treta foi de certa forma benéfica para a consciência liberal, o fato de que poucas pessoas sabiam de fato o que estava acontecendo me fez pensar que falta publicidade nesse mundo. Existem pouquíssimos materiais falando sobre toda essa treta e nenhum compilado sobre tudo o que aconteceu e está para acontecer. Por quê? “Bring back the 90’s community-driven people”.
É assim que eu vejo essa história toda. Uma grande Kim Kardashianzada tecnológica sem necessidade e com pouca publicidade.
Se faltou algum link para fontes, me avisem. Qualquer dúvida comente e qualquer sugestão ou correção, me avisem sem dó. Volto a repetir, EU NÃO TENHO COMPROMISSO COM O ERRO.
"""""""""""""""""
Link original:
Autor do artigo: Benjamin Overture
[Absolutamente tudo o que você precisa saber para entender a treta do SegWit, SegWit2x, BIP144, BIP148 e amigos]
Eu sei, estou atrasado, mas confia no tio que ainda tem muita coisa para falar e muita gente que não sabe.
Estou escrevendo essa pequena postagem porque eu achava que sabia o que estava acontecendo de verdade nos forks – e eu fui provado errado. Estou a meses acompanhando fóruns gringos sobre as modificações e a quantidade de divergências, tanto filosóficas quanto técnicas, é tão grande que chega a ser difícil estabelecer os conceitos mais simples. Minha filosofia é o que está me mantendo acordado na madrugada de hoje para escrever essa postagem afim de evitar que mais pessoas caiam naquele limbo de não saber por onde começar a ler.
Ok, antes de começar a nossa versão TI das Kardashians, ficam algumas mensagens.
Antes de falar qualquer coisa sobre o SegWit2x, gostaria de dizer que o segundo capítulo da série Bitcoin Professional está 99,99% concluído e que ela não deve contemplar as transações dos forks que ocorreram nos últimos meses (relembro que o módulo 2 é sobre transações). Faço isso por 2 razões: a primeira é que o conteúdo está gigante (são 11 páginas do Word sem margem com fonte monoespaçada tamanho 11), e modifica-lo para atender ao SegWit2x levaria mais tempo (calculo o dobro) e mais palavras (possivelmente o dobro caso eu tivesse que explicar essa treta), e a segunda é que pretendo fazer as coisas em separado – um artigo para explicar a treta, um para explicar transações e outro para explicar as modificações das transações em relação ao SegWit. Este ultimo artigo deverá ser feito somente ao final da Série.
Eu tô tentando estudar o fork de maneira técnica e abstrata ao mesmo tempo. O objetivo do meu estudo foi – e ainda é – prover informação tanto para quem é das TI quanto para quem é das finanças. Isso pode ser considerado um erro pelos dois lados, uma vez que o nível de abstração dos dois por si só já é profundo o bastante para ser humanamente possível fazer isso e manter a boa qualidade na postagem.
O ato de fazer um “fork” – que essencialmente significa você pegar um programa e modifica-lo, diferente do “clone” que você não modifica nada – gera problemas gigantescos em tecnologias distribuídas e descentralizadas. Pode ser que um fork mantenha a compatibilidade com programas antigos que não queiram seguir o mesmo fork que você, pode ser que não (e em alguns casos por uma boa razão). Tudo isso transforma o ambiente da tecnologia em algo semelhante a política: é praticamente impossível não ter um lado, já que cada opção tem argumentos prós e contras. Eu tenho meu palpite sobre o que EU acho que está certo ou errado, outras pessoas têm os dela, mas aqui a minha tentativa é apresentar mais argumentos. Entretanto, eu vou deixar extremamente claro qual é a minha opinião quanto aos assuntos que vamos abordar.
[Treta parte 1 - A sociedade da Treta]
Antes de explicar a treta, vamos abordar conhecimentos básicos sobre o que vamos falar na treta. O primeiro desses conceitos é o conceito de Node (ou nó, na tradução em português). Eu poderia passar batido por esse conceito, mas notei que nos últimos dias tem rolado uma movimentação muito grande de novatos por aqui.
Imagine que você e um amigo seu decidam fazer compras no supermercado e, para agilizar as compras, ambos decidam se separar em partes diferentes do supermercado, cada um com seu carrinho. Para poder controlar as compras, os dois imprimem exatamente a mesma lista de compras e acordam enviar mensagens pelo celular toda vez que encontrarem um item da lista, afim de deixar as listas sincronizadas. As mensagens devem conter o nome e o preço pago no item da lista, em seguida cada um anota em sua lista de compras o que foi comprado e o preço. Ao final, espera-se que ambos tenham exatamente os mesmos dados na lista, correto?
Essencialmente é esse o conceito de um node de Bitcoin. Toda vez que alguém faz uma transação algum (ou alguns) nodes recebem essa transação e inserem ela na rede (através de mineradores, processo que não vamos falar nessa postagem). Em seguida, o consenso é feito e consequentemente os outros Nodes também confirmam aquelas transações em suas réplicas centrais das transações. Perceba que não existe nenhum “Node principal”, afinal o objetivo de um Node é ser mais um dentro de uma cadeia afim de garantir a descentralização da rede. Se um node morrer, grandes são as chances de nada acontecer.
Para que os nodes funcionem, existem alguns programas que executam funções relevantes a um node (como copiar outros nodes, como verificar transações realizadas naquele node, etc). Os conceitos que permeiam as Bitcoins são públicos e qualquer pessoa pode desenvolver um programa que siga esses conceitos para participar da rede, estando sujeito somente aos protocolos da própria internet para enviar e receber essas informações. Seria como levarmos em consideração o celular que você está usando para enviar as mensagens ao seu amigo no supermercado, ou seja, não faz muita diferença qual celular você esteja usando desde que ele cumpra bem as funções de enviar e receber as mensagens.
Existem várias interpretações do protocolo da Bitcoin em software, mas sem dúvidas a mais notável delas é o Bitcoin Core (projeto aqui https://bitcoin.org/en/bitcoin-core/ ). Seus desenvolvedores são anciãos devotos de Satoshi Nakamoto e sua biblioteca vem ficando cada vez mais robusta graças a exaustiva análise de cada modificação submetida para inclusão no software, em especial as análises relacionadas aos padrões do protocolo. No começo dessa treta toda, 2/3 dos nodes de BTC estavam rodando o produto da Bitcoin Core.
Agora imagine a seguinte situação: supondo que houvesse uma “falha” no protocolo da Bitcoin – no protocolo, e não na implementação do Bitcoin Core. De quem é a responsabilidade de corrigir essa falha? Se você disser que essa responsabilidade é de quem fez o protocolo, eu vou te dar uma resposta ignorante como “Tá, e dai?”, porque modificar um pedaço de papel sem modificar o código não muda absolutamente nada no mundo real – sem contar que até hoje não sabemos com certeza quem é o cara que fez o protocolo, o que tornaria ainda mais inútil essa discussão. Se você falar que a responsabilidade é dos desenvolvedores da Bitcoin Core, eu vou falar que você está dando muito poder a uma única instituição de falar o que é e o que não é o Bitcoin, centralizando a coisa toda e acabando com a oportunidade dos outros 1/3 do mercado de participarem de maneira consensual. Se você falar que a culpa é da comunidade, que não se atentou para isso, eu vou dizer que isso é verdade, mas que eles por si não poderiam fazer nada além de uma manifestação para que as demais entidades envolvidas (Tanto o Bitcoin enquanto protocolo, quanto o Bitcoin Core, quanto os demais entes) tomassem alguma providência em relação a isso. A comunidade até tentou resolver essa situação se adiantando (e criando uma nova moeda), mas o peso que o Bitcoin e o Bitcoin Core têm na filosofia é muito grande, sendo difícil competir.
E foi exatamente o que aconteceu, o protocolo tinha uma falha na hora de lidar com muitas transações. O problema era o seguinte: toda vez que uma transação era feita ela precisava ser enviada para um node e aguardar até que um bloco que incluísse aquela transação fosse minerado. Só assim essa transação começaria a se espalhar pela rede. O método em si é interessante, já que assim poderíamos garantir a integridade dos nodes de maneira independente e centralizada, mas havia um problema com isso.
Os dados de uma transação pesam, em média, algo próximo a 500 bytes (esse valor pode variar por razões que pretendo explicar no próximo artigo da Bitcoin Professional), e um bloco pode conter, no máximo, 1MB de tamanho, dividido em várias transações. Os blocos que forem enviados com mais de 1MB serão recusados por conta da regra do consenso (que existe para evitar que se incluam todas as transações em um único bloco, centralizando os pagamentos das taxas de mineração a quem tem mais poder de mineração, acabando mineradores menores). Um bloco, mesmo podendo colocar mais de 1800 transações a serem mineradas, e mesmo com os crescentes números de mineradores, estava ficando pequeno demais para que valesse a pena fazer transferências pequenas.
E os mineradores, nada bobos, estavam começando a aceitar somente fees grandes para poderem continuar minerando as transações que eram inseridas em seus blocos. Não seria mais possível transacionar valores pequenos, já que as tarifas e a demora não compensariam para quem receberia o dinheiro. Esse era o problema da escalabilidade do protocolo.
[ Treta parte 2 – Os dois hard forks ]
A solução do livre mercado era simples: Ora, se existe demanda, em breve vai existir oferta. Quer dizer, se está faltando poder de mineração, então novos mineradores vão surgir para faturar essa grana, certo?
Não foi bem o que aconteceu, já que moramos em um mundo onde o mercado raramente funciona como deveria. Os mineradores começavam a não aguentar a carga de transações e isso poderia prejudicar todo o ecossistema das Bitcoins. Essa responsabilidade tem de ser dividida com um monte de gente (mineradores, o Estado, os criadores do protocolo, quem não otimiza algoritmo de seleção de UTXOs, entre outros). Como ninguém dos outros setores deu uma resposta satisfatória, entraram em ação as propostas de mudança de protocolo. Desse modo, independente das vontades privadas, uma decisão precisava ser tomada ou todo mundo seria prejudicado.
A maneira de se implementar uma mudança no protocolo da Bitcoin é através de uma BIP (Bitcoin Improvement Proposal, ou Proposta de Melhoria do Bitcoin) no próprio BIP1 você pode consultar exatamente o que é um BIP e como ele funciona (https://github.com/bitc…/bips/blob/master/bip-0001.mediawiki). Como você pode ver na figura do fluxograma disponibilizado na página, cada BIP é executada após a anterior ser implementada, e assim elas vão ocorrendo.
Quem discordar de um BIP poderá fazer duas coisas, a primeira é criar uma moeda própria (o que muitos desenvolvedores estão fazendo), copiando o código de um node (sendo ele feito pelo Bitcoin Core ou não) e modificando de acordo com o seu gosto, ou fazer um fork baseado em uma moeda já existente, copiando os dados de quem tem uma moeda e entregando para o mesmo dono daquela chave privada na outra rede. Seria como clonar sua carteira, com a diferença que na nova carteira você terá uma flutuação diferente do dinheiro (outra cotação, outra moeda, tudo novo).
Praticamente todas as situações acima ocorreram. Teve gente criando moeda, fazendo fork e tentando mudar o protocolo. E foi assim que aconteceu.
[Quando a treta começou?]
Toda essa história começou quando se observou que a comunidade precisava de maneiras eficientes para realizar votações em relação as novas mudanças propostas nos BIPS. O primeiro BIP que propôs isso foi o BIP9, datado de 4 de outubro de 2010 (https://github.com/bitc…/bips/blob/master/bip-0009.mediawiki). Nesse BIP era possível que nodes e mineradores entrassem em consenso sobre algum determinado assunto modificando apenas um bit 0 para um bit 1, criando uma espécie de democracia dentro do mundo das Bitcoins. Quando uma votação fosse feita, os nodes e os mineradores seriam notificados (através de canais públicos e de empresas vinculadas a atividade dos nodes e mineradores) e as modificações dos bits deveriam acontecer durante um tempo, e ao final teríamos uma votação. Pieter Wuille, Peter Todd, Greg Maxwell e Rusty Russell foram os autores dessa BIP.
Passado um tempo, veio o BIP que causaria o começo de toda a novela que vemos hoje: o BIP141 (https://github.com/bitc…/bips/blob/master/bip-0141.mediawiki) . Proposto em 21 de dezembro de 2015, esse BIP tratava do SegWit – uma espécie de método para a correção do problema de escalabilidade do Bitcoin que otimizava o algoritmo para poder receber menos dados (e consequentemente incluir mais transações em um único bloco), sem que nada fosse perdido durante o processo. O SegWit – que significa Segregated Witnesses, traduzido para testemunha segregada devido a maneira que ele lidava com os dados de identificação da transação (saiba mais aqui https://segwit.org/understanding-segregated-witness-905cc71… ) - era um ataque direto a algumas políticas ineficientes que o protocolo das Bitcoins mantinha em relação aos dados de uma transação, como já foi mencionado lá em cima no texto. O que ele argumentava era que as transações poderiam ser bem menores se alguns dados fossem incluídos de maneira mais inteligente nas transações, em especial os dados relacionados a assinatura de uma transação, chamados de “dados testemunha”. Agora não seria mais necessário enviar pilhas de dados referentes a assinatura da chave privada junto a transação (e se você tem alguma dúvida sobre o que é uma chave privada, consulte o primeiro episódio da série Bitcoin Professional no link aqui ).
A proposta de modificação gerou um certo apelo na comunidade em relação a segurança de uma transação. Ora, menos dados em relação a assinatura poderiam significar uma segurança menos robusta, algo que a comunidade do Bitcoin Core não aceitava de maneira fácil. Você pode ler uma explicação bem interessante sobre como o SegWit poderia afetar a segurança no seguinte link https://www.quora.com/How-does-Segwit-affect-security-of-Bi…. Inclusive essa resposta é a síntese da visão do pessoal do Bitcoin Core da comunidade sobre o gênesis do SegWit.
Para aliviar a proposta, a proposta estava sendo feita através de um chamado “soft fork”, que é uma modificação no software menos abrupta e com maior capacidade de atender a pessoas que não queiram realizar dessa nova mudança (ao contrário do hard fork, que essencialmente muda a essência da coisa e mata quem não quer adotar as novas mudanças) (A capacidade de atender a versões mais antigas de um software se chama backward compatibility). Lembrando que estamos falando de tecnologia descentralizada, e quanto menos agressivos formos, melhor – ainda mais quando falamos de dinheiro.
A ideia era realizar uma modificação do tamanho do bloco para conter um maior número de transações a serem incluídas era boa, mas como fazer isso em um soft fork? Quer dizer, como modificar algo tão fundamental no protocolo das transações sem prejudicar quem não quisesse participar da brincadeira?
A solução encontrada foi a seguinte: fazer uma espécie de “engana bobo” para as transações que não fossem do SegWit. Uma transação iria conter sua primeira parte compatível com nodes non-SegWit, mas uma segunda parte referente aos dados do SegWit para poder aproveitar as outras funções. Por um lado, isso é bem interessante, pois evita que todo mundo precise realizar algum tipo de atualização sob o risco de perder o trabalho feito. Mas por outro, isso pode causar problemas sérios, como por exemplo o fato de ainda estarmos limitados a 1MB do tamanho do bloco sem o SegWit (mesmo podendo incluir transações a mais e consequentemente mais fees). Soa como uma solução temporária e que logo precisaria passar por um hard fork.
A proposta do BIP141, que teve a participação de Pieter Wuille (o mesmo que fez a BIP9), Eric Lombrozo e Johnson Lau, trazia mais uma novidade para dentro do protocolo além da mudança na quantidade de transações contidas em um bloco: as microtransações, que apesar de não serem um assunto novo no ramo das criptomoedas, era a primeira vez que um BIP estava propondo a inclusão.
Eu explico: a quatro anos atrás era possível ter uma transação com fee 0 ser incluída em um bloco (inclusive, vejam uma discussão histórica nessa postagem do Reddit sobre o assunto. Quem é trader hoje quase não acredita como era no passado https://www.reddit.com/…/question_about_microtransactions_…/), mas hoje até mesmo uma fee ridiculamente alta pode fazer com que uma transação leve dias até ser incluída em um bloco. O conceito de micro transações vem para resolver esse problema através de uma rede chamada Lightining Network (Saiba os detalhes em https://lightning.network/), que aceita uma espécie de blockchain paralela para executar pagamentos pequenos com fees absurdamente baixas. Ela também aceita que uma determinada rota seja adotada entre nodes diferentes afim de confirmar mais rápido uma transação para as duas pontas.
Essa mudança também foi recebida de maneira genericamente boa, mas a maneira de implementar o Lightining Network parecia errada por parte de alguns desenvolvedores. A maior argumentação era que uma proposta como a Lightining Network poderia acabar com o conceito da Blockchain original, uma vez que os mineradores poderiam inserir uma grande quantidade de transações em um único bloco, centralizando a maior parte das transações e acabando com o conceito proposto por Satoshi Nakamoto. Teríamos poucos players com um alto poder de mineração (possivelmente um conglomerado chinês) controlando todas as transações. Isso abre portas para ataques do tipo 51%, onde uma entidade com 51% do poder de mineração pode fazer o que quiser com o dinheiro mesmo sem ter o poder da chave privada (saiba mais aqui http://www.btcpedia.com/bitcoin-51-attack/ ).
Alguns desenvolvedores do Bitcoin Core viram que essas mudanças não poderiam ser feitas usando um soft fork. Foi o que motivou a saída deles do projeto do Bitcoin Core para inaugurar o Bitcoin Unlimited em 1 de agosto de 2017. Uma nova moeda feita através de um hard fork que modifica o protocolo original idealizado por Satoshi Nakamoto, fazendo as alterações que os desenvolvedores julgaram necessárias. Esse protocolo estabelece que cada bloco poderá ter até 8MB de tamanho e abandona completamente o SegWit por conta da segurança, já explicado anteriormente.
O fork da Bitcoin Unlimited teve duas causas principais além da simples discordância pela qual o Bitcoin Core estava passando. A primeira foi um relatório feito por grandes mineradoras chinesas a respeito do tamanho do bloco que eles acreditavam ser o mais adequado. Segundo o documento, o tamanho ideal seria de 8Mb para um bloco, e não valeria a pena gastar o esforço com um soft fork. Para esse pessoal, o Bitcoin Unlimited seria a saída correta.
Aqui vale um esclarecimento para evitar confusões: Bitcoin está para Bitcoin Core assim como Bitcoin Cash está para Bitcoin Unlimited. As pessoas costumam fazer uma “bitsopa” com esse monte de Bitcoins, e não é atoa. O maior problema dessa confusão é que a implementação do Bitcoin puro de Satoshi Nakamoto feita pela Bitcoin Core recebeu o nome de Bitcoin, ficando difícil distinguir o protocolo da moeda em si. Já a Bitcoin Unlimited facilitou: o protocolo é Bitcoin Unlimited e a implementação dela é a Bitcoin Cash.
Nós vamos passar por toda a história até o fork da Bitcoin Unlimited. Você vai entender exatamente o que aconteceu.
Existem outros argumentos contra o soft fork e o SegWit (e você pode encontra-los aqui https://medium.com/…/why-we-must-oppose-cores-segwit-soft-f… e aqui https://medium.com/…/why-we-dont-support-segwit-91d44475cc18)
No meio desse caminho, um acordo foi firmado para reforçar as ideias do SegWit, acordo que ficou conhecido como Acordo de Hong Kong (Hong Kong Agreement), feito em 21 de fevereiro de 2016, bem antes do surgimento do Bitcoin Unlimited, feito no Hong Kong’s Cyberport - uma espécie de centro de convenções voltado ao mundo digital -(veja mais sobre o acordo aqui https://medium.com/…/bitcoin-roundtable-consensus-266d475a6… ). Grandes nomes das Bitcoins estavam presentes no acordo, como a AntPool, Bitfinex, BTCC, Genesis Mining e vários desenvolvedores do Bitcoin Core, incluindo Johnson Lau, que também tem seu nome na lista dos autores do BIP141. Nesse acordo ficou resolvido o seguinte:
- O SegWit vai continuar sendo desenvolvido através de um soft fork, igual já estava sendo feito, com o lançamento esperado para 2 meses (no caso seria abril de 2016) e implementação em mais um mês (maio de 2016).
- A comunidade, juntamente ao pessoal da Bitcoin Core, vai desenvolver uma maneira segura de fazer um hard-fork das implementações do SegWit, apresentando uma proposta em até 3 meses depois do lançamento do SegWit (agosto de 2016).
- Depois disso, será feita uma votação. Caso a comunidade aceite o hard fork com 95% dos votos, possivelmente ela entrará no ar em julho de 2017 (aproximadamente 1 ano após a disponibilização do código).
Parecia uma boa ideia, realizada de maneira calma e pacífica em relação ao que havia sido feito. Só que houveram problemas na parte prática do acordo.
O primeiro problema é que uma galera mudou de lado poucos meses depois de ter assinado o acordo, sinalizando suporte ao Bitcoin Unlimited. Antpool e Bitmain foram alguns dos nomes que “viraram a casaca” para suportar um protocolo que fosse melhorado ao longo do tempo. A razão dessa mudança de lado possivelmente foi o que aconteceu com o Etherum e o Etherum Classic: a nova moeda muito provavelmente ultrapassaria a antiga de valor por ser mais evoluída e mantida pelos mesmos criadores da primeira.
O segundo problema era o título de representatividade que esses “agreements” teriam. Empresas grandes ficaram de fora de desse acordo, como a Poloniex e a Kraken, podendo sinalizar que algo estava errado. A parte interessante é que todo mundo, tanto quem estava e quem não estava no acordo, concordou que o BIP141 deveria ser executado com a backward compatibility.
O terceiro e maior problema foi que o BIP141 não recebeu a atenção que deveria receber. Era esperado que o código fosse ativado quando tivesse 95% de aprovação da rede, sendo que somente uma parte muito pequena dos mineradores e nodes entraram nessa briga de alguma forma, mesmo com o acordo firmado.
Existem muitas razões que pairam os motivos pelo qual o pessoal sabia da necessidade do SegWit mas estava abandonando o barco em relação a BIP141. Uma delas é a chance de que seria muito mais interessante para os mineradores aumentarem o tamanho do bloco por conta de um fator chamado ASIC BOOST, que essencialmente ia permitir que os donos das mineradoras grandes(em especial as grandes que deram para trás no Hong Kong agrément) faturassem muito mais dinheiro sem o segwit e minerando uma moeda nova, como o Bitcoin Unlimited (uma vez que aumenta o tamanho do bloco aumenta a centralização dos mineradores). Para se ter ideia do quão real é essa teoria, o protocolo da Bitcoin Unlimited através do Bitcoin Cash tem hoje mais hashpower do que a Bitcoin comum. Quanto tempo o Bitcoin Unlimited tem? Analise esse gráfico aqui e veja a queda absurda o hashpower da Bitcoin comum (aqui: https://blockchain.info/charts/hash-rate?timespan=1year) e cruze as datas com o lançamento da Bitcoin Cash (1 de agosto) e de sua valorização. Essencialmente os mineradores estão brigando pela centralização neles.
Vale lembrar que o Bitcoin Unlimited só foi lançado em 22 de julho de 2017, logo após os desenvolvedores perderem as esperanças no SegWit (e depois no SegWit2mb) para resolver o problema das transações.
Entre esse meio tempo, em 31 de março de 2017, surge a primeira proposta do que é hoje conhecido como SegWit2x. Essencialmente ele é uma combinação de um soft e um hard fork, com o objetivo de evitar que a comunidade se divida ainda mais e acabe resultando na proposta que veio a seguir. Se você quiser ler o e-mail que fala do SegWit2x – ou SegWit2 ou SegWit2mb, leia https://lists.linuxfoundation.org/…/…/2017-March/013921.html.
A proposta do SegWit2x era duplicar o tamanho do bloco para atender o interesse dos mineradores, e ao mesmo tempo facilitar para quem estava querendo manter-se no protocolo original, junto com o Bitcoin Core. A única coisa que o SegWit2x precisava era de testar a coisa toda.
Com o fracasso do BIP141, veio a bomba que dividiu por inteiro a comunidade: o temido BIP148 (https://github.com/bitc…/bips/blob/master/bip-0148.mediawiki) , de 22 de maio de 2017. Esse BIP era a proposta de implementação do “soft fork” – entre aspas e explico o porquê - pela Bitcoin Core apresentado anteriormente que essencialmente dizia “gostem vocês ou não, o protocolo precisa ser melhorado, e quem não concordar nós vamos fazer um fork e abandonar os blocos de vocês para quem quiser continuar nesse barco”.
Mas a ideia inicial não era fazer um soft fork na boa e manter o desenvolvimento pra todo mundo? O pessoal não falou lá no acordo de Hong Kong que o processo ia ser tranquilo? E o mais importante: O SOFT FORK NÃO IA GARANTIR A COMPATIBILIDADE ENTRE TODO MUNDO E SERÍAMOS TODOS FELIZES? O pessoal do Bitcoin Core pode fazer isso?
Treta. Vamos por partes.
Revisemos o plano inicial: Primeiro um soft fork de boas, depois que já tiver tudo testado, ai fazemos um hard fork para não dar problemas pra ninguém. O problema é que geral cagou pra essa ideia.
E o que estava sendo dito no BIP148: O bagulho é o seguinte, SegWit tá feito, vamos fazer um “soft fork” da seguinte forma: quem gostar do SegWit vai ficar no nosso time, e quem não gostar nós vamos chutar o pau da barraca pro desenvolvimento de vocês e vocês vão virar uma outra moeda (chamada Legacy BTC).
Teoricamente isso é um “soft fork” pra uns e um “hard fork” pra quem discordar do “soft fork”.E para poder fazer essa ativação, tem duas coisas:
- Durante o dia 1 de agosto e 15 de novembro de 2017, vai rolar a votação.
- Se 95% dos envolvidos votarem para fazer o SeqWit, ai vai ter a implementação pacífica dele e tudo seguirá seu rumo.
- Se mais de 25% e menos de 90% aceitarem o SegWit, então vai ter uma divisão em duas moedas.
- Menos de 25%, nada acontece.
E adivinhem o que aconteceu? Você acha que todo mundo ficou assustado e resolveu dar seu voto pró-segwit? Você acha que aconteceu igual a Coréia do Norte com 100% de aprovação para Kim Naka SegWit?
Não, aparentemente iam reprovar o BIP148 por insuficiência de votos. O mercado estava falando para o pessoal do Bitcoin Core ser mais agressivo na hora de propor uma mudança e menos agressivo no impacto que essa mudança iria causar. O apelido “vanilla aproval”, que essencialmente era uma zoeira com o fato do pessoal da Bitcoin Core pedir 95% de aprovação, ficava cada vez mais comum . A briga foi tão grande que era necessário fazer uma nova reunião e ver o que poderia ser feito para salvar a Bitcoin.
Em 22 de maio de 2017, surgiu a proposta do BIP91. Essencialmente essa proposta entendia que o SegWit em si não tinha sido aprovado por conta dos mineradores e do tamanho do bloco e por isso foi inserido o SegWit2mb. Ao contrário do BIP141 e do BIP148, o SegWit2x não tinha nem 6 meses de maturidade e estava sendo inserido em um BIP, pasme, UMA SEMANA ANTES DO INICIO DA VOTAÇÃO. A votação segundo o BIP deveria ser iniciada em 1 de junho de 2017 e deveria terminar em 15 de novembro de 2017.
Para poder resolver esse problema, uma nova reunião do consenso foi feita. Foi ai que rolou a segunda reunião do consenso: O New York Agreement, feito em 25 de maio de 2017, que colocou um pouco de lado o foco na descentralização do Bitcoin e propôs algumas mudanças na proposta do BIP148, entre elas:
- Aceitar a proposta do SegWit2x em detrimento do SegWit;
- Aprovar o SegWit2x com 80% ao invés de 95%;
- No caso, com a inclusão do SegWit2x, o bloco teria 2MB e não 1MB. Era um favorecimento singelo a centralização da mineração.
- Ativar um hard fork 6 meses após com a aprovação do SegWit2x.
O mais sinistro dessa reunião foi que ela conseguiu 83,5% de aprovação nas assinaturas. Empresas como Coinbase, Xapo apareceram nesse consenso, junto a várias outras no mercado. Dessa vez as coisas pareciam que iam andar – pelo menos para quem acreditava no SegWit2x.
Não satisfeito com o resultado da SegWit2x, foi feito em 22 de julho de 2017 o anuncio oficial da Bitcoin Unlimited. Criou-se a moeda com 8MB de bloco, 8 vezes mais transação na mão de quem tem um hashpower alto.
Passada toda essa história, vamos ao momento presente
Aconteceu ontem um soft fork do SegWit2x, onde os nodes e mineradores atualizaram suas caçambas para poder atender as novas transações. Tudo aparentemente está correndo bem e nenhum sangue foi derramado (ainda). Caso isso ocorra, o hard fork será suspenso. Caso não, dia 15 de novembro vai ter o hard fork incluindo o SegWit2x no protocolo padrão da Bitcoin Core.
Duas coisas que valem ser mencionadas: outros softwares de nodes já haviam sinalizado o suporte ao SegWit2x antes do Bitcoin Core. O que está ocorrendo aqui é que a representação oficial do protocolo de Satoshi Nakamoto vai oficializar o SegWit2x.
A segunda coisa é que ainda é necessário assistir o comportamento de outras empresas que não assinaram o acordo de Nova York para saber como elas vão se comportar após o hard fork. Muito provavelmente nada de mais vai acontecer, mas essa não é uma verdade absoluta.
Por fim, gostaria de deixar minha opinião formalizada:
Toda essa história é o exemplo de um algoritmo de PoW ruim, sem ASIC Resistence. A Bitcoin tem MUITO o que aprender com as novas moedas e logo logo vai passar por um corredor polonês de problemas por conta desse tipo de atitude.
Muitos das tretas que vimos aqui poderiam ter sido sanadas se mais coisas fossem feitas de maneira mais aberta. Eu tive um GIGANTESCO trabalho para reunir essas informações em um compilado que falasse da história citando datas e documentos originais. Tudo ainda é muito “meu mundinho e minhas regras”, especialmente na hora de propor os BIPS (o texto é ruim, confuso e muitas vezes não explica nada com nada).
Imagine uma sala de aula do Bitcoin e nas cadeiras estão sentados:
- O minerador, que é aquele badboy egoísta que só liga pra ele.
- O node, que é aquele cara descolado que “ta na pista pra negócio”.
- O pró-BIP141, que é o pacifista que houve John Lenon.
- O pró-BIP148, que é aquele cara que senta no canto e não fala com ninguém e que só abre a boca pra ver o circo pegar fogo.
- A SegWit, que é a paixão do BIP141.
- A SegWit2x que da uns pegas tanto no BIP141 quanto no BadBoy.
- O BIP61, que caiu de paraquedas na sala e todo mundo gosta dele.
- A Bitcoin Unlimited, que é a chacrede dos mineradores e taca o foda-se pra todo mundo.
- O Bitcoin Core, que é aquele nerd metido a manda chuva.
E eu, que não gosto de ninguém na turma porque acho que todo mundo tá errado nessa porra. Eu acho que todo mundo ai tem sua parcela de culpa e tem que se fuder igual.
Honestamente pra mim não é um problema ver o Bitcoin enquanto moeda falir se o Bitcoin enquanto filosofia vai se fortalecer.
Por mais que ache que toda essa treta foi de certa forma benéfica para a consciência liberal, o fato de que poucas pessoas sabiam de fato o que estava acontecendo me fez pensar que falta publicidade nesse mundo. Existem pouquíssimos materiais falando sobre toda essa treta e nenhum compilado sobre tudo o que aconteceu e está para acontecer. Por quê? “Bring back the 90’s community-driven people”.
É assim que eu vejo essa história toda. Uma grande Kim Kardashianzada tecnológica sem necessidade e com pouca publicidade.
Se faltou algum link para fontes, me avisem. Qualquer dúvida comente e qualquer sugestão ou correção, me avisem sem dó. Volto a repetir, EU NÃO TENHO COMPROMISSO COM O ERRO.
"""""""""""""""""
Link original:
Autor do artigo: Benjamin Overture
