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

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

  1. Unholy

    Unholy Well-Known Monerano

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

    Повестка дня:
    1. Приветствия
    2. Круглый стол
    3. Вопросы
    4. Ключевые моменты
    Журнал встречи:

    <sarang>
    Во-первых, ПРИВЕТСТВИЯ
    <sarang> Привет!
    <ArticMine> Hi
    <Isthmus> Heya
    <UkoeHB_> hi
    TheoStorm вышел (~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl): Причина: Вышел
    <binaryFate>
    hi!
    <sarang> Хорошо, я подожду несколько минут, возможно, что к нам присоединится кто-то ещё
    Insight вышел (sid415968@gateway/web/irccloud.com/x-bbahcfjkmlxlfhtn):
    <sgp_>
    привет
    <sarang> понял, значит, переходим к КРУГЛОМУ СТОЛУ
    <sarang> кто-то хочет поделиться своими исследованиями?
    maxwilliamson вышел (~maxwillia@gateway/tor-sasl/maxwilliamson): Причина: Бездействие в течение 240 секунд
    <xmrmatterbridge><cankerwort>
    Howdy
    <UkoeHB_> https://github.com/monero-project/research-lab/issues/73
    gizmanade подключился (59faaf6b@gateway/web/cgi-irc/kiwiirc.com/ip.89.250.175.107)
    maxwilliamson подключился (~maxwillia@gateway/tor-sasl/maxwilliamson)
    <UkoeHB_>
    для темы исследования это, конечно, слишком круто, но есть очень интересная идея
    <sarang> получатель легко может «потерять» свою часть расходуемых средств, особенно если ключевые значения были неправильно сформулированы на стороне отправителя
    <binaryFate> есть ли какая-то потенциальная проблема, если отправитель играет «не по правилам» (намеренно ломает текущую схему), но потенциально может доказать, что отправил что-то на адрес получателя?
    <UkoeHB_> это можно отнести и к публичным ключам транзакции
    <Isthmus> Если отправитель не следует правилам, получатель не увидит сообщение о получении средств
    <Isthmus> как вариант, они могут попросить отправителя сделать транзакцию действующей
    <sarang> угу
    <Isthmus> и получается, что отправитель создал неприятный прецедент только самому себе
    <sarang> как в случае, когда отправитель пользуется некорректным обязательством
    <sarang> (за исключением свойств возможной траты)
    TheoStorm подлючился (~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl)
    <UkoeHB_>
    Да и вообще, если кошелек не предоставляет теги просмотра корректно, то зачем вообще нужен такой кошелек?
    <Isthmus> Бинго!
    <UkoeHB_> как минимум, такой продукт требует патча
    <xmrmatterbridge><cankerwort> это будет что-то по типу «быстрое сканирование»? если отправитель испортил его каким-то образом, оно все равно будет отображаться при обычном сканировании?
    <sarang> да
    <binaryFate> они могут воспользоваться этим и составить обращение в службу поддержки биржи
    gizmanade вышел (59faaf6b@gateway/web/cgi-irc/kiwiirc.com/ip.89.250.175.107):
    gizmanade подключился (59faaf6b@gateway/web/cgi-irc/kiwiirc.com/ip.89.250.175.107)
    <binaryFate>
    и это повредит Monero намного сильнее, чем принесет финансовый ущерб обменникам и биржам
    <UkoeHB_> как по мне, нужно иметь возможность сменить быструю/нормальную дифференцировку сканирования; да и сама техника очень простая в плане реализации
    <sarang> в кошельке должна быть опция, которая отключает данный метод сканирования
    <selsta> Как быстрое сканирование работает вместе с Supercop EC ASM? ASM добавит какое-то существенное ускорение для процесса сканирования?
    <binaryFate> здесь нужен взвешенный выбор или разумный компромисс
    <Isthmus> Ускорение скорости колоссально, если вы просто сканируете 1-2 адреса, то возможно, что разница не будет такой уж и большой, но что если у вас 20000 таких транзакций?
    <UkoeHB_> Всё равно не особо представляю, как это может дать настолько большой прирост скорости
    <Isthmus> извините! Ошибся! *1-2 транзакции
    <UkoeHB_> в смысле ускорение
    <UkoeHB_> если каким-то образом у вас есть контроль над ~80% транзакций, то да, тег view поможет вам только в том случае, если (255/256)*.2
    <xmrmatterbridge><cankerwort> сканирование будет учитывать 1/256 всех транзакций + (релевантные транзакции – перекрытие)
    <UkoeHB_> все верно
    <UkoeHB_> «сканирование» подразумевает, что вы будете выполнять еще и другие операций
    <UkoeHB_> на выход
    <UkoeHB_> так что будет правильнее считать 1/256 на выход, а не на транзакцию
    asdc_ccc подключился (~asdc_cccc@95-178-173-249.dsl.optinet.hr)
    <Isthmus>
    понял, спасибо
    <TheCharlatan> почему только один байт? два байта слишком показательный пример?
    <UkoeHB_> это убывающая отдача
    <UkoeHB_> изменение алгоритма сканирования на 1 или 2 байта в ключе тега view является весьма крошечным изменением
    <sarang> окей, запишу себе
    <sarang> Какие-то конкретные вопросы или идеи?
    <UkoeHB_> или возражения
    <Isthmus> а вот мне всё понравилось
    <TheCharlatan> Да :)
    <Isthmus> Надеюсь, что это уменьшит количество сообщений "Y MONERO SO SLO TO SYNC" (ВАШ MONERO СИНХРОНИЗИРУЕТСЯ, КАК СЛОУПОК...) в reddit канале на 1/256
    <UkoeHB_> да, мечтать не вредно
    sech11 подключился (~sech1@31-208-56-185.cust.bredband2.com)
    <xmrmatterbridge><cankerwort>
    думаю, что самое лучше время для таких обновлений — в момент очередного форка
    <binaryFate> как бы это странно не звучало, но вы чертовски правы
    <sarang> получается, что на текущий момент у вас нет четкого понимания, как лучше всего выстроить первую линию обороны
    <xmrmatterbridge><cankerwort> а что насчет сокращения размеров транзакций в тех случаях, где будет постепенно увеличиваться размер колец?
    <sarang> в настоящее время нет конкретного плана по увеличению размера кольца, особенно для CLSAG
    <sarang> обратите внимание, что переход от MLSAG к CLSAG уменьшит размер стандартной транзакции 2-2 с 2,5 кБ до 1,9 кБ.
    <sarang> (при отсутствии дополнительного слоя проверок)
    <UkoeHB_> а мне кажется, что такое обсуждение атаки Януса и поля extra внесло немного ясности
    <sarang> конечно, даже небольшой прогресс это тоже прогресс
    <sarang> :D
    sech1 вышел (~sech1@31-208-56-185.cust.bredband2.com): Причина: Бездействие в течение 240 секунд
    <sarang>
    UkoeHB_, у вас есть еще темы для обсуждения?
    <UkoeHB_> не думаю, спасибо, Саранг
    <sarang> ОК, спасибо, UkoeHB_
    <sarang> кто-нибудь еще хочет поделиться интересными исследованиями?
    <sarang> если нет, у меня есть пара вещей, которые стоит обсудить
    <Isthmus> я сейчас работаю над созданием графовой формализации ошибок взаимозаменяемости. Уже достигнут небольшой прогресс, по сравнению с прошлой неделей, но он все еще не совсем соответствует всем нашим принципам последовательности. Тяжело работать, когда ты настолько самокритичен к своей работе...
    <Isthmus> и еще я готовлю совместный проект с Insight. Один из стипендиатов подготовил патч для предотвращения излишнего перераспределения монетной базы. Сейчас это особенно полезно, когда мы используем множество дискретных выходов. Когда он закончит правки кода, я перепроверю его код еще раз и отправлю на рассмотрение / обзор
    <Isthmus> я хочу, чтобы как можно больше инженеров Insight работали в нашей экосистеме! Insight потратили кучу времени и ресурсов на исследования и различную помощь таким проектам, как Polkadot, ICON, Zcash и т. д., а еще я хочу привлечь свою команду к работе и попытаться внести хоть какой-то вклад в сообщество Monero
    <Isthmus> надеюсь, что через неделю я смогу представить нашему коллективу несколько новых участников из числа наших стипендиатов
    <sarang> это отлично!
    <Isthmus> в ближайшее время я все непременно расскажу и покажу вам
    <sarang> стипендиаты в каких областях?
    <Isthmus> у меня еще предстоит встреча со всеми потенциальными участниками, я хочу поговорить с кажлдым лично
    <sarang> а, понял тебя
    Isthmus возвращает микрофон Сарангу
    <xmrmatterbridge><cankerwort>
    а теперь позвольте мне откланяться и выяснить, что это вообще такое, я о Polkadot и ICON
    <sarang> Спасибо, Isthmus
    <sarang> Этот PR с увеличением скорости работы Bulletproofs уже готов к объединению: https://github.com/monero-project/monero/pull/6451
    <sarang> его нужно будет использовать «задним числом»
    <sarang> экономия составит порядка 25% для схемы с 2 выходными доказательствами
    <sarang> не стесняйтесь и присоединяйтесь к обзору
    <ArticMine> Превосходно
    <xmrmatterbridge><cankerwort> Фантастические новости
    binaryFate аплодирует
    <sarang>
    Во-вторых, я много работал над кодовой реализацией Triptych для более точных и детальных модульных тестов
    <sarang> соответствующая ветка: https://github.com/SarangNoether/monero/tree/triptych
    <sarang> (обратите внимание, что этот код не закончен и не должен использоваться в реальных условиях)
    <sarang> пример с изменением размеров: https://usercontent.irccloud-cdn.com/file/KvolrThG/size.png
    <xmrmatterbridge><cankerwort> Triptych = Triptych 2? Одна версия вытеснила другую или как?
    <sarang> сравнение времени проверки: https://usercontent.irccloud-cdn.com/file/4CATnXf6/timing.png
    <sarang> Triptych требует отдельных доказательств на вход (так же, как и MLSAG / CLSAG)
    <sarang> временной график использует данные теста производительности из ветки выше
    <sarang> серые линии центрированы в точке 11-MLSAG (для большей наглядности)
    <sarang> данные о синхронизации *не включают* себя некоторые незавершенные варианты оптимизаций (пакетирование и общие входные данные о наборах одних и тех же транзакций)
    <sarang> тем не менее это уже сейчас дает представление о том, как MLSAG, CLSAG и Triptych работают и насколько существенна между ними разница
    <Isthmus> здорово
    <TheCharlatan> а что за пересечение серой линии со значением оси x на линии Triptych?
    <sarang> вертикальная серая линия обозначает кольца с размером 11 для всех конструкций
    <sarang> горизонтальная линия - это размер / время для MLSAG при размере кольца 11
    <sarang> (но, опять же, это все для наглядности)
    <sarang> и как минимум должно помочь в наглядном сравнении
    <ArticMine> какое это окажет влияние на размер транзакций?
    <sarang> каждый вход транзакции (именно вход, а не элемент вызова или уже потраченный вход) требует одной подписи, и не важно, какой конструкцией вы пользуетесь
    <sarang> переход от 11-MLSAG к ~ 32-Triptych не приведет к изменению размера подписи
    <sarang> но поспособствует более быстрой проверке
    <binaryFate> действительно впечатляет
    <xmrmatterbridge><cankerwort> Это потрясающие улучшения! Но насколько я понял, мы рассматриваем возможность реализации не только Triptych, верно?
    <sarang> имеющиеся данные о размере являются окончательными
    <sarang> Triptych (и все другие конструкции следующего поколения) требуют надлежащей модификации образов ключей, которые, в свою очередь, требуют новых инженерных исследований в области multisig
    <sarang> что весьма нетривиально
    <derpy_bridge><[keybase] seddd>: извините, что так поздно, я как раз заканчиваю обзор документа CLSAG, и отправлю свои результаты проверки Сарангу, как только закончу, а так больше ничего нового нет :)
    <sarang> Спасибо, seddd, очень ценю
    <xmrmatterbridge><cankerwort> seddd = surae?
    <derpy_bridge> <[keybase] seddd>: +1
    <derpy_bridge> <[keybase] seddd>: отнюдь нет, cankerwort
    <sarang> и еще ledger/trezor уже заканчивают работу над реализацией поддержки CLSAG
    <derpy_bridge> <[keybase] seddd>: (surae намного умнее)
    <sarang> cslashm сделал PR, который будет включен в тестовую ветку
    <sarang> и еще Ledger готовят PR для добавления поддержки их новой прошивки
    <xmrmatterbridge><cankerwort> Приятно слышать, что аппаратные кошельки весьма активны в плане работы, а не как биржи и сервисы в недавнем сценарии с переходом на подадреса
    <derpy_bridge> <[keybase] seddd>: да, я еще не проверил все изменения от ledger, да и до PR от cslashm еще не добрался
    <sarang> да, вы правы, очень приятно, что ledger/trezor так быстро отреагировали
    <sarang> да и сама идея заключалась в том, чтобы управиться до обновления сети
    <sgp_> действительно классные цифры
    <sarang> вот так и выглядит мой отчет: ускорение BP, новые данные Triptych, CLSAG для аппаратных устройств
    <sarang> есть еще вопросы на представленные мной темы?
    <sgp_> Числа *весьма* похожи на Arcturus?
    <sgp_> в смысле единственные различия, это пакетные данные
    <xmrmatterbridge><cankerwort> кто такой Arcturus?
    <sarang> это я переименовал Triptych-2, чтобы уменьшить путаницу, да и работает он совсем по-другому
    <sarang> и меня ужасно раздражало его название - Triptych-2
    <xmrmatterbridge><cankerwort> Понял и простил
    <sarang> у меня вообще проблема с придумыванием названий :/
    <sarang> в любом случае, чтобы ответить на вопрос sgp_
    <sarang> в Arcturus реализовано лучшее масштабирование размеров
    <sarang> да и время проверки будет весьма близко к значениям Triptych
    <sgp_> да, мне тоже нравятся имеющиеся цифры
    <ArticMine> все, что получается уменьшить в размерах, автоматически становится лучше
    <sarang> в Arcturus вам нужно только одно доказательство / подпись на каждую транзакцию, а не на каждый вход, как обычно
    <Isthmus> ВоооООооОУ!
    <sarang> *Магия* повторного использования генератора подразумевает, что проверка будет аналогичной (если вы используете для сравнения общие наборы анонимности с Triptych)
    <sarang> (именно из-за этого я и переименовал его)
    <sarang> тем не менее имейте в виду, что Arcturus полагается на нестандартное допущение твердости
    <ArticMine> есть ли недостатки?
    <sarang> ^^
    <xmrmatterbridge><cankerwort> Планируется ли дополнительная проверка или аудит CLSAG? Насколько я понял, он будет добавлен в следующий хардфорк?
    <sarang> это только мое понимание и видение
    <sarang> (но это не мое решение)
    <binaryFate> Саранг, что ты думаешь по поводу того, как решить проблему multisig без использования примитивов?
    <sarang> Насколько я знаю, нам нужна поддержка общих групп RSA для правильной конструкции multisig следующего поколения
    <sarang> только в плане подписи, а не проверки
    <sarang> (несмотря на то, что это группы RSA, проблем с доверенными настройками нет)
    <binaryFate> вы уверены, что это именно требование, а не просто отсутствие альтернативы, как обойтись без них?
    <UkoeHB_> О! Я сделал небольшую рецензию в теме multisig: https://github.com/monero-project/research-lab/issues/72
    <sarang> ну, в любом случае мы должны использовать гомоморфную схему с открытым ключом, которая может использовать произвольные группы простого порядка
    <sarang> это ссылки на код и описание, которое я разработал
    <UkoeHB_> верно ^
    <sarang> Paillier шифрование, как оказалось, не требуется
    <sarang> но вам обязательно понадобиться аддитивно-гомоморфная схема
    derpy_bridge вышел (~derpy_bri@92.223.89.201): Причина: Удаленный хост разорвал подключение
    <sarang>
    во всяком случае, я и так занял много времени на этой встрече
    <sarang> что у вас было интересного и чем бы вы хотели поделиться?
    derpy_bridge подключился (~derpy_bri@92.223.89.201)
    <TheCharlatan>
    Я сделал Rust PoC для добавления времени блокировки и обязательств в транзакции. PoC создает транзакции и проверяет их с помощью подписи CLSAG и механизма времени блокировки, как описано в схеме DLSAG. К дополнительным требованиям относятся: обязательство входа и выхода, вспомогательное (фиктивное) время блокировки открытого текста, образ времени блокировки и подтверждение диапазона
    <TheCharlatan> и увеличение размера подписи, вопреки *слепому* описанию времени блокировки в DLSAG. Также я думаю, мы можем сэкономить на проверке диапазона времени блокировки выходных данных транзакции, следовательно, основной компонент является дополнительным доказательством диапазона. Еще у меня состоялась дискуссия об объединении доказательства диапазона и времени блокировки во всех входных данных транзакции, с тем отличием, что здесь потребуется подтверждение диапазона суммы в выходных данных
    <TheCharlatan> и еще суть совета от Саранга заключается в том, что в транзакциях с большим количеством выходов и входных данных проверка совокупного диапазона будет непомерно медленной
    <derpy_bridge><[keybase] seddd>: о как, отличные новости!
    <sarang> TheCharlatan: что, в свою очередь, добавит 32 байта на подпись
    <sarang> из-за использования дополнительного тега с описанием ссылки
    <TheCharlatan> Блин! Точно! Я не включил теги в описание :p
    <sarang> 32 байта весьма достойный показатель
    <sarang> и учтите тот факт, что основной ущерб в этом случае возьмет на себя время проверки
    <sarang> у меня даже есть тестовая ветка CLSAG, которая показывает разницу
    <sarang> (но, к сожалению, я не помню цифр тестов)
    <sarang> TheCharlatan: Ваш код общедоступный?
    <TheCharlatan> Да: https://github.com/TheCharlatan/rs-xmr-cryp/tree/master/timelock
    <sarang> и еще обратите внимание, что Triptych может быть легко расширен для добавления поддержки конструкций по типу d-LRS, как в CLSAG
    <sarang> отлично, спасибо!
    <derpy_bridge><[keybase] seddd>: TheCharlatan: это потрясающе! В эту субботу я тоже собирался переносить код CLSAG в Rust
    <sarang> есть еще одна реализация CLSAG в rust
    <sarang> https://github.com/crate-crypto
    <derpy_bridge><[keybase] seddd>: так мило! спасибо, Саранг :)
    <sarang> (но я не говорил вам про это)
    <derpy_bridge><[keybase] seddd>: конечно, спасибо за ссылку :)
    <TheCharlatan> Реализация crate-crypto выглядит намного приятнее
    <sarang> TheCharlatan: что в данный момент нам было бы полезнее всего от этой рабочей группы?
    <TheCharlatan> я не вижу кода проверки для bulletproof. Мне нужно пересмотреть всё это еще раз
    <sarang> Хорошо, отлично, рад был помочь
    <sarang> (вероятно, что лучше всего обсудить дополнительные моменты после окончания официальной части встречи)
    <TheCharlatan> да :)
    <sarang> Спасибо, TheCharlatan
    <sarang> ОКей, мы только что прошли часовую отметку
    <sarang> Давайте перейдем к КЛЮЧЕВЫМ МОМЕНТАМ
    <sarang> над чем участники нашей группы планируют работать на этой неделе?
    <sarang> я планирую завершить финальные штрихи для оптимизации кода Triptych
    <sarang> и интеграцию кода CLSAG для аппаратных устройств
    <sarang> прочие участники?
    <UkoeHB_> Я думаю, что займусь кратким изложением принципов атаки Януса c тегом view и полем extra, ну и, кончено же, обновлением пакетирования
    <UkoeHB_> в общем обновлением информации
    <derpy_bridge><[keybase] seddd>: а я займусь завершением аудита CLSAG и подготовлю соответствующий отчет
    <sarang> отличные планы
    <derpy_bridge> <[keybase] seddd>: _уступает слово UkoeHB__
    <sarang> Какие-нибудь заключительные вопросы или комментарии перед тем, как мы закончим?
    <UkoeHB_> ArticMine: кстати, что с вашим предложением?
    <binaryFate> блин! так много всего крутого и интересного! прямо как подарок на рождество!
    <asdc_ccc> ^
    <ArticMine> я все еще работаю над описанием платной части
    <sarang> Хорошо, мы заканчиваем! Спасибо всем за участие!
    <sarang> Журнал будет опубликован в ближайшее время
    <sarang> Обсуждения могут продолжаться :)

    Источник: Research meeting: 15 April 2020 @ 17:00 UTC #454

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

    Kukima (@Kukima)
     
  • О нас

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