Перевод Журнал встречи исследовательской лаборатории Monero от 2019-03-18

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

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    79
    Симпатии:
    6
    Журнал встречи исследовательской лаборатории Monero
    2019-03-18

    <sarang>
    1. ПРИВЕТСТВИЯ
    <sarang> Всем привет!
    <suraeNoether> Здравствуйте, коллеги!
    <worriedrise> Hello
    <oneiric> здравствуйте мои дорогие
    <suraeNoether> worriedrise: я почти уверен, что смогу доказать, что экземпляр взаимодействия подписей без стороннего вмешательства достигается без применения особых усилий. Я потратил около часа, работая над этим доказательством в выходные.
    <sarang> мы обсудим это в ближайшее время, нужно добавить соответствующую повестку дня
    <sarang> поскольку я уверен, что это вызовет много встречных споров
    <sarang> 2. КРУГЛЫЙ СТОЛ
    <worriedrise> С нетерпением жду, чтобы посмотреть на это
    <sarang> Мы довольно много обсуждали выбор корректных выходных данных и должны подготовиться к этому, чтобы у нас были готовые рекомендации к следующему выпуску
    <sarang> Распределение выходного возраста для выборок, сделанных различными опциями, располагаются достаточно близко друг к другу при обычных условиях ветвления
    <sarang> На этом этапе я намерен настоятельно рекомендовать output-lineup метод
    <sarang> есть мысли по этому поводу?
    <suraeNoether> я предпочитаю метод очереди, пока мы не определим лучшую альтернативу или, как вариант, лучшие метрики для дальнейшего анализа
    <worriedrise> Я согласен
    <sarang> Отлично
    <moneromooo> метода линейного вывода параметров (при условии, что вы все еще используете гамму) будут сильно отличаться
    <sarang> Они используют то же самое среднее значение за прошедшие 2 дня, но с повышением среднего периода роста, определяемым цепью (или ее частью)
    <moneromooo> И это зависит от того, сколько выходов будет в блоке. Мне это кажется фундаментально неправильным решением, хотя на практике это всё работает...
    <moneromooo> чувствую, что я переборщил :p
    <sarang> я не знаю лучшего подхода, который будет отвечать всем вашим требованиям
    <sarang> дело в том, что они используют усреднение для сглаживания колебаний плотности
    <suraeNoether> какой бы метод мы ни выбрали, нам придется переоценивать параметры выбора, так как всё распределение технически не будет соответствовать гамме?
    <suraeNoether> повышенная чувствительность к плотности блокчейна на самом деле является особенностью, а не вытекающей ошибкой
    <sarang> в условиях голода усреднение будет означать, что более старые результаты предпочтительнее, чем среднее значение за прошедшие 2 дня
    <moneromooo> Я ожидал, что гамма останется
    <sarang> выбор exp-гаммы останется
    <sarang> параметры используют средний выходной возраст
    <suraeNoether> Вопрос к Сарангу о голодовке: распределение времени в реальной жизни очень чувствительно к плотности блокчейна и наоборот. Состояние голода, как описывает Саранг, это «что произойдет, если люди начнут тратить все меньше и меньше или просто увеличат интервал времени между этими тратами?», ответ на это *должен* заключаться в том, что более старые выходы появляются в кольцевых сигнатурах чаще, чем нам хотелось бы
    <sarang> Я приглашаю людей немного поиграть с алгоритмами и условиями в цепочках с помощью моего нового кода для моделирования ;)
    <suraeNoether> в ответ на точку зрения moo: мы все еще пытаемся приблизить гамма-распределение с точки зрения возраста одного из будующих выходов, которые должны быть подтверждены
    <worriedrise> Кто-нибудь смотрит на показатели того, сколько раз выход используется в кольце?
    <suraeNoether> в любом случае нам следует провести собственный анализ затрат времени и посмотреть, являются ли параметры, приведенные в статье monerolink, верными
    <sarang> Если я правильно помню, то статистическое среднее имеет тенденцию к фиксированному размеру кольца
    <sarang> если люди хотят больше аналитической деятельности, то сейчас самое время для этого, у нас как раз появилась рабочая схема и она уже готова к следующему выпуску
    <sarang> В любом случае: уже есть рабочий тестовый код Bulletproofs MPC, но гарантии безопасности сильно зависят от количества раундов и наличия / отсутствия предварительных условий
    <suraeNoether> worriedrise и sarang: среднее количество применений на ключ с фиксированным размером кольца R и N всего кольца составляет <= R . Почему? Предположим, что каждая кольцевая подпись имеет R членов и N кольцевых подписей в общей сумме. Тогда существует не менее N ключей (по одному на каждую подпись кольца), поэтому среднее количество применений на ключ - это общее количество применений (N * R), разделенное на общее количество ключей (их N и более). Как-то так
    <suraeNoether> среднее использование на ключ составляет не более R
    <suraeNoether> Вы имеете в виду «bulletproofed диапазон доказательства MPCs» правильно? не отдельно взятые произвольные bulletproofed?
    <sarang> доказательство диапазона
    <suraeNoether> весьма искусно
    <sarang> смысл данной идеи распространяется и на общие доказательства
    <worriedrise> Средний, да. Вопрос в том, будет ли присутствовать кольца в этом случае, которые переоценены или вообще не выбраны?
    <sarang> наверняка
    <worriedrise> и насколько данная проблема серьезна?
    <suraeNoether> стоп, ты вообще читал про lelantus?
    <sarang> Да, и даже играл с несколькими из их схем реализации, которые они используют
    <sarang> модификации BPs и сигма-протокол Groth
    <sarang> больше мне нечего добавить
    <sarang> Моя заявка на финансирование уже открыта и завершена на 1/3!
    <suraeNoether> Есть ли у вас мысли или идеи о том, как оценить масштаб кольца lelantus по сравнению с нашим?
    <sarang> Да, при более тщательном подборе операций и лучшем понимании того, как обрабатываются обязательства в протоколе Groth
    <sarang> это всё очень круто только на словах
    <suraeNoether> Хорошо, от меня что-то нужно добавить в этом чтении на данную тему?
    <sarang> suraeNoether: у вас есть обновления для нас?
    <sarang> нет, не сейчас
    <suraeNoether> Итак, моя работа на прошлой неделе вращалась вокруг моделирования моего нового кода, который я хочу сейчас кратко описать:
    <suraeNoether> я пытаюсь смоделировать блокчейн в «достаточно реалистичной» среде и внедрить в это моделирование какое-то ненормативное поведение, которое может заинтересовать анализатор при машинном обучении поведения
    <suraeNoether> например, если мы хотим смоделировать классический еженедельный EABE-контроль, этому будет соответствовать встраивание периодического сигнала в эту цепочку блоков
    <suraeNoether> другой пример: что делать, если конкретный производитель просто нетерпелив и тратит быстрее, чем другие? Получается, что нас ждет экспоненциальное распределение вместо гаммы
    <suraeNoether> цель моего алгоритма сопоставления состоит в том, чтобы попытаться найти этот встроенный сигнал и увидеть, насколько он применим в данной задаче как с точки зрения ложных срабатываний, так и отрицательных значений
    <suraeNoether> это можно сравнить с методами, используемыми в monerolink для тестирования подходов, с одним серьезным исключением: цель заключается в том, чтобы оценить мощность статистического теста в широком диапазоне гипотез
    <suraeNoether> я хочу поговорить с Сарангом сегодня после встречи, чтобы обсудить методы моделирования выбора выхода. В конце концов, если мы хотим в дальнейшем реализовывать одну из четырех схем, имеет смысл реализовать их предварительно в симуляции и протестировать их производительность...
    <suraeNoether> я хочу подобрать очень точный набор для проведения тестов, чтобы понять суть того, что именно мы хотим тестировать, и какую информацию нам нужно получить в итоге для принятия обоснованных решений
    <suraeNoether> с другой стороны, мы всё равно получим довольно строгий набор симуляций для воспроизведения моноблочных цепей
    <sarang> отличная работа!
    <worriedrise> Можем ли мы как-то отслеживать, какие выходы могут быть переоценены или вообще не выбраны, как я упоминал ранее
    <suraeNoether> другие мои обновления касаются вопросов безопасности dlsag и слушания об обобщениях конструкции keccak для семейства хэш-функций parazoa
    <worriedrise> Я считаю, что это может быть отличным исследованием
    <moneromooo> Я думаю, что вы можете воссоздать это с помощью инструментов в src/blockchain_utilities
    <sarang> worriedrise: как эти данные повлияют на выбор выходных данных?
    <worriedrise> Если мы сможем найти определенные результаты, которые последовательно отбираются, это, скорее всего, и будет истинный отправитель
    <worriedrise> И наоборот
    <worriedrise> это может происходить с подходом через равномерный выбор в разрезе небольших блоков, а не только для выхода на основе coinbase
    <sarang> мы видим, что результаты выбираются с неправильным взвешиванием ссылаясь на размеры блока
    <worriedrise> Выходы из Coinbase легко заметить
    <sarang> Цифры для output-lineup показывают, что это гораздо практичнее со стороны математики
    <sarang> Мой инструмент может предоставить эти самые цифры
    <suraeNoether> worriedrise, это действительно интересная эвристика. Но, я не слишком переживаю из-за этого
    <sarang> например, как часто выбираются выходные данные в блоках размера X относительно их появления в цепочке
    <worriedrise> Да, но мы должны проверить, смогут ли другие методы сделать это непреднамеренно
    <sarang> Что ты имеешь в виду? Ведь мы можем проверить эти данные для всех предложенных методов
    <sarang> просто запустите инструмент симуляции, выбрав предпочтительный метод выбора и условие для плотности цепи
    <sarang> (включая настоящую цепочку)
    <worriedrise> верю, что сможем, я просто не был уверен в этом
    <sarang> Хорошо, понял
    <sarang> Я добавил эту функциональность еще неделю назад в мой инструмент
    <sarang> Не стесняйтесь запускать его, если вы действительно хотите поэкспериментировать с полученными результатами :p
    <sarang> (ссылка в повестке дня)
    <worriedrise> Спасибо. Я его не видел
    <sarang> всегда пожалуйста
    <suraeNoether> итак, мое главное беспокойство основано на отсутствии дисперсии
    <worriedrise> Как насчет фактической цепочки блоков, у нас есть эти данные?
    <suraeNoether> если средней размер кольца < или = 11, в том случае когда у нас фиксированный размер кольца - 11, дисперсия использования на выход будет просто *огромной*
    <sarang> worriedrise: эти данные означают, что...
    <suraeNoether> эта эвристика получится ужасной
    <sarang> плотность цепи или частота выбора, основанная на плохом взвешивании данных?
    <worriedrise> Согласен. Мы можем встретить проблему с coinbase выходами.
    <worriedrise> Данные выходов используют в реальном блокчейне. И у нас уже готовы данные для сравнения
    <worriedrise> Не только для моделирования
    <sarang> У меня нет данных о том, как часто выбираются выходы из небольших блоков
    <sarang> Зато у меня есть данные о том, как действует текущая схема выбора при смоделированных выборках из фактической цепочки
    <worriedrise> Это хороший показатель. Мне интересно, что из этого получиться :)
    <suraeNoether> мы можем гоняться за эвристикой весь день, давайте двигаться дальше
    <suraeNoether> Да
    <worriedrise> Хорошо
    <suraeNoether> worriedrise: ничто не мешает вам собирать данные, тщательно изучать и делать соответствующие выводы
    <suraeNoether> как правило, я всегда выступаю за любые дополнительные данные
    <worriedrise> Я не знаю, как это сделать, но я обязательно посмотрю
    <sarang> suraeNoether: у вас есть что-нибудь еще, что можно рассмотреть на собрании?
    <suraeNoether> у меня всё, хотя я подозреваю, что черновик соответствующего документа выйдет в свет на этой неделе (хоть я и сказал ранее, что он должен появиться на прошлой)
    <sarang> ладно
    <sarang> worriedrise/randomrun еще была идея сделать MLSAG короче:
    https://github.com/monero-project/research-lab/issues/52
    <sarang> Это переросло в идею общих MLSAG, в которой применяется своего рода агрегация ключей
    <sarang> Хотите прокомментировать или обсудить?
    <worriedrise> конечно
    <worriedrise> это то, что казалось бы вполне разумным решением, но сейчас у меня нет никаких доказательств безопасности спользования этого метода
    <suraeNoether> для простых транзакций ringct в этом подходе используется агрегация ключей, как в Musig, с сигнатурами LSAG для создания RingCT. Общий размер подписей меньше, хотя время проверки занимает примерно столько же
    <worriedrise> Идея заключается в использовании линейной хешированной комбинации для агрегирования ключей
    <worriedrise> в один ключ подписи
    <worriedrise> хотя общая связанность выглядит сложнее
    <sarang> верно
    <sarang> в худшем случае потребуется новый формат образа
    <sarang> в лучшем - вторая точка образа, верно?
    <suraeNoether> доказательство неприкосновенности из-за его структуры сводится аналогичному доказательству, похожему на доказательство безопасности для бумажных подписей (https://eprint.iacr.org/2018/774.pdf)
    <suraeNoether> именно, только выглядит сложнее
    <worriedrise> Правильно, это хорошо работает только с предыдущим правилом
    <suraeNoether> *одобрительно кивает головой*
    <worriedrise> Удалось ли вам записать, как это будет работать, не меняя образ ключа?
    <sarang> вы имеете в виду общую форму?
    <sarang> к сожалению, нет
    <worriedrise> Я хотел бы пологать, что bc будет хорошо работать в купе с DLSAG.
    <sarang> Конкретная форма будет работать и с уже существующим образом ключа, но добавит вторую точку как вы уже говорили ранее
    <worriedrise> да, вижу
    <sarang> я только сегодня начал детально изучать эту схему!
    <worriedrise> Да, но только для агрегирования суммы
    <worriedrise> Мне кажется, что нам нужны разные наборы констант для раличных образов ключей
    <worriedrise> с изменением образа ключа все они объедятся воедино
    <worriedrise> проблема в том, что это не работает для DLSAG
    <sarang> правильно
    <worriedrise> Поскольку их образы ключей не определены в общей точке
    <worriedrise> я пытаюсь проследить этот путь
    <worriedrise> буду рад услышать ваши комментарии :)
    <sarang> Это хорошая идея
    <worriedrise> Спасибо!
    <sarang> Как только эта встреча закончится, я займусь ее пересмотром
    <worriedrise> Это все выглядит слишком хорошо, чтобы быть правдой. Пожалуйста, внимательно перепроверьте это еще раз
    <worriedrise> отлично
    <sarang> вопросы?
    <sarang> конечно, будем продолжать расследование!
    <suraeNoether> информация о Konferenco: мы уже начинаем покупать билеты для выступающих
    <suraeNoether> Билеты на конференцию скоро поступят в продажу (tm)
    <suraeNoether> Если кто-то хочет представить тезисы, пожалуйста, не стесняйтесь! Просто, перейдите по адресу konferenco.xyz
    <sarang> я очень воодушевлен этой новостью!
    <suraeNoether> У нас отличный список из выступающих, и нам нужно еще больше!
    <sarang> Возможно, мы сможем увидеть worriedrise/randomrun :D
    <worriedrise> Я видел, что в мае ты будешь в Нью-Йорке
    <worriedrise> на другой конференции
    <h4sh3d[m]> Каких именно выступающих вы ищете?
    <suraeNoether> я считаю, что у нас может быть кто-то из фонда по правам человека и/или активист, работающий в Венесуэле, и еще у нас есть исполнительный директор coincenter - Джерри Брито
    <suraeNoether> h4sh3d[m]: кто угодно, если его выступление хоть как-то связано с технической составляющей или технологиями Monero, или как вариант, темы о повышении конфиденциальности в целом
    <suraeNoether> у нас также есть выступающие о социальных последствиях при развитии этих технологий. В общем, только научная работа, никаких ICO, сбор интеллектуалов, только хардкор!
    <suraeNoether> если у вас есть идея для выступления, вы также можете представить её
    <suraeNoether> worriedrise: да, я буду на MCC
    <sarang> suraeNoether, ты счастливчик!
    <suraeNoether> у меня такое чувство, что на меня хотят повесить всю организацию предстоящей встречи :p
    <worriedrise> Поскольку мы сейчас говорим о других технологиях, что вы думаете об идее иметь Monero адреса в качестве адресов Bitmessage?
    <worriedrise> https://github.com/monero-project/research-lab/issues/51
    <worriedrise> Я знаю, что есть некая проблема с порядком шифрования и аутентификации
    <sarang> Кажется разумным, если использовать это правильно!
    <worriedrise> если мы это переживем...
    <worriedrise> спасибо
    <suraeNoether> я просто еще не думал об этом
    <worriedrise> Не могли бы вы объяснить, в чем именно заключается проблема
    <suraeNoether> простой способ исправить это - использование ключевых структур
    <suraeNoether> Итак
    <suraeNoether> когда вы планируете воспользоваться данными функциями, не думаю, что вы хотите проходить аутентификацию и только затем использовать шифрование
    <suraeNoether> с последующей расшифровкой и только затем проверкой, я имею в виду
    <sarang> угу
    <suraeNoether> это плохой способ, потому что вы в конечном итоге расшифровываете что-то, не зная, что именно и от кого оно поступило
    <suraeNoether> с другой стороны, если шифрованный текст подписан ключом аутентификации, то вы знаете, кто подписал его, и только затем «одобряете» шифрованный текст
    <suraeNoether> сначала вы проверяете подпись и только затем расшифровываете текст
    <nioc> не знаю, имеет ли это какое-либо отношение, но rbrunner использовал bitmessage для своей схемы multisig (MMS)
    <worriedrise> Что плохого в том, чтобы не знать, от кого пришло сообщение?
    <worriedrise> вы могли бы прочитать его позже, разве нет?
    <worriedrise> как только введете свой ключ
    <suraeNoether> вот пример
    <sarang> Вы не знаете наверняка, было ли изменено зашифрованное сообщение
    <suraeNoether> почему данная реализация опасна
    <worriedrise> Я бы знал, ведь это было подписано сопроводительным ключом
    <suraeNoether> грубый пример: «что если разработчик приложения расшифровывает зашифрованный текст и начинает выполнять его как код, параллельно проверяя, что подпись действительна? Получается, тогда вы запускаете произвольный код, не зная, что в нем». И мне кажется, что разработчик должен делать это в обратном порядке...
    <worriedrise> При первом контакте мне просто нужно взять этот ключ, и с этого момента я буду знать, подписаны ли другие данные этим ключом
    <suraeNoether> на самом деле ответ нет, шифрование/дешифрование должно идти совсем в обратном порядке
    <suraeNoether> конечно, это глупый и очень злонамеренный пример для проведения аналогии
    <suraeNoether> Есть куда более безобидные примеры, такие как упоминал Саранг, что вы не знаете, действительно ли зашифрованный текст расшифровывается до ожидаемого текста
    <suraeNoether> и, честно говоря, это основной корень проблемы
    <moneromooo> разработчик приложения не может проверить подпись и начинает выполнять зашифрованный текст как код?
    <suraeNoether> зашифрованный текст неотличим от белого шума, поэтому он вряд ли что-то сможет выполнить :D
    <sarang> это будет отличная встреча!
    <moneromooo> Зашифрованный текст находится под контролем атакующего
    <suraeNoether> https://link.springer.com/chapter/10.1007/3-540-44448-3\_41 эта статья является отличным примером
    <worriedrise> Понял, я подумаю об этом на досуге. Интересно, как эта проблема решается в Bitmessage
    <suraeNoether> moneromooo: верно, но в этот момент разработчик просто выполняет случайный код, полученный от сторонней организации
    <moneromooo> Ты тоже так думал :)
    <sarang> В интересах экономии времени давайте рассмотрим пункты, касающиеся этой встречи, а затем продолжим дальнейшее обсуждение
    <sarang> Я планирую поговорить с suraeNoether о выборе выхода, возможно, у него появятся какие-то мысли на этот счет, в дополнении я подробно рассмотрю изменения MLSAG и продолжу эксперименты с Lelantus
    <sarang> и посмотрите мой запрос на финансирование, в конце концов! :p
    <suraeNoether> moneromooo, нет, в моем примере разработчик сначала расшифровывает выполняемый код :D
    <sarang> suraeNoether: ваши планы на эту неделю?
    <suraeNoether> 1) запрос на финансирование 2) ежемесячный отчет 3) симуляции 4) безопасность dlsag 5) снижение безопасности mlsag
    <suraeNoether> Оу! И закончить прочтение материала о parazoa
    <sarang> Зашибись
    <sarang> Любые вопросы или замечания, прежде чем мы официально закроем сегодняшнюю встречу?
    <sarang> Спасибо, что присоединились к нам!
    <worriedrise> Это вам спасибо!
    <sarang> Спасибо всем за участие. Объявляю перерыв!

    Источник: Logs for the Monero Research Lab Meeting Held on 2019-03-18

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

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