De BOLT 02 podemos aprender
Cuando un nodo tiene cambios para el compromiso remoto, puede aplicarlos, firmar la transacción resultante (como se define en BOLT #3) y enviar un
commitment_signedmensaje.1. type: 132 (`commitment_signed`) 2. data: * [`channel_id`:`channel_id`] * [`signature`:`signature`] * [`u16`:`num_htlcs`] * [`num_htlcs*signature`:`htlc_signature`]
¿Por qué no es suficiente la firma de toda la transacción de compromiso? Entiendo que cada HTLC tiene la suya htlc_pubkeyy, por lo tanto, también htlc_secretnecesita una firma en la transacción exitosa de HTLC, pero ¿cuál fue la razón detrás de este diseño?
¿Por qué no es suficiente la firma de toda la transacción de compromiso?
Porque el htlc_signaturecampo contiene la firma de las transacciones de HTLC que se gastan de los resultados de HTLC (recibidos u ofrecidos) de la transacción de compromiso.
Para ampliar un poco, algunas rutas de los scripts HTLC (tiempo de espera para una salida htlc ofrecida y éxito para una salida HTLC recibida ) pagan a un 2 de 2, por lo que necesita que se firme la transacción correcta que gasta de esta salida antes de comprometerse con esto ( de lo contrario, no se puede gastar usando esta ruta de script).
EDITAR: esta pregunta se origina en este problema de Github , al que Olaoluwa Osuntokun (@Roasbeef) dio hoy una explicación detallada de alto nivel de por qué se usan HTLC de segunda etapa en Lightning Network.
El siguiente es el copiar y pegar de su respuesta que podría ser de interés para cualquiera que pase.
Aquí está mi intento de una explicación de alto nivel:
Usamos algo llamado HTLC de dos etapas en el sistema. Esto nos permite desacoplar el CLTV (bloqueo de tiempo absoluto para HTLC) del CSV (retraso de compromiso para permitir la retribución por incumplimiento). Para ver por qué esto es un problema, considere si tuviéramos ambos en el script HTLC de nivel superior. A partir de aquí, uno puede imaginar un escenario en el que tenemos un HTLC que se puede agotar (se superó la altura absoluta del bloque), pero no podemos gastarlo (agotarlo) hasta que nuestro período de CSV también haya expirado. Por lo tanto, es necesario establecer sus valores CSV teniendo en cuenta también el valor de bloqueo de tiempo absoluto (CLTV). Fundamentalmente, antes de que un usuario pueda cancelar su HTLC entrante fuera de la cadena (agotando el tiempo de salida en la cadena), debe esperar este período de CSV. Sin embargo, si el CSV es mayor que el delta de bloqueo de tiempo (diferencia entre los HTLC entrantes y salientes),
Sin HTLC, la dependencia entre el valor delta de CLTV y el valor de CSV significa que si uno quiere tener un valor de CSV más alto (más tiempo para castigar a los pares de canales maliciosos), también necesita tener un valor de delta de CLTV más largo. Como ejemplo, una configuración común con lnd es que para los canales de valor súper alto tenemos un valor de CSV de 2016 bloques (dos semanas). Sin los HTLC de segundo nivel, necesitaríamos también hacer que nuestro valor delta de CTLV (40 bloques atm predeterminados) sea mayor que 2016 bloques. Este cambio luego se propagaría a través de toda la red, dando como resultado valores de bloqueo de tiempo muy largos. El remitente de un HTLC se come la demora de bloqueo de tiempo completo, lo que significa que sabe que su peor de los casos es mucho mayor, y se compensa por una mejor seguridad de HTLC de múltiples saltos.
Afortunadamente, encontramos una solución a esto: HTLC de dos etapas. Tenga en cuenta que los scripts HTLC que describí anteriormente nunca se implementaron realmente. Los HTLC de dos etapas se utilizan en realidad en el informe técnico original de LN por una razón similar. El diseño defectuoso descrito anteriormente se creó cuando los desarrolladores intentaban comprimir un poco los scripts y la huella en la cadena.
Un HTLC de dos etapas desacopla el período CSV del delta de bloqueo de tiempo CTLV. Para hacer esto, ahora requerimos que la parte que forzó el cierre gaste su HTLC con una transacción especial. Esta transacción gasta una cláusula CLTV en el script y también incluye un valor nLocktime. El resultado de esta transacción especial luego paga a la parte que cronometra o canjea el HTLC, pero luego aplica un período de CSV. Los llamamos dos etapas, ya que aplicamos dos estados en el reclamo: esperar el valor de tiempo de espera absoluto, luego esperar el valor CSV. Tenga en cuenta que una vez que pasa el valor de tiempo de espera absoluto, la parte puede gastar la salida de HTLC original, haciendo la transición de la máquina de estado de reclamo de HTLC al período de espera de CSV. En este punto, pueden cancelar de forma segura cualquier HTLC fuera de la cadena, ya que la otra parte no puede resolverlo con una imagen previa en este punto.
La forma en que hacemos cumplir este gasto es que hacemos que cualquier gasto de HTLC de la transacción de compromiso de uno (que transmite durante un cierre forzado) sea en realidad una salida de múltiples firmas. Usamos esta salida para crear lo que es esencialmente un "pacto multi-sig fuera de la cadena". Dado que requieren nuestra firma para gastar esta salida, los obligamos a realizar un tipo particular de gasto utilizando transacciones prefirmadas. Como resultado, cada vez que queremos darles un nuevo compromiso, además de la firma del compromiso (gasto multisig de la producción de fondos), también enviamos una serie de firmas, una para cada HTLC, que bendice su gasto del Salida HTLC.