Когда: Среда, 23 сентября 2020 года @ 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты Журнал встречи: <sarang> Хорошо, давайте начнем нашу исследовательскую встречу ⇐ intj440 вышел <sarang> Во-первых, приветствия! <sarang> Hi <midipoet> серьезно, если кому-то интересно посмотреть, как работает новый метод вызова, дайте мне знать. <n3ptune> Здравствуйте — Isthmus запускает волну из рук → intj440 подключился <midipoet> Horizon Europe хочет, чтобы консорциумы создавались с упором на партнерство за пределами Европы. Бюджет составляет 4-12 миллионов. <TheCharlatan> hi — midipoet замолкает, так как начинается встреча <ArticMine> hi <sarang> Краткое напоминание о том, что встреча на следующей неделе будет последней, которую я буду проводить; если кто-то еще захочет взять на себя это бремя, пожалуйста, не стесняйтесь <sarang> Переходим к круглому столу <sarang> Где каждый желающий может поделиться своими интересными исследованиями <sarang> Кто-нибудь хочет чем-нибудь поделиться? <n3ptune> Я хотел бы поделиться двумя большими проектами в ключе SQL, которые я только что закончил <n3ptune> Первый - это парсер tx_extra для PostgreSQL: http://github.com/neptuneresearch/tx-extra-parse <n3ptune> Это нужно для того, чтобы проанализировать данные из полей tx_extra (которые упакованы в одну байтовую строку) как отдельные записи базы данных для каждого тега подполя <n3ptune> Вот несколько выполненных нами запросов, а также их результаты: http://github.com/neptuneresearch/monero-tx-extra-statistics-report <n3ptune> Некоторые из них мы уже представляли ранее на собрании MRL в феврале 2020 года и в комментариях к повестке дня на github. С тех пор накопилось весьма много вопросов, на которые теперь у нас есть ответы. Извините, что на это потребовалось так много времени! <n3ptune> Самым большим результатом данного исследования стало то, что никто не хранит в транзакциях Monero другие нестандартные для консенсуса данные <sarang> Хех, весьма интересно <sarang> Означает ли это, что отказ от tx_extra в пользу стандартных полей, таких как зашифрованный pID, вряд ли нарушит существующие варианты использования? <n3ptune> Да, относительно текущего использования <n3ptune> Это все равно сломало бы всё в будущем <sarang> но это уже другая проблема <Isthmus> у нас получился весьма интересный ответ на ранее заданный вопрос UkoeHB_ <Isthmus> кроме того, одна транзакция содержит 1000 идентификаторов платежей, lol <Isthmus> и там очень много чего интересного <n3ptune> существует несколько способов записи одних и тех же данных <sarang> Да, наверняка <n3ptune> Например, вы записываете открытый ключ, а затем зашифрованный идентификатор платежа или зашифрованный идентификатор платежа, а уже потом открытый ключ <sarang> Все верно <n3ptune> или, например, вы добавляете "дополнительные публичные ключи" к каждой транзакции <sarang> "Лучший" вариант (для некоторого определения «наилучшего») - это установить стандартный набор данных и их порядок <sarang> тем самым исключая возможность дактилоскопии <sarang> или как минимум просто всё усложните <n3ptune> Да и вообще полное прекращение поддержки этого поля заставит отказаться от использования незашифрованных PID. <sarang> Угу <Isthmus> Да, проголосуйте за TLV <sarang> Приятно иметь данные, подтверждающие это <sarang> Что-то еще, чем вы хотели бы поделиться в ключе данной работы, n3ptune? <sarang> или Isthmus? <n3ptune> Если вы о tx_extra, то нет <n3ptune> любые вопросы приветствуются <n3ptune> Другой SQL проект, которым бы я хотел поделиться: http://github.com/neptuneresearch/ring-membership-sql <n3ptune> Это дает возможность PostgreSQL построить индекс вывода транзакции и декодировать key_offsets транзакции, что позволяет получить отдельные элементы колец транзакции <n3ptune> Это строительный блок для написания более сложных запросов, касающихся участников колец и таких данных, как последующий анализ выбора приманки <sarang> Круто, похоже на то, что делает интерфейс обозревателя блоков <n3ptune> В точку! <sarang> понятно <sarang> Что-нибудь интересное в процессе этой работы? <sarang> Или еще рано для анализа? <n3ptune> у нас пока нет вариантов использования <Isthmus> хех, у нас масса вариантов использования, просто они еще не готовы в текущей реализации <Isthmus> Будет забавно повозиться с этим в дальнейшим <sarang> Полностью согласен с вами <sarang> Поскольку выбор приманки полностью зависит от клиента <Isthmus> Особенно когда добавляется слой для отслеживания цепочек с дефектами взаимозаменяемости <sarang> Это великолепно! <sarang> Есть вопросы для n3ptune и/или Isthmus? <sarang> Хорошо <sarang> Тогда позвольте мне поделиться моей работой <sarang> Я представил Triptych на мастер-классе ESORICS, документ был весьма тепло встречен <sarang> Еще в эти выходные я буду выступать на тему конфиденциальности на предстоящем MCCVR и участвую в конференции, посвященной конфиденциальности в Bitcoin <dEBRUYNE> Чтобы внести немного ясности, это отдельные выступления? Потому что я видел только объявление о предстоящей панели <sarang> Я сделал несколько обновлений для повышения эффективности Arcturus, которые немного упрощают ситуацию, а также обновил его код подтверждения концепции на Python, чтобы указать, как лучше выполнять верификацию <sarang> Да, это отдельное выступление, и оно состоится непосредственно перед самой панелью <sarang> Они попросили меня выступить с докладом после того, как я согласился провести панель <sarang> Я также планирую обновить статистику транзакций для общего пользования <sarang> Недавно у компании cargodog[m] появилась интересная идея <cargodog[m]> Где она будет представлена? Я как раз искал статистику транзакций <sarang> Они разработали реализацию Arcturus на Rust: https://github.com/cargodog/arcturus/ cargodog[m] машет рукой <dEBRUYNE> Спасибо за разъяснения <sarang> cargodog[m]: Я сделаю репозиторий доступным после того, как закончатся основные скрипты с проверками <sarang> Скрипты находятся в ветке `tracing` моего репозитория `skunkworks` <cargodog[m]> Большое спасибо! <sarang> у cargodog[m] была идея использовать обобщенный код Gray для ускорения работы Triptych/Arcturus и т. д. <sarang> Я все еще в процессе определения степени повышения эффективности, при которой они применяются, а также в какой степени на них влияют лежащие в их основе криптографические системы <sarang> cargodog[m]: Вы можете сами поделиться этой работой, если хотите! <sarang> Я не знал, присутствуете ли вы на этой встрече <cargodog[m]> Спасибо, sarang: в настоящее время я заканчиваю статью, чтобы отобразить все улучшения <cargodog[m]> Извините, я опоздал на несколько минут <sarang> Еще одна вещь, которую я заметил в вашей бинарной реализации Gray — она заключается в том, что вы выполняете разложение Gray отдельно от самого определения <cargodog[m]> Моя цель - получить статью (короткую, но приятную), которая могла бы четко объяснить концепцию, не только применимую к Arcturus, но и к Triptych, Lelantus, One-out-of-Many и т. д. <sarang> также я работаю над обобщенной версией с кодом Gray, еще я хочу напрямую интегрировать изменения коэффициентов, чтобы избежать возможной избыточности <cargodog[m]> Действительно. Моя реализация OOM довольно специфична. Большая часть работы это обобщение текущего материала, чтобы сделать его более применимым к различным схемам <sarang> К счастью, вы можете итеративно вычислять код `n`-Gray, а это значит, что есть много возможностей для улучшения работы вашего двоичного метода. <sarang> я уже реализовал подобный метод на бумаге и могу представить его после окончания встречи <cargodog[m]> Это было бы прекрасно <sarang> Осталось сделать обновление коэффициентов, что не так уж сложно <sarang> Я не думаю, что таким образом можно добиться весомых улучшений, в отличие от не повторяющегося метода, но этот способ, безусловно, быстрее <sarang> Поскольку вы не вычисляете все методы с нуля <sarang> Я также прокомментировал, что подверг сомнению ваш подход из-за того, что он полагался на дорогостоящие инверсии, но я полностью пренебрегал эффектами пакетной инверсии, которые поддерживает ваш код <cargodog[m]> Тем не менее нам нужно каждое, пусть и потенциальное улучшение <cargodog[m]> В конечном итоге я надеюсь привлечь больше внимания к Arcturus и укрепить его позиции в криптографическом сообществе <sarang> Это означает, что вам нужно сделать только одну инверсию, а затем нетривиальное количество умножений мультипликатора <sarang> В любом случае я очень рад, что вы реализовали это, cargodog[m] <sarang> ⇐ rot вышел <cargodog[m]> Надеюсь, я смогу создать что-нибудь полезное → rot подключился <sarang> Каждая скалярная инверсия эквивалентна ~200 мультипликаторам <cargodog[m]> Это очевидно <sarang> Пакетная инверсия k скаляров - это одно 200-кратное обращение и еще одно дополнительное умножение на 3k <sarang> Спасибо! <cargodog[m]> ^ О! Я вчера как раз искал этот пример. Спасибо! <sarang> Я рад, что мой препринт смог помочь <sarang> Так или иначе, использование метода Gray повлечет за собой затраты на пакетную обработку <sarang> и, следовательно, я предполагаю, что есть некоторый компромисс, в котором преобладают некоторые улучшения от использования метода Gray при использовании больших анонимных наборов <sarang> Вы также указали, что в случае пакетной проверки, когда большие анонимные наборы являются обычным явлением, выигрыш становиться еще больше. <cargodog[m]> тут наоборот, скорее, более важен размер пакетной обработки, чем размер набора <cargodog[m]> а так, да <sarang> Конечно, эффективность там зависит от того, как именно вы пакетируете <sarang> Для чего-то по типу Lelantus мы просто повторно используем тот же анонимной набор → nssy подключится <sarang> Для текущего подхода, мы, скорее, заботимся о возрасте выхода, чтобы у нас было как можно меньше повторяющихся пакетов <cargodog[m]> Да, поэтому я весьма скептически отношусь к тому, как именно они собираются получать данные о транзакциях для пакетной обработки <cargodog[m]> но в общем идеи очень схожи <sarang> Конечно, это означает, что улучшение в Gray очень зависит от того, как именно вы выбираете анонимные наборы, и, следовательно, от того, как вы группируете <cargodog[m]> Да, все верно <sarang> В любом случае, если вы устраните вычислительные препятствия инверсии, вы заметите преимущества <cargodog[m]> Мне еще предстоит изучить методы выбора колец, чтобы максимизировать пакетирование <sarang> Да, это очень нетривиально <cargodog[m]> Очевидный подход - это увеличение размера кольца <sarang> Конечно, но нельзя игнорировать возраст выхода, это является потенциальной эвристикой. <sarang> к тому же он динамически изменяется <cargodog[m]> Действительно. Это очень большая проблема <sarang> В Lelantus используется большой анонимный набор, что отлично подходит для текущей реализации <cargodog[m]> К сожалению, мне нужно уходить, но потом я с радостью отвечу на все ваши вопросы <sarang> я боюсь, что на практике это может привести к возрастной эвристике <sarang> Нет проблем! Спасибо, что присоединились <cargodog[m]> Надеюсь, что в следующий раз буду присутствовать на целой встрече! <sarang> Возвращайтесь на канал в любое время <sarang> Я подготовлю для вас информацию о сложности инверсии, а также пример кода `n`-Gray после окончания текущей встречи <sarang> Журналы встречи доступны по ссылке в теме канала <sarang> Просто ищите упоминания и т. д. <sarang> или, возможно, что ваш IRC клиент умеет искать по тегам <sarang> в любом случае я подготовлю ссылки <sarang> Хорошо, есть вопросы по темам, которые я упомянул выше? <sarang> Если нет, желает ли кто-нибудь еще поделиться своими темами исследования? <Isthmus> Я нашел рисунок, который является конкретным примером работы фреймворка n3ptune <sarang> Продолжай! <Isthmus> я выбрал случайный дефект взаимозаменяемости (в данном случае конкретный дополнительный тег) и показал, как он используется для связывания транзакций через уже имеющиеся цепочки <Isthmus> https://usercontent.irccloud-cdn.com/file/1F4ccO3H/image.png <Isthmus> Таким образом, кошелек получил 3 свежих внешних выхода и совершил 16 транзакций. <Isthmus> Но каждый раз новая транзакция использовала изменения с одним и тем же дефектом. <sarang> Оу <Isthmus> Так что можно сказать, что все транзакции были отравлены в какой-то мере <UkoeHB_> тег - это идентификатор платежа? <Isthmus> круто то, что я могу автоматизировать фреймворк n3ptune для 1) автоматического анализа данных для выявления дефектов взаимозаменяемости и 2) автоматической идентификации каждой транзакции или цепочки кошелька. <Isthmus> Таким образом, мы можем отобразить дерево транзакций через адреса для ЛЮБОГО кошелька с ЛЮБЫМ дефектом взаимозаменяемости <Isthmus> Это совершенно новый монстр! <UkoeHB_> это действительно впечатляющая работа, ребята <dEBRUYNE> +1 <n3ptune> Спасибо <Isthmus> Я думаю, что это был тег `n_extra_nonce`? <dEBRUYNE> А я думаю, что стандартизация формата tx_extra поможет в этом отношении. <sarang> угу <Isthmus> Стандартизация tx_extra полностью исключила бы этот вид анализа, если бы сам протокол разрешал использовать только ключи и зашифрованный PID <sarang> Ну, в теории, да <sarang> На самом деле вы не сможете заставить корректно работать зашифрованный pID на уровне консенсуса <Isthmus> к дефектам взаимозаменяемости могут быть применимы такие пункты, как время разблокировки, необычные сборы и т. Д. <sarang> Вы можете использовать аутентифицированное шифрование, чтобы получатель не получил такую отравленную транзакцию... <sarang> Нет, я имею в виду, что вы можете использовать "pID" как угодно <sarang> Как вариант, заполнить нулями <moneromooo> Это допустимо в соответствии с правилами парсинга в кошельке? <sarang> или вашим номером телефона <sarang> в общем хоть чем <n3ptune> Я думаю, что это не тот случай <moneromooo> Раньше уже была жалоба на использование нестандартных полей в транзакциях <moneromooo> И как это выглядит по сравнению с выходами monerod? <n3ptune> Были случаи с полями extra nonce <n3ptune> В смысле пример по типу того, что официальное ПО не смогло бы создать? <moneromooo> 32-байтовый? <moneromooo> Не, больше такого не будет <n3ptune> То есть это не какой-либо идентификатор платежа. По примеру с 020901 и 022100 <moneromooo> Окей, понял <moneromooo> код Monero не сделает это самостоятельно <dEBRUYNE> <sarang> или вашим номером телефона <= Разве они не будут неотличимы из-за случайного элемента? <sarang> ? <sarang> Какой случайный элемент? <sarang> Сеть не может подтвердить, что вы зашифровали идентификатор платежа <dEBRUYNE> Игнорируйте мой бред, я всё перепутал <sarang> Вы можете настроить это так, чтобы _получатель_ смог получить такой выход <sarang> но не на уровне консенсуса <sarang> Лучшее, что вы можете сделать - это заставить получателя не тратить такой выход <Isthmus> ^ у zcash есть подобная реализация <sarang> С получателем? Да <moneromooo> Получатель просто не тратит полученные деньги? Отличный вариант <sarang> это вполне возможно (но не так просто в реализации) <dEBRUYNE> Мы могли бы добавить соответствующее предупреждение <sarang> Isthmus: это все на стороне клиенте <dEBRUYNE> Если такой выход был бы получен <sarang> Но вы можете написать клиент, который все равно сможет потратить этот выход <sarang> Сеть не может сказать вам «НЕТ» <Isthmus> Угу <sarang> dEBRUYNE: нам нужно будет использовать метод AEAD и изменить способ шифрования <sarang> вероятно, в конечном итоге мы включим в него все зашифрованные данные получателя, что намного лучше с точки зрения самого протокола <sarang> отдельный AEAD тег <sarang> Тем не менее <sarang> Мы приближаемся к концу нашего часа <sarang> Другие моменты, связанные с этим исследованием? <Isthmus> gg <sarang> Я думаю, что это является дополнительным свидетельством того, что применение стандартных TLV полей в tx_extra было бы очень кстати <sarang> и данные показывают, что нет очевидных вариантов использования нестандартных полей <sarang> Хорошо, есть ли другие темы для исследований, которыми можно поделиться до окончания встречи? ⇐ vtnerd_ вышел <sarang> Если нет - мы заканчиваем → vtnerd_ подключился <sarang> Спасибо всем за участие --- Источник: Research meeting: 23 September 2020 @ 17:00 UTC #510 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
