Перевод Журнал встречи исследовательской лаборатории Monero от 2019-04-08

Тема в разделе "Журналы о Monero", создана пользователем Unholy, 20 апр 2019.

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    188
    Симпатии:
    13
    Повестка дня:
    1. ПРИВЕТСТВИЕ
    2. КРУГЛЫЙ СТОЛ
      a. Саранг: CLSAG plumbing/timing, Dandelion++ (BIP, Grin), output selection
      b. Шурэ
      c. Прочие участники?
    3. Вопросы
    4. КЛЮЧЕВЫЕ МОМЕНТЫ
    <sarang> Повестка дня: https://github.com/monero-project/meta/issues/327
    <dotkc> suraeNoether: Я был бы рад нашей встрече, если ваш маршрут до Университета Клемсона будут пролегать через ATL
    <sarang> Давай начнем, время пришло
    <sarang> 1. ПРИВЕТСТВИЕ
    <sarang> всем привет
    <sarang> кто сегодня присутствует на встрече?
    <rehrar> hi
    <sgp_> hello
    <ArticMine> hi
    <suraeNoether> holaa
    <sarang> Добро пожаловать, dotkc, он новенький на этом канале
    <sarang> Двигаемся дальше 2. КРУГЛЫЙ СТОЛ
    <sarang> Мне есть чем поделиться с вами
    <sarang> Во-первых, у меня есть пример ветки (ссылка в повестке дня) с реализацией кольцевых сигнатур CLSAG на C ++ в совокупности с базовыми тестами для нашего текущего размера кольца
    <suraeNoether> ВОУУУ!
    <sarang> На моей тестовой машине MLSAG с 11 участниками (текущая схема) требует 13,0 миллисекунд для проверки
    <suraeNoether> clsag – классный чувак
    <sarang> Если мы перейдем к CLSAG, проверка (11 участников в сигнатуре) займет 10,6 миллисекунд
    midipoet запускает волну из рук!
    <sarang>
    Если мы изменим хэш-коэффициенты (позднее), время проверки увеличится до 11,1 миллисекунд
    <sarang> Если мы берём эти числа как верное значение, то получается, CLSAG даст нам более быстрые и меньшие в размере подписи
    <sarang> прошу обратить внимание, что данная ветка предназначена только в качестве примера
    <sarang> Существует несколько новых базовых функций, которые необходимо будет пересмотреть
    cardboardoranges вышел (~cardboard@65.112.8.10): Причина: апельсины в коробке
    <suraeNoether>
    увеличение времени проверки на 15% после года непрерывного роста блокчейна эквивалентно огромному шагу вперёд, навстречу уменьшению времени загрузки и синхронизации, что будет экономить время будущим узлам. Даже если мы повысим размер кольца до 13 / 14, исходя из полученных результатов Саранга, у нас всё равно будет прирост во времени для загрузки + синхронизации спустя год эксплуатации
    <suraeNoether> вероятно
    <suraeNoether> даже крошечные изменения для времени проверки будут означать огромные перепады в размере, конечно, если мы считаем загрузку + время синхронизации с помощью нашей метрики
    <sarang> экономия места составляет 320 байт на затраченный вход (каждый потраченный вход является отдельной сигнатурой)
    <ArticMine> С помощью чего сравнивается размер?
    <sarang> ^^
    <suraeNoether> было бы здорово увидеть график размера моноблочной цепочки в течение года после внедрения clsag
    <suraeNoether> это будет интересный эксперимент
    <sarang> у вас есть какие-либо вопросы или комментарии по поводу CLSAG в его нынешнем виде?
    <sarang> на данный момент у нас нет планов о его внедрении
    <sarang> Существует пример этой реализации на Python:
    https://github.com/SarangNoether/skunkworks/blob/clsag/clsag/clsag.py
    <ArticMine> Таким образом, при типичном tx с двумя выходами получится сэкономить порядка ~ 620 байт
    <sarang> правильно
    <sarang> Эм, 2 входами
    <sarang> Эта экономия приходится и на затраченные входные данные (следовательно, и на саму подпись)
    <suraeNoether> ох, чего бы это ни стоило
    <suraeNoether> у меня есть небольшой комментарий
    <sarang> Давай, suraeNoether!
    <suraeNoether> Разница между версией Саранга в 11,1 мс и версией LSAG в 10,6 мс заключается в том, что версия в 11,1 мс доказуемо не поддаётся фальсификации. В то время как LSAG это встроенная версия агрегации Musig Key (Andytoshi ^) для использования в конфиденциальных транзакциях, и она доказывается очень легко
    <suraeNoether> для версии 10,6 мс я все еще продолжаю заниматься доказательством непогрешимости
    <suraeNoether> но это менее тривиально, чтобы это доказывать
    <sarang> именно
    <suraeNoether> это единственный раз в моей жизни, когда я видел инженерный пример разрыва между теоретическим и прикладным процессом :p
    <hyc> очень круто
    <sarang> сейчас у временного кода есть флаг, где вы можете выбрать, какую именно версию вы хотите проверить
    <suraeNoether> выглядит довольно аккуратно
    <sarang> В любом случае продолжайте тесты со CLSAG, если вам это интересно
    <hyc> ^^ нужно больше технарей, чтобы вкрутить эту лампочку
    <sarang> Далее : Dandelion__
    <sarang> s/__/++
    <ArticMine> Какое влияние оказывает размера кольца?
    <sarang> ArticMine: он использует 1 дополнительный скаляр на элемент кольца (в отличие от 2)
    <suraeNoether> ArticMine: мы могли бы увеличить размер кольца до 13 / 14 и посмотреть время проверки по сравнению с нашим текущим доказательством?
    <sarang> проверка увеличивается прямолинейно
    <suraeNoether> насколько мне известно
    <sarang> Да, если мы увеличим размер кольца до 13 / 14, мы получим аналогичный показатель, как с 11 для MLSAG
    <sarang> (ориентировочно)
    <sarang> При желании я могу составить график с примерами размера и времени
    <ArticMine> Все-таки экономия места получается значительной
    <sarang> Да
    <sarang> и быстрее
    <sgp_> sarang: быстрый и приблизительный график оценки меня удовлетворит полностью
    <sarang> n-CLSAG в любом случае будет быстрее, чем n-MLSAG
    <sarang> Первоначальный вопрос был о сравнении n-CLSAG и 11-MLSAG
    <sarang> конечно, есть точка пересечения
    <sarang> Во всяком случае, мы немного затронем тему Dandelion++
    <sarang> У меня есть ссылки на предлагаемый BIP по этому поводу, а также обновленный PR для Grin
    <sarang> Если мы планируем идти нога в ногу с Dandelion++ в рамках нашей маршрутизации txn, есть несколько вариантов дизайна
    <suraeNoether> d++ будет отдельной темой для разговора, я полагаю, что vtnerd еще на конференции (ping)
    <sarang> Да, и обычное напоминание, что это не полноценная замена для решений на сетевом уровне, таких как Tor / I2P
    <sarang> Grin изменил их реализацию так, что узел, не относящийся к fluff/stem на основе txn, но для каждой эпохи отдельно
    <sarang> это из оригинальной стати
    <sarang> BIP не решает эту проблему (и я действительно считаю, что это неправильный подход)
    <sarang> Реализация Grin сложнее, чем наша, поскольку они выполняют агрегацию txn
    <suraeNoether> sarang: можете ли вы поделиться полезными ссылками для записи?
    <sarang> ссылки на BIP / Grin находятся в повестке дня
    <suraeNoether> мне интересно посмотреть на подробности реализации grin в сравнении реализаций bip
    <suraeNoether> большое спасибо
    <sarang> Оригинальный документ D++: https://arxiv.org/abs/1805.11060
    <sarang> Есть вопросы в ключе D++?
    <sarang> Я хочу, чтобы это было реализовано в Monero
    <suraeNoether> я тоже
    <suraeNoether> я считаю, что эпохальный подход, принятый grin, является правильным, но нужны аргументы для понимания разницы
    <suraeNoether> интересно услышать мысли andytoshi и gmaxwell
    <sarang> Согласно статье, эпохальный подход корректен
    <sarang> в каждую эпоху узел «подбрасывает монетку», чтобы решить, в каком «режиме» он будет находиться: fluff или stem
    <andytoshi> я ничего не знаю о dandelion, извините :)
    <sarang> и затем все txns маршрутизируются согласно этому жребию (если конечно узел не обнаруживает атаку «черной дыры»)
    <sarang> andytoshi: Однажды я обратился к волшебникам, чтобы спросить их о BIP, но они мне не ответили :/
    <sarang> кто знает, возможно, это уже обсуждали до нас
    <sarang> Последнее, чем я хотел поделиться с вами, это то, что moneromooo подготовил PR 5389 (ссылка в повестке дня) относительно выбора выхода
    <sarang> он использует метод «output lineup», который мы подробно обсудили ранее
    <sarang> Обзор этого метода / PR был бы весьма полезен
    <sarang> Это все для меня... suraeNoether, ваш отчет?
    <suraeNoether> отлично, у меня есть несколько обновлений
    <suraeNoether> обо всем по порядку: регистрация на monero konferenco теперь открыта по ссылке https://monerokon.com
    <suraeNoether> второе: как я уже говорил перед этой встречей, на следующей неделе я собираюсь посетить университет Клемсона, чтобы поговорить и встретиться со своими коллегами
    <suraeNoether> также я встречаюсь с Gao, он у них ведущий исследователь в группе блокчейна
    <suraeNoether> в дополнение, все мой силы направлены на мой самый старый из текущих проектов — MRL-11, он требуемые моделирования + анализ вспенивания
    <sarang> (предлагаю обсудить вспенивание более подробно после вашей встречи)
    <suraeNoether> учитывая недавний разговор с dotkc и sgp_ об автоматическом вспенивании, это имеет высокий приоритет на данный момент
    <sgp_> Я не могу даже сказать, насколько всем нам важен MRL-11
    <sarang> Да, прежде чем мы обсудим это подробно, у вас есть что-нибудь еще, чем вы могли бы поделиться с нами?
    <dotkc> У меня есть коллега, который может помочь в ключе MRL-11
    <suraeNoether> на данный момент ничего больше нет, после встречи я хочу провести публичное обсуждение различных моделей поведения, которые мы хотим протестировать
    <sarang> Хорошо
    <sarang> Итак, давайте поговорим о вспенивании
    <suraeNoether> у меня есть инфраструктура сопоставления и инфраструктура для моделирования Монте-Карло графика блокчейна
    <sarang> dotkc: ранее, вы опубликовали в r/Monero несколько статей, касающихся инструмента, над которым работает ваша группа. Можете представить себя для всех участников в этой комнате?
    <sarang> sgp_ и dotkc подробно обсуждали это на r/Monero и уже затрагивали эту тему в этой комнате
    <dotkc> по большому счету я никто, это хобби-проект, который материализовался из набросков кода, я и мои коллеги много говорим о конфиденциальности, поэтому мы здесь, чтобы постараться помочь всем нам
    <sarang> (поскольку dotkc является новым членом нашей общины, я хочу напомнить о том, что эти журналы собраний публикуются в открытый доступ)
    <dotkc> Я в курсе, спасибо за объяснение
    <sarang> всегда рад помочь
    <sarang> Можете кратко описать свой инструмент?
    <dotkc> мы начали со сборов всех обсуждений и мыслей по всему сообществу, связанных со вспениванием
    <dotkc> плюс, у нас были базовые знания в области анализа цепей и мониторинга сети
    <dotkc> наше намерение состоит в том, чтобы присоединиться ко всем вам в исследовании конфиденциальности относительно вспенивания и помочь пользователям использовать менее «плохие» методы в дальнейшем
    <dotkc> нам не нужно достигать «лучших практик» для общего улучшения сети
    cardboardoranges подключился (~cardboard@65.112.8.77)
    <sarang>
    как я понял из чтения предыдущих журналов встреч, цель программного средства - автоматизировать определенные методы вспенивания в соответствии с разрабатываемыми рекомендациями безопасности
    <sarang> и что есть какой-то спонсорский компонент в этой среде для поддержки таких проектов
    <dotkc> я не собирался вручную создавать тонны транзакций и воспроизводить вспенивание для дальнейшего анализа сети, поэтому нашим первым шагом было создание инструмента для автоматизации этого процесса
    <sarang> этот момент показался мне самым спорным
    <dotkc> сбор пожертвований, безусловно, был спорным моментом. Я думаю, многим из вас будет намного легче понять всю концепцию, если вы посмотрите на код и увидите, как мы дополняем пожертвования с помощью sweep_single
    <dotkc> вместо того, чтобы думать о пожертвованиях, мы, прежде всего, думаем о другом, о возможности безопасной траты
    <sarang> Какую конкретную эвристику, связанную со вспениванием, вы хотите избежать с помощью этой автоматизации?
    <dotkc> этот метод должен позволить пользователю раскрывать как можно меньше информации о себе в транзакции потенциальному злоумышленнику
    <sarang> Одна из причин, по которой у нас пока нет никаких официальных рекомендаций по вспениванию, заключается в отсутствии полного понимания соответствующей эвристики, которая может быть безопасно использована
    <sarang> Некоторые из них будут основываться на понятие времени, другие - на основе графика и т.д.
    <dotkc> некоторые из них, как мы уже обсуждали с @isthmus на прошлой неделе, избегают использования sweep_all, объединяющего несвязанные результаты без какой-либо явной выгоды
    <sarang> Можете ли вы предложить конкретные эвристики, которые вы хотите смягчить или избежать это в будущем
    <sarang> ?
    <dotkc> 1. sweep_all объединение несвязанных
    <sarang> (некоторые аналогичные рассуждения уже есть на GitHub / reddit, но я хотел бы услышать ваше резюме здесь)
    <dEBRUYNE> Мое личное мнение заключается в том, что ваш инструмент не получит распространения, если материал пожертвования (где создается третий вывод) не удалят
    <dotkc> 2. большое количество sweep_single за короткий промежуток времени с того же IP, переданная тем же соседям, бла-бла-бла
    <dotkc> спасибо, dEBRUYNE, я переделал его на дополнительную опцию после вчерашнего обсуждения
    <dotkc> давайте вернёмся немного назад. Я не предлагаю, что dots должен быть отдельным инструментом
    <dEBRUYNE> Почему пожертвование не может быть частью вспенивания?
    <dotkc> это инструмент для исследования вспенивания, который, вероятно, уйдет в небытие 2 способами
    <sarang> безусловно, это хорошая идея ограничить такие сетевые тесты, пока мы не проверим их комплексно
    <dEBRUYNE> dotkc: Обычно sweep_all с 1 входом создает 2 выхода, один из которых возвращается отправителю, а другой отправляется на случайный адрес
    <dotkc> 1. вспенивание - способ содействия конфиденциальности: мы переместим эти методы в основной кошелек
    <dEBRUYNE> Что, если бы вы заменили этот случайный адрес адресом для пожертвования?
    <dEBRUYNE> Тогда вы избавитесь от 3 выходной транзакций
    <sgp_> dEBRUYNE: именно это они и делали, если я правильно помню
    <dotkc> 2. при детальном разборе вспенивания мы обнаружили, что это наносит вред конфиденциальности, dots помогает разрушить эту иллюзию вспенивания == сохранить конфиденциальность, которая окружает это сообщество (меньше промежуточных пользователей)
    <dEBRUYNE> Я думаю, что может обеспечить частичную утечку
    <dEBRUYNE> иллюзию вспенивания == и сохранить конфиденциальность <= Я не согласен, думаю, что большая часть сообщества знает, что злоупотребление некоторыми функциями, такими как вспенивание, может повредить конфиденциальности
    <sarang> моя обеспокоенность в связи с пожертвованием также заключалась в том, что пожертвование на адрес с поддержкой только просмотра предоставляет публичную информацию, касающуюся операций вспенивания
    <dotkc> мы не делаем 3 выходных транзакции, я не уверен, кто именно вбросил это в обсуждение, кажется, они говорили о каком-то старом кошельке
    spaced0ut подключился (~spaced0ut@unaffiliated/spaced0ut)
    <dEBRUYNE>
    sarang: да, это было бы проблемой
    <sgp_> Это был пример для наблюдаемого поведения пожертвования, предпринятого кем-то еще, что имело схожие последствия для конфиденциальности
    <dotkc> «пожертвование» выглядит следующим образом: 1. sweep_single 2. потратить (пожертвовать) 3. произвести изменение
    <dotkc> если вспенивание и имеет преимущества, то этот метод будет самым безопасным способом потратить XMR
    <dotkc> мы делаем вспенивание перед тратой, потом тратим, затем только откат изменений
    <sarang> Я сомневаюсь, какие именно отпечатки оставляет данный метод на графике транзакций
    <sarang> нам нужно уделить этому особое внимание
    <sgp_> dotkc: по причинам, которые я упомянул вчера, включение пожертвований в результаты на любом этапе процесса постепенно будут ухудшать конфиденциальность. Было бы лучше, чтобы они предварительно 3 раза вспенивались без пожертвования. Думаю, что добавление этой функции пожертвовании заставляет мыслить нас не логично
    <suraeNoether> я полностью согласен с sgp_
    <xmrmatterbridge> <oneiric> случайные временные задержки перед предварительной тратой -> трата -> смена вспенивания?
    <sarang> Хорошая точка зрения, мы можем говорить об общих стратегиях вспенивания независимо от пожертвований
    <dotkc> помните, что это необязательно для очень четко определенного тестового / исследовательского инструмента, который рекомендуется использовать для testnet
    <suraeNoether> вспенивание будет достаточно сложным процессом, чтобы придать дополнительный слой безопасности, не пытаясь при этом смоделировать пожертвования, уже встроенные в процесс
    <suraeNoether> dotkc: пожалуйста, поймите
    <sarang> Случайные временные задержки, безусловно, важны для смягчения временных эвристик
    <suraeNoether> мы рекомендуем отказаться от этого из-за свойств конфиденциальности Monero, которые делают конфиденциальность каждого пользователя в отдельности чувствительной к выбору другого участника сети
    <sarang> Специфичная для графа эвристика будет зависеть также от скорости транзакций (появления выходов в других кольцах-приманках и т.д.)
    <suraeNoether> если некоторые пользователи хотят пожертвовать, отлично, они могут самостоятельно построить свою транзакцию и сделать это более рационально и правильно, вы же говорите о вставке дополнительного пункта в процесс, связанный с общей безопасностью
    <suraeNoether> это все равно что пытаться встроить автоматические пожертвования в процесс на этапе обмен ключами Monero
    <sarang> Хорошо, давайте обсудим идею вспенивания без идеи пожертвования
    <suraeNoether> это как езда на тракторе под галлюциногенами или деление на ноль, вы можете сделать очень много чего, да что уж там, практически всё, что только захотите, но это не оправдывает разумности этого выбора
    <suraeNoether> Итак, перейдем к вспениванию и его моделированию
    <midipoet> я в замешательстве после ваших разговорах о «пожертвовании»
    <sarang> Хорошо, давайте пока забудем об этой идее включения пожертвований для вспенивания
    <suraeNoether> В своих тестах я имитирую экономику, где каждый выход рождается в денежной / обычной транзакции. Транзакции Coinbase имеют фиксированную вероятность P быть отправленными «помеченной» стороне.
    <sgp_> это хорошая идея
    <suraeNoether> все остальные транзакции принимают все отмеченные входы, либо, наоборот, все не отмеченные входы
    <dotkc> большинство из вас, кажется, зациклены на части «пожертвования», поэтому я прошу вас рассматривать тот же алгоритм, который используется вместо «траты»
    <suraeNoether> транзакция с неотмеченными входами имеет фиксированную вероятность Q быть отправленной той же самой «помеченной» стороне
    <dotkc> например, если вы хотите заплатить кому-то, и вы знаете, что его кошелек в конечном итоге будет скомпрометирован
    <dotkc> это аналогичная проблема, как если бы вы просто отправили на адрес пожертвования с открытым ключом
    <suraeNoether> почему вы отправляете деньги кому-то, кто, как вы подозреваете, потеряет пароль к кошельку?
    <suraeNoether> или это подарок злоумышленнику?
    <sgp_> dotkc: да, но вы предлагаете пожертвование как часть процесса вспенивания, а не как часть платежа после того, как вы вспенили свои средства
    <xmrmatterbridge> <oneiric> люди должны быть осторожны с тем, кому они делают пожертвования, необходимы минимальные понимания безопасности
    <suraeNoether> хорошо, я хочу немного поговорить о формальном статистическом моделировании, и, наконец, уже перестать говорить о пожертвованиях
    <sarang> да, пожалуйста
    <suraeNoether> dotkc: давайте поговорим об этом более подробно после встречи
    <suraeNoether> а сейчас давайте поговорим о статистике
    <sgp_> Я думаю, что мы должны отложить обсуждение пожертвований, так как кажется, что мы будем продолжать топтаться на одном месте. Мы можем вернуться к этому вопросу в нерабочее время.
    <sarang> ^
    <suraeNoether> В своих тестах я имитирую экономику, где каждый выход рождается в денежной / обычной транзакции. Транзакции Coinbase имеют фиксированную вероятность P быть отправленными «помеченной» стороне.
    <xmrmatterbridge> <oneiric> маршрутизация для всех подделок в криптографии будет отличным инструментом для исследования
    <dotkc> в любом случае мы должны иметь возможность тратить средства без учета конфиденциальности, в независимости от того, что они могут держать свой кошелек в секрете.
    <suraeNoether> все остальные транзакции принимают все отмеченные входы либо, наоборот, все не отмеченные входы
    <suraeNoether> транзакция с неотмеченными входами имеет фиксированную вероятность Q быть отправленной той же самой «помеченной» стороне
    <suraeNoether> когда выход создан, продолжительность жизни для этого выхода выбирается случайным образом
    <suraeNoether> если вывод не отмечен, срок жизни извлекается из распределения времени траты кошелька
    <suraeNoether> когда блок начинает движение, все выходы, помеченные как «подлежащие трате», объединяются в транзакции с использованием эмпирического распределения числа входов и выходов, предоставленных n3ptune, isthmus в #noncesense-research-lab
    <suraeNoether> затем этот процесс повторяется
    <suraeNoether> параметры, которые в этом уравнении варьируются от моделирования к моделированию, это то «что помеченная сторона делает со своими выходами?»
    <suraeNoether> в случае вспенивания с определением фиксированного временем ожидания между процессом вспенивания и ответом будет «отправить N раз, каждый раз ожидая в ответ h блоков между отправками»
    <sarang> Как после этого будет оценивается результирующий график?
    <suraeNoether> в случае вспенивания, когда кошелек ждёт распределение времени (которое статистически идентично построению фоновой экономике в этом моделировании) и производит вспенивание очень большое количество N раз, и становиться ясно, что злоумышленник будет иметь нулевое преимущество в попытке идентификации вспенивания
    <midipoet> вспенивание — это глагол
    <suraeNoether> "вспенивание" это существительное :D
    <suraeNoether> после того как симуляция закончена, злоумышленник уже запускает свой алгоритм сопоставления, и у нас получается совсем другой набор параметров для проверки: какие именно схемы и модели использует злоумышленник, чтобы попытаться найти истинную схему траты жертвы
    <suraeNoether> Таким образом, я должен сделать два выбора относительно того, как это будет происходить: во-первых, я выбираю распределение, в котором помеченная сторона, неприменно будет тратить и, во-вторых, я выбираю модель, в которой противник планирует использовать для сопоставления транзакции. Тогда полученная из этой вереницы таблица будет отвечать на вопрос: «Насколько хорош алгоритм сопоставления, когда используется помеченная сторона X и когда помеченная сторона использует модель Y»?
    <suraeNoether> и для каждого из этих вариантов я могу создать отдельные таблицы
    <sarang> правильно, я думаю, что нужно еще уточнить то, что именно противник использует в своих схемах
    <suraeNoether> точно!
    <suraeNoether> вот почему я хочу воспользоваться выходом от sgp_
    <sarang> некоторые из этих схем будут основаны на времени, которого можно избежать с помощью добавления надлежащего времени задержки
    <suraeNoether> проблема заключается в том, что злоумышленник может использовать любую эвристику, которая ему нравится, для построения своей модели
    <sarang> Другие основаны исключительно на данных из графика и сильно зависят от использования выходов в ложных целях и связей между выходами истинного / поддельного изменения на этом самом графике.
    <xmrmatterbridge> <oneiric> эта проблема, по крайней мере, частично решена в Dandelion++?
    <suraeNoether> НО! Эта идея заключается в том, что если вспенивание использует фоновое распределение, это будет только одна сторона медали. Я утверждаю это в качестве дополнения, поскольку модель Y расходится с распределением затрат времени кошелька, следовательно, качество результатов станет более устойчивым к изменениям при выборе X, т.е. вы в своём большинстве будете неотличимы, но если ваше поведение
    <suraeNoether> начинает выходить за рамки, вы становитесь очень легкой мишенью
    <sarang> D++ влияет только на работу процесса ретрансляции
    <suraeNoether> oneiric, это всё связано с регистром и игнорирует сеть и процесс майнинга
    <sarang> это добавит задержки
    <sarang> но они очень незначительны
    <xmrmatterbridge> <oneiric> re: запутывает истинное время траты + происхождение
    <suraeNoether> oneiric, это, по сути, судебная экспертиза в среде кольцевых подписей :p
    <sarang> D++ помогает против сетевого наблюдения, а не в ключе целевого наблюдения
    <midipoet> правильно ли я понимаю смысл этой симуляции, он заключается в том, что выходы находятся в вечном движении (вспенивании)?
    <xmrmatterbridge> <oneiric> Оу, всё понял, спасибо, это на уровне подписей
    <dotkc> я предлагаю назвать такой принцип поведения – сопровождение вспенивания
    <midipoet> мы же закончили со вспениванием
    <suraeNoether> midipoet: в моем построении, да, именно так я моделирую экономику, чтобы создавать тестовый блокчейн
    <dotkc> я согласен с @suraeNoether, что при его анализе подходящее время делает такие шаги довольно ресурсоёмкими в плане разоблачения
    <suraeNoether> в конце концов, цель правильного выбора распределения кошелька заключается в том, что все выходы будут иметь возраст, взятый из него же
    <suraeNoether> в любом случае я довёл до ума этот эксперимент, теперь это работает «точно» правильно, что случай, в котором вспенивание соответствует распределению кошелька для N вспениваний подряд, будет попросту неотличимо, и вероятность того, что какой-либо один отслеживаемый элемент будет равен R^ -N, так что теперь мы можем думать об этом, как об идеализированной модели
    <dotkc> это пренебрегает многими реальными соображениями
    <suraeNoether> При использовании аргумента атаки «день рождения», вспенивания с длиной >23 будет достаточно. Но в любом случае этот показатель большой, и я подозреваю, что на практике у нас будут гораздо меньшие цифры
    <xmrmatterbridge> <oneiric> насколько логично пренебрегать такой цифрой сейчас и постепенно подниматься к более высоким значениям?
    <suraeNoether> dotkc: мы можем смоделировать различные эвристические методы, используя мой вышеупомянутый подход в рамках компонента «модель Х» из моей маленькой напыщенной речи выше
    <sarang> В какой степени мы уже определили набор эвристических кандидатов?
    <suraeNoether> сейчас это лучшая помощь, которую я могу получить от вас ^
    <suraeNoether> Бинго
    <suraeNoether> прежде чем я закончил печатать, Саранг одержал заочную победу
    <sarang> Фреймворк отличный, но крайне ограниченный
    <sgp_> они могут быть проверены с использованием «вымышленного» блокчейна
    <sarang> Я предлагаю, чтобы dotkc и suraeNoether более тесно работали над выявлением такой эвристики для дальнейшего изучения, будь то временные или чисто графовые значения
    <sarang> Наличие совершенно разных путей исследования, вероятно, будет пустой тратой ресурсов
    <dotkc> согласен
    <sarang> я согласен с sgp_ (и другими), что получение этого должно быть главным приоритетом
    <suraeNoether> сейчас я тестирую 1) периодические неслучайные траты, такие как подписка на журнал, 2) единичное экспоненциальное время ожидания , такое как нетерпеливый «вспениватель», но у которого есть некоторые статистические данные по вашему кошельку, 3) гамма-распределение, но с возможностью плавной настройки, чтобы увидеть чувствительность таблицы к путанице с разницей в период между временем ожидания
    <sarang> Я ценю ваш интерес и готов заняться этим вопросом специально для dotkc
    <xmrmatterbridge> <oneiric> возможно, 4) равномерно-случайный в заданном диапазоне
    <suraeNoether> 3) также соответствует нетерпеливому (или параноидальному!) вспениванию
    <dotkc> могу ли я предложить несколько небольших достижений, которые могут в свою очередь понравиться сообществу, пока продолжаются более всесторонние исследования?
    <suraeNoether> oneiric, круто! Добавлю данный пункт
    <sgp_> oneiric, да, это отличный тест
    <sarang> Что ты имеешь в виду, dotkc?
    <xmrmatterbridge> <oneiric> :)
    <sgp_> suraeNoether: Я напишу вам в личные сообщения при удобном случае
    <suraeNoether> ^ Бинго-Бонго!
    <moneromooo> Не уверен, поможет ли это, но у меня есть старый патч, который разделяет tx, чтобы получить только один вход за раз, и отправлять их с задержкой Пуассона.
    <dotkc> топ большинства поисковых запросов - это заслуживающий доверия пост, рекомендующий использование sweep_all
    <sarang> Кстати, dotkc, вы разработчик кода для dots?
    <dotkc> В сообществе есть множество советов, чтобы соблюсти конфиденциальность, и тысячи людей повторяют один и тот же совет - sweep_all (если счетчик страницы является показателем)
    <dotkc> разработчик, да
    <sarang> я придерживаюсь мнения, что на данный момент нет подробных проверенных рекомендаций по вспениванию
    <suraeNoether> ^
    <suraeNoether> это жестокое место
    <dotkc> согласен
    <dotkc> но можем ли мы договориться о чем-то, что по определению плохо?
    <sarang> Он борется с неизвестным набором эвристики
    <sarang> Это будет интересный опыт, dotkc
    <dotkc> устранение даже одного «плохого» случая - это прогресс, который будет поддерживать конфиденциальность пользователей
    <sarang> согласен
    <suraeNoether> лучшая практика заключается в том, чтобы тратить на «базовую правду» фоновый уровень расходов экономики, следующее лучшее решение - массивные наборы анонимности, поэтому анализ времени на входе терпит неудачу, или как показывает пример zcash, это не делает попросту ничего для выхода.
    <sarang> например, идея sweep_all против single
    <suraeNoether> я проверяю эту гипотезу
    <dotkc> я намерен перераспределить силы на «менее плохое» с моими краткосрочными целями для dots
    <sarang> как уже говорилось ранее, связывание выходов - плохая идея
    <sarang> и очень тяжелая, пока / если мы не включим coinjoin
    <suraeNoether> dotkc: худшее, что может быть реализовано – это периодическое поведение
    <suraeNoether> dotkc, я имею в виду детерминистически-периодические
    <sarang> suraeNoether: возможно, даже худший с точки зрения времени
    <sarang> не обязательно, если смотреть с точки зрения других метаданных (например, in / out counts)
    <suraeNoether> да, большая часть моей работы основана только на времени
    <suraeNoether> периодическое поведение выделяется в энергетическом спектре, как новичок в тренажерном зале
    <sarang> Структура графа, конечно, переплетается со временем, но есть и множество других
    <dotkc> я согласен с вами, что связи sweep_all и тривиальные временные связи кажутся очень плохими выбором
    <sarang> Я считаю, что связывание выходных данных крайне сложно избежать, поскольку это неотъемлемая часть multi-input txns
    <sgp_> это зависит от обстоятельств, но в любом случае sweep_all - плохой вариант, если вы не хотите, чтобы эти выходы были проанализированы
    <moneromooo> Если вы не хотите, чтобы они были связаны с вами, просто используйте две учетные записи, нет?
    <sgp_> moneromooo: да, всегда держи свои результаты отдельно :)
    <sarang> dotkc предлагал идеи с несколькими учетными записями на GitHub
    <dotkc> это прогресс! мы почти договорились по крайней мере об одном «плохом» поведении!
    crCr62U0 вышел (~crCr62U0@gateway/tor-sasl/crcr62u0): Причина — время бездействия: 256 секунд
    <sarang>
    В интересах экономии времени давайте кратко подведем итоги, а затем продолжим обсуждение
    <sarang> Давайте перейдем к 4. КЛЮЧЕВЫЕ МОМЕНТЫ
    <dotkc> @sarang: вы правы
    <sarang> одну секунду, dotkc
    <suraeNoether> dotkc: периодическое поведение или любое другое поведение по времени, которое принципиально отличается от «фоновой скорости» расходов, будет выделяться статистически. Я могу сказать вам это со 100% уверенностью.
    <sarang> Помимо участия в обсуждении вспенивания, чтобы помочь suraeNoether и другим с фреймворками, я дорабатываю материал по CLSAG, а также стараюсь устранить проблему в безопасности DLSAG
    <sarang> suraeNoether: ваши ключевые моменты?
    <suraeNoether> Мои ключевые моменты: симуляции для MRL-11. sgp_ собирался прислать мне несколько ссылок на возможные варианты поведения. Продолжение размышлений о судьбе dlsag и доказательство безопасности clsag. Мммм...
    <suraeNoether> я планирую еще немного заняться рекреационным кодированием spectre в конце недели и посвятить несколько часов сопоставлению
    <sarang> отлично
    <sarang> Кажется, все согласны с тем, что сопоставление / вспенивание должны быть приоритетом, который слишком долго откладывался на второй план
    <sarang> Спасибо всем за участие! Журналы будут опубликованы на GitHub в ближайшее время
    <sarang> Пусть обсуждение продолжается!
    <sgp_> Moneroversary! Напоминание! Оставьте свои комментарии, если вы хотели бы принять участие: https://github.com/monero-project/meta/issues/324
    * sarang, пожалуйста установите соответствующую тему – Встреча исследовательской лаборатории по понедельникам в 17:00 UTC. Будьте добры друг к другу!

    Источник: Research meeting: 8 April 2019 @ 17:00 UTC #327

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

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