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

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

  1. Unholy

    Unholy Well-Known Monerano

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

    Повестка дня:
    1. Приветствия
    2. Круглый стол
    3. Вопросы
    4. Ключевые моменты
    Прочие обновления:
    • Количество выходов в транзакции
    По большей части это уже историческое новшество, реализованное во времена, когда XMR имела номинальную стоимость. После того как на блоке 1 400 000 использование RingCT стало обязательным, все майнерские транзакции получили формат 1OTX.

    1.png
    • Майнерская транзакция tx_extra
    Кажется, что все используют tx_extra по-разному, включая совершенно экстраординарные случаи с множеством блоков с 60 B нулевого заполнения (??!): https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a

    Существуют объективные причины, по которым майнинг пулы используют её для того, чтобы отличить действительно рабочие майнеры от всех остальных. Однако возможно, стоит стандартизировать процесс? На данный момент у всех имеется собственный специализированный вариант реализации дополнительного поля, так, может, безопаснее было бы выделить для этого фактическое пространство (возможно, поддерживающее до 100 миллиардов рабочих майнеров на пул или нечто достаточно большое, чтобы ни у кого не было повода для оправдания поиска обходных путей). Я не уверен на сто процентов, какие специальные дополнения следует встроить, но я точно знаю, что мы можем сделать это, если захотим. Или даже лучше: можно было бы реализовать те же технические требования вне блокчейна или поделив диапазон нонса, или сделав нечто подобное.

    ПРИМЕЧАНИЕ. К моменту публикации этого сообщения логистика была проработана и проанализирована Исследовательской лабораторией Monero.

    2.png

    Это влияет на анонимность всех пользователей. Например, у меня есть список блоков, вычисленных в пуле и добавивших 60 B нулевого заполнения в каждую майнерскую транзакцию. Когда подобный пользователь создаёт транзакции с множеством входов, чтобы получить вознаграждение, кольцевые подписи не могут защитить их. Множество выходов в сочетании с идентификационной меткой майнера дают слишком много статистической информации, и мы можем узнать, когда действительно были потрачены эти выходы, и сможем вычислить их в качестве ложных в других транзакциях.

    Во избежание такой ситуации важно, чтобы любой вариант реализации воспроизводил всю иерархию на любом блоке. Например, если мы предоставляем {нонс, пул, прокси-сервер}, то каждый майнер (включая программное обеспечение для соло-майнинга) должен оставлять в пуле и на прокси-сервере случайные данные. В противном случае мы просто обеспечиваем более причудливый способ оставить ту же идентификационную метку :-Р
    • Альтруистический выбор транзакций
    Другим историческим новшеством является альтруистический выбор транзакций майнерами, которые предпочли бы включать множество или большие транзакции, что подразумевает штраф coinbase, который не компенсируется дополнительными комиссиями (другими словами, они бы пытались получить более высокую общую выплату за блок при вычислении пустого блока).

    3.png

    4.jpg

    Ах да, что касается зашифрованного и принудительного времени разблокировки — тут нам необходимо принимать решение, касающееся используемого формата. В настоящее время поле разблокировки включает в себя три вещи:
    • небольшие целые числа (например, 12), которые преимущественно интерпретируются как разница в высоте, то есть «разблокировка через 12 блоков»;
    • большие целые числа (например, 1 980 000), которые преимущественно интерпретируются как высота блоков;
    • большие целые числа (например, 1 578 561 720), которые преимущественно интерпретируются как временные метки unix.
    Несмотря на то, что при обычных обстоятельствах я едва ли стал бы привязывать реальное время к блокчейну, я склоняюсь к использованию следующего подхода: зашифрованное время разблокировки должно стать будущей временной меткой, записанной в unix секундах, и каждое кольцо должно включать в себя доказательство диапазона, позволяющее сравнить время разблокировки с самым «старым» или «молодым» членом кольца (я пока не достаточно тщательно продумал эту схему).

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

    Зашифрованное время разблокировки, по сути, может определяться временной меткой (1 500 000 000), что позволит сэкономить немного места за счёт устранения смещения времени между 1970 и размещением, но это требует дополнительной работы.

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

    <sarang> Приветствия
    <binaryFate> hi!
    <sgp_> привет
    <suraeNoether> Hi
    kico подключился (~kico@gateway/tor-sasl/kico)
    <koe>
    hiya
    <Isthmus> holla
    <sarang> Давайте сразу перейдем к нашему КРУГЛОМУ СТОЛУ
    <sarang> Isthmus, вы поместили информацию в повестке дня, хотите это обсудить?
    <sarang> ссылка на повестку дня: https://github.com/monero-project/meta/issues/430#issuecomment-576455137
    <Isthmus> конечно
    <Isthmus> Во-первых, я посмотрел на распределение количества выходов в транзакциях
    <Isthmus> https://usercontent.irccloud-cdn.com/file/OB2UWpjs/image.png
    <Isthmus> и по большей части это уже историческое новшество, реализованное во времена, когда XMR имела номинальную стоимость. После того как на блоке 1 400 000 использование RingCT стало обязательным, все майнерские транзакции получили формат 1OTX.
    <Isthmus> *транзакции с одним выходом
    <sarang> получается, что на этом графике отображены *все* транзакции?
    <sarang> и за всё время?
    <Isthmus> начиная с genesis-блока и до прошлой недели
    <Isthmus> данные предоставлены из «волшебной» базы данных n3ptune xD
    atoc подключился (2fb9c5f1@47.185.197.241)
    JamesNZ подключился (~JamesNZ@fedora/JamesNZ)
    <Isthmus>
    Еще одна причина — это выбор майнерами *альтруистических* транзакций, которые должны включать намного больше данных в блоки, получая штраф на монетную базу, который не компенсируются дополнительными сборами (другими словами, они могли получить более высокую выплату за блок, чем за пустой блок)
    <Isthmus> https://usercontent.irccloud-cdn.com/file/0pcNROcT/image.png
    <Isthmus> цвет - это размер, синий – это наименьший
    <Isthmus> похоже, что это не очень распространенная практика в нынешних реалиях
    <Isthmus> *альтруистический майнинг* может быть запрещен на уровне протокола, но на данный момент я не вижу весомого обоснования делать это
    <koe> на этой неделе я закончу свой прототип вариации кода для так называемого *альтруистического майнинга*, основанный на субоптимальном добавлении транзакций в блок и их анализ
    <suraeNoether> сравнение с частично заполненными блоками, не с пустыми?
    <Isthmus> @koe, вы хотите помочь нам?
    <sarang> Да, koe, это будет отличная работа
    Isthmus выходит из автобуса и вернётся к разговору через 5 минут
    Isthmus выключает горелка Бунзена и сворачивает IRC
    <sarang>
    koe: у вас есть ссылка на прототип кода?
    <koe> на этой неделе я по просьбе Isthmus занимался написанием кода для анализа блокчейна, провёл корректуру нескольких глав ZtM, поговорил с cohcho и jtgrassie об однородности монетной базы транзакций
    <koe> и еще набросал примерную дорожную карту для будущих разработок Monero: https://justpaste.it/5io6e
    <koe> в последние правки ZtM еще не попали все правки о multisig https://www.pdf-archive.com/2020/01/22/zerotomoneromaster-v1-0-20/zerotomoneromaster-v1-0-20.pdf
    <sarang> добавление точного и определенного вознаграждения за блок кажется весьма простой и хорошей идеей
    <koe> ссылка на прототип: https://paste.debian.net/1127152/
    <sarang> Что касается редактуры ZtM — у вас есть темы или отдельные вопросы, по которым вы хотели бы получить конкретную информацию или помощь?
    <koe> в настоящее время я работаю над multisig и уже успел прочитать большую часть имеющейся документации, но у меня всё еще есть некоторые моменты, которые я не понимаю
    <koe> если у вас есть что-то, что поможет мне или прольёт свет на мои вопросы, пожалуйста, дайте мне знать
    <koe> в противном случае я переключусь на работу с кодовой базой
    <suraeNoether> я не очень хорошо знаком с кодовой базой, но я знаком с тем, что она должна представлять из себя
    <sarang> спасибо, koe
    <suraeNoether> так что если у вас есть вопросы о том, как все должно работать (по сравнению с тем, что мы видим в настоящий момент)
    <suraeNoether> дайте мне знать
    <koe> хорошо, спасибо
    <sarang> что-нибудь еще интересное, чтобы поделиться, koe? Вы явно были заняты!
    <koe> все основные моменты я указал в дорожной карте, в частности, изменение обязательного выхода из монетной базы (Isthmus обнаружил, что все транзакции из монетной базы за последние 4 года были одним выходом) и, возможно, применение одиночной концепции участника в кольце (только в кольцевых эмболах, по типу rcttypebulletproof2), поскольку 99,5% выходов из монетной базы принадлежат пулам
    <koe> что подразумевает вероятность дактилоскопии
    <sarang> в прошлом sgp_ уже поднимал вопрос в ключе одиночной концепции
    <koe> только взгляните: https://minexmr.com/pools.html
    <sarang> меня беспокоит то, что полная сегрегация выходов из монетной базы подразумевает, что часть эвристик переместится «вниз по цепочке»
    <sarang> это означает, что наверняка будут улучшения, но, скорее всего, более незначительные, чем хотелось бы
    lithiumpt подключился (~lithiumpt@152.89.162.252)
    <atoc>
    koe, вам нужна помощь в корректуре ZtM или вы справитесь самостоятельно?
    <suraeNoether> я уже давно продвигаю идею с ограничением выходов из монетной базы до одного выхода путем консенсуса. Я за то, чтобы фиксировать вознаграждение за блок
    <koe> его постоянно нужно будет корректировать :) даже после публикации я получил несколько писем с замечаниями и советами, которые были включены в v2
    <sgp_> да, было такое дело… и на самом деле я хотел бы поднять эту тему опять
    <sgp_> ссылка: https://medium.com/@JEhrenhofer/lets-stop-using-coinbase-outputs-da672ca75d43
    <atoc> koe, у меня тоже есть несколько замечаний
    <atoc> и я постараюсь в ближайшее время отправить их вам
    <koe> с нетерпением жду :)
    <moneromooo> принудительное использование одного выхода для транзакций из монетной базы могло бы предотвратить использование p2pool.
    <atoc> да, конечно :)
    <suraeNoether> Atoc, я полагаю, что моя ветка mojojo больше не будет такой проблемной, хотя данные всё еще не записываются в файл так, как я хочу. Скрипт трассировки, который я запускаю, будет доступен в ближайшее время
    <koe> jtgrassie, p2pool это ваш проект?
    <moneromooo> насколько мне известно, еще никто этим не занимался.
    <suraeNoether> теперь симулятор успешно имитирует моноэкономику между Алисой, Евой и Бобом для моделирования предпочтения EABE
    <atoc> suraeNoether, блин, здорово! Нужно будет наверстать
    <atoc> хорошо слышать, что юнит-тесты работают
    <atoc> отлично
    <suraeNoether> отлично, рад слышать
    <sarang> Есть еще вопросы / комментарии для koe?
    <sgp_> ничего конкретного, но у меня есть связанная тема о майнинг пулах, помимо вопроса о выходных данных из монетной базы
    <sarang> ладно, продолжаем, Isthmus вернулся? Он ненадолго отстранялся об беседы
    Isthmus уже вернулся
    <sarang>
    Isthmus: вы не хотите закончить свой отчет?
    <Isthmus> это вам не «катить колесо с горки», здесь все зависит от того, как именно вы всё реализуете
    <sarang> (или мы можем перейти к вопросу sgp_)
    <Isthmus> да, двигаемся дальше
    <sarang> постойте
    <Isthmus> кажется, что все используют tx_extra по-разному, включая совершенно экстраординарные случай с множеством блоков с 60 B нулевого заполнения (??!): https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a
    <sarang> почему не сделать это ограничением только для монетной базы?
    <sarang> я согласен, но только если вы предполагаете, что структура трат будет достаточно вариативной
    <Isthmus> Хм, не уверен
    <Isthmus> примерно на 4 уровнях
    <Isthmus> lol
    <Isthmus> С точки зрения всей «цепочки», мы можем задать два вопроса
    <Isthmus> 1) Это кольцо использует монетную базу
    <suraeNoether> секунду, дайте мне поудобнее устроиться под моим шезлонгом
    <Isthmus> 2) На какую именно транзакцию монетной базы тратится это кольцо?
    <Isthmus> #1 это трудно сокрыть
    <Isthmus> #2 как это осуществить
    Isthmus уточняет:
    <Isthmus>
    оставить #2 без ответа
    <Isthmus> если я недобросовестный обменный сервис
    <Isthmus> в текущих реалиях я могу определить, с какими пулам работают мои пользователи
    <Isthmus> «этот пользователь делает ежемесячные депозиты, которые представляют собой транзакции с 4 входами, каждый из которых используется в кольце с нулевым заполнением 62 B, так что я могу полагать, что он использует minexmr.com и его мощность порядка 3000 H/s»
    <Isthmus> *каждая трата из монетной базы, где используется tx_extra...
    <Isthmus> но мы сведем на нет любую связь, если будем использовать только транзакции из монетной базы
    <sarang> справедливо
    <Isthmus> если я обменный сервис, то я могу проверить всех таких пользователей, где их среднее количество будет равно другим транзакциям
    <Isthmus> и если их больше, чем выходов из монетной базы, то я бы заподозрил, что они все майнеры
    <Isthmus> у меня почти всё
    <sgp_> в то время как существуют реальные проблемы, связанные с тем, что только в монетной базе всего один слой разделения, то реальные преимущества минимизируются, особенно для рядовых пользователей, которые не занимаются майнингом
    <koe> Кроме того, монетная база в настоящее время *захламляет* обычные кольца, так как большая часть идентифицируемых выходов уже израсходована
    <sarang> koe: новый алгоритм обоснованного выбора в некоторой степени должен помочь (относительно размера транзакций)
    <suraeNoether> еще одна вещь, которая важна в отношении конфиденциальности, заключается в том, что третья сторона, которая владеет такими данными, будет настоящим магнитом для адвокатской работы. Если биржа не сможет идентифицировать привычки своих пользователей, в перспективе они не будут вызваны в суд для дачи показаний об их клиенте
    Isthmus согласен с последними комментариями
    <Isthmus>
    В моем «идеальном мире» у нас 13 участников в кольце и два алгоритма выбора. 11 участников не являются выходами из монетной базы выбранными с помощью текущего алгоритма, и только 2 оставшихся участника подбираются самостоятельно с помощью второго алгоритма
    <sgp_> Isthmus: звучит весьма логично
    <sgp_> также хотелось бы отметить, что вам нужен набор не менее 3-х
    <Isthmus> Ох, я назвал случайные числа :)
    <Isthmus> просто для примера
    <Isthmus> (я пытаюсь избежать ошибочного представления о том, что настройка алгоритма выбора колец в монетной базе каким-то образом будет нулевой суммой с частью набора анонимности)
    <nioc> koe: Я знаю, что rbrunner занимался реализацией multisig, так что тебе нужно поговорить с ним. Хотя, я довольно давно не видел его в сети
    <koe> еще мне интересно, насколько сильно навязанные типы колец реагируют на то, как люди их используют, хотя то же самое можно сказать и о многих других правилах протокола...
    <sarang> похоже, я вклинил свои «пять копеек» во время разговора Isthmus, прощу прощения...
    <Isthmus> M – это минимально вероятный возраст между любым выходом и его ближайшим предком из монетной базы
    <Isthmus> :- P
    <Isthmus> Это может быть как вариативная функция, так и заранее фиксированная для всех транзакций
    <koe> nioc, окей, спасибо, понял
    <Isthmus> Я думаю, что n3ptune и я можем сделать реализацию для всех выходов, просто чтобы посмотреть, что их этого получится
    <Isthmus> Два других вопроса на повестке дня - время разблокировки и tx_extra в монетных базах
    <Isthmus> Я могу заняться этим, если будет такая необходимость
    <sarang> конечно, я видел вашу информацию о зашифрованных блокировках
    <sarang> (и я тоже хочу затронуть тему блокировок)
    <Isthmus> Круто, давайте я предоставлю заготовленный текст
    <Isthmus> и да, для шифрования принудительной разблокировки мы должны выбрать формат. В настоящее время в поле разблокировки помещаются 3 вещи:
    <Isthmus> небольшие целые числа (например, 12), которые преимущественно интерпретируются как разница в высоте, то есть «разблокировка через 12 блоков»
    <Isthmus> большие целые числа, такие как «1980000», предположительно должны интерпретироваться как высота блоков
    <Isthmus> очень большие целые числа, такие как «1578561720», предположительно интерпретируемые как метки времени Unix
    <Isthmus> мне не хотелось бы переносить реальное время в блокчейн, я склонен к подходу: зашифрованное время разблокировки - это будущая временная метка, записанная в Unix секундах, и каждое кольцо должно включать в себя подтверждение диапазона, сравнивающее время разблокировки с самым старым или самым молодым участниками кольца (я еще не до конца продумал всю схему)
    <Isthmus> минимальное время блокировки в 10 является тривиальным параметром для любого внешнего наблюдателя / майнера, чтобы обеспечить принудительное выполнение путем отсрочки (или отклонения) транзакций, содержащим элементы менее 10 блоков. И это не требует математической проверки в рамках транзакции
    <Isthmus> Зашифрованное время разблокировки может быть фактически определено как отметка времени –1500000000, чтобы сэкономить немного места, удалив смещение времени
    Isthmus передает микрофон Сарангу
    <sarang>
    у нас уже есть один эффективный способ сделать зашифрованные блокировки, как представлено в документе DLSAG
    <moneromooo> маленькие целые числа - это высота блоков. Если вы сейчас используете 12, то это будет просто бессмысленно
    <suraeNoether> Я на 100% поддерживаю шифрование времени блокировок... Я знаю, что Саранг уже проделал некоторую работу над требованиями к этому
    <sarang> Метод описан здесь: https://github.com/SarangNoether/skunkworks/tree/timelock
    <sarang> Он работает следующим образом: выходы снабжены блокировкой с обязательством Педерсена
    <Isthmus> "<moneromooo> Если вы сейчас используете 12, то это будет просто бессмысленно" ахахах, как раз все сейчас так и делают
    <sarang> подписи снабжены вспомогательным открытым текстом, который выбирается случайным образом
    <sarang> а также всё защищено вспомогательным обязательством
    <sarang> существует доказательство диапазона, построенное с использованием всех этих значений, CLSAG / MLSAG также получает этот набор записей
    rottensox подключился (~rottensox@unaffiliated/rottensox)
    <sarang>
    это сохраняет анонимность подписавшего и показывает, что блокировка по времени уже прошла, но не раскрывает информацию о самой блокировке
    <sarang> для CLSAG это составит 1 новый элемент группы; блокировка времени в открытом тексте заменяется промежуточным значением открытого текста
    <sarang> а вспомогательное обязательство для подписи - это 1 новый групповой элемент
    <binaryFate> означает ли это, что транзакции без блокировки будут неотличимы от транзакций с блокировкой? Или просто время блокировки будет иметь более сложный временной показатель?
    <sarang> Доказательства диапазона могут быть обработаны в bulletproofs
    <Isthmus> пожалуйста, пусть они будут неразличимы
    <sarang> всё зависит от того, как это будет реализовано
    <suraeNoether> для неразличимости потребуется использование транзакций без блокировок
    <sarang> таким образом, стоимость составит 64 дополнительных байта на подпись и 32 байта на дополнительный выход
    <sarang> и да, вы бы включили нулевое время блокировки
    <sarang> весь остальной процесс протекает аналогичным образом
    <sarang> да, это не *бесплатное* решение, но оно и не такое *дорогое*, как может показаться
    <sarang> во всяком случае, эта информация дополняет то, что Isthmus рассказал о том, как сейчас обрабатывается блокировка
    <binaryFate> это совершенно не по теме, но лично мне нравится идея, что мы можем встроить произвольный хэш в транзакцию, который будет неотличим от других транзакций
    sarang возвращает микрофон Isthmus
    <binaryFate>
    в этом случае будет только половина или даже четверть хэша
    <binaryFate> (при использовании зашифрованного поля)
    <Isthmus> @binaryFate, если мы добавим принудительное поле с зашифрованным комментарием, это будет самый лучший вариант
    <suraeNoether> binaryFate: вы всегда можете использовать свой ключ для шифрования
    <binaryFate> да, как вариант... но он более чувствителен к локальному хранилищу
    <suraeNoether> всё верно, я понял, что вы хотите также иметь возможность извлечь сообщение?
    <binaryFate> просто покажите сообщение и укажите на прошлый хеш в блокчейне, который отмечает его как временный
    <binaryFate> но если у вас есть текст сообщения, вы можете вернуть хэш
    <suraeNoether> да, всё верно
    <binaryFate> во всяком случае, прощу прощения, что влез в разговор
    <sarang> Isthmus: забирай :)
    <Isthmus> споры и такие дискуссии неотъемлемая часть исследований :- D
    <Isthmus> я думаю, что в таких дискуссиях и появляется 2/3 всего исследовательского материала
    <suraeNoether> *кивает* да, за это я и люблю их
    <Isthmus> в любом случае эта тема очень сильно продвинулась с *мёртвой точки* за последнее время
    <sarang> Isthmus, у вас были какие-то заметки о том, как представлены метки времени
    <Isthmus> https://usercontent.irccloud-cdn.com/file/Ovp9yP0j/image.png
    <sgp_> сейчас мне нужно будет отойти, и когда я вернусь, то хотел бы поднять свой второй вопрос о подписании колец майнинг пулов
    <atoc> @isthmus согласен, новые идеи всегда появляются именно таким образом
    <Isthmus> давай @sgp_
    <sgp_> ладно, постараюсь закончить как можно быстрее
    <sgp_> есть несколько способов, благодаря которым, мы сможем переделать кольца для майнинговых пулов, чтобы защитить «целостность» выходных данных (сделать так, чтобы больше не было публично известно, в каких транзакциях они используются)
    <sgp_> для майнинг пулов, которые используют истории транзакций, ясно, какие данные являются выходными данными изменений и какие из них впоследствии расходуются пулами
    <sgp_> чтобы избежать этого, пулы могут выбирать кольца, используя исключительно приманки, которые они создают в качестве выплат майнерам
    <sgp_> таким образом, никто не сможет отличить выходные данные. И что более важно, будет сохранён один вывод для каждой транзакции пул
    <sgp_> это не консенсусное изменение, но оно потребует отдельный «режим выбора пула» или что-то подобное
    Isthmus закашлял от *это не консенсусное изменение*
    <sgp_>
    Isthmus: а как тогда? выплаты будут не из выходов монетной базы
    Isthmus внимательно перечитывает
    <Isthmus>
    Ааа, может быть, я как-то не так понял
    <Isthmus> продолжайте :)
    <sgp_> это защищает выходные данные пула от того, что они будут *помечены* как потраченные каким-то конкретным пулом в определенных транзакциях
    <sgp_> как-то так... я просто хотел освежить её концепцию и дать понять, что я не забросил эту идею
    <sarang> спасибо sgp_
    <sarang> В интересах времени, Isthmus, пожалуйста, продолжайте!
    Isthmus подводит итог:
    <Isthmus>
    Кажется, что все используют tx_extra по-разному, включая совершенно экстраординарные случай со множеством блоков с 60 B нулевого заполнения (??!): https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a
    <Isthmus> https://usercontent.irccloud-cdn.com/file/tXHruCE0/image.png
    <Isthmus> Это влияет на анонимность всех пользователей. Например, у меня есть список блоков, вычисленных в пуле и добавивших 60 B нулевого заполнения в каждую майнерскую транзакцию. Когда подобный пользователь создаёт транзакции со множеством входов, чтобы получить вознаграждение, кольцевые подписи не могут защитить их.
    <Isthmus> (мульти-вход + уникальный отпечаток статистически загромождён, потенциально мы сможем их отличить и будем знать, когда эти выходы действительно расходуются, и в дальнейшем сможем исключить их в качестве приманок для других транзакций)
    <Isthmus> чтобы избежать возможности дактилоскопии, важно, чтобы любая реализация имитировала полную иерархию блока. Например, если мы используем {nonce, pool, proxy}, то каждый майнер (включая программное обеспечение для соло-майнинга) должен помещать случайные данные в их состав. А иначе мы будем оставлять точно такой же отпечаток, как и раньше :p
    <Isthmus> в любом случае другие в этой комнате добились намного большего прогресса в том, как решить эту проблему, поэтому я передаю эстафету
    <sarang> Кому-нибудь хочет что-то добавить
    <suraeNoether> Нет, и мне нужно уйти
    <sarang> Хорошо, suraeNoether: краткое обновление, прежде чем вы уйдёте?
    <sarang> хотя, это не обязательно
    <koe> Саранг, это шифрованное время блокировки? https://justpaste.it/2754y
    <suraeNoether> у меня с Сарангом состоялась дискуссия о том, что модель связываемости не поддается обработке в CLSAG...
    <suraeNoether> скажу даже немного больше, у меня уже есть рабочие симуляции в моей ветке match-mojojo mrl-skunkworks
    <suraeNoether> всё, теперь мне точно нужно уходить
    <suraeNoether> извините :(
    <suraeNoether> я вернусь еще немного позже для представления своего обновления
    <sarang> koe: Вы можете включить вспомогательную метку времени в дополнительное обязательство подписи
    <sarang> Isthmus: что-нибудь еще?
    <sarang> (извините, я пытался сделать так, чтобы у каждого был шанс представить свои обновления)
    <Isthmus> Спасибо, я не стал представлять свой новый материал ;)
    <sarang> OK, большое спасибо, Isthmus
    <sarang> в свою очередь, я работал над вопросом о времени блокировки, вместе с sgp_ сделал сообщение для блога об аудите поставок (чтобы ответить на вопросы, которые всё чаще стали возникать, особенно в последнее время) и «полол сорняки» свертываемости в моделях безопасности
    <sarang> в этом случае связываемость подразумевает формальное определение, используемое в связываемых кольцевых подписях, а не попытку связать вас с какой-то конкретной транзакцией
    <sarang> koe: это может быть алгебраически эквивалентным, мне нужно взглянуть
    <sarang> хорошо, у кого-нибудь еще есть работа, которой он хочет поделиться?
    <sarang> сегодня какой-то небывалый всплеск активности!
    <koe> окей, тогда позвольте, я продолжу — есть ли у кого-нибудь мысли о принудительной сортировке TLV формата для дополнительных полей?
    <sarang> не могли бы вы кратко рассказать о преимуществах / недостатках для тех, кто отсутствовал на предыдущей встрече?
    <moneromooo> Если кто-то захочет добавить туда случайные данные, то это будет так же заметно, как и сейчас?
    <koe> и провести дополнительную стандартизацию монетной базы, обратившись в комитет интерпула
    <sarang> (обратите внимание, что на monerologs.net можно найти журналы этого и большинства других каналов)
    <moneromooo> что такое комитет интерпула?
    <koe> комитет между пулами
    <koe> состоит из
    <moneromooo> О, вы имеете в виду простой *диалог* c пулом?
    <koe> lol, конечно
    atoc вышел (2fb9c5f1@47.185.197.241): Удаленный хост разорвал подключение
    <koe>
    в стандартизации промышленности эти вещи называются «комитетами»
    atoc подключился (2fb9c5f1@47.185.197.241)
    ferretinjapan вышел (ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan): Ping timeout: 268 seconds
    <koe>
    преимущество принудительно отсортированных TLV + руководство по использованию: a) гарантирует, что все реализации используют один и тот же необходимый формат для создания дополнительных полей, поскольку без строгой структуры каждая реализация будет уникальной; b) для тех, кто сосредоточен на неприкосновенности частной жизни, будет сделан предельно понятный способ объединиться с другими аналогичными разработчиками (например,
    <koe> кто знал, что кодовая база сама сортирует записи полей?); c) дополнительное поле останется прежним, то есть таким же, как и сейчас, поэтому те, кто выбирает добровольный отказ от конфиденциальности (назовём их пижонами), могут сделать это без ущерба для других
    <sarang> напомните, в предыдущих дискуссиях были какие-то особые мнения против этого?
    <sarang> если да, то почему?
    ferretinjapan подключился (ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan)
    <koe>
    компромиссы: a) это может иметь *ограниченное* влияние на неразличимость транзакций, особенно если это транзакция из монетной базы; b) подразумевает, что не будет применяться более строгое ограничение к полю; c) что касается транзакций из монетной базы, как мы знаем, многие пулы публикуют свои найденные блоки
    <koe> (контраргумент заключается в том, что разработка Monero сосредоточена на цепочке и не может касаться слишком большой активности вне цепи)
    <sarang> отлично, спасибо
    <sarang> так как вы тоже интересовались временем блокировки, возможно, у вас есть вопросы или замечания на эту тему?
    <koe> мне просто очень интересна эта тема
    <sarang> помните, что доказательство диапазона можно включить в уже существующие проверки, что означает отсутствие эффективного изменения размера
    <sarang> ваша конструкция выглядит алгебраически эквивалентной тому, что я приводил в пример ранее
    <koe> у меня нет достаточных познаний о CLSAG, чтобы делать такие выводы
    <sarang> часть конструкции CLSAG можно отнести и к MLSAG
    <koe> Возможно, если бы мы знали наверняка, насколько большой охват у времени блокировки в естественной среде
    <sarang> разница лишь в том, как подписи обрабатываются в самом обязательстве
    <sarang> в MLSAG это будет стоить очень дорого, а в CLSAG он добавит всего один вспомогательный тег, но сделает проверку multiexp немного дороже
    <koe> О как, здорово! Я думал, что все эти дополнительные скаляры есть только в mlsag
    <sarang> если кто-то считает, что это к этому варианту стоит присмотреться более детально, то я смогу сделать более детальные оценки времени для операций с кривыми
    <sarang> Да, для CLSAG вы не добавляете скаляры
    <sarang> и это ничего не будет стоить вам в MLSAG
    <sarang> в смысле, увеличение размера или времени дополнительной проверки
    <sarang> сейчас в CLSAG используется *пользовательский* код кривой для повышения эффективности, который, в свою очередь, не будет работать в новой конструкции
    <sarang> (код Python не подходит для синхронизации, а так…только посмотреть, как всё это работает)
    <sarang> в любом случае
    <sarang> мы уже вышли за временные рамки нашей встречи
    <sarang> кто хочет поделиться своими КЛЮЧЕВЫМИ МОМЕНТАМИ на предстоящую неделю?
    <sarang> (это мой самый любимый пункт встречи, можно правильно расставить приоритеты и *трезво* взглянуть на ситуацию)
    koe вышел (4ba8fbe3@75-168-251-227.mpls.qwest.net):
    <atoc>
    Я продолжу работу с Шурэ и надеюсь, что на следующей неделе смогу представить новые результаты
    koe подключился (4ba8fbe3@75-168-251-227.mpls.qwest.net)
    <sarang>
    У меня несколько основных векторов... Нужно выделить дополнительное время для работы по написанию сравнений между несколькими документами о времени блокировки и провести анализ данных, относящихся к сублинейным протоколам
    <sarang> О, и еще одно замечание... Конференция IEEE S&B состоится в конце этого года
    <sarang> https://ieeesb.org/
    <sarang> я и suraeNoether в комитете
    <sarang> это большое событие, им нужны темы для выступлений
    <sarang> если у вас есть работа, которой вы хотите поделиться, подумайте о ее официальном представлении на этом мероприятии
    <atoc> О, здорово
    <sarang> (у нас не должно быть конфликтов интересов, отбросьте все свои предрассудки, если мы будем строги с вами)
    <sarang> я уже был гостем на этом мероприятии
    <sarang> какие-нибудь замечания, вопросы или мысли, прежде чем мы прервемся?
    <sarang> Как правило, не так много, чтобы покрыть за одну встречу D
    <sarang> раз...
    <sarang> два...
    <koe> Я сосредоточусь на multisig для ZtM2 и, если не успею закрыть все интересующие меня вопросы к следующей встрече, переключусь на bulletproofs
    <atoc> я не думал, что IEEE занимается темами Безопасности и Анонимности, тем более в ключе блокчейна
    <sarang> Я буду рад помочь с bulletproofs, у меня даже есть отдельная тестовая ветка для ZtM
    <sarang> atoc: это действительно отличное мероприятие
    <koe> всему свое время :)
    <sarang> Я очень рад, что меня пригласили в комитет :)
    <sarang> Хорошо, спасибо всем за явку! Получилась отличная встреча!
    <atoc> Да, было круто!
    <sarang> журнал встречи будет опубликован на GitHub
    <sarang> вы можете продолжить обсуждение дальше
    <sarang> (а мне нужна пауза для публикации журнала!)

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

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

    Kukima (@Kukima)
     
    #1 Unholy, 30 янв 2020
    Последнее редактирование модератором: 3 фев 2020
  • О нас

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