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

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

  1. Unholy

    Unholy Well-Known Monerano

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

    Повестка дня:
    1. Приветствия
    2. Круглый стол
    3. Вопросы
    4. Ключевые моменты
    <sarang> Всем привет
    <sarang> да начнётся встреча!
    <sgp_> привет
    <sarang> во-первых, ПРИВЕТСТВИЯ
    <sgp_> черт, я тебя опередил :)
    <sarang> следом КРУГЛЫЙ СТОЛ
    <suraeNoether> howdy :D
    <suraeNoether> Саранг, будете первым?
    <sarang> Я перенес исправление эксплойта RCT3 из агрегированной системы проверки с несколькими входами в систему проверки с одним входом, обновил код, чтобы отразить изменения, и проверил соответствующие доказательства безопасности для этой конструкции
    <sarang> также я изучил некоторые способы поддержки мультисигнатур в рассматриваемых сублинейных протоколах, к сожалению, это не принесло видимых результатов
    <sarang> на данный момент все конструкции RCT3, Omniring и Triptych требуют инверсии секретного ключа, что несовместимо с методом линейной комбинации, используемым для обработки мультисигнатур
    <sarang> данный метод можно использовать только в ключе RCT3 и Triptych на этапе генерации образа ключа, но на данном этапе это всё еще не работает так, как должно работать
    <suraeNoether> я читал о каких-то схемах подписи, которые не используют хеш-функции, а прибегают к инверсии ключа... когда позже я рассмотрю ваши материалы о triptych, я перепроверю, есть ли что-то, что ускользает от вашего чуткого глаза
    <sarang> Спасибо
    <suraeNoether> я бы предположил, что это что-то не очевидно, потому что вы и randomrun очень внимательны в этих моментах
    <sarang> Несколько вещей всё еще в стадии разработки
    <sarang> независимо от мультиподписей я работаю над препринтом Triptych для библиотеки IACR
    <sarang> Это будет доказуемо-безопасная версия с одним подписантом или версия с несколькими подписантами, если сработает аргумент обоснованности
    <sarang> Он будет включать в себя ту же конструкцию образов ключей, которая находится в основе PRF, RCT3 и Omniring, поскольку она намного эффективнее, чем схема, основанная на хешировании публичных ключей.
    <sarang> Теперь я передаю эстафету вам, Шурэ
    <suraeNoether> круто, я сейчас собираю данные для нашего анализа прослеживаемости. Я представил предварительные результаты вчерашнего *одиночного* моделирования, которые обещают быть довольно многообещающими, но пока их не получится обобщить
    <sarang> Код с вашими правками и результатами уже в вашем репозитории?
    <suraeNoether> всё, что вам нужно будет сделать, это запустить playerchallenger.py с python3, и вы увидите результаты симуляции
    <sarang> Вы можете указать ветку и сам коммит, чтобы быть уверенным, что мы выполняем один и тот же код?
    <suraeNoether> Конечно, результаты будут отличаться от моделирования к моделированию, поэтому точные цифры, которые я предоставил вчера, будут также меняться
    <sarang> верно
    <suraeNoether> https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching – вот эта
    <sarang> Поймал, спасибо!
    <suraeNoether> во многих отношениях код еще не завершен (всегда есть способы сделать выбранную Евой схему взвешивания лучше или учитывать больше данных), но этого достаточно, чтобы начать сам анализ данных и уже сейчас получить числа для вспенивания
    <sgp_> Как мне его настроить для тестирования с различными параметрами вспенивания?
    <suraeNoether> в настоящее время я всё еще вношу изменения в код, чтобы специально исследовать вспенивание, и это потребует некоторых изменений в самой симуляции, не думаю, что закончу это сегодня
    <suraeNoether> ^ хех
    <sgp_> хорошо, я подожду
    <sarang> Я вижу коммит d5076 как самый последний
    <suraeNoether> да-да, именно он, d5076
    <sarang> понял, спасибо
    <suraeNoether> я думаю, что у документа MRL в ключе вспенивания будут *положительные* данные
    <suraeNoether> кроме этого, я пытаюсь нагнать RCT, omni и triptych документы, с которыми уже разобрался Саранг
    <suraeNoether> это все, что у меня есть для вас. О, это же и есть мой отчет о проделанной работе :p
    <scoobybejesus> *скрестил пальцы* а что насчёт моего вопроса
    <scoobybejesus> sarang> данный метод можно использовать только в ключе RCT3 и Triptych на этапе генерации образа ключа <<< Можно ли сделать, чтобы логика работала так, что подписание транзакции по-прежнему происходило с помощью линейной комбинации, но образ ключа был получен сразу несколькими участниками?
    <sarang> Нам нужен безопасный MPC для функции J(x) = (1/x)*U
    <sarang> если всё будет именно так, это будет лучше для каждой стороны
    <sarang> (где U - фиксированный генератор групп с кривой)
    <sarang> я пытаюсь найти документ, в котором этот конкретный PRF был впервые представлен
    <sarang> Цитата из документа Omniring (ссылка 20): https://www.iacr.org/cryptodb/archive/2005/PKC/3320/3320.pdf
    <sarang> у кого-нибудь еще есть работа, чтобы поделиться ею или просто обсудить её?
    <sarang> кроме того, меня одновременно и раздражает и восхищает эта конкретная псевдослучайная функция :p
    <suraeNoether> Просто вычисли логарифм и добавь ;)
    <sarang> Но на самом деле MPC для этой функции, основанной на линейных комбинациях, решит эту проблему
    <sarang> но это может и не сработать при сохранении хороших свойств PRF
    <sarang> (есть весомый аргумент, что такой MPC попросту не может существовать)
    <suraeNoether> если серьезно, почему бы не вычислить обратный результат произведения закрытых ключей и вместо частичной суммы на базовой точке, передаваемой вокруг, использовать произведение на этой самой базовой точке
    <suraeNoether> Если у меня есть x, а у вас y, пусть комбинированный ключ будет 1/(xy) U
    <sarang> только если вы уберете аффинное пространство составного ключа, я не знаю другого способа заставить всё это работать с остальной частью доказательства
    <sarang> и при этом я не понимаю, какие данные образа ключа будут переданы для создания целого образа
    <suraeNoether> Я отправляю вам (1/x)U. Вы умножаете на 1/y...
    <suraeNoether> Так что вам нужен не просто MPC, а линейная функция ввода ключа...
    <sarang> Возможно. Я думал в контексте комбинации линейных ключей изначально (так как остальные доказательства хорошо сочетаются с ними)
    <sarang> поэтому multisig работает так хорошо, потому что в нём всё хорошо сочетается с линейными комбинациями
    <sarang> что если бы можно было ослабить это ограничение
    <sarang> единственный момент в Triptych и RCT3, который требует использования закрытого ключа (без учета построения образа ключа) - это самый конец доказательства для построения замаскированного скаляра
    <suraeNoether> Хмммм
    <suraeNoether> Хорошо, я займусь дальнейшим чтением документа triptych и постараюсь слить мои изменения в репозиторий, чтобы продолжить эксперименты со вспениванием для sgp_
    <sarang> Правильно
    <sarang> Дайте мне знать, если у вас появятся какие-то дополнительные мысли в ключе multisig / MPC конструкций
    <sarang> О! Вот документ, который вышел совсем недавно. В нем описывается создание составных доказательств zk в библиотеке Python: https://arxiv.org/abs/1911.02459
    <sgp_> Спасибо, suraeNoether! Я заинтересован в тестировании вашей модели
    <sarang> Ну так что? Перейдём к КЛЮЧЕВЫМ МОМЕНТАМ?
    <sarang> Моя основная задача заключается в том, чтобы внести ясность в формализацию препринта Triptych и еще рассмотреть возможные варианты безопасности MPC
    <sarang> а затем я хочу сделать анализ работы suraeNoether над его кодом моделирования
    <sarang> (и наверстать отставание по документам)
    <suraeNoether> Мне же предстоит прокомментировать и задокументировать ту часть, в которой описывается, как всё это работает, для всех тех, кто хочет что-то понять и разобраться в этом
    <suraeNoether> кроме этого, я буду много читать и планирую доделать свои рабочие отчеты

    Источник: Research meeting: 12 November 2019 @ 17:00 UTC #409

    Перевод:
    Unholy (@Unholy)
    Редактирование:
    Mr. Pickles (@v1docq47)
    Коррекция:
    Kukima (@Kukima)
     
    #1 Unholy, 15 ноя 2019
    Последнее редактирование модератором: 16 ноя 2019
  • О нас

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