En un contrato dado, ¿debería la marca de tiempo "LockTime" incluir una hora adicional para las confirmaciones para evitar un gasto doble?

Cada vez que una transacción tiene una marca de tiempo adjunta, y hay transacciones firmadas pero no enviadas en juego, ¿no debería el titular del tx no enviado tener en cuenta las confirmaciones con el tiempo de vencimiento?

Es decir, en el ejemplo 7 de esta página wiki sobre contratos , creo que si el AP espera hasta casi la medianoche (casi cuando expira el tx), entonces existe la posibilidad de un gasto doble y es posible que no se pague al AP. Eso significa que AP tendría que enviar las confirmaciones de tx 6 antes... casi una hora.

  • ¿Es esta una comprensión correcta del tiempo de bloqueo en relación con los ataques de doble gasto?

  • ¿Cómo se debe manejar esto cuando la red está aumentando rápidamente en la generación de bloques (y la dificultad no se ha ajustado)? Esto está sucediendo ahora con la conversión GPU-> ASIC

Respuestas (1)

El nLockTime es el momento más temprano en que un minero puede incluir esa transacción en un bloque. No significa el momento exacto en que ambas partes pueden asumir que se ha producido la liquidación definitiva.

Tiene razón al concluir que existe la posibilidad de que otra transacción (con nLockTime = 0) se transmita y compita al mismo tiempo que la transacción original nLockTime > 0).

Pero no sería necesariamente un gasto doble, ya que la transacción vista más adelante con nLockTime = 0 tendría que haber sido firmada por ambas partes.

Si ocurre un escenario de "gasto doble", no sería una sorpresa para ninguna de las partes.

La situación puede ocurrir donde las dos partes creen que la transacción nLockTime = 0 será la que se confirmará y por alguna razón no se confirma lo suficientemente rápido. En cambio, en el nLockTime de la transacción original (aproximadamente, ya que hay un par de horas de margen disponible para el minero en lo que respecta a la marca de tiempo), esa transacción se confirma y, por lo tanto, la transacción enviada más tarde (donde nLockTime = 0) nunca se confirmará.

Por lo tanto, el umbral del nivel de confirmación normal (por ejemplo, seis confirmaciones) aún se aplica a estas transacciones en lo que respecta a la liquidación final.

Esa es una buena explicación de cómo sería el tiempo de seguimiento de la transacción. Supongo que el inicio de la transacción tendría que esperar 6 confirmaciones y estaría sujeto a todas las condiciones normales de carrera en este caso.