Когда: Среда, 13 мая 2020 г., 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты Журнал встречи: <sarang> Вначале, приветствия <sarang> Hi <binaryFate> hello! ⇐ Inge- вышел (~inge@17-231-47-212.rev.cloud.scaleway.com): Причина: Бездействие в течение 246 секунд <Isthmus> Heyo <h4sh3d[m]> Hello → Inge- подключился (~inge@17-231-47-212.rev.cloud.scaleway.com) <ArticMine> Hi <sarang> Следующий пункт - КРУГЛЫЙ СТОЛ <rehrar> hi <sarang> У кого-нибудь есть интересное исследование, которым можно поделиться? <sarang> насколько я знаю, Isthmus хотел поведать нам о чем-то <Isthmus> Всем привет! Я учел все ваши комментарии и замечания, огромное спасибо! Обновленная версия: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/142 <Isthmus> Большая часть изменений пришлась на Дорожную карту <Isthmus> В первой фазе мы перешли к очень формальному перечислению потенциальных противников и особенностей Monero и будем документировать все возможные проблемы и сопутствующие решения по следующим направлениям: <Isthmus> «[Компонент] Monero уязвим к [воздействию] гипотетического противника, который может использовать следующий [алгоритм]. Решение должно соответствовать этим [требованиям]. Текущие методы включают в себя [схему], которая потребует [процесса миграции] и имеет следующие [компромиссы], которые будут препятствовать полноценной реализации алгоритма. Как вариант, пока [пропускная способность сети / устройства] не сможет преодолеть ограничение» <Isthmus> На протяжении всего проекта сообщество будет получать обновленные и актуальные данные во время еженедельных исследовательских встреч на #monero-research-lab. На третьей фазе будет опубликовано несколько больших независимых документов (ключевые результаты исследований): <Isthmus> 1. Удобочитаемая заметка — материал, специально подготовленный и адаптированный для любого читающего с доступными объяснениями того, как квантовые компьютеры могут повлиять на Monero и какие потребуется принять меры для смягчения последствий такой атаки. Запись должна минимизировать FUD и преподнести материал так, что эти уязвимости применимы почти ко всем криптовалютам (а не только Monero). <Isthmus> 2. Техническая документация - документ с изложением позиции MRL для сбора ключевой информации для (текущих и будущих) исследователей и разработчиков. В статье подробно будут описаны уязвимости и выделены потенциальные стратегии и решения или наиболее применимые компромиссы. В дополнение в качестве примера могут быть добавлены варианты кода, если это необходимо в преподавательских или педагогических целях. <Isthmus> 3. Пресс-релиз для журналистов — специальная версия документа для новостных сайтов и изданий (по типу Monero Outreach), в которой содержится нетехническая информация, а также основные выводы, которые должны подойти всем пользователям без исключения. <Isthmus> Также все результаты и обновления будут распространяться через Twitter, посты Reddit и, как вариант, видео Breaking Monero <Isthmus> (конец) <Isthmus> О! Я сегодня еще планирую опубликовать небольшой пост в Reddit <sarang> Мне нравится изменение в сфере охвата исследования, особенно пересмотр информирования о текущем состоянии протокола <sarang> отход от конкретных вещей, таких как реализация или проверка концепции, кажется особенно разумным, если учесть, что вычислительная техника не стоит на месте и постоянно меняется <Isthmus> ^ согласен <Isthmus> Важно отметить, что многим *кандидатам* для постквантовой криптографии потребуются намного больше изменений в доказательствах и значительное увеличение вычислительных ресурсов, следовательно, они не подходят для оперативного развертывания. По этой причине понимание общих стратегий и возможных компромиссов будет очень полезным, нежели конкретные примеры и указания для реализации <sarang> вопросы к Isthmus (можно рассмотреть комментарии из темы самого предложения, чтобы охватить более широкую область)? <rehrar> неа <sarang> Хорошо, кто-нибудь еще хочет поделиться своими исследованиями? <sarang> если нет, тогда, пожалуй, я представлю своё обновление за прошедшую неделю <h4sh3d[m]> Да, у меня есть что-то <h4sh3d[m]> ранее кто-то уже говорил об этом: https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f <sarang> Да, это идея атомарного свопа <h4sh3d[m]> Я рассмотрел её немного пристальней, и часть с подписью адаптера ECDSA мне показалась очень интересной <sarang> Вы о том, что избегает использования хеш-доказательств преобраза? <sarang> (мне всё еще предстоит это детально изучить) <h4sh3d[m]> Да, протокол очень близок к тому, чем я уже поделился с вами <h4sh3d[m]> идея с использованием dl-доказательства между различными группами с помощью подписи адаптера ECDSA может работать <sarang> По крайней мере, само DL-доказательство эквивалентности между группами очень простое <sarang> и что самое главное, оно работает уже сейчас <h4sh3d[m]> Да, именно поэтому это и интересно =) <h4sh3d[m]> и еще немного от меня: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html <sarang> эта ссылка связана с gist? <Isthmus> Очень здорово <sarang> понял, это ссылка из gist <h4sh3d[m]> Да, первая ссылка «часть с подписью адаптера ECDSA» из Gist <sarang> понял-понял <sarang> с нетерпением жду его завершения <h4sh3d[m]> С помощью этого мы сможем поместить одну половину ключа monero в адаптер `Y " (или другую в зависимости от того, удастся своп или нет) ⇐ heatsinkid вышел (~heatsinki@gateway/tor-sasl/heatsinkid): Удаленный хост разорвал подключение <h4sh3d[m]> мне интересно, что получится в итоге. Но как отметил zkao, что на данном этапе это всего конструкция <sarang> получить как можно больше реализаций такой схемы, безусловно, очень хорошо <sarang> спасибо, что поделились, h4sh3d[m] (и zkao тоже!) <sarang> у вас есть вопросы для h4sh3d[m]? <h4sh3d[m]> Круто, я продолжу публиковать свои результаты <sarang> Вам спасибо, никаких проблем <sarang> Я закончил часть своей работы над протоколами транзакций следующего поколения, поэтому я опубликовал обновленную концепцию реализации Arcturus на C ++: https://github.com/SarangNoether/monero/tree/arcturus → heatsinkid подключился (~heatsinki@gateway/tor-sasl/heatsinkid) <rehrar> воуууу!!!! <sarang> и добавил отказ от ответственности, та работа еще не подвергалась какой-либо проверке и должна считаться небезопасной для финального использования <sarang> тем не менее у меня уже есть новые данные о пространстве / времени <sarang> еще мне пришлось переписать тесты производительности для Triptych, MLSAG и CLSAG для лучшего сравнения, так как Arcturus интегрирует проверку баланса непосредственно в доказательство (а другие нет) <sarang> Результаты, которые я вставлю через секунду, показывают, что структура входа / выхода транзакций играет роль в общих результатах синхронизации <sarang> данные для транзакций 1-in-2-out: https://usercontent.irccloud-cdn.com/file/KZxENlzN/timing-1-2.png <sarang> данные для транзакций 2-in-2-out: https://usercontent.irccloud-cdn.com/file/Ww2hDEbo/timing-2-2.png <sarang> данные учитывают общее время проверки подписи / подтверждений и проверки баланса <sarang> но не учитывает проверку диапазонов (она одинаковая для всех протоколов) <sarang> вы можете получить свои результаты, выбрав соответствующие параметры теста производительности в моей ветке `clsag-device` (для MLSAG и CLSAG), ветке` triptych` (для Triptych) или ветке `arcturus` (для Arcturus) <sarang> серые линии в точке 11-MLSAG показывают результат в настоящем времени <binaryFate> очень похоже на результаты Triptych. У вас есть результаты для большего количества входов / выходов? <sarang> при увеличении размера кольца результаты Triptych и Arcturus не сильно изменятся, так как компонент проверки баланса становится менее значимым <sarang> главным образом вся разница сводится к тому, как отделены операции группы проверки баланса (в Triptych) или включены ли они в одну мультискалярную операцию с остальной частью доказательства (в Arcturus) <sarang> и этой разницы не заметно при увеличении размера кольца <sarang> разница буде видна только в размере самой транзакции <sarang> я почему-то думал, что результаты Arcturus уже включены… ошибся... Я исправлю это сразу после встречи <sarang> вне зависимости от этого, я координирую подготовку технического задания для предстоящего аудита CLSAG от OSTIF и Teserakt, которые рекомендовала рабочая группа по аудиту. <sarang> у вас есть еще какие-то вопросы по любой из представленных мной тем? <moneromooo> Оооооооу ^_^ → lederstrumpf подключился (lederstrum@gateway/shell/matrix.org/x-ebhqmmiiojtdocdx) <sarang> у кого-нибудь еще есть темы для обсуждения за круглым столом? <Isthmus> Хмм, я только что вспомнил, как генерировались аватары из морских раковин, основанные на преобразовании метаданных транзакций с неоднородной структурой в строку, а затем пропускали её через визуальную хеш-функции от surae ... <Isthmus> на этих выходных я постараюсь создать прототип, чтобы показать его на следующей неделе (довольно сложно описать всё это абстрактно) <sarang> О, чувак, я помню эту идею с ракушками! Прошло уже очень много времени <Isthmus> Да. Я раздобыл репозиторий Шурэ прямиком из 2018 года, но еще не успел подключить его к своим входным данным Monero https://github.com/Mitchellpkt/seashells/blob/master/seashells_notebook.ipynb <sarang> думаю, что мы можем перейти к КЛЮЧЕВЫМ МОМЕНТАМ и завершить встречу <selsta> у меня была идея добавить возможность создания ракушек в CLI <sarang> Я внесу некоторые изменения в свой PR шифрования ключей в памяти, более подробно рассмотрю предложение о свопе и обновлю модель безопасности Arcturus перед предстоящей подачей документа на конференцию <sarang> кто-то еще? <h4sh3d[m]> Я займусь более детальным изучением адаптера ECDSA и перепишу кое-какие части документа об атомарном свопе <sarang> вы имеете в виду обновление вашей статьи? <h4sh3d[m]> да <sarang> превосходно! <sarang> хорошо, полагаю, что мы можем закончить; спасибо всем за участие! <sarang> журнал встречи будет опубликован в ближайшее время Источник: Research meeting: 13 May 2020 @ 17:00 UTC #462 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
