Geekly Articles each Day
📜 ⬆️ ⬇️

Raise our Vertcoin P2Pool * node with merged thru and flops



I woke up in the morning, compared the statistics of accruals of honestly inked coins in the pool office with those of a calculator, and finally convinced that the pool is undercharging?
Tired of not paying commissions?
Or decided to support the decentralization of the network and leave a large pool?
Or maybe he just wanted to “raise” something of his own?

No matter what the reason, the other is important - there is a caustic, blinding desire to change something in my head, and to stop mining “through my uncle”.
And between her and you there is one simple, but at the same time very reasonable question - “How?”.
The answer is the same simple - "Easy!".
')


What is so good about P2Pool and how is it eaten?


First of all, it’s open source, with all the transparency that comes from it. In any case, you can always independently check the points of interest.
Secondly, mining on p2pule is equivalent to mining mining from a financial point of view, of course, for a certain period of time.
Thirdly, it contributes to the decentralization of the network.
And if in the first paragraph there are no questions, then the last two require a basic understanding of what n2pool is.

Speaking very roughly and briefly, this is a set of nodes (nodes) working in a coordinated and at the same time independent. At each node, the admin has the right to set his own parameters, both commissions and block generation, which will be valid only for miners on this node. At the same time, the block found on one node is distributed to all participants of the pool, in proportion to their contribution to the common cause. All this is fixed and accounted for through its own balls of reduced complexity and the blockchain p2pula (sharechain). Such a military-political alliance of independent nodes acting as a united front. About P2Pool, gently and in detail .

Let's return to our points. When the commission is zero (the node is our own, why should we set commissions to ourselves, and then receive them ourselves?) We get the number of coins from the block that was generated by the genereted transaction directly proportional to our contribution. Moreover, in addition to the base value of the coins in the block, the commissions included in the block are also distributed. Everything is like with solo mining, only in smaller quantities, but much more often.

Speaking of the cornerstone of decentralization, about which, by the way, such liners as Bitcoin and Litecoin and “attack 51 percent” have already struck the bottoms, when one pool can alone decide which transactions to process and which not, it can be expressed in a fairly wide range - starting from panicky hysterical, and ending pofigistically neutral. But the fact that this is “not good” is clear to everyone. And let it be without excesses so far and large pools advocate preventing a “51 percent attack”, there is cause for alarm - Uncle Adya also talked a lot and believed him, too, until it was too late. If, however, P2Pool takes 51% of the network hashrate, or even 70% doesn’t make a difference, it doesn’t significantly affect the selectivity of transaction processing - do not forget that P2Pool consists of independent nodes, each of which sets the rules for itself only and criteria for transactions to be processed.

In this example, you will use a server with Debian 7 installed on it, and Vertcoin cryptocurrency ( site , forum , reddit ). Why choose vertcoin? By the fact that this fork not only took the best from its predecessors, Bitcoin and Lightcoin, but also added a lot of its own - Stealth Payments, protection from specialized mining equipment, i.e. ASICs, due to the algorithm changing over time (or, to be precise, the parameter of the hash function changes), and also the helicopter will increase in price many, many, many times, and all current miners will become millionaires . In other matters, enough about the helicopter - the article is not about him, and everything written has a place to be for the vast majority of the rest of the cryptocurrencies, of course with some peculiarities and corresponding adaptation of actions to specifically taken cryptocurrency and the OS.


Laying the foundation: binaries and scripts


And so, we proceed.
The first step is to update the existing software.
apt-get update apt-get dist-upgrade

Further, there are two options: download a ready-made executable file of the wallet, or compile it yourself on the server. If we decide to download a ready-made binary, you can immediately move on to the next item. Below will be considered the second option, as more general and universal.
We upload the necessary packages to the server to build the binary and git (the current list can always be found in the documentation ):
 apt-get install build-essential libssl-dev libdb-dev libdb++-dev libboost-dev libminiupnpc-dev libboost-all-dev apt-get install git

Merge the source from the githaba repository and collect the binary in the maximum "configuration" and security:
 git clone https://github.com/vertcoin/vertcoin cd ~/vertcoin/src make -f makefile.unix USE_UPNP=1 USE_IPV6=1 -e PIE=1

More information about the parameters can be found there on the documentation page.
If the server has a multi-core processor (which is recommended at the extreme), you can also add the -jN parameter, where N is the number of cores. This will allow to collect in the specified number of threads and significantly reduce the compilation time. For example, for a dual-core system, the line will look like this:
 make -j2 -f makefile.unix USE_UPNP=1 USE_IPV6=1 -e PIE=1

If everything went well, then we get a vertcoind binary at the output.

Now let's do the p2pool script, copy and install it:
 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

Now you can create a configuration file for the wallet and enter the necessary data into it
 nano ~/.vertcoin/vertcoin.conf 

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

After that, launch the wallet client in one window and the p2pool script in another
 ~/vertcoin/src/vertcoind --server 

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

And in principle, at the very least, the node will begin to work, you can target your farm on it, and start promoting your creation on all resources. But we will not do this for the time being for one simple reason - “Where are the promised flops?”.

We create for our purposes an individual user.


A thing at least logical in principle, but far from obvious, at least for a person who hasn’t been very concerned with server administration before. Create a home directory for a new user, and transfer previously obtained components to the “correct” places.
 cd /home mkdir vtc mv /root/vertcoin/src/vertcoind /usr/bin/ mv /root/p2pool-n /home/vtc/

To add a new user to the system, I used the adduser command. First, we will create a new group for the user (in the example, its name is vtc ), then we will create a new user (we will not be fancy with imagination, and we will call the user also - vtc ) and add it to this group. The full list of commands can be viewed by running the adduser utility with the --help parameter.
 addgroup --gid 1000 vtc adduser --home /home/vtc --shell /bin/false --no-create-home --uid 1000 --gid 1000 vtc adduser vtc vtc

I will add a few comments on the above, in the following lines:
  1. Create a group with the name vtc and identifier 1000.
  2. We already create a user with the name vtc , identifier 1000, specify the path to its home directory and the fact that we do not need to create it (we created it a step earlier), as well as we indicate which program will respond to the shell access when trying to SSH connection under this by user. As a program, a simple binary is chosen, which in any case returns a logical “lie” - in other words, it will not work to connect via SSH under this account. Made it for security purposes. Among the questions asked in the process of adding a user, only the password is worth answering. The rest can be clicked enter.
  3. Add a user with the name vtc to the group called vtc .

You can check the correctness of the performed manipulations by looking at the contents of the passwd and group system files, which are located in the / etc folder. This is done by the following commands through the standard nano editor (or any other):
 cd /etc nano passwd ... nano group

You can also make cosmetic edits, for example, change the access program via SSH, or delete annoying commas in the user description (which, in theory, should share the first name / surname / company name / etc, if this information was entered).
At the end we indicate the owner of our directory / home / vtc - it is obvious that they will be our new vtc user. The -R flag indicates that this is also the case for all subdirectories and files.
 chown -R vtc:vtc /home/vtc/

Also, installing a client on an FTP server, for example, vsFTPd (easily put in a package via apt-get , is a bit tacky, but pretty good in terms of security - and when it comes to cryptocurrency, security is never excessive), you can connect to the server under the user vtc .

Now you can proceed to setting up a helicopter client. Create a hidden .vertcoin directory and in it a vertcoin.conf configuration file with the following parameters:
 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


Save and close the editor. After that, we change the permissions of the created file to “read-only for the owner” (if you are paranoid, this does not mean that no one wants to steal your coins), and again we update the owner of the / home / vtc directory :
 cd .vertcoin chmod 0400 vertcoin.conf chown -R vtc:vtc /home/vtc/

Now log in with our user and run the wallet. The -s switch indicates which shell to use (remember we specified the false binary as the shell for the user? A simple login under the vtc user will simply end the session)
 su -s /bin/bash vtc vertcoind -daemon

In response, should receive a phrase that the server started. You can get current information with the getinfo command:
 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" : "" }

In principle, most fields do not need a description. The maximum on which you can stop the attention, it blocks . Now the client downloads the entire history of transactions from the network, and accordingly, the blocks, which may take more than one hour - at the time of writing this line there were 121578 blocks in the system. When the client receives the last current block (you can easily look at any block explorer for this currency, or when the constant load on the server's CPU drops), our client will become a full member of the network.
If after a few minutes the number of connections will be zero, this may mean that the client could not find other nodes on his own, at least in a reasonable time. In this case, you can either just wait for his “insight”, or manually add active nodes to the configuration file (the list of working nodes is often published in the first message of the coin topic on the forums, along with the rest of the general information) via the addnode command:
 addnode=ip_address_or_domain_name

Logging out from under vtc user, leaving the client to quietly do his uneasy business.
 exit


Merged mining: introduction


Let's start creating the basis for merged mining . Speaking briefly, this allows you to parallelly mine several currencies, using when trying to create blocks for two or more currencies, the same data - mine and we get one main currency, and to them a bonus and more. Of course, you can independently mine merged currencies as the main ones, but from a financial point of view it is unpromising.
Far and not all currencies are possible to mine in this way - there is a main currency and there is a merged currency that can be mine together with the main one. This ratio is not symmetrical. Of course, a merged currency never leaves the shadow of its elder brother, therefore the expediency of their future is in question.

In this example, the main currency is a helicopter, merged currencies to it are Monocle ( site and forum ) and Parallaxcoin ( forum ).
A few words about them:

Also, an example of joint mining is a pair of bitcoin and namecoin (the latter can be mined along with BTC). Litecoin also has its own merged currency.

For each of the coins, I will not describe the above steps for assembling and setting up again, but simply give the procedure:
  1. Download source from GitHub - monocles / parallax .
  2. We collect binaries.
  3. We transfer them to the “right” place - / usr / bin / in this case.
  4. We create service directories and configuration files for both coins - .monocle & monocle.conf and parallaxcoin & parallaxcoin.conf respectively, all in the same directory / home / vtc . Below is an example of the contents of these files. We set permissions for configuration files and once again update the owner of the contents of the directory / home / vtc / , for the sake of new files and directories.
  5. We go under our user, and run wallets to synchronize with the network.

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

* Commission of 0.01 coins is mandatory and minimally possible for mono glue. Without it, the transaction simply will not be perceived by the rest of the network.
parallaxcoin.conf
 server=1 gen=0 rpcallowip=127.0.0.1 rpcport=7817 rpcuser=parallaxcoin rpcpassword=plxRPCpass mintxfee=0.0005 minrelaytxfee=0.0005

Soon, one more shit fork - Umbrella should start, and to be exact - as many as four: forks of bitcoin and lightcon start today, and vert and dark - on 1 August. If this does happen, then in addition to the current set of coins for the node, you can add the merged mining of “umbrellas”.

Improving the performance of the node


In the peer-to-peer network, which formally is any cryptocurrency, there are no main and any regulators as such. According to this “right” there will be one who shouts about his “rightness” “earlier” and “louder”. Yes, yes, we are talking about precisely those cases when two nodes find the same block at the same time - who earlier and faster managed to inform everyone of this, he won. The loser is left with nothing (and to be completely correct, with orphan ). Such a battle for the time where every millisecond in the account. Therefore, we will teach our site to report its own successes quickly and to the maximum number of other nodes, thereby increasing the weight of our node in the network.

"Speed"


one). One of the criteria that affects the speed of assembly and further transfer of the unit over the network is its size. The standard maximum block size that a node can generate is 250000 bytes. In order to speed up the above processes, we will reduce its size by half. In theory, this of course can lower our profits, due to not including more transactions in the block (and therefore commissions for them), but personally my opinion is that the gain from the increase in speed will be greater. This is done by adding the following line to the client configuration file of all our three coins (the one that is * .conf )
 blockmaxsize=125000

2). Another important parameter affecting speed is the distribution of processes between the cores. This will be discussed below in part about setting up daemons.

"Volume"


one). We will increase the maximum number of possible connections for our client, thereby allowing him to report on the found blocks to a greater number of other nodes. To do this, we supplement the configuration files of our clients with the line:
 maxconnections=500

2). Removing firewall restrictions ( iptables is often used). I’ll say right away that on Debian OS under OpenVZ this feature is missing for one simple reason - there are no limitations in principle, at least according to the statement of my host and some people on the forums . Therefore, this part will be somewhat abstract, without clear instructions on what and how to do.
We need to set the following rules for the firewall:
 #  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

These rules should be set for all ports through which our node will work - both for ports that are used by cryptocurrency clients and the p2pool script. See who is listening to what port through the command
 netstat -tunap

These rules should automatically be loaded and unloaded when the system starts / shuts down. This is done in two ways - incorrect (through manual loading of the rules, for which “another sysadmin who came to your place will be a very long time for you” (c)) and correct (through the iptables-persistent daemon). Normal how-to can be viewed here .
Add: in order to increase these limits, the connlimit module must be included in the kernel. If this module is not included, there are no restrictions, and therefore the problem itself. by poiuty

Configuring Daemons


Let us proceed to the key point of all our research - the correct startup of clients and the p2pool script with merged mining at the start of the system. This will be done in standard ways - through the creation and configuration of daemons. To do this, the system has a special directory where all the “control scripts” - /etc/init.d/ . In this directory is a template - skeleton , in the image and likeness of which we will make our scripts. Go to this directory and copy the template:
 cd /etc/init.d/ cp skeleton vertcoind

Open the file for editing and make changes:
 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

And now, what we actually did:
  1. Provides - we set the name
  2. Short-Description / Description - a description of what this file is doing, in case of a case, we will suddenly “forget” for ourselves or third parties will understand all this
  3. DESC = "Vertcoin daemon" - service description
  4. NAME = vertcoind - set the name of the executable file
  5. DAEMON = / usr / bin / $ NAME - and its full name (do you remember we copied them to this directory before?)
  6. DAEMON_ARGS = "- daemon" - set launch arguments: the wallet should start in the daemon background
  7. DAEMON_LOADER = "/ usr / bin / taskset 0x1" $ DAEMON - as already mentioned, it is strongly recommended to distribute between the cores the processes of the clients themselves and the p2pool script, in order to increase the speed of the node as a whole. In this case, we use the taskset utility to indicate that the client will run exclusively on the first kernel. I have a dual-core server, so it was decided to push all three clients to one core (the first), and the p2pool script to another (the second).
    In the case when you have only a single-core server, then this line can be eliminated by removing the part related to the taskset , leaving only $ DAEMON .
    In the case when you have a server with more than two cores, the task becomes a bit more complicated, and for proper configuration you will still need to learn how the taskset utility works . Attention! The basic idea is not to evenly spread the load between the cores, but to differentiate between the cores the execution of clients and the p2pool script, and, if possible, give more resources to the main currency. So, for example, in the case of any three-core exotic, we should hang a helicopter client on the first core, on the second p2pool script, and on the third - everything else.
  8. CHUID = vtc: vtc - set the user and group, on behalf of which the executable file will start.
  9. start-stop-daemon --start_blah_blah - make the appropriate changes to the command to start the daemon.


We save and close the file, grant it execution rights and copy it as a preset for two other clients and the p2pool script:
 chmod 0755 vertcoind cp vertcoind monocled cp vertcoind parallaxcoind cp vertcoind p2pool_vtc


Correct the contents of the monocled and parallaxcoind files. They are in principle similar to vertcoind , except that they are related to other executable files (points 1-4 above) - we change the vertcoind to monocled and parallaxcoind, respectively. In monocles, also in paragraph 6, we add the value of the minimum commission, which is a feature of this particular coin, so the line takes the following form:
 DAEMON_ARGS="-daemon -paytxfee=0.01"


Separately dwell on the file p2pool_vtc . Below is its final view in places other than 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


Regarding the changes themselves:
  1. Provides - again the name
  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 :rpcpassword@ip_address_or_domain:rpcport . . . , — ( , , ) . , . «» ( ), .
    • d). DAEMON_LOADER="/usr/bin/taskset 0x2 "$DAEMON — p2pool- . — . .
    • e). --give-author 0 — . .
    • d). max-conns & outgoing-conns — , / .

Now that almost everything is ready, we can control our demons manually through convenient commands, without any user login procedure and prescription of arguments. The first command will give us a possible list of actions, the second will launch the p2pool script (of course, provided that our nodes have already been synchronized with the network, downloading the whole block history, and are working):
 /etc/init.d/p2pool_vtc /etc/init.d/p2pool_vtc start

The last command will “revive” our node, and it will start synchronization with the p2pool network. Soon the statistics of our node will become available, in this case mine, on which this manual was written - http://91.234.32.241:9171/static/ . Noda is created “solely for example”, so you should not break it trying to get hundreds of bitcoins .

As a final touch, we update the startup list on the server so that our daemons automatically start when the server is started, and restart the server in order to check the success of our actions:
 update-rc.d vertcoind defaults update-rc.d monocled defaults update-rc.d parallaxcoind defaults update-rc.d p2pool_vtc defaults reboot

After reboot everything started? That's good!

Instead of the conclusion or "finish files"


First of all, let's make the statistics of our node more human-fit. For this we will use a third-party frond-end, for example this or this . For one, it will be possible to remove all the garbage, if you have not done this before:
 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

It is also possible through the htop task manager to make sure that all our four daemons successfully started under the vtc user , and also work on different processor cores (this is recognized using the same taskset utility and pid of running processes).
You can also increase the priority of these processes ( nice ), setting it equal to "-10": select the desired process and press F7. I failed to implement this automatically through the same daemon startup files, so at this point you will need to do it with “handles” after each server reboot. Increasing the priority also has a positive effect on the speed of the node.

Another bottleneck is the lack of verification during operation, has any of our processes been self-terminated, in other words, “has a node dropped?”. For good, there should be some kind of script that would check the availability of various processes according to the crown, and in the case of the absence of these, would reboot the server. But since my farm is behind my back, I learned about the fall (of which, probably, for four months there were just a couple of pieces) I knew immediately after the disappearance of noise in the room. If you want to automate everything to such an extent that you could forget about the node for a couple of months, then you should think about it.

Targeting a farm to a node is very simple: Of course, you can add your own parameters, but optimizing and adjusting the miner is not the topic of this topic.
-o stratum+tcp://your_ip_or_node_domain:9171 -u wallet_name -p any_password -Q 0 -s 1 -E 1

The values ​​of the parameters Q , s and E are recommended for p2pool-a, and contribute to a more “quick” exchange of tasks between the node and the farm:

The last paragraph wants to enlighten the fate of the inked merged currencies. They are mined in the "solo" mode by the client on our node. Accordingly, the blocks of coins are charged on him. How quickly our node will find the blocks and receive rewards for them, depends entirely on its total hashrate. In order to get coins to your wallet (for example, the one that is installed on the working PC / laptop, and from which you can easily manage them using the graphical interface), we need to log in with our vtc user , check for a positive balance on the wallets (found , or not), and then transfer them to the miners of the node, in proportion to their hashrate (for example, mono glue):
 su -s /bin/bash vtc monocled getinfo monocled sendmany blah-blah-blah

The syntax of the sendmany command , as well as a list of all other parameters and commands, can be viewed by running the client / p2pool script with the key - help / -h , respectively.

This material was written by a person who had no previous system administration experience. In case bearded system administrators start to burn their eyes in writing: the best way to prove one’s case is to point out errors in the comments. Constructive criticism is always welcome.

Used, but not mentioned literature:
one). The topic on the reddite , which in its time raised its first node.
2). A wonderful topic on Bitcointalk , about fine-tuning p2pool from the guru of this craft.
3). Guide to creating supernody for lightcoin.

Thanks to everybody, you're free.

Source: https://habr.com/ru/post/229643/

More articles:


All Articles