Перевод Журнал встречи исследовательской лаборатории Monero от 2020-01-13

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

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    196
    Симпатии:
    13
    Когда: 13 января 2020 @ 17:00 UTC
    Где: #monero-research-lab (freenode/matrix)

    Журнал встречи:

    <sgp_> Время встречи исследовательской лаборатории Monero
    <sgp_> Приветствия
    <sgp_> отдельно пропингую: sarang, moneromooo, SerHack, ArticMine, binaryFate
    <sgp_> knaccc
    <sarang> hi
    <sgp_> dEBRUYNE
    <sgp_> needmoney90
    <sgp_> прошло довольного много времени с последней встречи, надеюсь, что у всех все в порядке :)
    <sgp_> https://github.com/monero-project/meta/issues/542
    <sgp_> ну, я собираюсь продолжить и надеюсь, что другие воспрянут духом уже по ходу данной встречи
    <sgp_> 1. Аудит Bulletproofs+
    <sgp_> это самый важный момент сегодняшней встречи
    <sgp_> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/197
    <sgp_> прошло 3 недели с тех пор, как они открыли предложение
    <sgp_> sarang: у вас были какие-то вопросы, они ответили на них?
    <sarang> Было дело! Сфера применения очень широка, и всё сводится к воспринимаемой общественной ценности
    <sgp_> на последнем собрании рабочих групп Monero они пришли к выводу, что перед перемещением предложения им нужно услышать ваши замечания
    <sgp_> sarang: Что вы подразумеваете под «сферой применения»?
    <sarang> Они намерены сделать обзор препринта, обзор кода и затем сравнить его с некоторыми другими реализациями
    <sarang> И это весьма отличный подход к аудиту
    <sarang> также я думаю, что цена вполне уместна
    <sgp_> а что за сравнение? Насколько оно нужно в ключе данного аудита?
    <sarang> Как минимум, не думаю, что это будет лишним
    <sarang> и если бы нам нужно было выбрать что-то, что нужно исключить, я бы сказал, что мы можем отказаться от данной части их предложения
    <sgp_> понял
    <sarang> просто я считаю, что сравнение не будет лишним
    <sgp_> они обещают управиться с аудитом за месяц
    <sgp_> хорошо, давайте оставим сравнение
    <sgp_> что насчёт дополнительного аудита?
    <sarang> sgp_: да, за данную цену это вполне разумный срок
    <sarang> Если бы сравнение повышало общую цену предложения, тогда да, от него можно было бы отказаться
    <sgp_> вы считаете, что аудиторы достаточно компетентны для проведения подобного анализа?
    <sarang> Я не могу за них поручиться лично, однако у них есть предыдущие работы, которые были весьма лояльно восприняты
    <sgp_> значит, перемещаем предложение как есть
    <Isthmus> +1
    <sarang> думаю, что проблем не должно возникнуть
    <Isthmus> В лучшем случае мы получаем отличный аудит. Если рассматривать второй негативный вариант – мы ищем новых аудиторов и считаем первый аудит фиктивным :- )
    <dEBRUYNE> Я бы сказал, что ошибочное чувство безопасности — это недостаток
    <sgp_> в худшем случае они просто представляют аудит, который мы не будем учитывать
    <dEBRUYNE> (если это действительно плохой аудит)
    <dEBRUYNE> я по-прежнему голосую за привлечение второй команды аудиторов
    <dEBRUYNE> Тем более, что мы касаемся деликатных частей кода
    <sgp_> следует ли нам начать искать других аудиторов уже сейчас или этим можно заняться после окончания первого аудита?
    <sarang> Возможно, стоит провести еще один аудит, который затронет только код?
    <dEBRUYNE> Думаю, что уже пора начинать
    <sarang> Думаю, что остальные части аудита можно опустить
    <sgp_> не вижу никаких препятствий
    <dEBRUYNE> да, мне нравится идея с аудитом только кодовой базы
    <Isthmus> +1 sgp
    <ErCiccione[m]> дополнительная проверка кода — это хорошая идея
    <sgp_> dEBRUYNE, sarang, Isthmus: у вас есть кто-то на примете?
    <sgp_> возможно, стоит написать письмо Quarkslab или Kudelski, что думаете?
    <dEBRUYNE> как насчёт OSTIF?
    <gingeropolous> +1 за дополнительный аудит
    <dEBRUYNE> В прошлом они уже выступали посредниками для проведения аудита
    <Isthmus> С кем мы уже взаимодействовали раньше? Подходят ли они для данного аудита?
    <sgp_> рабочая группа по проведению аудитов не была впечатлена их работой в прошлый раз
    <hyc> в предыдущий раз нам не понравился аудит от OSTIF
    <dEBRUYNE> sgp_: вы имеете в виду OSTIF?
    <sgp_> Да
    <dEBRUYNE> Я полагаю, что поиск аудиторов через OSTIF побуждает чувство доброй воли, но, как правило, это также увеличивает и цену за аудит
    <hyc> а какие были проблемы с OSTIF? Как по мне, аудит randomx получился отличным
    <sgp_> 1) мы не получили вариант с дешевыми тарифными ставками, 2) все разговоры с ними приводили к большей путанице
    <sgp_> и они просят 10% за оказание своих услуг
    <hyc> понял
    <sgp_> sarang, у вас контакты тех, с кем мы уже работали в прошлом?
    <sarang> думаю, что да
    <dEBRUYNE> думаю, что как минимум стоит проконсультироваться с OSTIF
    <sgp_> хорошо, кто-то еще считает, что нам нужно связаться с OSTIF? Кстати, Саранг, вы можете ставить меня в копию всех электронных писем
    <gingeropolous> я думал, что OSTIF был обязательным фактором, потому что аудиторы должны работать через какую-то некоммерческую организацию
    <sgp_> gingeropolous: Не уверен, что это всё именно так работает. Хотя….
    <dEBRUYNE> Это было связано с налогами и прочей бюрократией
    <sgp_> часть с налогами можно исключить, так как это будут пожертвования
    <gingeropolous> Понял вас. Что могу сказать, это хорошая отправная точка
    <sgp_> Хорошо, значит, мы пришли к консенсусу
    <sgp_> Любые дополнительные комментарии?
    <sgp_> Подводя итог: мы перемещаем открытый CCS запрос на стадию финансирования, а уже затем приступаем к поиску дополнительных аудиторов
    <sarang> Отлично
    <sarang> Мы можем ограничить объем кода для аудита
    <sgp_> sarang, пожалуйста, свяжитесь со мной после встречи, мне нужно кое-что обсудить с вами
    <sgp_> если кто-то хочет помочь с организационными моментами нашей рабочей группы по проведению аудита, пожалуйста, напишите мне тоже
    <sarang> да, конечно
    <sgp_> Окей, двигаемся дальше
    <sgp_> Triptych / Arcturus
    <sgp_> У меня есть довольно важный вопрос:
    <sgp_> как обстоят дела с Arcturus? Были ли какие-то изменения за время последнего обсуждения?
    <sarang> Ну, появилась реализация на Rust, которая показывает себя намного лучше, чем стандартная
    <sarang> ну а так, ничего нового
    <sgp_> (прощу прощения, мне нужно ненадолго отойти)
    <dEBRUYNE> Теоретически мы уже сейчас можем приступить к интеграции Triptych
    <dEBRUYNE> думаю, что люди уже смирились с тем, что multisig потребует более сложной реализации
    <Isthmus> sgp, окей
    <Isthmus> @sarang, реализация на rust уже общедоступна?
    * Isthmus отправился проверять репозиторий
    <sarang>
    да, конечно!
    <sarang> https://github.com/cargodog/arcturus
    <sgp_> я почти вернулся
    <Isthmus> спасибо, @sarang
    <sgp_> есть ли у нас какой-то запасной вариант?
    <sgp_> есть еще одно предположение
    <sarang> Arcturus по своей природе более рискованный вариант, учитывая его новую структуру
    <Isthmus> Что за запасной вариант? Не совсем понимаю
    <sgp_> как снизить риски?
    <sgp_> или это невозможно?
    <sarang> Требуется время и экспертная оценка
    <dEBRUYNE> да, риски несут в себе катастрофические последствия
    <sarang> Проверка предположения сильно отличается от проверки самой реализации
    <sarang> всё верно
    <dEBRUYNE> Я считаю, что было бы разумно «перестраховаться» и остановиться на Triptych
    <gingeropolous> угу
    <dEBRUYNE> Различия недостаточно велики, чтобы гарантировать выбор реализации, основанной(основываясь?) на новом предположении
    <gingeropolous> двойное угу
    <sgp_> Кто-нибудь из присутствующих вообще в курсе, как сейчас обстоят дела с arctutus?
    <sgp_> или можно прекратить тратить время на разговоры об этом?
    <sgp_> я бы вернулся к рассмотрению arcturus после появления квалифицированных аудитов
    <ArticMine> Извините, я опоздал. Мое мнение заключается в том, что мы можем рассмотреть Аrcturus позже, после внедрения Triptych
    <Isthmus> Все это кажется разумным
    * Isthmus кивает в поддержку предложения от ArticMine
    <sgp_>
    хорошо, кто-то против того, чтобы мы сосредоточились только на triptych?
    <moneromooo> Количество правок в коде одинаковое для двух вариантов?
    <sarang> В принципе, они идентичны в этом плане
    <sgp_> sarang: ^
    <sarang> Но все же есть существенные внутренние различия
    <sgp_> для журнала встречи: кто за то, чтобы полностью сосредоточиться на triptych?
    <ArticMine> Я
    <sethsimmons> <sgp_ "кто за то, чтобы полностью сосредоточиться на triptych?"> я
    <moneromooo> пожалуй, я тоже выберу этот вариант
    <dEBRUYNE> мой выбор Triptych
    <dEBRUYNE> я скоро вернусь, нужно отойти
    <sethsimmons> Отлично, давайте сосредоточимся на triptych, а потом, если потребуется, мы подумаем об Arcturus
    <sethsimmons> В Arcturus нет явных плюсов, особенно если учитывать потенциальные риски
    <sgp_> я предполагаю, что нам не потребуется рассматривать вариант с Arcuturus, так как через несколько лет будет что-то еще лучше
    <sarang> образы ключей идентичны для этих вариантов
    <sethsimmons> Да, думаю, что есть такие шансы
    <sarang> и миграция выходов не требуется
    <sarang> это очень похоже на то, как мы делали в случае перехода от MLSAG к CLSAG
    <sethsimmons> Triptych — это большой шаг вперед, и он позволит выиграть много времени для следующей гонки вооружений
    <sarang> миграция потребуется в случае CLSAG->{Arcturus,Triptych}
    <sgp_> Окей, с этим определились. Каков наш следующий шаг?
    <sgp_> Финансирование работы Саранга?
    <sarang> Насколько важны мультиподписи?
    <sgp_> хм, хороший вопрос...
    <sgp_> так, проведём быстрое голосование
    <sarang> Важными проблемами остаются такие моменты, как группирование / алгоритм выбора / представление выходных наборов данных и проблемы миграции выходных данных и multisig
    <ArticMine> Я говорю «да»
    <moneromooo> Конечно, да
    <sethsimmons> <sarang "Насколько важны мультиподписи?"> Разве в Arcturus не те же самые проблемы с мультиподписью, что и в Triptych?
    <sarang> Код проверки / верификации уже работает
    <ErCiccione[m]> я голосую за
    <sarang> а вот код мультиподписи отсутствует, и его реализация весьма нетривиальна
    <sgp_> Является ли отсутствие мульподписи препятствием для реализации обновления в аппаратные кошельки?
    <moneromooo> Нет.
    <ArticMine> Нет
    <sethsimmons> Неа
    <sgp_> Понятно, значит, нет
    <sethsimmons> ими пользуется очень крошечный процент пользователей
    <sethsimmons> как по мне, лучше улучшить предположения о конфиденциальности по умолчанию
    <sarang> Чтобы внести ясность: у нас есть способ обрабатывать мультиподписи, но для этого потребуется дополнительный код и добавление библиотеки для общих структурных групп (группы RSA).
    <sarang> Я не могу сказать, насколько это реализуемо в аппаратных кошельках
    <sethsimmons> А это вообще им нужно?
    <sarang> Мультиподписи? Не думаю
    <sethsimmons> или мы можем добавить поддержку мультиподписей уже после реализации?
    <sarang> мы не можем с полной уверенностью сказать, что это ненужный функционал
    <sethsimmons> ну, это явно лучше, чем ничего
    <ArticMine> Я предлагаю следующий путь действий — добиться полноценной работы мультиподписей в triptych и уже затем перейти к этапу с его реализацией
    <sethsimmons> мы можем вернуться к этой проблеме уже после этапа реализации
    <sarang> Как быть в случае, если мультиподписи в Triptych не смогут корректно работать на аппаратных кошельках
    <sethsimmons> или, как вариант, работать над этой проблемой параллельно
    <sgp_> ну, это не должно быть помехой для его реализации
    <sarang> Хорошо, просто хотел прояснить, что может случиться так, что мультиподпись не будут работать на аппаратных кошельках
    <ArticMine> С другой стороны, мы не должны препятствовать реализации данного функционала
    <sarang> Я недостаточно знаю, чтобы сказать что-то наверняка
    <sgp_> достойный компромисс
    <Lyza> Мы просто можем наверстать этот момент в будущем, если на данном этапе появятся проблемы
    <sarang> Обратите внимание, что подход с мультиподписями основан на уже известных методах, но потребует дополнительного изучения и анализа
    <sarang> У меня есть рабочий код на Python
    <sarang> (хочу предупредить, что это не более чем исследовательский вариант реализации данного функционала)
    <sgp_> хорошо, что дальше?
    <ArticMine> Хорошо, будем относиться к нему с должным скептицизмом
    <sarang> https://github.com/SarangNoether/skunkworks/tree/inverse-mpc
    <sarang> ^ это код и описание алгоритма
    <dEBRUYNE> ArticMine: Я думаю, что sarang имеет в виду, что мультиподписи для «обычных» устройств возможны, хоть и более сложные в плане реализации
    <dEBRUYNE> но это исключено в случае аппаратных кошельков (устройств)
    <dEBRUYNE>Ledger и Trezor
    <ArticMine> Я понял, спасибо
    <sarang> Не обязательно исключено... Просто потребуется дополнительная работа
    <sarang> Повторюсь, что у меня нет опыта, чтобы сказать это наверняка
    <ArticMine> Опять же, не все пользователи используют аппаратные кошельки
    <dEBRUYNE> В настоящее время я не вижу какой-то выгоды от использования мультиподписи в аппаратных кошельках
    <dEBRUYNE> ArticMine: Они всегда смогут использовать «стандартный» кошелек Monero <ArticMine> Но, опять же, это моя точка зрения
    <moneromooo> Не думаю, что нам нужно беспокоиться об этом. Просто реализуйте triptych и требуемое программное обеспечение, а уже затем инженеры из ledger/trezor сделают всё, что в их силах
    <sgp_> звучит разумно
    <Lyza> +1
    <sgp_> итак, что нам потребуется для реализации triptych
    <sgp_> что нужно сделать в первую очередь
    <sarang> Провести анализ и прийти к решению о выборе выходных данных и их представлению и пакетированию
    <sarang> Аудит консенсусных частей кода
    <sarang> реализация мультиподписи (по желанию)
    <moneromooo> А как насчёт того, чтобы поговорить с ledger/trezor напрямую, насколько это трудная реализация
    <sgp_> Выбор выходных данных — это область для потенциальных улучшений, верно?
    <ArticMine> А как начёт мульиподписи для стандартных кошельков
    <sarang> Если вы используете большие выходные наборы, использование пакетирования предоставляет много преимуществ
    <sarang> Следует полагать, что вы не хотите делать индивидуальные представления для каждого выхода...
    <dEBRUYNE> sarang: не стоит упускать из виду момент с финансированием данной работы
    <sgp_> sarang: Я рассматриваю выбор выходных данных как побочный проект для оптимизации
    <sgp_> это не столь критично
    <moneromooo> Я был бы заинтересован в частичном кэшировании криптографических операций на этапе пакетирования, чтобы избавиться от константы O(N) на этапе проверки
    <moneromooo> конечно, если это возможно
    <sarang> Зависит от того, как именно вы планируете выполнять пакетирование этих данных
    <sarang> и насколько важно будет использовать выходные наборы между разными доказательствами в одной транзакции
    <sgp_> когда вы говорите «аудит», вы имеете в виду аудит документа или аудит кода? Или оба этих варианта?
    <sarang> Оба
    <sarang> Экспертная оценка в дополнение к академической оценке обеспечивает более высокую уверенность в качестве продукта
    <sarang> Особенно для чего-то нового (как наш вариант)
    <sgp_> код консенсусных частей и выбора выходов — это отдельные области кода, правильно?
    <dEBRUYNE> Мы можем подключить независимую аудиторскую группу
    <sarang> sgp_: наверное :D
    <sgp_> Я думаю, что это очень важная деталь, которую нужно знать :)
    <sarang> Я имею в виду, что в некоторых случаях пакетирование должно иметь элементы, пересекающиеся с общим консенсусом, чтобы избежать проблем с майнерами
    <sgp_> если так, то мы можем начать с именно с этой части кода
    <gingeropolous> есть ли какая-то возможность перехода на triptych с сохранением потенциальной возможности миграции пользователям, у которых уже есть существующая настройка мультиподписи?
    <sarang> gingeropolous: к сожалению, нет
    <sarang> это важный момент в отношении мультиподписей
    <ArticMine> Нам нужно взять в расчёт период для возможности переноса существующих настроек мультиподписей
    <sgp_> Хм
    <sgp_> переход на новую схему не затронет уже существующие кошельки с мультиподписью
    <sgp_> им просто придётся перевести средства на новый кошелек с мультиподписью
    <sarang> все существующие кошельки с мультиподписью продолжат работать
    <dEBRUYNE> Да, это как в случае с переходом к RCT
    <sgp_> О, у меня есть еще один вопрос о совместимости
    <sgp_> Предположим, я сегодня создаю кошелек с мультиподписью и стандартным адресом
    <sgp_> Что будет, если кто-то попытается перевести средства на этот кошелёк после перехода на tripytch
    <sgp_> это будет возможно?
    <sarang> Думаю, что вам нужно, чтобы все стороны использовали для этого надежную итерацию (да, это будет возможно)
    <sarang> Это, скорее, вопрос доверия
    <sarang> Новая итерация с уже несколькими подписями не требует такого доверия
    <sarang> В ближайшее время я займусь проверкой данной мысли
    <ArticMine> Вот именно поэтому я и предлагаю предоставить время для перехода
    <sgp_> предположим, что это кошелек с мультиподписью 2/3
    <sgp_> и вам требуется согласие как минимум двух участников
    <sarang> да, вам нужно всего 2 человека, но они не смогут потратить их(средства?) без доверенной итерации
    <sgp_> ArticMine: это не поможет в ряде случаев
    <sgp_> что за доверенная итерация?
    <sarang> Им нужно будет восстановить приватный ключ таким образом, чтобы они оба знали его
    <sarang> В отличие от ненадежного метода, в котором они не знают долю другой стороны
    <sarang> Это всё из-за операции инверсии, которая является причиной всего этого баловства с несколькими подписями
    <sarang> И от этого никак не избавиться (это присутствует в других конструкциях, таких как Arcturus, RCT3, Omniring)
    <sarang> Это всё из-за того, что им нужно создать образ ключа, который использует именно эту инверсию
    <ArticMine> Итак, вот и нарисовалась первая проблема
    <sgp_> позвольте мне повторить это еще раз, чтобы убедиться, что я всё правильно понимаю
    <sarang> Да, конечно
    <sgp_> чтобы вернуть средства, отправленные в кошелёк с мультиподписью до момента реализации triptych, им потребуется реконструировать приватный ключ таким образом, чтобы все участвующие стороны знали уникальный ключ траты. И уже затем они смогут вывести все средства из этого кошелька
    <sgp_> Если проще, то
    <sarang> Да
    <sgp_> кошелек необходимо «преобразовать» из кошелька с мультиподписью в кошелек без мультиподписи
    <sarang> Это отличная формулировка, да
    <sgp_> Окей, теперь я понял :D
    <sarang> Знаю, что это может быть очень проблематично для ряда пользователей
    <ArticMine> для преобразования требуется аналогичное количество подписей, что и в случае подписи транзакции?
    <ArticMine> Верно?
    <sarang> ArticMine: угу
    <sarang> Я много думал о способах избежать этой инверсии, но для подобных конструкций это довольно сильно завязано на применяемой математике
    <sgp_> думаю, что к этому нужно подходить очень осторожно
    <sgp_> вот почему переходный период не решает данную проблему, ArticMine
    <sgp_> кошельки смогут работать либо с выходами clsag, либо с выходами triptych
    <sgp_> и это «преобразование» необходимо произвести до получения первого выхода triptych
    <sgp_> хотя у меня есть ещё одна идея
    <sgp_> смогут ли clsag кошельки с мультиподписью тратить выходные данные clsag и создавать новые выходы для triptych ненадёжным способом?
    <ArticMine> А что случится, если отправить транзакцию из CLSAG кошелька в кошелёк Triptych?
    <sarang> sgp_: да, смогут
    <sarang> Сама конструкция выходов идентична в обоих случаях
    <sarang> Разница заключается в том, как вычисляются сами образы ключей
    <UkoeHB__> sarang, а на каком этапе в данной схеме (https://github.com/monero-project/research-lab/issues/72) участникам становиться известен приватный ключ?
    <sgp_> отлично, значит, у нас есть резервный вариант, пусть и не самый лучший
    <sgp_> мы можем сделать проверку адреса при отправке и выводить уведомление, что получатель использует устаревшую версию
    <sarang> Прошу прощения, но мне нужно уходить
    <sarang> Эта встреча длилась намного дольше, чем я ожидал
    <u29601mg6ba93j[m> <sarang "Прошу прощения, но мне нужно уходить"> Спасибо за участие!
    <ArticMine> Я предлагаю встретиться через неделю
    <sgp_> да, это было супер
    <gingeropolous> согласен
    <ArticMine> Хорошо, значит на следующей неделе?
    <dEBRUYNE> Да, отлично

    ---

    Источник: IRC #monero-research-lab

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

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