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

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

  1. Unholy

    Unholy Well-Known Monerano

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

    Повестка дня:

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

    <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> хех, у нас масса вариантов использования, просто они еще не готовы в текущей реализации :p
    <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]> Где она будет представлена? Я как раз искал статистику транзакций :D
    <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> :D
    rot вышел
    <cargodog[m]>
    Надеюсь, я смогу создать что-нибудь полезное :D
    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)
     
  • О нас

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