Место встречи: Freenode | Mattermost | Matrix #monero-dev Дата и время встречи: 19 июля 2020 года, 17:00 UTC Используйте этот конвертер часового пояса, чтобы преобразовать UTC в ваш часовой пояс. Предлагаемые пункты встречи: Главной темой этой встречи является обсуждение предстоящего обновления сети. Дата обновления и обсуждение того, что должно войти в текущий выпуск Статус CLSAG и связанные с ним проверки Подготовка контрольного списка и распределение обязанностей между участниками Возможные проблемы и способы их устранения Не стесняйтесь предлагать дополнительные пункты и правки для пунктов выше. Журнал встречи: <sarang> Планируются ли другие важные изменения для предстоящего обновления сети? <sarang> По результатам аудита безопасности нам не потребуется никаких изменений в коде CLSAG <moneromooo> А я хочу изменить время разблокировки. Это то, что я хотел поменять все эти годы... <moneromooo> И кто-то недавно подтолкнул меня к этому опять, так что я могу заняться этим <moneromooo> Не могу думать ни о чем другом... <moneromooo> (просто внести технически-консенсусное изменение, на практике ничего не изменится) <moneromooo> Кажется, у меня было что-то еще, что я хотел еще реализовать в этом обновлении, но я не могу найти это в своем списке. <sarang> Никаких изменений, связанных с CLSAG, после завершения аудита, верно? <moneromooo> О! Еще был момент с "предварительным делением ключа на 8"... <sarang> У них было только два замечания, не связанных с безопасностью <moneromooo> Не уверен, вы должны знать об этом больше меня <moneromooo> Правильно, общий консенсус не претерпит изменений <sarang> Я не думаю, что они окажутся необходимы, да и смена общего типа, скорее всего, создала бы потенциальный риск <sarang> Мне нравится идея c образом ключей, но я понимаю, что она весьма спорна <fluffypony> moneromooo: сделать его короче или, наоборот, длиннее? <fluffypony> (время разблокировки) <moneromooo> Нет, без каких-то функциональных изменений <moneromooo> Фактически <moneromooo> В настоящее время он хранится как полный 64-битный беззнаковый образ. Но на деле монетная база использует только 60 бит <moneromooo> Может быть, нам стоит убрать лишнее и использовать только 60 бит <moneromooo> Сохраняя... 4 бита? <moneromooo> Так что это, скорее, желание в экономии <sarang> каждый байт важен <moneromooo> Но текущая дельта предотвращает ситуации, когда "время разблокировки < текущей высоты" <sarang> Я бы хотел сделать название CLSAG более простым для понимания, но боюсь, что этот корабль уже отчалил... <moneromooo> ZLSAG. <moneromooo> Все становится лучше с Z. <moneromooo> И звучит почти так же <sarang> %s/C/Z/g <sarang> готово <sarang> действительно, что теперь может пойти не так <moneromooo> RingZT. <dsc_> Продано! <Isthmus> Возможно, дельта с высотой самого младшего участника кольца? <moneromooo> Интересная идея <moneromooo> И еще, может быть, стоит переместить tx key / nonce за пределы поля extra или вообще убрать его, поскольку sgp упомянул, что люди собирались использовать extra для добавления своих данных в транзакцию <moneromooo> Но я склоняюсь к тому, что минусов в такой реализации больше чем плюсов <sgp_> Я считаю, что этот план провалился, хотя, конечно, любой желающий может использовать это поле на свое усмотрение <moneromooo> Или, как вариант, замена зашифрованного фрагмента с фиксированным размером (без согласованного применения). <moneromooo> Если фиксированный фрагмент достаточно велик, мы также можем рассчитать его энтропию <sgp_> это больше похоже на компромисс между раздутием и частичными всплесками <moneromooo> Окей, действительно, это плохая идея <sgp_> если мы хотим удалить tx_extra, нам нужно найти другой компромисс <sgp_> мы не знаем, для чего конкретно сможем его еще использовать <moneromooo> Достаточно просто перечислить все транзакции, которые имеют "неизвестную" природу происхождения <moneromooo> Тогда у нас будет повод подумать, использовать его для чего-то еще или просто сломать всё <Isthmus> !RemindMe через 1 неделю — Isthmus хочет еще вернуться к этой информации <sgp_> Я до сих пор вижу в этом нечто, о чём нам нужно объявить заранее, поскольку мы потенциально можем что-то сломать… и кто знает, что именно, lol <Isthmus> Да, давайте обозначим потенциальное удаление на 2022 или как-то так. Лучше поздно, чем никогда, особенно когда речь идет о связываемости транзакций <Isthmus> @mooo, если это будет замена на принудительное шифрование фиксированного размера, я могу добавить свои пять копеек <sarang> Есть ли другие хорошие примеры использования для этого, особенно те, которые нельзя было бы решить с помощью зашифрованного pID? <moneromooo> У меня уже где-то есть патч, который делает это, но имеет квантованный набор допустимых размеров <sarang> ставлю палец вниз за квантовые наборы / размер данных <moneromooo> Может быть, цветные монеты. Их можно зашифровать? <sarang> это должно решать все текущие вопросы или ничего (и я бы предпочел ничего, так как pID уже существует) <moneromooo> Один только размер является квантовым случаем <sarang> О! Несколько активов на выходов? Да <sarang> Есть несколько способов сделать это <moneromooo> Еще один момент, который я бы хотел реализовать, - набор зашифрованных данных, где вы можете заполнить JSON для получателя. А затем получатель / отправитель согласовывает набор полей, которые он хочет получить в ответ <moneromooo> Но тут слишком много вытекающих проблем <sarang> Даже если ничто другое не делает этого, кроме CLSAG, это все равно огромное улучшение <sarang> На 25% меньше, на 20% быстрее <sarang> и улучшенная модель безопасности <sarang> проверенный код подписи <sgp_> Я все еще настаиваю на том, чтобы выходы из монетной базы тратились только на вновь созданные монеты <sarang> Мне нравится эта идея <moneromooo> Лично я не смогу помочь вам в этой задумке, так как это выглядит, как попытка деанонимиазции майнеров <sarang> sgp_: Вы уже прочитали пост в блоге, который я опубликовал в сообществе о CLSAG? <sgp_> Да, одну секунду <sarang> не торопитесь <sgp_> Я знаю, что мы отдаем предпочтение соло майнерам, но я думаю и обо всех других пользователях... <sarang> не могу опубликовать <moneromooo> Это не очевидно <sgp_> это просто одна из тех вещей, когда мы попросим соло майнеров о небольшой услуге, но всем остальным от этого будет только лучше <hyc> А я не вижу угрозы <sgp_> hyc: какой угрозы? <hyc> выделение выходов из монетной базы в отдельные кольца как бы разрушает их набор анонимности <luigi1111w> Я вижу выгоду в том, что входы из монетной базы не являются частью обычных колец <luigi1111w> но также нет никакой пользы в том, что у них есть свои отдельные кольца <hyc> и только если они будут выбраны в обычных кольцах, это позволит им восстановить общий набор анонимности <moneromooo> Хорошо, я доверяю MRL, если они дадут добро на это изменение, и я также доверю мнению luigi1111w <sgp_> luigi1111w: Как мы можем обеспечить такое путем консенсуса? <hyc> luigi1111: Я не понимаю. Если они не являются частью общих колец и не имеют собственных колец, то как их можно вообще потратить? <luigi1111w> 0 колец <luigi1111w> зачем вообще участвовать в кольцах, если они просто публикуют свои транзакции <hyc> аа, вот оно как <sgp_> о, вы имеете в виду, что, чтобы потратить деньги, им не нужны приманки <luigi1111w> это подобно пустому залу театра <sgp_> в действительности да <sgp_> я выступаю за сохранение размера кольца для выхода из монетной базы, так как стоимость крошечная, да и по другим соображениям это выглядит выгодно <sarang> С точки зрения анализа графов удаление выходов монетной базы из стандартных колец позволяет избежать эвристики <sarang> что довольно выгодно <sarang> следовательно, я поддерживаю эту идею <sgp_> это довольно посредственное преимущество <Isthmus> @sarang, зашифрованное поле = ePID. Как вариант, можно оставить что- то одно или просто расширить ePID до желаемого размера <hyc> какой бы размер вы ни выбрали, он всегда будет "недостаточно большим" <sgp_> luigi1111w: а что вы думаете, если кольца монетной базы будут использоваться c_ringsize 3? <sarang> Isthmus: Я думаю, что все сводится к тому, оптимально ли иметь дополнительное пространство для произвольных данных (как в случае с pID) <luigi1111w> мне это кажется бессмысленным <luigi1111w> очень маленький шанс того, что у вас не появятся "отравленные" выходы <luigi1111w> хоть размер и не большой, но выгоды ноль — Isthmus просто делает заметку, и пока не готов вступать в полемику <sgp_> Я думаю, что непредсказуемость помогает снизить эффективность наблюдения и позволяет не полагаться только на средства индивидуальной защиты <sgp_> ну или как минимум затруднит дальнейший анализ <sgp_> конечно, я не сторонник таких мер, но это всё-таки лучше, чем ничего <UkoeHB_> Isthmus: Вы когда-нибудь уже делали PR для фиксированных базовых сумм? <Isthmus> Ой, забыл это добавить. Возможно, я смогу сделать это к субботе <sarang> ? <sgp_> а что вы думаете насчет этого: https://github.com/monero-project/monero/issues/5222? <sgp_> Я отредактировал это сообщение, чтобы показать, что это относится ко всем публичным кошелькам Источник: Dev Meeting July 19th, 17:00 UTC: Network upgrade #485 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
