Принимаем оплату в bitcoin: Часть Третья, свой testnet. С блэкджеком
В прошлой статье я рассказал как установить bitcoind ( ну как минимум на Ubuntu Linux) и как подключится к testnet. Но 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 со следующим содержанием:
Теперь несколько слов о портах. Параметр 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.
Примерно так:
И, конечно, параметры datadir и 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:
И разрешаем его выполнение:
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. Ну ничего, мы ведь уже умеем майнить.
На этом подготовку можно считать законченой, и хотелось бы, наконец, получить какой-то более практически ценный результат.
В следующих статьях я расскажу, как мы можем использовать полученную тестовую систему для разработки, и мы, наконец, перейдем к собственно реализации платежного шлюза.
