Pensamiento adversario y formas de atacar Bitcoin

Un grupo de desarrolladores de Bitcoin Core discutió varios vectores de ataque para Bitcoin, así como formas de planificar con anticipación y eludir a los actores infames.

Bitcoin 2022, organizada en Miami, Florida, del 6 al 9 de abril, presentó un panel titulado “Prevención de ataques a Bitcoin” con tres Bitcoin Core desarrolladores: Lucas Dashjr, bryan obispo y Jameson Lopp (en sustitución de Peter Todd). El panel fue moderado por Shinobi.

Los panelistas analizan los vectores de ataque técnico y social, principalmente en el proceso de desarrollo de Bitcoin Core, que podrían obstaculizar o descarrilar por completo la única misión de Bitcoin como dinero inmutable. El propósito de la lluvia de ideas abierta sobre los vectores de ataque es formular medidas de defensa apropiadas y, como De Sun Tzu Estrategias de “El arte de la guerra”:

“No confíen en que el enemigo no viene. Confía en tu disposición para encontrarte con él. No confíes en que el enemigo no atacará. Confía solo en tu habilidad para elegir un lugar que el enemigo no pueda atacar”.

El siguiente es un resumen de dicho panel con una descripción general rápida del proceso de desarrollo de Bitcoin Core.

Breve descripción general de Bitcoin Core

La Bitcoin Core los desarrolladores trabajan a través de un proceso de desarrollo para ofrecer parches de errores del protocolo Bitcoin, optimizaciones de software y funciones mejoradas; luego publican estas actualizaciones siguiendo el consenso de la comunidad a través de Propuestas de mejora de Bitcoin (BIP). Diseñar con éxito un ataque contra el proceso de desarrollo, ya sea a nivel técnico o social, podría impedir (a veces de manera crítica) las actualizaciones de protocolo e infundir desconfianza entre los desarrolladores.

Para aclarar, Bitcoin Core es una implementación de software libre y de código abierto de un Bitcoin nodo completo, denominado cliente. Aunque su nombre es engañoso, Bitcoin Core no tiene un control centralizado o "núcleo" sobre la red de Bitcoin, sino que sirve como un posible cliente que las personas pueden usar libremente a su discreción. Además, las reglas de consenso del protocolo de Bitcoin requieren que todos los nodos completos de Bitcoin y los participantes económicos apliquen indefectiblemente esas reglas al considerar la validez de un bloque.

Además, las actualizaciones de Bitcoin Core no se descargan automáticamente sino manualmente, ya que las actualizaciones automáticas de software proporcionan un vector de ataque para que un actor travieso comprometa todos los nodos y mineros de un solo golpe.

El equipo de desarrolladores de Bitcoin Core no tiene como pedestal a un solo líder o portavoz, lo que distancia al cliente y al proceso de desarrollo de la explotación del carácter personal debido a las fallas que todos los líderes terrenales poseen de forma inherente. Por ejemplo, los líderes narcisistas pueden debilitarse al crear malestar entre sus seguidores, o los líderes malhumorados pueden comportarse de manera irracional cuando se les provoca con insultos. Para derribar un movimiento advenedizo, uno debe deshacerse inteligentemente de su líder o fracturar a sus seguidores.

Sin embargo, sin un solo líder, ¿cómo llegan a un acuerdo los desarrolladores independientes de Bitcoin Core sobre opciones de diseño complejas o correcciones de errores de emergencia? Los BIP antes mencionados se utilizan en el proceso de desarrollo de Bitcoin Core para implementar funciones o información en el protocolo de Bitcoin, pero los BIP también funcionan para estandarizar la comunicación de nuevas ideas, como se muestra en forma de diagrama a continuación y como se describe en BIP 1:

¿Cómo podemos echarle una llave a este proceso? A pesar de introducir cierta formalidad a través de BIP 1 en una red que de otro modo no estaría estructurada, se presenta una oportunidad para que los actores malintencionados o simplemente equivocados subviertan el proceso de desarrollo a través de medios tanto técnicos como sociales. Sin embargo, reconocer esta "llave inglesa" a menudo solo es posible en retrospectiva, lo que hace que ciertos vectores de ataque sean especialmente difíciles de detectar y evitar. Si puede esquivar una llave inglesa, puede esquivar a un desarrollador desviado empeñado en impulsar su agenda egoísta a expensas de Bitcoin.

En la práctica, las implementaciones reales de BIP no son tan claras como un diagrama de flujo de trabajo y la explicación anterior se ha resumido. Sin embargo, podemos comenzar a teorizar métodos nefastos para subvertir el proceso de desarrollo descentralizado.

Nota: El término “consenso” es una palabra ambigua que se usa para implicar varias cosas diferentes más allá de las reglas de Bitcoin. Por lo general, se usa para indicar que "básicamente todos están de acuerdo" con una decisión, mientras que, en realidad, hay palabras más precisas y distintas que funcionan para definir mejor los diferentes niveles de acuerdo en una decisión que el término general "consenso". En aras de la simplicidad, este artículo se refiere al acuerdo casi unánime y general como lograr "consenso".

Antiguos ataques a Bitcoin

La red Bitcoin implementada en 2009 con varias críticas errores y descuidos eso podría haber resultado en vectores de ataque técnico serios, pero esas vulnerabilidades conocidas públicamente fueron remediadas hace mucho tiempo. En términos generales, estos errores y descuidos son difíciles de encontrar, ya que no hay nada en el código que sea molesto o dolorosamente obvio. Una comunidad de desarrollo de código abierto dedicada que contribuye voluntariamente a la base de código ha trabajó incesantemente para mejorar la integridad del protocolo durante la última década y algo más. Al comprender las vulnerabilidades pasadas y sus soluciones, podemos permanecer atentos para mitigar futuras fallas y proporcionar una base para generar los peores escenarios para buscar posibles mecanismos de defensa.

Ciertamente, el ataque social más notable contra la comunidad de Bitcoin y el proceso de desarrollo ocurrió en 2015 cuando dos desarrolladores de Bitcoin veteranos y muy respetados en ese momento, Gavin Andresen y mike hearn, creó y promovió un nuevo cliente de Bitcoin incompatible etiquetado Bitcoin XT. Bitcoin XT propuso aumentar las transacciones posibles por bloque, conocido como el tamaño de bloque, como forma de competir con los sistemas de pago convencionales como MasterCard o Visa. Al adoptar esta versión incompatible de Bitcoin, los usuarios efectivamente fuerza dura, o hacer bloques y transacciones válidos que antes no eran válidos, lo que en última instancia obliga a todos a actualizar a sus clientes de manera similar; de lo contrario, corren el riesgo de estabilidad de la red y ataques de repetición.

El creador de Bitcoin, el anónimo Satoshi Nakamoto, hacía tiempo que se había alejado de Bitcoin cuando se anunció este controvertido proyecto y la comunidad se quedó para descifrar el de Satoshi. comentarios como si fueran escrituras sagradas. Bitcoin XT no logró obtener consenso ya que ingenuamente propuso aumentar el tamaño máximo de bloque y sus defensores buscaron subvertir el consenso de los usuarios a través de colusión a puerta cerrada, desarrollador-minero-corporación. Sin entrar en cada detalle minucioso de la infame “guerra de bloques” y engendrando un libro entero, podemos observar claramente desde el intensivo dos año disputar la función crítica de los nodos completos (usuarios) que se coordinan para hacer cumplir las nuevas reglas sin el apoyo de los mineros a través de horquillas blandas activadas por el usuario (UASF).

Si Bitcoin hubiera caído en la trampa del bloque grande, la descentralización de la red y la naturaleza apolítica de Bitcoin habrían sufrido en consecuencia. Para comprender las ramificaciones de cambiar una variable aparentemente simple, que es el límite de tamaño de bloque, se requiere no solo comprender el impacto técnico en la integridad de la base de código, sino también Consecuencias invitando a vectores de ataque adicionales contra el ecosistema de red naciente. Uno puede extender esta línea de pensamiento hacia la actualidad. sugerencias estúpidas de cambiar Bitcoin a prueba de participación en lugar de prueba de trabajo. A pesar de que la solución a la guerra del tamaño de bloques se resolvió técnicamente a través de un UASF, el drama social que siguió requirió soluciones no técnicas de simplemente permanecer firme y no ceder en una implementación de software perjudicial, sin importar el respaldo corporativo o del desarrollador famoso.

Método de activación de ataques por BIP

dashjr sostiene que un ataque al proceso de desarrollo de Bitcoin Core ocurrió el año pasado: el "Prueba rápida” método de activación del tan esperado “Raíz principal" SoftForm mejora (BIP 343). La lógica de prueba rápida funciona para activar una implementación de BIP sin el riesgo de una división de cadena no deseada por medio de una activación exitosa o fallida rápida dentro de un período de tres meses. Una vez que finalizó el trabajo para construir Taproot, los desarrolladores no pudieron llegar a un acuerdo general sobre el método de activación y esencialmente ignoraron el paso crucial de recibir primero el indudable consenso de la comunidad.

Aunque Taproot se activó con éxito y las funciones posteriores proporcionadas fueron sin duda beneficiosas para los usuarios, su activación Método se percibió como controvertido y planteó posibles vectores de ataque al tiempo que sentó un precedente pobre para futuras activaciones de BIP. El mecanismo de activación de Speedy Trial fue visto como un ataque al proceso de desarrollo de Bitcoin Core porque algunos desarrolladores se apartaron del consenso percibido por la comunidad y se negaron a considerar BIP 8 como un método de activación, también conocido como el "Veamos qué pasa”, en el despliegue de Taproot.

El método Speedy Trial era la antítesis del resultado de la guerra de bloques, donde la disputa concluyó que los usuarios que coordinaban un acuerdo casi unánime deberían controlar las reglas de consenso de la red y no los mineros. Con Speedy Trial y sin BIP 8, la decisión de activar (o no activar simplemente sin señalar cuándo se implementa) dependía completamente de los mineros, independientemente de consenso de los usuarios. El posiblemente imprudente método de implementación de Speedy Trial fue en contra del consenso percibido por la comunidad y, para mitigar esto en el futuro, potencialmente requeriría la coordinación de un UASF con suficiente adopción viable más allá de unas pocas personas preocupadas en la esquina de una habitación para contrarrestar la activación de un BIP.

Los panelistas de "Prevención de ataques a Bitcoin" consideraron cómo evaluar estos ataques históricos y evitar ataques similares en el futuro. Es posible que los "atacadores" que presionan por Bitcoin XT o Speedy Trial no hayan tenido intenciones maliciosas con sus propuestas, pero claramente sus métodos entraron en conflicto con ciertos principios que una parte de la comunidad defiende firmemente, es decir, los usuarios tienen el derecho exclusivo de aprobar o vetar cambios en las reglas de consenso. En retrospectiva, los atacantes simplemente no siguieron los mismos principios de Bitcoin que siguió la comunidad, lo que resultó en que esos ataques se convirtieran en una guerra interpretativa subjetiva de lo que era "mejor" para Bitcoin.

Los escenarios de Bitcoin XT y Speedy Trial mencionados anteriormente transmiten los métodos en los que el proceso de desarrollo de Bitcoin Core podría volverse controvertido, enfatizando la necesidad de abordar todas las implementaciones de BIP con cautela y consideración. En las siguientes secciones, los panelistas teorizan sobre posibles vectores de ataque adicionales.

Ataques de verificación de software de Bitcoin

Los intereses de Bishop en el proceso de desarrollo incluyen compilaciones deterministas y firma de compilaciones que se pueden aprovechar para evitar ciertos vectores de ataque a los usuarios de Bitcoin, es decir, ataques que buscan engañar al usuario para que crea que ha descargado un cliente Bitcoin Core de buena fe.

Cualquiera que sea usuario de un cliente de Bitcoin debe descargarlo de algún lugar de Internet plagado de spam. Si la página web que aloja el archivo de descarga se ve comprometida o interceptada durante la descarga, es posible que el archivo en sí se haya modificado de forma malintencionada. ¿Cómo puede ese usuario probar que la versión que descargó es de hecho el cliente de Bitcoin previsto?

El método común para proporcionar no repudio de una compilación de software, o prueba de la integridad y el origen de los datos, es con firmas digitales. Las firmas digitales, el primo electrónico y matemáticamente inclinado del sello de cera a prueba de manipulaciones, son un elemento estándar de la mayoría de los protocolos criptográficos que utilizan asimétrico claves (públicas y privadas) para habilitar la autenticación entre dos extraños, ¡pero espera! Esto no garantiza la autenticidad de la firma. En última instancia, la autenticación sin confianza en las claves utilizadas para verificar la firma no tiene sentido, ya que el destinatario debe estar seguro de que la clave de verificación realmente pertenece al remitente.

Luego hay otro vector de ataque astuto si el propio software de verificación está comprometido. Un delincuente astuto que afirme ser alguien que no es, pero que también tenga que probar su afirmación a través de una firma digital, podría plantar el software de verificación de claves comprometido para que el usuario desprevenido lo descargue y, en consecuencia, se le presente un resultado falso de autenticación. El software comprometido contiene un error muy sutil que, con un vistazo rápido al código, manipularía al usuario para que razonara que el software de verificación arrojó un resultado preciso.

Si bien las compilaciones deterministas no resuelven la autenticación de la posesión de firmas digitales, sí funcionan para reducir la confianza requerida en una sola fuente o reclamar el software que un usuario ha descargado. Las compilaciones deterministas funcionan para proteger la implementación del software contra un par de desarrolladores deshonestos o las claves de un desarrollador comprometido durante el proceso de desarrollo. Esta protección se logra mediante hashes criptográficos del software que los desarrolladores firman digitalmente a medida que se construye el software durante cada paso del proceso de construcción, asegurando efectivamente que el software final archivos binarios son los mismos que los archivos binarios que construyeron los desarrolladores honestos y, por lo tanto, no se han visto comprometidos de ninguna forma o manera.

En conjunto, con compilaciones deterministas y firmas de compilación, básicamente se puede rastrear la confianza en el software desde los archivos binarios hasta el código fuente y el git confirma realizados por varios desarrolladores e identificar qué cambios introdujo quién. La legitimidad del software se puede investigar más a fondo a través de técnicas como Red de confianza donde los usuarios pueden arbitrar si las claves que se verifican son auténticas o no y si están operando el cliente de Bitcoin previsto. Por lo tanto, sin aprovechar las compilaciones deterministas y la firma de compilaciones, el usuario es susceptible a una miríada de vectores de ataque.

Un ejemplo: si un usuario descarga un cliente Bitcoin a través de HTTP en lugar de HTTPS con una conexión Wi-Fi pública, tal vez en una cafetería u hotel extranjero, sin verificar la firma de la compilación, los atacantes podrían muy bien interceptar la conexión de descarga del usuario y reemplazar el archivo de descarga con una versión maligna de Bitcoin que puede robar monedas, espiar a los usuarios o realizar otras funciones dañinas.

Bishop encuentra que una parte "divertida" del proceso de creación de software es mantener variables de entorno de desarrollo consistentes que funcionan para eliminar cualquier fuente de no determinismo. Las fuentes no deterministas podrían dar lugar a variaciones indeseables de la firma de la compilación debido al entorno naturalmente abierto en el que están construyendo los desarrolladores. Una variabilidad, como los diferentes sistemas operativos entre desarrolladores individuales, genera un hash completamente diferente al final del proceso de desarrollo. Idealmente, eliminar todas las fuentes de variabilidad en el entorno de construcción mejoraría las construcciones deterministas y, posteriormente, mejoraría la confianza en su integridad.

Osificación deliberada del desarrollo de Bitcoin

Lopp, canalizando a su Sun Tzu interior, diseña un método particularmente tortuoso para dividir y manipular Bitcoin Core al estilo de los infames desarrolladores, sembrando el descontento en toda la comunidad y en los repositorios de GitHub. Si un desarrollador respetado expresara una irritación e ira extremas hacia todas y cada una de las mejoras, parches o cambios de protocolo, entonces el creciente consenso general será de miedo. hacia tocar el protocolo. Esta "congelación" del proceso de desarrollo se conoce como osificación y haría que las mejoras continuas del protocolo fueran prácticamente imposibles.

Tal vez lograr la osificación sea en última instancia beneficioso para el protocolo, ya que esto implicaría el dominio generalizado establecido de Bitcoin, pero Lopp argumenta todo lo contrario en el sentido de que la osificación es un vector de ataque explotable en lugar de una defensa eficaz. Si bien la osificación funciona para defenderse de los cambios perjudiciales en el protocolo de Bitcoin, como Bitcoin XT, también podría funcionar para evitar actualizaciones beneficiosas o necesarias que brinden una mayor privacidad entre pares y mejoras más sólidas en la base de código.

El vector de ataque que describe Lopp sería extremadamente difícil de evaluar en el acto si una confrontación activa en el proceso de desarrollo es un ataque al protocolo o un desacuerdo legítimamente constructivo. Esto habla del punto anterior donde, en retrospectiva, el ataque es mucho más visible después del hecho. Sin poseer la omnisciencia total de la verdadera intención de cada desarrollador, el proceso de desarrollo estaría atrapado entre la espada y la pared.

La defensa contra ataques técnicos, como los primeros errores y descuidos mencionados anteriormente, son relativamente sencillos y lógicos en su solución. Sin embargo, cuando introducimos el elemento humano errático, comenzamos a jugar un juego peligroso con mucha menos previsibilidad. Los ataques de ingeniería social a menudo se empaquetan con soluciones confusas y es probable que deban abordarse a medida que se presenten. Un ataque memético o narrativo convencional dirigido puede pasar completamente desapercibido y determinar una defensa contra ellos es en gran medida un área gris.

La guerra es la filosofía del engaño. Podría decirse que el vector de ataque más lógico para los posibles adversarios podría ser incitar el descontento social y la guerra de memes. Lopp explica que forzar deliberadamente la osificación es el ataque perfecto porque muchos usuarios lo considerarían una defensa.

Ataques judiciales a los desarrolladores de Bitcoin Core

La continua prevalencia de Craig Wright, un individuo que afirma ser el anónimo Satoshi Nakamoto, y su travesuras criptográficas más intimidación judicial de los desarrolladores de Bitcoin Core representa un ataque directo al proceso de desarrollo de Bitcoin Core. A pesar de la evidencia creciente que Craig Wright no es Satoshi Nakamoto, continúa causando estragos acumulando millones de dólares en honorarios legales y superando efectivamente a la defensa debido a los costos astronómicos, financieros y personales, que Craig Wright impone a los desarrolladores y contribuyentes voluntarios a través de Demandas estratégicas contra la participación pública (Trajes SLAPP). Recordemos al criminal astuto que dice ser alguien que no es, pero que también tiene que probar su afirmación a través de una firma digital; este escenario exacto se desarrolló pero, debido a la naturaleza abstrusa de la criptografía asimétrica, ha sido ineficaz para convencer al sistema judicial.

En consecuencia, los desarrolladores de Bitcoin Core deben adoptar métodos de contribución anónimos o correr el riesgo de ser objeto de un proceso de litigio costoso y engorroso. Estos métodos de anonimato dependen en última instancia de las prácticas de privacidad del individuo, tal vez como evitar Bitcoin 2022 y las conferencias por completo para mantener el anonimato. Aún el litigio contra un individuo supuestamente anónimo aún podría ser posible si hay un nombre IRL o un elemento de identificación personal vinculado al seudónimo de ese desarrollador. Sin embargo, la necesidad de contribuir de forma privada es en sí misma una carga presente y futura para los desarrolladores y sus familias.

Eventualmente, si estos ataques judiciales a los contribuyentes de Bitcoin Core persisten o Jack Dorsey, Fondo de Defensa Legal de Bitcoin se agota, los desarrolladores serán expulsados ​​​​del espacio y aumentarán aún más la osificación del protocolo, ya que gastar dinero en litigios interminables no es muy atractivo; una "muerte por mil cortes", como Shinobi lo resumió elocuentemente.

Ataques futuros y complicaciones en el desarrollo de Bitcoin

Si se espera que Bitcoin sobreviva y prospere no solo en este siglo, sino durante muchos siglos, entonces se deben tomar medidas cuidadosas para formular mecanismos de defensa contra ataques esperados e inesperados en Bitcoin Core, así como en el ecosistema de Bitcoin. No puede tener un vehículo de riqueza multigeneracional si deja de tener valor antes de morir.

Si bien los panelistas tenían puntos de vista diferentes sobre si atacar a los usuarios de Bitcoin es equivalente a atacar el protocolo de Bitcoin, siguen existiendo vectores de ataque a los usuarios, como las firmas digitales fraudulentas antes mencionadas y la saga legal en curso de Craig Wright. Otros vectores incluyen malas prácticas de construcción de billeteras o narrativas maliciosas convencionales que lavan el cerebro a los usuarios que podrían ser significativamente perjudiciales para ciertos principios de Bitcoin que consideramos primordiales.

A pesar de los avances en la gestión de claves privadas de Bitcoin, conocidas como TARJETEROS, queda la posibilidad de que los malos actores construyan billeteras intencionalmente que no siguen lo último ni lo ideal prácticas de seguridad disponible para ellos. Por ejemplo, todavía hay implementaciones de billetera que use una sola dirección para enviar y recibir bitcoins — exponiendo así cualquier privacidad que los usuarios puedan tener.

Además, aunque no necesariamente intencional sino más bien como resultado de sus limitaciones, cualquier tipo de billetera liviana (una que no opere también como un nodo completo) requiere una conexión a un nodo completo para comunicar transacciones. Las billeteras ligeras, particularmente populares entre los usuarios ocasionales, presentan la dualidad de una interfaz simple y fácil de usar, pero también presentan brechas en la seguridad propicias para los vectores de ataque. Los usuarios de estas billeteras son susceptibles de que las comunicaciones de sus transacciones sean interceptadas por actores potencialmente nefastos. Una solución sencilla, pero poco práctica para algunos, para este vector sería renunciar al uso de billeteras ligeras en favor de billeteras de nodo completo.

Shinobi prevé vectores de ataque alternativos derivados de simples campañas de desinformación contra Bitcoin y luego rápidamente en espiral hacia el cabildeo del gobierno para acciones legales y regulaciones estrictas. Una de esas campañas de desinformación obvias es la idea infundada de que la prueba de participación es una alternativa viable a la prueba de trabajo. Si todas las jurisdicciones, principalmente aquellas con una infraestructura de energía abundante y fácilmente barata, cayeran en un efecto dominó de desesperación por tomar el poder para frenar el pisoteo de Bitcoin a través de la prohibición total de la minería de bitcoin, tal vez impuesta a través de inspección de modulaciones de potencia de red de energía únicas que puede identificar plataformas de minería de bitcoin, luego reubicar todo el poder de hash existente fuera de la red resultaría bastante desafiante.

El proceso de reemplazar y adquirir las escalas necesarias de energía fuera de la red, particularmente en secreto, no es una tarea fácil. Como ejemplo, los paneles solares y las turbinas eólicas siguen siendo demasiado restrictivos para actuar como un sustituto equivalente y asumir por completo una transición de toda la red a la minería de bitcoin fuera de la red debido a la generación de energía variable e intermitente inherente de la energía solar y eólica. Dashjr propuso una posible solución al desviarse del estándar actual de prueba de trabajo solo si la situación era lo suficientemente grave. Si la cadena de bloques se detuviera por algún dictado político inimaginable o el algoritmo hash (SHA256) utilizados para asegurar Bitcoin se rompieron, entonces puede ser posible unirse para encontrar una solución y sería beneficioso para todos los participantes de la red.

Esta propuesta de modificar la prueba de trabajo tal como la conocemos es en sí misma un ejemplo de los ataques inesperados que podrían ocurrir en Bitcoin y las decisiones inevitablemente controvertidas a través del proceso de desarrollo de Bitcoin Core que seguiría dado un escenario tan grave.

Continuando por el camino de situaciones hipotéticas que requerirían implementaciones BIP sensibles al tiempo, quizás el peor escenario imaginable sería si el SHA256, RIPEMD-160o ECDSA Sin duda, los mecanismos se vieron comprometidos, pero incluso entonces, la pregunta sigue siendo ¿cuáles serían las alternativas viables? Lopp bromea diciendo que un algoritmo de prueba cuántica hará felices a todos, pero esta respuesta descarada probablemente se hará realidad en algún momento en el futuro lejano, lo que requerirá discusiones desagradables sobre los mecanismos prácticos de defensa contra computación cuántica explotando criptografía asimétrica.

Bitcoin es un dinero apolítico y una protesta pacífica contra el régimen monetario actual y corrupto. Debido a la naturaleza del oponente al que se enfrenta Bitcoin, es decir, el dólar estadounidense, es probable que se produzca un aluvión implacable de ataques técnicos y sociales contra Bitcoin. si aún no está en marcha. Bishop relaciona la comunidad completamente voluntaria de Bitcoin, que defiende firmemente a Bitcoin listo, con la de un "sistema inmunológico" de desarrollo propio que podría ser el mayor mecanismo defensivo y ofensivo de Bitcoin.

Pensamientos Finales

En resumen, Bitcoin no es de ninguna manera invencible. Sin considerar activamente todos los posibles vectores de ataque y buscar las soluciones respectivas, los adversarios siempre a la espera podrían encontrar debilidades en el código o en la comunidad misma. Ya sea que el ataque sea de partes coludidas, software de Bitcoin falsificado, osificación deliberada, ataques dirigidos a través del sistema judicial o algún escenario de desastre futuro desconocido, los Bitcoiners deben trabajar juntos y unirse para cerrar cualquier brecha que pueda ser el principio del fin de Bitcoin.

El objetivo de este panel no es inculcar pesimismo en la audiencia, sino prescribir una dosis adecuada de realidad con los muy posibles ataques al desarrollo de Bitcoin y la red. podría encontrar avanzando. Ignorar esto sería increíblemente perjudicial para la seguridad general de Bitcoin si decidimos vivir en la dichosa ignorancia de estos vectores de ataque. Si la historia tiene algo que enseñarnos, sería que todos los regímenes monetarios existentes y anteriores, fuera de Bitcoin, han sucumbido a la falibilidad de las instituciones humanas. Trabajemos para que Bitcoin no experimente un destino similar.

Los seres humanos son impulsados ​​racionalmente por incentivos monetarios que han permitido que la naturaleza monetaria pseudoanónima y de código abierto de Bitcoin aproveche a un grupo grande y hábil de piratas informáticos con la oportunidad de obtener una recompensa de la moneda escasa que es bitcoin. Paradójicamente, el descubrimiento y la explotación de fallas que podrían comprometer a Bitcoin disminuirían la nueva riqueza del atacante; por lo tanto, en teoría, alentaría monetariamente a los piratas informáticos a respaldar continuamente la red de Bitcoin y reportar errores y exploits de manera responsable.

A pesar de las discusiones sobre las formas de atacar el proceso de desarrollo de Bitcoin Core y el ecosistema más amplio con pocas soluciones fácilmente disponibles sobre cómo determinar y prevenir exactamente estos ataques, Bishop finalizó el panel con una declaración conmovedora que hablaba del mayor incentivo de todos: el dinero. Comentó: "Bitcoin es el mejor programa de recompensas por errores de todos los tiempos... buena suerte".

Esta es una publicación invitada de Okada. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC, Inc. o Bitcoin Magazine.

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
• CriptoHawk. Radar de altcoins. Prueba gratis.
• Fuente: https://bitcoinmagazine.com/technical/adversarial-thinking-for-attacks-on-bitcoin