¿Cómo anunciaría el protocolo de chismes los canales de una fábrica de canales?

Estaba escuchando SLP59 con Christian Decker . Hablaron principalmente de fábricas de canales. Si bien la construcción de canales multipartidistas y sistemas de orden superior (subcanales) que se derivan de ellos parece clara y se describe en este documento, me pregunto cómo se tendría que adaptar el protocolo de chismes para que las personas puedan anunciar dichos canales.

Generalmente, existe la necesidad de apuntar a un tx de financiación de un canal de pago para evitar el envío de channel announcmentmensajes no deseados y para autenticar los canales. Sin embargo, con las fábricas de canales, solo hay un gran tx de financiación para el canal multipartidista. Los subcanales están fuera de la cadena.

¿Cómo sería una solución para el protocolo de chismes?

No sé lo suficiente sobre esto para dar una respuesta adecuada. Parece que la semántica de short_channel_idnecesitaría cambiar, o que los canales tendrían que ser privados y podría short_channel_idser un valor inventado pasado en una factura de BOLT#11. Pregunta relacionada a la que anteriormente me diste una respuesta.
Otra posibilidad que podría ser posible sin cambios en el chisme, es que la short_channel_idtransacción del anzuelo podría usarse en la factura BOLT#11, y el beneficiario podría pasarla payment_hasha su par de canal de forma privada, de modo que cuando el par reciba una entrada update_add_htlccon el gancho short_channel_idy eso payment_hash, saben a qué miembro de la fábrica de canales está destinado. Para los pagos salientes, los participantes tendrían una channel_idpara la transacción que no depende de que esté en una ubicación específica en la cadena de bloques.
Otra (quizás mala) idea es usar la short_channel_idtransacción gancho, y cuando el participante de la fábrica recibe un update_add_htlc, lo transmite a todos los miembros de la fábrica. Todos los miembros menos uno deben devolver un update_fail_malformed_htlc, y un miembro debe devolver un update_fulfull_htlco update_fail_htlc. El nodo podría recopilar estas respuestas y descubrir a quién estaba destinado.

Respuestas (1)

Casi todo seguiría igual. Si observa los mensajes relevantes channel_announcementy channel_updatetenemos los siguientes formatos:

channel_announcement

  1. tipo: 256 ( channel_announcement)
  2. datos:
    • [ 64: node_signature_1]
    • [ 64: node_signature_2]
    • [ 64: bitcoin_signature_1]
    • [ 64: bitcoin_signature_2]
    • [ 2: len]
    • [ len: features]
    • [ 32: chain_hash]
    • [ 8: short_channel_id]
    • [ 33: node_id_1]
    • [ 33: node_id_2]
    • [ 33: bitcoin_key_1]
    • [ 33: bitcoin_key_2]

channel_update

  1. tipo: 258 ( channel_update)
  2. datos:
    • [ 64: signature]
    • [ 32: chain_hash]
    • [ 8: short_channel_id]
    • [ 4: timestamp]
    • [ 1: message_flags]
    • [ 1: channel_flags]
    • [ 2: cltv_expiry_delta]
    • [ 8: htlc_minimum_msat]
    • [ 4: fee_base_msat]
    • [ 4: fee_proportional_millionths]
    • [ 8: htlc_maximum_msat] (opción_canal_htlc_max)

Si observa esto, verá que channel_announcementincluye una lista ordenada lexicográficamente de firmas de nodos y bitcoins y sus claves públicas correspondientes. Es trivial extenderlo a un número arbitrario de participantes al hacer que esta lista tenga una longitud variable.

En particular, el short_channel_idalambique se refiere a la salida única con la que se abrió el contrato fuera de la cadena, que también permanecería igual.

channel_updatePuede parecer un poco más complicado ya que ahora hay n*(n-1)direcciones posibles (pares de emisor-receptor) este contrato se puede atravesar, mientras que en el canal simple de 2 participantes solo tenemos 2 direcciones. Sin embargo, el concepto de dirección se puede ampliar fácilmente para clasificar lexicográficamente todos los pares emisor-receptor y utilizar el índice para identificar el par.

Es probable que sea necesario modificar algunos de los formatos de los mensajes (clave pública de longitud variable y listas de firmas) y hacer explícitos algunos campos (índice de clasificación para el par emisor-receptor), pero el concepto general sigue siendo el mismo.

la capacidad del canal no forma parte de ninguno de los 2 mensajes. Creo que actualmente conocemos la capacidad del canal inicial del tx de financiación en cadena. pero al crear subcanales, debemos tener en cuenta las capacidades y asegurarnos de que la capacidad total no supere la capacidad del tx de financiación.
Eso no es diferente de la situación actual: sabe que ambos extremos de un canal LN tienen un saldo acumulativo de xsi la salida es para xsatoshis, pero no sabe el saldo actual real. Con los canales multipartidistas, en lugar de dividir el saldo acumulado en dos, lo divides npara nlos participantes, todo lo demás permanece igual :-)
Creo que estaba hablando de algo diferente. Cuando se utiliza un canal multipartidista para una fábrica de canales, el subcanal derivado de él debe anunciarse a través del protocolo de chismes (BOLT 07), este canal debe tener una capacidad. como mencionó en analogía con nuestro sistema actual, esto correspondería al saldo y sería privado. pero un canal que viene de una fábrica no debería ser así. en particular, si los miembros del partido se retiran y los subcanales se vuelven visibles en la cadena de bloques a medida que se transmite el tx de liquidación (como en el caso de eltoo) del canal multipartidista
En caso de que todos los miembros sigan respondiendo, las asignaciones de canales dentro de la fábrica realmente no son importantes, ya que puede reemplazarlos por capricho (en realidad, no es necesario crear canales en primer lugar, solo mueva los saldos entre los participantes). Cuando los participantes dejan de responder, te conectas a la cadena y, de repente, tienes una financiación en la cadena para un canal Lightning normal :-)
¿Cómo anunciaría el protocolo de chismes los canales de una fábrica de canales?
RespuestasAquíPolítica de privacidad1y, 0v