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

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

  1. Unholy

    Unholy Well-Known Monerano

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

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

    <sarang> Во-первых, ПРИВЕТСТВИЯ
    <sarang> hi
    sarang ждет несколько минут, возможно, что появиться кто-то ещё
    <sgp_>
    Привет
    <moneromooo> .time localtime
    <monerobux> Не удалось найти часовой пояс для localtime
    <sgp_> .time cdt
    <monerobux> Не удалось найти часовой пояс для cdt.
    atoc подключился (2fb9d2fc@47.185.210.252)
    <Isthmus>
    Первый пункт повестки дня - троллинг monerobux бота
    <sarang> естественно
    <sarang> что ж, давайте перейдем к нашему КРУГЛОМУ СТОЛУ
    <atoc> оххх
    <ArticMine> Hi
    <sarang> Предполагаю, что Isthmus есть чем с нами поделиться, он разместил свои материалы в повестке дня
    <sarang> https://github.com/monero-project/meta/issues/456
    <sarang> а если более точно: https://github.com/monero-project/meta/issues/456#issuecomment-617883059
    <Isthmus> Конечно
    <sarang> Действуйте!
    <UkoeHB_> hi
    <Isthmus> Только что завершилось моё исследование, в котором количественно оценивалось влияние волатильности обменного курса на отсроченные выплаты в Monero
    <Isthmus> я считаю, что курс Monero выходит за рамки работы MRL, но это относится ко всем вкладчикам, которые финансируют в CCS
    <Isthmus> хм, я хотел вырезать и вставить текст из GitHub, но он всё еще слишком длинный для IRC
    <Isthmus> по сути, я собрал статистический анализ скользящих временных окон цены XMR, чтобы создать основу для формулы управления риском волатильности
    <Isthmus> здесь должно было быть много слов, но будет только их малая часть:
    <Isthmus> [INPUTS:] X% уверенности в том, что выплата за Y-месяц покроет котировку (на основе данных за последние Z-месяцы), может быть достигнута с помощью формулы [OUTPUT:] V% волатильности.
    <Isthmus> предположим, что мы хотим посмотреть данные за последние 24 месяца
    <Isthmus> рассмотрим в качестве примера 4-месячное окно (1 месяц для сбора средств CCS + 3 месяца для выплат)
    <Isthmus> Вот результаты, основанные на исторических данных
    <Isthmus> https://usercontent.irccloud-cdn.com/file/tbl4tkZn/image.png
    <Isthmus> например, за последние два года мы наблюдаем неблагоприятную асимметрию: участники проектов с 4-x месячным графиком больше других подвержены снижению величины выплат более чем в два раза (красная линия), нежели увеличение ~50% (зеленая линия).
    <sarang> Вот такая асимметрия...
    <Isthmus> Это была функция распределения вероятностей, у меня также есть и накопительная версия
    <Isthmus> https://usercontent.irccloud-cdn.com/file/2UBTfPI7/image.png
    <Isthmus> красный крестик подчеркивает, что курс USD / XMR снизился более чем на 65% для всех 4-месячных окон (то есть только 35% спонсоров получили бы выплаты, равные цене котировки). Оранжевый крестик показывает, что 80% вероятность получить достаточный уровень выплат будет достигнута только с использованием буфера в +35%.
    <Isthmus> объяснение оранжевого крестика: 80% уверенность, что 4-месячная выплата покроет котировку (на основе данных за последние 24 месяца), может быть достигнута с помощью буфера волатильности 35%.
    <Isthmus> теперь давайте рассмотрим, что произойдет, если мы удвоим временной график (чтобы новые данные включали бычий рынок)... Предыдущие графики охватывали только последние 2 года (синие точки); и теперь давайте перенесём все это на 4-летний графике (синие и зеленые точки).
    <Isthmus> https://usercontent.irccloud-cdn.com/file/aCapoFx3/image.png
    <Isthmus> упс, там получился прозрачный фон, извините
    <Isthmus> теперь, когда мы учитываем бычий рынок, чье движение приближается к максимальному показателю за все время, так и последующему затуханию. Расширенный набор данных содержит новые результаты безубыточности с обеих сторон от красной линии (+ несколько выбросов, опущенных на этом графике, которые показаны на следующем).
    <Isthmus> https://usercontent.irccloud-cdn.com/file/kiCGTbDh/image.png
    <Isthmus> за 4-летнюю историю мы видим, что-то около 60%, что приводит нас к возрастанию буфера до 170% (оранжевый крест).
    <Isthmus> https://usercontent.irccloud-cdn.com/file/le8lMFik/image.png
    <Isthmus> я надеюсь, что наличие такой структуры управления рисками волатильности сможет повысить доступность финансирования для людей и организаций, которые хотят внести свой вклад, но не могут позволить себе спекулировать на падениях и взлётах рынка
    Isthmus заканчивает своё эссе
    <sarang>
    Это отличные данные
    <sarang> вопросы для Isthmus?
    <sgp_> Волатильность всем нам обходится очень дорого...
    <sgp_> у меня нет вопросов, спасибо за данные
    <Isthmus> вам спасибо :)
    <sarang> Хорошо, если у вас нет вопросов для Isthmus, тогда позвольте мне перехватить микрофон
    <ArticMine> у меня одно примечание!
    <ArticMine> Большое спасибо вам за эту работу! Все
    <atoc> вопрос для прояснения ситуации: как обстоят дела с задержкой выплат в Monero?
    <ArticMine> То, с чем мы имеем дело, больше похоже на бешеный медвежий рынок, а не на волатильность
    <UkoeHB_> Реальных задержек нет, но в любом случае получатели пожертвований проигрывают в отношении фиата к эквивалентной способности покупателя
    <ArticMine> как по мне, во время медвежьего рынка сроки немного отстают
    <atoc> всё, вижу, спасибо
    <atoc> Я тоже задавался вопросом об этом. Это определенно хорошая информация, спасибо
    <moneromooo> спонсоры ничего не теряют. Они получают именно то, за что заплатили. А вот получатели могут как проиграть, так и выиграть от курса. Другие участники рынка, скорее всего, выиграют, чем проиграют
    <UkoeHB_> спонсоры могут проиграть в том случае, если получатели обоснованно просят доплаты во «имя волатильности»
    <sarang> В любом случае это полезная информацию для всех авторов предложений и потенциальных спонсоров для оценки волатильности
    <sarang> Isthmus: вы хотите обсудить работу TheCharlatan в ключе времени блокировок?
    <sarang> (примечания, которые вы опубликовали в повестке дня)
    <ArticMine> Я думаю, что волатильность немного не тот термин
    <Isthmus> @ArticMine, да, согласен, если у вас есть какое-то слово, которое передает весь коллапс на рынке, дайте мне знать
    <Isthmus> @sarang, конечно
    <Isthmus> Несколько месяцев назад мы обнаружили, что время разблокировки открытого текста Monero приводит к утечке информации и создает риск связности для транзакций
    <Isthmus> время разблокировки в зашифрованном виде позволит решить проблемы конфиденциальности, однако необходимо тщательно продумать характеристики и саму конструкцию
    <sarang> Правильно
    <ArticMine> Проблема заключается в систематической тенденции к снижению цены на протяжении срока CCS
    <sarang> думаю, что можно взять часть формул из документа DLSAG
    <Isthmus> Insight подготовили предложение для Isthmus & TheCharlatan в ключе новых исследований на текущее лето. Будем рады вашей обратной связи: https://github.com/insight-decentralized-consensus-lab/monero_encrypted_unlock_time
    <Isthmus> Наши цели:
    <sarang> в препринте DLSAG уже работает структуризация выхода с двумя ключами, также у меня есть некоторый код, демонстрирующий как общий метод, так и то, как могут использоваться различные конструкции LRS
    <Isthmus> решения по проектированию новой системы (например, использование unlock_time на выход или на транзакцию)?
    <Isthmus> Прототип кода для быстрого тестирования различных подходов, включая моделирование построения транзакций, подписание и верификацию
    <Isthmus> Отчет о количественных компромиссах для пространства / времени / конфиденциальности со стратегией смягчения последствий
    <Isthmus> Код реализации для дерева кода Monero, по крайней мере, для одного из выбранных подходов
    <Isthmus> Комплексный анализ результатов исследований, перекрестные ссылки с кодом и документацией
    <Isthmus> Ой, извини, Саранг, продолжай
    <sarang> О, нет, все в порядке, я просто представил некоторую предысторию... пожалуйста, продолжайте
    <Isthmus> это конец моего списка: -)
    <sarang> Понял!
    <sarang> да, значит, что над этим уже была проделана какая-то работа
    <sarang> я обсуждал это с TheCharlatan
    <sarang> в принципе, вы можете следовать подходу, аналогичному тому, что используется в DLSAG, используя любую dLRS конструкцию
    <sarang> то есть можно использовать MLSAG, CLSAG, Triptych
    <sarang> и очевидно, что масштабирование будет отличаться по размеру / времени
    <sarang> по сути, вы увеличиваете 2-LRS (ключ подписи, ключ суммы) до 3-LRS (ключ подписи, ключ суммы, ключ времени блокировки)
    <sarang> но вы должны изменить нетрадиционную структуру доказательств диапазона
    <sgp_> Означает ли это, что все выходы будут иметь одинаковое время разблокировки?
    <sarang> В теории - да
    <sarang> Но это будет зависеть от того, как именно это будет реализовано
    <Isthmus> Угу, @sgp_, все как вы говорите
    <sarang> во всяком случае, будет незначительное увеличение размера транзакции из-за того, что нужно включить необходимые вспомогательные данные для обязательств
    <sarang> что более важно, так это то, что есть временные увеличения, которые линейно масштабируются с размером кольца
    <sgp_> возможно, вначале следует изучить рынок, прежде чем менять что-то?
    <sarang> временное увеличение присутствует независимо от того, будут ли блокировки считаться на выход или целиком на транзакцию
    <sarang> у меня есть код с примером на C++ для CLSAG, и вероятно, что я бы мог бы аналогичным образом адаптировать его для Triptych
    <sarang> (и нет смысла делать это для MLSAG)
    <sarang> прежде чем тратить на это временя / усилия, думаю, что было бы полезно узнать, что именно думаю люди
    <sarang> подпись довольно проста (от 2-LRS к 3-LRS), но потребуются дополнительные затраты на проверку диапазона, которые должны изменить общую структуру выплаты из-за масштабирования Bulletproofs DoS
    <sgp_> это влияет только на транзакции, которые используют блокировки, или вообще на все?
    <sarang> и, конечно же, нужно учитывать фактический момент времени реализации
    <sarang> для максимальной однородности все выходы будут нуждаться в таких блокировках
    <sarang> блокировка может быть установлена ниже 0
    <sarang> это должно сказаться на времени проверки
    <sarang> поскольку для каждого члена кольца необходимо обработать данные блокировки
    <sarang> и верификатор не может сказать, какие блокировки установлены в 0 из-за самой структуры обязательств
    <UkoeHB_> Я чувствую себя как knaccc, так как я не могу себе представить, о чем вы вообще говорите
    <Isthmus> граница интересов
    <moneromooo> может ли шифрование времени блокировки препятствовать использованию его в качестве строительного блока второго уровня?
    <sarang> Конструкции, включающие поперечные и внецепные каналы, будут нуждаться в доработках
    <sgp_> Isthmus: какой процент транзакций использует эти блокировки?
    <sarang> moneromooo: шифрование временных блокировок изначально было разработано для 2-го слоя DLSAG
    <gingeropolous> я думал, что второй слой как раз и требует такие временные блокировки, которых у нас пока нет
    <sarang> DLSAG не нуждается в них, но это полезно, чтобы избежать появления новых эвристик
    <sarang> например, участники кольца, чьи блокировки только что подошли к своему логическому концу, могут быть вероятными подписчиками и т. д.
    <gingeropolous> и я думаю, что оба типа будут нуждаться в дополнительном шифровании
    <sarang> в любом случае, если решение заключается в добавлении временных блокировок, нам потребуется, чтобы структура обязательств была потенциально подготовлена к уменьшению воздействия новых эвристик, но это всё связано с определенными затратами
    <sarang> стоимость масштабируется с изменением размера колец
    <moneromooo> тогда стоимость должна компенсироваться поддержкой второго слоя, не иначе
    <gingeropolous> согласен, это подходит под наше определение, что Monero - это цифровые деньги
    derpy_bridge подключился (~derpy_bri@92.223.89.163)
    <sarang>
    такое решение, как DLSAG, требует временных блокировок, но не требует их дополнительного шифрования
    <sarang> однако такая однородность точно не будет лишней
    <UkoeHB_> Isthmus, возможно, стоит сделать базовые оценки затрат, связанных с добавлением блокировок (требования к хранению, дополнительные операции EC), как для CLSAG, так и для Triptych.
    <sarang> UkoeHB_: У меня уже есть эти данные для CLSAG
    <sarang> и для Triptych тоже есть (правда, пока только на C++)
    <UkoeHB_> о как! А можно ссылку?
    derpy_bridge_ вышел (~derpy_bri@92.223.89.162): Причина: Бездействие в течение 256 секунд
    <sarang>
    Да, конечно, после встречи
    <TheCharlatan> затраты на подпись и обязательства?
    <sarang> ссылка на ветку для 3-CLSAG: https://github.com/SarangNoether/monero/tree/3-clsag
    <sarang> TheCharlatan: доказательство диапазона не повлечет за собой дополнительные расходы
    <sarang> единственное, что это зависит от конкретного изменения
    <sarang> при желании я могу обновить код C++ Triptych для добавления временных блокировок, чтобы получить сравнительные данные о различиях в производительности
    <sarang> это не потребует много времени
    <sarang> в любом случае я поддержу идею, если она основана на четком понимании всех затрат и имеет консенсус
    <sgp_> я поддерживаю это исследование в том случае, если мы осознаем, что это решение, которое Monero будет использовать для масштабирования второго уровня. Ответ на вопрос «Как зашифровать» намного проще, чем сам процесс аудита. И в моём понимании, аудит - это первостепенная проблема
    <sarang> sgp_: мы все прекрасно понимаем и осознаём
    <sarang> (с точки зрения обработки новых подписей)
    <sgp_> я имею в виду, что мы должны понять, что лучше
    <sarang> а вот что на текущий момент не совсем понятно, так это особенности, связанные с доказательствами диапазона, структурой комиссий и т. д.
    DeanWeen подключился (~dean@gateway/tor-sasl/deanguss)
    <UkoeHB_>
    комиссии можно легко переработать
    <sarang> Может быть и так.... А вот что действительно изменится, так это то, что агрегированное доказательство диапазона теперь должно учитывать вновь сгенерированные выходы, а также подтверждение для каждого входа временной блокировки
    <sarang> и именно это нужно продумать и спроектировать
    <UkoeHB_> правильно
    <sarang> и это также усложняет ситуацию, так как в настоящее время нет конкретных ограничений на вход
    <sarang> в то время как Bulletproofs имеют свою предельную стоимость проверки, поэтому мы и ограничиваем количество выходов
    <sarang> добавление отдельного Bulletproofs доказательства не имеет смысла с точки зрения размера
    <UkoeHB_> хммм
    <UkoeHB_> временные блокировки на вход могут быть дорогими, поэтому я склонен полагаться на оценки /o\
    <Isthmus> у нас есть 1 транзакция и зашифрованный бит на каждый выход
    <Isthmus> 1 = это зашифрованное время блокировки
    <Isthmus> 0 = по умолчанию (10 блоков)
    <sarang> Isthmus: вам все еще нужны компоненты подписи и доказательства диапазона
    <sarang> то, как вы группируете временные блокировки для выходов, слишком грубо
    <Isthmus> я просто пытался придумать, как можно блокировать выходы 1+ без блокировки изменений (без дополнительной зашифрованной временной блокировки для каждого выхода)
    <sarang> в таком случае будет минимальная стоимость изменения размера
    <sarang> сейчас главная проблема - это время верификации
    <sarang> и специфика структуры доказательства диапазона
    <Isthmus> да… вы правы, это основные проблемы, которые нам предстоит решить
    <sarang> Ну, у нас есть код CLSAG, чтобы иметь представление о стоимости изменений
    <sarang> который можно переделать для Triptych
    <sarang> точнее, какое время будет оптимальным
    <sarang> «как можно меньше» не выглядит как настоящее дизайнерское решение
    <sgp_> Могу я вмешаться? мне нужно убедиться, что я понимаю общую картину
    <sarang> конечно
    <sarang> вперёд
    <sgp_> Для того чтобы добавить функцию, должно быть по крайней мере несколько способ её применения, особенно если это относится к затраты в ключе человекочасов
    <UkoeHB_> Тайм-ауты nvm для каждого выхода будут дешевыми, порядка 8 байт на дополнительный выход
    <sgp_> главное преимущество заключается в возможности добавить что-то по типу DLSAG или других связанных протоколов, которые могут позволить второй уровень, верно? Получается, что временные блокировки необходимы для решений второго уровня?
    <sarang> если мы реализуем временные блокировки прямо сейчас; то у них есть несколько принятых спецификаций, и вероятно, что они добавят новую эвристику для всех трат
    <Isthmus> ключевое слово «если»
    <sarang> их добавление повлечет и добавление новых специфик для дактилоскопии
    <sgp_> насколько нам известно, они не используются для чего-то конкретного?
    <sarang> ^^ хорошее замечание
    <Isthmus> по большей части это не только временные блокировки
    <Isthmus> используются 5 различных форматов
    <Isthmus> советую вам заглянуть в документацию
    <sarang> это то, что я имел в виду
    <Isthmus> это значит, кто-то их использует
    <Isthmus> и, к сожалению, я не знаю реального прецедента их использования
    <sarang> Создание унифицированного формата является первым шагом
    <UkoeHB_> какая доля всех транзакций имеет ненулевые блокировки?
    <TheCharlatan> sgp_, еще они полезны при реализации атомарного свопа, это на тот случай, если вы ищете конкретное применение
    TheoStorm вышел (~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl): Причина: Вышел
    <jwinterm>
    UkoeHB_, да, у меня назрел аналогичный вопрос
    <sgp_> https://usercontent.irccloud-cdn.com/file/xIfs2dFC/table
    <jwinterm> TheCharlatan, получается, что они сейчас находятся в «подвешенном состоянии»? Я думал, что для атомарных свопов требуются временные блокировки, которые есть в bitcoin, то есть транзакция не может быть смайнена до определенного времени
    <gingeropolous> да, lightning сети и атомарные свопы - наиболее актуальное место для применения времени блокировки
    <Isthmus> порядка 10 тысяч ненулевых блокировок
    <Isthmus> и это без учета подадресов ;-)
    <jwinterm> общее количество транзакций составляет порядка 10 миллионов?
    <Isthmus> 6 миллионов
    <Isthmus> точнее 7 миллионов
    <jwinterm> .c 1e4/7e6
    <monerobux> jwinterm: 0.001428571429
    <sgp_> просто глупая идея: почему бы полностью не удалить эту функцию, если это как-то не обосновывает ее необходимость?
    <jwinterm> я бы сказал, что это явно больше, чем 0.1%
    <TheCharlatan> Istmus и я также обсуждали введение более компактного формата, это особенно полезно, если шифрование считается нежелательным. Но я считаю, что мы все равно должны изменить их на что-то более разумное и менее опасное
    <sgp_> я всё равно не понимаю их обоснованность
    thrmo_ вышел (~Thrmo@unaffiliated/thrmo): Удаленный хост разорвал подключение
    <UkoeHB_>
    компактный формат?
    <sarang> Вы имеете в виду поддержку только одного единого формата?
    <sarang> это выглядит как ранее обусловленный «первый шаг»
    <UkoeHB_> если использовать такой вариант, то думаю, изменение размера составит около 9 байт
    <sarang> ну, мы понимаем, что добавление времени блокировки также добавит дополнительные методы дактилоскопии
    thrmo подключился (~Thrmo@unaffiliated/thrmo)
    <sgp_>
    для того чтобы появились «крутые» приложения с временной блокировкой, нам нужно договориться о предварительной реализации такого функционала
    <sarang> как и использования платежного канала, реализованного в DLSAG
    <Isthmus> @UkoeHB_, я думал, что это uint64. Я нашел несколько выходов, заблокированных до 18446744073709551614 (около 500 миллиардов лет) :p
    <sarang> Isthmus: наверное, что-то очень-очень ценное
    <ArticMine> Использование одного формата для временных блокировок кажется разумным первым шагом
    <UkoeHB_> есть варианты с использованием 63 бит информации
    <Isthmus> да
    <sarang> Итак, в интересах экономии времени, что будет нашим следующим шагом в этом процессе проектирования?
    <UkoeHB_> смета расходов
    <sarang> Isthmus, TheCharlatan: давайте обсудим это после встречи
    <TheCharlatan> ситуация с временной блокировкой уже полностью переосмыслена. Было много дискуссий по этому поводу в Bitcoin, например, чтобы ограничить размер до значения в 1 байт, которое затем интерпретируется как «сила времени»
    <ArticMine> единый унифицированный формат
    <sgp_> Я думаю, что вначале нужно провести оценку стоимости самого дешевого варианта, чтобы понять, насколько это оправдано
    <TheCharlatan> а вот я бы полностью избавился от времени блокировки на основе временной шкалы
    <Isthmus> это добавляет корректирующий термин при изменении времени блока
    thrmo вышел (~Thrmo@unaffiliated/thrmo): Удаленный хост разорвал подключение
    <Isthmus>
    и это достаточно легко сделать
    <sgp_> TheCharlatan: ахаха точно! Или спрашивать, какое оправдание у людей, которые их используют
    <sarang> Итак, кроме исследования в ключе использования открытого текста в одном унифицированном формате и обновления смет, вам есть, что еще добавить по этой теме?
    <sarang> (иначе мы можем обсуждать это вечно….)
    <sarang> раз
    <sarang> два
    <sarang> продано!
    <sgp_> Нет, я просто хочу выяснить, для чего все это и почему они должны использоваться, прежде чем замедлять скорость проверки транзакций
    <sarang> хорошо, в оставшееся время я могу представить несколько обновлений
    <sarang> я пересмотрел используемые проверки в Triptych, чтобы добавить возможность пакетирования с помощью общего ключа
    <sarang> новые временные данные: https://usercontent.irccloud-cdn.com/file/TWAkCeJJ/timing.png
    thrmo подключился (~Thrmo@unaffiliated/thrmo)
    <sarang>
    эти данные представляют собой амортизированную стоимость для проверки набора подписей с двумя входами
    <sarang> предполагается, что одно и то же кольцо используется для двух входов Triptych
    <sarang> (для MLSAG/CLSAG это не играет никакой роли)
    <sarang> еще я пересмотрел тесты MLSAG для лучшей совместимости с другими сериями
    <UkoeHB_> стоп, получается, что проверка будет еще быстрее?
    <sarang> по идее, да
    <selsta> Что такое амортизируемая стоимость?
    <sarang> если у вас транзакция с двумя входами, вам нужно вычислить две подписи
    <sarang> для MLSAG / CLSAG это занимает вдвое больше времени
    <sarang> в Triptych, если вы используете то же кольцо, вы получаете огромные преимущества
    <sarang> так что это цена за вход для транзакции с 2 входами
    <sarang> получается, что для транзакций с большим количеством входных данных, которые будут совместно использовать одно кольцо, преимущества становятся еще больше
    <UkoeHB_>
    <sarang>
    серые пересекающиеся линии центрированы в точке N=11 MLSAG
    <sarang> это означает, что Triptych будет медленнее в случае (для 2 входов) N=64 и N=128
    <sarang> (но вы не можете разделить разницу... вам нужно выбрать степень 2)
    <sarang> в любом случае надеюсь, что это даст более реалистичные временные данные, по крайней мере, при использовании 2 входов
    <sgp_> является ли 128 аналогичным временем, как в случае с DLSAG 12? 13?
    <sarang> вы можете использовать мою ветку `triptych` и `clsag-device`, чтобы самостоятельно получить все актуальные данные
    <sarang> а вот данных на C++ для DLSAG у меня нет
    <sgp_> ой, извините, я имел ввиду MLSAG
    <sarang> мне только предстоит провести несколько тестов для MLSAG
    <sarang> чем я и займусь после встречи (или, вообще, пересоберу сборку)
    <sgp_> отлично, понял вас
    <sarang> это должно занять несколько минут
    <sarang> на этом у меня всё
    <sgp_> отлично, спасибо!
    <sarang> есть ли у кого-нибудь еще исследования, которыми можно поделиться (у нас осталось мало времени)?
    <UkoeHB_> здорово
    <UkoeHB_> привет, да, что насчет вопроса с прошлой недели https://github.com/monero-project/monero/issues/6456
    <UkoeHB_> это синтез дискуссий и исследований с IRC канала за последние месяцы
    <sarang> всеобъемлюще :)
    <sarang> я признаю, что у меня не было возможности сесть и посмотреть :/
    <sarang> у вас есть какие-то конкретные предложения на данный момент, UkoeHB_?
    <UkoeHB_> дискуссия сводится к атаке Януса, и какое решение стоит нам принять? Еще присутствуют рекомендации по структуре транзакций, сортировке tlv и сортировке тегов
    <sarang> понял
    ⇐ thrmo вышел (~Thrmo@unaffiliated/thrmo): Причина: Бездействие в течение 272 секунд
    <sarang>
    Я обязательно уделю этому время к следующей встречи
    <UkoeHB_> и переход к 1 публичному ключу для транзакций с 2 выходами и 1 образу в случае > 2 выходов
    <sarang> Спасибо большое, что посвятили этому своё время
    <sarang> Хорошо, давайте кратко пройдемся по КЛЮЧЕВЫМ МОМЕНТАМ
    <Isthmus> "1 публичному ключу для транзакций с 2 выходами" < это при условии, что каждый 2 выход из транзакции имеет выход с изменениями?
    <Isthmus> *задумался
    <UkoeHB_> мы должны рассмотреть эту идею, если хотим что-то противопоставить атаке Януса
    <Isthmus> Хорошо, если есть транзакция, разделенная между 2 (неизменными) получателями, мы должны сделать её как 3 выход с дополнительным фиктивным выходом, верно?
    <UkoeHB_> все верно
    <Isthmus> довольно спорное решение
    <Isthmus> Извините, @sarang, что перебил, продолжайте
    <sarang> помнится мне, что кто-то вызвался сделать обзор кода CLSAG, что было бы очень полезно... нам также порекомендовали добавить Poly1305 к шифрованию кошелька, что кажется весьма хорошей идеей
    <sarang> кроме того, я обновлю некоторые данные для 3-CLSAG и 3-Triptych, чтобы помочь будущему обсуждению
    <sarang> у меня всё :)
    <sarang> кто-то еще?
    <Isthmus> Я дополню материал о временной блокировке дополнительными ссылками / данными / вариантами использования
    <Isthmus> и, вероятно, закончу еще одно предложение реализации квантово-устойчивого алгоритма
    <sarang> великолепно
    <sarang> какие-то заключительные комментарии или предложения?
    <Isthmus> О как! Было бы весьма интересно прочитать об этом, UkoeHB_ :- )
    <sarang> Встреча окончена! Спасибо за отличную встречу!

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

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

    Kukima (@Kukima)
     
  • О нас

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