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

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

  1. Unholy

    Unholy Well-Known Monerano

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

    Повестка дня:
    1. Приветствия
    2. Круглый стол
    3. Вопросы
    4. Ключевые моменты
    <sarang> ВСЕМ добро пожаловать
    <almutasim> Hi.
    <binaryFate> hi hi
    Isthmus запускает волну из рук
    <sarang>
    Давайте сразу начнём с круглого стола
    <sarang> Препринт Triptych с новой связываемой конструкцией кольцевых подписей, которую, в свою очередь, можно расширить для использования в транзакциях, уже находится в архиве IACR.
    <sarang> ссылка: https://eprint.iacr.org/2020/018
    TheoStorm вышел (~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl): (Причина: Вышел)
    <sarang>
    CoinTelegraph уже опубликовал статью об этом (но обратите внимание, что в представленных там данных есть ошибки, которые, они сказали, будут исправлены в ближайшее время)
    <sarang> я хочу обновить данные о размере и времени, чтобы правильно учитывать проверку пакетов и обеспечить справедливое сравнение
    <sarang> еще была проделана огромная работа над многоиндексной версией документа Triptych
    <sarang> что еще больше позволит улучшить производительность
    <sarang> также я написал MPC для этой версии Triptych, которая была бы полезна для работы с мультиподписями
    <sarang> и в дополнение я работаю над вопросами, относящимися к разделу математики, которые я уже как-то задавал авторам оригинальной статьи
    <sarang> Кто-нибудь еще хочет поделиться своей исследовательской работой?
    <almutasim> Когда будет подходящий момент, мы могли бы выпустить пресс-релиз статью о Triptych. Monero Outreach может поспособствовать в этом деле. Например, перед тем как всё уйдет на релиз
    <sarang> Чтобы внести ясность - нет никаких гарантий, что Triptych или другая конструкция пригодны для развертывания в основной сети
    <almutasim> точно
    <Isthmus> У меня есть кое-какой анализ *дактилоскопии*, и n3ptune только что закончил довольно крутой сетевой анализ
    <sarang> ОоОоо
    <sarang> Isthmus: Что вам удалось обнаружить?
    <Isthmus> мои заметки о дактилоскопии не являются чем-то новым или выдающимся, просто идея, которая может сделать представление данных более интуитивным. Итак, я думаю о каком-то абстрактном снятии отпечатков с кошелька. Что что-то вроде — если каждая транзакция находится в каком-то углу гиперкуба в многомерном пространстве, состоящем из разных эвристик. Яба-даба-дууу!
    <Isthmus> несмотря на то, что я работаю с наборами логических функций напрямую на сервере, мне нужен рабочий способ выводить результаты
    <Isthmus> моя первая попытка: https://mitchellpkt.github.io/fingerprint.html
    <sarang> Эмм, вы не можете представить себе визуализацию многомерных гиперкубов ? =p
    <Isthmus> lol
    <Isthmus> Это связано с тем, что @suraeNoether добавляет результаты, понятные и читаемые человеком, к сопоставлению своих графиков
    <sarang> Мне нравится такая идея перечисления
    <Isthmus> Спасибо! Он полагает, что это также простой и интуитивный способ передачи данных в виде CSV таблицы с двумя столбцами, и другие заинтересованные могут выполнять сопоставление строк на участках, которые они считают подходящими для данного анализа
    <suraeNoether> Извините-извините! Я тут! Немного не подрасчитал время
    <sarang> Isthmus: Есть ли что-то, что вы могли бы нам рассказать о сетевом анализе, который вы упомянули?
    <n3ptune> Re: я собрал и проанализировал данные и сроки появления блоков от большинства узлов, которые у меня записаны, за последние 6 месяцев
    <sarang> Здорово!
    <sarang> Что в итоге?
    <n3ptune> у Isthmus есть заметки, а мне нужно еще немного доработать мой код. Готовые графики вы можете посмотреть здесь: https://github.com/noncesense-research-lab/archival_network/wiki/Block-propogation-time
    <Isthmus> Это был вопрос, который задал @moneromooo, верно?
    <Isthmus> единицы измерения - это размер в байтах и временные метки в миллисекундах, я ничего не перепутал?
    <suraeNoether> это был мой вопрос ^
    <n3ptune> мы использовали эту формулу, где NRT - это отметка со стороны узла : prop_time_lower_bound(h) = MAX[NRT(h,1), NRT(h,2), NRT(h,3)] - MIN[NRT(h,1), NRT(h,2), NRT(h,3)]
    <sarang> разве там есть изменяющиеся показатели?
    <sarang> это всё разные узлы?
    <sgp_> Доброго времени
    <n3ptune> Да, данные с 4 узлов
    <sarang> понял
    <suraeNoether> таким образом, время опорной точки блока составляет не менее 0,1 сек. Что весьма интересно
    <Isthmus> разброс на графике - высота от темного = старого к светлому = новому
    <Isthmus> ^ цветовая градация
    <sarang> И каковы различия между меткой времени, сообщаемой майнером, и временем узла при ее получении?
    <Isthmus> Отметки времени, которые сообщает майнер, нигде в этом исследовании не рассматриваются
    <Isthmus> но мы сделали это исследование в другом тесте
    Isthmus копается в github
    <suraeNoether>
    хм, что тогда измеряется в качестве времени опорной точки?
    <sarang> получается, что эти блоки передаются только между вашими узлами?
    <sarang> и где вы смотрите местное время при отправке и получении?
    <Snipa> ^ хороший вопрос! минимальное время распространения кажется низким, так как 100 мс это критично мало, учитывая время, которое необходимо для распространения по всей сети
    <sarang> Хорошо, я перефразирую вопрос: как рассчитывается NRT
    <n3ptune> это разница во времени между узлами, получающими одинаковые блоки
    <sarang> понял
    <Isthmus> Да, блоки ходят не только между нашими тестовыми узлами
    <n3ptune> NRT берётся из системного времени узла, когда приходит блок
    <sarang> Значит, независимо от того, кем он был получен
    <sarang> (что будет разниться)
    <sarang> было бы интересно увидеть разницу между сообщаемым майнером временем (которое может быть неточным) и временем получения информации узлом
    <suraeNoether> хммммм
    <endogenic> o/
    <Isthmus> https://usercontent.irccloud-cdn.com/file/brPsQyeU/image.png
    <Isthmus> это для тебя, @sarang
    <sarang> что мы действительно видим на этом графике, так это не время распространения, а неустойчивость в одном слое временного распространения
    <sarang> здесь = начальные участки
    <Snipa> Мне нужно проверить логи пула, и я смог бы предоставить дополнительные данные, если, конечно, вам это интересно. Мы начали регистрировать разницу во времени, когда узел находит блок и когда этот блок сохраняется в локальной базе данных, что в свою очередь подразумевает, что он обрабатывался локальным узлом
    <suraeNoether> дела...
    <suraeNoether> здорово
    <sarang> очень большой показатель времени
    <Isthmus> @Snipa, великолепно!
    <Isthmus> «что мы действительно видим на этом графике, так это не время распространения, а неустойчивость в одном слое временного распространения» < можете уточнить?
    <suraeNoether> хорошо, это то, сколько времени требуется блоку для ретрансляции от одного узла к другому
    <sarang> Я имею в виду, что для таких графиков, которые вы показали, нельзя напрямую интерпретировать время ретрансляции блока вашим узлом сразу после того, как он найден
    <sarang> suraeNoether: нет
    <suraeNoether> нет?
    <Isthmus> Да, именно по этой причине мы отметили все оси как «нижняя временная граница»
    <Isthmus> кроме того, мы можем утверждать тот факт, что где-то в штате Небраска есть *старый компьютер* с очень медленным подключением к сети, но это не имеет смысла
    <sarang> suraeNoether: он смотрит на разницу во времени получения, неважно какой *маршрут* проделал блок
    <Snipa> Хм, на самом деле я смогу предоставить данные глобального распространения блоков, так как у каждого узла есть лог, который мы можем посмотреть
    <Isthmus> @Snipa, да! Было-бы отлично!
    <suraeNoether> sarang, да, верно
    <n3ptune> Да, было бы отлично получить такие данные
    <Isthmus> Мы кое-что забыли:
    <Isthmus> в нашем уравнении не хватает злоумышленника
    <Snipa> пинганите меня чуть позже, и мы сможем всё подробно обсудить и рассмотрим формат данных
    <Isthmus> Конечно! Спасибо!
    <suraeNoether> у вас уже есть два источника информации, которые настроены на определение времени распространения, но вам нужно 3 для триангуляции, аля сейсмическое обнаружение эпицентров
    Isthmus ставит разговор на паузу и обещает вернуться через 3-6 минут
    <sarang>
    Isthmus, не оставляй нас с этим наедине!
    <suraeNoether> я уже себе места не нахожу
    <suraeNoether> и еще пролил чай
    <suraeNoether> если бы не он, я загорелся бы из-за любопытства, что подогрел isthmus
    <sarang> просто подождите его на остановке... Автобус любопытства Isthmus скоро должен появиться
    <sarang> а пока мы его ждём, у кого-то еще есть интересная работа??
    <sarang> очень интересная работа
    <suraeNoether> пока мы ждем Isthmus, я предоставлю своё краткое обновление: после некоторых обсуждений с endo мой код стал работать значительно эффективнее, стал еще легче для понимания и более дружелюбным для отладки; я сделаю соответствующий коммит немного позже. Вся моя текущая работа сосредоточена на повторном пересмотре документа CLSAG и работой над соответствием
    <n3ptune> Отлично, жду дальнейших обновлений
    <endogenic> теперь его код помещается в одном листе блокнота..
    <suraeNoether> также isthmus и я разговаривали о том, чтобы создать предложение о шифровании всех временных отметок блокировок
    <sarang> Вы имеете в виду использование обязательств в стиле DLSAG?
    <sarang> Мы уже обсуждали это на предыдущей встрече
    <suraeNoether> на самом деле мы уже поднимали этот вопрос с isthmus, и я рассматриваю этот шаг как очень хорошее повышение всеобщей конфиденциальности, в том смысле, что это избавляет нас от формализованной информации в больших наборах данных, с которыми работает isthmus
    <sarang> Я могу определить размер и время, если хотите
    <suraeNoether> я не уверен, что это снизит размеры наших транзакций, но мы точно увидим, как это повлияет на конфиденциальность
    <sarang> этот параметр можно будет упаковать в контейнер bulletproof
    <suraeNoether> ^ хм
    <sarang> Да, размер не является проблемой из-за логарифмического масштабирования
    <suraeNoether> да, и время проверки будет быстрое, как яйца гепарда бегущие впереди него
    <suraeNoether> простите, у нас же встреча... я должен быть менее вульгарным.. пожалуйста, примите мои извинения
    <sarang> всё верно ... время проверки линейно увеличивается, но если добавить multiexp всё выравнивается
    <sarang> CoinTelegraph обновили свою статью: https://cointelegraph.com/news/moneros-triptych-research-could-vastly-improve-its-anonymity
    <sarang> Спасибо автору за то, что быстро всё исправил
    <almutasim> Пресс-релизу нужно уделить должное внимание
    <sarang> suraeNoether: самое интересное, это то, что из-за заполнения в bulletproof, для большинства актуальных транзакций не будет увеличение размера, если не считать места, занимаемого данными об обязательствах
    <suraeNoether> cointelegraph молодцы
    <sarang> (в отличие от текстового представления)
    <suraeNoether> sarang: можно ли использовать подобный подход для добавления зашифрованного текста сообщений?
    <suraeNoether> например, moneroMail
    <Isthmus> Извините, кто-то подрался с водителем автобуса прямо на моей остановке
    <sarang> Не совсем... в bulletproofs есть свободное место, которое может содержать 1-2 элемента доказательства или произвольных данных с учётом контроля случайности (мне нужно перепроверить эту информацию)
    <Isthmus> Эх.. Сан-Франциско...
    <sarang> Добро пожаловать, Isthmus
    <Isthmus> Хорошо, дайте мне минуту, догоню нить разговора
    <Isthmus> n3ptune: хотите поделиться обновлениями?
    <Isthmus> для блоков
    <n3ptune> конечно
    <suraeNoether> sarang, насколько я понял, места достаточно для обмена ключами, а не текста?
    <sarang> Ну да, всё упирается в свободное место
    <n3ptune> есть ли какая-то цель у тега tx_extra?
    <sarang> Я не помню точно, Poelstra и его друзья нашли 32 или 64 байта свободного места
    <sarang> n3ptune: это хороший вопрос для moneromooo и компании
    <sarang> Пока мы ждем обновлений от n3ptune, Isthmus, у вас есть еще что-нибудь интересное, чтобы поделиться?
    <sarang> или мы переходим к КЛЮЧЕВЫМ МОМЕНТАМ в соответствии с нашей повесткой
    <suraeNoether> я планирую усердно поработать над комментариями документа clsag, но вряд ли я смогу закончить это сегодня
    <suraeNoether> думаю, на этой неделе я точно закрою этот вопрос
    <Isthmus> назад
    <suraeNoether> вперед
    <sarang> Моя задача состоит в том, чтобы представить CLSAG (после проверки), еще я надеюсь решить вопрос с Omniring и передать обновленный документ его авторам, поработать над обновлением библиотеки кривой EC, которая необходима для проверки концептуального кода, и обновить материалы для препринтов, которые будут размещены на сайте monero
    <sarang> Isthmus: пожалуйста, продолжай
    <sarang> (о, и еще обновить данные препринта Triptych с отображением производительности)
    <Isthmus> https://usercontent.irccloud-cdn.com/file/gAM3VbDV/1578508953.JPG
    <sarang> что это такое
    <Isthmus> Итак, допустим, что у нас работает 100 узлов
    <Isthmus> если у нас есть только 2 узла, то наша схема распространения будет иметь более хаотичный характер и будет зависеть от топологии сети (предположим, что другие узлы не соединены друг с другом и запущены с ключем t_second - t_first)
    <Isthmus> когда мы добавим 3-й узел, он может увеличить время распространения (так как он слушает всё до или после себя), и он не может уменьшить время распространения, так как max-min
    <Isthmus> когда мы увеличим количество до 100 узлов, время распространения, вероятно, выровняется и мы приблизимся к истинному разумному показателю
    <sarang> Разве время распространения не зависит от max-min среди всех других узлов? Таким образом, третий узел может выйти за пределы двух других и повлиять на конечное значение
    <Isthmus> Да, в этом суть
    <sarang> Хорошо, должно быть я неправильно истолковал
    <sarang> мы не можем уменьшить его
    <sarang> ладно, забудьте
    <Isthmus> когда мы добавляем третий узел, есть вероятность (2/3), что он выйдет за пределы N=2 и увеличит время распространения, и вероятность (1/3), что он будет между первыми двумя узлами
    <Isthmus> извините, если я даю какое-то невнятное описание, потому что я понял это, когда ехал в автобусе
    <almutasim> Max-Min - весьма чувствительный показатель, особенно к выбросам
    <Isthmus> Хм, дай мне подумать над этим
    <Isthmus> упустим это сейчас
    <Snipa> Как именно вы *отстаете* от времени, когда получен блок? Вы настроили monerod и читаете его логи или опрашиваете RPC, чтобы определить, когда он был добавлен?
    <Isthmus> Это вопрос к n3ptune, он занимается разработкой данных. Все они оказались в базе данных SQL к тому времени, как я смог дорваться до них
    <n3ptune> настраиваю monerod
    <Snipa> P2P соединение?
    nssy2 подключился (~nssy@197.237.91.81)
    <Isthmus>
    для каждой высоты у нас есть свой эпсилон (зеленая линия), который является временем отставания
    <n3ptune> вы также можете использовать monerod --block-notify, если запускать monerod через скрипт
    <Snipa> --block-notify ожидает момента, когда блок будет записан, поэтому я говорю, что узлы, которые не используют SSD или NVMe, имеют гораздо более медленное время распространения, так как вы ждёте, пока информация будет записана на жесткий диск
    <n3ptune> ваш вариант мне нравится больше, потому что вы используете стандартный демон, но в нашем случае это не подходит
    <sarang> Итак, используя метрику max-min, вы предполагаете, что это выровняет размещение узлов по топологии сети?
    <Isthmus> Да, хотя после комментария @almutasim я хочу рассмотреть несколько других менее чувствительных показателей
    <Isthmus> вставьте все эти эпсилоны в гистограмму
    <sarang> выбросы являются узлами, которые расположены ближе к майнеру или более удалены от него топологически
    <Isthmus> Хм, выброс может сделать только 2 прыжка, но один из них будет очень медленным
    <n3ptune> P2P соединение?: нет, это происходит, когда он добавляет его в цепочку блоков, после того как он определяет, не является ли он блоком из альтернативной ветки. Всё это потому, что у нас была еще одна первоначальная цель - захватить данные из альтернативной цепочки блоков. Патч демона доступен здесь: https://github.com/neptuneresearch/monerod-archive
    <Isthmus> @sarang, это зависит от того, является ли определение топологического расстояния только графом p2p-связи или оно учитывает время между всплесками
    <sarang> верно
    <Isthmus> этот эпсилон - это то, чем n3ptune поделился немногим ранее, за исключением того, что теперь мы использовали max-min с 4 узлами
    <Isthmus> ^это я про X ось на гистограмме
    <n3ptune> --block-notify ждет, пока блок будет записан >> тогда я предполагаю, что этот метод делает это непосредственно в blockchain::add_new_block() или, по крайней мере, это происходит до того, как будет найдено уведомление о блоке, а не *сразу* при получении информации о блоке
    <sarang> Поскольку у нас почти закончилось время, жду от вас *последние* биты информации перед окончанием нашей встречи (обсуждение, конечно, может продолжаться дальше)
    <Isthmus> О да
    <Isthmus> просто замечание — tx_padding используется в реальных условиях намного чаще
    <Isthmus> на графике рассеивания, показанном ранее, вертикальные полосы слева направо являются пустыми блоками, и только затем идут транзакции N=1,2,3...
    <sarang> это вопрос для кого-то вроде moneromooo :)
    <Isthmus> существует разница в горизонтальной ширине и вертикальных полосах из-за различий в размерах транзакций, но переменчивость в блоках только из монетной базы была странной
    <Isthmus> https://xmrchain.net/tx/acdf8eac41a7a76fd899e09640db34023abff66b3ae2c9ea86e49f19c0720af4
    <Snipa> Не совсем, такие блоки из монетной базы довольно распространены из-за дизайна пула
    <Isthmus> нет, размер переменчивости блоков из монетной базы, вот что странно
    <Isthmus> оказывается, некоторые майнеры зачастую используют нулевое заполнение, ради интереса проверьте tx_extra в блоках из монетной базы
    <sarang> gadzooks
    <Snipa> Ничего удивительного
    <Isthmus> как по мне, это выглядит как умышленное заполнение
    <Isthmus> куча блоков с пустым пространством и с нулями в tx_extra
    <Snipa> возможно, что эти поля требует сам пул
    <Snipa> поскольку это заполнение мы используем в качестве дополнительного пространства для хранения nonce
    <Isthmus> «поскольку это заполнение мы используем в качестве дополнительного пространства для хранения nonce» - всё это заполнение транзакций из монетной базы
    <Snipa> извините, это я затупил
    <Isthmus> вы знаете, почему некоторые майнеры используют заполнение, а другие нет?
    Isthmus смотрит на всех майнеров с наивным взглядом
    <Snipa>
    мне нужно посмотреть это в коде
    rex4539 вышел (~rex4539@balticom-197-78.balticom.lv):
    sech1 вышел (~sech1@31-208-119-248.cust.bredband2.com): Причина: Ошибка подключения
    <Isthmus>
    вот сравнение
    <Isthmus> https://xmrchain.net/search?value=1988283
    <Isthmus> и
    <Isthmus> https://xmrchain.net/search?value=1985042
    <Isthmus> они выглядят точно так же, кроме отличия в заполнении
    Isthmus завершает свой ход мыслей
    <Isthmus>
    В любом случае спасибо, что позволили поделиться своими мыслями
    <Snipa> для ознакомления: CB TXN блока содержит раздел «extras», который запрашивается у Monerod как дополнительное пространство, в которое могут быть помещены произвольные данные. Эти данные используются различными реализациями пула для одноразовых номеров в ключе каждого пула, а также любых данных пользователя или одноразовых номеров, используемых более продвинутыми методами
    sech1 подключился (~sech1@31-208-119-248.cust.bredband2.com)
    <Isthmus>
    «как дополнительное пространство, в которое могут быть помещены произвольные данные»
    Isthmus съеживается
    <Snipa>
    Вы можете использовать эти данные различными способами, особенно, если знакомы с дизайном настроек пула, но все основные реализации пула используют это пространство одинаково
    <Isthmus> и какие текущие варианты использования?
    <Snipa> вы также можете определить, какой именно пул отправил информацию о блоке, так как пулы используют уникальные идентификаторы в определенных байтах
    <Isthmus> я ничего не знаю о дизайне настроек пула
    <Snipa> https://github.com/Snipa22/nodejs-pool/blob/master/lib/coins/xmr.js#L115
    <suraeNoether> для всех тех, кто заинтересован в оказании помощи на MoneroKon 2020 в Берлине, прямо сейчас проходит встреча в соседней комнате. Просто, информация для размышлений
    <Snipa> ^ это реализация, которая лежит в основе пулов, которые поддерживают XNP расширения
    <sarang> Ну вот и всё, мы официально закрываем нашу встречу
    <sarang> всем спасибо!

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

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

    Kukima (@Kukima)
     
  • О нас

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