¿Sería posible enviar dinero a través de Lightning Network a una dirección fuera de línea?

Tengo entendido que la especificación actual de Lightning Network requiere una dirección que reciba dinero para firmar cosas con su clave privada, lo que requiere que el propietario de esa clave esté en línea. ¿Existe alguna técnica que permita a un tercero aceptar dinero en su nombre sin confiar en ese tercero?

Puedo imaginar una situación en la que el remitente delega el envío a un tercero, al igual que la publicación de transacciones antitrampas se puede delegar a un tercero que observa la cadena de bloques. Por ejemplo, tal vez el remitente proporcione a un tercero las transacciones adecuadas necesarias para autorizar el envío de lightning btc al destino una vez que el destino esté en línea. Aunque no sé si esto es posible con la funcionalidad actual de Bitcoin. es posible?

Respuestas (1)

Esto suena como una billetera web, donde las claves se administran por ti y simplemente interactúas a través de un sitio web. Tendría que confiar en el tercero, pero como hemos visto en la red principal, esto es aceptable para una gran cantidad de personas.

Al igual que con la red Bitcoin existente, debe ejecutar las cosas usted mismo para no confiar, pero hay opciones más convenientes si está dispuesto a confiar (y pagar tarifas) a otras partes.

Ok, pero, como dijiste, eso es solo una billetera web. La dirección de la billetera web todavía está en línea porque es operada por los servidores de la billetera web. Así que realmente no responde a la pregunta.
Lo siento, pensé que la pregunta era sobre si un tercero podría reemplazarlo en Lightning Network (que, sí, es una billetera web). Si está preguntando específicamente acerca de proporcionar transacciones prefabricadas al servicio web, no, eso no funcionará. Las transacciones que componen los contratos inteligentes deben producirse a medida que el dinero fluye a través del canal. Si supieras todo lo que sucederá en el canal con anticipación, no necesitarías el canal.
Bueno, la vinculación de transacciones descrita aquí rusty.ozlabs.org/?p=462 parece que todo lo que se necesita para crear la transacción es un hash del destino. Si el destino crea previamente un montón de hashes y se los entrega a su proveedor de canal, parece que el remitente puede crear las transacciones necesarias para transferir dinero a su proveedor, que puede esperar a que el destino se conecte y complete la cadena. La única restricción sería que si el destino no se conecta dentro del tiempo del contrato de bloqueo de tiempo con hash (~ 1 día), la transacción debería cancelarse.
Creo que el problema es que crea transacciones además de los UTXO más recientes en los contratos inteligentes. Está asumiendo que el canal no se está utilizando mientras una de las partes está fuera, y no creo que sea una suposición justa. Si se usa el canal (como una ruta para pagos no relacionados), entonces hay nuevos UTXO a los que hacer referencia y las transacciones almacenadas no tienen valor.
Hmm, no pensé que una dirección que estaba fuera de línea podría usarse como un salto de ruta... ¿el enrutamiento a través de una dirección fuera de línea no es un problema similar al envío a una dirección fuera de línea?
Si no va a enrutar otras transacciones, es posible que desee considerar si vale la pena tener un nodo en Lightning Network. Cada canal eventualmente requerirá 2 transacciones en cadena y, por lo tanto, dos tarifas. Si solo desea darle una dirección para que una sola persona le pague mientras está desconectado, probablemente no debería usar lightning. Incluso si necesita múltiples transacciones (todas conocidas con anticipación), todo lo que necesita es un canal de pago unidireccional.
La mayoría de las personas no necesitarán enrutar transacciones. Como dijiste, cada canal requiere 2 transacciones en cadena, por lo tanto, los usuarios normales querrán minimizarlas. La situación más probable es una disposición de concentrador y radios, donde la mayoría de los usuarios se conectan a uno o dos concentradores, y esos concentradores hacen todo el trabajo pesado en lo que respecta al enrutamiento. Independientemente, no veo cómo su respuesta tiene algo que ver con las direcciones que se usan como saltos de enrutador cuando están fuera de línea.
Tengo entendido que los canales solo se pueden usar cuando ambas partes están en línea. Por lo tanto, mi suposición de que el canal no se usa cuando una de las partes está fuera sería completamente correcta.