Tengo problemas para entender el error que se solucionó en BIP030 y cómo se explotaría.
¿La premisa de este ataque es que tendría que haber un netsplit y la cadena se bifurcó y luego se revirtieron las transacciones anteriores?
¿Cómo sería la pseudo-lógica de validación de lo siguiente?
Hay varias soluciones potenciales a este problema:
- Garantice que todas las bases de monedas sean únicas, lo que hace que las transacciones duplicadas sean muy difíciles de crear.
- Recuerde las salidas restantes anteriores de un identificador de transacción dado, en caso de que se agregue una nueva transacción con el mismo identificador.
- Solo permita transacciones duplicadas en caso de que la instancia anterior de la transacción no tuviera salidas gastables. Eliminar un bloque de la cadena puede restablecer de manera segura las salidas de la transacción eliminada a nada.
La razón por la que pregunto es para poder desarrollar reglas de validación adicionales que funcionen en paralelo con el cliente existente.
El problema era que, en caso de que se creara una transacción duplicada en una rama lateral que luego se revierte y solo es vista por una cierta parte de la red, existe un riesgo de bifurcación. Los nodos A que hayan visto las transacciones duplicadas y su anulación considerarán que la transacción original no se puede gastar (ya que se sobrescribió y posteriormente se eliminó de su base de datos de transacciones en la reorganización), mientras que los nodos B que no vieron el duplicado considerarán la transacción original como gastable. . Cuando la transacción original se gasta después, y la mayoría de la red está en B, la red se dividirá, ya que los nodos A considerarán que la cadena creada por B no es válida.
La tercera solución presentada es implementada por BIP30: esta fue una solución provisional para evitar que sucediera lo peor. Una solución más completa (la primera) implementada como BIP 34