Update ln-07.md
This commit is contained in:
Bitcoin Txoko
+139
-1
@@ -163,4 +163,142 @@ Bob quiere comprometer irrevocablemente algunos de los HTLCs para poder reenviar
|
|||||||
|
|
||||||
##### Paso 8: Alice -> Bob: revoke_and_ack
|
##### Paso 8: Alice -> Bob: revoke_and_ack
|
||||||
|
|
||||||
Al igual que Bob hizo anteriormente, Alice responde al `commitment_signed` con un `revoke_and_ack` para revocar su estado anterior. Esto también sirve como un reconocimiento para Bob de que Alice ha recibido y se ha comprometido a `B1`, por lo que Bob ahora
|
Al igual que Bob hizo anteriormente, Alice responde al `commitment_signed` con un `revoke_and_ack` para revocar su estado anterior. Esto también sirve como un reconocimiento para Bob de que Alice ha recibido y se ha comprometido a `B1`, por lo que Bob ahora puede agregar `B1` a su transacción de compromiso en el área de preparación.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Rápida limpieza...
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
¡Por fin, tenemos algunos HTLCs comprometidos de forma irrevocable! `A1` y `A2` han sido comprometidos de forma irrevocable. `B1` y `A3`, sin embargo, no lo han sido ya que aún no han sido comprometidos por ambas partes.
|
||||||
|
|
||||||
|
Comprometamos rápidamente `B1` y `A3` de forma irrevocable también.
|
||||||
|
|
||||||
|
##### Paso 8: Alice -> Bob: commitment_signed
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 9: Bob -> Alice: revoke_and_ack
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 10: Bob -> Alice: commitment_signed
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 11: Alice -> Bob: revoke_and_ack
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Limpiado:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
¡Ahora todos los HTLCs han sido comprometidos de forma irrevocable!
|
||||||
|
|
||||||
|
#### Eliminando HTLCs
|
||||||
|
|
||||||
|
Probablemente ya entiendas la idea de agregar HTLCs. Pero, ¿qué pasa con eliminarlos? Los HTLCs se eliminan si un pago tiene éxito o si falla. Ten en cuenta que los mensajes de eliminación de HTLC solo pueden ser enviados por el par que no envió la actualización original `update_add_htlc` y que los HTLCs solo son removibles una vez que han sido comprometidos de forma irrevocable. Afortunadamente para nosotros, todos los HTLCs han sido comprometidos de forma irrevocable, así que podemos comenzar a eliminarlos ahora.
|
||||||
|
|
||||||
|
##### Paso 12: Bob -> Alice: update_fulfill_htlc(A2)
|
||||||
|
|
||||||
|
En el mejor de los casos, un HTLC se elimina porque se está cumpliendo, lo que significa que su pre-imagen se está devolviendo. Esto se hace con el mensaje `update_fulfilled_htlc`, que se ve así:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
En nuestro ejemplo, Bob envía a Alice el mensaje `update_fulfill_htlc` para el HTLC `A2`. Esto también demuestra que los HTLCs no tienen que ser eliminados en el mismo orden en que fueron agregados.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Ten en cuenta que, al igual que las actualizaciones para agregar un HTLC, las actualizaciones para eliminar un HTLC también estarán inicialmente pendientes en el lado receptor hasta que hayan sido reconocidas por un `revoke_and_ack`. Así que, en nuestro caso, Alice elimina `A2` de su transacción en el área de preparación cuando recibe el `update_fulfill_htlc` (y asigna el monto del HTLC a la salida de Bob), pero Bob aún no elimina el HTLC de su transacción en el área de preparación.
|
||||||
|
|
||||||
|
A diferencia de otros mensajes de actualización, no hay necesidad de esperar a que una eliminación de HTLC sea comprometida de forma irrevocable si recibes la pre-imagen para ello. Después de todo, puedes enviar inmediatamente la pre-imagen hacia arriba para reclamar cualquier HTLC allí.
|
||||||
|
|
||||||
|
##### Paso 13: Bob -> Alice: update_fail_htlc(A1)
|
||||||
|
|
||||||
|
Los HTLCs también pueden ser eliminados debido a fallos en el pago, como el tiempo de espera de los HTLCs o si hubo algún tipo de fallo de enrutamiento, como que un canal específico en la ruta ya no exista, no se cumplan los requisitos de tarifa de un salto, un enlace no tenga saldo suficiente, etc. Tales fallos se comunican con el mensaje `update_fail_htlc`:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
El campo de razón es un blob cifrado para el remitente del pago para informarles sobre la razón del fallo.
|
||||||
|
|
||||||
|
Después de que Bob envía a Alice el mensaje `update_fail_htlc` para `A1`, el estado se ve como sigue:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 14: Bob -> Alice: update_fail_malformed_htlc(A3)
|
||||||
|
|
||||||
|
El mensaje final que se puede usar para eliminar un HTLC es el mensaje `update_fail_malformed_htlc`:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Este mensaje se envía si algún salto en la ruta de pago no pudo analizar el `onion_routing_packet` que recibió en `update_add_htlc`. Si Bob envía a Alice este mensaje para `A3`, entonces el estado ahora se ve así:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 15: Alice -> Bob: update_fulfill_htlc(B1)
|
||||||
|
|
||||||
|
Alice también inicia la eliminación de `B1` enviando un `update_fulfill_htlc` a Bob.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Ahora limpiemos las eliminaciones de HTLC comprometiéndolas de forma irrevocable. Esto requerirá algunos flujos de `commitment_signed` - `revoke_and_ack`:
|
||||||
|
|
||||||
|
##### Paso 16: Bob -> Alice: commitment_signed
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 17: Alice -> Bob: revoke_and_ack
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 18: Alice -> Bob: commitment_signed
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 19: Bob -> Alice: revoke_and_ack
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 20: Bob -> Alice: commitment_signed
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### Paso 21: Alice -> Bob: revoke_and_ack
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Los dos estados válidos ahora se ven bonitos y limpios nuevamente:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### Actualizando tarifas
|
||||||
|
|
||||||
|
Hay un mensaje `update_*` más que necesitamos cubrir y ese es el mensaje `update_fee`. Este mensaje se utiliza para actualizar la tasa de tarifa que los pares deben usar al construir sus transacciones de compromiso. La tasa de tarifa original se decide en el flujo de apertura de canal, pero si la tasa de tarifa promedio del mempool aumenta, el financiador del canal podría decidir actualizar la tarifa de las transacciones de compromiso para que tengan una mejor oportunidad de ser confirmadas de manera oportuna en una situación de cierre forzado. También podría ser que cuando se abrió el canal, se eligió una tasa de tarifa muy alta y quizás se desearía una tasa de tarifa más baja.
|
||||||
|
|
||||||
|
Este mensaje sigue reglas similares a otros mensajes `update_*` en que también debe ser comprometido de forma irrevocable antes de que surta efecto. La única regla adicional que se aplica a este mensaje es que solo el financiador del canal puede enviar este mensaje:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Ten en cuenta que con los canales de anclaje, la necesidad de usar el mensaje `update_fee` se está volviendo cada vez menor, ya que los nodos podrán usar CPFP en la transacción de cierre forzado si es necesario.
|
||||||
|
|
||||||
|
### Retransmisión de mensajes
|
||||||
|
|
||||||
|
Algo que puedes haber notado en el flujo de agregar/eliminar HTLC es que los reconocimientos explícitos para los mensajes `update_*` se retrasan hasta el intercambio de `commitment_signed`/`revoke_and_ack`. Eso está bien la mayor parte del tiempo, ya que asumimos que el transporte subyacente entre los dos nodos (ver [BOLT8](https://github.com/lightning/bolts/blob/master/08-transport.md)) es ordenado y confiable. Sin embargo, si por alguna razón la conexión entre los dos nodos necesita ser restablecida, habrá dudas sobre si nuestro par ha recibido el último mensaje que enviamos. Aquí es donde entra el mensaje `channel_reestablish`. Al reconectarse, antes de continuar con el flujo de operación normal, los pares intercambiarán este mensaje para asegurarse de que están en la misma página y para determinar qué mensajes posiblemente necesitan retransmitir a su par.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Cada par en el canal tiene su versión de la transacción de compromiso y las dos transacciones de compromiso pueden actualizarse de forma independiente, lo que significa que el número de veces que el estado de la transacción de compromiso de un lado ha sido actualizado (a través del flujo de `commitment_signed` y `revoke_and_ack`) podría ser completamente diferente al del otro lado.
|
||||||
|
|
||||||
|
El campo `next_commitment_number` en el mensaje `channel_reestablish` nos permite comunicarnos con nuestro par sobre el próximo `commitment_signed` que esperamos recibir de ellos. De esta manera, ellos sabrán si quizás hemos perdido un `commitment_signed` de ellos que enviaron anteriormente antes de la desconexión. En otras palabras, `next_commitment_number` le dice al par remoto cuál es nuestro último estado comprometido.
|
||||||
|
|
||||||
|
De manera similar, `next_revocation_number` es el número de compromiso del próximo `revoke_and_ack` que esperamos recibir. En otras palabras, esto indica a nuestro par cuál número de compromiso creemos que es el más reciente.
|
||||||
|
|
||||||
|
El `your_last_per_commitment_secret` es el último secreto por compromiso recibido del par remoto, lo que le dará al par remoto una idea del estado que definitivamente ha revocado.
|
||||||
|
|
||||||
|
`my_current_per_commitment_point` es el punto de compromiso de la parte local en su última transacción de compromiso firmada por el par remoto (en otras palabras, la transacción de compromiso que aún no ha sido revocada).
|
||||||
|
|
||||||
|
Hay muchas verificaciones que un nodo debe hacer al recibir un `channel_reestablish` para asegurarse de que todas las actualizaciones necesarias se retransmitan para que el canal pueda continuar funcionando con normalidad. También hay algunas verificaciones que aseguran que los nodos no sean engañados para revocar un estado que aún no debería ser revocado o engañados para transmitir un estado que _ha_ sido revocado. Si estás interesado en los detalles sobre estas verificaciones, lee [BOLT2](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md).
|
||||||
|
|
||||||
|
Ten en cuenta que cuando ocurre un restablecimiento de conexión, ambos lados deben eliminar cualquier actualización no comprometida de su área de preparación. Si volvemos a visitar la analogía de git, deberían usar git stash cuando ocurra una reconexión. Esto significa que ambos lados necesitarán retransmitir cualquier mensaje `update_*` que aún no haya sido comprometido en la transacción de compromiso del otro lado.
|
||||||
|
|||||||
Reference in New Issue
Block a user