Когда: понедельник, 29 июля 2019 @ 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол a. Sarang: прототип RCT3, обновление библиотек b. Surae c. Прочие участники? Вопросы Ключевые моменты a. Sarang: прототип RCT3, разделение доказательства Omniring b. Surae c. Прочие участники? <sarang> Хорошо, давайте начнем <sarang> Всем привет! <sarang> Журнал этой встречи будет опубликован в повестке дня на GitHub. <sarang> ПРИВЕТСТВИЯ <suraeNoether> приветствия! <kenshamir[m]> hey <sarang> Упс, вот текущая повестка дня: https://github.com/monero-project/meta/issues/377 *Саранг сменил тему на встреча исследовательской лаборатории по понедельникам @ 17: 00 UTC: https://github.com/monero-project/meta/issues/377. Будьте добры друг к другу. ⇐ Common-Deer вышел (~CommonDee@14-202-132-82.static.tpgi.com.au): Ошибка: Соединение прервано → Common-Deer подключился (~CommonDee@14-202-132-82.static.tpgi.com.au) <sarang> Давайте сразу перейдём к КРУГЛОМУ СТОЛУ <sarang> Я в поте лица работал над реализацией RCT3, занимался интеграцией оптимизаций и пытался выяснить, возможно ли заставить образы ключей работать так, как нам необходимо <sarang> Это привело к ряду обновлений библиотек, на которые опирается код <sarang> Если обобщить — просто много работы с кодом <sarang> Я также выступил с забавной лекцией о шифровальной машине Enigma и математике, что стоит за ней. Было весело <suraeNoether> отлично, только зачем? встреча или какое-то спонтанное выступление? <sarang> Мой друг преподает в университете и подумал, что это будет хорошая тема для его крипто-класса <suraeNoether> Здорово <sarang> В ближайшее время, я хочу закончить интеграцию оптимизации внутреннего верификатора BP в RCT3 <sarang> И конечно же DEF CON! <suraeNoether> neat <suraeNoether> у меня на компьютере есть хаотично-тестовая ветка с моими симуляциями и экспериментами, над которыми я сейчас работаю <sarang> И как идут дела? <hyc> defcon — кто-нибудь уже получил репеллент кузнечика? <sarang> -____- <suraeNoether> ну, я доказал все теоремы, которые необходимы для доказательства того, что алгоритм в graphtheory.py делает то, что я пытаюсь доказать, и еще — в настоящее время я проверяю, что мои смоделированные гроссбух делают всё правильно <sarang> звучит здорово <sarang> Нужно сделать всё предельно аккуратно, чтобы получить результаты и увидеть, если / как они могут работать с таким анализом, что Isthmus и другие участники как раз и делают в Monero и Zcash <suraeNoether> в дополнение к этому у меня есть куча МАГИЧЕСКИХ задач, которые мне нужно сделать, и еще мои дискуссии о цифровой судебно-медицинской экспертизе с Isthmus не стоят на месте <suraeNoether> думаю, что содержание этого проекта может занять более двух статей: <sarang> Блин, здорово! <sarang> Также стоит отметить, что документ CLSAG был обновлен на IACR в основном благодаря комментариям и вопросам от kenshamir[m] <sarang> kenshamir[m] также работает над реализацией CLSAG / MLSAG в Rust с использованием библиотеки dalek → thrmo подключился (~thrmo@unaffiliated/thrmo) <suraeNoether> hyc: я слышал, что кузнечики очень вкусные, и мне интересно, вдруг какой-нибудь из этих модных ресторанов в Вегасе со звездами Мишлен может извлечь выгоду из этого <sarang> Чем бы ты хотел поделиться с нами, kenshamir[m]? <kenshamir[m]> Привет, библиотека закончена, но еще не совместима с Monero, потому что она использует другую кривую. Цифры довольно впечатляющие, и я считаю, что это связано с тем, как был создан CLSAG → sfhi2 подключился (~sfhi@37.252.225.109) <sarang> Ой блин <sarang> Будет здорово увидеть ваш анализ MLSAG и CLSAG на разных размерах колец <sarang> Я поднял этот вопрос несколько дней назад, потому что мы по-разному обрабатываем разные размеры линейных комбинаций в кодовой базе <scoobybejesus> этот код для Rust находиться в публичном репозитории? <sarang> Мы используем не менее 4 методов <kenshamir[m]> Эти данные для разных размеров кольца, возможно, я случайно ошибся в размерах ключей <kenshamir[m]> 256 и 512 были выбраны для приманки; если вдруг я непонятно истолковал <sarang> Причина, по которой проверка CLSAG занимает меньше времени, чем MLSAG, заключается в добавлении нового алгоритма оценки линейных комбинаций <sarang> kenshamir[m]: можете поделиться ссылкой для журнала встречи? <sarang> (если вам удобно выкладывать их в публичный доступ) <kenshamir[m]> <scoobybejesus "этот код для Rust находиться в публичном репозитории?"> Нет, как только я добавлю документацию и перепроверю код, я могу опубликовать все ссылки здесь <sarang> спасибо <kenshamir[m]> <sarang "kenshamir: можете поделиться ссылкой для журнала встречи?"> Да, конечно <scoobybejesus> — kenshamir[m] собирается отправить очень длинное сообщение: < https://matrix.org/_matrix/media/v1/download/matrix.org/qyxFtJuthDFQlLNsQifQmhnr > — kenshamir[m] всё-таки допечатал и отправил это сообщение: < https://matrix.org/_matrix/media/v1/download/matrix.org/DuHfhNbuqOFRLjbkIaQdIXlA > ⇐ thrmo вышел (~thrmo@unaffiliated/thrmo): Причина: бездействие в течение 272 секунд → thrmo подключился (~thrmo@unaffiliated/thrmo) — kenshamir[m] собирается отправить очень длинное сообщение: < https://matrix.org/_matrix/media/v1/download/matrix.org/nwVabRjaqUnwjXywxfnikxtC > <sarang> Что значит «без Pippenger/Straus»? Простая итеративная оценка линейных комбинаций? ⇐ sfhi вышел (~sfhi@37.252.225.109): Причина: бездействие в течение 272 секунд <kenshamir[m]> Да, всё верно <sarang> Впечатляющие показатели <sarang> Конечно, ведь это другая хеш-функция <kenshamir[m]> Я только что сделал скалярную функцию в цикле <kenshamir[m]> ахаха, да, это тоже <suraeNoether> хмммммммм <sarang> Но если хеш-функция одинакова для обеих вариантов CLSAG / MLSAG, то получившиеся числа действительно хороши <suraeNoether> что-то, что быстрее и меньше с аналогичной схемой безопасности, и будет проблемой для дальнейшей реализации (в ожидании аудита) <sarang> кстати, я все еще общаюсь с потенциальными аудиторами, которые оказались очень тяжелыми на подъем <sarang> в смысле у меня нет вестей с этого фронта :/ <suraeNoether> изменение пространства позволяет логарифмически увеличить время проверки без фактического замедления сети (по крайней мере когда речь заходит о новых узлах). Если опираться на эти цифры — кольца размером ~ 16 / 32 больше не похожи на попытки заливки в сеть мелассы / бетона <sarang> Хорошо, есть еще какие-нибудь интересные исследования? <gingeropolous> Re: ревизии или развертывание в целом. Это та вещь, которую можно развернуть параллельно с существующей? То есть иметь перекрытие, при котором сеть использует существующее в качестве основного / по умолчанию, но при желании может использовать новое, а затем, после проверки нового, просто удалить старое? <hyc> ^ медленные аудиторы? Нужно полагать, что много людей сейчас на летнем отдыхе <gingeropolous> или переключиться на новый и больше ретранслировать / проверять старый стиль во время перекрытия? <suraeNoether> sarang: я ошибаюсь, говоря gingeropolous, что это правильно, в смысле, что clsag может быть реализован параллельно, до того как mlsag устареет? <hyc> у нас было 24-часовое перекрытие при последнем хардфорке для таких вещей <gingeropolous> всё было бы немного по-другому. <sarang> Я полагаю, что это может работать, если модель оплаты поддерживает это ⇐ thrmo вышел (~thrmo@unaffiliated/thrmo): Причина: бездействие в течение 244 секунд <sarang> Я действительно не понимаю, почему это полезно ⇐ crCr62U0 вышел (~crCr62U0@gateway/tor-sasl/crcr62u0): Причина: бездействие в течение 260 секунд <gingeropolous> я не знаю, просто завожу разговор о том, что все новые технологии должны быть проверены <gingeropolous> я имею в виду, что очевидный аудит – это здорово <sarang> конечно <gingeropolous> это не панацея <dEBRUYNE> hyc: Да, летний период – это очень низкая активность <sarang> Это в любом случае хорошо, а также помогает найти возможные ошибки <kenshamir[m]> Может ли Monero извлечь выгоду из использования BP арифметических схем? <dEBRUYNE> gingeropolous: Разве мы не обсуждали такую модель для Bulletproofs или RingCT немногим ранее? <sarang> Скорее всего, нет, тем более с нашей текущей моделью транзакций <gingeropolous> угу, dEBRUYNE <sarang> Масштабирование не такое большое <dEBRUYNE> Я думаю, что мы не смогли прийти к консенсусу по уважительным причинам, но я не помню их :-Р <gingeropolous> я думаю, что это было после аудита <sarang> и у нас есть хэш-функции, которые *портят* часть нашего функционала <sarang> У Zooko был слайд в какой-то из его презентаций, где его команда оценила время проверки схемы со сложностью Sapling (Sprout? Не помню точно) <sarang> и проверка BP была O(1 сек) <sarang> По сравнению с нашим текущим временем проверки, которое, вероятно, составляет 1/50 от этого <sarang> или даже 1/100 <kenshamir[m]> Хлоп <suraeNoether> kenshamir: если бы мы разработали арифметическую схему для описания RingCT транзакций, тогда да, но это то, что пытаются сделать RCT3, omniring и lelantus ... sarang, я думаю, что zooko имели в виду, как это будет выглядеть для транзакций Sapling, язык должен быть проверен в надстройке BP <suraeNoether> без настройки <suraeNoether> за исключением нашей не-AC-совместимой хэш-функции → thrmo подключился (~thrmo@unaffiliated/thrmo) <dEBRUYNE> sarang: Это время проверки для полностью экранированных транзакций? <suraeNoether> dEBRUYNE, да <dEBRUYNE> Отличненько! <sarang> Да, время нужно для того, чтобы показать пример, как может выглядеть схема передачи транзакций промышленного размера <dEBRUYNE> Особенно учитывая, что вам нужно запустить полный узел, чтобы правильно выполнять экранированные транзакции <dEBRUYNE> В любом случае я отвлекся <sarang> В любом случае suraeNoether прав в том, что RCT3 и Omniring пытаются донести преимущества BP до конкретных языков, используемых для доказательства операторов RingCT. <sarang> вот почему мы так заинтересованы в них <suraeNoether> да, использование bp для SNARK - это как... хм... установка турбовентиляторного двигателя большого диаметра в Mini Cooper. Он в любом случае не будет делать то, что вы задумали, но работать это будет <sarang> BP может быть гораздо более эффективным для языков, которые изначально ориентированы на его использование <sarang> вот почему доказательства диапазона настолько эффективны <kenshamir[m]> ахахах <suraeNoether> действительно <suraeNoether> двигаемся дальше → JOhNKmus подключился (JOhNKmus@gateway/vpn/privateinternetaccess/johnkmus) <sarang> хех <sarang> хорошо, другие исследования? <sarang> Или ВОПРОСЫ по нашей повестке дня? <sarang> Ладно! Переходим к КЛЮЧЕВЫМ МОМЕНТАМ <sarang> Я буду дорабатывать некоторые моменты для своего предстоящего выступления, семинара и лекции DEF CON; и также планирую завершить оптимизацию интеграции RCT3 <sarang> suraeNoether: ? → antanst0673803 подключился (~antanst@62.169.219.213) <suraeNoether> о, черт возьми <suraeNoether> оу! я задумался о числах, извините <sarang> твоё число 7 ⇐ antanst067380 вышел (~antanst@62.169.219.213): Причина: бездействие в течение 272 секунд <suraeNoether> мои ключевые моменты: работа над симуляциями и экспериментатором, работа с isthmus для формализации статистических гипотез для проверки всего этого <sarang> Наличие данных из группы Isthmus будет чрезвычайно ценным для такого анализа <suraeNoether> на самом деле это число равно O(153.58*N), которое представляет собой количество битов, используемых для описания количества возможных историй расходов при размере кольца 32 с N выходами <suraeNoether> вот такие орехи <sarang> Это все при условии отсутствия внешних источников информации? <sarang> Или другая графовая информация о цепных реакциях и потраченных выходах? <suraeNoether> просто общее количество согласованных историй трат <sarang> хорошо, для гипотетического графика <suraeNoether> угу <sarang> понял → crCr62U0 подключился (~crCr62U0@gateway/tor-sasl/crcr62u0) <gingeropolous> O (153,58 * N)... отлично, теперь твоя математика еще больше похожа на математику <suraeNoether> это означает, что для 1000 транзакций при размере кольца 32 существует 2 ^ (153 580) возможных трат <suraeNoether> в любом случае <suraeNoether> (N должно быть намного больше, чем размер кольца для приведенной выше формулы) <sarang> вполне разумно <sarang> Какие-нибудь другие заключительные мысли или вопросы, прежде чем мы закончим? <sarang> Хорошо! Спасибо всем за участие! На сегодня мы закончили! Источник: Research meeting: 29 July 2019 @ 17:00 UTC #377 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
