Когда: Понедельник, 7 октября 2019 г., 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол a. Саранг: обновление Lelantus, обновление доказательства концепции и анализа RCT3 b. Шура c. Прочие участники? Вопросы Ключевые моменты <sarang> Приветствия <suraeNoether> howdy! <ArticMine> hi <sarang> Я полагаю, что мы можем сразу перейти к КРУГЛОМУ СТОЛУ <sarang> suraeNoether: ? <suraeNoether> да, конечно. На этой неделе я работал над моим кодом. Я исправил несколько модульных тестов, также исправил проблему, из-за которой работа кода продолжалась O(n^2), а теперь выполняется за O(n)... код претендента и код пространственного ориентирования почти готов, но его симуляция все еще работает довольно нестабильно <sarang> Есть идеи, с чем именно это связано? <suraeNoether> также я занят чтением документа с идеей от randomrun и думаю о предстоящих доказательствах безопасности в ее реализации <suraeNoether> ну, я прямо не знаю, вот что еще странно... у меня есть пара модульных тестов, которые проверяют такие вещи, как «проверить правильное количество узлов, которые добавляются к итоговому графику», и все они работают нормально... Но интегрированное моделирование всё равно создает плохой выходной файл <suraeNoether> вот почему я опубликовал такую глупую GIF-анимацию на тему «два модульных теста, без интеграционного теста» <sarang> я видел ее <suraeNoether> но я не опускаю руки, продолжаю работать над этим... и еще у меня почти готовы другие шесть модульных тестов <sarang> превосходно <suraeNoether> я также хочу затронуть темы, которые isthmus опубликовал на github <sarang> давайте отложим их, пока он не вернется <suraeNoether> хорошо, возможно, он появится на этой встрече <suraeNoether> *одобрительно кивает*, но он может и не вернуться, хотя мы должны затронуть эти темы на этой встрече <sarang> на прошлой неделе я был занят несколькими работами <sarang> Я работал с Арамом в ключе обновления документа Lelantus: https://lelantus.io/enabling-untraceable-anonymous-payments.pdf <sarang> Мне кажется, что это решает проблему трассировки отправителя за счет правильной одноразовой адресации <suraeNoether> хмм… *поглаживает подбородок* <sarang> Текущая попытка исправить проблемы наталкиваться на *непреодолимую стену* из генераторов Педерсена <suraeNoether> мне очень интересно потратить немного времени и наверстать упущенное <sarang> Таким образом, мы всё еще ищем возможные способы использования доказательства Шнорра... пока это не принесло никаких результатов <sarang> Кроме того, я уже обновил код проверки концепции RCT3 и анализ пространства-времени, чтобы отразить новую версию препринта, которая также уже была выпущена <sarang> Он сжимает доказательство траты на вход, но это влечет за собой большие затраты на вводные данные <sarang> К сожалению, отказ от этого сжатия не очень хорошо сочетается с их интегрированным доказательством текущего баланса <sarang> Например, (количество трат)*(размер набора анонимности) должно быть в возведён во вторую степень или дополнено до единицы <suraeNoether> lelantus изначально использовал древовидную структуру, да? почему? <sarang> Что почему? <suraeNoether> почему они требуют возведение ввода данных до второй степени? <sarang> RCT3, а не Lelantus <sarang> Это связано с аргументом внутреннего продукта, который он использует для сжатия <suraeNoether> блин, я их перепутал, снимаю свой вопрос <suraeNoether> понял, теперь это имеет смысл <sarang> Было бы неплохо получить отдельные доказательства траты <sarang> но для этого потребуется переделать доказательства безопасности и т. д. <sarang> я больше был занят идеями RandomRun для Triptych, включающего доказательства текущего баланса и множественные траты <sarang> у меня уже есть простая и рабочая версия системы проверки Groth, которая поддерживает доказательство знания множественных обязательств вместе со связываемостью <sarang> но я еще не сделал никаких доказательств безопасности (в частности, у меня есть несколько вопросов о требованиях уникальности для определенных элементов доказательства) <sarang> получение интегрированного баланса довольно сложная процедура, и я сейчас как раз над этим работаю <suraeNoether> есть ли какая-либо статья или документ, которым вы готовы поделиться с публикой, или это все еще находиться в стадии тестирования? <sarang> Все его идеи перечислены на GitHub: https://github.com/monero-project/research-lab/issues/56 <sarang> а сам код можно найти здесь (но он еще слишком *сырой*): https://github.com/SarangNoether/skunkworks/tree/lrs/lrs <suraeNoether> понял вас <sarang> и вдобавок его безопасность не проверена <sarang> можно сказать, что он находится в стадии *заигрывания с алгеброй*, чтобы увидеть / понять его полезность <suraeNoether> это хорошо, нам нужно понять раньше других все его плюсы, прежде чем какая-то другая монета реализует это <sarang> Как бы то ни было, спасибо RandomRun за идеи по расширению системы проверки Groth <sarang> вероятно, что его идеи это уже отдельная статья <sarang> даже уже и на данном этапе (если вы имеете в виду доказательство безопасности) это превращает идею Groth с кольцевыми подписями в отдельную связываемую кольцевую подпись <sarang> и если расширенное доказательство баланса работает, то мы действительно можем заняться его *приготовлением* <sarang> Пока мы ждем возвращения Isthmus, я могу подвести итог и поделиться моими КЛЮЧЕВЫМИ МОМЕНТАМИ на эту неделю. Они будут заключатся в построение баланса, работающего в Triptych, и в завершении моей презентации по протоколам транзакций — Isthmus только что закончил с рабочим совещанием и пытается наверстать отставание <suraeNoether> отлично <sarang> Isthmus: мы еще не затрагивали вашу тему <sarang> справитесь сами? <Isthmus> Конечно <Isthmus> Одна из вещей, над которыми я размышлял последнее время — как оценить актуальное (безопасное) время для разблокировки баланса <Isthmus> Вот один из вариантов для этого: https://github.com/noncesense-resea...k/blob/master/writeup/lock_time_framework.pdf <Isthmus> Поскольку время блокировки должно быть больше, чем события реорганизации, мы можем подойти к этому вопросу систематически, перечисляя список вещей, которые инициализируют альтернативные блоки, оценивая максимально вероятную длину альтернативных цепочек, которые они могут создавать, и буферизовать их с помощью термина безопасности <sarang> Перечисление ожидаемых источников реорганизаций является хорошей идеей, особенно теперь, когда у вас есть эмпирические данные о реорганизации на основе задержек <Isthmus> и вообще моя идея состоит в том, чтобы вывести разговор из стадии *дружелюбной болтовни* к решению конкретных проблем, которые мы уже сейчас можем моделировать / обсуждать / и т.д. :- ) ⇐ xmrmatterbridge вышел (~xmrmatter@lists.getmonero.org): Причина: Удаленный хост разорвал подключение <sarang> Действительно, кажется, я припоминаю разговор об этом - об отдельных узлах, которые бы обрабатывали более длинные записи, но я предполагаю, что они не пришли в тот момент к какому-то консенсусу? <sarang> (в плане их реализации) <Isthmus> Ну, это было еще тогда, когда в сети были ASIC устройства <suraeNoether> Я бы выбрал T2 или T3. Выбор принудительного времени блокировки запрета транзакций бесспорно имеет определенную пользу для всей экосистемы. Паралич анализа при выборе «оптимального» времени блокировки нежелателен, а наличие времени принудительной блокировки, даже если мы не меняем текущее время блокировки, критически важно → xmrmatterbridge подключился (~xmrmatter@lists.getmonero.org) <Isthmus> Да, «должны ли мы установить время блокировки?» и «как долго мы должны блокировать их?» это два разных вопроса <suraeNoether> да, в этом и есть вопрос <sarang> как я понял, есть хорошее обоснование для достижения консенсуса, независимо от того, какое решение будет сделано ⇐ xmrmatterbridge вышел (~xmrmatter@lists.getmonero.org): Причина: Удаленный хост разорвал подключение <sgp_> Стоит ли проводить отдельное исследование в ключе конфиденциальности? Может получится так, что чем дольше время блокировки, тем лучше это в какой-то степени для общей конфиденциальности сети <suraeNoether> sgp_: это верно только в том случае, если время блокировки больше, чем среднее время для совершения траты <suraeNoether> но это ведь не желаемое время блокировки <suraeNoether> а, скорее, очевидное <suraeNoether> еще один вопрос, который меня беспокоит, заключается в том, как определить, что является *довольно долгим* или *достаточным* временем блокировки <suraeNoether> время блокировки на протяжении двух блоков слишком мало, в то время как блокировка в 90 дней непомерна велика <sgp_> Я не думаю, что это настолько важная тема <sgp_> полагаю, что нам будет очень трудно сделать его еще меньше 10 <suraeNoether> мой вопрос заключается в том <suraeNoether> есть ли у кого-нибудь весомый аргумент в пользу использования другого значения, отличающегося от текущего значения в 10 <sgp_> *тем более если оно должно быть увеличено <sgp_> suraeNoether: Я бы попытался обосновать уменьшение числа в ключе *пользовательского опыта*, если это, конечно, возможно <suraeNoether> и лично я бы не осмелился опускать значение ниже 10 <sgp_> Документ Isthmus обрисовывает в общих чертах основную схему, почему это нужно сделать <sgp_> suraeNoether: что служит обоснованием для вашего решения? <suraeNoether> позвольте мне перефразировать, потому что «и лично я бы не осмелился» звучит как-то по-идиотски <suraeNoether> sgp_: ну, мы уже видели много повторных реорганизаций длиной больше чем 10 <suraeNoether> кроме того, затраты времени, которые меньше чем 20 минут, *чрезвычайно* выделяются в графике транзакций <suraeNoether> если последовательность очень быстрых цепочек происходит в одном ряду, вы можете даже поспорить, что это один и тот же человек <ArticMine> у меня в голове вертится другой вопрос - что является приемлемой вероятностью риска для T2 и T3 <suraeNoether> ArticMine: у меня возник аналогичный вопрос <sgp_> это то, что я подразумевал с точки зрения конфиденциальности <suraeNoether> *одобрительно кивает* <sarang> Вы случайно не знаете аналогичный порог времени блокировки в Bitcoin? <sarang> просто интересно <suraeNoether> ^ sgp_, ArticMine, isthmus? <sgp_> нет <suraeNoether> хмм <Isthmus> Я не берусь комментировать какие-либо конкретные цифры, пока мы не определимся с рамками для этого обсуждения → Common-Deer подключился (~CommonDee@14-202-132-82.static.tpgi.com.au) <suraeNoether> лично мне было бы интересно увидеть эти цифры при определении общей структуры <sarang> Вот рецензия, на которую я натыкался раньше: https://bitcoil.co.il/Doublespend.pdf <dEBRUYNE> sarang: у Bitcoin нет времени блокировки для обычных транзакций <dEBRUYNE> по существу, у вас есть цепочки неподтвержденных транзакций <suraeNoether> dEBRUYNE: спасибо, это непременно важная информация <sarang> На 8 странице приведены примеры, основанные на хэшрейте и подтверждениях с использованием Bitcoin в качестве примера <Isthmus> это всё равно что обсуждать, что именно раньше появилось, яйцо или курица <sgp_> Isthmus, я понял вашу точку зрения <Isthmus> Имеет ли вообще смысл буферизации времени блокировки больше, чем вероятность развитияя наихудшего сценария? <sarang> dEBRUYNE: большинство принимающих сторон используют правило 6 подтверждений для «подтвержденных» транзакций <suraeNoether> Isthmus: если бы мы сделали это, наше время блокировки было бы равно 23 <sarang> Мне любопытно узнать о выборе этого конкретного значения <suraeNoether> мы совсем недавно видели реорганизацию с 23 блоками <dEBRUYNE> по существу, это даже не правило <dEBRUYNE> вы легко можете обойтись и без него — Isthmus пытается оспорить то, что говорит suraeNoether <sgp_> Давайте рассмотрим сценарий с 3 стандартными отклонениями <sarang> dEBRUYNE: правильно, но мне просто любопытно сделать сравнение <Isthmus> Lock_time = Safety*(max(len_latency, len_51%, len_selfish...)) <Isthmus> Так что если вы говорите, что это будет 23 ⇐ Common_Deer выщел (~CommonDee@14-202-132-82.static.tpgi.com.au): Причина: Бездействие в течение 250 секунд <Isthmus> вы подразумеваете блокировку <Isthmus> lock_time=23 <Isthmus> что вы используете в качестве значения для термина безопасности? <Isthmus> и где вы взяли значение для max? <suraeNoether> Оу, это хорошие вопросы <Isthmus> Я никогда не предлагал никакого значения для термина безопасности, поэтому я пытаюсь понять, как мы получили 23 <suraeNoether> Вовсе нет <suraeNoether> это не 23 <suraeNoether> я говорю max(...)> 23 только потому, что мы уже наблюдали появление значения 23 за последний год <Isthmus> Ого, я не знал этого <Isthmus> когда и где? <suraeNoether> поэтому любое выбранное нами число должно быть > safety*23 <Isthmus> Мы можем узнать это из журналов NRL <sarang> это было получено из отчета одного узла, да? <suraeNoether> sarang: *пожимает плечами*, даже если это было 15 или 12, safety*12 как показатель безопасности >1, как правило, будет больше 20 <sgp_> Вот почему я думаю, что нужно предварительно смотреть / оценивать все реорганизации <suraeNoether> моя точка зрения такова: если мы взглянем на то, как распространены реорганизации, и если мы действительно хотим защититься от них, нам нужно добиться неоправданно большого времени блокировки, которое, в свою очередь, подразумевает замедление экономики Monero <sarang> sgp_: все реорганизации, независимо от предполагаемого происхождения (задержка, объект с высокой хэш-мощностью и т. д.)? <sgp_> sarang: в любом случае я хочу увидеть результаты и понять, что за цифры получатся <Isthmus> Я был не в курсе, да и просто не согласен. Но, я не видел показателя *больше* 2 с тех пор, как мы перешли на CryptoNoteR <suraeNoether> sgp_: *одобрительно кивает головой*, мы должны посмотреть на распределение времени реорганизации и определить статистику вместо выбора, и в этом вопросе ваша точка зрения на 100% верна <sgp_> это просто моя мысль, которую я хочу донести <ArticMine> Я предлагаю индивидуальный подход к оценке риска. Давайте начнем с того, что именно представляет для нас угрузу? <sgp_> например: возможно, что это была *случайная* реорганизация длиной в 20, а все остальные не больше 3, это тоже нужно учитывать <sarang> Я думаю, что использование данных и методов Bitcoin-сообщества для оценки рисков объектов с высокой хэш-мощностью было бы полезно в качестве одной из точек зренияя <sgp_> Isthmus: если смотреть со стороны структуры, то я думаю, что нам нужно добавить некоторый подтекст для определения конфиденциальности <Isthmus> Действительно, коэффициент Джини для хэшрейта BTC гораздо более однобокий, чем распределение Монеро <sgp_> сокращение времени блокировки может повлечь негативные последствия для конфиденциальности <sgp_> с другой стороны, это имеет положительные последствия для пользовательского опыта <ArticMine> В Bitcoin есть существенные различия: 1) Великий брандмауэр Китая 2) 10-минутные блоки ⇐ ferretinjapan вышел (ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan): Причина: Удаленный хост разорвал подключение <Inge-> Лучший пользовательский опыт в конфиденциальности… Звучит как не-Monero. — Isthmus одобрительно кивает Artic <Isthmus> Я подозреваю (возможно, что я могу отказаться от своих слов…), что тот факт, что мы *подбрасываем* монеты каждые 2 минуты (а не каждые 10 минут), может подразумевать, что мы сможем добиться стабильного равновесия намного быстрее <sgp_> Inge-: Это компромисс. Никто не будет использовать монету, если у нее будет стодневный период блокировки <Isthmus> SLOWNERO <Isthmus> YESSSS <suraeNoether> ^это похоже на использование гладкой / экспоненциальной кривой в ключе вашей ипотеки по сравнению с дискретизированными временными шагами с использованием формул ежемесячной аннуализации <suraeNoether> в смысле я привел аналогию в отношении 2 минут против 10 <suraeNoether> хорошо, давайте кратко порассуждаем, предполагая, что самая длинная «естественная» реорганизация составит 6 блоков. Это меньше, чем наше текущее время блокировки, но в тоже время оно больше, чем приводит в качестве примера isthmus (в дополнение оно соответствует произвольному выбору Сатоши). <suraeNoether> если мы выбираем параметр безопасности равный 2 или 3, тогда мы должны ориентироваться на время блокировки, равное 12 или 18, но никак не меньше, чем 10. <suraeNoether> теперь, если мы вспомним, что повторные блокировки не всегда происходят *естественным* образом и есть вероятность их возникновения из-за враждебного поведения (или подразумеваемой атаки), то использование самого большого значения не кажется уже таким и бессмысленным <suraeNoether> Почему? Злоумышленник может выжидать подходящее время для реальной атаки, пока не появиться благоприятное окно ее проведения. И еще несколько реорганизаций длиной от 2 до 6 за всю историю Monero не подразумевает, что злоумышленник не может заставить себя дожидаться реорганизации длиной в 30 <suraeNoether> я подразумеваю, что это всё просто бездонная кроличья нора <sgp_> «прошлые показатели не указывают на будущие результаты». Как по мне, то сеть работает просто отлично и при текущем сценарии <suraeNoether> хорошо, тогда зачем пытаться выбрать другое число, отличное от 10, особенно в преддверии обновления? <suraeNoether> sgp_: ну… это просто частица нашей *истории* <ArticMine> В итоге получается, что мы просто так и оставим 10? <sgp_> давайте сначала договоримся о структуре <sgp_> а если мы ни о чем не договоримся, пусть останется как есть (10) <Isthmus> Оу, я не пытаюсь протиснуть эту идею в преддверии этого обновления <Isthmus> как по мне, мы только обсуждать всё будем не меньше трёх месяцев <suraeNoether> только если так — suraeNoether вытирает капли пота со лба <Isthmus> и вообще, я просто ответил на пинг с прошлой встречи <Isthmus> я думаю, что 10 в самый раз для текущего состояния сети — suraeNoether снимает с себя накладную бороду <Isthmus> аахахаха <Isthmus> @suraeNoether «это всё просто бездонная кроличья нора», ну точно, прямо как MRL, если мы собираемся поднять вопрос о времени блокировки на всеобщее рассмотрение, то мы должны спуститься также в три другие кроличьи норы: 1) Какая самая длинная «естественная» реорганизация, 2) Самый благоприятный вектор для проведения атаки, 3) Какой погрешности мы хотим добиться? <Isthmus> и вообще, я не думаю, что есть способ решить этот вопрос именно таким способом <Isthmus> (я думаю... что, возможно, есть какой-то другой способ...) <suraeNoether> и я не говорю, что нет способа решить эту проблему <Isthmus> Кстати, что вы думаете о термине аддитивной безопасности по сравнению с мультипликативным? <sgp_> suraeNoether: Я согласен с вами на теоретическом уровне, но никак не на практическом уровне <suraeNoether> sgp_: да, я и говорю, что теоретически нет оптимального решения, а на практике появиться целый ряд *возможных* решений, которые могут оказаться «достаточно хорошими» и будут иметь различные компромиссы в зависимости от моделей возможных атак <sgp_> ....И вы работали над Monero раньше? lol <suraeNoether> вот почему isthmus использует слово *вероятный* <suraeNoether> ... <sgp_> да, это обычный компромисс, но в любом случае нам нужно выбрать что-то и у меня есть причина (обусловленная) полагать, что это число должно отличатся от 10 <suraeNoether> *кашляет в кулак*... лучшего решения не существует <sgp_> Я как никогда предрасположен к диалогу в этом ключе <Isthmus> Может быть, нам стоит вернуться к этой теме на следующей неделе с более актуальными данными в отношении глобальных событий (в архивной версии сети) <ArticMine> Разве нельзя просто использовать подход, основанный на оценке риска? <Isthmus> @ArticMine, да, пожалуйста, поделитесь вашей идеей :- ) <ArticMine> 1) % хэшрейта атакующего <ArticMine> 2) что подразумевает атака <ArticMine> 3) тип атаки, т. е. двойная трата, нарушение конфиденциальности — Isthmus одобрительно кивает <ArticMine> Нужно уметь разделять риски <Isthmus> Некоторые моменты из пункта 1) могут попадать в пункт 3). Ну, или как-то так <Isthmus> https://usercontent.irccloud-cdn.com/file/iRNSWEPW/image.png <sarang> Опять же, статья, связанная с Bitcoin, всего-навсего выполняет анализ порога хэшрейта. <ArticMine> Да, это анализ <suraeNoether> 1) время блокировки >50 или <10 — крайне плохие идеи по противоположным друг другу причинам <suraeNoether> 2) это оставляет нам не так много места для возможного маневра <suraeNoether> 3) переход от 10 к 15 крайне маловероятен, в том плане, чтобы повлиять на конфиденциальность в целом; это 10-минутная разница, когда мы говорим о распределении с медианами в ключе полутора дней <suraeNoether> 4) переход от 10 к 40 будет иметь огромное влияние на всю экономику, и как минимум это всё должно быть оправдано настоящей кучей весомых доказательств ⇐ kl_ вышел (uid344501@gateway/web/irccloud.com/x-mpqjmqclivhmrzhd): Причина: Удаленный хост разорвал подключение <suraeNoether> я смотрю на это как на преднамеренный *аналитический паралич* только потому, что у нас уже есть данные, чтобы ответить на все эти вопросы в ключе специфических гипотез <sarang> В интересах экономии времени, можем ли вернуться к этой теме, когда у всех желающих появится возможность прочитать соответствующий анализ? <sgp_> Да, конечно <sarang> у Isthmus был еще один пункт для обсуждения <Isthmus> возможно, что у меня не 100% технический анализ, так что не стесняйтесь вносить свои исправления и замечания <sarang> Речь шла о представлении публичного ключа транзакции, в смысле, что бы его использование не связывало адрес с возможным подадресом <Isthmus> Да, было дело <Isthmus> Это подразумевает возможность для любого желающего выяснить, были ли какие-либо подадреса включены в состав транзакции <Isthmus> своего рода утечка информации о получателе <moneromooo> или отправителя <sarang> Стоп, я думал, что теперь всегда используются уникальные tx pubkey, независимо от типа адреса... Мне нужно время, чтобы проверить это <Isthmus> Да и / или отправитель <dEBRUYNE> sarang: это справедливо, но в этом случае я бы установил его в ноль <sgp_> первый раз слышу об этом <moneromooo> На самом деле... Я не уверен, логика немного отличается <suraeNoether> я запутался... <moneromooo> Я удалил это, когда попытался добавить изменения адреса пользователя <suraeNoether> isthmus, у вас есть пример, который мы могли бы разобрать? <Isthmus> Нет, понятия не имею, как именно отличаются эти конструкции <sarang> suraeNoether: по умолчанию вы используете уникальный ТХ для субадресов <Isthmus> Погодите <Isthmus> Может быть, я смогу привести пример <Isthmus> Означает ли tx_extra=(empty), что никаких субадресов не было? <Isthmus> В этом случае получается, что я могу просто заглянуть в обозреватель блоков <sarang> tx_extra хранит tx pubkey, который включен по умолчанию <suraeNoether> sarang: Вы имеете в виду, что tx pubkey кодируется по-другому? <suraeNoether> оу-оу <suraeNoether> да уж <sarang> да <suraeNoether> ахахах <Isthmus> ммммм <sarang> для субадреса и основного адреса это работает по-разному <sarang> можно использовать только один pubkey для нескольких адресов не подадреса <sarang> это и подразумевает различия <Isthmus> ^^^^ <suraeNoether> хммм <sarang> Я думал, что это уже было исправлено, чтобы сделать транзакцию уникальной для получателя <suraeNoether> Саранг, я начинаю припоминать этот разговор об использовании уникального ключа для отдельно взятого получателя. Не понравилось, что он пересматривает количество адресов назначения или что-то в этом роде... <sarang> Уникальный на выход, это то, что я имел ввиду <sgp_> почему адреса назначения будут отличаться от выходов f? Ведь тут не идёт речь о том большом вспенивании <suraeNoether> *пожимает плечами* пользователи постоянно делают глупые вещи по самым непонятным причинам <sarang> Я посовещаюсь с moneromooo и загляну в код, чтобы посмотреть на текущее поведение <Isthmus> +1 <moneromooo> я намеренно прекратил писать, мы бы говорили о тех вещах, в которых вы не уверены <Isthmus> Круто, я думаю, что мы поставим данный разговор на паузу и вернемся к нему через неделю, если вы не против <ArticMine> +1 <sarang> У кого еще есть, что сказать о его ключевых моментах, прежде чем мы закроем эту встречу? <sarang> Хорошо, спасибо всем за участие Источник: Research meeting: 7 October 2019 @ 17:00 UTC #398 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
