Когда: Среда, 27 мая 2020 г., 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня Приветствия Круглый стол Вопросы Ключевые моменты <sarang> ОК, время встречи! <sarang> Как обычно, мы начинаем с ПРИВЕТСТВИЯ <Isthmus> ПРИВЕТСТВИЯ <ArticMine> Hi <sarang> привет — sarang ждет других участников в течение нескольких минут <knaccc> yo → others подключился (43a4fffc@c-67-164-255-252.hsd1.co.comcast.net) <knaccc> очень хорошо <sarang> ох, как утонченно! <sgp_> привет <sarang> Хорошо, давайте перейдем к КРУГЛОМУ СТОЛУ <sarang> я начну с нескольких вещей <sarang> студенты-исследователи из CMU подготовили препринт по трассировке Monero и Zcash: https://eprint.iacr.org/2020/593 → adhux0x0f0x3f подключился (~adhux0x0f@gateway/tor-sasl/adhux0x0f0x3f) <sarang> в нем рассматривались только те данные, которые были предварительно получены до активации протокола Sapling в Zcash (такие независимые проверки ранних работ очень важны) <sarang> но в случае с Monero был рассмотрен гораздо более новый период транзакций <sarang> выводы заключаются в том, что совершенствование протокола было очень полезным <sarang> но я полностью не согласен с их методологией, приводящей к выводу об эффективности обновленного алгоритма выбора выходов <sarang> я просто думаю, что у них не получилось сделать рациональные выводы <sarang> еще я подготовил несколько заметок и отправил их авторам препринта, дополнив моей благодарностью за их проделанную работу <sarang> они разместили свой аналитический код на GitHub, так что я собираюсь посмотреть, какую полезную информацию можно извлечь из этого исследования <sarang> в дополнение я сейчас работаю над некоторыми определениями для переноса модели безопасности Omniring в Arcturus <sarang> и над верификацией адресов вместе с moneromooo <sarang> и еще я написал тестовый код для идеи сканирования тегов <knaccc> на каком языке? <sarang> Как было предложено UkoeHB_, идея состоит в том, чтобы включить небольшой короткий хэш определения ключа для каждого выхода и использовать его в режиме «быстрого сканирования», который позволяет избежать некоторых операций с кривой <sarang> knaccc: временный код написан на C ++ <sarang> это не финальная реализация, скорее, только тестовая модель для получения информации о времени <sarang> в предположении тег представления является одним байтом, и только 1 из каждых 256 тегов проверяет результаты на совпадение <sarang> на тестовом компьютере общее время сканирования без просмотра тегов для этих 256 проверок составляет 43,520 мс. <sarang> общее время сканирования с просмотром тегов (и одним совпадением в группе) составляет 32,559 мс <sarang> это означает, что в этом примере режим быстрого сканирования работает на 75% быстрее <knaccc> сколько транзакций в общей сложности вы сканировали? <sarang> Это было не настоящим сканированием; это была симуляция, которая выполняла все операции для поддельных выходных данных, сгенерированных тестовым кодом <knaccc> я имею в виду, каково было отношение совпадающих выходов к просканированным выходам <sarang> Он сопоставил тег просмотра и выходной ключ, а затем рассчитал время сканирования в различных режимах <sarang> предположительно 1/256 <sarang> статистический <knaccc> Когда вы подразумеваете 1 из 256, учитываете ли вы стоимость дополнительного сканирования, чтобы затем перепроверить полученные результаты? <sarang> Да, позвольте мне объяснить <sarang> тест имеет 3 режима <sarang> режим 1. стандартное сканирование без просмотра тегов <sarang> режим 2. просмотр тега без совпадений (вычисление деривации и просмотр тега, а затем проверка) <sarang> режим 3. тег просмотра (после получения и просмотра тега следует его проверка) <sarang> таким образом, «отсутствие тегов просмотра» предполагает 256 операций для первого режима <sarang> если «да, теги просмотра присутствуют», предполагается 255 операций для всех режимов <ArticMine> Есть вопрос и о нестандартной математике <sarang> ? <sarang> knaccc: тестовый код всегда генерирует совпадающий тег представления и выходной ключ (для проверки работоспособности), но симуляция просто использует режимы, чтобы проверить, произошло ли совпадение или нет <knaccc> Ваши результаты примерно совпадают с обратной калькуляцией, но если вы экономите на скалярной базе и скалярное вычисление в переменной базе стоит 25, а скалярное вычисление с фиксированной базой стоит 15, то вы уменьшаете стоимость сканирования со 100% до 25 / (25 + 15) = 62,5% <ArticMine> для Arcturus <sarang> ArticMine: в Arcturus теги представления полностью экранированы <ArticMine> извините <sarang> Они обычно применяются в процессе построения выходного ключа <sarang> который в любом случае экранирован в Arcturus <sarang> риск при использовании тегов заключается в том, что отправляющий кошелек может генерировать любой тег, который он захочет, и получатель не обнаружит нужный ему выход <sarang> и вы не можете сделать дополнительное сканирование с помощью этого метода <sarang> а плохая реализация тегов может добавить факт дактилоскопии, в том случае если кошелек сделал что-то глупое и установил его в фиксированное значение <sarang> конечно, универсальные кошельки-получатели не увидят это, особенно если выполнят только быстрое сканирование. В любом случае это не будет работать для кошелька-отправителя → MSavoritias подключился (~MSavoriti@44-224-rev.isper.sk) <sarang> вот временный код: https://github.com/SarangNoether/monero/commit/93172f80b2c25def9aaf40fc30dbee54f92f47a5 <sarang> (он проходит проверку сборки, но Windows CI не работает) <knaccc> мне интересно, где разница между 75% реального и 62,5% теоретического <knaccc> я посмотрю код <sarang> Существует небольшое увеличение стоимости для каждого вычисления хеша и некоторых нескалярных операций <sarang> Да, дайте мне знать, если вы заметите что-то, что я пропустил <knaccc> они обычно пренебрежимо малы по сравнению с 0,15 мс или 0,25 мс для мультитула EC <sarang> угу → dubie подключился (~dubie@63.230.70.90) <sarang> проверка хеша составляет примерно 2-3% от общего времени <knaccc> я не вижу в вашем коде ссылки на loop_count <sarang> Об этом позаботится предварительный тест <sarang> который использует отдельные результаты для выведения статистики <knaccc> о как <sarang> каждый тест настраивается в non-timed init() <sarang> и затем привязывается к test() <knaccc> да, в этом есть смысл <sarang> если вы хотите проверить, просто запустите `./performance_tests --stats --filter=\*view_tag\*` <sarang> флаги `true / false` соответствуют логическим переменным в определении теста <sarang> о, еще стоит учитывать преобразование байтов <sarang> оно не велико, но и пренебрегать ими тоже не стоит <sarang> но я лично склонен игнорировать его во время оценок <sarang> на этом у меня, пожалуй, всё <sarang> у вас есть вопросы? <knaccc> код выглядит отлично <sarang> Хорошо, кто-нибудь еще хочет поделиться своим исследованием? <sarang> knaccc: отлично <Isthmus> Хм, я начал задаваться одним вопросом этим утром... <Isthmus> За последние несколько лет мне пришлось отказаться от тонны интересных программных идей, потому что повторяющиеся транзакции с 3 выходами являются эвристически связанными, а альтернативные бизнес-модели (подписки, учетные записи и т. д.) имеют массу недостатков в конфиденциальности по сравнению с простой платой за обслуживание каждой отдельной операции <Isthmus> и теперь мне интересно, а не душит ли это внедрение и интеграцию Monero, мешая прямолинейному и приватному методу компенсации для разработчиков, которые хотят внести свой вклад в экосистему. <Isthmus> если мы хотим, чтобы Monero использовался не только для двухточечных транзакций и без потенциального риска для пользователей в ключе статистического анализа, то схема с 3 выходами должна выглядеть так: получатель + изменение + дополнительная плата за обслуживание <Isthmus> конечно, для многих транзакций третий вывод будет пустышкой (или, как вариант, пользователи могут проявить творческий подход и разделить сдачу на 2 адреса для еще большей гибкости) <sarang> Принудительно увеличить до 3? <Isthmus> возможно, что имеет смысл объединить это с большими кольцами, поскольку соотношение (# выход) / (# кольцевая подпись) за единицу времени не должно быть слишком большим (поскольку выходы, которые еще никогда не появлялись в кольцевой сигнатуре, имеют известное состояние траты [неизрасходованно] и информируют [с доказуемой уверенностью] отправителя, что средства впоследствии не были перемещены) <Isthmus> @sarang, да <sarang> разделение изменений означает более высокую вероятность использования нескольких выходных изменений в последующих транзакциях <sarang> что плохо для связывания <sarang> это главный недостаток всех этих наворотов <Isthmus> Да, именно поэтому я всегда выступал против того, чтобы люди разделялись внутри одного кошелька <ArticMine> Какой дополнительный размер получится за передачу? <Isthmus> 0.22 kB <Isthmus> я думаю <Isthmus> ой, стоп ⇐ tromp вышел (~tromp@2a02:a210:ca3:2800:39a5:d7db:7b8e:ee59): Удаленный хост закрыл подключение <sarang> выглядит слишком большим <Isthmus> данные не совсем корректны <Isthmus> секунду <ArticMine> Если мы пойдем на 4? <sarang> ArticMine: что 4? — binaryFate занимает одно из свободных мест в задней части комнаты <ArticMine> Разве нет bulletproofs доказательств эффективности? <ArticMine> для 4 против 3 выходов, которые должны были быть заполнены <sarang> заполнение BP не подразумевает дополнительных выходов <Isthmus> я смотрю данные на xmrchain и не могу найти ни одной 1/3/e транзакции, а вот 1/3/s довольно много (дайте мне минуту переварить всё) <sarang> это просто часть алгебры <sarang> ArticMine: это будет означать, что bulletproofs будет немного больше для стандартных транзакций <sarang> вы это имели в виду? <ArticMine> да <sarang> BP с 3 выходами (дополненное до 4) на 64 байта больше, чем BP с 2 выходами <sarang> (у BP с 4 выходами тот же самый размер, как и в случае с BP с 3 выходами) <ArticMine> это просто моё виденье <sarang> понял <sarang> Да, вы правы, что это увеличит типичный размер диапазона <Isthmus> Да, это делает Monero пригодным для использования в бизнес сегменте, но увеличивает размер транзакции <Isthmus> Еще одно пасхальное яйцо: ⇐ MSavoritias вышел (~MSavoriti@44-224-rev.isper.sk): Причина: MSavoritias <Isthmus> По сути, нет транзакций 1-in-3-out с зашифрованными PID <Isthmus> существует только несколько транзакций 1-in-3-out, в которых PID отсутствует вообще <Isthmus> и несколько 1-in-3-out с необычным тегом в xmrchain, не уверен, что в именно в поле tx_extra — Isthmus берёт в расчет данные за последние пару недель → tromp подключился (~tromp@2a02:a210:ca3:2800:39a5:d7db:7b8e:ee59) <jwinterm> Я думаю, что это было бы разумно, учитывая, что транзакции с PID, вероятно, созданы пользователями для бирж или сервисов <Isthmus> и это выделяется как нестандартное программное обеспечение <Isthmus> я думаю, что мы иногда делаем все только хуже, особенно, когда добавляем функцию «для всех транзакций» в кошельке, а не для протокола <sarang> угу → MSavoritias подключился (~MSavoriti@44-224-rev.isper.sk) <ArticMine> есть ли дополнительное увеличение до 64 байт? <sarang> Новый выход имеет публичный ключ, обязательство и зашифрованную сумму... <sarang> получается порядка 72 байт <ArticMine> и 4 <sarang> 73 байт, если вы добавите тег просмотра <sarang> и добавьте еще один публичный ключ, обязательство, сумму и тег для каждого выхода <ArticMine> 82 против 73 байт и 4 более 3 <sarang> нет <sarang> в дополнение к возможному увеличению доказательства диапазона каждый дополнительный выход требует еще 73 байта для публичного ключа, обязательства, скрытой суммы и необязательного тега представления <sarang> увеличение диапазона с 2 -> {3 или 4} составляет еще 64 байта <ArticMine> значит, что для 3 он будет равен 137 байта <sarang> это уже более правдоподобно <sarang> Это также подразумевает увеличение времени сканирования (но оно сокращается за счет предпросмотра тегов) <ArticMine> и для 4 210 байт <sarang> и дополнительное время сканирования <ArticMine> Да <sarang> В любом случае, в интересах экономии времени, есть ли другие темы, которые нужно затронуть? <sarang> (мы всегда можем продолжить обсуждение после окончания основной встречи) <knaccc> Кстати, мне было бы интересно увидеть примеры использования 3-out транзакций <knaccc> да, конечно, как вариант, после встречи <sarang> пучаются очень большие комиссии <sarang> Один выход отправляется получателю, один для изменения, другой поставщику услуг <ArticMine> НДС / СБОРЫ? <knaccc> sarang, что вы подразумеваете под поставщиком услуг? Это какой-то слишком общий пример <knaccc> ArticMine, вы предлагаете платить НДС напрямую правительству как часть транзакции? <sarang> knaccc: может быть, вы используете какой-то сервис стороннего кошелька <sarang> или у вашего кошелька есть возможность пожертвовать небольшую сумму на благотворительность с каждой транзакции <knaccc> всё, теперь понял, спасибо <sarang> Хорошо, давайте быстро пройдемся по КЛЮЧЕВЫМ МОМЕНТАМ, если у вас нет других тем для обсуждения <sarang> когда я исправлю ошибку с Windows CI, я подготовлю новый PR <sarang> и еще закончу подготовку документов Triptych и Arcturus для отправки на PoPETs <sarang> надеюсь, что успею закончить дополнительные тесты и трассировку <moneromooo> Микроплатежи в каждой транзакции - отличный способ задушить Monero. Мы ведь не хотим иметь огромное количество выбросов пыли, ведь она тоже потребляет ресурсы, как и «нормальные» выходы <sarang> moneromooo: это то, что я имел в виду <knaccc> сборы имеют важное значение для multisig <ArticMine> довольно скользкий путь... <knaccc> я думаю, что все типы оплаты по умолчанию должны поддерживать multisig <knaccc> и multisig не будет никогда поддерживаться другим типом кошелька <sarang> Хорошо, я полагаю, мы можем закрыть нашу сегодняшнюю встречу (и я смогу публиковать журнал), но обсуждение, конечно, может продолжаться дальше <sarang> Спасибо всем за участие! <knaccc> ^^ Источник: Research meeting: 27 May 2020 @ 17:00 UTC #468 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
