Requisito de doble firma de transacción de reparación de incumplimiento

En el Lightning Network Paper ( https://lightning.network/lightning-network-paper.pdf ), las transacciones de Breach Remedy parecen requerir firmas de ambos miembros del canal. Infiero esto de esta descripción en el documento:

Cuando se acuerde un nuevo par de Transacciones de Compromiso (C2a/C2b), ambas partes firmarán e intercambiarán firmas para la nueva Transacción de Compromiso, luego invalidarán la Transacción de Compromiso anterior. Esta invalidación ocurre cuando ambas partes firman una Transacción de reparación de incumplimiento (BR1), que reemplaza a la Transacción de entrega revocable (RD1). Cada parte entrega a la otra una revocación a medio firmar (BR1) de su propia Entrega Revocable (RD1), que es un gasto de la Transacción de Compromiso. La transacción Breach Remedy enviará todas las monedas a la contraparte dentro del saldo actual del canal.

(Énfasis mío).

Sin embargo, no entiendo por qué esto es un requisito. Me parece que es posible diseñar el Contrato de Vencimiento de Secuencia Revocable de tal manera que solo se requiera la firma del emisor de la Transacción de Reparación de Incumplimiento, no adicionalmente la de la parte redimiente.

¿Es correcta mi noción? ¿Si no, porque no?

Respuestas (1)

Si asumimos que "medio firmado" implica que ambas partes firman la transacción, entonces la transacción de Breach Remedy también incluiría el gasto de la otra salida en la transacción de compromiso que luego también requeriría la firma de Bob. Esto lógicamente tiene sentido (pero no se establece explícitamente en el documento) ya que reduciría las tarifas de transacción y consolidaría las UTXO. Pero sí, tiene razón, no es necesario que ambas partes firmen la transacción de Breach Remedy.

El diseño del protocolo actual en realidad elimina por completo el Remedio de incumplimiento y las Transacciones de entrega revocable mediante el uso de scripts especiales que hacen cumplir las reglas que esas transacciones harían cumplir al existir. Este script usa un tiempo de bloqueo relativo (con OP_CHECKSEQUENCEVERIFY) para hacer cumplir la regla de entrega revocable. También utiliza una clave de revocación que puede generar la parte que realiza la revocación después de que se haya revocado una transacción de compromiso, eliminando así la transacción de Breach Remedy. La construcción del script de salida se describe aquí .

Supongo que en su escenario, Bob es el que transmite un antiguo Compromiso TX. Por favor, infórmeme si esta suposición es incorrecta. Esto significa que parte del dinero del canal de pago va a Alice de todos modos. Algunos van a Bob. Cuando Alice transmite su Breach Remedy TX, solo tiene que dirigirle los fondos que están en camino a Bob. Esto requiere la firma de Bob. Que el Breach Remedy TX que Alice recibió de Bob esté medio firmado implica que también requiere la firma de Alice antes de estar listo para ser incluido en un bloque. ¿Por qué se requiere la firma de Alice para redirigir los fondos de Bob?
No, en este escenario es Alice quien transmite la transacción de compromiso anterior y Bob quien transmite la transacción de Breach Remedy. La transacción Breach Remedy necesita que tanto Alice como Bob firmen porque gasta de ambas salidas (tanto las salidas de Alice como las de Bob) en la transacción de compromiso, aunque no es necesario.
¿Sabes dónde dice eso en el Lightning Network Paper? ¿Tienes alguna razón por la que fue elegido de esta manera?
No es parte del papel en absoluto. Una razón para realizar la transacción como tal sería consolidar UTXO y reducir las tarifas de transacción.
Lo siento, pero no veo dónde dice el periódico que un Breach Remedy TX gasta la salida del Delivery TX de la parte que no traiciona. De hecho, las figuras 8, 9 y 14 no se parecen en nada. ¿Puedes indicar dónde dice eso?
¿Leíste mi comentario o mi respuesta revisada? "** No es parte del papel**"
Entendí su comentario como si estuviera diciendo que el documento no establece una razón para la consolidación, pero sí establece que la consolidación ocurre. Las figuras 8, 9 y 14 parecen contradecir esto, ya que no muestran una flecha que apunte desde el TX de Entrega de la parte que no traiciona hasta su TX de Remedio de Incumplimiento.
Si lo entiendo correctamente, está diciendo que si la parte que toma la represalia no quiere preocuparse por la consolidación de sus UTXO, no es necesario que se requiera una firma de la parte que toma la represalia. Después de pensar un poco, publicar una pregunta diferente que también respondiste , y pensar un poco más, llegué a la conclusión de que no entiendo cómo funcionaría eso.
Si la parte traidora Bob es capaz de crear BR1b en la figura 8 con solo su firma requerida, puede crear un segundo Breach Remedy TX BR1bEvil que envía el dinero a una de sus propias direcciones. Por supuesto, él todavía le da BR1b a Alice, pero cuando traiciona, puede transmitir BR1bEvil antes de que Alice transmita BR1b, lo que efectivamente finaliza el canal de pago de inmediato con un pago justo. Esto contradice la declaración del periódico de que el cierre unilateral de un canal de pago conlleva un período de espera. Por lo tanto, creo que algo está mal y que realmente se requieren 2 firmas.
Puede ser que esto no se haya considerado en el documento inicial y, por lo tanto, sea una falla en el diseño original (IIRC, en realidad, hay algunas fallas). Sin embargo, el diseño actual establecido por la especificación de LN resuelve este problema en el que la clave necesaria para crear la transacción de reparación de incumplimiento solo la conoce la parte que la crearía.
Requisito de doble firma de transacción de reparación de incumplimiento
RespuestasAquíPolítica de privacidad1y, 0v