¿Posible condición de carrera (doble gasto) en HTLC-Timeout en la red lightning?

De las salidas HTLC ofrecidas,

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

Con las siguientes condiciones,

  • a locktimese establece en 600900 en la transacción HTLC-Timeout.
  • el nodo remoto tiene el payment_secret.
  • el nodo local desea agotar el tiempo de espera de la última transacción de compromiso.

Según tengo entendido, para agotar el tiempo de espera de la última transacción de compromiso, el nodo local tiene que,

  1. transmitir la transacción de compromiso en blockheight 600900;
  2. transmitir inmediatamente la transacción HTLC-Timeout;
  3. espere unos días para gastar la transacción HTLC-Timeout una vez que haya pasado el valor de bloqueo de tiempo especificado.

Mientras tanto, el nodo remoto con payment_secretpuede gastar la transacción de compromiso también. ¿Causará esto una condición de carrera/doble gasto en la red de Bitcoin? Si es así, ¿cómo se puede resolver?

Respuestas (1)

En primer lugar, creo que parece haber una pequeña confusión sobre la notación. Uno no gasta una transacción, sino salidas de transacción. En el caso de htlcs ofrecidos, la salida es solo una salida (entre muchas otras potencialmente).

También entiendo el bloqueo de tiempo ligeramente diferente. Si publica la transacción de compromiso, se puede extraer y verificar directamente. Es la salida bloqueada por tiempo, por ejemplo, el htlc que solo se puede gastar después del bloqueo de tiempo.

Con respecto a la condición de carrera / doble gasto. En primer lugar, los gastos dobles en Bitcoin son imposibles por diseño (a menos que tengamos un exploit desconocido), por lo que podemos reducirlo a la cuestión de una condición de carrera. Aquí tenemos que distinguir dos casos:

  1. Antes del timelock: en ese caso no se puede gastar la salida htlc y solo el lado remoto puede hacerlo con la preimagen. Es el Período de seguridad para que el lado remoto obtenga los fondos si se suponía que se reenviaría el htlc.
  2. Después del bloqueo de tiempo: en ese caso, de hecho, puede surgir una condición de carrera. En ese momento, el lado remoto no debería obtener la preimagen, sino cancelar el enrutamiento de todos modos, pero si no barre la salida y el lado remoto obtiene la preimagen, entonces, de hecho, se trata de qué gasto se incluirá primero en un bloque.
¡Gracias por su respuesta! Sin embargo, el tx de compromiso local debe transmitirse con el tx htlc-timeout, de lo contrario, no habría condición de carrera. Me pregunto si es responsabilidad del titular de la preimagen evitar la condición de carrera.
Así que tengo una pregunta aquí. Suponga que el período de tiempo de espera es 600900 y la transacción HTLC_success se transmite en el bloque 600959. Mientras tanto, en 600900, también se transmite el tiempo de espera de HTLC. En este caso, ¿cuál se incluirá en la cadena de bloques?
@SubhraMazumdar Las transacciones de éxito y tiempo de espera de HTLC están gastando la misma salida, por lo que no se pueden minar ambas.
¿Posible condición de carrera (doble gasto) en HTLC-Timeout en la red lightning?
RespuestasAquíPolítica de privacidad1y, 0v