¿Por qué es necesario el número de compromiso oculto en los TX de compromiso relámpago?

El número de compromiso oscurecido para cada transacción de compromiso son los 48 bits inferiores de:

SHA256(payment_basepoint from open_channel || payment_basepoint from accept_channel)

Está codificado en los campos de secuencia y tiempo de bloqueo (24 bits cada uno) de la transacción de compromiso. No entiendo por qué es necesario, el BOLT rfc dice:

Esto oscurece la cantidad de compromisos realizados en el canal en el caso de un cierre unilateral, pero aún proporciona un índice útil para ambos nodos (que conocen los puntos base de pago) para encontrar rápidamente una transacción de compromiso revocado.

¿Por qué el TXID del compromiso TX no es suficiente como clave de índice de búsqueda?

Respuestas (1)

Mirando el código c-lightning encuentro esta llamada :

    txs[0] = commit_tx(ctx, &channel->funding_txid,
               channel->funding_txout,
               channel->funding_msat / 1000,
               channel->funder,
               channel->config[!side].to_self_delay,
               &keyset,
               channel->view[side].feerate_per_kw,
               channel->config[side].dust_limit_satoshis,
               channel->view[side].owed_msat[side],
               channel->view[side].owed_msat[!side],
               committed,
               htlcmap,
               commitment_number ^ channel->commitment_number_obscurer,
               side);

en particular la siguiente línea:

commitment_number ^ channel->commitment_number_obscurer

Al rastrear la commitment_numbervariable, esto me sugiere que en realidad es un número entero. Si ve con qué frecuencia en el código tiene que validarse que dos transacciones de compromiso se sucedan directamente, tiene sentido tener un número entero no oscurecido en lugar de un txid. Considere, por ejemplo, este bloque de código :

    /* FIXME: Document this requirement in BOLT 2! */
    /* We can't send two commits in a row. */
    if (peer->revocations_received != peer->next_index[REMOTE] - 1) {
        assert(peer->revocations_received
               == peer->next_index[REMOTE] - 2);
        peer->commit_timer_attempts++;

Se oscurece más adelante ya que la información de cuántos compromisos tx existían no debería ser pública. Según tengo entendido, está oscurecido con una OTP a través de XOR. La OTP es la que mencionaste anteriormente. La idea es tener un número entero que se pueda usar pero que se oculte cuando se envía a la cadena de bloques. Sin embargo, no encontré una posición en el código donde el valor oscurecido se tome y se procese a un valor limpio.

Espero que eso ayude (:

Gracias por la búsqueda de código Rene. El número de compromiso oscurecido está codificado en la transacción de compromiso del nodo, de modo que durante un cierre unilateral pueda buscar rápidamente qué estado transmitió la contraparte (según tengo entendido) y responder en consecuencia. ¿Por qué no se puede usar el txid como clave de búsqueda (txid->commitment nr)?
por las razones que he mencionado parece más conveniente tener un número de índice para las transacciones de compromiso en memoria. Si sabe que es la Transacción de compromiso número 100, probablemente pueda derivar la clave de revocación/script de canje a través de la derivación de clave en lugar de almacenar todo ese estado para cada txid.
No me refiero a la memoria, sino a por qué estos 48 bits ayudan a facilitar una búsqueda durante el cierre del canal. Supongo que una sola clave representa una clave de búsqueda en el almacenamiento persistente para obtener datos (firmas) que se requieren para responder a un cierre revocado de ese estado. Si esta clave de mapa hash fuera solo el número entero no oscurecido, como sugiere, ¿cómo podría inferirse eficientemente este número entero del número de compromiso oscurecido? (hash-digest). Debe ser una forma eficiente para que un par infiera inmediatamente el estado de transmisión.
Para la búsqueda en la tienda (en la implementación), tendría más sentido indexar por número de compromiso oculto que por entero de estado, ya que eso es lo que se transmite. Estoy abierto a estar equivocado, pero sospecho que tiene algo que ver con 48 bits (clave oculta) frente a 256 bits (TXID)?
¿Por qué es necesario el número de compromiso oculto en los TX de compromiso relámpago?
RespuestasAquíPolítica de privacidad1y, 0v