Bitcoin Txoko
103 lines
5.0 KiB
Markdown
103 lines
5.0 KiB
Markdown
- 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.
|
|
|
|
```
|
|
<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
|