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

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

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    179
    Симпатии:
    13
    Когда: Понедельник, 7 октября 2019 г., 17:00 UTC
    Где: #monero-research-lab (freenode/matrix)

    Повестка дня:
    1. Приветствия
    2. Круглый стол
      a. Саранг: обновление Lelantus, обновление доказательства концепции и анализа RCT3
      b. Шура
      c. Прочие участники?
    3. Вопросы
    4. Ключевые моменты
    <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> это хорошо, нам нужно понять раньше других все его плюсы, прежде чем какая-то другая монета реализует это :p
    <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: спасибо, это непременно важная информация :p
    <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 :p
    <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)
     
    Am1n нравится это.
  • О нас

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