Проснулся утром, сравнил статистику начислений честно намайненных монет в кабинете пула с показателями калькулятора, и окончательно убедился в том что пул недоначисляет?
Надоело платить комиссии «не за что»?
Или решил поддержать децентрализацию сети и уйти с крупного пула?
А может просто захотелось «поднять» что-то своё?

Не важно какова причина, важно другое — в голове засело едкое, ослепляющее желание что-то поменять, и прекращать майнить «через дядю».
И между ней и тобой появляется один простой, но в то же время очень резонный вопрос — «Как?».
Ответ на него такой же простой — «Легко!».

Чем же так хорош P2Pool и как его едят?

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

Если говорить очень грубо и кратко, то это множество узлов(нод), работающих скоординированно и в то же время независимо. На каждой ноде админ вправе установить свои параметры, как комиссий, так и генерации блоков, которые будут иметь силу только для майнеров на данной ноде. В то же время найденный на одной ноде блок распределяется всем участникам п2пула, пропорционально ихнему вкладу в общее дело. Всё это закреплено и учитывается через собственные шары пониженной сложности и блокчейн п2пула (sharechain). Такой себе военно-политический альянс независимых нод, выступающих единым фронтом. О P2Pool, нежно и подробно ^[1].

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

Говоря об краеугольном камне децентрализации, об который между прочим уже чиркнули днищами такие лайнеры как Bitcoin ^[2] и Litecoin ^[3] и «атаке 51 процента», когда один пул может единолично решить, какие транзакции ему обрабатывать, а какие нет, можно высказываться в довольно широком спектре — начиная от панически истерического, и заканчивая пофигистически нейтральным. Но то что это «не есть хорошо», ясно всем. И пусть пока обошлось без эксцессов и крупные пулы выступают о недопущении «атаки 51 процента», повод для тревоги есть — дядя Адя тоже много говорил и ему тоже верили, правда до тех пор пока не стало уже слишком поздно. В случае же если же P2Pool займёт 51% хешрейта сети, или даже 70% — без разницы, существенно влиять на выборочность обработки транзакций у него не выйдет — не забываем что P2Pool состоит из независимых нод, каждая из которых сама и только для себя устанавливает правила и критерии принимаемых на обработку транзакций.

В данном примере будет использовать сервер с установленным на него Debian 7, и криптовалюта Vertcoin(сайт ^[4], форум ^[5], реддит ^[6]). Почему именно vertcoin? По тому что данный форк не только взял самое лучшее от своих предшественников, биткоина и лайткоина, но и добавил много своего — стелс транзакции (Stealth Payments), защищённость от специализированного оборудования для майнинга, т.е. ASIC-ов, за счёт меняющегося со временем алгоритма (а если быть точным, то изменяется параметр хеш функции), а еще верткоин вырастет в цене во много-много-много раз, и все нынешние майнеры станут миллионерами. В прочем хватит о верткоине — статья не о нём, и всё написанное имеет место быть для подавляющего большинства остальных криптовалют, разумеется при некоторых особенностях и соответствующей адаптации действий под конкретно взятую криптовалюту и ОС.

Закладываем основу: бинарники и скрипты

И так, приступаем.
Первым делом следует обновить имеющийся софт

apt-get update
apt-get dist-upgrade

Далее возможны два варианта — скачать ^[7] готовый исполняемый файл кошелька, либо самостоятельно скомпилировать его на сервере. Если решаем скачать уже готовый бинарник, то можно сразу переходить к следующему пункту. Ниже будет рассмотрен второй вариант, как более общий и универсальный.
Загружаем на сервер необходимые пакеты, для сборки бинарника и git (актуальный список всегда можно посмотреть в документации ^[8]):

apt-get install build-essential libssl-dev libdb-dev libdb++-dev libboost-dev libminiupnpc-dev libboost-all-dev
apt-get install git

Сливаем исходники с репозитория гитхаба и собираем бинарник в максимальной «комплектации» и защищённостью:

git clone https://github.com/vertcoin/vertcoin
cd ~/vertcoin/src
make -f makefile.unix USE_UPNP=1 USE_IPV6=1 -e PIE=1

Подробнее об параметрах можно посмотреть там же на странице документации.
Если на сервере стоит многоядерный процессор(что крайней рекомендуется), можно также добавить параметр -jN, где N — количество ядер. Это позволит собирать в указанное количество потоков и значительно сократить время компиляции. Например, для двухъядерной системы строка будет выглядеть следующим образом:

make -j2 -f makefile.unix USE_UPNP=1 USE_IPV6=1 -e PIE=1

Если всё прошло успешно, то на выходе получаем бинарник vertcoind.

Теперь займёмся скриптом p2pool-а, скопируем и установим его:

cd ~
apt-get install python-zope.interface python-twisted python-twisted-web
git clone https://github.com/donSchoe/p2pool-n
cd ~/p2pool-n/py_modules/vertcoin_scrypt
python setup.py install

Теперь можно создать файл конфигурации для кошелька и внести в него необходимые данные

nano ~/.vertcoin/vertcoin.conf

server=1
gen=0
rpcport=5899
rpcallowip=127.0.0.1
rpcuser=user
rpcpassword=password

После чего запустить в одном окне клиент кошелька, а в другом скрипт p2pool-а

~/vertcoin/src/vertcoind --server

python ~/p2pool-n/run_p2pool.py --net vertcoin

И в принципе худо-бедно нода начнёт работать, можно нацеливать на неё свою ферму, и начинать пиарить на всех ресурсах своё творение. Но мы этого пока-что делать не будем по одной простой причине — «А где же обещанные плюхи?».

Создаём для наших целей отдельного пользователя

Вещь хоть в принципе и логичная, но далеко не очевидная, как минимум для человека до этого не сильно сталкивавышемся с администрированием серверов. Создадим домашний каталог нового пользователя, и перенесём на «правильные» места ранее полученные компоненты

cd /home
mkdir vtc
mv /root/vertcoin/src/vertcoind /usr/bin/
mv /root/p2pool-n /home/vtc/

Для добавления нового пользователя в систему я использовал команду adduser. Сначала создадим новую группу для пользователя (в примере её имя — vtc), потом создадим нового пользователя (не будем изощряться с фантазией, и назовём пользователя так же — vtc) и добавим его в данную группу. Полный список команд можно посмотреть, запустив утилиту adduser с параметром --help.

addgroup --gid 1000 vtc
adduser --home /home/vtc --shell /bin/false --no-create-home --uid 1000 --gid 1000 vtc
adduser vtc vtc

Добавлю несколько комментариев, касательно вышенаписанного, по строкам:

1. Создаем группу с названием vtc и идентификатором 1000.
2. Создаём уже пользователя с именем vtc, идентификатором 1000, указываем путь к его домашнему каталогу и то что его создавать не нужно(мы его создали шагом ранее), а так же указываем какая программа будет отвечать до доступ к шеллу, при попытке SSH подключения под данным пользователем. В качестве программы выбран простой бинарник, который в любом случае возвращает логическую «ложь» — другими словами, подключиться через SSH под данным аккаунтом не выйдет. Сделано это в целях безопасности. Среди вопросов, задаваемых в процессе добавления юзера, достоин ответа только пароль. Остальные можно прощелкивать энтером.
3. Добавляем пользователя с именем vtc в группу с названием vtc.

Проверить корректность проделанных манипуляций можно просмотрев содержимое системных файлов passwd и group, которые лежат в папке /etc. Делается это следующими командами через стандартный редактор nano(либо любой другой):

cd /etc
nano passwd
...
nano group

Там же можно внести и косметические правки, например изменить программу доступа по SSH, или удалить назойливые запятые в описании пользователя (которые по идее должны разделять имя/фамилию/название фирмы/etc, в случае если эти данные вводились).
На окончание указываем владельца нашей директории /home/vtc — очевидно что им будет наш новый пользователь vtc. Флаг -R указывает, что данное имеет место быть и для всех вложенных каталогов и файлов.

chown -R vtc:vtc /home/vtc/

Так же, установив на сервер FTP клиент, например vsFTPd ^[9] (легко ставится пакетом через apt-get, немного геморно настраивается, но зато довольно хорош в плане безопасности — а когда речь идёт о криптовалютах, безопасность никогда не бывает чрезмерной), можно коннектится к серверу под данным пользователя vtc.

Теперь можно приступить к настройке клиента верткоина. Создадим скрытый каталог .vertcoin и в нём файл конфигурации vertcoin.conf со следующими параметрами:

cd /home/vtc
mkdir .vertcoin
nano .vertcoin/vertcoin.conf

server=1  
gen=0
rpcport=5899
rpcallowip=127.0.0.1
rpcuser=vertcoin
rpcpassword=vtcRPCpass
mintxfee=0.0005
minrelaytxfee=0.0005

• server — указывает на то, что этот узел будет являться «серверным». Понимаем как-то так на интуитивном уровне.
• gen — отключает автоматический майнинг монет на процессоре, из-за его крайней неэффективности.
• rpcport/allowip/user/password — задаёт значения для коммуникации и приём/отдачу команд кошельком. Менять первый два параметра крайне не рекомендуется. Имя/пароль устанавливаем на своё усмотрение, последний — чем длиннее и нетривиальней, тем лучше. Рекомендуемая длина — от 20 знаков.
• Последние два параметра имеют отношение к комиссиям — минимальное значение комиссий от транзакции, необходимое для включение её в сгенерированный нодой блок и минимальное значение, при котором нода передаст информацию о комиссии дальше по сети. Хотим больше зарабатывать — увеличиваем значение. Хотим поддержать сеть — ставим ноль.

Сохраняем и закрываем редактор. После чего изменяем права доступа к созданному файлу на «только чтение для владельца» (если ты параноик, то это еще не значит, что твои монеты никто не хочет украсть), и опять же обновляем владельца каталога /home/vtc:

cd .vertcoin
chmod 0400 vertcoin.conf
chown -R vtc:vtc /home/vtc/

Теперь залогинимся под нашим пользователем и запустим кошелёк. Ключ -s указывает, какой именно шелл использовать (помните мы указали бинарник false в качестве шелла для пользователя? простой логин под юзером vtc просто завершит сеанс)

su -s /bin/bash vtc
vertcoind -daemon

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

vertcoind getinfo
...
{
    "version" : 80701,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 4941,
    "timeoffset" : 0,
    "connections" : 8,
    "proxy" : "",
    "difficulty" : 0.00238789,
    "testnet" : false,
    "keypoololdest" : 1405374049,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}

В принципе большинство полей в описании не нуждаются. Максимум на чём можно остановить внимание, это blocks. Сейчас клиент скачивает с сети всю историю транзакций, а соответственно и блоков, что может занять не один час — на момент написания данной строки в системе было 121578 блоков. Когда клиент получит последний текущий блок (можно легко посмотреть по любому block explorer-у для данной валюты, либо когда спадёт постоянная нагрузка на CPU сервера), наш клиент станет полноценным участником сети.
Если спустя несколько минут количество соединений (connections) так и будет нуль, это может означать что клиент не смог самостоятельно найти другие узлы сети, по крайней мере за приемлемое время. В этом случае можно либо просто ждать его «прозрения», либо добавить вручную действующие узлы в файл конфигурации (список работающих узлов зачастую публикуется в первом сообщении темы об монете на форумах, вместе с остальной общей информацией) через команду addnode:

addnode=ip_address_or_domain_name

Разлогиниваемся из под юзера vtc, оставляя клиент спокойно делать своё непростое дело.

exit

Merged mining: вступление

Приступим к созданию основы для merged майнинга ^[10]. Если говорить кратко, то это позволяет параллельно майнить несколько валют, используя при попытке создать блоки для двух и более валют, одни и те же данные — майним и получаем одну основную валюту, а к ним бонусом еще и другие. Конечно можно самостоятельно майнить merged валюты как основные, но с финансовой точки зрения это бесперспективно.
Далеко и далеко не все валюты возможно майнить таким образом — есть основная валюта и есть merged валюта, которую можно майнить совместно с основной. Данное отношение не является симметричным. Разумеется, merged валюта никогда не выходит из тени своего старшего брата, по этому целесообразность их будущего под вопросом.

В данном примере основная валюта — верткоин, merged валюты к нему — Monocle(сайт ^[11] и форум ^[12]) и Parallaxcoin(форум ^[13]).
Несколько слов об них:

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

Так же, примером совместного майнинга является пара bitcoin и namecoin (последний можно майнить параллельно с BTC). Для litecoin тоже есть свои merged валюты.

Описывать еще раз для каждой из монет вышеописанные шаги по сборке и настройки не буду, а просто приведу порядок действий:

1. Скачиваем исходники с GitHub-а — монокли ^[14]/параллаксы ^[15].
2. Собираем бинарники.
3. Переносим их в «правильное» место — /usr/bin/ в данном случае.
4. Создаём служебные каталоги и файлы конфигурации для обоих монет — .monocle & monocle.conf и parallaxcoin & parallaxcoin.conf соответственно, всё в том же каталоге /home/vtc. Ниже будет приведён пример содержимого данных файлов. Выставляем права доступа конфигурационных файлов и еще раз обновляем владельца содержимого каталога /home/vtc/, ради новых файлов и каталогов.
5. Заходим под нашим пользователем, и запускаем кошельки на синхронизацию с сетью.

monocle.conf

server=1
gen=0
rpcport=6888
rpcallowip=127.0.0.1
rpcuser=monocle
rpcpassword=monRPCpass
mintxfee=0.01
minrelaytxfee=0.01

* комиссия в 0.01 монеты является для моноклей обязательной и минимально возможным. Без неё транзакция просто не будет восприниматься всей остальной сетью.
parallaxcoin.conf

server=1
gen=0
rpcallowip=127.0.0.1
rpcport=7817
rpcuser=parallaxcoin
rpcpassword=plxRPCpass
mintxfee=0.0005
minrelaytxfee=0.0005

В скором времени должен стартовать еще один говнофорк — Umbrella ^[16], а если быть точным — то целых четыре: форки биткоина и лайткона стартуют уже сегодня, а верта и дарка — 1 августа. Если это всё-таки произойдёт, то в дополнение к текущему набору монет на ноду можно будет добавить еще и merged майнинг «зонтиков».

Улучшаем «производительность» ноды

В одноранговой сети, коей формально и является любая криптовалюта, главных и каких либо регуляторов нету как таковых. По этому «прав» будет тот, кто кричит о своей «правоте» «раньше» и «громче». Да да, речь идёт как раз о тех случаях, когда два узла находят один и тот же блок одновременно — кто раньше и быстрее успел всех оповестить об этом, тот и в выигрыше. Проигравший же остаётся с ничем (а если быть полностью корректным — то с орфаном (orphan ^[17])). Такая себе битва за время, где каждая миллисекунда на счету. По этому будем учить наш узел сообщать об собственных успехах быстро и на максимальное количество других узлов, тем самым повышая вес нашей ноды в сети.

«Скорость»

1). Одним из критериев, который влияет на скорость сборки и дальнейшей передачи блока по сети, является его размер. Стандартный максимальный размер блока, который может сгенерировать узел, равен 250000 байтам. Что-бы ускорить вышеназванные процессы мы уменьшим его размер в два раза. В теории это конечно может понизить нашу прибыль, за счёт не включения в блок большего количества транзакций (а следовательно и комиссий за них), но лично моё мнение что выигрыш от увеличения скорости будет больше. Делается это добавлением следующей строки в файл конфигурации клиента всех наших трёх монет (тот что *.conf)

blockmaxsize=125000

2). Так же важным параметром, влияющим на скорость, является распределение процессов между ядрами. Это будет рассмотрено ниже в части про настройку демонов.

«Громкость»

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

maxconnections=500

2). Снятие ограничений файрвола (зачастую им выступает iptables). Скажу сразу — на ОС Debian под OpenVZ данная возможность отсутствует по одной простой причине — ограничений нету в принципе, по крайней мере по заявлению моего хостера и некоторых людей на форумах. По этому данная часть будет несколько абстрактной, без чётких указаний «что и как» делать.
Нам нужно задать следующие правила для файрвола:

# Разрешаем 8 подключений на подсеть класса /24
-A INPUT -p tcp --syn --dport PORT -m connlimit --connlimit-above 8 --connlimit-mask 24 -j REJECT --reject-with tcp-reset
# Разрешаем два подключения с одного IP
-A INPUT -p tcp --syn --dport PORT -m connlimit --connlimit-above 2 -j REJECT --reject-with tcp-reset
# Разрешаем TCP соединение в случае удачного выполнения предыдущих правил
-A INPUT -m state --state NEW -m tcp -p tcp --dport PORT -j ACCEPT

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

netstat -tunap

Эти правила должны автоматически загружаться и выгружать при старте/выключении системы. Делается это двумя способами — неправильным (через ручную загрузку правил, за что «другой сисадмин, пришедший на ваше место, будет очень долго вас материть»(с)) и правильным (через демона iptables-persistent). Нормальный how-to можно посмотреть тут ^[18].

Настройка демонов

Приступим к ключевому моменту всех наших изысканий — правильным автозапуском клиентов и скрипта p2pool-а с merged майнинга при старте системы. Осуществляться это будет стандартными способами — через создание и настройку демонов. Для этого в системе есть специальной каталог, где лежат все «сценарии управления» — /etc/init.d/. В данном каталоге лежит шаблон — skeleton, по образу и подобию которого мы будем делать свои сценарии. Перейдём в данный каталог и скопируем шаблон:

cd /etc/init.d/
cp skeleton vertcoind

Откроем файл для редактирования, и внесём изменения:

nano vertcoind

#! /bin/sh
### BEGIN INIT INFO
# Provides:          vertcoind
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Auto init Vertcoind
# Description:       Auto init Vertcoind via booting system
### END INIT INFO

# Author: vk <technical@storage.co.ua>
#
# Please remove the "Author" lines above and replace them
# with your own name if you copy and modify this script.

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="Vertcoin daemon"
NAME=vertcoind
DAEMON=/usr/bin/$NAME
DAEMON_ARGS="-daemon"
DAEMON_LOADER="/usr/bin/taskset 0x1 "$DAEMON
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
CHUID=vtc:vtc
...
do_start()
{
	# Return
	#   0 if daemon has been started
	#   1 if daemon was already running
	#   2 if daemon could not be started
	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON_LOADER --test > /dev/null 
		|| return 1
	start-stop-daemon --start --quiet --chuid $CHUID --pidfile $PIDFILE --exec $DAEMON_LOADER -- 
		$DAEMON_ARGS 
		|| return 2

А теперь, что же мы собственно сделали:

1. Provides — задаём название
2. Short-Description/Description — описание того что делает данный файл, на случай его вдруг сами «забудем» или разбираться во всём этом будут третьи лица
3. DESC=«Vertcoin daemon» — описание сервиса
4. NAME=vertcoind — задаём название исполняемого файла
5. DAEMON=/usr/bin/$NAME — и его полное имя (помнишь мы ранее скопировали их в этот каталог?)
6. DAEMON_ARGS="-daemon" — задаём аргументы запуска: кошелёк должен стартовать в фоновом режиме демона
7. DAEMON_LOADER="/usr/bin/taskset 0x1 "$DAEMON — как уже говорилось ранее, настоятельно рекомендуется распределять между ядрами процессы самих клиентов и скрипта p2pool-a, для повышения скорости работы ноды в целом. В данном случае мы с помощью утилиты taskset ^[19] указываем что клиент будет выполняться исключительно на первом ядре. В наличии у меня двухъядерный сервер, по этому было решено все три клиента спихнуть на одно ядро(первое), а скрипт p2pool-а на другое(второе).
   В случае когда у вас под рукой только одноядерный сервер, то данную строку можно упразднить, убрав часть относящуюся к taskset-у, оставив только $DAEMON.
   В случае когда у вас сервер с более чем двумя ядрами, задача немного усложняется, и для правильной конфигурации нужно будет таки изучить принцип работы утилиты taskset. Внимание! Основная идея не в том, что-бы равномерно раскидать нагрузку между ядрами, а что-бы разграничить между ядрами выполнение клиентов и скрипта p2pool-a, и при возможности отдать больше ресурсов основной валюте. Так например в случае какой-либо трёхъядерной экзотики нам следует на первое ядро повесить клиент верткоина, на второе скрипт p2pool-а, а на третье — всё остальное.
8. CHUID=vtc:vtc — задаём юзера и группу, от имени которых будет стартовать исполняемый файл.
9. start-stop-daemon --start_blah_blah — вносим соответствующие изменения в саму команду запуска демона.

Сохраняем и закрываем файл, предоставляем ему права на исполнение и копируем его как заготовку для двух других клиентов и скрипта p2pool-а:

chmod 0755 vertcoind
cp vertcoind monocled
cp vertcoind parallaxcoind
cp vertcoind p2pool_vtc

Корректируем содержимое файлов monocled и parallaxcoind. Они в принципе аналогичны vertcoind, за исключением того что имеют отношение к другим исполняемым файлам (пункты 1-4 выше) — меняем vertcoind на monocled и parallaxcoind соответственно. В моноклях так же в пункте 6 добавляем значение минимальной комиссии, что является особенность конкретно этой монеты, так что строка принимает следующий вид:

DAEMON_ARGS="-daemon -paytxfee=0.01"

Отдельно остановимся на файле p2pool_vtc. Ниже приведён его конечный вид в местах, с отличных от vertcoind:

#! /bin/sh
### BEGIN INIT INFO
# Provides:          p2pool_vtc
# Required-Start:    $all
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Auto init Vertcoin P2Pool
# Description:       Auto init Vertcoind P2Pool via booting system
### END INIT INFO

# Author: vk <technical@storage.co.ua>
#
# Please remove the "Author" lines above and replace them
# with your own name if you copy and modify this script.

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="P2Pool VTC daemon"
NAME=python
DAEMON=/usr/bin/$NAME
DAEMON_ARGS="/home/vtc/p2pool-n/run_p2pool.py --net vertcoin -a your_wallet_name --merged http://monocle:monRPCpass@127.0.0.1:6888 --merged http://parallaxcoin:plxRPCpass@127.0.0.1:7817 --give-author 0 --max-conns 100 --outgoing-conns 10"
DAEMON_LOADER="/usr/bin/taskset 0x2 "$DAEMON
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
CHUID=vtc:vtc

Касательно самих изменений:

1. Provides — опять же название
2. Required-Start: $all — так как скрипт p2pool-а для своей корректной и полноценной работы требует уже запущенные три(в данном случае) клиента криптовалют, то указываем что для старта данного демона необходимо подождать до того, пока все остальные демоны пойдут на выполнение (в том числе и три наших).
3. Short-Description/Description/DESC — задаём соответствующие описания
4. NAME=python — так как p2pool не является самостоятельной программой, а всего лишь скриптом, написанный на питоне, то исполняемым файлом нашего демона будет именно питон.
5. DAEMON_ARGS=blah-blah-blah — и уже в качестве аргумента демона мы подсовываем питону полное название нашего скрипта p2pool-а(/home/vtc/p2pool-n/run_p2pool.py) и его собственные параметры запуска. Рассмотрим их подробней:
   • a). --net vertcoin — задаём с какой именно сетью будет работать p2pool. В данном примере используется основная p2pool сеть верткоина. Для общности информации скажу, что есть так-же вторая и третьи сети верткоина, а так-же — как минимум по одной сети у всех уважающих себя криптовалют.
   • b). -a your_wallet_name — задаём кошелёк по умолчанию, на который будут капать монеты. Если или ты, или другой майнер на нашей ноде неправильно укажет, или не укажет вовсе, кошелёк для получения монет. Если данный параметр не указывать, то монеты будут капать на кошелёк нашего узла на сервере, что не есть хорошо. Как сказал один умный человек —
     

     Big fat wallets on a public server are not a good idea
   • c). --merged blah_blah — здесь мы указывает все merged валюты, которые будут майнится узлом. Синтаксис следующий: --merged rpcuser ^[20]:rpcpassword@ip_address_or_domain:rpcport. Все данные берутся из конфигурационных файлов соответствующих клиентов. В данном примере таких валют две. Так же стоит понимать, что именно эта строка указывает — именно от этого клиента(который находится по заданному адресу, слушает заданный порт, и имеет заданных юзера и пароля) будет осуществляться рассылка в сеть информации об найденном блоке. Так что в теории это можно нацелить на совершенно другой клиент, который находится на другом сервере. В нашем примере монеты будут начислять на «наши» клиенты(а точнее их кошельки), которые находятся у нас на сервере.
   • d). DAEMON_LOADER="/usr/bin/taskset 0x2 "$DAEMON — указываем что скрипт p2pool-а будет выполняться исключительно на втором ядре. В случае если система не двухъядерная — см. выше.
   • e). --give-author 0 — задаём размер пожертвований автору скрипта равным нулю. На своё усмотрение.
   • d). max-conns & outgoing-conns — задаём высокое количество возможным соединений, что позволит нашей ноде сообщать и получать информацию об найденных блоках/шарах от большего количества узлов.

Теперь, когда почти всё готово, мы можем управлять нашими демонами вручную через удобные команды, без всякой процедуры логина под пользователем и прописыванием аргументов. Первая команда выдаст нам возможный список действий, вторая же — запустит скрипт p2pool-а(разумеется при условии что наши узлы уже синхронизировались с сетью, загрузив всю историю блоков, и работают):

/etc/init.d/p2pool_vtc
/etc/init.d/p2pool_vtc start

Последняя команда «оживит» нашу ноду, и она начнёт синхронизацию с сетью p2pool-a. Вскоре станет доступна статистика нашей ноды, в данном случае моей, по которой писался данный мануал — http://91.234.32.241:9171/static/ ^[21]. Нода создана «исключительно для примера», так что ломать её, пытаясь заполучить сотни биткоинов не стоит.

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

update-rc.d vertcoind defaults
update-rc.d monocled defaults
update-rc.d parallaxcoind defaults
update-rc.d p2pool_vtc defaults
reboot

После ребута всё запустилось? Вот и хорошо!

Вместо заключения или «допиливаем надфилем»

Первым делом сделаем статистику нашей ноды более человеко-пригодной. Для этого будем использовать сторонний frond-end, например этот ^[22] или этот ^[23]. За одно можно будет и удалить весь мусор, если не сделали этого раньше:

cd
git clone https://github.com/hardcpp/P2PoolExtendedFrontEnd
rm -rf /home/vtc/p2pool-n/web-static/
mv -f P2PoolExtendedFrontEnd /home/vtc/p2pool-n/web-static
chown -R vtc:vtc /home/vtc/
rm -rf monocle
rm -rf parallaxcoin
rm -rf vertcoin

Так же можно через диспетчер задач htop можно удостоверится, что все наши четыре демона успешно стартовали под юзером vtc, а так же работают на разных ядрах процессора (узнаётся это с помощью той же утилиты taskset и pid запущенных процессов).
Там же можно увеличить приоритет данных процессов(nice), задав его равным "-10": выбираем нужный процесс и жмём F7. Реализовать это в автоматическом режиме через те же файлы запуска демонов мне не удалось, по этому этот момент нужно будет делать «ручками» после каждого ребута сервера. Повышение приоритета так же положительно сказывается на быстродействии ноды.

Еще одно узкое место — отсутствие проверки во время работы, не самозавершился ли какой-то из наших процессов, другими словами — «не упала ли нода?». По хорошему здесь должен быть некий скрипт, который бы по крону проверял наличии тех или иных процессов, и в случае отсутствия оных, перезагружал бы сервер. Но так как моя ферма находится у меня за спиной, то о падении (коих наверное за месяца четыре было всего буквально пару штук) я узнавал сразу-же по исчезновению шума в помещении. Если же ты хочешь автоматизировать всё до такой степени, что-бы про ноду можно было б забыть на пару месяцев, то об этом таки стоит задуматься.

Нацеливается ферма на ноду очень просто:
-o stratum+tcp://your_ip_or_node_domain:9171 -u wallet_name -p any_password -Q 0 -s 1 -E 1
Разумеется можно добавлять и конкретно свои параметры, но оптимизация и настройка майнера не является темой данного топика.
Значения параметров Q,s и E являются рекомендуемыми для p2pool-а, и способствуют более «резвому» обмену заданиями между нодой и фермой:

• -Q|--queue — длина очереди запрошенных работ. По умолчанию равно 1. Рекомендуемое значение — 0.
• -s|--scan-time — лимит времени, для сканирования текущего задания. По умолчанию равно 60. Рекомендуемое значение — 1
• -E|--expiry — верхняя граница времени, которая позволительна после получения работы, на рассмотрение её «запоздавшести»(stale). Значение по умолчанию — 120. Рекомендуемое значение — 1.

Последим абзацем хочется просветить судьбу намайненных merged валют. Они майнятся в режиме «соло» клиентом на нашей ноде. Соответственно, блоки монет начисляются на него же. Как быстро наша нода будет находить блоки и получать за них вознаграждение, целиком и полностью зависит её общего хешрейта. Что-бы получить монеты на свой кошелёк(к примеру тот, который установлен на рабочем ПК/ноутбуке, и с которого используя графический интерфейс ими можно легко распоряжаться), нам нужно залогиниться под нашим пользователем vtc, проверить наличие положительно баланса на кошельках(нашелся блок, или нет), и после перевести их майнерам ноды, пропорционально их хешрейту(на примере моноклей):

su -s /bin/bash vtc
monocled getinfo
monocled sendmany blah-blah-blah

Синтаксис команды sendmany, как в прочем и список всех остальных параметров и команд, можно посмотреть запустив клиент/скрипт p2pool-а с ключем --help/-h, соответственно.

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

Использованная, но не упомянутая литература:
1). Топик на реддите ^[24], по которому в своё время поднимал свою первую ноду.
2). Замечательная тема на Bitcointalk ^[25], про тонкую настройку p2pool-а от Гуру этого ремесла.
3). Руководство по созданию суперноды ^[26] для лайткоина.

Всем спасибо, все свободны.

Автор: Vetal_inside

Источник ^[27]