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

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

  1. Unholy

    Unholy Well-Known Monerano

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

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

    Обновлено предложение по исследованию времени разблокировки с помощью новых временных данных от sarang: https://github.com/insight-decentralized-consensus-lab/monero_encrypted_unlock_time

    Кроме того, я продолжаю свой эксперимент с новым приложением для проектирования аватаров морских ракушек. По сути, каждый отпечаток транзакции (метаданные) сравнивается с поведением основного программного обеспечения, и ему присваивается 0 при совпадении или 1 при отклонении. Зацикливание отпечатков создает соответствующую строку отпечатков, которая используется для создания визуализированного хэша. Новые данные могут быть добавлены в исследовательскую ветку блокчейна, чтобы было проще определить, какие транзакции должны быть сгенерированы пользовательским программным обеспечением.

    Например, первое изображение показывает аватар для транзакций, которые (имитируют) основной графический интерфейс пользователя / интерфейс командной строки, у которого есть отпечаток ...0000, а второе изображение показывает аватар для транзакций, которые включали новые выходы в кольце и, таким образом, производили другую подпись (...0010). Обратите внимание, что эта проблема уже исправлена.

    1.png

    2.png

    Журнал встречи:

    <sarang> ПРИВЕТСТВИЯ
    <sarang> привет!
    <sgp_> Здравствуйте
    <dEBRUYNE> hi
    sarang ждёт, возможно, кто-то задерживается
    <xmrmatterbridge> <telapongo23>
    привет, ребята, я так просто посижу и послушаю вас, если вы не против :-D
    Isthmus запускает волну из рук
    <hyc>
    привет
    <sarang> Давайте перейдём к КРУГЛОМУ СТОЛУ, где каждый желающий может поделиться своими темами исследований
    <sarang> Кто хочет поделиться своими исследованиями? (Я видел, что Isthmus только что опубликовал свои примечания в повестке этой встречи)
    <ArticMine> Hi
    <sarang> полагаю, что могу поделиться несколькими пунктами
    <sarang> во-первых, я рассмотрю некоторые цифры Arcturus, часть из которых была представлена на прошлой встрече
    <sarang> напомню, что Arcturus - это модификация Triptych, для которой требуется только одно доказательство на всю транзакцию вместо одного доказательства на трату
    <h4sh3d[m]> Hi
    <sarang> (что делает его похожим на RCT3 (обновленный) и Omniring)
    <sarang> а теперь немного самих данных
    <sarang> данные для 1-го входа: https://usercontent.irccloud-cdn.com/file/DYMoX7jy/size-1.png
    <sarang> данные для 2 входов: https://usercontent.irccloud-cdn.com/file/7Hw5Wnsv/size-2.png
    <sarang> данные для 16 входов: https://usercontent.irccloud-cdn.com/file/QzJ03VBI/size-16.png
    <sarang> вы можете увидеть улучшение по мере увеличения количества входов
    <sarang> в дополнение я обновлю результаты прошлой недели...
    <sarang> время проверки для транзакции 1-input/2-output: https://usercontent.irccloud-cdn.com/file/airMJ4pC/timing-1-2.png
    <sarang> время проверки для транзакции 2-input/2-output: https://usercontent.irccloud-cdn.com/file/iZdBR8xe/timing-2-2.png
    <sarang> в связи с этим я работал над новой моделью безопасности транзакций Arcturus, которая использует модель определения баланса по типу Omniring и применяет ее к комбинации доказательств Arcturus и доказательствам диапазона Bulletproof
    <sarang> я опубликую обновление, когда закончу верстку текста и реорганизацию самого препринта в архиве IACR
    <sarang> (данный этап находится в процессе работы)
    <sarang> вопросы по представленному мной материалу?
    <hyc> Arcturus выглядит лучше, чем другие предложенные схемы
    <fort3hlulz> Какой главный недостаток Arcturus по сравнению с другими схемами?
    <fort3hlulz> как по мне, он выглядит как безоговорочный лидер, но, возможно, что я упустил что-то
    <sarang> RCT3 выглядит лучше в плане размера (при рассмотрении всей цепочки), но он работает хуже из-за проверки заполнения входа
    <sarang> и Arcturus полагается на нестандартное предположение о криптографической стойкости
    <hyc> каковы последствия этой нестандартности?
    <sarang> вы можете сами увидеть все оценки для цепочек на 12 странице препринта Arcturus в IACR: https://eprint.iacr.org/2020/312.pdf
    <sarang> обратите внимание, что на 3 рисунке RCT3 выигрывает, но уже на 4 рисунке он сдает свои позиции
    <sarang> (размер и время)
    <sarang> потребуется дополнительное исследование, чтобы понять, можно ли его уменьшить размер до более вменяемых значений
    <sarang> в Triptych нет этого ограничения, и он опирается только на стандартные предположения
    <sarang> я подготавливаю документ к подаче на конференцию и надеюсь получить его качественный обзор
    <sarang> поэтому я хочу обновить модель безопасности до истечения срока подачи документов
    <hyc> выгода очевидна
    <sarang> Triptych и Arcturus почти аналогичны, если мы говорим о времени проверки
    <sarang> из-за того, что генераторы в обоих подходах объединены в пакеты
    <hyc> похоже, что у triptych проблемы с размером
    <hyc> ну почти
    <sarang> Triptych требует нескольких доказательств и содержит в себе некоторые дополнительные элементы (например, смещения обязательств)
    <sarang> в то время как в Arcturus используется всего одно доказательство и не требует дополнительных смещений
    <sarang> (элементы доказательства масштабируются с изменением размера, что смотрится чертовски хорошо)
    <hyc> по крайней мере, все графики линейны без отображения экспоненциального роста
    <hyc> в любом случае я предпочту более оптимальное время проверки
    <sarang> В этом случае Triptych и Arcturus аналогичны
    <sarang> вся разница сводиться к проверке баланса
    <sarang> и разница становиться незаметной при увеличении размера кольца
    <hyc> и Triptych не требует нестандартных предположений
    <sarang> нет
    <Isthmus> "вся разница сводиться к проверке баланса" < спасибо, все встало на свои места
    <sarang> вероятно, я мог бы добавить определение безопасности баланса, применяемого в Arcturus и в Triptych
    <sarang> Isthmus: проверки баланса в MLSAG / CLSAG / Triptych идентичны... учитывайте смещение обязательств и выходы в ноль
    <sarang> в Arcturus он уже встроен в систему проверки
    <sarang> при больших размерах кольца проверка баланса на основе смещения отягощена большим количеством групповых операций, необходимых для оставшейся части процесса проверки
    <hyc> в любом случае размер в Arcturus растёт медленнее, чем в Triptych
    <sarang> как я уже упоминал, при малых размерах колец разница не особо заметна
    <sarang> угу
    <sarang> да и сами элементы трат организованы намного лучше
    <sarang> что не менее важно, так это то, что они используют одну и ту же криптографическую систему Groth, но по-разному
    <sarang> (как и в случае с Lelantus)
    <sarang> во всяком случае, я уже потратил достаточно времени нашего круглого стола!
    <sarang> у кого-нибудь еще есть интересные исследования, которыми они хотят поделиться?
    <Isthmus> TheCharlatan обновил предложение с зашифрованным временем блокировки, опираясь на предоставленные данные о времени: https://github.com/insight-decentralized-consensus-lab/monero_encrypted_unlock_time
    kic0 подключился (~kico@gateway/tor-sasl/kico)
    <sarang>
    s/Tryptich/Triptych/
    <Isthmus> (на основе отзывов с предыдущего собрания MRL и материалов, представленных Сарангом)
    <Isthmus> кроме того, мы продолжаем экспериментировать с новым приложением для проекта аватаров ракушек от surae. Каждый отпечаток транзакции (поведение или метаданные) сравнивается с поведением основного программного обеспечения, и ему присваивается 0 при совпадении или 1 при отклонении.
    <Isthmus> зацикливание отпечатков создает соответствующую строку отпечатков, которая используется для создания визуализированного хэша, и впоследствии они могут быть добавлены в исследовательский блокчейн, чтобы было проще определить, какие транзакции должны быть сгенерированы пользовательским программным обеспечением
    <sarang> Я рад, что данные 3-CLSAG и 3-Triptych оказались полезными
    <Isthmus> Например, первое изображение показывает аватар для транзакций, которые (имитируют) основной графический интерфейс пользователя / интерфейс командной строки, у которого есть отпечаток... 0000
    <Isthmus> https://usercontent.irccloud-cdn.com/file/vjCauM0y/image.png
    <Isthmus> второе изображение показывает аватар для транзакций, которые включали новые выходы в кольце и, таким образом, производили другую подпись (...0010)
    <Isthmus> https://usercontent.irccloud-cdn.com/file/Lzt9vfyJ/image.png
    <Isthmus> (обратите внимание, что эта проблема была исправлена в недавнем обновлении)
    <Isthmus> в любом случае это всего лишь прототип
    <sarang> Значит, хеш-входы - это индивидуально установленные биты? 1 = "то же, что и стандарт", 0 = "значительно отличается"
    ⇐ kico вышел (~kico@gateway/tor-sasl/kico): Причина: Бездействие в течение 240 секунд
    <sarang>
    и это делается по разным характеристикам для входной строки?
    <Isthmus> да
    Isthmus берёт паузу для уточнения информации
    <Isthmus>
    0 = "основной кошелек будет строить транзакцию таким образом"
    <Isthmus> 1 = "основной кошелек никогда не будет строить транзакцию таким образом "
    TheoStorm вышел (~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl): Причина: Вышел
    <Isthmus>
    как в случае с ювенильными участниками
    <sarang> понял
    <Isthmus> Шурэ прокомментировал: «Оболочка может быть фрактальной в зависимости от хеша, визуализированного в 2d, с применением *цветовых схем*, выбранных из семейств цветовых надстроек на основе входного хеша...»
    <UkoeHB_> Что такое ювенильные участники?
    <UkoeHB_> ?
    <Isthmus> Любая транзакция, которая включает в себя кольцо с участником кольца, возраст которого менее 10 блоков (в зависимости от времени его нахождения)
    <Isthmus> https://github.com/monero-project/monero/issues/5712
    <UkoeHB_> о как
    <Isthmus> стандартный кошелек соблюдает правило блокировки на 10 блоков, поэтому они должны быть сгенерированы специальным программным обеспечением
    <Isthmus> теперь это правило консенсуса
    <sarang> как визуальный отпечаток определяет степень нестандартности транзакции?
    <sarang> например, можете ли вы взглянуть на отпечаток и сказать: "Скорее всего, эта транзакция нестандартная!"
    <sarang> (очевидно, вес Хэмминга на входе ответит вам путем проверки)
    <Isthmus> Нет, так как визуальная хеш-функция еще нестабильна
    <UkoeHB_> Вы можете посмотреть на саму строку отпечатка, чтобы увидеть, насколько они отличаются
    <sarang> именно это я имею под весом Хэмминга
    <Isthmus> фактически…. Но только если бы для выбора цветовой шкалы использовался вес Хэмминга......
    <Isthmus> тогда это может быть достигнуто вполне интуитивно
    <Isthmus> например, если шкала цветов (0) с зелёным оттенком
    <sarang> В таком случае в чем вообще заключается польза формы отпечатка?
    <sgp_> Возвращаясь к предложению о времени разблокировки, я все еще думаю, что все предложенные компромиссы не логичны
    <Isthmus> Потому что у 0010 и 0001 разные входные данные
    <sarang> всё правильно
    <sarang> получается, что на самом деле вес Хэмминга просто говорит вам, если фактические строки отличаются
    <sarang> я просто предположил, что вес Хэмминга более используемый компонент в этой схеме
    <sarang> и одна цель состоит в том, чтобы минимизировать это
    <Isthmus> Это зависит от того, насколько важна степень корректности
    <UkoeHB_> я согласен с sgp_, овчинка не стоит выделки
    <Isthmus> С моей точки зрения, 0010, 0001 и 0011 - это 3 разные подписи
    <Isthmus> даже если 0011 хуже остальных :p
    <UkoeHB_> ArticMine: как идут дела с вашим предложением о штрафах?
    <sarang> Пока мы ждем ArticMine, есть какие-либо вопросы по представленному материалу от Isthmus?
    <sgp_> ничего по представленному материалу, но у меня есть вопрос к Isthmus о распределении выходов по монетной базе
    <Isthmus> Привет, @sgp_! Что вы имеете в виду? :- )
    <sarang> мне также было бы интересно увидеть это и в ключе BTC
    <sgp_> привет, Isthmus :)
    <sgp_> как вы знаете, я грежу идеей отделить выходы из монетной базы от других выходов
    <sgp_> в идеале я хотел бы узнать, каковы независимые распределения трат для этих двух категорий
    * kic0 → kico
    <sgp_>
    я подозреваю, что выходы из монетной базы тратятся быстрее
    <Isthmus> мы можем убедиться в этом, вычтя эталонное распределение из наблюдаемого ансамблевого распределения.
    <Isthmus> И разделить его на следующие составляющие:
    <Isthmus> распределение (с учетом монет в кольцах) - reference_distribution
    <Isthmus> распределение (без учета монет в кольцах) - reference_distribution
    <Isthmus> @binaryFate собирался представить этот тип анализа на Konferenco, хотя я не знаю, был ли он разделен по типу выходов
    <sarang> данные из криптовалют по типу BTC были бы очень полезными
    <sarang> в идеале добавочное сравнение Monero с BTC
    cornfeedhobo вышел (~cornfeedh@unaffiliated/cornfeed): Причина: Бездействие в течение 260 секунд
    <Isthmus>
    Я посмотрю, как можно извлечь данные из BTC, из набора данных Google BigQuery.
    <sarang> звучит великолепно!
    <Isthmus> думаю, что можно сделать это через запрос в SQL одной строкой
    <Isthmus> но мои запросы обычно состоят из более чем 20 строк
    <Isthmus> :- P
    <sarang> также было бы интересно посмотреть, как изменились данные BTC со времени публикации статьи Миллера
    <sarang> они использовали две большие группы блоков
    <sgp_> в любом случае мы должны располагать выбором колец только для монетной базы. Если результаты показывают, что распределения настолько велики, то это основная причина для скорейшего разделения монетной базы
    <Isthmus> " Если результаты показывают, что распределения настолько велики, то это основная причина для скорейшего разделения монетной базы" << да, согласен
    DeanWeen вышел (~dean@gateway/tor-sasl/deanguss): Причина: Бездействие в течение 240 секунд
    <sgp_>
    Обратите внимание, что я по-прежнему поддерживаю предложение с кольцами только для монетной базы :p
    <sarang> В интересах экономии времени бы ли еще какие-то исследования, о которых стоит упомянуть?
    <sgp_> Isthmus, на этом у меня все, спасибо
    <UkoeHB_> еще комментарии или замечания?
    <sarang> Реструктуризация транзакций для добавления слоя единообразия и последующего смягчения атаки Януса кажется мне весьма полезной и разумной
    <sgp_> согласен
    <sgp_> трата ресурсов не выглядит особо большой
    <sarang> Особенно с экономией от CLSAG
    cornfeedhobo подключился (~cornfeedh@unaffiliated/cornfeed)
    <Isthmus>
    Я за. Единообразие всегда полезно
    <ArticMine> UkoeHB_, уже почти готово. Я сдержался, чтобы высказать свои мысли, особенно с текущей ситуацией из-за COVID-19
    <ArticMine> обзор будет у меня через пару недель
    <UkoeHB_> Отлично, спасибо :)
    <sarang> Хорошо, наш час подходит к концу, давайте перейдем к КЛЮЧЕВЫМ МОМЕНТАМ
    <sarang> я хотел бы закончить обновление модели безопасности для Arcturus, чтобы обновленный препринт был представлен на рассмотрение для предстоящей конференции
    <sarang> и затем перейду к обсуждению предстоящего аудита CLSAG от Teserakt
    <sarang> кто-то еще?
    <UkoeHB_> В предложении о добавлении транзакций я рекомендую использовать сортированный TLV. Однако это решение еще не полностью резюмировано. Еще одним из вариантов является сохранение «ограниченных тегов» для основных функций (например, зашифрованных идентификаторов платежей, nonce и т. д.). Но отсюда возникает другой вопрос - стоит ли использовать ограниченные теги?
    iDunk вышел (~iDunk@unaffiliated/idunk): Причина: Бездействие в течение 240 секунд
    <sarang>
    Ну, определенно, некоторые теги потребуются для соблюдения консенсуса
    <UkoeHB_> Переход к ограниченным тегам может привести к большей однородности в реализациях пула, поскольку будет фиксированный размер одноразовых номеров для всех майнеров. Однако они могут просто переместить одноразовые номера в теги
    <UkoeHB_> После обновления в дополнительном поле останутся только зашифрованные идентификаторы платежей
    <UkoeHB_> и нонсы для всех майнеров
    <UkoeHB_> так что не думаю, что потребуется соблюдение консенсуса
    <sarang> Оу, TLV же только для поля extra... Правильно
    <sarang> nvm
    <sarang> просто я думал о полях в целом, что не правильно, моя вина
    <UkoeHB_> мы могли бы сделать специальное руководство для одноразовых номеров, точнее, для организаторов пула
    <UkoeHB_> надеюсь, что это поможет сделать пулы и соло-майнеров неразличимыми
    <sarang> Хорошо, еще вопросы или замечания?
    <h4sh3d[m]> Я разместил предложение по атомарному свопу, отзывы приветствуются
    <sarang> ссылка?
    <h4sh3d[m]> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/145
    <sarang> спасибо!
    <sarang> хорошо, в интересах экономиии времени мы заканчиваем нашу встречу. Спасибо всем за участие!

    Источник: Research meeting: 20 May 2020 @ 17:00 UTC #467

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

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