Когда: Среда, 15 апреля 2020 г., 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты Журнал встречи: <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> ⇐ 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> Блин! Точно! Я не включил теги в описание <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)
