Принимаем оплату в bitcoin: Часть Третья, свой testnet. С блэкджеком

В прошлой статье я рассказал как установить bitcoind ( ну как минимум на Ubuntu Linux) и как подключится к testnet. Но testnet - хорошее решение, когда вы проводите тесты готового сайта, уже развернутого на сервере в интернете. А вот для локальной разработки это далеко не самое удобное решение.

Первые части вы можете прочитать здесь и здесь.

И вот тут нам пригодится третий режим работы bitcoind - regtest (Regression Test Mode). По сути - это свой маленький, карманный bitcoin. За небольшими исключениями, поведение программной части будет полностью соответствовать боевому. Но, во первых, вам нет необходимости скачивать blockchain (даже тестовый, значительно более компактный). Далее, по большому счету вам даже не понадобится соединение с интернет, все операции будут происходить полностью локально.  

Нам понадобится установленный bitcoind, что логично, и немного терпения. Нужно запустить минимум 2 копии bitcoind таким образом, чтобы они взаимодействовали между собой, имитируя работу сети. И наконец - нам нужно будет заняться майнингом. Но не пугайтесь, в случае Regression Test сложность автоматически выставляется нулевой и нам не понадобятся мегаватты энергии и ферма из ASIC последнего поколения. 

Для начала - создадим 2 каталога, в которых и будут хранится данные, файлы конфигурации и отладочные логи. Во всех примерах я буду использовать /home/developer как корневой путь. Итак, выполняем команды ниже:

mkdir -p /home/developer/bitcoin-service
mkdir -p /home/developer/bitcoin-client

Названия bitcoin-service и bitcoin-client взяты просто для удобства. Вы можете назвать их даже MYCOOLBITCOINNET - главное обязательно используйте именно их при всех дальнейших действиях.

Мы же пока предположим, что bitcoin-client - это некий "клиент", который будет нам что-то оплачивать при тестах, а bitcoin-service - соответственно наш "магазин", то есть он будет принимать оплату.

Теперь в каждой из созданных директорий нам нужно создать файлы bitcoin.conf со следующим содержанием:

# Как и в случае s testnet, нам нужно разрешить взаимодействие с демоном.
# Параметр ниже разрешает bitcoind прослушивание порта JSON-RPC
server=1
rpcuser=username
rpcpassword=userpassword
# указываем RPC порт. Для каждого из сервисов он должен быть разным!
# По умолчанию это порт 8332, но настоятельно рекомендую использовать другие значения
rpcport=18332
# Указываем режим работы - Regression Test Mode
regtest=1
# Следующие параметры я опишу позже, важно только чтобы они тоже были различными
port=18333
addnode=localhost:28333
# А в этих местах нам нужно указать соответственно bitcoin-service и bitcoin-client.
datadir=/home/developer/bitcoin-service
pid=/home/developer/bitcoin-service/.pid

Теперь несколько слов о портах. Параметр rpcport указывает, какой порт будет прослушиваться в ожидании RPC-соединений. Кроме того, что логика подсказывает - у разных демонов должны быть разные порты, запустить два на одном и том же порту просто не получится технически. По этому для удобства проще всего указать например 18332 для первого и 28332 для второго.  

Теперь несколько слов о параметрах port и addnode. Первый из них - port - указывает, какой порт демон будет прослушивать в ожидании сетевых подключений от других демонов - мы же помним, bitcoin является p2p сетью. Он тоже должен отличатся у разных запущенных демонов. А параметр addnode, в свою очередь говорит, какие подключения будут установлены сразу после старта демона. В боевой сети и сети testnet это реализовано специальным механизмом поиска нод. А поскольку мы запускаем демоны в полностью локальном режиме, этот механизм нам ничем не поможет. 

Поэтому нам прийдется указывать подключения в файле конфигурации. Поэтому, если для bitcoin-service мы указали port 18333 а для bitcoin-client 28333, то параметр addnode соответственно будет выглядеть для bitcoin-service localhost:28333, и localhost:18333 для bitcoin-client.

Примерно так:

#/home/developer/bitcoin-service/bitcoin.conf:
port=18333
addnode=localhost:28333
#/home/developer/bitcoin-client/bitcoin.conf:
port=28333
addnode=localhost:18333

И, конечно, параметры datadir и pid должны указывать на соответствующие директории:

#/home/developer/bitcoin-service/bitcoin.conf:
datadir=/home/developer/bitcoin-service
pid=/home/developer/bitcoin-service/.pid

#/home/developer/bitcoin-client/bitcoin.conf:
datadir=/home/developer/bitcoin-client
pid=/home/developer/bitcoin-client/.pid

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

Теперь мы можем, наконец, запустить нашу тестовую сеть и наслаждаться своим персональным bitcoin. Для этого нам нужно выполнить команды, важно запустить их в разных окнах терминала:

bitcoind -conf=/home/developer/bitcoin-service/bitcoin.conf --printtoconsole
bitcoind -conf=/home/developer/bitcoin-client/bitcoin.conf --printtoconsole

Параметр -conf=... указывает, какой файл конфигурации мы хотим использовать, а --printtoconsole говорит о том, что всю отладочную информацию мы будем наблюдать на экране, без необходимости следить за логами. Обычно в этом нет необходимости, но при первом старте лучше убедиться, что все сделано правильно. Если среди непонятных буковок и циферок не наблюдается страшное слово Error - значит можно считать, что все прошло успешно, и у нас заработала локальная bitcoin-сеть и можно переходить к дальнейшим шагам.

Если в случае боевой сети и testnet обращение к демону происходит достаточно просто: bitcoin-cli [command], то под капотом происходит примерно следующее: bitcoin-cli проверяет путь по умолчанию, по которому находится обычно файл конфигурации. Для Linux это будет $HOME/.bitcoin/bitcoin.conf, и получает из него параметры подключения - те самые rpcport, rpcuser и rpcpassword. И уже используя их, подключается к bitcoind для выполнения команды. Однако у нас теперь мало того, что файлы конфигурации расположены в местах, отличных от стандартных, так еще и одновременно запущено 2 копии bitcoind. Логичный вопрос, который возникает - как нам подключится к тому, который нас интересует и выполнить команду именно на нем? 

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

bitcoin-cli -rpcuser=username -rpcpassword=userpassword -rpcport=18332 getwalletinfo

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

Второй вариант, более читаемый:

bitcoin-cli  -conf=/home/developer/bitcoin-service/bitcoin.conf getwalletinfo 

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

Ну и третий вариант - написать пару bash-скриптов, которые будут подставлять все необходимые нам параметры, и уже с их помощью обращаться к демонам. Создаем файл например bitcoin-service.sh:

#!/usr/bin/env bash
echo "Bitcoin SERVICE node:"
bitcoin-cli  -conf=/home/developer/bitcoin-service/bitcoin.conf $@

И разрешаем его выполнение:

chmod +x bitcoin-service.sh

Такой же файл стоит сделать и для второго демона, логично назвав его bitcoin-client.sh. Теперь любую команду мы можем выполнить просто набрав: 

./bitcoin-service.sh getwalletinfo

Обидно, но баланс нашего кошелька 0.0 BTC, это видно по строке "balance": 0.00000000. Пора исправить это:

./bitcoin-service.sh generate 1000

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

Теперь мы можем остановить наши тестовые bitcoin-демоны и запустить их в более удобном режиме:

bitcoind -conf=/home/developer/bitcoin-service/bitcoin.conf --daemon

bitcoind -conf=/home/developer/bitcoin-client/bitcoin.conf --daemon

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

Теперь мы можем передать монеты с одного демона на другой. Получим bitcoin-адрес: 

./bitcoin-client.sh getnewaddress
Bitcoin CLIENT node:
2Mw8q4gVeyb7kTGmGNmyVqRp4yaNCF6Niw6

#И теперь перешлем несколько тестовых монет:
./bitcoin-service.sh sendtoaddress 2Mw8q4gVeyb7kTGmGNmyVqRp4yaNCF6Niw6 500
Bitcoin SERVICE node:
eec8a8efdd40d21564de027b8c9fa97b2abfb35befa5cd543f8be1f16016ef8f

Мы получили номер транзакции, значит все прошло хорошо. Проверим что у нас получилось:

./bitcoin-client.sh getwalletinfo

А тут нас ожидает не слишком приятный сюрприз, баланс по прежнему равен 0. А происходит так потому, что наша новая транзакция не включена в блок, и соответственно не подтверждена. Зато в строке "unconfirmed_balance" мы наблюдаем 500.00000000. Ну ничего, мы ведь уже умеем майнить.

# Одного блока сейчас будет вполне достаточно
./bitcoin-client.sh generate 1 

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

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