¿Cómo detectar un ataque de carrera y volver a gastar las salidas ya gastadas?

Mi servicio acepta, procesa y envía automáticamente pagos a sus usuarios. Se conecta a bitcoind a través de su API JSON-RPC y hace uso de la raw transactionsinterfaz.

Que va a pasar en este caso:

  • El servicio recibe 3 pagos de 3 usuarios diferentes.
  • Todos los pagos se incluyen en el siguiente bloque, por lo que ahora tienen una confirmación.
  • Tras una confirmación, el servicio forma un nuevo TX que gasta estas 3 salidas. Se adjunta la tarifa correspondiente. El TX ahora es válido pero no confirmado.
  • Unos segundos más tarde, se produce un ataque de doble gasto en una de las salidas (ahora gastadas) del TX.

Como me resulta difícil reproducir el escenario anterior, mi pregunta es:

  1. ¿Cuál es la mejor manera para que el servicio detecte este ataque de doble gasto a través de la API de RPC?
  2. Una vez que detecta el gasto doble y se da cuenta de que el TX nunca se confirmará, ¿puede volver a gastar las mismas salidas (sin incluir la que se gastó el doble) de inmediato en el caso de un ataque de carrera?
Siento que esto es una repetición de las preguntas respondidas que hiciste aquí y aquí . Si esto es un riesgo real para su servicio, le recomiendo que se siente con el modo de registro y desarrolle una prueba de unidad sólida que pueda ejecutar contra su código de producción. Hay un ejemplo básico en esta respuesta .
@DavidA.Harding gracias por la sugerencia sobre el procedimiento de prueba y todas sus excelentes respuestas hasta ahora. Corríjame si me equivoco, pero AFAIU esta pregunta describe un ataque de doble gasto basado en bifurcación , mientras que la pregunta anterior se refiere a un ataque de doble gasto basado en la raza , que en mi opinión es un caso totalmente diferente, ¿no es así? ¿él?
Estoy confundido. En la viñeta #1, recibe las salidas a, b, c de TX1, TX2 y TX3. En la viñeta #2, estos TX obtienen una confirmación. En la viñeta #3, usa esas salidas como entradas a, b, c para crear TX4. ¿Qué sucede exactamente en la bala #4? Un gasto doble que invalide TX1, TX2 o TX3 requeriría una bifurcación (consulte las respuestas anteriores). Se necesitaría crear un gasto doble usando las entradas a, b o c para invalidar TX4 con las mismas claves privadas que usa su servicio o algo multigrado; ¿Es eso un riesgo aquí? ¿O está pagando a otras personas y preocupándose de si gastan el doble de las salidas de TX4?
@DavidA.Harding mi culpa por no dejarlo claro, gracias por señalarlo. Lo que tenía en mente es que el atacante transmitiría dos TX en conflicto en rápida sucesión y el malicioso se propagaría más rápido que el otro que paga mi servicio. Si acababa de gastar las salidas de este TX (que tendría 1 conf) para formar otro (TX4) ¿cómo debería comportarse el servicio? Pero creo que entiendo lo que dices: si hay al menos 1 conf por la red, no es posible un ataque de doble gasto basado en raza, mientras que un ataque de doble gasto basado en bifurcación sí lo es, ¿es eso correcto?
eso es correcto.

Respuestas (1)

Como dijo Doug en los comentarios de la pregunta (publicados aquí como respuesta a su solicitud):

Si hay al menos 1 conf por la red, no es posible un ataque de doble gasto basado en la raza.

Por lo tanto, el ataque que describe es un doble gasto basado en una bifurcación similar a sus preguntas aquí y aquí .

¿Cómo detectar un ataque de carrera y volver a gastar las salidas ya gastadas?
RespuestasAquíPolítica de privacidad1y, 0v