Bitcoin 2022, hospedado em Miami, Flórida, de 6 a 9 de abril , apresentou um painel intitulado”Evitando ataques ao Bitcoin“com três Bitcoin Core desenvolvedores: Luke Dashjr, Bryan Bishop e Jameson Lopp (substituindo por Peter Todd). O painel foi moderado por Shinobi.
Os palestrantes discutem vetores de ataque técnico e social, principalmente em o processo de desenvolvimento do Bitcoin Core, que poderia atrapalhar ou inviabilizar totalmente a única missão do Bitcoin como dinheiro imutável. O propósito de um brainstorming aberto de vetores de ataque é formular medidas de defesa apropriadas e, como a estratégia “A Arte da Guerra” de Sun Tzu:
“Não confie que o inimigo não está vindo. Confie em sua prontidão para conhecê-lo. Não confie que o inimigo não atacará. Confie apenas em sua capacidade de escolher um local que o inimigo não possa atacar.”
A seguir está um resumo do referido painel com uma rápida visão geral do processo de desenvolvimento do Bitcoin Core.
p>
Breve visão geral do Bitcoin Core
Os desenvolvedores Bitcoin Core trabalham através de um processo de desenvolvimento para oferecer correções de bugs do protocolo Bitcoin, otimizações de software e recursos aprimorados; eles então publicam essas atualizações seguindo o consenso da comunidade por meio de Propostas de melhoria de Bitcoin (BIPs). Projetar com sucesso um ataque contra o processo de desenvolvimento, seja em nível técnico ou social, potencialmente impediria (às vezes críticas) atualizações de protocolo e incutiria desconfiança entre os desenvolvedores.
Para esclarecer, o Bitcoin Core é uma implementação de software livre e de código aberto de um Bitcoin completo nó, referido como cliente. Embora seja enganoso no nome, o Bitcoin Core não tem controle centralizado ou “núcleo” sobre a rede Bitcoin, mas serve como apenas um cliente possível que as pessoas podem usar a seu critério. Além disso, as regras de consenso do protocolo Bitcoin exigem que todos os nós completos do Bitcoin e participantes econômicos apliquem infalivelmente essas regras ao considerar a validade de um bloco.
Além disso, as atualizações do Bitcoin Core não são baixadas automaticamente, mas sim manualmente, pois atualizações automáticas de software fornecem um vetor de ataque para um agente malicioso comprometer todos os nós e mineradores em um único golpe.
A equipe de desenvolvedores do Bitcoin Core não pedestal um único líder ou porta-voz-distanciando assim o cliente e processo de desenvolvimento da exploração do caráter pessoal devido a falhas que todos os líderes terrenos possuem inerentemente. Por exemplo, líderes narcisistas podem ser enfraquecidos criando agitação em sua base de fãs, ou líderes mal-humorados podem se comportar irracionalmente quando provocados com insultos. Para derrubar um movimento iniciante, é preciso descartar habilmente seu líder ou quebrar seus seguidores.
Ainda sem um único líder, como os desenvolvedores independentes do Bitcoin Core chegam a um acordo sobre escolhas de design complexas ou correções de bugs de emergência? Os BIPs mencionados acima são usados no processo de desenvolvimento do Bitcoin Core para implementar recursos ou informações para o protocolo Bitcoin, mas os BIPs também trabalham para padronizar a comunicação de novas ideias, conforme esquematicamente descrito abaixo e conforme descrito em BIP 1:
Como podemos atrapalhar esse processo? Apesar de introduzir alguma formalidade via BIP 1 em uma rede não estruturada, há uma oportunidade para atores mal-intencionados ou simplesmente mal orientados subverterem o processo de desenvolvimento por meios técnicos e sociais. Reconhecer essa “chave”, no entanto, geralmente só é possível em retrospectiva – tornando certos vetores de ataque especialmente difíceis de detectar e evitar. Se você pode se esquivar de uma chave inglesa, pode se esquivar de um desenvolvedor desviante determinado a empurrar sua agenda de autoatendimento às custas do Bitcoin.
Na prática, as implementações reais de BIP não são tão organizadas quanto um diagrama de fluxo de trabalho e o explicação acima foi resumida. No entanto, podemos começar a teorizar métodos nefastos para subverter o processo de desenvolvimento descentralizado.
Observação: o termo “consenso“é uma palavra ambígua usada para implicar várias coisas diferentes além das regras do Bitcoin. Normalmente usado para indicar “todos basicamente concordam” com uma decisão, enquanto, na realidade, existem palavras mais precisas e distintas que funcionam para definir melhor os vários níveis de concordância em uma decisão do que o termo genérico “consenso”. Para simplificar, este artigo se refere a um acordo quase unânime e geral como obtenção de “consenso”.=”https://diyhpl.us/wiki/transcripts/cryptoeconomic-systems/2019/near-misses/”target=”_blank”> bugs e descuidos que poderiam ter resultado em vetores de ataque técnico sérios, mas esses vulnerabilidades publicamente conhecidas foram corrigidas há muito tempo. De um modo geral, esses bugs e descuidos são difíceis de encontrar, pois não há nada no código que seja intrusiva ou dolorosamente óbvio. Uma comunidade dedicada de desenvolvimento de código aberto que contribui voluntariamente para a base de código trabalhou incessantemente para melhorar o protocolo integridade na última década e mais alguns. Ao entender as vulnerabilidades passadas e suas soluções, podemos permanecer vigilantes para mitigar falhas futuras e fornecer uma base para gerar cenários de pior caso para procurar possíveis mecanismos de defesa.
Certamente o ataque social mais notável à comunidade Bitcoin e processo de desenvolvimento ocorreu em 2015, quando dois respeitados e veteranos desenvolvedores de Bitcoin na época, Gavin Andresen e Mike Hearn, criou e promoveu um novo cliente Bitcoin incompatível chamado Bitcoin XT. O Bitcoin XT propôs aumentar as transações possíveis por bloco, conhecido como blocksize, como forma de competindo com sistemas de pagamento convencionais como MasterCard ou Visa. Ao adotar esta versão incompatível do Bitcoin, os usuários efetivamente hardfork ou criariam blocos válidos e anteriormente inválidos e transações que, em última análise, forçam todos a atualizar seus clientes da mesma forma-senão arriscando estabilidade da rede e ataques de repetição.
O criador do Bitcoin, o anônimo Satoshi Nakamoto, há muito tempo longe do Bitcoin quando este projeto controverso foi anunciado e a comunidade foi deixada para decifrar os comentários de Satoshi para orientação como se fossem escrituras sagradas. O Bitcoin XT não obteve consenso, pois ingenuamente propôs aumentar o tamanho máximo do bloco e seus proponentes procuraram subverter o consenso do usuário por meio de conluio fechado, desenvolvedor-miner-corporation. Sem entrar em todos os detalhes da infame “guerra de tamanho de bloco” e gerar uma livro inteiro, podemos observar claramente do intensivo dois anos disputam a função crítica de nós completos (usuários) coordenando para impor novas regras sem suporte de mineradores via softforks ativados pelo usuário (UASF).
Se o Bitcoin tivesse caído na armadilha do grande bloco, a descentralização da rede e a natureza apolítica do Bitcoin teriam sofrido de acordo. Para entender as ramificações de alterar uma variável aparentemente simples, que é o limite do tamanho do bloco, requer não apenas entender o impacto técnico na integridade da base de código, mas também ocultar consequências convidando vetores de ataque adicionais contra o ecossistema de rede nascente. Pode-se estender essa linha de pensamento para as atuais sugestões estúpidas de mudar o Bitcoin para prova de participação em vez de prova de trabalho. Embora a solução para a guerra do tamanho do bloco tenha sido resolvida tecnicamente por meio de um UASF, o drama social que se seguiu exigiu soluções não técnicas de simplesmente permanecer firme e não ceder em uma implementação de software prejudicial, independentemente do apoio do desenvolvedor corporativo ou de celebridades.
Ataques pelo método de ativação BIP
Dashjr contesta um ataque ao desenvolvimento do Bitcoin Core processo ocorreu apenas no ano passado: o “Speedy Trial” método de ativação do tão esperado “Taproot”
Embora o Taproot tenha sido ativado com sucesso e os recursos subsequentes fornecidos foram inquestionavelmente benéficos para os usuários, seu método de ativação foi percebido como controverso e apresentou potenciais vetores de ataque, ao mesmo tempo em que definia pouca precedência para futuras ativações de BIP. O mecanismo de ativação do Speedy Trial foi visto como um ataque ao processo de desenvolvimento do Bitcoin Core porque alguns desenvolvedores se afastaram do consenso percebido da comunidade enquanto se recusavam a considerar BIP 8 como um método de ativação, também conhecido como “Vamos ver o que acontece” proposta, na implantação do Taproot.
O método Speedy Trial era antitético para o resultado da guerra em bloco, onde a disputa concluiu que os usuários coordenando um acordo quase unânime deveriam controlar as regras de consenso da rede e não os mineradores. Com o Speedy Trial e sem o BIP 8, a decisão de ativar (ou não ativar simplesmente não sinalizando quando é implantado) dependia inteiramente dos mineradores, independentemente do consenso do usuário. O método de implantação do Speedy Trial, sem dúvida imprudente, foi contra o consenso percebido da comunidade e, para mitigar isso no futuro, exigiria potencialmente a coordenação de um UASF com adoção viável suficiente além de algumas pessoas preocupadas no canto de uma sala para combater a ativação de um BIP.
p>
Os palestrantes do “Preventing Attacks On Bitcoin” consideraram como avaliar esses ataques históricos e evitar ataques semelhantes no futuro. Os “atacantes” que pressionavam o Bitcoin XT ou o Speedy Trial podem não ter tido intenção maliciosa com suas propostas, mas claramente seus métodos conflitavam com certos princípios que uma parte da comunidade defende inflexivelmente – ou seja, os usuários têm o direito exclusivo de aprovar ou veto mudanças nas regras de consenso. Em retrospectiva, os invasores simplesmente não seguiram os mesmos princípios do Bitcoin que a comunidade fez, o que resultou nesses ataques se tornando uma guerra subjetivamente interpretativa do que era “melhor” para o Bitcoin.
O já mencionado Bitcoin XT e Cenários de teste rápido transmitem os métodos nos quais o processo de desenvolvimento do Bitcoin Core pode se tornar controverso, enfatizando a necessidade de abordar todas as implementações de BIP com cautela e ponderação. Nas seções a seguir, os membros do painel teorizam vetores de ataque plausíveis adicionais.
Ataques de verificação de software Bitcoin
Os interesses de Bishop no processo de desenvolvimento incluem construções determinísticas e assinatura de construção que podem ser aproveitadas para evitar certos vetores de ataque em usuários de Bitcoin, ou seja, ataques que procuram enganar o usuário fazendo-o acreditar que baixou um cliente Bitcoin Core genuíno.
Qualquer um que seja usuário de um cliente Bitcoin deve baixá-lo de algum lugar no spam-internet. Se a página da Web que hospeda o arquivo de download for comprometida ou interceptada durante o download, o próprio arquivo pode ter sido modificado de forma maliciosa. Como esse usuário pode provar que a versão que baixou é realmente o cliente Bitcoin pretendido?
O método comum para fornecer não repúdio de uma compilação de software, ou prova da integridade e origem dos dados, é com assinaturas digitais. Assinaturas digitais, o primo eletrônico e com inclinação matemática do selo de cera inviolável, são um elemento padrão da maioria dos protocolos criptográficos que usam chaves assimétricas (públicas e privadas) para habilitar a autenticação entre dois estranhos — mas espere! Isso não garante a autenticidade da assinatura. Em última análise, a autenticação sem confiança nas chaves usadas para verificar a assinatura é inútil, pois o destinatário deve ter certeza de que a chave de verificação realmente pertence ao remetente.
Existe então outro vetor de ataque astuto se o próprio software de verificação for comprometido. Um criminoso inteligente alegando ser alguém que não é, mas tendo que provar sua afirmação por meio de uma assinatura digital, poderia plantar o software de verificação de chave comprometido para o usuário desavisado baixar e, consequentemente, receber um resultado falso de autenticação. O software comprometido contém um bug muito sutil que, com uma rápida olhada no código, manipularia o usuário para raciocinar que o software de verificação produziu um resultado preciso.
Embora as compilações determinísticas não resolvam a autenticação da posse de assinatura digital , ele funciona para reduzir a confiança necessária em uma única fonte ou reivindicação para o software que um usuário baixou. As compilações determinísticas trabalham para proteger a implementação do software contra alguns desenvolvedores desonestos ou as chaves de um desenvolvedor comprometido durante o processo de desenvolvimento. Essa proteção é obtida por meio de hash criptográfico do software que os desenvolvedores assinam digitalmente à medida que o software é criado durante cada etapa do processo de compilação — garantindo efetivamente que os arquivos binários do software final sejam os mesmos que os arquivos binários que os desenvolvedores honestos construíram e, portanto, não foram comprometidos de forma alguma.
Em conjunto, com compilações determinísticas e assinatura de compilação, pode-se basicamente rastrear a confiança no software dos binários ao código-fonte para os git commits feitos por vários desenvolvedores e identificar quais alterações foram introduzidas por quem. A legitimidade do software pode ser investigada por meio de técnicas comorede de confiança onde os usuários podem arbitrar se as chaves que estão sendo verificadas são autênticas ou não e estão operando o cliente Bitcoin pretendido. Portanto, sem tirar proveito de compilações determinísticas e assinatura de compilação, o usuário fica suscetível a uma infinidade de vetores de ataque.
Um exemplo: se um usuário baixar um cliente Bitcoin por meio de HTTP em vez de HTTPS com uma conexão Wi-Fi pública, talvez em um café ou hotel estrangeiro, sem verificar a compilação assinando, os invasores podem muito bem interceptar a conexão de download do usuário e substituir o arquivo de download por uma versão vilã do Bitcoin que pode roubar moedas, espionar usuários ou executar outras funções prejudiciais.
Bishop descobre que um “ fun” parte do processo de construção de software é manter variáveis de ambiente de desenvolvimento consistentes que trabalham para eliminar quaisquer fontes de não-determinismo. Fontes não determinísticas podem resultar em variabilidades indesejáveis da assinatura de construção devido ao ambiente naturalmente aberto que os desenvolvedores estão desenvolvendo. Uma variabilidade, como sistemas operacionais diferentes entre desenvolvedores individuais, gera um hash totalmente diferente no final do processo de desenvolvimento. Idealmente, remover todas as fontes de variabilidade no ambiente de construção melhoraria as construções determinísticas e, posteriormente, melhoraria a confiança em sua integridade.
Ossificação deliberada do desenvolvimento do Bitcoin
Lopp, canalizando seu Sun Tzu interior, concebe um método particularmente desonesto de dividir e manipular o Bitcoin Core à la nefasto desenvolvedor(es) semeando descontentamento em toda a comunidade e repositórios do GitHub. Se um desenvolvedor respeitado transmitir extrema irritação e raiva em relação a todas e quaisquer melhorias, patches ou alterações de protocolo, o crescente consenso geral será de medo de tocar no protocolo. Esse”congelamento”do processo de desenvolvimento é conhecido como ossificação e faria melhorias contínuas no protocolo praticamente impossível.
Talvez alcançar a ossificação seja, em última análise, benéfico para o protocolo, pois isso implicaria no amplo domínio estabelecido do Bitcoin, mas Lopp argumenta exatamente o contrário, pois a ossificação é um vetor de ataque explorável em vez de uma defesa eficaz. Embora a ossificação funcione para se defender contra alterações prejudiciais ao protocolo Bitcoin, como o Bitcoin XT, ela também pode funcionar para impedir atualizações benéficas ou necessárias que fornecem maior privacidade ponto a ponto e melhorias mais robustas na base de código.
O vetor de ataque que Lopp descreve seria extremamente difícil de avaliar no local se um confronto ativo no processo de desenvolvimento é um ataque ao protocolo ou um desacordo legitimamente construtivo. Isso fala com o ponto anterior onde, em retrospectiva, o ataque é muito mais visível após o fato. Sem possuir total onisciência da verdadeira intenção de cada desenvolvedor, o processo de desenvolvimento ficaria preso entre uma pedra e um lugar difícil.
A defesa contra ataques técnicos, como os primeiros bugs e descuidos mencionados acima, são relativamente diretos e lógica em sua solução. Ao introduzir o elemento errático e humano, no entanto, começamos a jogar um jogo perigoso com muito menos previsibilidade. Os ataques de engenharia social geralmente são embalados com soluções difusas e provavelmente terão que ser tratados à medida que surgem. Um ataque memético direcionado ou narrativa dominante pode ser totalmente imperceptível e determinar uma defesa contra eles é em grande parte uma área cinzenta.
A guerra é a filosofia do engano. Indiscutivelmente, o vetor de ataque mais lógico para possíveis adversários pode ser incitar descontentamento social e guerra de memes. Lopp explica que forçar deliberadamente a ossificação é o ataque perfeito porque muitos usuários considerariam isso uma defesa.
Ataques judiciais aos desenvolvedores do Bitcoin Core
A prevalência contínua de Craig Wright, um indivíduo que afirma ser o anônimo Satoshi Nakamoto, e seu palhaçadas criptográficas maisintimidação judicial de desenvolvedores do Bitcoin Core representa um ataque direto ao processo de desenvolvimento do Bitcoin Core. Apesar das evidências crescentes de que Craig Wright não é Satoshi Nakamoto, ele continua a causar estragos acumulando milhões de dólares em honorários legais e efetivamente superando a defesa por causa dos custos astronômicos-financeiros e pessoais-que Craig Wright impõe a desenvolvedores e colaboradores voluntários por meio de Ações Estratégicas Contra a Participação Pública (ações SLAPP). Lembre-se do criminoso esperto alegando ser alguém que não é, mas também tendo que provar sua afirmação por meio de uma assinatura digital; este cenário exato aconteceu mas, devido à natureza obscura da criptografia assimétrica, tem sido ineficaz em convencer o sistema judicial.
Consequentemente, os desenvolvedores do Bitcoin Core devem adotar métodos de contribuição anônima ou correm o risco de serem alvo de um processo de litígio caro e oneroso. Esses métodos de anonimato dependem, em última análise, das práticas de privacidade do indivíduo, talvez como evitar o Bitcoin 2022 e conferências inteiramente para manter o anonimato. No entanto, o litígio contra um indivíduo supostamente anônimo ainda pode ser possível se houver um nome IRL ou identificação pessoal elemento vinculado ao pseudônimo desse desenvolvedor. No entanto, a necessidade de contribuir de forma privada é um fardo presente e futuro para os desenvolvedores e suas famílias.
Eventualmente, se esses ataques judiciais aos contribuidores do Bitcoin Core persistirem ou Jack Dorsey de O Fundo de Defesa Legal do Bitcoin se esgota, os desenvolvedores serão expulsos do espaço e aumentarão ainda mais a ossificação do protocolo, já que queimar dinheiro em litígios intermináveis não é muito atraente; uma”morte por mil cortes”, como Shinobi resumiu eloquentemente.
Ataques e complicações futuras no desenvolvimento do Bitcoin
Se espera-se que o Bitcoin sobreviva e prospere não apenas neste século, mas por muitos séculos e assim por diante, medidas cuidadosas devem ser tomadas na formulação de mecanismos de defesa contra ataques esperados e inesperados ao Bitcoin Core, bem como ao ecossistema Bitcoin. Você não pode ter um veículo de riqueza multigeracional se ele se tornar inútil antes de morrer.
Embora os participantes do painel tenham opiniões diferentes sobre se atacar usuários de Bitcoin é equivalente a atacar o protocolo Bitcoin, continuam a existir vetores de ataque aos usuários, como as assinaturas digitais fraudulentas acima mencionadas e a saga legal de Craig Wright em andamento. Outros vetores incluem práticas ruins de construção de carteiras ou narrativas maliciosas que fazem lavagem cerebral nos usuários que podem ser significativamente prejudiciais a certos princípios do Bitcoin que consideramos primordiais.
Apesar dos avanços no gerenciamento de chaves privadas do Bitcoin, conhecido como carteiras, permanece a possibilidade de maus atores construírem intencionalmente carteiras que não seguem o mais recente nem o ideal práticas de segurança disponíveis para eles. Por exemplo, ainda existem implementações de carteira que usam um único endereço para enviar e receber bitcoin — expondo assim qualquer privacidade que os usuários possam ter.
Além disso, embora não necessariamente intencional, mas sim resultado de suas limitações, qualquer tipo de carteira leve (uma que também não funcione como um nó completo) requer uma conexão com um nó completo para comunicar transações. As carteiras leves, particularmente populares para usuários casuais, apresentam a dualidade de uma interface simples e fácil de usar, mas também apresentam lacunas na segurança maduras para vetores de ataque. Os usuários dessas carteiras são suscetíveis à interceptação de suas comunicações de transações por agentes potencialmente nefastos. Uma solução simples-mas impraticável para alguns-para esse vetor seria renunciar ao uso de carteiras leves em favor de carteiras de nó completo.
Shinobi prevê vetores de ataque alternativos decorrentes de campanhas simples de desinformação contra o Bitcoin e, em seguida, rapidamente se transformando em lobby do governo por ações legais e regulamentações pesadas. Uma dessas campanhas óbvias de desinformação é a noção infundada de que a prova de participação é uma alternativa viável à prova de trabalho. Se todas as jurisdições, principalmente aquelas com infraestrutura de energia prontamente barata e abundante, caíssem em um efeito dominó de desespero de poder para conter o Bitcoin através do banimento total da mineração de bitcoin, talvez imposto via inspecionando modulações de energia exclusivas da rede de energia que podem identificar plataformas de mineração de bitcoin e, em seguida, realocando todo o poder de hash existente-grid seria bastante desafiador.
O processo de substituição e aquisição das escalas necessárias de energia fora da rede – particularmente em segredo – não é tarefa fácil. Como exemplo, painéis solares e turbinas eólicas permanecem muito restritivos para atuar como um substituto equivalente e assumir totalmente uma transição em toda a rede para a mineração de bitcoin fora da rede devido à geração de energia variável e intermitente inerente à energia solar e eólica. Dashjr propôs uma solução potencial desviando-se do padrão atual de prova de trabalho apenas se a situação fosse terrível o suficiente. Se o blockchain fosse interrompido por algum ditado político inimaginável ou o algoritmo de hash (SHA256) usado para Bitcoins seguros foram quebrados, então reunir-se para encontrar uma solução pode ser possível e seria benéfico para todos os participantes da rede.
Esta proposta de modificar a prova de trabalho como a conhecemos é um caso em si-ponto para os ataques inesperados que podem ocorrer no Bitcoin e as decisões inevitavelmente controversas através do processo de desenvolvimento do Bitcoin Core que se seguiriam em um cenário tão terrível.
Continuando no caminho de situações hipotéticas que exigiriam tempo-implementações de BIP sensíveis, talvez o pior cenário imaginável seria se o SHA256, RIPEMD-160, ou ECDSA mecanismos foram, sem dúvida, prometido-mas mesmo assim, a questão permanece sobre quais seriam as alternativas viáveis? Lopp brinca dizendo que um algoritmo à prova quântica deixará todo mundo feliz, mas essa resposta atrevida provavelmente se tornará realidade em algum momento no futuro distante, exigindo discussões desagradáveis em torno de mecanismos práticos de defesa contra computação quântica explorando criptografia assimétrica.
Bitcoin é um dinheiro apolítico e um protesto pacífico contra o regime monetário incumbente e corrupto. Devido à natureza do oponente que o Bitcoin está enfrentando, ou seja, o dólar americano, é provável que ocorra uma enxurrada implacável de ataques técnicos e sociais contra o Bitcoin, se ainda não estiver em andamento. Bishop relaciona a comunidade inteiramente voluntária do Bitcoin, que está defendendo firmemente o Bitcoin, a um “sistema imunológico” autodesenvolvido que poderia ser o maior mecanismo defensivo e ofensivo do Bitcoin.
Pensamentos finais
Em resumo, Bitcoin não é invencível de forma alguma. Without actively considering all potential attack vectors and seeking respective solutions, the always-waiting adversaries could find weaknesses in the code or in the community itself. Whether the attack be from colluding parties, counterfeit Bitcoin software, deliberate ossification, targeted attacks through the judicial system or some unknown future disaster scenario, Bitcoiners must work together and unite to seal any gaps that could be the beginning of the end for Bitcoin.
The aim of this panel is not to instill in the audience doom nor gloom, but rather to prescribe a proper dose of reality with the very possible attacks Bitcoin development and the network could encounter moving forward. Ignoring this would be incredibly detrimental to the overall security of Bitcoin if we decide to live in blissful ignorance of these attack vectors. Should history have anything to teach us, it would be that all existing and previous monetary regimes — outside of Bitcoin — have succumbed to the fallibility of human institutions. Let’s work to not have Bitcoin experience a similar fate.
Humans are rationally driven by monetary incentives which has enabled the open source, pseudo anonymous, monetary nature of Bitcoin to harness a large, skilled group of hackers with opportunity for a reward of the scarce currency that is bitcoin. The discovery and exploitation of flaws that could compromise Bitcoin would paradoxically diminish the attacker’s newfound wealth — thereby, in theory, monetarily encouraging hackers to continually support the Bitcoin network and responsibly report bugs and exploits.
Despite discussions of ways to attack the Bitcoin Core development process and the wider ecosystem with little readily-available solutions of how to exactly ascertain and prevent these attacks, Bishop ended the panel with a poignant statement that spoke to the greatest incentive of all: money. He remarked, “Bitcoin is the greatest bug bounty program of all time … good luck.”
This is a guest post by Okada. Opinions expressed are entirely their own and do not necessarily reflect those of BTC, Inc. or Bitcoin Magazine.