Aunque Bitcoin hace todo lo posible para evitar el doble gasto, ¿podría suceder en la práctica? ¿Es muy poco probable que pueda ocurrir un fraude, o existe una prueba matemática de que nunca podría ocurrir?
Como dijo David Schwartz en 367 ; Dan Kaminsky ha pasado algún tiempo auditando el núcleo de Bitcoin. Es un respetado profesional de la seguridad y su opinión sobre estos asuntos es muy apreciada.
Llegó a la conclusión de que no había vulnerabilidades de seguridad preocupantes, pero la escalabilidad es algo que deberá abordarse a medida que crezca el proyecto. Esencialmente; nada que los desarrolladores no supieran ya.
Las únicas vulnerabilidades fundamentales conocidas son el doble gasto y los ataques del 51 %, que están estrechamente relacionados. No parece probable que existan vulnerabilidades fundamentales desconocidas significativas, aunque, por supuesto, podría haber errores explotables en el cliente. (Los algoritmos subyacentes se debilitarán con el tiempo, pero eso no es un problema).
El doble gasto definitivamente puede suceder. Si alguien controlara el 51% del poder de hash de la red, podría duplicar el gasto a voluntad. Sin embargo, cuánto tienes que preocuparte por eso es una pregunta difícil.
Una pregunta más profunda es si estos problemas son realmente fundamentales o si podrían solucionarse sin cambiar los fundamentos de Bitcoin. Hasta donde yo sé, estas son preguntas de investigación abiertas. Se han realizado propuestas para reducir el impacto del ataque del 51 %, pero presentan sus propias vulnerabilidades que, si bien son más difíciles de explotar, tienen consecuencias aún más desastrosas (como estados de red que son inconsistentes, persistentes y requieren intervención manual, y tal vez un autoridad central de facto -- para resolver). Puede argumentar que con algunas de estas sugerencias, ya no es Bitcoin.
Hay una serie de ataques que tienen el potencial de permitir que un atacante duplique el gasto, pero ninguno de ellos tiene éxito cuando se recomienda la práctica de aceptar el pago solo cuando la transacción tiene seis o más confirmaciones en su contra.
Por ejemplo, si un comerciante acepta el pago inmediatamente después de 0/no confirmado, un "ataque de carrera" a veces puede tener éxito con el doble de gastos por parte de un atacante poco sofisticado.
Además, está el ataque de Finney que requiere un poco más de esfuerzo (es posible solo cuando se extrae y se ha resuelto con éxito un bloque). http://en.bitcoin.it/wiki/Debilidades#The_.22Finney.22_attack
Hay otro ataque que requiere un poco más de sofisticación en el que un comerciante que acepta incluso con 1/sin confirmar puede encontrar fácilmente los fondos perdidos debido a un gasto doble: http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391
Hay sugerencias sobre cómo la mayoría de los comerciantes aún pueden aceptar el pago inmediatamente en 0/sin confirmar con un riesgo mínimo de que se produzca un gasto doble, aunque requieren algunos procesos adicionales que aún no se han desarrollado, probado y perfeccionado.
Además, existen otros enfoques para este problema para que no haya demoras en la confirmación, aunque sus implementaciones son externas y no se benefician de la arquitectura descentralizada de Bitcoin (es decir, cada uno requiere confianza otorgada a otra parte):
Esta es una actualización, a partir de NOV-2012, ya que las respuestas están desactualizadas.
¿Hay alguna vulnerabilidad en este momento?
Probablemente no. Pero podría crearse una nueva vulnerabilidad por error en futuras versiones del cliente estándar.
¿Hubo alguno en el pasado?
Sí, consulte https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures y verá que se han solucionado muchas vulnerabilidades. Casi el 50 % de los nodos siguen siendo vulnerables a CVE-2012-4682 y CVE-2012-4683.
alex aguas
david schwartz
felipe