Открыть порты для bitcoin

Устанавливаем полную ноду биткоина с Bitcoin Core – пошаговое руководство

Децентрализация – ключевая характеристика биткоина. Благодаря децентрализации биткоин не имеет единой точки управления и отказа. Децентрализация также означает необходимость в как можно большем числе полных нод.

ForkLog составил пошаговую инструкцию по установке полной ноды биткоина при помощи наиболее популярного клиента сети Bitcoin Core.

Что такое полная нода и для чего она нужна

Мы освещали этот вопрос в образовательной карточке, но все же напомним: полной нодой считается любой компьютер, подключенный к блокчейну и полностью с ним синхронизированный. Полные ноды хранят все данные блокчейна, начиная с генезис-блока.

Полные ноды бесплатно обслуживают сеть, загружают и валидируют каждый блок с транзакциями, руководствуясь исключительно алгоритмом консенсуса. Они являются полностью независимыми. Полные ноды отвергают противоречащие консенсусу блоки или отдельные транзакции.

«Биткоин – это изощренная децентрализованная сеть доверия, которая может поддерживать мириады финансовых процессов. В то же время каждая нода в сети биткоина следует нескольким простым математическим правилам. Взаимодействие между многими нодами – вот что ведет к изощренному поведению, а не какая-то изначально заложенная сложность или доверие к одной ноде. Подобно муравьиной колонии, биткоин – это устойчивая сеть простых нод, следующих простым правилам, которые вместе могут делать удивительные вещи без какой-либо центральной координации», — пишет известный биткоин-евангелист Андреас Антонопулос в своей книге Mastering Bitcoin.

Развернуть полную ноду может любой пользователь с доступом к компьютеру с достаточными характеристиками и интернет-соединением. По состоянию на 20 мая 2020 года, сеть биткоина поддерживали более 10 тысяч нод, большая часть которых развернута в Северной Америке и Западной Европе.

Возможно, кто-то спросит, зачем устанавливать полную ноду, если можно просто воспользоваться одним из многих доступных кошельков. Ответов несколько:

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

Вы планируете осуществлять большое число транзакций и хотите быть уверенными в том, что ваши транзакции будут верифицированы. Если вы не управляете собственной нодой, вы доверяете верификацию своих транзакций кому-то другому. Полная нода обеспечивает полный контроль над личными финансами.

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

Минимальные технические требования

Перед установкой полной ноды необходимо убедиться, что ваш компьютер удовлетворяет ряду минимальных технических требований. Согласно bitcoin.org, это:

• Десктопный компьютер или ноутбук с последними версиями Windows, Mac OS X или Linux;
• 200 Гб свободного пространства на жестком диске с минимальной скоростью чтения / записи 100 MB/s;
  2 Гб оперативной памяти (RAM);
• Широкополосное интернет-соединение с upload-скоростью как минимум 400 Kb/s. Также важно, чтобы соединение было неограниченным и с высокими upload-лимитами.

В идеале ПО для полной ноды должно работать 24/7, но это может получиться не у всех, поэтому рекомендуемое время его работы составляет как минимум шесть часов в день.

Устанавливаем полную ноду

Реквизитом стал ноутбук Dell Inspiron 15 3584 (Core i3-7020U (2.30 GHz), DDR4 4GB, HDD 1TB) с Windows 10. Устанавливаем Bitcoin Core – наиболее популярный клиент сети, работу над которым ведет широкое сообщество разработчиков. Как будет видно ниже, это достаточно простой процесс, большая часть которого сводится к установке самого кошелька.

Заходим на https://bitcoin.org/en/download, где нас встречает Bitcoin Core 0.19.1 — последняя версия ПО, выпущенная в марте этого года.

По умолчанию здесь представлена прямая ссылка на .exe файл, но также можно выбрать архив .zip или скачать версии для других операционных систем.

Скачав установочный файл, приступаем непосредственно к установке. Мы в шаге от возможно самого главного решения в нашей жизни!

Следующим шагом необходимо выбрать диск, на который программа будет установлена. По умолчанию установщик предложит выбрать диск C. Для этого необходимо 52Мб свободного пространства, которые у нас имеются:

Начинаем процесс распаковки:

Спустя короткое время распаковка завершена, и Bitcoin Core готов к работе. Почти.

Далее идет очень важный этап — необходимо указать диск, на котором будут храниться данные блокчейна. И как видно на скрине ниже, к сегодняшнему дню его полный размер вырос до 284 Гб.

По умолчанию установщик предложит выбрать диск C, но возможны ситуации, когда на нем не будет необходимого свободного пространства. Это именно тот случай, который подстерегал и нас. Пришлось выбрать другой диск.

Как видим, разработчики заранее предупреждают, что процесс первоначальной синхронизации не будет простым. Также необходимо быть готовым к тому, что он займет изрядное время.

Кроме того, на пути может встать файерволл, но это решается достаточно быстро и просто.

После всех этих действий мы оказались в самом клиенте, который тут же начинает процесс синхронизации блокчейна с самого начала существования сети биткоина. То есть, загружаются данные всех блоков, в том числе и генезис-блока, созданного Сатоши Накамото. Чувство того, что ты приобщаешься к истории, трудно передать словами!

Как уже говорилось ранее, синхронизация данных блокчейна займет время, и пока она продолжается, можно заняться бэкапом приватных ключей. Методы их хранения и обеспечения безопасности в данном материале рассматриваться не будут.

Синхронизация данных до второй половины 2015 года была выполнена весьма быстро — на это потребовалось около трех часов. Однако далее процесс существенно замедлился, что объясняется возросшим средним размером блока.

Как бы то ни было, спустя почти пять дней беспрерывной работы ноутбука и нервного ожидания, процесс синхронизации был завершен!

Но для запуска полной ноды этого пока еще недостаточно — на данном этапе клиент выступает в роли исключительно кошелька, при этом не самого удобного с точки зрения скорости.

Наша задача — запустить полную ноду. Для этого необходимо осуществить еще несколько действий. В первую очередь — настроить входящие соединения через порт 8333.

Для этого через вкладку Настройки > Опции заходим в сетевые настройки, отмечаем “разрешить входящие подключения” и вручную прописываем параметры порта.

В теории этого должно быть достаточно, однако для того, чтобы изменения вступили в силу, еще необходима перезагрузка программы. К слову, выключение Bitcoin Core всегда следует производить через Файл > Закрытие программы.

Перезагрузив клиент, выжидаем около 15-20 минут, после чего заходим на https://bitnodes.io/, где находим поле проверки доступности ноды.

Если это сделать непосредственно после запуска программы, вас, скорее всего, встретит сообщение, что нода не отвечает:

Наша конечная цель в том, чтобы получить следующий результат:

Иногда просто разрешить входящие соединения через порт 8333 оказывается недостаточно: не все маршрутизаторы поддерживают такую автоматическую конфигурацию, и в этом случае настройку необходимо осуществлять вручную.

Дополнительную информацию по возможным проблемам с конфигурацией можно найти в специальном разделе на Bitcoin.org, либо обратиться за помощью к специалистам.

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

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

Подписывайтесь на новости ForkLog в Telegram: ForkLog FEED — вся лента новостей, ForkLog — самые важные новости и опросы.

Источник

Bitcoin in a nutshell — Protocol

Транзакции — это чуть ли не самый «главный» объект в сети Bitcoin, да и в других блокчейнах тоже. Поэтому я решил, что если и писать про них целую главу, то тогда нужно рассказать и показать вообще все, что можно. В частности то, как они строятся и работают на уровне протокола.

Ниже я объясню, каким образом формируется транзакция, покажу как она подписывается и продемонстрирую механизм общения между нодами.

Table of content

Keys and address

Для начала создадим новую пару ключей и адрес. Как это делается я рассказывал в главе Bitcoin in a nutshell — Cryptography, так что здесь все должно быть понятно. Для ускорения процесса возьмем вот этот набор инструментов для Bitcoin, написанный самим Виталиком Бутериным, хотя при желании вы можете воспользоваться уже написанными фрагментами кода.

Я скинул на адрес 1LwPhYQi4BRBuuyWSGVeb6kPrTqpSVmoYz 0.00012 BTC, так что теперь можно экспериментировать по полной программе.

Searching for nodes

Вообще говоря, это хорошая задача на подумать: как найти других участников сети при том, что сеть децентрализована? Подробнее про это можете почитать здесь, скажу заранее, совсем децентрализованного решения пока что не существует.

Я покажу два способа. Первый — это DNS seeding. Суть в том, что есть некоторые доверенные адреса, такие как:

• bitseed.xf2.org
• dnsseed.bluematt.me
• seed.bitcoin.sipa.be
• dnsseed.bitcoin.dashjr.org
• seed.bitcoinstats.com

Они захардкожены в chainparams.cpp и командой nslookup можно получить от них адреса нод.

Другой способ не такой умный и на практике не используется, но в учебных целях он подходит даже лучше. Заходим на Shodan, регистрируемся, авторизуемся и в строке поиска пишем port:8333 . Это стандартный порт для bitcoind , в моем случае нашлось примерно 9.000 нод:

Version handshake

Установка соединения между нодами начинается с обмена двумя сообщениями. Первым отправляется version message, а в качестве ответа на него используется verack message. Вот иллюстрация процесса version handshake из Bitcoin wiki:

When the local peer L connects to a remote peer R, the remote peer will not send any data until it receives a version message.

• L -> R Send version message with the local peer’s version
• R -> L Send version message back
• R Sets version to the minimum of the 2 versions
• R -> L Send verack message
• L Sets version to the minimum of the 2 versions

Это делается в первую очередь для того, чтобы ноды узнали, какой версией протокола пользуется их «собеседник» и могли общаться на одном языке.

Setting up a connection

Каждое сообщение в сети должно представляться в виде magic + command + lenght + checksum + payload , за это отвечает функция makeMessage . Этой функцией мы еще воспользуемся, когда будем отправлять транзакцию.

В коде будет постоянно использоваться библиотека struct. Она отвечает за то, чтобы представлять параметры в правильном формате. Например struct.pack(«q», timestamp) записывает текущее UNIX время в long long int , как этого и требует протокол.

Теперь открываем Wireshark, ставим фильтр bitcoin или tcp.port == 8333 и смотрим на получившиеся пакеты. Если все сделано верно, то, во-первых, будет верно определен протокол, user-agent, block start height и так далее. Во вторых, как и обещалось, вам прилетит ответ в виде сообщений version и verack. Теперь, когда соединение установлено, можно начинать работу.

Making transaction

Перед созданием транзакции еще раз открываем спецификацию и внимательно ее придерживаемся. Отклонение на 1 байт уже делает транзакцию невалидной, так что нужно быть предельно аккуратным.

Для начала зададим адреса, приватный ключ и хэш транзакции, на которую мы будем ссылаться:

Далее создадим транзакцию в raw виде, то есть пока что неподписанную. Для этого достаточно просто следовать спецификации:

Заметьте, что в поле tx_in[«script»] написано отнюдь не

, как вы, наверное, ожидали. Вместо этого указан блокирующий скрипт выхода, на который мы ссылаемся, в нашем случае это OP_DUP OP_HASH160 dab3cccc50d7ff2d1d2926ec85ca186e61aef105 OP_EQUALVERIFY OP_CHECKSIG .

BTW нет никакой разницы между привычным OP_DUP OP_HASH160 dab3cccc50d7ff2d1d2926ec85ca186e61aef105 OP_EQUALVERIFY OP_CHECKSIG и 76a914dab3cccc50d7ff2d1d2926ec85ca186e61aef105s88ac — во втором случае просто используется специальная кодировка для экономии места:

Signing transaction

Теперь самое время подписать транзакцию, здесь все довольно просто:

После того, как получена подпись для raw transaction, можно заменить unlocking script на настоящий и привести транзакцию к окончательному виду:

Sniff & spoof

Здесь нужно пояснить одну деталь. Я думаю вы понимаете, зачем мы вообще подписываем транзакции. Это делается для того, чтобы никто не смог изменить наше сообщение и отправить его дальше по сети, потому что изменится подпись сообщения и так далее.

Но если вы внимательно читали, то запомнили, что мы подписываем ненастоящую транзакцию, которая в конечном итоге будет отправлена другим нодам, а ее модификацию, где в unlocking script указан locking script из выхода, на который мы ссылаемся. В принципе понятно, почему это происходит: в настоящий unlocking script должна быть записана эта самая подпись, и получается замкнутый круг: для правильной подписи нужен правильный unlocking script, для правильного unlocking script нужна правильная подпись. Так что Сатоши пошел на компромисс и разрешил пользоваться не совсем «настоящими» подписями.

Поэтому может случится так, что кто-нибудь в сети поймает наше сообщение, изменит unlocking script и отправит отредактированное сообщение дальше. Никто из нод не сможет этого проверить, потому что подпись не «защищает» unlocking script. Эта уязвимость называется Transaction malleability, подробнее про нее вы можете почитать здесь или посмотреть доклад с Black Hat USA 2014 — Bitcoin Transaction Malleability Theory in Practice.

TL;DR Если вы пользуетесь стандартными скриптами вроде P2PKH, то вам ничего не грозит. В противном случае стоит быть аккуратным.

Sending transaction

Отправка транзакции в сеть производится точно так же, как и в случае с version message:

Запускаем получившийся код и бежим смотреть на пакеты. Если все сделано верно, то в качестве ответа на ваше сообщение придет inv message (в противном случае был бы reject message). Интересный факт — каждая нода, при получении свежей транзакции проверяет ее на валидность (процесс описан в Bitcoin in a nutshell — Mining), поэтому если вы где-то ошиблись, то вас об этом мгновенно оповестят:

Уже через несколько секунд после отправления транзакции в сеть, ее можно будет отследить, правда сначала она будет числиться неподтвержденной. Потом, спустя какое-то время (вплоть до нескольких часов), транзакция будет включена в блок.

Если вы к тому времени не закроете Wireshark плюс в сообщении version укажете текущую высоту блокчейна, то вам прийдет уведомление о новом блоке в виде все того же inv message, но на этот раз с TYPE = MSG_BLOCK (я его закрыл, поэтому ниже скриншот из блога Ken Shirriff):

В Data hash вы можете видеть длинную строку, которая на самом деле является заголовком нового блока в little endian форме. В данном случае это блок #279068 с заголовком 0000000000000001a27b1d6eb8c405410398ece796e742da3b3e35363c2219ee. Куча ведущих нулей — не случайность, а результат майнинга, о котором я расскажу отдельно.

Но перед этим вам нужно разобраться с самим блокчейном, блоками, их заголовками и так далее. Поэтому следующая глава: Bitcoin in a nutshell — Blockchain

Источник