HTLC y transacciones de compromiso

¿Por qué las transacciones de compromiso no pueden ser simplemente HTLC en lugar de contratos revocables al tener la segunda mitad de la clave privada revocable? Quiero decir, ¿por qué molestarse en crear una clave pública revocable a partir de dos mitades de las claves privadas de Alice y Bob y al invalidar una transacción compartiendo la otra mitad, cuando tanto Alice como Bob podrían crear dos transacciones, ambas revocables con dos claves separadas conocidas solo por Alice? y Bob, que luego se canjearía para invalidar transacciones antiguas?

Editar: mi comprensión actual de cómo funcionan las transacciones de compromiso

Tanto Alice (A) como Bob (B) crean transacciones opuestas:

TX_A:

5 BTC -> B
if RK_A
  5 BTC -> B
else if 1k blocks later
  5 BTC -> A
(Signed by B)

TX_B:

5 BTC -> A
if RK_B
  5 BTC -> A
else if 1k blocks later
  5 BTC -> B
(Signed by A)

Donde RK_A es la clave de revocación de A. Ahora bien, si TX_A y TX_B son válidos, ni B tiene RK_B ni A tiene RK_B. Por lo tanto, ambos pueden firmar sus respectivas transacciones y "salir" de este canal después de 1k bloques sin riesgo de perder todos sus BTC.

Sin embargo, una vez que tanto A como B deciden olvidarse del saldo anterior, tienen que invalidar TX_A y TX_B. Lo hacen cuando A revela RK_A a B y B revela RK_B a A. De esta manera, si, por ejemplo, A firma TX_A y lo transmite a la red de Bitcoin, B puede proporcionar RK_A y reclamar 5 BTC adicionales.

Ahora, el proceso de creación y revelación de RK_X parece estar involucrado y, por lo tanto, mi pregunta es, ¿por qué no simplemente tener algunos números aleatorios en lugar de RK_A y RK_B que solo A y B conocen y que luego se intercambian cuando TX_A y TX_B necesitan ser invalidado?

Hola, ven a nuestra comunidad y es genial que estés interesado en Lightning Network. Me encantaría responder a su pregunta y entiendo la esencia, pero realmente no entiendo qué es exactamente lo que está pidiendo. ¿Sería tan amable de elaborar o editar su pregunta o tal vez especificar un poco más el mecanismo que cree que podría usarse para invalidar el estado del canal anterior?
Hola @RenePickhardt, he agregado información adicional, espero que esto ayude :)
Gracias por ampliar tu pregunta. De hecho, pensé que te referías a algo diferente. Sin embargo, de nuevo estoy confundido. ¿Cuál es la diferencia entre una clave de revocación privada y un número aleatorio? En ambos casos, los datos deben transportarse BOLT 2 vital en el mensaje revoke_and_ack

Respuestas (1)

¿Por qué no simplemente tener algunos números aleatorios en lugar de RK_A y RK_B que solo A y B conocen y que luego se intercambian cuando TX_A y TX_B deben invalidarse?

Supongamos que la transacción está estructurada en la que A y B generan secretos aleatorios. Por cada revocación que suceda, los nodos deberán almacenar el secreto para cada compromiso que se firme. Cada HTLC ofertado y redimido, implica 2 revocaciones de compromiso. Entonces, un nodo tendrá que almacenar una enorme base de datos de todos los secretos, ordenándolos en la forma en que se firma la transacción. Con el método actual, tenemos un punto base a partir del cual se genera el secreto para que no tengamos que almacenar cada clave individualmente, sino derivarla en función de las revocation_basepointy per_commitment_secretque se generan de forma determinista y se guardan de forma compacta .

¿Por qué las transacciones de compromiso no pueden ser simplemente HTLC en lugar de contratos revocables al tener la segunda mitad de la clave privada revocable?

Todas las transacciones relámpago se construyen de manera que sean completamente válidas en la cadena principal de Bitcoin. Si simplemente crea transacciones en las que las salidas se desbloquean con una imagen previa, entonces se abre a los ataques de intermediarios. En el caso de una liquidación en cadena, cuando se transmite la transacción que contiene esta entrada que se gasta solo con una imagen previa, entonces el nodo de retransmisión o el que extrae, conocerá esta imagen previa y simplemente cambiará las salidas de la transacción a los que se pagan a sí mismos. Esa es la razón por la que usamos la verificación de firma, de modo que la persona que gasta la entrada firme toda la transacción para que nada se pueda modificar.

Si se pregunta cómo se ofrecen los HTLC para pagos relámpago, no es tan simple como una simple clave privada. A continuación, se muestra un script que muestra el compromiso que la otra parte firma con una transacción que mantengo cuando ofrezco el HTLC.

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

Si tenemos todas las salidas construidas de esta manera, entonces el tamaño de la transacción será innecesariamente grande y también tendrá una gestión de claves ineficiente como mencioné en la sección anterior.

Pero si entiendo correctamente, revocationprivkeytambién tendría que almacenarse para cada transacción, ya que per_commitment_secrettendría que regenerarse para cada nueva transacción.
@spacemonkey no necesariamente; las claves se pueden calcular a partir de una representación compacta. Para la generación de claves, solo genera una semilla, y luego usa un índice para voltear bits y codificar el resultado. Para el almacenamiento, solo se necesita guardar un secreto para cada prefijo único; en efecto, se cuenta el número de ceros finales, y esto determina en qué parte de la matriz de almacenamiento se almacena el secreto. Puede leer más almacenamiento de claves en BOLT #3 aquí: github.com/lightningnetwork/lightning-rfc/blob/master/…
HTLC y transacciones de compromiso
RespuestasAquíPolítica de privacidad1y, 0v