-
@ Bitcoin Txoko
2024-12-31 14:52:21En el capítulo anterior tuvimos una visión simplificada de los HTLC, con suerte eso te dio una comprensión del mecanismo general y los incentivos en juego. En este capítulo profundizaremos en cómo se ven los HTLC en más detalle y cómo encajan en las transacciones de compromiso.
De nostr:naddr1qqxnzdenxgerzve5x5enyv3sqyg8wumn8ghj7mn0wd68ytnhd9hx2q3qtx0k0a7lw62vvqax6p3ku90tccgdka7ul4radews2wrdsg0m865sxpqqqp65wc4f8xj aprendimos sobre las transacciones de compromiso. Aquí hay un breve resumen:
Las transacciones de compromiso son asimétricas: Alice y Bob (participantes de un canal) cada uno tiene sus propias transacciones de compromiso. La transacción de compromiso que cada participante tiene se ve ligeramente diferente a la de su par en que cualquier salida que vaya al nodo local debe estar gravada por un bloqueo de tiempo relativo de
to_self_delay. Esto es para darle a la otra parte la oportunidad de gastar a lo largo del camino de revocación de la salida si lo necesita.Con esto en mente, continuemos con el ejemplo del capítulo anterior donde Alice está enviando 2 BTC a un destinatario usando su canal con Bob como el primer salto en la ruta. Recuerda que a Alice se le ha dado un hash
Hal que necesita pagar. En este ejemplo, Alice es la ofertante de HTLC y Bob es el receptor de HTLC.Alice - Ofertante de HTLC
Enfoquémonos en cómo Alice construirá su transacción de compromiso para incluir ahora el HTLC. La transacción de compromiso tendrá tres salidas:
- Una salida de 5 BTC a Bob, gastable inmediatamente
- Una salida de 3 BTC con dos posibles caminos de gasto:
- Una gastable por Alice después de un
to_self_delay - Una gastable inmediatamente por Bob si tiene la clave de revocación requerida (ver nostr:naddr1qqxnzdenxgerzve5x5enyv3sqyg8wumn8ghj7mn0wd68ytnhd9hx2q3qtx0k0a7lw62vvqax6p3ku90tccgdka7ul4radews2wrdsg0m865sxpqqqp65wc4f8xj y nostr:naddr1qqxnzdenxgerzvek8qenyvekqyxhwumn8ghj7mn0wvhxcmmvqgs9n8m87l0hd9xxqwndqcmwzh4uvyxmwlw0637kuhg98pkcy8ana2grqsqqqa282rd072 si necesitas un recordatorio)
- Una gastable por Alice después de un
- Una salida de 2 BTC con... hmm, pensemos juntos sobre lo que necesita suceder aquí.
Esta salida es donde debe suceder la magia del HTLC. Necesitamos los siguientes caminos de gasto en esta salida: - Debe ser gastable por Bob si tiene la preimagen de
H; este es el camino bloqueado por hash - O gastable por Alice después decltv_expiry- O gastable por Bob inmediatamente si tiene la clave de revocaciónPERO recuerda que las salidas de Alice hacia sí misma siempre deben tener un bloqueo de tiempo relativo de
to_self_delayincluso después decltv_expiry. Así que actualicemos los caminos de gasto con esta información: - Debe ser gastable por Bob si tiene la preimagen deH; este es el camino bloqueado por hash - O gastable por Alice después decltv_expiryY después del retraso relativoto_self_delay- O gastable por Bob inmediatamente si tiene la clave de revocaciónTodavía hay un problema: gravar la salida a Alice con ambos bloqueos de tiempo podría, en el peor de los casos, extender el tiempo de espera del HTLC por
to_self_delay. Es decir, Bob podría tener un bloque adicional deto_self_delaypara barrer la salida bloqueada por hash a pesar de que el HTLC esté técnicamente expirado. Así que en lugar de bloquear esta salida con ambas condiciones de bloqueo de tiempo, se bloquea solo por elcltv_expiry. Luego, en lugar de enviar fondos a Alice directamente, los fondos se envían a una transacción de tiempo de espera de HTLC separada (firmada por Alice y Bob) y esta transacción de tiempo de espera separada impone elto_self_delay. Esto permite a Alice bloquear el hecho de que el HTLC ha expirado y evita que Bob reclame la salida bloqueada por hash, todo mientras asegura que Alice solo pueda obtener sus fondos después deto_self_delayy, por lo tanto, aún permite a Bob gastar desde el camino de revocación (de la transacción de tiempo de espera de HTLC) si es necesario.La forma final de los caminos de gasto de la salida de HTLC de la transacción de compromiso se ve como sigue: - Un camino de gasto a Bob si tiene la preimagen de
H(camino bloqueado por hash) - Un camino de gasto a Bob si tiene la clave de revocación - Un camino de gasto a una transacción de tiempo de espera de HTLC de segunda etapaLa transacción de tiempo de espera de HTLC se construye así:
- La transacción en sí está bloqueada por tiempo con
nLocktimeestablecido encltv_expiry. Esto significa que el camino de gasto en la transacción de compromiso original que envía a esta transacción de tiempo de espera de HTLC está efectivamente retrasado porcltv_expiry - La transacción tiene una salida con dos posibles caminos de gasto:
- Uno a Alice después de
to_self_delay - Uno a Bob si puede proporcionar la clave de revocación
El script para la salida de HTLC de la transacción de compromiso de Alice (la ofertante de HTLC) se ve así:
```
A nodo remoto con clave de revocación
OP_DUP OP_HASH160
OP_SWAP OP_SIZE 32 OP_EQUAL OP_NOTIF # A nodo local a través de la transacción de tiempo de espera de HTLC (bloqueada por tiempo). OP_DROP 2 OP_SWAP 2 OP_CHECKMULTISIG OP_ELSE # A nodo remoto con preimagen. OP_HASH160 El script de salida de la transacción de tiempo de espera de HTLC se ve así:
OP_IF # Transacción de penalización <revocationpubkey> OP_ELSE `to_self_delay` OP_CHECKSEQUENCEVERIFY OP_DROP <local_delayedpubkey> OP_ENDIF OP_CHECKSIGBob - Receptor de HTLC
Ahora enfoquémonos en cómo Bob (el receptor de HTLC) construirá su transacción de compromiso para incluir el HTLC. La transacción de compromiso tendrá tres salidas: - Una salida de 3 BTC a Alice gastable inmediatamente - Una salida de 5 BTC con dos posibles caminos de gasto: 1. Una gastable por Bob después de un
to_self_delay2. Una gastable inmediatamente por Alice si tiene la clave de revocación requerida - Una salida de 2 BTC que es un poco más complicada; profundicemos.
Pensemos en qué caminos de gasto debería tener esta salida: - Un camino de gasto que Bob puede reclamar si tiene la preimagen de
H(camino bloqueado por hash) pero dado que es una salida hacia sí mismo, necesita tener unto_self_delay- Un camino de gasto que Alice puede gastar inmediatamente si tiene la clave de revocación necesaria - Un camino de gasto que Alice puede gastar después dectlv_expiry(camino bloqueado por tiempo)Nuevamente, tener dos bloqueos de tiempo diferentes en el mismo script plantea un problema: si Bob conoce la preimagen pero tiene que esperar
to_self_delaybloques para gastar desde el camino bloqueado por hash, entonces hay una posibilidad de que esteto_self_delaysea más largo que elcltv_expiryque Alice debe esperar para reclamar el camino bloqueado por tiempo. Esto significaría que Alice podría potencialmente gastar a lo largo del camino bloqueado por tiempo a pesar de que Bob tiene la preimagen. Por lo tanto, Bob necesita una forma de bloquear el hecho de que se usará el camino bloqueado por hash mientras aún retrasa su redención de los fondos porto_self_delay. Así que se utiliza una transacción de éxito de HTLC separada para esto, permitiendo a Bob gastar desde el camino bloqueado por hash a esta transacción de éxito de HTLC, que luego impondrá por separado la condición deto_self_delay.La forma final de los caminos de gasto de la salida de HTLC de la transacción de compromiso se ve como sigue: - Un camino de gasto a Alice si tiene la clave de revocación (camino de revocación) - Un camino de gasto a Alice después de
cltv_expiry(camino bloqueado por tiempo) - Un camino de gasto a la transacción de éxito de HTLC si Bob puede revelar la preimagen deH(camino bloqueado por hash)La transacción de éxito de HTLC se ve así: - La transacción no está bloqueada por tiempo (a diferencia del caso de Alice) - La transacción tiene una salida con dos posibles caminos de gasto: 1. Uno a Bob después de
to_self_delay2. Uno a Alice si puede proporcionar la clave de revocación
El script para la salida de HTLC de la transacción de compromiso de Bob (el receptor de HTLC) se ve así:
```
A nodo remoto con clave de revocación
OP_DUP OP_HASH160
OP_SWAP OP_SIZE 32 OP_EQUAL OP_IF # A nodo local a través de la transacción de éxito de HTLC. OP_HASH160 2 OP_CHECKMULTISIG OP_ELSE # A nodo remoto después del tiempo de espera. OP_DROP OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG OP_ENDIF OP_ENDIF ``` Puedes ver en el script anterior que el primer camino es el camino de revocación, el segundo es el camino a la transacción de éxito de HTLC (y también es el camino bloqueado por hash) y el tercero es el camino de gasto bloqueado por tiempo.
El script de salida de la transacción de éxito de HTLC se ve así:
OP_IF # Transacción de penalización <revocationpubkey> OP_ELSE `to_self_delay` OP_CHECKSEQUENCEVERIFY OP_DROP <local_delayedpubkey> OP_ENDIF OP_CHECKSIGLa imagen completa
Revisión
- La salida de HTLC en una transacción de compromiso difiere dependiendo de si el constructor de la transacción es el ofertante de HTLC o el receptor de HTLC
- La salida de HTLC necesita estar gravada por dos bloqueos de tiempo, pero tener ambos bloqueos de tiempo en el script puede causar problemas
- La solución es barrer la salida a una segunda etapa de transacción de tiempo de espera de HTLC o transacción de éxito de HTLC e imponer el
to_self_delayen esta transacción
Referencias
- BOLT3: Transacciones
- Cosas de LN Parte 5: Profundización en HTLC por nostr:nprofile1qqswrt9pnxatlplu49h6meld8svmwqt87wwvk256rqk07n6eu4qeh5gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszpfjtz