Un usuario A abre un canal utilizando algún software, existen diferentes alternativas como por ejemplo LND que es una CLI que permite tener full control de un nodo LN o Phoenix que es mas restringido pues el nodo no es controlado por el usuario pero es mas user-friendly. Mas adelante se detallara las diferentes formas de interactuar con LN.
En el momento que un usuario A abre el canal, lo que pasa en la red principal de BTC es que se genera una dirección multi-firma 2 of 2 (quiere decir que esa dirección multi-firma requiere la firma de ambas partes para acceder a los fondos ). El fee de esa TX en la red principal la paga el usuario A por abrir el canal. También el usuario a al abrir el canal debió definir cuanto dinero tendrá inicialmente en el canal y con cual peer (otro usuario de LN) abría el canal, el peer inicia con saldo inicial de 0 en el canal. Nota: Dependiendo de la configuración del otro peer, pudo aceptar unirse al canal automáticamente cuando le llego la solicitud o puede ser que el peer necesite confirmación del usuario manualmente. Ejemplo usando LND
lncli connect PEER_URI
lncli openchannel --node_key=<ID_Peer> --local_amt=<sats>
En el momento en que la TX que confirma la dirección multi-firma on-chain es confirmada, se pueden realizar TXs entre los peers del canal múltiples veces bidireccionalmente. Existen varios métodos para meter mas dinero a el canal mas adelante se hablara de ellos. Es importante saber que hay dos formas de pasar dinero:
- Invoice: Consiste en que el usuario que quiere recibir los tokens genera un factura a nombre del otro peer. Y el otro peer paga esa factura generada.
lncli addinvoice --memo="Pago" --amt=<sats>
#Esto genera una salida von la direccion para enviarsela al otro peer
#{
# "payment_request": <direcion_invoice>
#}
#Tambien se pueden invoices sin monto fijo para que el emisor escoja el monto
lncli addinvoice --memo="Usted elige"
#El otro peer debe ejecutar algo asi para el pago
lncli payinvoice <direcion_invoice>
b. Non-Invoice: Consiste en enviar dinero sin factura previamente generada por el receptor, se envía los tokens mediante el ID publico del nodo. Pero este método requiere que el otro peer tenga configurado su nodo con keysend=true
lncli sendpayment --dest=<nodo_id_receptor> --amt=<sats> --keysend
Finalmente cuando ya los pagos necesario se ha echo lo ideal es cerrar el canal, aqui existen varios escenarios posibles, es importante saber que aunque la TX inicial era 2 of 2 multi sig, si es posible cerrar el canal si solo un usuario quiere, los escenarios son:
-
Cooperativo: Ambas partes firman el cierre del canal desde sus nodos, provocando una solo TX on-chain que hace “settle” actualizando para ambas partes el dinero resultante después de los movimientos.
lncli closechannel --channel_point=<TXID_onchain_inical>:<OutputIndex> -
Forzado: Cuando el peer no quiere cerrar el canal puedes forzarlo lo único que se debe hacer es decir la verdad a la hora de solicitar el cierre (Decir el ultimo estado del canal)
lncli closechannel --channel_point=<TXID_onchai_inicial>:<TXID_inicial> --force -
Por fraude: Cuando el nodo propio o un nodo vigilante de un canal (Los watchtowers son hechos para vigilar los canales y se pueden configurar) se da cuenta de un fraude cometido por el otro peer, lo que se procede es a publicar el estado del canal correcto y justo antes de que se cumpla el TimeLock establecido on-chain para cerrar y minar la TX de cierre del canal.
Existe un articulo que explica mejor los tipos de cierre https://mabeloza.medium.com/different-ways-to-close-a-lightening-payment-channel-a11bbe4ed486
