Присоединяйтесь к еженедельной встрече Monero Research Lab. Когда: Понедельник, 4 марта 2019 @ 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол a. Sarang: monthly report, Bulletproofs MPC b. Surae c. SamsungGalaxyPlayer: public mining selection algorithm d. Прочие участники? Вопросы Дополнительные моменты Журнал встречи: * sarang изменил тему на «Встреча исследовательской лаборатории»: https://github.com/monero-project/meta/issues/309 <sarang> Начнем? <sarang> 1. ПРИВЕТСТВИЯ! <sarang> Всем привет! <oneiric_> hullo — needmoney90 запускает волну из рук! — ErCiccione[m] скрывается, как настоящий итальянец <sarang> Давайте пройдемся по нашему пункту 2. КРУГЛЫЙ СТОЛ! <sarang> Так как я самый смелый, сильный и красивый, начинать тоже стоит с меня <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> Насколько мне известно, нет. Он в моем списке <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> стоп, я не это имел в виду, я оговорился, дай мне еще одну попытку <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)
