En este capítulo, revisaremos el proceso de apertura y anuncio de un canal pre-taproot, añadiendo algunos detalles técnicos. En los próximos capítulos, aplicaremos el mismo tratamiento a la operación normal y cierre de un canal. Estos capítulos nos darán la base sobre la cual construir a medida que aprendamos sobre canales taproot en el futuro. Asumiremos que ya estás familiarizado con la estructura de una transacción de compromiso y entiendes por qué son asimétricas. Si necesitas un recordatorio, ¡por favor revisa los capítulos anteriores! ### Contenidos - [El objetivo final](#el-objetivo-final) - [Apertura del canal](#apertura-del-canal) - [El mensaje open_channel](#el-mensaje-open_channel) - [El mensaje accept_channel](#el-mensaje-accept_channel) - [El mensaje funding_created](#el-mensaje-funding_created) - [El mensaje funding_signed](#el-mensaje-funding_signed) - [El mensaje channel_ready](#el-mensaje-channel_ready) - [Anunciando el canal](#anunciando-el-canal) - [Verificando el canal](#verificando-el-canal) ### El objetivo final Establezcamos qué es lo que nuestros viejos amigos, Alice y Bob, están tratando de lograr. Alice y Bob son nodos de la Red Lightning. Alice es conocida en la red por su *ID de nodo*, o la clave pública utilizada para identificar su nodo, esta es `alice_node_id`. Del mismo modo, el ID de nodo de Bob es `bob_node_id`. Sus dos principales objetivos son: 1. Quieren abrir un canal entre ellos de manera sin confianza. 2. Quieren poder publicitar su nuevo canal para que el resto de la red pueda usarlo para el enrutamiento. ### Apertura del Canal Primero lo primero: a lo largo de este capítulo, utilizaremos diagramas y colores para ilustrar el proceso de apertura del canal. Aquí está la guía de código de colores: - Un fondo *blanco* significa que el campo de la transacción aún no se conoce. - Un campo *coloreado* significa que el valor del campo es conocido. - *Verde* indica las claves públicas de Alice. - *Azul* indica las claves públicas de Bob. Un canal se abre una vez que ambas partes tienen la capacidad de firmar completamente sus respectivas transacciones de compromiso y una vez que la transacción de financiación está en la cadena. Tres transacciones están en juego para la apertura de un canal. La primera es la transacción de financiación, que necesita ser confirmada en la cadena. Las otras dos son las transacciones de compromiso mantenidas por Alice y Bob que describen el estado inicial del canal. En este momento, aún no sabemos nada sobre los parámetros del canal, por lo que todos los campos tienen un fondo blanco:    #### El mensaje open_channel El primer paso del proceso es que Alice decida que quiere abrir un canal a Bob, es decir, ella se convertirá en la financiadora del canal (y Bob será el financiado). Supongamos que Alice decide que quiere abrir un canal de 1 BTC a Bob y darle inmediatamente a Bob la mitad de la capacidad del canal (0.5 BTC). Alice ahora preparará un mensaje `open_channel` que enviará a Bob. Como referencia, en la tabla a continuación puedes ver los parámetros relevantes. | Nombre del Campo | Descripción del Campo | |___|___| | chain_hash | La blockchain en la que abrir el canal. | | temp_chan_ID | Identificar el canal antes de que se conozca el outpoint de la transacción de financiación. | | funding_sats | La cantidad de salida de la transacción de financiación, es decir, la capacidad del canal. | | push_msat | La cantidad que el financiador envía incondicionalmente al financiado en el momento de la apertura. | | dust_limit_sats | Umbral por debajo del cual no se deben generar salidas. | | feerate_per_kw | La tasa de tarifa inicial a utilizar para las transacciones de compromiso. Puede actualizarse más tarde a través de `update_fee`. | | revocation_basepoint | Utilizado, junto con el first_per_commitment_point del nodo remoto, para derivar la primera clave pública de revocación que se utilizará en la transacción de compromiso de Bob. | | payment_basepoint | Utilizado, junto con el first_per_commitment_point, para derivar la primera clave pública de pago - la clave pública to_remote en la transacción de compromiso de Bob. | | delayed_payment_basepoint | Utilizado, junto con el first_per_commitment_point, para derivar la primera clave pública retrasada - la clave pública local_delayed en la transacción de compromiso de Alice. | | first_per_commitment_point | El primer punto a utilizar junto con los puntos base anteriores (excluyendo el revocation_basepoint) para derivar las claves públicas correspondientes. | | channel_flags | La única bandera actualmente definida es la bandera "announce_channel" que determina si el canal debe ser anunciado a la red o no. | | tlv: channel_type | Para que se pueda determinar la estructura de la transacción de compromiso. | Ahora llenemos los valores de Alice para estos campos:  Alice envía este mensaje a Bob. Dado que Alice ha decidido el tipo de canal que quiere abrir (legado en lugar de anclajes, taproot, etc.) así como la capacidad del canal, ya puede armar una parte bastante grande de la transacción de financiación:  Alice ya puede elegir algunos de sus UTXOs para ser entradas a la transacción de financiación, ya que conoce la capacidad del canal que quiere abrir. Sin embargo, aún no sabe qué clave pública Bob querría usar para el canal, por lo que no puede finalizar la salida de financiación del canal todavía, y por lo tanto no puede producir firmas para las entradas. Como Alice ha decidido el tipo de canal (y por lo tanto la estructura de la transacción de compromiso), también puede comenzar a ensamblar las piezas de las transacciones de compromiso. Si asumimos que Bob está feliz con esta propuesta de apertura de canal de Alice, él también puede comenzar a armar las piezas utilizando la información en el mensaje `open_channel`. Recuerda que ambos pares necesitan construir sus propias transacciones de compromiso y ambos necesitarán firmar las transacciones de su par. Veamos qué piezas ya pueden llenar:  La transacción de compromiso de Alice tiene la estructura de una transacción de canal por defecto, no anclada. Todas sus claves públicas han sido llenadas (`alice_local_delayed_pk_1` se deriva utilizando su `delayed_payment_basepoint` y su `first_commitment_point`). Dado que aún no ha recibido ningún mensaje de Bob, no puede llenar ninguna de sus claves públicas. Y dado que la transacción de financiación aún está incompleta, tampoco puede conocer el TXID para apuntar la entrada de esta transacción de compromiso. La transacción de compromiso de Bob se ve un poco más completa:  Al igual que Alice, él tampoco puede llenar aún el TXID de la transacción de financiación, pero puede llenar algunas otras cosas: - Los valores `alice_pubkey_1`, `alice_to_self_delay`, `push_amt` y `local_amt` se toman tal cual del mensaje `open_channel`. - `alice_payment_key_1` se deriva utilizando el `payment_basepoint` de Alice y el `first_commitment_point`. - `revoke_pubkey_1b` se deriva utilizando el `revocation_basepoint` de Alice y el `first_per_commitment point` de Bob (Alice no puede derivar este punto aún ya que no ha recibido el `first_per_commitment_point` de Bob). ¡Genial! Es hora de que Bob indique a Alice su aceptación de la propuesta enviando el siguiente mensaje: `accept_channel`. #### El mensaje accept_channel El mensaje comparte muchos de los campos del `open_channel`. Aquí está el mensaje que Bob preparará.  Cuando Alice recibe este mensaje de Bob, ahora puede completar la salida de la transacción de financiación y puede crear las firmas para las entradas. Dado que todo está ahora lleno, el TXID de la transacción de financiación también es conocido.  Alice ahora puede llenar más de su propia transacción de compromiso: - ahora puede usar los valores enviados por Bob para llenar `bob_pubkey_1`, `bob_payment_key_1`, `bob_to_self_delay` y `revoke_pubkey_1a` - dado que el TXID para la transacción de financiación ahora es conocido, también puede completar la entrada Ahora sabe todo lo que necesita saber para firmar esta transacción ella misma _pero_ recuerda que aún le falta la firma de Bob para esta transacción.  La transacción de compromiso de Bob sigue siendo la misma que antes, ya que no aprendió nueva información después de enviar el mensaje `accept_channel`. Ahora que Alice conoce el TXID de la transacción de financiación, también puede completar su vista de la transacción de compromiso de Bob y así puede producir su firma para la transacción de él. Ella enviará el siguiente mensaje a Bob: `funding_created`. #### El mensaje funding_created Alice ahora utilizará el mensaje `funding_created` para decirle a Bob el TXID y el índice de la transacción de financiación junto con su firma para la transacción de compromiso de Bob. Ten en cuenta que Bob aún no podrá transmitir su transacción de compromiso porque la transacción de financiación no ha sido transmitida aún.  Una vez que Bob reciba el mensaje `funding_created`, podrá completar el resto de su transacción de compromiso:  #### El mensaje funding_signed Alice no transmitirá la transacción de financiación hasta que tenga una firma válida de Bob para su transacción de compromiso, entra `funding_signed`:  Ten en cuenta que este es el primer mensaje que utiliza el ID de canal real en lugar del temporal. Esta fue la última pieza del rompecabezas para Alice. Ahora tiene toda la información que necesita para poder firmar su transacción de compromiso si alguna vez es necesario.  #### El mensaje channel_ready Alice ahora puede transmitir de manera segura la transacción de financiación. Tanto Alice como Bob estarán atentos a la cadena para la confirmación de la transacción de financiación. Una vez que haya alcanzado la `minimum_depth` especificada por Bob en su mensaje `accept_channel`, ambos lados intercambiarán el mensaje `channel_ready`. Este mensaje cumple dos propósitos. Primero, sirve como una señal para el par para indicar que el canal está listo para usar (y pueden comenzar el proceso de anuncio del canal si abrieron un canal público y anunciado). En segundo lugar, también le dice al par que envíe su `second_per_commitment_point` que deben usar en su segunda transacción de compromiso.  ### Anunciando el canal Esta parte es bastante fácil. Alice y Bob solo necesitan construir un mensaje, `channel_announcement`, juntos y una vez que esté completo, pueden transmitirlo a la red. Otros nodos utilizarán este mensaje para probar algunas cosas: - Que la transacción de financiación del canal es en realidad un UTXO existente y no gastado con un número aceptable de confirmaciones. - Que la salida de la transacción de financiación en realidad se parece a una transacción de financiación de canal Lightning. - Que el canal es en realidad propiedad de las claves que Alice y Bob dicen que utilizaron para construir el canal. - Que Alice y Bob están de acuerdo en el mensaje que se está transmitiendo. Una versión parcial del mensaje `channel_announcement` se ve así:  `h` es el hash de todos los datos que serán cubiertos por las firmas. Para completar este mensaje, tanto Alice como Bob necesitan calcular una firma sobre `h` utilizando las claves privadas asociadas con sus IDs de nodo y las claves públicas que utilizaron en la transacción de financiación. Luego ambos intercambian el mensaje `announcement_signatures` para comunicarse estas firmas.  Ahora ambos nodos pueden armar el mensaje completo `channel_announcement`:  ### Verificando el canal Supongamos que Charlie es un nodo que recibió este mensaje. Vamos a repasar los pasos que seguirá para verificar el nuevo canal que Alice y Bob han anunciado: 1. Primero, Charlie utilizará el `short_channel_id` incluido en el mensaje para asegurarse de que la transacción de financiación realmente existe en la cadena, que tiene un número suficiente de confirmaciones y que de hecho está no gastada. 2. Luego, Charlie verificará que la salida no gastada realmente se parece a un canal Lightning propiedad de `alice_pubkey_1` y `bob_pubkey_1`. Hará esto utilizando las claves públicas publicitadas para reconstruir el P2WSH y asegurarse de que es el mismo que se encuentra en la cadena. 3. Ahora, Charlie querrá verificar que los nodos que poseen las claves públicas utilizadas en la salida de financiación corresponden de hecho a los nodos que poseen las claves públicas de ID de nodo. Puede hacer esto verificando las firmas `alice_pubkey_1_sig` y `bob_pubkey_1_sig`. Si estas firmas son válidas, entonces está claro que los propietarios de `alice_pubkey_1` y `bob_pubkey_1` están de acuerdo en ser asociados con `alice_node_ID` y `bob_node_ID` ya que el mensaje firmado contiene estas claves públicas. 4. Finalmente, Charlie también querrá asegurarse de que los propietarios de las claves públicas de ID de nodo están de acuerdo en ser asociados con el nuevo canal. Puede hacer esto verificando las firmas `alice_node_ID_sig` y `bob_node_ID_sig`. Si estas firmas son válidas, entonces está claro que los propietarios de `alice_node_ID` y `bob_node_ID` están de acuerdo en ser asociados con `alice_pubkey_1` y `bob_pubkey_1` ya que el mensaje firmado contiene estas claves públicas. ¡Alice y Bob han terminado! Su canal ahora está abierto y otros nodos en la red, como Charlie, utilizarán felizmente el nuevo canal. ### Referencias - [BOLT2 Protocolo de pares](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - [Apertura y anuncio de un canal pre-taproot](https://ellemouton.com/posts/open_channel_pre_taproot/) por nostr:nprofile1qqswrt9pnxatlplu49h6meld8svmwqt87wwvk256rqk07n6eu4qeh5gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszpfjtz