Когда: Среда, 8 января 2020 г., 18:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты <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)
