Перевод Кластер критической децентрализации 36c3 - Эксперименты на пути к интеграции Namecoin в Tor Browser

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

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    788
    Симпатии:
    229

    Аннотация

    Разработчики Namecoin и Tor начинают новый эксперимент: сборки GNU/Linux Nightly Builds для браузера Tor теперь имеют опциональную поддержку, позволяющую использовать домены .bit Namecoin. Этот эксперимент призван решить давнюю проблему пользовательского опыта, связанную с доменами .onion — отсутствие удобных для человеческого понимания названий. При использовании Namecoin вы получаете доступ к луковым сервисам через читабельные и запоминаемые адреса, такие как http://federalistpapers.bit/ вместо http://7fa6xlti5joarlmkuhjaifa47ukgcw... . В данном выступлении я расскажу о целях эксперимента, об уже проделанной до этого момента работе, и о том, что ещё предстоит сделать.

    Стенограмма выступления

    Диего:
    Сейчас здесь появится Джереми, который расскажет нам о Namecoin. Я приглашаю его сюда, а сразу после выступления он сам проведёт семинар, по-моему, это будет в той части, где у нас проводятся семинары, и там он продемонстрирует всё то, о чём сейчас будет говорить. Так что продолжаем, выходи на сцену, поаплодируйте. Он расскажет о Namecoin, Tor… аплодисменты, да-да, аплодисменты… Окей, окей, начинаем. Джери, бери микрофон.

    Джереми: Итак, меня зовут Джереми, я представляю Namecoin. Сегодня я расскажу вам о том, что приключилось со мной в течение последних нескольких лет или около того, когда я пытался интегрировать Namecoin в Tor Browser и экспериментировал в этой интереснейшей области. И почему бы нам не начать?

    Прежде всего, небольшой отказ от ответственности: это выступление не о Tor. Я являюсь разработчиком Namecoin, и это в некоторой степени определяет мой взгляд на вещи. Видение разработчиков Tor может отличаться от моего, но это вполне нормально.

    Так, вероятно, все здесь знают, что сервисы .onion, используемые Tor, очень и очень круты. Они подразумевают шифрование, аутентификацию и устойчивость к цензурированию — всё это просто невероятно здорово. И эти сервисы даже не зависят от какой-либо третьей доверенной стороны, такой как сертифицирующие органы, всё просто волшебным образом встроено в Tor. И это замечательно. Но, к сожалению, существует проблема, связанная с опытом пользовательского взаимодействия (UX). Вы спросите, в чём проблема? А вот в чём.

    Адреса. Их же практически невозможно запомнить или даже просто узнать. И поэтому пользователи, как правило, не проверяют весь адрес, что создаёт возможность для проведения фишинговой атаки.

    Теперь для тех, кто не был вчера на вводном выступлении, посвящённом Namecoin, я вкратце расскажу то же самое. Namecoin, по сути, это DNS, но на базе блокчейна. Мы используем домен верхнего уровня .bit. Внутри имена представлены специальными монетами, которые вы можете рассматривать в качестве «цветных монет». Мы являемся первым проектом, ответвившимся от Bitcoin в 2011.

    Разработчики Namecoin очень быстро поняли, что использование Namecoin на уровне именования сервисов .onion является потенциально интересным, поскольку это обеспечит возможность децентрализованного создания имён, как и в случае с .onion, но только они уже будут иметь значение для пользователя. Так, например, federalistpapers.bit указывает на сервис .onion под названием Federalist Papers. И это решает проблему UX.

    Первая реализация состоялась в июле 2011. Это был NmcSocks, созданный itsnotlupus. Эксперименты в этом направлении продолжались ещё несколько лет. Мы многое обсуждали с разработчиками Tor, но далеко не многое из того, о чём говорилось, было воплощено в жизнь. Я выступал на 34C3 по этой теме, так что вы можете посмотреть это выступление, если интересно.

    А затем нами были отмечены некоторые признаки растущего интереса. И это произошло, когда я в октябре прошлого года столкнулся в Twitter с разработчиком Tor по имени Артур Эдельштейн. Вот и всё, что произошло — я подписался на RSS рассылку всех результатов поиска, связанного с Namecoin, в Twitter, чтобы узнать, что люди думают о нас, и вот что я нашёл. Не уверен, сможете ли вы прочитать это. Артур написал: «Мне хотелось бы сделать сайты .onion проще, чтобы доменные имена можно было запомнить. Разные подходы подразумевают разные свойства, которые я пытаюсь исследовать». И среди прочих в качестве такого интересного подхода он упомянул Namecoin. Так что я ответил и написал: «Привет, я — разработчик Namecoin, который создал прототип именования Namecoin для сервисов .onion. Конечно же, меня по-прежнему интересует эта тема, было бы здорово пообщаться и обсудить дальнейшие шаги».

    Так мы занялись обсуждением этого вопроса, и это было интересно и отличалось от всего, что было до этого, поскольку раньше все эксперименты ребят из Tor были направлены на то, чтобы пользователи могли самостоятельно установить редактор Namecoin в браузер. Именно так появилось «Предложение 279» (Proposal 279), предполагающее реализацию подключаемого API именования. Но в этот раз Артур ориентировался на иной подход, и он написал: «Я думаю, модульность — это хорошо, но мне не кажется, что сидеть и ждать, пока «пески времени» выявят победителя, было бы правильно. Проекту Tor следует реализовать и развернуть соответствующие блоки в Tor и Tor Browser, а затем мы увидим, что получится, и сможем задействовать итеративный подход».

    И что меня по-настоящему удивило, когда я начал общаться с ребятами из Tor по этой теме, так это то, что они полностью признавали, что отсутствие имеющих значение названий доменов .onion действительно является проблемой UX, а также большой проблемой с точки зрения безопасности. До той степени, что команда Tor была готова изменить модель безопасности, чтобы исправить ситуацию. В частности, это означало, что обеспечение гарантированной анонимности владельцев имён, по сути, не является требованием, по крайней мере, в краткосрочной перспективе. То есть им хотелось быть уверенными в том, что у нас есть план, который обеспечит это в конечном счёте, но это не было каким-то строгим требованием, которому надлежало следовать в ближайшее время.

    Но к чему они относились очень серьёзно — это производительность и масштабируемость. Так, например, у Артура был такой сценарий рекомендательного характера, который касался требований, которые он хотел бы предложить, и этот сценарий сводился к тому, чтобы пользователь мог установить Tor Browser с нуля и запустить его, а затем смог сразу вбить название домена .bit в адресную строку, и задержка не была бы дольше, чем можно было бы ожидать от веб-сайта .onion, а это означало, что случайное отклонение с точки зрения встраивания схемы Tor в сервис .onion должно было стать доминирующей составляющей задержки. Сложно? Да, сложно.

    Когда он сказал это, моей первой мыслью было: «Окей, не придуман ещё способ, чтобы мы справились с этим». Но что я действительно не сказал, так это: «Окей, это будет по-настоящему сложно, но есть масса вариантов оптимизации, которые мы могли бы реализовать и которыми мы не занимаемся сейчас. Так что, пожалуй, я могу поэкспериментировать, и посмотрим, что из этого выйдет». И ведь это общее правило для всех разработчиков программного обеспечения: не следует никому сразу же говорить, что что-то невозможно сделать, по крайней мере, перед тем как сказать такое, следует провести хоть какие-то исследования.

    В то время Ахмед Бодивала и я финансировались NLnet и Cyphrs и занимались портированием Electrum, лёгкого кошелька Bitcoin, в Namecoin. Это было совсем недавно, и именно в этот момент Артур и я впервые заговорили о Tor, и, несмотря на то, что тогда ещё Electrum-NMC находился практически в зачаточном состоянии, после разговора с Артуром стало понятно, что нам следует ставить на кодовую базу, и это позволит нам достичь тех показателей производительности, которые были намечены Артуром.

    NLnet, по сути, позволили нам перераспределить часть финансирования на разработку другого лёгкого клиента под названием ConsensusJ-Namecoin. И судя по тому, что мы обсуждали с Артуром, для нас это было тупиковое направление, поскольку решение предполагало наличие начальной пятиминутной синхронизации, и мы уже никак не могли это оптимизировать. К счастью, NLnet с лёгкостью согласились перенести финансирование с одного набора производных на другой. И мы решили перенести финансирование с ConsensusJ-Namecoin, сфокусироваться на Electrum-NMC и довести проект до того состояния, когда он стал бы работать с Tor. Так что я выражаю искреннюю признательность NLnet за то, что обеспечили такую гибкость — это было круто.

    Итак, с чего мы начали в октябре 2018, до того как всё было оптимизировано. Начальная синхронизация предполагала загрузку 672 мегабайт, что при использовании моей системной платы Thalos II занимало примерно шесть минут, и это при довольно быстром процессоре и без использования Tor. Так что мы были ещё очень далеки от целевых показателей, намеченных Артуром.

    Для тех, кто не знает, как Electrum для Bitcoin кодирует контрольные точки. По сути, это список хешей каждого 2016-го блока. Electrum просто загружает заголовки для блокчейна, которые находятся после хеша последней имеющейся контрольной точки. И это хорошо, так как… обычно вы создаёте кошелёк после контрольной точки, поэтому необходимость в загрузке заголовков тех блоков, что были до этой точки, отсутствует, и, так или иначе, они уже более не понадобятся, поскольку они не будут касаться вашего кошелька. Но если сделать так, что придётся произвести валидацию транзакции, которая была до хеша последней контрольной точки, то Electrum придётся загружать все 2016 заголовков блоков, находящихся между двумя хешами контрольных точек, которые были вокруг неё, а затем производить валидацию транзакции при помощи SPV.

    Но это не работает так же хорошо в случае с Namecoin, и вот почему. Всё ещё действительные имена могут обнаружиться где угодно среди последних 36 килоблоков. А это значит, что даже если кошелёк был создан после последней контрольной точки, могут найтись имена, которые были обновлены до последней контрольной точки, если только контрольная точка не была установлена 36 килоблоков назад. То есть это означает, что мы не можем сделать это на контрольной точке, предшествующей этой. Но если мы зададим контрольную точку, которая будет находиться 36 килоблоков назад, объём синхронизации снижается до 66 мегабайт, а это уже десятикратное улучшение, что очень неплохо для начала. Но как нам улучшить и эти показатели?

    А что если нам задать контрольную точку, которая будет находиться раньше, чем за 36 килоблоков? Это снизит нагрузку, связанную с начальной синхронизацией, до 4,9 мегабайт. Неплохо, но это означает, что если вам придётся искать заголовок блока, который вы пока не загрузили, то вам придётся загружать 2016 заголовков. Это составляет 3,2 мегабайта, и это только во время поиска заголовка. Таким образом, образуется дополнительная задержка при поиске имени, а это уже серьёзная проблема с точки зрения производительности. Можем ли мы улучшить это?

    Ответ: да. Заголовки блоков Namecoin. Если вы незнакомы с тем, как работает объединённый майнинг, заголовок блока Namecoin состоит из двух частей: есть заголовок блока в стиле Bitcoin, размер которого равен 80 байтам, все его поля будут теми же, что в случае с Bitcoin, и есть заголовок объединённого майнинга, имеющий переменную длину, но она редко составляет более 10 килобайт. И обе эти части должны верифицировать доказательство работы, но штука в том, что если у вас есть какой-то другой способ верификации правильности заголовка блока, то вам не нужен заголовок объединённого майнинга. И знаете что — контрольная точка является действенным методом, чтобы сделать это. Если обязательством по правильности заголовка блока является контрольная точка, вы можете быть уверены в том, что доказательство работы является действительным для этого заголовка блока.

    Так как контрольная точка позволяет верифицировать заголовок блока без заголовка объединённого майнинга, это означает, что у нас нет необходимости в загрузке заголовка объединённого майнинга. Я подправил протокол таким образом, что он не отправляет заголовков объединённого майнинга для блоков, высота которых предшествует последней контрольной точке, и это сокращает размер требуемого набора из 2016 заголовков с 3,2 мегабайт до 323 килобайт. Круто. Очередное десятикратное улучшение, но… знаете, 323 Кб это по-прежнему многовато, если их загружать через Tor при поиске DNS. Можно ли улучшить и этот результат? Давайте посмотрим.

    Итак, протокол Electrum, по сути, реализует формат дополнительной контрольной точки, использующий доказательства Меркла. Идея состоит в том, что клиент обеспечивает корень дерева Меркла со всеми заголовками, имеющимися до высоты последней контрольной точки, а затем клиент запрашивает сервер: «Я хочу видеть данный заголовок блока в блокчейне», и сервер выдаёт доказательство по ветви дерева Меркла, если такой заголовок будет запрошен. Таким образом, вы можете загрузить один заголовок за раз. Вам уже не приходится загружать все эти 2016 заголовков. И всё же вы по-прежнему связаны с контрольной точкой посредством доказательства Меркла. И что хорошо в доказательствах по ветвям дерева Меркла, если вы не знакомы с тем, что это такое, хорошо в них то, что их размер изменяется логарифмически, что обеспечивает прекрасную масштабируемость.

    Теперь, к сожалению, мне было нужно портировать всё это с Electron-Cash на Electrum, поскольку единственный вариант реализации был предназначен для Electron-Cash, то есть BCH форк Electrum. И я произвёл портирование на Electrum, а затем объединил, скажем так, всё с Electrum. Но это сработало, и теперь вместо 323 килобайт, необходимых для получения заголовка блока для доказательства SPV, уже требовалось менее двух килобайт. И это более чем просто здорово, что мы можем сделать это в случае с Tor.

    Но что насчёт заголовков, идущих после последней контрольной точки, как правило, это заголовки, которые были добыты уже после выхода программного обеспечения. Electrum обычно одновременно загружает заголовки только с одного сервера. Это легко оптимизируется, и я сделал так, чтобы они загружались параллельно с разных серверов. Неплохо, так как это значительно ускоряет процесс синхронизации.

    У Артура также был свой взгляд на влияние окончательного двоичного размера при загрузке Tor Browser, и он сказал: «Размер Tor Browser составляет от 60 до 80 мегабайт, поэтому добавление ещё нескольких мегабайт, возможно, будет приемлемым, до 10 мегабайт, иначе будет уже слишком». Проблема состояла в том, что размер всех компонентов Namecoin, которые должны были быть интегрированы в Tor Browser, в совокупности составлял 39,7 мегабайт. Это требовало серьёзной оптимизации.

    Первым, что требовало оптимизации, была группа ненужных функций, которые надо было сделать отключаемыми на момент сборки. У Electrum-NMC очень привлекательный GUI, но этого не требуется для Tor Browser. Имеются плагины для аппаратных кошельков, но, опять же, Tor Browser этого не нужно. Вещи, связанные с платёжным протоколом, по большей части используются для синхронизации с BitPay. Electrum-NMC не требуется этого в случае с Tor Browser, равно как и масса других функций, связанных с кошельками, таких как подписание транзакций — Tor Browser этого не нужно. Кроме того, наши кодовые базы, связанные с Go, в частности, ncdns и dns-prop279, содержат значительный объём кода, связанного с TLS и DNS, включая код, обеспечивающий TLS поддержку Chromium, но Tor Browser этого также не требуется. На момент сборки всё это становилось опциональным, и мы могли попросту избавиться от всего этого.

    Если вы не знаете, что такое Go, двоичные файлы Go всегда статически связаны, и время запуска Go значительно. У нас было два разных выполняемых файла Go, ncdns и dns-prop279, а это, к сожалению, означало, что эти двоичные файлы дублировали многое из своего содержимого. Поэтому у нас были веские причины пропустить два этих двоичных файла, но мы объединили их в один специализированный инструмент. Это позволило избежать избыточности статической библиотеки, что очень помогло.

    Кроме того… мы использовали проект TorNS, созданный meejah, в качестве зависимости, а также txtorcon, библиотеку, отвечающую за связь с портами управления Tor. И это имело смысл, поскольку если meejah занимается разработкой txtorcon, очевидно, он воспользовался бы этой библиотекой. Но, к сожалению, txtorcon очень велика, её зависимости велики, поэтому я сделал так, чтобы TorNS использовал Stem вместо txtorcon — это другая библиотека, контролирующая порты управления. В Stem отсутствуют дополнительные зависимости, в целом она меньше, так что это нам здорово помогло. И сейчас я хотел бы поблагодарить Джеси Викторс из Onion Name System за образец кода, который очень помог в этом случае.

    Итак, как мы сократили двоичный размер? В целом он уменьшился с 39,7 до 3,3 мегабайт. Да, это уже было серьёзное сокращение, но это уже не было тем, что препятствовало бы соответствию требованиям, о которых говорил Артур.

    Итак, после того как мы добились соответствия поставленным целям, настало время продемонстрировать результат всем остальным разработчикам Tor, чтобы получить дополнительное одобрение. Демонстрация состоялась 26 апреля этого года, и на ней присутствовал Джордж Коппен, который на тот момент являлся ведущим разработчиком Tor Browser. И как ожидалось, были некоторые сомнения, но в целом всё прошло позитивно, и это было здорово.

    И здесь мне бы хотелось немного уйти в сторону. У Tor прекрасная культура анализа, и в один из моментов, когда я рассказывал, что мы, по сути, предлагаем, меня спросили: «Допустим, вы столкнётесь с возражениями против интеграции Namecoin в Tor Browser. Какие аргументы вы приведёте в защиту проекта?» И это хорошая постановка вопроса, поскольку такая формулировка позволяет разработчикам узнать оборотную сторону и все компромиссы, связанные с их предложением, без какой-либо враждебности. И мне хотелось бы, чтобы такие вопросы задавались в отношении как можно большего количества проектов FLOSS. Так что огромное спасибо Tor за их невероятную культуру анализа.

    Но даже несмотря на весь оптимизм, всё это пока ещё только эксперимент, а не то, что мы готовы предложить конечным пользователям прямо сейчас, и охват результатов в этом случае является довольно узким. В частности, это означало, что домены .bit не указывают на IP-адреса, а только на «луковые» службы. Это означает отсутствие TLS, и что мы не собираемся делать что-то, кроме «ночной» сборки, и что, по крайней мере, прямо сейчас не будет никакой стабильной или альфа-версии. Будет создана только новая версия для Linux, которая будет отключена по умолчанию, и будет необходимо воспользоваться переменной среды, чтобы запустить её. По крайней мере, так будет сейчас.

    И одна из причин, по которой нам бы хотелось, чтобы результат был ограниченным, состоит в том, чтобы ограничить риск, которому подвергаются конечные пользователи в связи с этим новым кодом. А ограничение риска означает, что анализ будет проще и быстрее. А если эксперимент будет удачным, то мы всегда сможем расширить охват позже. Все пять ограничений, описанных мною, все их можно снять, если эксперимент окажется удачным. Ну а если не окажется, то так оно и будет. Ну и, кроме того, добавление всего этого дополнительного кода в сборку Tor Browser, кода, который также является дополнительной нагрузкой для разработчиков Tor, ограничение объёма также оказывает на влияние на рабочий процесс, связанный с управлением кодовой базой. И именно так и задумано — если они решат избавиться от него впоследствии, то они смогут сделать это с лёгкостью и без каких-либо затруднений.

    Я ранее уже упомянул, что обеспечение анонимности владельцев имён не являлось краткосрочным требованием, но нас волновала и анонимность людей, которые будут просматривать веб-сайты, поскольку она является критически важным свойством для пользователей Tor Browser. Таким образом, существует одна очень важная подфункция под названием «изоляция потоков», которая… это малоизвестная функция Tor, но она очень важна. По сути, она обеспечивает изоляцию трафика, связанного с действиями различных пользователей на различных контурах Tor. Именно это обеспечивает анонимность пользователей Tor, а не их псевдоанонимность.

    И, к сожалению, большой объём кода, связанного с интеграцией Namecoin, требовал внесения правок, которые бы позволили ему поддерживать изоляцию потоков надлежащим образом. И у меня ушло два или три месяца на то, чтобы всё работало, как положено. Тем не менее это давало определённые преимущества, поскольку изоляция потоков в сочетании с параллельным скачиванием блокчейна, которое мною упоминалось в связи с Electrum-NMC, позволяет скачивать заголовки одновременно по множеству контуров Tor. Таким образом, если вам попадётся плохой контур Tor, который будет слишком медленным, то в целом скачивание блокчейна уже не замедлится. И это огромное преимущество. Помимо правки программного обеспечения, связанного с Namecoin, мне было необходимо исправить демона Tor и Firefox, чтобы изоляция потоков работала, как следует, с Namecoin. Если честно, это была одна из самых трудоёмких частей этой работы.

    Оставалось только встроить всё это. Я хорошенько вычистил код и на личной встрече с Tor, которая состоялась в Стокгольме в июле 2019, интегрировал всё в сборку Tor Browser, включая встраиваемые сборки, что было довольно просто — у Tor Browser великолепная система воспроизводимых сборок, и, наконец, 11 ноября всё было передано разработчикам Tor для анализа. И после бесконечного множества циклов анализа и после того, как мне пришлось тщательно изучить все результаты, 18 декабря, наконец, состоялось добавление кода в Tor Browser Nightly. И первые официальные двоичные файлы Tor Browser Nightly с опциональной поддержкой Namecoin были опубликованы 20 декабря. Так что, как видите, это совершенно новый, буквально свеженький материал.

    И если вы хотите опробовать, как это работает, вы можете скачать самую последнюю версию Tor Browser Nightly для новой Linux на сайте Tor и запустить её с переменной среды TOR_ENABLE_NAMECOIN=1, после чего Namecoin будет использоваться для обработки адресов .bit и .bit.onion. Вы можете спросить: почему оба этих индекса — просто прямо сейчас это одно и то же. В будущем, возможно, .bit будет так же указывать на IP-адреса, а .bit.onion — только на «луковые».

    И если в целях тестирования вы захотите попробовать какие-нибудь доменные имена, вы можете воспользоваться этими: federalistpapers, onionshare, riseup и именами систем для запросов на Intercepts и WikiLeaks. И все эти домены сейчас принадлежат тем, кто любезно поддерживает Namecoin, и они будут рады пожертвовать ими в пользу добросовестных владельцев. Но так как пока этого не произошло, не особо полагайтесь на них в плане безопасности. Так что пока не стоит передавать что-то WikiLeaks при помощи этой URL. Я не даю никаких гарантий, что это будет безопасно.

    Итак, что дальше? Нам бы хотелось реализовать поддержку для Windows и macOS. Это будет несложно, но потребует некоторого рефакторинга. Опять же, написание воспроизводимой сборки на Python для Windows будет интересным и забавным предприятием. Нам бы хотелось обеспечить поддержку для Android — это уже будет просто кроличья нора. Кто знает, что нас там ждёт? Мы считаем, что нам ещё больше удастся повысить показатели производительности. Мы можем урезать задержку вдвое, урезать используемую пропускную способность вдвое и значительно сократить двоичный размер, воспользовавшись некоторыми хитростями, взятыми из проекта Go-Busybox, разработанного u-root. Нам бы хотелось реализовать удобный GUI для регистрации доменных имён, который был бы сконфигурирован под Tor, чтобы пользователи смогли выбирать из раскрывающегося меню, вводя домен .onion, а не строить JSON вручную. Нам бы хотелось обеспечить анонимность владельцев имён, даже несмотря на то, что для Tor это не является краткосрочным требованием. Всем, кто участвует в разработке, хотелось бы этого. Это будет достигнуто путём интеграции Monero и Bisq. Подробно о том, как это будет работать, я рассказал в рамках своего выступления на 34C3. Нам бы хотелось обеспечить поддержку IP-адресов, а не только «луковых» сервисов, равно как и поддержку TLS. Также мы хотим, чтобы поддерживались такие операционные системы, как UNIX и Tails, что сейчас не работает из-за фильтрации портов управления. Исправление этих OSS будет довольно несложным. Нам бы хотелось, чтобы валидация блокчейна стала лучше, чем сейчас в случае с Electrum. В частности, нам бы хотелось реализовать верификацию подписей ECDSA в именных транзакциях, а не только доказательства работы. Мы также хотим обеспечить поддержку аутентифицированных доказательств отсутствия. В этой области сейчас проводятся исследования, и мы надеемся на получение каких-нибудь полезных результатов. Возможно, мы даже найдём способ, который позволит использовать полные узлы с Tor Browser, но это уже совсем другой вопрос. Это будет сложно. И самое важное: нам бы хотелось получить больше откликов от сообщества Tor, поскольку нам пока неизвестны критерии, которые позволят нам перейти с версии Nightly на версию Alpha или Stable или же вообще сделать эту опцию используемой по умолчанию. Вы знаете, пожелания разработчиков Tor могут не совпадать с представленным списком планируемого. Они могут захотеть чего-то иного, и мы отнесёмся к этому с уважением, потому что это их браузеры, а не наши.

    И если вы захотите попробовать всё сами, я буду проводить семинар здесь, в Critical Decentralization Cluster, семинар состоится прямо после выступления. Захватите с собой машину с новой версией Linux, виртуальную машину или вообще голое железо и выразите своё мнение — удачный у нас эксперимент или нет. В любом случае нам будет важен ваш отклик.

    Мне бы хотелось поблагодарить наших спонсоров, которые сделали эту работу возможной: NLnet, Министерство экономики Нидерландов и Cyphrs — без их финансирования ничего бы не получилось. Так что огромное спасибо нашим спонсорам!

    Вот моя контактная информация. Вы можете связаться со мной прямо здесь на Конгрессе, я буду тут до самого конца. У меня на футболке большой логотип Namecoin, так что вы найдёте меня без труда. Спасибо. У нас ещё осталось время на вопросы? А, вы уже передаёте микрофон? Окей, отлично.

    Вопрос из зала: Что необходимо, чтобы запустить сервер, совместимый со всем этим? В частности, какой смысл в хост-заголовке?

    Джереми: Хороший вопрос. Вся переадресация происходит с .bit на .onion, и это происходит на транспортном уровне. А прикладной уровень, такие вещи, как хост-заголовок, равно как TLS и S&I заголовок, если вы используете TLS, всё это происходит в домене .bit, а не в домене .onion. И если у вас «луковый» сервис и вы хотите, чтобы он работал, как положено, с Namecoin, вам необходимо убедиться в том, что он соединяется с правильным сайтом, если хост-заголовок находится в домене .bit. К слову, по опыту практически все сервисы .onion соединяются правильно, независимо от отправленного вами хост-заголовка, возможно, потому что никто и не ждёт других хост-заголовков. Это просто не проверяется. Единственный «луковый» сервис, который на моей памяти повёл себя иначе — DuckDuckGo. Все остальные при любых обстоятельствах вели себя одинаково. Не слышу… Да, всё правильно. Это хорошая идея, конфигурировать их, чтобы они не отвечали ни на что другое. Вы правы. Но никто не занимается этим на практике. Ещё вопросы? Кажется, больше вопросов нет. Хорошо. Спасибо.

    [Аплодисменты]

    Разве только у Диего есть вопросы. Ты хочешь задать мне вопрос, Диего?

    Диего: Джереми, как тебе удаётся выглядеть так восхитительно, работая на Namecoin, и как кто-либо может помочь Namecoin, чтобы выглядеть так же?

    Джереми: Не буду никак комментировать, насколько восхитительно я выгляжу, а что касается помощи Namecoin и участия во всём, чем мы занимаемся, вы можете связаться с нами через наш IRC канал, namecoin-dev на freenode, также на канале Matrix, если вы предпочитаете Matrix. Вы можете написать мне по электронной почте, мой адрес написан вон там, вы можете встретиться со мной на Конгрессе и пообщаться, или же вы можете оставить пост на reddit, наш subreddit — /namecoin. Также у нас есть PHP BB форум, если вы любите олдскул и желаете общаться с нами именно так. Есть масса способов связаться с нами, и мы будем рады приветствовать новых разработчиков в наших рядах, мы будем рады работать с большим количеством людей. У нас очень дружелюбное сообщество. Нам нравятся новички, так что обязательно свяжитесь с нами, если вы хотите сотрудничать.

    Диего: Хорошо, большое спасибо, Джереми, поаплодируйте ему ещё раз.

    ---

    Источник: Critical Decentralisation Cluster 36c3 - Adventures and Experiments Adding Namecoin to Tor Browser

    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
    #1 Mr. Pickles, 20 окт 2020
    Последнее редактирование: 22 окт 2020
  • О нас

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