Перевод Журнал встречи разработчиков Monero от 2018-03-04 / 2

Тема в разделе "Статьи", создана пользователем Unholy, 19 мар 2018.

  1. Unholy

    Unholy Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    10
    Симпатии:
    1
    Журнал встречи Разработчиков Monero от 2018-03-04
    04 Марта 2018
    Часть вторая
    Начало журнала вы можете найти здесь.

    <+moneromooo> предупреждение за месяц или два до всего этого, плохая идея.
    <+moneromooo> нам нужны были дополнительные две недели для тестирования майнеров
    <+hyc> разве у нас уже нет предупреждения monerod?
    <+moneromooo> Немного поздно для такой цели, хотя, всё ещё возможно.
    <+moneromooo> Я думаю, он начал «стонать» пару недель назад, нет?
    <+hyc> мы могли бы просто добавить его в баннер при запуске - "слудующий hardfork будет XX" где XX приблизительно 6 месяцев от текущей даты
    <+moneromooo> Сделаем.
    <+hyc> правильно
    <@fluffypony> да
    <@fluffypony> hyc: боюсь, никто не читает баннеры в момент запуска
    <knifeofpi> совсем немногие, lol
    <rbrunner> это ведь не будет мешать
    <+moneromooo> многие из пользователей могут не запускать его довольно часто и могут остаться без нужной информации.
    <rehrar> Сделайте это, как с раздражающими всплывающими окнами, которые постоянно хотят, чтобы вы сообщили им вашу электронную почту для новостной ленты
    <rehrar> Нужно будет поставить четыре отдельных флажка, чтобы закрыть уведомление
    <+hyc> так бы мы могли бы сделать периодические предупреждения
    <+hyc> раз в месяц, потом раз в неделю, потом раз в день и так далее по мере приближения даты XX
    <+moneromooo> Может быть
    <rehrar> Я думаю, что это довольно хорошая идея
    <+moneromooo> Да, согласен.
    <+moneromooo> Теперь это в моем списке задач.
    <rehrar> Что-то ещё по теме hardfork / заморозки кода?
    <sgp_> Напоминаю: код для ringsize нужно изменять
    <+hyc> ?
    <ocinvfvsUIOIvdsb> 7
    <rehrar> Точно. Там был свободный консенсус изменить минимальное количество ringsize до 7.
    <dEBRUYNE> не уверен, был ли отдельно консенсус по этому вопросу
    <rehrar> Повторно обсудим этот вопрос?
    <ocinvfvsUIOIvdsb> Было упущено из виду на прошлой встрече
    <dEBRUYNE> Это кажется слишком резким изменением
    <knifeofpi> dEBRUYNE: Я не согласен
    <rehrar> Давайте обсудим ;)
    <knifeofpi> минимум 7 являться необходимостью нежели желанием на данный момент.
    <@ArticMine> Я за увелечение ringsize до 7
    <Slack_4> <nicolas.misiura> Повлияет ли этот релиз на кошелёк (api)?
    <ocinvfvsUIOIvdsb> согласен с knifeofpi
    <sgp_> у меня нет больше новых данных с прошлой недели
    <sarang> Я за
    <ocinvfvsUIOIvdsb> + sarang
    <ocinvfvsUIOIvdsb> +1
    <DaveJones> +1
    <rbrunner> +1
    <knifeofpi> +1
    <rehrar> По моему мнению, sgp проделал колоссальную работу. Этого вполне достаточно, чтобы убедить (меня по крайней мере)и понять, что оно того стоило.
    <knifeofpi> rehrar: согласен
    <@fluffypony> +1
    <ErCiccione> поддерживаю
    <+hyc> yep. +1 rehrar
    <dEBRUYNE> rehrar: smooth опубликовал рапорты на github fwiw
    <@ArticMine> ссылку
    <dEBRUYNE> В любом случае, пожалуйста, увеличьте консенсус, а не только выбор в кошельке по умолчанию
    <rbrunner> Это до сих пор «висяк» с прошлого раза
    <@ArticMine> Я говорю о консенсусе
    <ocinvfvsUIOIvdsb> Я думаю, что все здесь следят за обновлениями в GitHub. Я голосую за размер ringsize в 7, на основе SGP и других данных
    <+moneromooo> Минимальный размер кольца обязательно является в данном случае консенсусом
    <dEBRUYNE> ArticMine: https://github.com/monero-project/monero/issues/3035#issuecomment-368273632
    <rehrar> Если верить его сообщениям: числа для модели выбираются произвольно, поэтому нетрудно доказать, что компромиссы того стоят
    <rehrar> в постусловие железных доказательств мы не должны торопиться
    <knifeofpi> tx увеличиться совсем незначительно
    <knifeofpi> мы должны принять наихудший вариант
    <rehrar> это действительно аргументы, которые я уважаю, потому что произвол приводит к таким вещам, как Sumo
    <dEBRUYNE> 7-8% увеличение времени проверки значительно
    <rehrar> но как можно по-другому "спланировать атаку", кроме моделирования угроз в меру своих возможностей?
    <knifeofpi> не moneromooo, мы распологаем 10% ускорения для какой-то проверки?
    <ocinvfvsUIOIvdsb> Теперь у нас есть аудиторы. После FFS мы сможем быстро перебросить силы на bulletproofs, например, к этому лету
    <rehrar> смоделированной модели (50% скомпрометированных выходов).
    <+moneromooo> то время было сочтено, это не стоило усложнения кода.
    <knifeofpi> понятно
    <+moneromooo> Это было не очень сложно
    <rehrar> И даже у альтернативы smooth % скомпрометированных выходов показал более убедительные цифры по крайней мере для меня
    <@ArticMine> Увеличение времени проверки должно быть сбалансировано с угрозой конфиденциальности. Так что да, я понимаю аргумент smooth в сравнение со скользким склоном, но на данный момент времени просто разумно увеличить до 7
    <rehrar> smooth: "Например, при 50% (в некотором смысле, возможно, оптимальная доля для аргументации увеличенного ring size), переход от ring size с 5 до 10 снижает ставку 6.25% до 0.195%. Но, предполагаемый компромисс при 20%, переходя от ring size с 5 до 10, уменьшается от 0,16% до 0.000051% и предполагаемый компромисс долей 80%, С 40% до 13"
    <Slack_4> <serhack> Привет всем, я согласен с sgp.
    <rehrar> smooth: "Я полагаю, что, вероятно, существуют различные взгляды на то, как интерпретировать эти цифры, но мне понятно, что цифры и характер улучшений сильно меняются в зависимости от предполагаемой доли, без реальной основы для выбора одного из предположений"
    <rehrar> Он прав, разные люди будут видеть эти цифры по-разному
    <rehrar> Я понимаю, что мы обсуждаем 7, а не 10.
    <rbrunner> Если XMV взлетит довольно высоко, у нас может появиться второй fork до появления следующего hardfork...
    <dEBRUYNE> rehrar: я думаю, что выход меняется на основании ввода
    <+hyc> конечно, основной момент заключается в том, что это будут минимальные изменения, которые не будут иметь особой разницы между ночной или дневной сборкой
    <ocinvfvsUIOIvdsb> Как и на прошлой неделе, у нас, похоже, есть незавершенный консенсус. Можем ли мы прийти к общему мнению о 7 по умолчанию и единому минимальному значению?
    <knifeofpi> ocinvfvsuioivdsb: соглашусь
    <ocinvfvsUIOIvdsb> Не думаю, что мы уделили достаточно времени для ring size (многие поддерживают просто переход без дополнительных объяснений)
    <@ArticMine> Простой переход от 5 к 7 кардинально повысит конфиденциальность
    <sgp_> Да, на прошлой встрече мы договорились, что сейчас не самое подходящее время для фиксирования значения ringsize
    <@ArticMine> Заниматься на этом этапе ringsize довольно преждевременно
    <+hyc> верно, шаг за шагом.
    <rehrar> #fixedringsizeseptember
    <sgp_> Я думаю, что большинство людей согласны с тем, что увеличение с 5 до 7 обеспечивает измеримые преимущества при реалистичных сценариях
    <rehrar> Хорошо, все сводиться именно к этому
    <rehrar> мы устанавливаем 7 минимальным?
    <@ArticMine> Да
    <ocinvfvsUIOIvdsb> да +1
    <scoobybejesus> угу
    <knifeofpi> да!
    <Slack_4> <serhack> +1
    <knifeofpi> закрываем этот консенсус на минимальное значение 7?
    <Slack_4> <janowitz> да
    <rehrar> Угу
    <ocinvfvsUIOIvdsb> нам всё ещё нужен pull request для fluffypony по ring size
    <+moneromooo> Это есть в моём списке задач
    <rbrunner> Сделайте это с любовью :)
    <sgp_> ты moneromooo
    <@fluffypony> <3
    <ocinvfvsUIOIvdsb> ты
    <sarang> В интересах экономии времени, есть ли у кого какие-либо вопросы о Bps?
    <sarang> (он сказал, опасаясь своих слов)
    <+moneromooo> Moar Pippenger!
    <sarang> lol, да
    <sarang> Консенсус разделён между 2 или 3 аудиторами?
    <rehrar> Можем ли мы перевести его на финансирование?
    <sarang> угу
    <sarang> это и есть наш план
    <sgp_> хорошо
    <sarang> думаю 3 будет вполне достаточно
    <sarang> Если мы находим 2 аудитов, то фонд будет поделён на 2
    <sarang> Если мы находим 3 аудитов, то фонд будет поделён на 3
    <sarang> всё просто и понятно :)
    <rehrar> можем ли мы рассчитывать на четверых?
    <rehrar> что если будет три?
    <ocinvfvsUIOIvdsb> + 1 rehrat
    <rehrar> может тогда сразу четыре?
    <sarang> считаю, что от 4 будет низкая отдача
    <rehrar> rehrat, это лучшее имя
    <ocinvfvsUIOIvdsb> почему может снизиться от 4?
    <sarang> Я был бы счастлив начать работу уже с 2
    <sarang> и буду доволен 3
    <rbrunner> Возможно, у нас будут траты для других важных целей
    <dEBRUYNE> 3 это оптимально, ИМХО
    <sarang> ^
    <dEBRUYNE> Sarang, тогда 3?
    <rehrar> Верно :)
    <sarang> Да
    <dEBRUYNE> в зависимости от процентов, будет точно 3 или 2
    <@ArticMine> 3 будет самым лучшим выбором
    <xmrmatterbridge> <pinkphloid> Привет всем!
    <sarang> Это позволит делать одному аудит математической части и 2 людям по реализации
    <rbrunner> что 2?
    <sarang> Bunz стоит первым в списке
    <+moneromooo> как насчет того, чтобы вторая группа рассмотрела, скажем, multisig?
    <sarang> потом QuarksLab и следом Dudelski
    <sarang> *Kudelski
    <sarang> moneromooo: мы должны сделать отдельный запрос на SoW
    <dEBRUYNE> Я бы предпочел Kudelski, Quarkslab и Buenz
    <sarang> dEBRUYNE: именно в таком порядке?
    <dEBRUYNE> не обязательно
    <xmrmatterbridge> <pinkphloid> у меня рейс из Fra в dxb, поэтому я частично выпаду из поля зерния. Как обновление повлияет на API кошелька
    <knifeofpi> отлично!
    <dEBRUYNE> Я уверен, что мы сможем получить финансирование для 3 человек
    <dEBRUYNE> особенно, если главный разработчик будет на фонде kickstart
    <@fluffypony> определённо
    <ocinvfvsUIOIvdsb> +1 moneromooo за идею для multisig обзор (в добавок к 2-3 людям для bulletproofs)
    <+moneromooo> API непременно измениться, но он будет обратно совместим с AFAIK
    <rehrar> Хорошо, время подходит к концу. Может закончим, или мы хотим обсудить ещё код?
    <rehrar> Можем ли получить ещё человека для RingCT?
    <sarang> OK, ждите публикацию FFS завтра
    <Slack_4> <serhack> Как изменится API кошелька moneromooo?
    <sarang> Я думаю, что это откроет дверь для дополнительного обсуждения будущих аудитов, которые я впредь хотел бы видеть частью нашего процесса разработки
    <+sarang окончил разговор
    <+moneromooo> Ну, так как многие люди читают нас здесь, я хочу отметить, что было бы хорошо опубликовать существование ключевых смягчений повторного использования
    <iDunk> moneromooo, такого ведь не может быть, serhack.
    <ocinvfvsUIOIvdsb> чем больше обзоров у нас есть, тем легче защищаться от FUD: https://twitter.com/matthew_d_green/status/832971753186029570
    <+hyc> хех. trollnoise.
    <+moneromooo> Специально тем людям которые будут использовать ключи повторно для будущего fork.(если это действительно не троянский конь).
    <sgp_> Да, смягчение будет очень полезным инструментом
    <rbrunner> так война не выигрывается...
    <@fluffypony> хы
    <rehrar> Хорошо. 6. Давайте подтвердим следующую дату/время встречи (для тех, кому нужно уйти)
    <@fluffypony> что-бы ни случилось "следующие несколько месяцев" кроме MoneroLink
    <rehrar> Следующие выходные?
    <@fluffypony> rehrar: то же время, то же место, тот же пони
    <rehrar> March 11, 17:00 UTC

    Источник: Logs for the Dev Meeting Held on 2018-03-04

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

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