-
2024-11-22 14:07:44Veamos 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. ``` <remotepubkey> ``` ### to_local La salida `to_local` tiene 2 caminos de gasto. 1. Una `<revocationpubkey>` 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 <revocationpubkey> OP_ELSE `to_self_delay` OP_CHECKSEQUENCEVERIFY OP_DROP <local_delayedpubkey> 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_A1 = 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 <Rev_A1> OP_ELSE `to_self_delay` OP_CHECKSEQUENCEVERIFY OP_DROP <alice_delayedpubkey> 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 `cA1`. 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_A1 = 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:  #### Estado 2:  ### 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) - [LN Things Part 3: Revocation in more detail](https://ellemouton.com/posts/revocation/) por nostr:nprofile1qqswrt9pnxatlplu49h6meld8svmwqt87wwvk256rqk07n6eu4qeh5gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszpfjtz