Una vez escuché un ataque contra LN, que se llamó "inundación y botín": https://medium.com/blockchains-huji/flood-loot-a-systemic-attack-on-the-lightning-network-5c3dac7bba24
El tercer paso de ese ataque se describió de la siguiente manera:
tercero Resolver pagos en el último salto
Una vez que todos los pagos se enrutaron con éxito y los HTLC se agregaron a los canales del nodo de destino, el nodo de destino resuelve todos los pagos devolviendo los secretos requeridos y reclama estos fondos para sí mismo. En ese momento, el nodo de destino podría cerrar con gracia sus canales y marcharse con los fondos enviados por el nodo de origen. Una vez que cada víctima adquiere los secretos, los envía de regreso al nodo de origen, solicitando resolver los HTLC y mover su cantidad al lado del canal de la víctima. El nodo de origen se niega a resolver los pagos e ignora cualquier otro mensaje de sus víctimas.
Entonces, ¿qué significa "resolver el HTLC" aquí? Veo un mecanismo titulado "Terminación fuera de la cadena de HTLC" en el documento técnico de LN. ¿El término "resolver" aquí se refiere a este mecanismo?
Si es así, creo que resolver/terminar los HTLC del nodo de destino fuera de la cadena le da al atacante una ventaja (o le da una desventaja a la víctima) cuando los HTLC del nodo de origen aún no se han resuelto/terminado fuera de la cadena. Porque, una vez que se resuelvan los HTLC del nodo de destino, la víctima confiará completamente en que se ejecuten los HTLC del nodo de origen (en lugar de que caduquen/reembolsen) para simplemente evitar la pérdida de fondos, en el mejor de los casos, mientras tanto, el atacante se beneficiará robando fondo de vencimiento/reembolso de HTLC, incluso en el peor de los casos, el atacante no perderá nada.
Entonces, ¿qué pasa si el nodo de la víctima en el medio se niega a resolver los HTLC con el nodo de destino también, siempre y cuando el nodo de origen se niegue a resolver sus HTLC con el nodo de la víctima en primer lugar?
¿Por qué, cómo y cuándo debe un nodo LN intermedio terminar/resolver su(s) HTLC(s) fuera de la cadena?
Primero, recomendaría leer BOLT2 en la sección Operación normal del canal para comprender exactamente cómo y cuándo se resuelven los htlcs. El documento técnico está muy desactualizado y solo explica los principios.
Dicho esto, el problema de su pregunta permanece.
Para responder a su pregunta: los nodos intermedios deberían resolver los HTLC lo más rápido posible, pero eso depende del par saliente.
Supongamos el siguiente camino:
A-->B-->C-->D
Tan pronto como D resuelva el HTLC fuera de la cadena, C debería resolverlo con B. Y B debería luego resolverlo con A. El problema ocurre si A deja de hablar con B. En ese caso, B no puede resolver sus HTLC mientras pagó a C, a quien se le reembolsó. paga D antes. Desafortunadamente, B solo puede resolver su HTLC con A después de haber resuelto los HTLC con C. La idea de hacerlo al revés no funcionaría y eliminaría la propiedad sin confianza del enrutamiento.
En teoría, esto no debería ser un problema para B, ya que B puede desencadenar un cierre forzado del canal y resolver los HTLC en cadena. Sin embargo, esto genera varias preguntas prácticas que pueden conducir al ataque descrito:
El tercer punto podría conducir al escenario del segundo que puede conducir al primero. En tales casos, pueden ocurrir efectos secundarios y B puede perder sus fondos que están en el HTKC ya que B le ha pagado a C pero A no le reembolsará a pesar de que tiene las transacciones en cadena firmadas adecuadas.
Un nodo generalmente no quiere forzar el cierre del canal ya que eso es costoso. Especialmente si esos nodos esperan reclamar salidas htlc. Sin embargo, si el bloqueo de tiempo htlc se cierra, el nodo debe considerar cerrar el canal para obtener el compromiso txcinfirmed y estar mejor preparado en el sentido de tener una ventana de tiempo para resolver sus HTLC sin que A pueda interferir.
Lamento no poder darte una respuesta definitiva aquí. Eso es exactamente parte del problema/ataque y lo hace tan sutil