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

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

  1. Unholy

    Unholy Well-Known Monerano

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

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

    <sarang> давайте сразу начнем с ПРИВЕТСТВИЙ
    <sarang> привет!
    <ArticMine> Hi
    kic00 подключился (~kico@gateway/tor-sasl/kico)
    <RingSize937>
    Приветствую
    <Isthmus> Heyo
    <koe> привет
    * kic00 → kico
    <Insight>
    привет
    <atoc> Hi
    <sarang> Давайте перейдем к КРУГЛОМУ СТОЛУ, где каждый может поделиться своими исследованиями, представляющими общий интерес (и мы сможем обсудить любые возникающие вопросы)
    RingSize937 вышел (0c8314ca@12.131.20.202): Удаленный хост разорвал подключение
    <sarang>
    Поскольку на прошлой неделе обсуждалось так много всего и сразу, я постараюсь, чтобы сегодняшнее обсуждение было максимально сфокусированным на прошлых моментах для внесения ясности
    <sarang> У меня есть несколько моментов, которые я хочу упомянуть
    <sgp_> привет
    <sarang> Во-первых, я хотел лучше понять последствия добавления скрытых временных блокировок в сигнатуры CLSAG и разработал реализацию 3-CLSAG на C ++ для тестов производительности
    <sarang> включение временных блокировок сведет на нет преимущества времени проверки при переходе с MLSAG на CLSAG
    maxwilliamson вышел (~maxwillia@gateway/tor-sasl/maxwilliamson): Удаленный хост разорвал подключение
    <sarang>
    но мы все равно получим преимущества по сравнению с MLSAG
    RingSize9001 подключился (0c8314ca@12.131.20.202)
    <sarang>
    аналогичный подход будет работать в Triptych, поэтому я немного переработал код Triptych до 3-Triptych
    <sarang> И просто для полноты картины — я обновил препринт Triptych для IACR с конструкцией d-LRS
    <sarang> Вот тестовый код 3-CLSAG:
    https://github.com/SarangNoether/monero/commit/db33d18bb889043c4bdea6d8582ffe2f6c581d28
    <sarang> и концепт кода 3-Triptych:
    https://github.com/SarangNoether/skunkworks/commit/f7581a385d72baa3dbb60c83e8d856a9335bec1f
    <sarang> обновленный препринт Triptych: https://eprint.iacr.org/2020/018
    → maxwilliamson подключился (~maxwillia@gateway/tor-sasl/maxwilliamson)
    <sarang>
    я также нашел незначительное изменение в существующем тестовом коде CLSAG
    <sarang> и наконец, suraeNoether и я начали заниматься моделями безопасности
    <sarang> вопросы по этим пунктам?
    <koe> мой вопрос не к Сарангу, а к Isthmus – какова на текущий момент распространенность ненулевого значения для времени блокировок транзакций за пределами монетной базы?
    Isthmus начинает копаться в своих записках
    <Isthmus>
    весьма частое явление
    <koe> добавление (или отказ от) зашифрованного времени блокировки частично зависит от того, насколько эффективно она будет использоваться
    <sarang> да, на данном этапе я весьма скептически настроен, это, скорее, любопытство
    <Isthmus> Я думаю, что мы можем вообще удалить это поле (в настоящее время это просто произвольное целочисленное поле) или вообще зашифровать его
    <koe> а вот мне нравится эта идея, это прямое применение концепций, уже используемых в Monero
    <sarang> да, концепция выглядит весьма опрятно
    <Isthmus> мы будем первыми, кто сможет реализовать это?
    <Isthmus> Я думаю, что это станет отраслевым стандартом
    <sarang> Zcash предлагает такую функциональность?
    <sarang> (я не проверял)
    <sgp_> без понятия
    <Isthmus> не думаю, но не уверен на все 100%
    <ArticMine> ZCash имеет серьезные проблемы с масштабированием
    <sarang> В любом случае, будь то Zcash или кто-то еще, это не должно быть определяющим фактором для принятия решения :)
    <sarang> но мне всё равно любопытно
    <Isthmus> Ой, подождите, Zcash унаследовал nLockTime от Bitcoin
    <Isthmus>
    <Isthmus>
    дайте мне минутку, я должен перепроверить
    <Isthmus> и OP_CLTV
    <sarang> В случае реализации было бы разумно объединить доказательства диапазона времени с доказательствами, существующими в Bulletproofs
    <sarang> это означает, что сумма входов с синхронизацией (все входы, если они обязательные) и выходов ограничена
    <koe> у меня вопрос о Triptych: какие потенциальные шаги осталось завершить перед заменой RingCT?
    <sarang> Формальный обзор, определить его влияния на multisig (особенно на аппаратно-ограниченное оборудование) и рассмотрение других вариаций и аналогий кроме Triptych
    <sarang> я еще не исследовал, насколько легко было бы включить временные блокировки в RCT3 с текущей моделью безопасности
    <ArticMine> ^ и еще примерный рекомендуемый размер транзакций для Triptych
    maxwilliamson вышел (~maxwillia@gateway/tor-sasl/maxwilliamson): Удаленный хост разорвал подключение
    TheoStorm вышел (~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl): Причина: Вышел
    <sarang>
    обратите внимание, что, как я уже упоминал на прошлой неделе, в MLSAG нет смысла использовать скрытое время блокировоки из-за проблем с масштабированием
    <sarang> (хотя это технически реализуемо)
    <koe> согласен
    <sarang> ладно, нужно предоставить время для других участников
    <sarang> Кто еще хочет поделиться своими исследованиями?
    <Isthmus> Сетевой стек Zebra выглядит весьма интересно, потенциальные приложения в Monero?
    needmonero90 оглядывается вокруг и занимает свободное место
    <sarang>
    Я видел это вчера!
    <sarang> пост об этом: https://www.zfnd.org/blog/a-new-network-stack-for-zcash/
    <sgp_> круто, обязательно проверим
    <sarang> и соответствующий пост на форуме (но там пока нет активности):
    https://forum.zcashcommunity.com/t/a-new-network-stack-for-zcash/35870
    maxwilliamson подключился (~maxwillia@gateway/tor-sasl/maxwilliamson)
    <sarang>
    Это из исследования Zcash Foundation
    <Isthmus> Monero придерживается единого состояния, верно?
    <sarang> это хороший вопрос, и я не знаю ответа
    <sgp_> ping vtnerd
    <sarang> я думал об этом, но не уверен
    <hyc> даже не уверен, что это вообще подразумевает… единое состояние? что это?
    <hyc> существует агрегатное состояние для ограничения пропускной способности
    <hyc> и синхронизация информации осуществляется по каждому отдельно взятому соединению
    <Isthmus> Так, может быть, мы уже используем подход описанный Zebra?
    <Isthmus> он весьма *элегантен*
    <sarang> Isthmus: у вас есть другие темы, которые вы хотели бы затронуть?
    <hyc> «В отличие от Zcash, который поддерживает фиксированное количество исходящих соединений, мы пытаемся подключиться к как можно большему количеству одноранговых узлов при условии ограниченности ресурсов»
    <hyc> этот подход будет весьма проблематичным для них, так как они используют levelDB / rocksDB
    <hyc> lvelDB/rocksDB требует для хранения тысячи файловых дескрипторов
    <hyc> это будет конкурировать со спросом на дескрипторы сокетов
    <sarang> Интересно... Возможно, этот вопрос стоит поднять на форуме?
    <sarang> один из разработчиков (Генри) открыл соответствующую ветку
    <hyc> Как-нибудь без меня. Я не заинтересован в помощи проекту zcash
    <sarang> ok
    <Isthmus> Я пытаюсь составить график времени разблокировки, но мой ноутбук всё еще упорно борется с набором данных в 1,5 ГБ.
    <hyc> они уже должны были прийти к пониманию, что их выбор базы данных не подходит для сетевой службы, которая использует так много соединений
    <sarang> Isthmus: без спешки!
    <sarang> А пока, koe, ты хотел что-то рассказать нам?
    <koe> Угусь
    <koe> ну, это не совсем исследование, просто моя дорожная карта была немного исправлена, в частности, я хочу получить мнения по поводу элемента koe_11, который позволил бы кошелькам только для просмотра узнать, когда были потрачены средства; элемент koe_9 должен позволить всем реализациям кошелька исключать транзакций до появления RingCT
    <koe> https://www.pdf-archive.com/2020/01/29/moneroroadmapkoe012920/moneroroadmapkoe012920.pdf
    <hyc> как по мне, у koe_11 должен быть самый высокий приоритет
    <koe> также Саранг помог мне разработать децентрализованный протокол CoinJoin-esque (временно называемый JoinMo), который уже доступен в главе 9 текущей версии ZtM2.
    <koe> https://www.pdf-archive.com/2020/01/29/zerotomoneromaster-v1-0-21/zerotomoneromaster-v1-0-21.pdf
    <koe> Ой, 10 главе*
    <sarang> Мне нравится JoinMo, использующий общие секреты для каждого участника, чтобы скрыть сопоставление ввода-вывода
    <koe> Кроме того, rbrunner в свое время проводил исследования интеграции Monero в OpenBazaar и столкнулся с некоторыми проблемами, поэтому мое *исследование* заключалось в разработке решений для этих проблем, я планирую опубликоватьсвой отчет на следующей неделе
    <sarang> Я уделяю особое внимание специфике SAG / LSAG, поскольку ключи предназначены только для уникального выхода
    <sarang> а также я думал о последствиях использования отдельного набора ключей для входных данных
    <sarang> (я имею в виду, ключ = участник)
    <koe> однако интеграция OpenBazaar, вероятно, повлечет за собой большое обновление кодовой базы, чтобы оптимизировать коммуникационные раунды
    <koe> кроме того, следует обновить multisig, чтобы соответствовать статье suraeNoether
    <sarang> Да
    <Isthmus> и еще пункт 10 — я по-прежнему обеспокоен тем, что любой наблюдатель в блокчейне может определить, какие именно транзакции не включают выходные данные для подадресов
    <Isthmus> n3ptune и я занимаемся этим графиком :)
    <Isthmus> и да, в идеальной вариации такого не должно быть
    <sarang> да :)
    <sarang> ранее было предложено стандартизировать формы ключей для каждого выхода
    <sarang> но этот консенсус не получил распространения
    <sgp_> koe: хороший список! Пункт koe_9 может быть спорным пунктом, так как траты pre-rct будут выделяться больше других, разве нет?
    <atoc> да, отличный список, koe
    <koe> да, я взял это в расчет
    <koe> такая проблема будет актуальна и для RingCT, так как траты старых выходов всегда несколько непредсказуемы
    <koe> и мое предложение состоит в том, чтобы начать использовать *предварительно* правильные выходы в качестве приманки,
    <hyc> а также, если бы мы сказали всем *подметать за собой следы*, это тоже было бы слишком очевидно, да? Возможно, стоит рассмотреть вариант, где каждая транзакция с входами pre-RCT возвращается к своему отправителю
    <koe> гамма выбирается из всех выходов
    <sgp_> koe: в настоящее время в качестве приманки мы выбираем rct выходы случайным образом?
    <koe> да, и из монетной базы (не уверен, включены ли pre-ringct из монетной базы)
    <koe> в то время как выходы из монетной базы включены как приманка в обычных транзакция (отсюда и идут корни этой идеи)
    <sgp_> тогда это на самом деле делает pre-rct трату менее подозрительной
    <sarang> обработка выходов из монетной базы еще не решена
    <Isthmus> Это на 80% шутка: мы добавляем кольца Koe_9 и sgp_coinbase_only, *но* в свою очередь требуем, чтобы каждый из них включал N монетной базы и M транзакций pre-ringCT для фиксированных параметров консенсуса N и M
    <sarang> sgp_: хвостовая эмиссия быстро рухнет
    <sgp_> sarang: ну, это ближе к нулю, а что дальше от нуля — хуже... как-то так
    <sarang> Да, но предоставляет не намного больше информации
    <Isthmus> https://usercontent.irccloud-cdn.com/file/R26YQwiJ/image.png
    <Isthmus> ^ забавно то, что все они гипотетически разблокируются на высотах 2 и 12 в 2014 году
    <sarang> Вы имеете в виду нестандартную обработку этого поля?
    <sarang> (и что она должна быть стандартизирована)
    <sgp_> Isthmus: хм, мне нужно услышать намного больше информации о том, сколько людей на самом деле тратят pre-rct по сравнению с монетной базой. Моя интуиция склоняется к отказу от такого решения
    <ArticMine> задействуйте один поддельный предварительный выход RingCT, если реальный выход ringct не является предварительным
    <Isthmus> @sarang: Да, в данный момент в поле разблокировки находятся 3 объекта:
    <Isthmus> https://www.irccloud.com/pastebin/0Y87gTTq/
    <Isthmus> оу, извините
    <Isthmus> небольшие целые числа (например, 12), которые преимущественно интерпретируются как разница в высоте, то есть «разблокировка через 12 блоков»
    <Isthmus> большие целые числа, такие как «1980000», предположительно должны интерпретироваться как высота блоков
    <Isthmus> очень большие целые числа, такие как «1578561720», предположительно интерпретируемые как метки времени Unix
    <sarang> угу
    <atoc> и еще я работаю над реализацией первой версии атомарного свопа xmr-btc на Rust
    <atoc> дополнительная информация будет здесь:
    https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/whitepaper/xmr-btc.pdf
    <sarang> atoc: вы определили подходящий ZKP?
    <sarang> помимо таких очевидных вещей, как обработка *несоответствующих* участников и т. д., zkp, пред-образ или случай, где hash / log не будет указан
    <atoc> документ предлагает две транзакции для каждого токена
    <sarang> угу
    <atoc> хорошо, я посмотрю, указан ли zkp
    <atoc> однако я еще не работал над частью обмена
    <atoc> и мне еще нужно перечитать сам документ
    <sarang> Да, вы должны будете заметить, что потребуется конкретное доказательство того, что пре-образ хеша и пре-образ дискретного журнала равны
    <sarang> Для этого можно использовать Bulletproofs с подходящей схемой
    <atoc> понял
    nssy2 подключился (~nssy@197.237.91.81)
    <sarang>
    В документе Bulletproofs есть упоминание о такой схеме, но мне сказали, что она предназначена только для тестирования и пока не подходит для любой попытки реализации
    <atoc> хорошо, я учту это
    <atoc> и возможно, что мы увидим, работает ли эта схема нормально, а если нет, то надеюсь, что мы сможем найти пути к её улучшению
    <sarang> koe: спасибо за дорожную карту; приятно видеть много предложений, собранных в одном месте
    <sarang> возможно, стоит открыть какие-то пункты для обсуждения?
    <sgp_> Я голосую за два предложения, связанных с майнинг пулами :)
    <atoc> Саранг, я отправлю вам ссылку на мой репозиторий, как только закончу кое-какие рабочие моменты
    <sarang> хотя.. основная часть дискуссий происходит в IRC
    <sarang> спасибо, atoc
    <atoc> отлично, буду ждать ваши отзывы
    <sarang> буду рад помочь
    <sarang> спасибо за вашу работу
    <koe> конечно, я могу сделать отдельные комментарии в github
    <atoc> на этой неделе я просто знакомился с различными методами атомарного свопа
    <atoc> и библиотеками в Rust
    <sarang> koe: Я бы отметил, что все, что требует постоянных исследований, подходит как нельзя лучше для исследовательской лаборатории ;)
    * rottensox_ → rottensox
    <sarang>
    Но я не пытаюсь каким-то образом ограничить или задать планку!
    <sarang> Хорошо, у нас осталось порядка ~10 минут (следом за нами будет еще одна встреча - 19:00 UTC Monero Konferenco)
    <koe> хорошо
    <sarang> еще какие-то темы исследований, которые не были затронуты на сегодняшней встрече?
    <atoc> Саранг, вы рассматривали создание аналогичного списка?
    <sarang> вы про тот, над которым работаю лично я?
    <atoc> ну или какой-то невидимый список с возможными работами и исследованиями
    <sarang> нет, никогда не задумывался о таком
    <sarang> аналогичная тема в Github не пользуется особым спросом
    <atoc> я думаю, что важно опубликовать такой список, чтобы просмотреть на самые важные темы и исследования для Monero
    <sarang> да, но стоит учитывать, что большая часть обсуждения происходит в IRC в режиме реального времени
    <atoc> да, конечно
    <sarang> только если использовать их как памятку
    <atoc> ладно, я возвращаюсь к основной теме, а вы в свою очередь подумайте о таком списке
    <sarang> я не хочу, чтобы люди *копались* в ключе какого-то вопроса в журналах IRC
    <sarang> конечно, я оформлю несколько вопросов
    <sarang> мы еще должны устранить старые проблемы
    <nioc> арахисовая галерея здесь! Теперь, когда соответствующий проект Шурэ и Саранга завершен (?) или почти завершен, каков ваш дальнейший план действий?
    <atoc> «*копались* в ключе какого-то вопроса в журналах IRC» - это прямо история моей жизни:D
    <sarang> nioc: отличный вопрос для suraeNoether!
    <sarang> в последнее время он работает над моделями безопасности LRS
    <sarang> (из-за которых и задерживается обзор документа CLSAG)
    <sarang> хорошо, давайте перейдём к КЛЮЧЕВЫМ МОМЕНТАМ
    <sarang> я занят написанием материала о доказательствах / утверждении транзакций и пишу новый код для InProofV2 и OutProofV2
    cohcho вышел (~cohcho@gateway/tor-sasl/cohcho): Удаленный хост разорвал подключение
    <sarang>
    помимо обновлений модели безопасности я занят работой по пересмотру доказательств в ключе хранения данных, ну и другие мелочи...
    <sarang> Кто-то еще?
    cohcho подключился (~cohcho@gateway/tor-sasl/cohcho)
    <atoc>
    мне предстоит разобраться с mkW в моём приватном репозиторий .git (с реализацией атомарного свопа) и затем перенести всё в Github
    <sarang> понятно
    <koe> мои пункты: multisig и условное описание протоколов, возможно, что я еще начну работу над материалом bulletproof, если позволит время...
    <sarang> BPs для ZtM, верно?
    <Isthmus> а я хочу создать веб-сайт, на котором вы можете ввести адрес (или список адресов) и посмотреть, какие транзакции использовали их в качестве участников кольца
    <Isthmus> но мне еще нужно поработать над серверной частью
    <koe> ну или хотя бы попытаться перечитать его
    <Isthmus> думаю, что соответствующая часть будет обрабатывать выходы, которые не участвовали в других кольцах, имеют только одно состояние траты и не могут быть попадать под характеристику правдоподобного отрицания
    <sarang> дайте мне знать, если у вас будет какие-то конкретные вопросы, на которые я смогу ответить
    <koe> конечно :)
    <sarang> заключительные мысли или комментарии по любому из пунктов?
    <sarang> (от кого угодно)
    <koe> на самом деле я уже и так рассказал вам слишком много спойлеров из черновика ztm2
    <sarang> мне очень лестно наблюдать в последнее время такой интерес к исследованиям :D
    <sarang> становится всё труднее идти нога в ногу с прогрессом и везде поспевать
    <sarang> во всяком случае, спасибо, что пришли, мы объявляем перерыв!

    Источник: Research meeting: 29 January 2020 @ 18:00 UTC #432

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

    Kukima (@Kukima)
     
  • О нас

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