BTC$76,978.00 7.3%
ETH$2,383.38 4.2%
XRP$1.40 18.2%
BNB$678.15 5.6%
SOL$90.97 4.4%
DOGE$0.0837 8.4%
ADA$0.2157 12.8%
TRX$0.3399 0.8%
LINK$11.38 7.5%
AVAX$7.56 10.0%
BTC$76,978.00 7.3%
ETH$2,383.38 4.2%
XRP$1.40 18.2%
BNB$678.15 5.6%
SOL$90.97 4.4%
DOGE$0.0837 8.4%
ADA$0.2157 12.8%
TRX$0.3399 0.8%
LINK$11.38 7.5%
AVAX$7.56 10.0%
Finanças On-Chain
PTEN

A ler: Código Aberto vs. Código Disponível: O Que o Caso Coldcard Ensina Sobre Incentivos no Software Bitcoin

Web3

Código Aberto vs. Código Disponível: O Que o Caso Coldcard Ensina Sobre Incentivos no Software Bitcoin

Fonte: Bitcoin Magazine·Publicado em 20/08/2026 às 23:03

Segundo um artigo da Bitcoin Magazine, a distinção entre código verdadeiramente aberto e código meramente visível divide a indústria Bitcoin há mais de uma década, mas a maioria das pessoas, incluindo muitos defensores fervorosos do Bitcoin, compreende mal estas diferenças fundamentais. O recente ataque à Coldcard, uma popular carteira física de auto-custódia, onde os utilizadores perderam mais de 100 milhões de dólares em bitcoin (mais de 1.500 BTC), trouxe esta questão para primeiro plano de forma dramática.

A confusão começa na própria terminologia. Software Livre e de Código Aberto (FOSS) e Software Livre/Livre e de Código Aberto (FLOSS) referem-se a software que cumpre definições formais de liberdade do utilizador. A Free Software Foundation define software livre através de quatro liberdades essenciais, enquanto a Open Source Initiative adiciona dez critérios práticos que incluem redistribuição livre sem royalties, disponibilidade do código-fonte na forma preferida para modificação, direito de criar e distribuir trabalhos derivados, e ausência de discriminação contra pessoas, grupos ou campos de atividade, incluindo uso comercial.

O firmware da Coldcard, porém, não se enquadra nestas definições rigorosas. Embora seja publicamente visível, é lançado sob licença MIT com a adição da Commons Clause, que remove especificamente o direito de vender o software. A própria documentação da Commons Clause esclarece sem ambiguidade: esta não é uma licença de código aberto. Esta distinção não é meramente técnica, argumentam os críticos, porque a liberdade comercial no software verdadeiramente aberto desbloqueia incentivos de terceiros para testar e rever código que de outra forma não existiriam.

As quatro liberdades do código aberto formam o núcleo filosófico, mas na prática assentam numa assunção económica crítica: que pessoas suficientemente motivadas examinarão efetivamente o código. Quando esta assunção falha, o sistema produz uma clássica tragédia dos comuns, onde um recurso partilhado é sobreutilizado ou negligenciado porque utilizadores individuais agem no seu interesse próprio de curto prazo em vez do interesse de longo prazo do grupo. Cada pessoa tem incentivo para receber mais ou contribuir menos do que é sustentável, e o recurso degrada-se como resultado.

Um programador do Bitcoin expressou o problema sem rodeios, afirmando que usar simulações de código aberto em testes é irresponsável e míope. Código aberto é considerado seguro porque qualquer pessoa pode verificá-lo, mas se alguém não está disposto a fazer o mínimo de testar as funcionalidades de que realmente depende, está a comportar-se como um parasita do sistema. Como resultado, código aberto não cria segurança por si só, apenas cria a possibilidade de verificação. Se essa verificação ocorre depende de incentivos, competência e atenção.

O Bitcoin Core, a implementação de referência do Bitcoin, representa um exemplo presciente de código aberto puro a funcionar em larga escala na prática. O software, que opera por trás da maior parte da infraestrutura relacionada com o Bitcoin, é lançado sob licença MIT e o seu processo de desenvolvimento é amplamente público por design. Qualquer pessoa pode abrir um pedido de alteração, sendo a revisão de código o filtro principal e o ponto de entrada recomendado para novos contribuidores. Os revisores usam vocabulário formal incluindo Concept ACK (concordância com o objetivo), Approach ACK (concordância com objetivo e método), ACK com hash específico (testado e aprovado para integração), ou NACK (discordância acompanhada de fundamentação técnica).

Os mantenedores do Bitcoin Core pesam o consenso entre contribuidores e os méritos técnicos de uma alteração antes de a integrar. Mudanças críticas ao consenso enfrentam um patamar ainda mais elevado e geralmente requerem uma Bitcoin Improvement Proposal e extensas discussões multi-anuais na lista de correio bitcoin-dev e no IRC. Não existe uma casta privilegiada de programadores do Bitcoin Core, sendo a confiança conquistada através de competência demonstrada ao longo do tempo, e os mantenedores existem por razões práticas de auditoria, integração de código, gestão de lançamentos e moderação básica.