diff --git a/es/ln-03.md b/es/ln-03.md new file mode 100644 index 0000000..1983bbd --- /dev/null +++ b/es/ln-03.md @@ -0,0 +1,102 @@ +- Título: Revocación en más detalle +- Resumen: En este capítulo profundizaremos en los scripts utilizados en las transacciones de compromiso y el proceso de revocación. + +--- + +Veamos nuevamente la transacción de compromiso de Alice. Esta gasta de la transacción de financiación y tiene dos salidas: una salida `to_local` y una salida `to_remote`. + +### to_remote + +La salida `to_remote` es simplemente un P2WPKH enviando a la clave pública de Bob. + +``` + +``` + +### to_local + +La salida `to_local` tiene 2 caminos de gasto. + +1. Una `` +2. Una clave pública que pertenece a Alice pero que solo se puede gastar después del número de bloques `to_self_delay`. + +``` +OP_IF + # Transacción de penalización + +OP_ELSE + `to_self_delay` + OP_CHECKSEQUENCEVERIFY + OP_DROP + +OP_ENDIF +OP_CHECKSIG +``` + +En el Capítulo 2, describimos la revocación de la siguiente manera: + +1. Alice genera una clave privada temporal `dA1` y una clave pública correspondiente `PA1` y envía la clave pública a Bob. +2. Alice luego crea una transacción de compromiso donde la salida `to_local` es inmediatamente gastable por Bob si tiene la clave privada `dA1`. +3. Si Alice y Bob actualizan el estado de su canal, entonces intercambiarán las claves privadas anteriores entre sí para invalidar el compromiso anterior, es decir, Alice enviará a Bob `dA1`. + +Esta descripción es mayormente correcta pero no completa. Si echamos un vistazo nuevamente al script `to_self_delay` anterior, parece que el camino de revocación no tiene ninguna condición que diga que solo Bob puede gastarlo. Simplemente parece que cualquiera con la clave privada correspondiente a la clave pública de revocación puede gastarlo. Dado que Alice es quien generó la clave privada temporal en primer lugar, ¿no significa eso que también puede gastarlo? + +Se utiliza un truco ingenioso para asegurarse de que solo Bob pueda gastar a través del camino de revocación. Antes de construir las transacciones de compromiso, tanto Alice como Bob derivan **dos** claves temporales y claves públicas asociadas. +1. Un par de claves `revocation_basepoint` (r -> R) +2. Un par de claves `per_commitment_point` (c -> C) + +En otras palabras, Alice tendrá: +- su par de claves `revocation_basepoint`: `rA1` -> `RA1` +- su par de claves `per_commitment_point`: `cA1` -> `CA1` + +Bob tendrá: +- su par de claves `revocation_basepoint`: `rB1` -> `RB1` +- su par de claves `per_commitment_point`: `cB1` -> `CB1` + +Ahora, cuando sea el momento de que Alice construya la transacción de compromiso, enviará a Bob su clave pública del punto de compromiso `CA1`. Bob le enviará su clave pública del punto base de revocación `RB1`. Alice ahora puede derivar la clave pública de revocación que se incluirá en la transacción de compromiso de la siguiente manera: + +``` +Rev_A2 = R_B1 * sha256( R_B1 || C_A1 ) + C_A1 * sha256( C_A1 || R_B1 ) +``` + +Ahora la salida `to_local` de Alice se ve así: + +``` +OP_IF + +OP_ELSE + `to_self_delay` + OP_CHECKSEQUENCEVERIFY + OP_DROP + +OP_ENDIF +OP_CHECKSIG +``` + +Cuando sea el momento de que Alice y Bob actualicen el estado e invaliden el estado antiguo, Alice envía a Bob su clave privada para el punto de compromiso `cA2`. Con esta clave, Bob ahora tiene tanto la clave privada del punto de compromiso de Alice `cA1` como su propia clave privada del punto base de revocación `rB1`, que corresponde a la clave pública `RB1` que le envió a Alice anteriormente cuando Alice estaba construyendo la transacción de compromiso. Así que ahora, con estas dos piezas de información, Bob puede derivar la clave privada correspondiente a la clave pública `Rev_A1` y, por lo tanto, gastar a través de la salida de revocación. Puede calcular la clave privada de la siguiente manera: + +``` +rev_A2 = r_B1 * sha256( R_B1 || C_A1 ) + c_A1 * sha256( C_A1 || R_B1 ) +``` + +Alice nunca podrá derivar esta clave privada porque no tiene y nunca tendrá la clave privada del punto base de revocación de Bob `rB1`. + +Ahora actualicemos los diagramas del Capítulo 2 para reflejar las nuevas cosas que hemos aprendido en este capítulo. + +#### Estado 1: + +![state1-updated](https://cdn.satellite.earth/9c58502b97a323b2687fced83807bacf1d9f0511188657bd4a7ee710f1ca1234.png) + +#### Estado 2: + +![state2-updated](https://cdn.satellite.earth/7c7f1fd80a40ae6a56af65b1e1226c9add0933f2276f13fe01a1f88bc6f2a9fe.png) + +### Revisión + +- **Dos** pares de claves se generan al construir las transacciones de compromiso +- Se necesitan las claves privadas de ambos pares de claves para poder gastar desde el camino de revocación + +### Referencias + +- [BOLT3: Derivación de `revocationpubkey`](https://github.com/lightning/bolts/blob/master/03-transactions.md#revocationpubkey-derivation) +- [Cosas de LN Parte 3: Revocación en más detalle](https://ellemouton.com/posts/revocation/) por nostr:nprofile1qqswrt9pnxatlplu49h6meld8svmwqt87wwvk256rqk07n6eu4qeh5gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszpfjtz