Почему скрытый номер обязательства необходим в молниеносных обязательствах TX?

Скрытый номер фиксации для каждой транзакции фиксации — это младшие 48 битов:

SHA256(payment_basepoint from open_channel || payment_basepoint from accept_channel)

Он закодирован в полях времени блокировки и последовательности (по 24 бита каждое) транзакции фиксации. Я не понимаю, зачем это нужно, в BOLT rfc написано:

Это скрывает количество обязательств, сделанных в канале в случае одностороннего закрытия, но все же предоставляет полезный индекс для обоих узлов (которые знают payment_basepoints), чтобы быстро найти отмененную транзакцию обязательства.

Почему TXID обязательства TX не подходит в качестве ключа поискового индекса?

Ответы (1)

Глядя на код c-lightning, я нахожу этот вызов :

    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);

в частности следующую строку:

commitment_number ^ channel->commitment_number_obscurer

Отслеживая commitment_numberпеременную, я подсказываю, что это действительно целое число. Если вы видите, как часто в коде приходится проверять, что две транзакции фиксации непосредственно следуют друг за другом, имеет смысл использовать незатененное целое число вместо txid. Рассмотрим, например, этот блок кода :

    /* 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++;

Позже это скрывается, поскольку информация о том, сколько существовало tx-фиксаций, не должна быть общедоступной. Насколько я понимаю, он скрыт с помощью OTP через XOR. OTP - это тот, который вы упомянули выше. Идея состоит в том, чтобы иметь целое число, которое можно использовать, но скрыть его при отправке в блокчейн. Однако я не нашел в коде места, где скрытое значение берется и обрабатывается до чистого значения.

Надеюсь, это поможет (:

Спасибо за поиск кода Рене. Скрытый номер фиксации закодирован в транзакции фиксации для узла, так что во время одностороннего закрытия он может быстро найти, какое состояние было передано контрагентом (насколько я понимаю), и отреагировать соответствующим образом. Почему нельзя использовать txid в качестве ключа поиска (txid->commitment nr)?
по причинам, которые я упомянул, представляется более удобным иметь в памяти порядковый номер для транзакций фиксации. Если вы знаете, что это транзакция обязательства номер 100, вы, вероятно, можете получить ключ отзыва / сценарий выкупа с помощью деривации ключа вместо сохранения всего этого состояния для каждого txid.
Я имею в виду не память, а то, почему эти 48 бит помогают облегчить поиск во время закрытия канала. Я предполагаю, что один ключ представляет собой ключ поиска в постоянном хранилище для извлечения данных (сигналов), которые необходимы для ответа на отмененное закрытие этого состояния. Если бы этот ключ хэш-карты был просто незатененным целым числом, как вы предлагаете, как можно было бы эффективно вывести это целое число из скрытого номера обязательства? (хеш-дайджест). Это должен быть эффективный способ для однорангового узла немедленно определить состояние широковещательной передачи.
Для поиска в магазине (в реализации) было бы более разумно индексировать по скрытому номеру фиксации, чем по целому состоянию, поскольку это то, что транслируется. Я готов ошибаться, но подозреваю, что это как-то связано с 48 битами (скрытый ключ) и 256 битами (TXID)?