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

Тема в разделе "Журналы о Monero", создана пользователем Unholy, 1 июн 2021.

  1. Unholy

    Unholy Well-Known Monerano

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

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

    <sgp_> ну что, время встречи
    <sgp_> сегодня какие-то проблемы с серверами irccloud, многих выбрасывает после подключения к комнате
    <sgp_> релей через matrix работает отлично
    <sgp_> https://github.com/monero-project/meta/issues/545
    <sgp_> 1. Приветствия
    <ArticMine> Hi
    <sgp_> ArticMine, sarang, moneromooo, knaccc, dEBRUYNE, vtnerd
    <knaccc> как дела?
    <UkoeHB> hi
    <sgp_> довольно тихо сегодня, надеюсь, что народ подключится по ходу встречи
    <sethsimmons> Всем привет
    <sgp_> Были ли какие-либо нерешенные вопросы в дискуссиях о triptych за последние две недели?
    <ArticMine> Основной вопрос, который я увидел, сводился к срокам
    <sgp_> похоже, что на данный момент нет каких-то невыполнимых задач, кроме того, что на данный момент неясно, кто именно будет работать над интеграцией
    <sgp_> я понимаю, что это документ ждёт еще порция оптимизаций и некоторых консенсусных решений от sarang (например, связанных с выбором выходов)
    <sgp_> возможно, что кто-то хочет самостоятельно выдвинуть свою кандидатуру по работе над интеграцией?
    <ArticMine> ...еще есть проблема с multisig-кошельками
    <sgp_> нужно ли принимать какие-либо консенсусные решения по работе с несколькими подписями?
    <UkoeHB> а какой смысл, если в скором времени планируется реализация triptych
    <ArticMine> Это больше вопрос о том, как именно будет обрабатываться мультиподпись и сколько времени на это потребуется
    <UkoeHB> да, это похоже на явную проблему
    <ArticMine> есть проблема с изменением формата адресов для обеспечения совместимости
    <ArticMine> Я согласен с UkoeHB, это сложный проект, в процессе работы над которым появляются всё новые детали и тонкости
    <sgp_[m]> Да, это большой и сложный проект
    <sgp_[m]> Я не думаю, что нам следует менять форматы адресов
    <ArticMine> Может потребоваться пересмотр принципов работы мультиподписи
    <sgp_[m]> Каким образом происходит изменение форматов адресов?
    <ArticMine> Насколько я помню, это было связано с отправкой
    <sgp_[m]> Другой вариант - унаследованный процесс "преобразования" уже имеющейся мультиподписи
    <sgp_[m]> И я всерьёз рассматриваю данный вариант решения этой проблемы
    <ArticMine> транзакций нового формата на старые адреса
    <ArticMine> Я считаю, что мы не должны затягивать с BP+, изменением размера кольца CLSAG и проблемой #70 из-за всей этой волокиты
    <sgp_[m]> Да, чтобы потратить выходные данные в triptych, отправленные из устаревшей версии кошелька с мультиподписью, его вначале нужно «преобразовать» в кошелек без мультиподписи
    <sgp_[m]> Ладно… Есть что-то новое из последних результатов работы над triptych или стоит переключиться на #70?
    <ArticMine> Таким образом, необходимо предотвратить отправку выходных данных из Triptych в устаревшие кошельки с мультиподписью
    <ArticMine> следовательно, изменить формат адреса
    <sgp_[m]> ArticMine: эти изменения могут вызвать больше новых проблем, чем решить имеющиеся
    <sgp_[m]> Я бы предпочел отложить эту тему и переключиться на #70
    <ArticMine> Да, нужно будет поднять этот вопрос на следующей встрече
    <ArticMine> конечно
    <sgp_> https://github.com/monero-project/research-lab/issues/70#issuecomment-768036260
    <sgp_> articmine, ваш выход
    <ArticMine> Короче говоря, нам необходимо предотвратить резкое повышение комиссий
    <ArticMine> При нынешней ситуации уровень может подняться в 100 раз
    <UkoeHB> думаю, что мы обсуждали это на прошлой неделе, мультиподпись в triptych не требует какого-либо преобразования или изменения форматов адресов. Основная проблема заключается в том, что реализация мультиподписи в triptych потребует пересмотра и изменения части применяемой криптографии https://github.com/monero-project/research-lab/issues/72.
    <UkoeHB> если мультиподпись не поддерживается, то отправка выходных данных из triptych на *старый* адрес с мультиподписью — это плохо
    <sgp_[m]> ArticMine: Честно говоря, я тоже беспокоюсь, что сборы достигли исторического минимума
    <ArticMine> и любая атака на сеть Monero приведёт к резкому увеличению комиссии.
    <ArticMine> кстати, в моем предложении есть идея с повышением комиссии примерно в 5 раз
    <sgp_[m]> отличная идея избавиться от текущего минимального уровня
    <ArticMine> Да
    <sgp_[m]> Итак, я могу попытаться обобщить изменения:
    <ArticMine> Минимальная комиссия увеличивается до равной минимальной комиссии, поддерживающей масштабирование
    <ArticMine> но есть 3 критических изменения
    <sgp_[m]> 1. Более высокая минимальная комиссия, но меньшая «вертикаль» комиссии по мере увеличения количества транзакций?
    <ArticMine> всё верно
    <ArticMine> Таким образом, минимальная комиссия при 1425000 байтах равна текущей формуле
    <ArticMine> ...цена за спам для злоумышленников будет катастрофически высокой
    <ArticMine> что мы имеем сейчас
    <ArticMine> Основные консенсусные изменения:
    <sgp_[m]> Является ли эта точка пересечения примерно 10-кратным увеличением стоимости транзакций по сравнению с сегодняшним днем?
    <sgp_[m]> или около того
    <ArticMine> больше, она составит х30
    <ArticMine> дайте мне секунду
    <sgp_[m]> а как будет выглядеть «наклон»?
    <sgp_[m]> он будет основываться на ожидаемой рыночной капитализации?
    <ArticMine> Это уже будет после минимальной комиссии, которая отвечает за масштабирование
    <ArticMine> таким образом, комиссия следует обратному квадрату долгосрочной медианы
    <ArticMine> это естественная наклонная
    <ArticMine> и что касается размеров блока
    <sgp_[m]> Вы изменили переменную, не так ли? С 1.4 до 2?
    <ArticMine> в настоящее время средний показатель составляет около 40 тыс.
    <ArticMine> да, это часть консенсуса
    <ArticMine> и это необходимо для того, чтобы учесть текущие темпы роста
    <ArticMine> таким образом, долгосрочная медиана не отстает от краткосрочной
    <ArticMine> даже на максимуме
    <dEBRUYNE> не так быстро, мы не успеваем читать
    <ArticMine> два других консенсусных изменения
    <sgp_[m]> Я немного скептически отношусь к изменению 1.4->2 (с 1.4 до 2)
    <ArticMine> 2) занижение минимально уровня под долгосрочную медиану для повышения последующего снижения
    <ArticMine> это очень важно
    <sgp_[m]> В настоящее время нет минимального уровня, как и нет максимальной скорости его снижения?
    <ArticMine> поскольку у нас до сих пор не может быть долгосрочной медианы, которая была бы создана в течение последних нескольких лет
    <ArticMine> нет
    <ArticMine> другой вариант - сделать минимальную штрафную зону динамичной
    <ArticMine> установив его(ее? Если о штрафной зоне) на уровень долгосрочной медианы
    <ArticMine> повышение уровня с 1,4 до 2 необходимо, просто посмотрите на темпы внедрения
    <sgp_[m]> да, текущие темпы видно невооружённым глазом
    <ArticMine> Мы не можем использовать в Monero схемы, применяемые к Bitcoin
    <ArticMine> Таким образом, должен быть какой-то резерв для потенциального роста, который не должен доставлять нам дискомфорт, так как повторение событий 2016 года может нанести непоправимые последствия...
    <sgp_[m]> значит, вы позволите минимальной зоне без штрафов прогрессировать
    <ArticMine> да
    <ArticMine> это предотвращает резкое падение краткосрочной медианы
    <ArticMine> и предотвращает резкое повышение комиссий
    <sgp_[m]> у вас есть какая-то симуляция данной схемы?
    <ArticMine> не уверен
    <ArticMine> у меня есть примеры из жизни
    <sgp_[m]> понял
    <ArticMine> я ориентируюсь на цифры от 300000 до 1500000 байт
    <sgp_[m]> я согласен с данными штрафами в текущих обстоятельствах
    <ArticMine> сама формула штрафа не меняется
    <sech1> значит ли это, что нам придется попрощаться с текущими сборами в 0,2 цента?
    <ArticMine> Да они вырастут до 1 цента
    <ArticMine> однако если тенденция внедрения увеличится, они могут вернуться к старым показателям
    <sech1> что, если после этих изменений мы просто уменьшим все в 5 раз?
    <ArticMine> или 4x
    <ArticMine> стоит отметить, что низкая комиссия не масштабируется
    <ArticMine> так же как она не масштабируется сейчас
    <sgp_[m]> Вы говорите, что формула штрафа не меняется… я не понимаю этого...
    <ArticMine> многие в сообществе обеспокоены очень низкой комиссией, особенно с текущим темпом роста сети
    <sgp_[m]> Разве он не устанавливается ML формулой?
    <ArticMine> Формула штрафа применяется к MS / MN
    <ArticMine> это о том, какие изменения есть в зоне без штрафов
    <ArticMine> поэтому MN не опускается ниже ML
    <ArticMine> MN не опускается ниже 300000
    <ArticMine> а как только MN превысит ML, формула штрафа не изменится
    <ArticMine> или вы имеете в виду переход от 1.4 к 2 после роста ML?
    <sgp_[m]> Я имел в виду совсем не это, но об этом можно поговорить отдельно
    <ArticMine> тогда в ML нет изменений
    <ArticMine> совсем другое дело, что MN сможет опуститься ниже ML и потребует применение штрафа
    <sgp_[m]> Какой темп роста допускается при 2?
    <sgp_[m]> переход от 1.4 к 2 – это весьма резкий скачок
    <ArticMine> 2x за 69 дней
    <ArticMine> или 1.4x за аналогичный промежуток времени
    <ArticMine> показатель сроков остаётся одним и тем же
    <sgp_[m]> Таким образом, с использованием 2x допустимое увеличение составит до 7.4 в год... если, конечно, я нигде не ошибся
    <sgp_[m]> Стоп
    <sgp_[m]> так же и было при 1.4
    <sgp_[m]> x10.6 с 2?
    <sgp_[m]> или масштабирование будет еще быстрее?
    <ArticMine> x5.3 с 1.4 против x32 с 2
    <ArticMine> в 2016 мы говорили об показателях в x10
    <sgp_[m]> какая формула для 5.3 и 32?
    <ArticMine> 1.4^5 vs 2^5
    <sgp_[m]> понял, спасибо
    <ArticMine> но, опять же, не стоит брать максимальные значения
    <ArticMine> они будут не совсем верными
    <sgp_[m]> А почему бы, скажем, не использовать 1.6? Это будет ближе к 10x, но у нас не будет головной боли, связанной с платой за используемое место
    <ArticMine> это вернёт нас в 2016
    <sgp_[m]> просто транзакции на короткий промежуток стали бы немного дороже, не более
    <ArticMine> Мы будем слишком сильно полагаться на возможности быстрого роста в текущем темпе внедрения
    <ArticMine> а нам еще нужно подготовить благоприятную почву для #70
    <sgp_[m]> Мне нужно уходить, но мы можем продолжить этот разговор немного позже
    <ArticMine> если у вас будут комментарии, пожалуйста, отпишитесь в соответствующей теме на
    <ArticMine> github
    <ArticMine> в любом случае спасибо

    ---

    Источник: IRC #monero-research-lab

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

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