¿Por qué necesitamos la revocación tanto en las salidas de HTLC ofrecidas/recibidas como en las salidas de tiempo de espera/éxito de HTLC?

La secuencia de comandos testigo para la salida en la transacción de éxito/tiempo de espera de HTLC es:

OP_IF
    # Penalty transaction
    <revocationpubkey>
OP_ELSE
    `to_self_delay`
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

Que ya existe una transacción de sanción. Mientras que en el HTLC ofrecido y las salidas HTLC recibidas en la transacción de compromiso, tenemos,

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
...

¿Por qué no ponemos la revocación solo en las salidas HTLC-Timeout/Success?

Respuestas (2)

Los HTLC tienen un tiempo de espera diferente ( cltv_expiry) que el tiempo de espera regular que usamos para las transacciones de penalización ( to_self_delay). Esa es la razón por la que usamos una etapa de transacción separada (HTLC éxito/HTLC tiempo de espera) para permitir que nuestra contraparte tenga suficiente tiempo para ejercer su derecho a obtener el saldo completo del canal en caso de que transmitamos el estado anterior del canal.

Para dar más detalles, cuando su contraparte le diga que agregue un HTLC, su versión de la transacción de compromiso tendrá 3 salidas:

  1. Pagar a su contraparte inmediatamente
  2. Pagándose a sí mismo, custodiado por la clave de revocación por to_self_delaytiempo
  3. Salida HTLC recibida como a continuación
    # 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_IF
        # To local node via HTLC-success transaction.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node after timeout.
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

Cuando proporciona la imagen previa de HTLC a su contraparte, la transacción se resuelve. Sin embargo, incluso después de la resolución exitosa del HTLC con su contraparte, digamos que decide engañarlos cerrando a la fuerza el estado anterior de la transacción de compromiso que contiene el HTLC. Tan pronto como publique esta transacción de compromiso, publica la transacción de éxito de HTLC que consume la OP_IFparte dentro del archivo OP_ELSE. Dado que la transacción exitosa de HTLC está consumiendo una salida que no está bloqueada en el tiempo, no está proporcionando suficiente tiempo para que su contraparte use su derecho de la clave de revocación que se encuentra en la salida de HTLC recibida. Esa es la razón por la que hay una segunda etapa, donde su gasto de la salida HTLC ofrecida para usted está bloqueado hasta queto_self_delayque permite a su contraparte utilizar el secreto de revocación.

Ahora puede preguntarse por qué existe la revocación en la salida de HTLC recibida de la transacción de compromiso si se proporciona en las transacciones de éxito/tiempo de espera de HTLC. Tomemos el caso anterior para explicarlo. Agregó el HTLC y firmó la transacción de compromiso. Ese HTLC se liquidó cuando usted proporcionó la imagen previa a su contraparte y se revocó la transacción de compromiso que contenía ese HTLC. A pesar de eso, suponga que intenta transmitir la transacción de compromiso anterior que contiene el HTLC y se abstiene de publicar la transacción exitosa de HTLC. Si la revocación no existiera en la transacción de compromiso, la contraparte podría no ser capaz de recuperar sus fondos hasta que elcltv_expiryque podría extenderse a cientos de bloques (un par de días) si hay varios saltos. Esto es engorroso ya que ese HTLC ya se liquidó (especialmente si hay una cantidad de HTLC previamente satisfechos), y la provisión de revocación en la transacción de compromiso permite que la contraparte los liquide de inmediato.

La parte de revocación está diseñada para que su contraparte nunca sufra por las acciones que decida tomar para engañarlos. La presencia de revocación en la transacción de compromiso y la transacción de éxito de HTLC/tiempo de espera de HTLC ayuda a proteger a los participantes de Lightning Network de los fraudes cometidos por sus pares.

Si publica un tx de compromiso anterior con 1 HTLC recibido, la contraparte puede ingresar al proceso de tiempo de espera como se especifica en cltv_expiryy luego cobrar el dinero a través del tiempo de espera de HTLC de todos modos. Entonces, ¿su punto es que no queremos que la contraparte espere tanto tiempo si hace trampa? No parece tener una buena razón para publicar este tx, aunque se puede desear un daño puro .
@yyforyongyu (1) Sí, tiene razón en que la contraparte puede cobrar después del proceso de tiempo de espera, pero el nodo local (que está haciendo trampa) puede gastarlo inmediatamente usando la transacción de éxito de HTLC (ya que tiene la imagen previa). (2) no es solo daño puro, sino que definitivamente tiene incentivos económicos para publicarlo. Obtuvo los fondos de su contraparte al proporcionar la imagen previa para el HTLC. Suponga que después de eso proporcionó algunos fondos a su contraparte por algún bien que les compró. El estado anterior que incluía el HTLC es más beneficioso para ti, así que lo publicas.
Digamos que soy el nodo local que está haciendo trampa. Tengo que gastarlo a través de un HTLC-success tx, que tiene una revocación dentro. Una vez que gasto el compromiso tx, tengo que esperar to_self_delayun tiempo antes de poder gastar el HTLC-success tx, mientras tanto, ¿la contraparte puede tomar el dinero a través de la revocación?
@yyforyongyu Sí. Dado que puede gastar la salida de HTLC de la transacción de compromiso inmediatamente (para el éxito de HTLC), no le dará tiempo a su contraparte para que reaccione. Como resultado, la to_self_delaysalida de éxito dentro del HTLC permite a la contraparte usar la revocación y luego gastar el dinero.
interesante. Esto vuelve a la pregunta original, si la contraparte puede tomar el dinero a través de la revocación dentro del HTLC-success tx, ¿cuál es el punto de tener una revocación dentro del compromiso tx?
@yyforyongyu Eso se responde en el penúltimo párrafo de mi respuesta (traté de hacerlo más claro). ¿Qué pasa si el tramposo nunca publica la transacción exitosa de HTLC? Aunque ese HTLC se liquide, es posible que la contraparte tenga que esperar un par de cientos de bloques para liquidarlo (si hay una cantidad de saltos). Imagínese si contuviera varios HTLC de este tipo y tuviera que esperar a que cada uno de ellos caducara a pesar de que todos se han resuelto.

TL;DR

Porque crearía una dependencia desagradable de los deltas de CLTV sobre el retraso de CSV o una seguridad reducida para los HTLC.
Tener la ruta de revocación en la transacción de la segunda etapa permite agotar el tiempo de espera de un HTLC (es decir, su compañero ya no puede canjearlo a través de una imagen previa) mientras deja intacto el período de revocación (CSV) para que usted sea castigado si hizo trampa.

HTLC de dos etapas

El protocolo Lightning Network utiliza HTLC de dos etapas.
Por qué : permite usar delta de bloqueo de tiempo absoluto más corto que el delta de bloqueo de tiempo relativo utilizado para el modelo de seguridad fundamental (castigo), sin degradar el modelo de seguridad para las salidas HTLC.
Cómo : hacer que (básicamente) las salidas HTLC paguen a la ruta de revocación, las transacciones [tiempo de espera/éxito] solo se pueden transmitir después del bloque Bo al receptor con la preimagen. Haga que la transacción [tiempo de espera/éxito] pague solo después del vencimiento total del período de revocación (ya no hay ruta de preimagen aquí, si el receptor no hizo trampa, se le pagará ).

Más información sobre los HTLC de dos etapas en esta respuesta .

¿Por qué poner la ruta de revocación en ambas etapas?

Porque la primera etapa vence al final del período de bloqueo de tiempo absoluto, que probablemente sea menor que el período de revocación.
Si la ruta de revocación no estaba presente en la segunda transacción (que en realidad es el objetivo de usar dos etapas), entonces reduciría drásticamente el período de revocación para las salidas HTLC o requeriría el uso de deltas CLTV increíblemente altos.

Un ejemplo

Tengo un canal contigo, y acordamos una to_self_delayde 144 bloques (1 día para sancionar la emisión de un estado revocado) y una (temeraria) cltv_expiry_deltade 6 bloques.

Acabo de intentar hacer un pago a través de nuestro canal. Agregamos una salida HTLC ofrecida a mi transacción de compromiso y una salida HTLC recibida a la suya.
Digamos que a alguien le pareció divertido no tomar sus tarifas insignificantes y en su lugar atascó al HTLC para meterse con nosotros. Después de 4 bloques, fallamos el HTLC, firmamos un nuevo par de transacciones de compromiso y continuamos con las operaciones. Más tarde me enteré de que en realidad bloqueaste el HTLC justo después de recopilar la preimagen.

No creamos nuevos estados a nuestro canal y la misma noche sufro un corte de energía, mi nodo se desconecta y no me doy cuenta hasta que estoy despierto (5 horas después).
En el momento exacto en que me desconecté, tomó la decisión absolutamente irracional de transmitir su antigua transacción de compromiso en la que todavía tiene una salida HTLC recibida firmada.
Su transacción se confirma y pasa los 6 bloques (todavía 4 horas hasta que me despierte), puede reclamar la salida con sus transacciones exitosas de HTLC.

4 horas más tarde, me despierto, vuelvo a poner en línea mi nodo respaldado continuamente y noto la brecha.
Antes de que pudiera tener el tiempo para sentirme desilusionado, decepcionado y lo suficientemente frustrado como para lanzar malas palabras a un alias aleatorio de color de Internet , mi nodo robó sus monedas de la salida de su transacción de compromiso to_self, reclamó mi to_remotesalida y gastó su transacción de éxito HTLC.

Sin la ruta de revocación en la segunda etapa, mis monedas se perderían.

¿Por qué necesitamos la revocación tanto en las salidas de HTLC ofrecidas/recibidas como en las salidas de tiempo de espera/éxito de HTLC?
RespuestasAquíPolítica de privacidad1y, 0v