Когда: Среда, 20 мая 2020 г., 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты Примечание в теме от Mitchellpkt (Isthmus) Обновлено предложение по исследованию времени разблокировки с помощью новых временных данных от sarang: https://github.com/insight-decentralized-consensus-lab/monero_encrypted_unlock_time Кроме того, я продолжаю свой эксперимент с новым приложением для проектирования аватаров морских ракушек. По сути, каждый отпечаток транзакции (метаданные) сравнивается с поведением основного программного обеспечения, и ему присваивается 0 при совпадении или 1 при отклонении. Зацикливание отпечатков создает соответствующую строку отпечатков, которая используется для создания визуализированного хэша. Новые данные могут быть добавлены в исследовательскую ветку блокчейна, чтобы было проще определить, какие транзакции должны быть сгенерированы пользовательским программным обеспечением. Например, первое изображение показывает аватар для транзакций, которые (имитируют) основной графический интерфейс пользователя / интерфейс командной строки, у которого есть отпечаток ...0000, а второе изображение показывает аватар для транзакций, которые включали новые выходы в кольце и, таким образом, производили другую подпись (...0010). Обратите внимание, что эта проблема уже исправлена. Журнал встречи: <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 хуже остальных <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_> Обратите внимание, что я по-прежнему поддерживаю предложение с кольцами только для монетной базы <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)
