Когда: Среда, 19 февраля 2020 г., 18:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты Журнал встречи: <sarang> Хорошо, давайте начнем нашу встречу <sarang> ПРИВЕТСВИЯ <sgp_> привет <n3ptune> Привет — needmonero90 запускает волну из рук <needmonero90> Да-да, я сегодня на встрече! <needmonero90> Хотелось бы отметить, что ваши собрания не указаны в календаре <needmonero90> нужно полагать, что это не преднамеренно <sarang> В каком календаре? <UkoeHB_> Hi <sarang> и каким местом к нему относятся наши встречи? <ArticMine> Hi <sarang> Время / повестка дня собрания всегда указываются в разделе проблем на github <sarang> в любом случае кто-нибудь хочет начать наш КРУГЛЫЙ СТОЛ? <UkoeHB_> Да <sarang> Вперёд, UkoeHB_ <UkoeHB_> Я закончил разработку «протокола для децентрализованной торговой площадки», мы надеемся, что это сможет решить проблемы, с которыми столкнулся rbrunner в своем анализе интеграции openbazaar. В дополнение мы добавили поддержку multisig и txtangle <UkoeHB_> https://www.pdf-archive.com/2020/02/19/zerotomoneromaster-v1-0-28/zerotomoneromaster-v1-0-28.pdf <sarang> Отлично <UkoeHB_> еще у меня появилась идея уменьшить минимальные колебания комиссии и включить антиспам непосредственно в протокол вместо того, чтобы полагаться на увеличение комиссии <sarang> у вас уже есть анализ данного решения? <UkoeHB_> он описан в проблеме #70 <UkoeHB_> и ждёт ваших комментариев <UkoeHB_> о! Сананг, я представил черновик для обновленной главы о доказательствах в транзакциях <sarang> Великолепно <UkoeHB_> (но это не исследования ) <sarang> это, скорее, краткое изложение того, что находится в кодовой базе (+ некоторые изменения) <sarang> с нетерпением жду возможности прочитать эти обновления, на которые вы ссылаетесь <UkoeHB_> ряд тем всё еще нуждается в обзоре: https://github.com/monero-project/research-lab/issues <UkoeHB_> я всё <sarang> Спасибо, UkoeHB_ <sarang> Ваши вопросы или комментарии? <ArticMine> Да <sarang> Пожалуйста, продолжай! <ArticMine> Я рассмотрел вопрос #70 <ArticMine> и это на самом деле имеет серьезные последствия <ArticMine> когда LT среда существенно увеличивается <ArticMine> и у меня есть идея для ее решения <ArticMine> пока все ещё предварительная на данном этапе <ArticMine> что касается исправления <ArticMine> самое главное — это установка высоких или хотя бы средних комиссий за условное депонирование, которое, как ожидается, добавиться в следующем обновлении <ArticMine> у меня будут дополнительные комментарии по этому вопросу в ближайшие две недели <ArticMine> всё <sarang> спасибо, ArticMine <sarang> Есть еще вопросы / комментарии по темам, представленным UkoeHB_? <sarang> хорошо <sarang> тогда я поделюсь несколькими своими исследованиями <sarang> во-первых, прямо сейчас (и в ближайшие несколько дней) проходит Стэнфордская блокчейн-конференция: https://cbr.stanford.edu/sbc20/ <sarang> во-вторых, я закончил некоторые математические / кодовые тесты, связанные с многопартийностью, для протоколов следующего поколения <sarang> в-третьих, я работал над кодом и записями для подтверждения транзакций как для обновленного PR, так и для включения обновлений в Zero to Monero <sarang> в-четвертых, я использовал новые данные от n3ptune и его друзей, чтобы лучше оценить кумулятивный эффект протоколов следующего поколения <sarang> как рост всей цепочки, так и времени проверки <sarang> главное предостережение: они предполагают то же распределение входов / выходов, что и текущая версия <sarang> и применимо только к данным из цепочки bulletproof <sarang> https://usercontent.irccloud-cdn.com/file/ijaEAI7m/size.png <sarang> ^ эта ссылка показывает оценки общего роста цепочек для различных протоколов с различным размером кольца <sarang> а именно от 16 до 1024 в степени 2 (только для возможности визуальной оценки) <UkoeHB_> Для справки - не хотите ли вы добавить соответствующие точки для MLSAG и CLSAG с размером кольца 11? <sarang> Конечно, мне нужно взять эти данные из моей таблицы <sarang> подождите, пожалуйста <UkoeHB_> какой пологий склон от 11 к 20 lol, прямо выбивается из всего графика <sarang> хех, у меня есть эти данные, но я их не включал, потому что они очень линейны <sarang> я использую N = 11 для MLSAG / CLSAG <sarang> во всяком случае, я еще переделаю данные о времени <sarang> https://usercontent.irccloud-cdn.com/file/T7uWoFEp/time.png <sarang> ^ оценка времени проверки для _различных_групп_операторов_ при разных размерах кольца <UkoeHB_> что интересно, все эти протоколы / схемы подписи имеют одинаковый размер <sarang> всё время проверки линейно (вплоть до логарифмического члена) <UkoeHB_> а где там прячутся данные tryptich? <sarang> под Triptych-single <sarang> они, по сути, неразличимы <selsta> есть ли у Triptych-single преимущества перед Triptych-multi? <sarang> RCT3-multi страдает из-за требований заполнения входов, которые имеют эффект линейной проверки <sarang> selsta: полное доказательство надежности <sarang> обновление оценок размера MLSAG / CLSAG... <UkoeHB_> Не могли бы вы сделать отдельный маленький график с данными от 0 до 128? Поскольку этот кажется довольно громоздким <sarang> при N=11 MLSAG для этого диапазона примерный размер составит порядка 7,84 ГБ, а CLSAG - 5,84 ГБ. <sarang> (фактический размер этой цепочки составляет 7,9 ГБ) <sarang> https://usercontent.irccloud-cdn.com/file/DFhClmEe/time-small.png <sarang> ^ данные в том же отрезке времени, только увеличенные <UkoeHB_> спасибо есть ли приблизительные оценки CLSAG / MLSAG? <sarang> хех, я просто отмечу, что <sarang> у меня есть предварительные оценки, но они не передают всей картины, так как multiexp не применяется, а хеширование тривиально <sarang> Оценка MLSAG при N=11 составляет 29,9 часа для всего диапазона цепочки (но я не перепроверял результаты) <ArticMine> Какое оборудование использовалось для расчета времени проверки? <sarang> одно ядро на Opteron с частотой 2,1 ГГц и с большим количеством оперативной памяти <sarang> я бы полагался на временные данные только для сравнения, а не как на абсолютные значения <ArticMine> возраст процессора? <sarang> Я все еще нахожусь в процессе получения данных для CLSAG, мне потребуются дополнительные тесты <sarang> Gen-3 Opteron, если ты это имеешь в виду <UkoeHB_> Есть ли какой-то способ симулировать этот тест? другие участники могли бы выполнить аналогичную проверку на своём оборудовании? <sarang> только оценки при использовании кода теста производительности <sarang> для протоколов следующего поколения это довольно просто <ArticMine> отлично, большое спасибо <sarang> Ну, это не очень просто <sarang> вам нужно получить данные о производительности и использовать линейную интерполяцию, которую вы подключаете к симулятору <sarang> для MSLAG / CLSAG вам потребуется дополнительные данные о производительности операций <sarang> а вот ссылка на сам симулятор: https://github.com/SarangNoether/skunkworks/blob/sublinear/estimate.py — Isthmus прикидывается уткой и крякает в течении 30 секунд <Isthmus> https://usercontent.irccloud-cdn.com/file/HuPcfLdT/image.png <sarang> опять же сложно сравнивать MLSAG / CLSAG и протоколы следующего поколения — Isthmus выключает режим утки <sarang> воу-воу <Isthmus> цифры это одно, но мы все должны быть встревожены тем, что анализ чего-то подобного возможен для стороннего наблюдателя <Isthmus> ;-) <sarang> Да, и это безусловно интересная тема! <Isthmus> Использование субадресов связано с риском для конфиденциальности... <Isthmus> в любом случае это просто информация для размышления, извините, я сейчас в дороге <sarang> ОК, Isthmus, спасибо, что поделились наблюдением <sarang> еще одно напоминание о том, что структура входа / выхода раскрывает некоторую информацию об использовании подадреса <sarang> поскольку Isthmus пришлось оставить нашу скромную встречу, есть ли у вас другие вопросы / комментарии к данным, которыми я поделился выше? <sarang> UkoeHB_: если вы хотите провести свою череду тестов, то отпишитесь мне после встречи, я расскажу, где взять и куда подставить нужные данные <UkoeHB_> Мой компьютер довольно слабый, это так, просто из любопытства <sgp_> sarang: не могли бы вы напомнить, как обстоят дела по исправлению утечки данных с подадрессов? <sarang> минутку <sarang> требование о разделении ключей в транзакциях для каждого выхода - хорошая идея, но идея не получила должной поддержки <sarang> данные о размерах, которые я представил для следующего поколения протоколов, предполагают использование отдельного ключа для каждого выхода <UkoeHB_> Это необходимо для самой концепции протоколов? <sarang> вы имеете в виду системы проверки? Нет <sarang> им все равно, как вы получаете ключи для подписи <UkoeHB_> Можете ли вы оценить дополнительные данные в ключе? Num Out * 32 и Num TX * 32? <sgp_> sarang: почему эта реализация не получила поддержки? Какие возникли сложности? Может размер? Или время проверки? <sarang> все мои данные для MLSAG/CLSAG уже включают раздельные ключи ⇐ phire вышел (phire@119.252.27.69): *.net *.split <sarang> данные от n3ptune уже включают в себя публичные ключи <sarang> их можно использовать для более детального подсчета → phire подключился (phire@119.252.27.69) <UkoeHB_> С учетом только 3% всех субадресов разница составляет порядка 100 МБ <UkoeHB_> что равно примерно 2% от общего размера <sarang> это, вероятно, хороший показатель <sarang> но потребуется дополнительная проверка <sarang> так что должна быть корреляция <UkoeHB_> думаю, что размер составит ~1 ГБ для 30 миллионов публичных ключей <sarang> у moneromooo должно быть лучшее представление о последствиях <sarang> а вообще, это отличная идея, не смотря на все её сложности <sarang> Хорошо, мы приближаемся к отметке в один час <sgp_> Очевидно, что без этого изменения последствия будут весьма негативными для общей конфиденциальности сети........ <sarang> Это дифференцированные данные, но они не *предполагают* что выходные данные предназначены для субадресов <sarang> (и это не причина для сохранения текущего подхода) → rottensox подключился (~rottensox@unaffiliated/rottensox) <UkoeHB_> я настроен немного скептически <sgp_> получается, что *один из этих выходов попадает на субаддрес?* <sarang> UkoeHB_:? <UkoeHB_> слишком много фиктивных данных <sarang> sgp_: показывает количество выходов для конкретного подадреса <UkoeHB_> это показывает, что как минимум один из выходов принадлежит субадресу <sarang> Разве это не показывает общее количество выходов? <UkoeHB_> Нет <sarang> хм <UkoeHB_> а в чем тогда загвоздка? <UkoeHB_> количество дополнительных публичных ключей всегда равно количеству выходов <UkoeHB_> даже если это не субадресс <UkoeHB_> и вообще, как продвигается работа над документом CLSAG? <sarang> Хм, почему-то я думал иначе <sarang> я все еще жду suraeNoether <sarang> он хотел продолжить работу над своими новыми идеями для моделей безопасности <sarang> так что пока никак <sarang> Хорошо, заключительные замечания или мысли <sarang> (если у вас есть дополнительные идеи, мы можем продолжить их обсуждение после завершения официальной части встречи) <sgp_> следует открыть соответствующий вопрос <sarang> Хорошо, спасибо всем за участие <sarang> на сегодня мы закончили! Источник: Research meeting: 19 February 2020 @ 18:00 UTC #439 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
