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

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

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    71
    Симпатии:
    6
    Присоединяйтесь к еженедельной встрече Monero Research Lab.

    Когда: Понедельник, 4 марта 2019 @ 17:00 UTC

    Где: #monero-research-lab (freenode/matrix)

    Повестка дня:
    1. Приветствия
    2. Круглый стол
      a. Sarang: monthly report, Bulletproofs MPC
      b. Surae
      c. SamsungGalaxyPlayer: public mining selection algorithm
      d. Прочие участники?
    3. Вопросы
    4. Дополнительные моменты
    Журнал встречи:

    * sarang изменил тему на «Встреча исследовательской лаборатории»: https://github.com/monero-project/meta/issues/309
    <sarang>
    Начнем?
    <sarang> 1. ПРИВЕТСТВИЯ!
    <sarang> Всем привет!
    <oneiric_> hullo
    needmoney90 запускает волну из рук!
    ErCiccione[m] скрывается, как настоящий итальянец
    <sarang>
    Давайте пройдемся по нашему пункту 2. КРУГЛЫЙ СТОЛ!
    <sarang> Так как я самый смелый, сильный и красивый, начинать тоже стоит с меня :D
    <sarang> Я опубликовал свой ежемесячный отчет за февраль (ссылка будет ждать вас в повестке дня), комментарии приветствуются
    <sarang> Помимо перечисленных там материалов и отчетов, у меня есть первоначальный рабочий код для Bulletproofs MPC (ссылка там же, в повестке дня)
    <sarang> moneromooo работает над идеей схемы типа coinjoin, для которой NPC был бы эффективным и пришелся бы кстати
    <sarang> Она все еще нуждается в большом количестве дополнительного и разностороннего тестирования и работы над ошибками, но код уже работает
    <sarang> Также мы с Шурэ все еще вносим изменения и правки в договор о совместной работе в коллабораци с другими исследовательскими подразделениями
    <sarang> На этой неделе я займусь дополнительной очисткой кода MPC и юнит-тестами
    <sarang> Есть вопросы по этим темам?
    <suraeNoether> У меня есть один
    <oneiric_> Ссылка на репозиторий?
    <sarang> Все ссылки в повестке дня: https://github.com/monero-project/meta/issues/309
    <oneiric_> спасибо :)
    <sarang> Код находиться в супер-пупер ранней стадии разработки
    <suraeNoether> bp mpc и coinjoin: принцип их работы описан где-то за пределами документации, посвященной bulletproofs? Я представляю, как именно работает bulletproofs MPC, но если подразумевается их совместное использование в coinjoin Monero, я хотел бы увидеть объяснение того, как именно
    <sarang> Оу, хорошая мысль! Вообще... Документация BP только вкратце описала протокол MPC и намекнула нам заглянуть в приложения за любой дополнительной информацией.
    <sarang> moneromooo работает над спецификациями coinjoin для Monero в своей отдельной ветве
    <suraeNoether> Документ для CoinJoin RingCT появился отдельно?
    <sarang> Насколько мне известно, нет. Он в моем списке :D
    <suraeNoether> понял
    <sarang> в любом случае рефакторизованный код bulletproofs с поддержкой MPC - это хорошая идея
    <suraeNoether> совершенно верно
    <sarang> Это превращает обычное доказательство с несколькими выходами в тривиальный MPC одного игрока
    <sarang> и, конечно же, верификатор совершенно не изменился
    <suraeNoether> Я не пытаюсь сказать, что работа над MPC не важна или бесполезна для Monero. Я просто хотел посмотреть, что было написано в самом документе
    <suraeNoether> моё обновление тоже простое
    <suraeNoether> Я работаю над февральским отчетом прямо сейчас. В дополнении работаю над своей просьбой о финансировании на следующий квартал 2019 года. Ещё мы с Сарангом работаем над нашим предложением, внесли одно большое изменение о выплате аванса, чтобы предотвратить истощения фонда оплаты для всех исследователей MRL в течение всего периода финансирования.
    sarang передает эстафету suraeNoether
    <sarang>
    О, это действительно хороший момент из новой модели финансирования
    <sarang> Мы много обсуждали и советовались по этому поводу
    <suraeNoether> В дополнении я передал материалы с доказательствами нашим соавторам, с которыми я почти ежедневно общаюсь по поводу скорой публикации материала; наши сроки были перенесены уже дважды, я попросил разрешения объяснить, над чем именно мы работаем
    <suraeNoether> sarang и я работали одновременно с двумя соавторами над формализацией материала DLSAG, я работал над доказательствами безопасности, в то время как sarang работал над получением временных результатов для наглядного сравнения и сопоставления результатов с "vanilla monero ringct"
    <sarang> Да, в документации есть определенные принципы построения материала и др.
    <suraeNoether> (одна из причин, по которой я хотел прочитать описание bulletproof coinjoin - это понять, насколько хорошо он будет сочетаться с новой схемой)
    <sarang> О, интересно. Я об этом не подумал.
    <suraeNoether> Да, короче говоря: это примитивы, необходимые в Monero для организации сети наподобие lightning
    <sarang> Протокол MPC bulletproofs не зависит от того, как выполняются подписи coinjoin
    <suraeNoether> sarang: правильно, bulletproofs mpc - это просто безопасное вычисление доказательства диапазона без раскрытия скрытых значений вашим подписчикам
    <sarang> Верно
    <sarang> я понимаю вашу точку зрения
    <suraeNoether> в дополнение к этому мой план на эту неделю состоит из: 1) изучения подробной информации о flyclient и внесение сторонних предложений (если таковые будут, даже если они игнорируют flyclient) 2) соответствующее моделирование (были сдвинуты из-за последних затянувшихся субботних вечеров за работой) 3) Мой февральский отчет + запрос на финансирование в следующем квартале
    <suraeNoether> Пожалуй, это закрывает мое краткое обновление для круглого стола
    <suraeNoether> я хотел бы услышать от кого-либо еще, кто провел какие-либо исследования на прошлой неделе. isthmus всегда горит продуктивностью (у бедняги уже ожоги 3-й степени)
    <suraeNoether> О, я смотрю на повестку дня, и у нас есть выступление sgp_
    <suraeNoether> sgp предложил другой алгоритм выбора входных данных для пулов: https://github.com/monero-project/monero/issues/5222
    <sgp_> да, suraeNoether, спасибо за ссылку на обсуждение Github
    <sgp_> это обсуждение только вокруг алгоритма выбора данных в разрезе пула, а не алгоритма по умолчанию для всех пользователей
    thrmo вышел (~thrmo@unaffiliated/thrmo): Причина: Он покинул нас...
    el00ruobuob подключился (~el00ruobu@blabour.fr)
    <sgp_>
    Я полагаю, что это не будет противоречивым или спорным решением и не сможет оказать негативного влияния на какую-либо подсистему, если вы видите это как-то иначе, я хотел бы получить ваш комментарий по данному моменту
    <sgp_> Если ко мне нет вопросов, мы можем приступать
    <suraeNoether> мысли, представленныпе в вашем обсуждении на github, отчасти пересекаются с мыслями, изложенными isthmus, он поднимал данный вопрос для транзакций, в которых участвует несколько разнородных входов, и я думаю, что это обсуждение немного обширнее и глубже, чем вы можете себе представить
    <suraeNoether> поскольку выбор входа не является консенсусом по умолчанию, любой пул может *решить* делать это как ему удобно
    <sgp_> может быть и так, эта концепция была уже представлена в начале 2018 года
    <moneromooo> Я хотел бы получить весомое подтверждение, что это не повредит чему-либо еще или не сломает что-то с «другой стороны», прежде чем я изменю код
    <moneromooo> (от sarang или / и surae)
    <suraeNoether> проблема, как я понимаю, заключается в том, что она уменьшает «вещи» следующим образом -
    <sarang> Я глянул его бегло сегодня утром, но в любом случае я хочу посмотеть на этом более подробно
    <suraeNoether> если у нас есть размер кольца N*M, а среднее количество выходов на транзакцию равно M, а члены кольца выбираются по транзакции, а не по вводу, есть веский аргумент, что это уменьшает эффективный размер кольца до N.
    <suraeNoether> истинный размер кольца - N*M, но в качестве кольцевых элементов включены только N транзакции
    <sarang> Правильно, это версия binning
    <sarang> и если вы можете устранить прочий мусор доказуемо или эвристически, это проблема
    el00ruobuob_[m] подключился (~el00ruobu@blabour.fr)
    <sgp_>
    Я утверждаю, что типичные недостатки binning здесь не применяются, так как общедоступные пулы делают все транзакции общедоступными
    <sgp_> Кольцевые подписи в свою очередь могут обеспечить защиту равную 0, пулы при таких раскладах не будут чем-то хуже
    <suraeNoether> хммм, что ж
    ⇐ el00ruobuob вышел (~el00ruobu@blabour.fr): Превышено время ожидания: 240 секунд
    <suraeNoether> проблема не заключается в конфиденциальности каких-то отдельных пулов
    <suraeNoether> просто их поведение может негативно влиять на конфиденциальность других участников экосистемы monero
    <sgp_> Цель состоит не в том, чтобы установить эффективный размер кольца для пула. Идея заключается в сохранении целостности выходов пула, используемых в других кольцах
    <sarang> верно
    <suraeNoether> sgp_: теперь я понял
    <suraeNoether> в любом случае
    <suraeNoether> скажем, у меня есть пул и 3 xmr, я хочу отправить по 1 xmr (1) майнеру Алисе и (2) майнеру Бобу и (3) себе любиому
    <suraeNoether> у нас уже три выхода
    <suraeNoether> Предположим, что каждый выход будет равен 1 xmr
    <sgp_> понял :)
    <suraeNoether> по вашему предположению я построил 3 отдельных кольцевых подписи, все из которых содержат эти выходы
    <suraeNoether> более того, я общественный пул
    <suraeNoether> любой желающий сможет увидеть, что все 3 выхода были потрачены
    <sgp_> стоп, подожди
    <suraeNoether> у меня есть выходы A, B и C. Я хочу отправить A Алисе, B Бобу и C Чарли. Все являются выходом одной транзакции, следовательно, я должен включить A, B и C в свои кольца
    <suraeNoether> если я хочу отправить все 3, это гарантирует, что любой может увидеть, что они были потрачены
    <sgp_> это предложение алгоритма выбора входных данных предназначено для обработки изменений выходных данных, не источника (например, coinbase). Они требуют еще одного более агрессивного вмешательства
    <sgp_> Я немного сбит с толку тем, как вы интерпритируете эти результаты
    <sgp_> Если у вас есть 3 XMR на выходе A, вы сами создаете транзакцию для Алисы, Боба с выходами B, C, D
    <sgp_> Затем вы создаете следующую транзакцию с кольцом {B, C, D}
    <sgp_> чтобы сделать непонятным, какой именно из B, C, D является выходом
    <suraeNoether> стоп, я не это имел в виду, я оговорился, дай мне еще одну попытку :D
    <sgp_> согласно этому преподложению A всё равно известна нам как трата. Это не решает проблему
    <suraeNoether> гхммм… вы знаете… мне нужно подумать над этим… пул не будет иметь 3 выхода из одной транзакции, он должен генерировать кучу одиночных выходов, каждый из отдельной транзакции
    <suraeNoether> я думаю, мы должны посвятить этому моменту немного больше времени
    <suraeNoether> но я предполагаю, что это может иметь кучу изменений для структуры транзакций
    <suraeNoether> хорошо, я могу привести пример, но давайте сделаем это после встречи
    <sarang> принял
    <sarang> У кого-нибудь есть еще какие-либо интересные исследования?
    <sgp_> я не говорю, что это идеальное решение, которое защищает от всех эвристик, но это постепенное улучшение по сравнению со статусом-кво ;)
    <sarang> Мы также можем объединить это с пунктом 3. Вопросы от кого-либо по любой доступной теме, связанной с исследованиями
    <oneiric_> вопросы по взаимодействию kdf, но, возможно, не по теме
    <sarang> Стреляй, у нас есть время
    <oneiric_> Итак, интеграция i2p присматривается к Reddsa из zcash в качестве автономного алгоритма подписи
    <oneiric_> RedDSA имеет уникальный способ генерации “ослепляющего «альфа» материала” для создания нового “слепого закрытого ключа”
    <oneiric_> кроме того, она полностью идентична eddsa
    <sarang> Хорошо, я не был знаком с этой конструкцией
    <oneiric_> ищу ссылку на «альфа» генерацию, один момент
    <oneiric_> https://geti2p.net/spec/proposals/123-new-netdb-entries#blinding-calculations
    <oneiric_> и предложенный red25519: https://geti2p.net/spec/proposals/146-red25519
    <suraeNoether> Окей
    <oneiric_> Есть что-то опасное или уже известные ошибки, о которых вы знаете?
    <sarang> Таким образом, разница заключается в детерминированном выводе смещения для секретного «альфа» ключа
    <oneiric_> sarang, да, я тоже так и понял
    <sarang> Если злоумышленник может получить какое-либо преимущество при попытке определения входных данных хеш-функции, используемых для получения «альфа», это хреново…
    <oneiric_> у них есть контроль над пунктом назначения, но его в любом случае хешируют
    <suraeNoether> oneiric_: кажется, что основной упор делается именно на "секретный" вход
    <suraeNoether> если кто-то будет использовать пустой "секрет" (просто "0" или плохо подобранный пароль), то кто-то может получить места назначения и временные мерки и держать их все в большой таблице и искать необходимую информацию по ним
    <oneiric_> да, это херово... полностью подрывает всю суть схемы
    <suraeNoether> следующий вопрос - должны ли они переключиться в случае чего на SHA256, и ответ "нет", потому что hkdf в основном используется hmac в качестве kdf, я писал про это около года назад
    <suraeNoether> Воуу "насколько мне известно
    hkdf hmac kdf"
    <oneiric_> Что бы вы предложили в качестве альтернативы для генерации альфа, или есть какие-то проверки, которые можно включить, чтобы предотвратить неправильный выбор?
    <oneiric_> blake2b вменяемая альтернатива, верно?
    <suraeNoether> oneiric_, я не думаю, что есть защита от использования просто паршивой случайности :)
    <suraeNoether> выбранная хэш-функция не имеет большого значения, пока HKDF правильно реализован к HMAC, даже паршивые хэш-функции могут давать неразличимые результаты
    <suraeNoether> но допустим, ты сказал:
    <suraeNoether> "вместо использования простого секрета, давайте мы будем использовать HKDF (секрет) или SHA256 (секрет)", но вы все еще можете быть взломаны и вам пригодиться просто немного удачи...
    <sarang> давайте закончим и перенесем обсуждение этого за пределы временных рамок нашей встречи
    <sarang> 4. ДОПОЛНИТЕЛЬНЫЕ МОМЕНТЫ
    <oneiric_> Спасибо! Я очень ценю ваши вклады, sarang и surae
    <sarang> Я рассмотрю предложение sgp_ более подробно, завершу работу над кодом MPC и проведу дополнительные тесты, и, надеюсь, выложу документ, связанный с DLSAG, чтобы мы могли публиковать его в открытом доступе
    <gingeropolous> мне любопытно, MRL стоит на SPECTRE и в общем отходит от Накамото-консенсуса. Если ли информация из предыдущего расследования? Мне особенно интересно, потому что если Monero когда-либо действительно достигнет сильной децентрализованной сети со многими майнерами, существующая система консенсуса может дать серьёзные трещины
    <gingeropolous> децентрализованная сеть? То есть, если бы у нас было 3k узлов, и все занимались соло-майнингом на скорости 200 h/s с транзакциями, поступающими случайным образом со всех узлов, насколько хорошо будет функционировать сеть при таких условиях?
    <sarang> Позже в этом месяце я опубликую свой новый запрос на финансирование, который, как и запрос suraeNoether, будет иметь предварительный авансовый платеж для защиты от волатильности
    <gingeropolous> извините, что ждал непонятно чего и только сейчас нажал Enter
    <sarang> SPECTER и PHANTOM имеют проблемы с масштабированием
    <sarang> и различные гарантии
    <sarang> было предложение сделать между ними своего рода гибрид
    <suraeNoether> gingeropolous: spectre актуален по нескольким причинам, но ужасно дерьмовый в разрезе масштабирования (хотя эта часть полностью смягчается с помощью const-time spectre). Материал о spectre сводиться к тому, что он очень хорошо работает против разделения сети
    <suraeNoether> в Накамото-консенсусе, если сеть будет разделена на две части, обе стороны продолжают вести свои независимые учетные системы
    <suraeNoether> в случае, когда они воссоединяются, только записи на одной стороне будут окончательными
    <suraeNoether> (кроме неконфликтных)
    <suraeNoether> с другой стороны, в spectre записи, сделанные с обеих сторон, имеют шанс быть объединенными в учетную систему
    <suraeNoether> поэтому вместе с некоторыми аргументами вероятности он более надежен, чем Накамото
    <sarang> Я по-прежнему остаюсь оптимистом по поводу возможного общего механизма на основе графов
    <suraeNoether> как любит жаловаться Тони Арциерайерхал в twitter, Накамото-консенсус на самом деле не является хорошим "решением" для Византийского-консенсуса из-за описанного выше свойства разделения.
    <suraeNoether> https://en.wikipedia.org/wiki/CAP_theorem : Накамото набирает низкий балл на P в CAP
    <sarang> suraeNoether: какие-то дополнения от вас?
    <suraeNoether> spectre жертвует C для P
    <suraeNoether> 1) отчет за февраль 2) запрос FFS на следующий квартал 3) сопоставление моделей 4) изменения dlsag 5) чтение о клиенте fly и mmr
    <suraeNoether> sarang: ваши точки отсчета?
    <sarang> Звучит отлично
    <sarang> Есть замечания, прежде чем мы официально завершим сегодняшнюю встречу?
    <sarang> Эм, я уже сказал свое
    <sarang> Я рассмотрю предложение sgp_ более подробно, завершу работу над кодом MPC и проведу дополнительные тесты, и, надеюсь, выложу документ, связанный с DLSAG, чтобы мы могли публиковать его в открытом доступе
    <suraeNoether> о, теперь я вижу
    <sarang> Спасибо всем, что пришли. Мы объявляем перерыв!

    Cсылка на предыдущую встречу исследовательской лаборатории Monero от 2019-02-25
    Источник: Research meeting: 4 March 2019 @ 17:00 UTC #309

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

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