Orden de Intercambio de Claves de Revocación durante Transacciones Lightning

¿Cómo comparten Alice y Bob sus claves privadas efímeras simultáneamente? Si no lo hacen, digamos que Alice le envía primero a Bob su clave privada. En este punto, Bob puede transmitir su transacción de compromiso actual y la transacción de compromiso anterior (ya que todavía no ha enviado la clave privada de su transacción de compromiso anterior a Alice). Pero Alice solo puede transmitir su transacción de compromiso actual, ya que ya envió su clave privada de revocación de su transacción de compromiso anterior a Bob. Esta asimetría es un poco desconcertante.

Si la transacción de compromiso anterior favoreció a Bob, lo que le impide transmitirlo, sabiendo que Alice no puede penalizarlo.

Supongo que una respuesta para esto es que comparten sus claves privadas en función de si el valor fluye de Alice a Bob o de Bob a Alice. Es decir, si la transacción de compromiso anterior favorece a Bob, primero tiene que compartir su clave privada. O algo así.

Respuestas (2)

Alice y Bob crean conjuntamente una clave pública R para cada salida revocable (secuencia de comandos de salida RSMC).

Cada uno de ellos genera de forma privada r-1 y r-2 y deriva las claves públicas R-1 y R-2 de estos. R es la suma de R-1 y R-2. No se han intercambiado secretos, solo claves públicas. Entonces R es indiscutible para cualquiera. Sin embargo, es gastable por r = r-1 + r-2

Cuando se crea un nuevo compromiso tx, este RSMC debe revocarse. Si el nuevo compromiso de tx favorece a Bob, Alice debe compartir r-1 con Bob. Ahora Bob sabe que puede gastar esta salida revocada si Alice la transmite. Bob no necesita compartir r-2 con Alice, ya que preferiría transmitir el siguiente tx a su favor.

Las imágenes previas se utilizan para el enrutamiento (scripts de salida htlc) Consulte las diapositivas posteriores en el capítulo: https://teachbitcoin.github.io/payment_channels.html#/

Estaba usando imágenes previas como proxy para claves privadas y hashes como claves públicas. Estos no son los mismos que los que se usan para los HTLC. Edité mi pregunta para reemplazar "imagen previa" con "clave privada efímera".

No hay problema de tiempo. AFAIK, un algoritmo simplificado es básicamente justo después de que obtiene un nuevo compromiso firmado por el otro lado, puede revelar con seguridad el secreto de su compromiso anterior. El truco es que el estado del rayo es asimétrico y el compromiso 1 de Alice es diferente al compromiso 1 de Bob.

El remedio de incumplimiento es siempre "otro lado + mi secreto" (por lo que en caso de hash, puede imaginar que necesita la firma del otro lado + preimagen en caso de clave efímera, es similar al que generó el secreto aún no puede generar la clave completa ).

Digamos que Bob firma su nuevo compromiso. Ya no hay razón para que Alice use ninguno de sus antiguos compromisos (ya que Bob podría castigarla por hacerlo). Por supuesto, Bob todavía podría publicar el compromiso anterior que Alice firmó una vez (su última versión). Pero eso es un poco esquizofrénico (acaba de firmar que acepta un nuevo estado y ahora quiere huir). Si lo hace, podría haber una carrera: Alice puede publicar inmediatamente su versión y, de hecho, solo uno ganará (ya que ambos gastan el multigrado 2 de 2). Por lo tanto, las actualizaciones de estado no son atómicas, cuando se propone S, la otra parte aún puede rescatar con S-1, pero una vez que ambos se comprometen con S, no hay vuelta atrás). También si lo harías

O tal vez para aclarar, creo que en el protocolo siempre hay un momento en que Alice se ha comprometido a declarar S, pero Bob aún puede elegir si quiere cooperar y tomar S o dejar de jugar e ir con S-1. No es que S-1 sea un desastre para Alice después de todo, ambos lo acordaron previamente. Simplemente significa que para Alice, una "transacción exitosa" ocurre solo después de que Bob también señala su aceptación al publicar su antiguo secreto (no inmediatamente después de que ella firma su compromiso).