Журнал встречи Разработчиков 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)
