Aitorbtx on Nostr: More LN ⚡️⚡️ ...

More LN ⚡️⚡️

quoting note13rw…lzuz

En el capítulo anterior, aprendimos cómo Alice y Bob abrieron un canal, utilizando transacciones de compromiso que pueden publicarse en la blockchain en cualquier momento para recuperar sus fondos. Pero, por supuesto, las transacciones de compromiso iniciales se vuelven inválidas tan pronto como cambia el estado del canal, en otras palabras, cuando se realiza un pago y el saldo del canal se distribuye de manera diferente entre los participantes del canal. En este capítulo, comenzaremos a aprender cómo Alice y Bob pueden acordar una nueva división de fondos, es decir, cómo dividir el saldo del canal de manera diferente e invalidar las transacciones de compromiso más antiguas que tienen.

💡 Cubriremos cómo funciona esto bajo el paradigma actual de cómo se actualizan los canales, llamado "LN-Penalty", nombrado así por el mecanismo de penalización utilizado para asegurar los fondos contra adversarios maliciosos. Hay una propuesta más nueva llamada "LN-Symmetry" (anteriormente eltoo) que no requiere el mecanismo de penalización para ser segura y simplifica este proceso, pero requiere modificaciones a las reglas de consenso de Bitcoin para funcionar.

### Transacciones de compromiso asimétrico

En LN-Penalty, cada participante en un canal tiene una transacción de compromiso que representa el estado del canal. Las transacciones de compromiso que posee cada parte varían ligeramente. La razón de esto es asignar culpa. ¿Por qué es necesario asignar culpa? Porque necesitamos dejar claro qué parte transmitió su transacción de compromiso e identificar a la parte correcta para castigar si han publicado un estado inválido.

### Configuración del estado

En el último capítulo, mostramos cómo Alice y Bob intercambiaron sus claves públicas para crear sus transacciones de compromiso iniciales. Echemos un vistazo más de cerca a cómo lucen estas transacciones de compromiso. Para simplificar, supongamos que el saldo total del canal es de 10 BTC y que Alice y Bob tienen cada uno 5 BTC en sus lados del canal. Para configurar sus transacciones de compromiso iniciales, cada parte primero crea una clave privada temporal, para Alice, llamémosla `dA1`, para Bob, `dB1`. También calculan las claves públicas asociadas, `PA1` para Alice y `PB1` para Bob. En este punto, cada parte puede construir sus propias transacciones de compromiso. La de Alice se verá así:

1. Gastará la transacción de financiación.
2. Tendrá dos salidas (o más, cuando haya HTLCs. Cubriremos eso en el futuro).
3. La salida `to_remote` enviará a Bob sus 5 BTC de inmediato.
4. La salida `to_local` será más elaborada. Aquí pueden suceder dos cosas. Alice puede enviarse a sí misma los 5 BTC después de un OP_CSV `to_self_delay` o puede ser gastada por Bob si puede demostrar que tiene la clave privada temporal de Alice `dA1`.

De manera similar, Bob también puede construir la transacción de compromiso de Alice y proporcionarle su firma para ello. Alice puede firmar esta transacción válida ella misma en cualquier momento y transmitirla a la red, dándole la seguridad que necesita para recuperar sus fondos en caso de que Bob desaparezca.


En este punto, cualquiera de las partes puede transmitir sus transacciones de compromiso para cerrar el canal. Supongamos que Alice transmite la suya. Bob recibirá sus 5 BTC de inmediato. Alice tendrá que esperar el número de bloques `to_self_delay` antes de poder usar sus 5 BTC. Sin embargo, no necesita preocuparse por que Bob gaste su salida porque sabe que nunca compartió su clave privada con él.

### Invalidando el estado antiguo

Ahora Alice quiere enviarle a Bob 1 BTC usando su canal. Así que, al igual que en el paso anterior, cada parte genera nuevas claves privadas (`dA2` para Alice, `dB2` para Bob), calcula las claves públicas asociadas (`PA2` para Alice, `PB2` para Bob) y comparte las claves públicas entre sí. Y nuevamente, ambos crean transacciones de compromiso para reflejar el nuevo estado del canal (Alice ahora tiene 4 BTC ya que transfirió 1 BTC a Bob; Bob ahora tiene 6 BTC).

El problema, sin embargo, es que Alice todavía tiene su transacción de compromiso del paso anterior, donde tenía 5 BTC, lo cual es más rentable para ella. Para mostrarle a Bob que está invalidando el estado antiguo y comprometiéndose al nuevo estado, necesita enviarle a Bob su clave privada temporal inicial (`dA1`). Ahora, dado que Bob tiene esta clave, puede gastar la salida `to_self` de Alice si ella alguna vez publica un estado antiguo e inválido, antes de que ella pueda reclamarlo (recuerda que la salida `to_local` tiene un `to_self_delay`).

Bob también le envía a Alice su antigua clave (`dB1`) para invalidar su estado antiguo. No tiene razón para no hacer esto ya que su nuevo estado es más rentable para él.


¡Eso es todo! Ahora hemos aprendido cómo Alice y Bob pueden transaccionar de manera segura estableciendo nuevos estados e invalidando estados antiguos.

### Revisión

- Para **actualizar el estado**, cada participante del canal genera nuevos pares de claves y se envían mutuamente la clave pública.
- Para **invalidar el estado**, por ejemplo, cuando se realiza una transacción, cada participante del canal actualiza el estado y se envían mutuamente la clave privada del estado anterior.

### Referencias

- [BOLT3](https://github.com/lightning/bolts/blob/master/03-transactions.md)
- [LN Things Part 2: Updating State](https://ellemouton.com/posts/updating-state/) por elle (nprofile…fjtz)
- [eltoo](https://bitcoinops.org/en/topics/eltoo/)