Canales de pago con firmas dinámicas

Hablando de canales de pago de financiación única, la idea es bastante simple: Alice pone 10 btc en una firma múltiple firmada con Bob, y luego cada uno actualiza el estado en consecuencia para enviarse dinero entre sí.

ingrese la descripción de la imagen aquí

Ahora, imagina que una tercera persona se une a la imagen, digamos Carol. Y Alice quiere enviarle algo de btc. ¿Se puede actualizar el estado del canal con la clave pública de otra persona?

ingrese la descripción de la imagen aquí

Me gustaría saber si algo así es posible. De lo contrario, me gustaría saber por qué esto no es posible (seguro que me falta algo sobre cómo funcionan los canales de pago y me gustaría entender qué). ¿Quizás usando Channel Factory algo como esto es posible?

La idea principal aquí es que alguien puede apartar fondos para una nueva persona, sin tener que crear un nuevo canal, pero usando los fondos en un canal ya creado.

Tenga en cuenta que esto no tiene nada que ver con el enrutamiento. Es simplemente usar fondos dentro de un canal para otra persona en lugar de solo las 2 partes del canal.

EDITAR

Tal vez exista la posibilidad de crear "canales fuera de la cadena" (¿quizás se trata de fábricas de canales?) que están de alguna manera conectados a la rama principal, utilizando otros participantes. Quiero enfatizar que, en este ejemplo, Carol nunca ha participado en un canal dentro de la cadena; es una participante nueva involucrada en el uso de "canales fuera de la cadena":

ingrese la descripción de la imagen aquí

Respuestas (2)

Es posible que Alice y Bob acuerden entre ellos pagarle a Carol ya cualquier número de otros destinatarios (sujeto a límites en el tamaño de la transacción). Sin embargo, no es posible que Carol y otros destinatarios adicionales reciban esos pagos con la misma seguridad sin confianza disponible para Alice y Bob a través de la construcción del canal de pago.

Alice y Bob abren un canal al comprometer fondos en una dirección multisig que requiere las firmas de ambos para gastar. Para Alice, esto garantiza que se requiere su consentimiento para que cualquier transacción que gaste los fondos sea válida. Bob recibe la misma garantía de que se requiere su consentimiento.

La innovación de los canales de pago bidireccionales (incluidos, entre otros, los utilizados por Lightning Network) es que los destinatarios pueden revocar cada pago en el canal, lo que permite que un pago posterior ocupe su lugar.

El gravamen (script de canje) que protege un pago revocable es mayor que un gravamen de Bitcoin normal, por lo que el final más deseable para un canal de pago es un cierre mutuo donde el último pago revocable se revoca y se convierte en un pago no revocable que parece un gasto multigrado normal de Bitcoin 2 de 2.

La única forma conocida de que funcionen los pagos revocables es que cada parte tenga una lista completa de todos los pagos realizados y (si se ha revocado) qué datos son necesarios para revocarlo. Esto es lo que impide que Carol tenga seguridad total en el canal de pago.

Alice y Bob pueden consentir mutuamente en pagarle a Carol y pueden informarle a Carol sobre este pago. Si la transacción que contiene ese pago se transmite, Carol obtiene su dinero. Pero debido a que la dirección multisig en la que se depositaron inicialmente los fondos solo requiere el consentimiento mutuo de Alice y Bob para crear otros pagos, pueden crear otros pagos en secreto de Carol.

Si uno de los pagos secretos creados entre Alice y Bob se transmite, Carol no tiene los datos necesarios para demostrar en la cadena de bloques que se realizó de manera fraudulenta. Alice y Bob pueden, por consentimiento mutuo, robar los fondos de Carol.

Una forma más conceptual de verlo es visualizar la cadena de bloques como un ancla de confianza para los canales de pago. Necesita tener cierto grado de control sobre ese ancla para poder confiar en el canal resultante. Alice y Bob tienen eso porque se requiere su consentimiento para usar el ancla; Carol no tiene ningún control sobre el ancla, por lo que no puede confiar en ella.

Digamos que el estado Alice:3, Bob:7 (estado anterior) se publica en la cadena. Según tengo entendido, tanto Alice como Bob tienen algunos "datos" para sobrescribir esencialmente dicho estado anterior, con el estado correcto más nuevo (Alice:4, Bob:6). ¿No se pueden compartir estos "datos" con Carol, de modo que si Alice y Bob se confabulan y publican en cadena un estado anterior, Carol puede sobrescribirlo?
@LucaMatteis cuando Alice y Bob revocan un estado temprano, cada uno comparte datos de revocación entre sí que les permite a cualquiera de ellos apoderarse de los fondos del otro si el otro publica un estado anterior. No hay forma de agregar a Carol de manera retroactiva a estos estados anteriores, y se pueden agregar estados posteriores después de que Carol se convierta en un destinatario designado para el cual Carol tampoco es un destinatario y, por lo tanto, no tiene ningún recurso. Esto significa que Carol no tiene ninguna seguridad contra la colusión entre Alice y Bob, aparte del cierre inmediato del canal de pago cuando Carol recibe los fondos por primera vez.

El principal problema que veo con esto es una mayor complejidad y una posible colusión entre 2 de las 3 partes. Si Carol ahora debe firmar actualizaciones, ¿qué hace Alice si Carol no responde? ¿Transmitir su transacción de rescate a pesar de que Bob es un participante receptivo? ¿Tiene transacciones de rescate por mala conducta tanto de Bob como de Carol? ¿Qué pasa si Bob y Carol están coludidos? Ahora necesita rescates para cada uno de ellos, además de los combinados. ¿Qué pasa si agregas a Dave a la mezcla?

Todos estos escenarios deberían cubrirse para mantener el sistema sin confianza. A medida que aumenta la complejidad de un solo canal, escala aún más los posibles problemas. Probablemente sea mejor mantener los canales en sí mismos lo más simples posible e intentar escalar a través del enrutamiento.

Canales de pago con firmas dinámicas
RespuestasAquíPolítica de privacidad1y, 0v