Перевод Журнал встречи исследовательской лаборатории Monero от 2020-10-21

Тема в разделе "Журналы о Monero", создана пользователем Unholy, 23 ноя 2020.

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    191
    Симпатии:
    13
    Когда: 21 октября 2020 @ 17:00 UTC
    Где: #monero-research-lab (freenode/matrix)

    Журнал встречи:

    <TheCharlatan> Похоже, что на сегодняшней встрече у нас всего несколько человек :)
    <TheCharlatan> Всем привет
    <UkoeHB_> hi
    <Isthmus> heyo
    <moneromooo> Ой. Снова забыл… Привет!
    <TheCharlatan> Сегодня без повестки дня?
    <UkoeHB
    > кто-нибудь работал над какими-либо исследовательскими проектами, которые он хотел бы обсудить
    <UkoeHB_> ?
    <TheCharlatan> В последнем хардфорке мы изменили способ обработки unlock_times на основе Unix
    <Isthmus> :- )
    <TheCharlatan> Формула была создана UkoeHB_
    <UkoeHB_> угу
    <TheCharlatan> Я опубликовал полную статью на тему того, почему это было изменено в моем блоге: https://thecharlatan.ch/Monero-Unlock-Time-Vulns/
    <UkoeHB_> о как, отлично
    <TheCharlatan> Также должно быть раскрытие информации о предстоящем hackerone, правда, кто-то из основной команды должен нажать какую-то волшебную кнопку, чтобы новость стала общедоступной
    <ArticMine> Hi
    <TheCharlatan> Как бы то ни было, в этой статье рассматривается конкретная уязвимость в протоколе, которая теперь исправлена
    <moneromooo> Я могу это сделать. Думаю, мы делаем это только для реальных эксплойтов, а не для всего, о чем поступает обратная связь
    <TheCharlatan> также я написал еще одну статью о времени блокировки, в которой кратко объясняется, почему я считаю эту область проблемной
    <TheCharlatan> статья основана на работе, которую Isthmus представлял еще в январе, мы еще обсуждали её с Сарангом в мае - https://thecharlatan.ch/Monero-Unlock-Time-Privacy/
    <TheCharlatan> Повторим еще раз: 98% текущего использования unlock_time вообще не имеет смысла
    <TheCharlatan> и это значения unlock_time, которые ниже высоты текущего блока
    <TheCharlatan> 2% значений легитимности кажутся разумно распределенными и безопасными для некоторых небольших кластеров. Да, это всё основано на работе Isthmus
    <Isthmus> гхм
    <TheCharlatan> однако текущий выбор кольца не учитывает unlock_time
    <ArticMine> еще один вопрос, который у меня возникает в отношении времени блокировки, - это возможность использования её в основных платежных каналах Monero.
    <moneromooo> Хм. Мы могли бы консенсусом запретить время разблокировки ниже высоты текущего блока. Получится что-то вроде «эта транзакция действительна только для N блоков». Похоже, это может быть весьма полезно...
    <TheCharlatan> Таким образом, две транзакции, добытые в одном блоке, но с разными значениями, будут наделены собственной, уникальной высотой
    <TheCharlatan> Да, поэтому в статье я утверждаю, что мы должны полностью избавиться от этого
    <TheCharlatan> думаю, что это будет весьма сложно преподнести для общественности
    <TheCharlatan> поэтому вместо этого я предлагаю: 1) ограничить данное поле в размерах, 2) использовать только unlock_time на основе высоты блоков, 3) переместить поле вообще за пределы выхода и 4) принимать во внимание только зрелость транзакции, а не ее высоту
    <TheCharlatan> и уже потом 5) то, что сказал moneromooo
    <Isthmus> (время разблокировки) - (высота самого младшего члена кольца) > = 10
    <moneromooo> 3 пункт не потребует выводить всё за пределы выхода, можно обойтись самой высотой
    <moneromooo> а что с 4?
    <TheCharlatan> moneromooo, я скопировал это из публикации
    <Isthmus> Хм, да, такой вывод хорош для функциональности, но сделает утечку информации более сильной, особенно если будет сохранен в открытом тексте. Тем не менее время блокировки с шифрованием для каждого выхода на данный момент единственное правильное решение (в теории достигается полная функциональность и конфиденциальность информации)
    <TheCharlatan> Предположим, что текущая высота блока составляет 400000. Согласно текущим правилам выход с unlock_time 350000, добытый на высоте блока 200000, обрабатывается так же, как выход на 200000, даже несмотря на то, что выход unlock_time стал доступен для траты только для 50000 блоков, в то время как другой на 200 000.
    <moneromooo> Вы имеете в виду, что код выбирает членов кольца, которые все еще заблокированы? Вы уверены в этом?
    <TheCharlatan> Неа
    <TheCharlatan> Это не то, что я имел в виду :)
    <TheCharlatan> В этом отношении код работает правильно
    <moneromooo> Тогда, пожалуйста, дайте более понятное определение
    <TheCharlatan> Участник кольца должен выбираться не по current_height - tx_mined_height, а по current_height - unlock_time (если timelock не равен 0)
    <Isthmus> Кстати, вот визуальное представление комментария TheCharlatan «Повторим еще раз: 98% текущего использования unlock_time вообще не имеет смысла»
    <Isthmus> https://usercontent.irccloud-cdn.com/file/h4V6caVQ/image.png
    <Isthmus> Набор данных начинается с высоты 10 ^ 6 (красная линия)
    <Isthmus> Таким образом, время разблокировки ниже этого значения бессмысленно (никогда не будет заблокировано)
    <moneromooo> Вижу
    <moneromooo> Это имеет смысл.
    <moneromooo> Вы говорите, что выход с очень большим временем разблокировки никогда не будет выбран как ложный, потому что, скорее всего, он будет использоваться только как реальная трата. Правильно ?
    <moneromooo> очень большим временем разблокировки
    <TheCharlatan> Чтобы исправить unlock_time выбор участников кольца, мы должны сначала собрать некоторые данные об использовании CHECKLOCKIMEVERIFY и CHECKSEQUENCEVERIFY в bitcoin. Просто чтобы убедиться, что мы имитируем фактическое использование unlock_time.
    <TheCharlatan> moneromooo, да
    <UkoeHB_> Думаю, что обработка заблокированного возраста транзакции как «время, через которое можно потратить», а не «время до разблокировки» - хорошая идея
    <Isthmus> Ха-ха, это даже лучше, как PDF, чем CDF... Несколько транзакций в синем круге являются единственными, которые использовали время разблокировки блока осмысленно
    <Isthmus> https://usercontent.irccloud-cdn.com/file/qa6YyXhu/image.png
    <TheCharlatan> Но, как сказано в статье, сейчас это не проблема, потому что таких транзакций около 200. Конечно, использование может измениться уже в ближайшем будущем
    <TheCharlatan> Что касается временных интервалов для выходов, я мог неправильно взвесить текущие риски. В конце концов, мы не смогли найти ни одной транзакции, которая блокировала бы XMR до скончания времён
    <Isthmus> кроме моего случая :- P
    <UkoeHB_> ArticMine: Мне тоже интересен данный аспект, но мне трудно представить, кто будет их использовать и для каких целей
    <TheCharlatan> Помимо твоего случая :p
    <ArticMine> Несколько транзакций одному поставщику
    <ArticMine> Например, кофейня или транспорт
    <ArticMine> Один открывает канал оплаты с продавцом. Затем тратит n канал на чашку кофе или поездку на автобусе / трамвае и т. д.
    <ArticMine> Для этого есть очень важные преимущества в конфиденциальности
    <TheCharlatan> В любом случае следующим шагом будет исследование использования в bitcoin временных интервалов
    <TheCharlatan> Тогда я думаю, что мне следует открыть проблему по следующим пунктам: 1), 2), 3) и 5). После этого обсуждение может быть продолжено более точечно
    <moneromooo> При использовании зашифрованного времени блокировки исключается проверка в ключе того, заблокирован ли какой-либо вход в кольце или заблокирован только реальный вход?
    <Isthmus> Это должен быть реальный выход, потому что мы не сможем узнать / расшифровать время блокировки приманок
    <moneromooo> Тогда это решит проблему, на которую указал TheCharlatan
    <TheCharlatan> да, это просто реальный вход, как и в случае с количеством
    <Isthmus> b10c написал несколько действительно отличных статей о времени блокировки в bitcoin
    <Isthmus> https://b10c.me/mempool-observations/1-locktime-stairs/
    <Isthmus> https://b10c.me/mempool-observations/2-bitmex-broadcast-13-utc/
    <moneromooo> (поскольку блокировки будут выбраны сами кольцами без проверки, и да, подумав еще немного, я мог бы это решить)
    <TheCharlatan> ^ Угу, и возможно, что меня вдохновили некоторые из этих статей :p
    <TheCharlatan> Давайте я ещё раз спрошу: что вы думаете о полном удалении времени блокировки?
    <UkoeHB_> Я не питаю к ним тёплых чувств
    <Isthmus> Я думаю, что единственные жизнеспособные варианты – это их полное удаление или шифрование
    <moneromooo> Я не был бы против их удаления, но только если они не нужны для работы в платежных каналах
    <moneromooo> (тогда нужно рассмотреть другой вариант)
    <UkoeHB_> отсутствие текущего варианта использования подразумевает, что этот функционал не будет утрачен
    <ArticMine> Как по мне, удаление - не самый лучший вариант
    <ArticMine> как раз из-за платежных каналов
    <ArticMine> в LN ужасный беспорядок, но каналы оплаты поставщиков - это тот ребенок, которого нельзя оставлять в ванной с водой
    <ArticMine> Поэтому я выбираю шифрование
    <UkoeHB_> Не могли бы вы обрисовать в общих чертах, как будет построен такой платежный канал?
    <moneromooo> Схема временных блокировок, которая нам понадобится для будущей системы платежных каналов, может быть не такой, которая у нас есть сейчас, так что это не мешает удалению
    <TheCharlatan> ^ я согласен с moneromooo
    <moneromooo> Как вариант, рассмотреть аналогичный способ только после того, как у нас появится рабочий прототип такого канала
    <moneromooo> Ну, или, как вариант, удаление, но следует держать уже что-то наготове для потенциальной замены
    <ArticMine> и только тогда мы можем отказаться от текущего способа
    <ArticMine> если нет другого ясного варианта использования
    <Isthmus> думаю, что участники данной встречи не знают других известных способов использования (на основе этого и ряда других недавних разговоров)
    <Isthmus> если мы откроем вопрос на github с перекрестной публикацией в Reddit об удалении, это должно дать нам более широкое представление от участников сообщества, где еще их можно использовать
    <ArticMine> Отличная идея
    <TheCharlatan> Isthmus, да, как вариант :)
    <moneromooo> Я слышал о следующих способах использования: «не допустить, чтобы я распродал всё в страхе», «подарок моим детям на 18-летие» и «предотвратить воровство»
    - Isthmus проясняет ситуацию: каналы оплаты - очень убедительный пример использования, и я готов повторно обсудить их реализацию, но только когда каналы оплаты будут готовы к потенциальной реализации
    -Isthmus обдумывает случаи, упомянутые mooo
    <moneromooo>
    Я также могу представить себе случай в качестве хранение денег (например, фиксированный депозит).
    <moneromooo> Хотя, наверное, это лучше сделать с помощью multisig
    <ArticMine> Министерство юстиции США «сжигает Monero» с привязкой ко времени
    <Isthmus> О да!
    <Isthmus> Но это же не единственный способ сжечь их, да?
    <Isthmus> например, отправить в генератор или отправить в pubkey 00000000000000000 и т. д.
    <moneromooo> Нет :)
    <moneromooo> Я имею в виду, может быть, нет :)
    - Isthmus хочет составить список всех способов доказуемо уничтожить Monero, но не хочет сорвать текущую встречу
    <moneromooo>
    установить для pubkey значение 0000, это не значит, что они сгорят
    <Isthmus> О, правда, еще может существовать закрытый ключ...
    <sech1> «аварии на лодке» всегда были единственным способом сжечь Monero
    <TheCharlatan> Встреча почти закончена, есть ли еще что-то для обсуждения?
    <Isthmus> Кстати, все данные о времени разблокировки попадают в базу данных @N3ptune
    <TheCharlatan> воу, спасибо, n3ptune!
    <n3ptune> спасибо!
    <n3ptune> канал #noncesense-research-lab всегда открыт для таких обсуждений
    <Isthmus> :- D
    <Isthmus> Я получил гигантский (несколько гигабайт) набор данных от n3ptune в эти выходные, чтобы закончить тесты статистики для каждого поля на предмет утечек информации https://github.com/Mitchellpkt/crypto_field_stats_tests
    <TheCharlatan> отлично :)
    <TheCharlatan> тогда увидимся на следующей неделе
    <UkoeHB_> Спасибо за встречу

    ---

    Источник: IRC #monero-research-lab

    Перевод:
    Unholy (@Unholy)
    Редактирование:
    Mr. Pickles (@v1docq47)
    Коррекция:
    Kukima (@Kukima)
     
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.