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