Когда: Среда, 29 января 2020 г., 18:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты Журнал встречи: <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» - это прямо история моей жизни <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> мне очень лестно наблюдать в последнее время такой интерес к исследованиям <sarang> становится всё труднее идти нога в ногу с прогрессом и везде поспевать <sarang> во всяком случае, спасибо, что пришли, мы объявляем перерыв! Источник: Research meeting: 29 January 2020 @ 18:00 UTC #432 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
