Почему конфиденциальность при использовании служб сторожевой башни повышается из-за непредсказуемых идентификаторов транзакций обязательств?

В open channelсообщении в BOLT 02 написано следующее заявление о различных базовых точках.

Различные поля _basepoint используются для получения уникальных ключей, как описано в BOLT #3 для каждой транзакции фиксации. Изменение этих ключей гарантирует, что идентификатор транзакции каждой транзакции фиксации будет непредсказуемым для внешнего наблюдателя, даже если видна одна транзакция фиксации; это свойство очень полезно для сохранения конфиденциальности при передаче штрафных транзакций третьим сторонам.

Меня интересует последняя фраза. Почему это особенно помогает с конфиденциальностью таких сервисов? Я думал, что улучшу конфиденциальность, используя несколько сторонних сервисов просмотра, а не только один. В случае, если я использую один, они все равно будут знать всю историю состояния моего канала.

Одна вещь, о которой я догадался, заключалась в том, что, зная одну транзакцию фиксации, я мог рассчитать все txid для всех возможных состояний канала. Но я думал, что подписи зависят от количества выходов, а txid зависит от подписей.

У меня неправильное представление или причина повышенной конфиденциальности другая, которую я не вижу?

Ответы (1)

На самом деле, BOLT был разработан с очень сильными свойствами конфиденциальности в отношении сторожевых вышек. Вы можете передать все свои первые половины идентификатора tx id одной сторожевой башне, и она все равно ничего не узнает о вторых половинах, других txs или что-либо еще о состоянии канала (или какой канал он вообще смотрит), до тех пор, пока поскольку полная передача обязательства не отображается в блокчейне. Как только это произойдет, он все равно не сможет узнать ничего, кроме этого единственного состояния обязательства. Вот для чего это сделано и это весьма примечательно ИМХО.

извините, я не понимаю. Я вижу, что могу передать часть идентификатора tx обязательства службе сторожевой башни, и они смогут идентифицировать tx, если он появится в блокчейне. Однако, как только это произойдет, сторожевая башня должна потребовать средства от моего имени, выпустив мое средство защиты от взлома tx. Если у него нет этого (который раскрывал бы состояние канала), служба просмотра кажется мне довольно бесполезной. Думаю, я что-то упускаю. Было бы здорово, если бы вы могли уточнить
Сообщение о лекарстве, которое вы отправляете в сторожевую башню, зашифровано второй половиной идентификатора tx обязательства, поэтому сторожевая башня не может прочитать его, если сначала не встретит транзакцию обязательства в блокчейне.
Хорошо, это была недостающая часть головоломки, и это действительно очень интересный подход. Чего я до сих пор не понимаю, так это того, почему ваш подход не сработал бы, если бы все транзакции с обязательствами использовали одну и ту же базовую точку для закрытого ключа. Я имею в виду, что идентификаторы tx все равно будут отличаться из-за разных сумм, или я что-то упустил?
Все они используют одни и те же базовые точки, но разные per_commitment_points. Обоснование далее описано здесь: github.com/lightningnetwork/lightning-rfc/blob/master/… Общая идея заключается в том, что сторожевым башням или кому-либо еще не следует узнавать о канале больше, чем это абсолютно необходимо, и в то же время в идеале хранить как как можно меньше данных. Вторая часть пока не так хорошо работает на практике. Eltoo улучшит это.
Пожалуйста, не забудьте включить последующие ответы в свой ответ! :) Комментарии должны быть временными.
Действительно? Как? Попытаться интегрировать все туда и обратно в искусственный ответ? Удалить комментарии? Фальсифицировать историю? Звучит тяжело и опасно для меня.