Masternode

Legacy: This article describes a concept that has been superseded in the course of ongoing development on the Organic Design wiki. Please do not develop this any further or base work on this concept, this is only useful for a historic record of work done. You may find a link to the currently used concept or function in this article, if not you can contact the author to find out what has taken the place of this legacy item.

In addition to a normal blockchain secured by mining nodes, some cryptocurrencies such as Dash also have a network of servers called masternodes which facilitate anonymous and instant transactions. The servers run the masternode daemon and each one needs a certain amount of collateral (e.g. for the Dash network 1000DASH is required for a masternode) to be accepted on the network. Interest is received for running the service. This is particularly attractive because the collateral can remain under full control of the user and doesn't need to be on the same server as the masternode is running on. This means you can use third-party hosted services (such as masternode.me for Dash nodes) too with no risk of losing your collateral.

Most crypto-currencies supporting masternodes are forks of Dash, most have lower entry-level and higher returns, but come with the disadvantage of being less reputable coins that could dump in value unexpectedly. Lists of coin supporting masternodes along with their statistics can be found at masternodes.pro, masternodes.online and MNrank.com.

Build or pre-compiled

Masternodes are usually forks from the Dash crypto-currency, which is in turn a heavily modified fork of the original Bitcoin core. As such they are programmed in C and need to be compiled for execution. Some of the projects provide pre-compiled binaries for different environments, while others require compilation. A masternode can typically run on a very low-spec system, but compilation requires a reasonably high-spec system, so you would usually carry out the compilation locally and then send the resulting binaries to your light-weight server.

Cold vs Hot wallet

There are generally two modes of running a masternode, either with the collateral held offline in a "cold wallet", or with it held in the wallet of the masternode itself (which is just a normal node, but with different configuration settings in its conf file). The former is obviously safer and by far the preferable method for nodes with high-value collateral, but for the smaller nodes the latter method is preferable as its much simpler. When using the cold wallet method, that wallet only needs to be online whenever the masternode needs to be started. The cold wallet has a masternode.conf file which tells it which balances are to be locked and associated with remote masternodes. This file is not used in the case of a masternode holding its own collateral.

Payment logic

The way payment works is that each block that is mined (in the usual way using PoW/PoS) send a portion of the block reward to one of the masternodes and the rest to the miner who solved the block. Each block's masternode portion goes to a different masternode (actually there is a very small chance that one node can get paid in two successive blocks). All the masternodes form into a list and each time one gets paid it goes to the end of the list so all the nodes slowly work their way up the list. But to make the system less predictable, the payment does go to the first node in the list, but rather to a random node in the top 10% of the list which is called the "selection pool".

Types of masternode

Dash

Dash is the original masternode cryptocurrency and is very stable, but has extremely high entry-level of around a million US dollars (as of late 2017). You can use a hosted service such as masternode.me which is very easy to get up and running with, very stable and very low cost.

As of mid 2019 the masternodes use DIP-3 protocol which removes the possibility of an operator voting (by splitting up the keys per role). It also gives the operator the freedom to manage the server without requiring the owner to be involved (for things like IP address changes) without requiring the owner to issue a command to start the MN back up. There is now no need for any configuration on the owner's side at all apart from the signing of a message created by the operator. Also, it makes reward payment more flexible by including a mechanism at the protocol level for MN operators to be paid directly from the reward at a rate pre-negotiated with the owner (so the operator receives their fees automatically in a trustless way instead of having to invoice the owner). DIP-3 means also that you don't need the dash-core wallet, you can use anything that can sign, there's also a stand-alone script for signing anyway, so you can now use any wallet like exodus etc for your collateral. Even a full paper wallet can be used now because you only need to use the key if you change your MN operator and the payouts can now be sent automatically at protocol level to your daily spending wallet. And finally the other relevant change is that the randomness has been removed from the top 10% of the payment queue, which means that all nodes will be paid on an exact schedule.

• Official documentation
  • Masternode newbie guide
  • Payment logic
• Node40 has a good support forum
• Masternode config file
• TAO's setup guide
• Withdrawing profits without affecting collateral
• DashTV
• Dash Core Releases Details of Legal Trust Structure Allowing Masternode Network to Own Property
• FuzeX Signs Memorandum of Understanding With 'DASH' to Launch New FuzeX Cryptocurrency Payments Card

VIVO

One such coin that's worth trying is VIVO which has a reasonably low entry cost of about 1BTC and an excellent return of 300%pa (about US$1600/month at current prices) and has an very easy to follow setup guide (see this for multiple nodes with cold-wallet - don't forget the sentinel setup too or your node may stop working, and note also that sentinel requires that you have an rpc user and password in your vivo.conf. A block explorer for VIVO can be found here and masternode states here. The main community discussion is in Discord here.

After setting my first VIVO masternode up I first found that it about ten hours for the blockchain to sync which looked from the debug log to be due to a lot of bad actors on the network. The nest strange thing was that the address "0" I used to send my collateral to was different to the address "0" returned by the same command after the masternode had successfully started. However rewards did start to arrive successfully after about 14 hours, they arrive in the "immature" category and become available ("generate" category) after 100 blocks which is about four hours).

The rewards are sent to the same account ("0") as the collateral, and you need to use sendfrom "0" to spend them, remember that the fee will be subtracted from the account (and the subtractfeefromamount options is not available for the sendfrom command), so be sure you don't eat into the 1000VIVO collateral because simply sending the missing VIVO back will probably not work. No password is required for the send operation by default.

Note: To check the status of your node according to the network, check here, this may be different than what you get from your local masternode list or status commands. You may need to nuke the chain data and resync.

Feedback: I've been finding the VIVO masternode to be pretty unstable. You need to check on it each day and often give it manual attention. The project development and support doesn't inspire much confidence. I have been getting rewards most of the time (about US$60-$70 per day on average), but overall I think probly best avoided.

Xuez

XuezCoin seems like a pretty cool project that will get used for more than just masternodes, but unfortunately it's been through a lot of problems after one guy got angry and sabotaged the project which was originally called Xios and they had to rebrand to Xuez.

• Official site
• Xuez block explorer
• Github repo
• Discord group

Insane (INSN)

Insane will soon be setting up a masternode system requiring a collateral of 50,000INSN... Currently returns on INSN masternodes are insanely low, like around 1% per annum which doesn't even cover the cost of a $5/mo VPS!

The installation procedure is just a single script which downloads the current source, compiles it and starts the node. One problem with this approach is that you need a reasonably powerful server to run through the compilation process, but you can compile it locally first and then copy the resulting INSaNed binary across to a minimum spec VPS.

• INSaNed-1.0.5.3-Membrane-08 - pre-compiled binary for Ubuntu 16.04
• Official site
• Block explorer

Compiling from source

git clone https://github.com/CryptoCoderz/INSN
make -f makefile.unix
strip INSaNed

Note: Add the USE_UPNP=- option to the make command if you get miniupnp version errors

GoByte (GBX)

I setup a GoByte masternode as they have good returns right now and we got a good deal on the collateral which is 1000GBX. It's a pretty standard setup and they have a pre-compiled releases made for Ubuntu 16.04 in their Github repo (and more up to date version here). GBX has pretty wide exchange support, I use Cryptopia.

• Official site
• Setup procedure
• Sentinel setup - GoByte masternodes have a sentinel
• GBX block explorer
• Hosted nodes and node shares
• A local script for distributing shares

Unsticking a node

Sometimes a node might stop paying out and needs to be reindexed and may also need its chain data rebuilt. To do this, stop the daemon, delete the blocks and chainstate folders, and the mnpayments.dat and mncache.dat files, and then start the daemon again with the -daemon and -reindex options.

Reinitialising a node

Sometimes a node falls into a "non-capable" state due to some of the capital having been spent - perhaps due to a send being done when the node is not active and the capital therefore not locked. When this happens you will need to reinitialise the node again with the capital in a new address. You can first check that this is the problem using the listaddressgroupings command to check that there is no address with exactly 1000 GBX in it. If there is a problem, first send 1000 to a new address, and then generate a new key and send the collateral amount to the account zero again. The reason for the two sends is so that the full 1000 is sent in one single output to the new masternode address, not from two different outputs.

gbx-cli masternode genkey
gbx-cli getaccountaddress 0
gbx-cli sendtoaddress <ACCOUNT_ADDRESS_0> 1000
gbx-cli stop

Then edit the conf file and update private key to the new value obtained with genkey above, and then restart the node normally. The collateral needs 15 confirmations, after which time the masternode should start automatically.

Issues

• typo in the update line should be & not &&
• it says that in local wallet console you do genkey and outputs and these are used in the masternode.conf entry, but the genkey part should come from the actual masternode on the vps
• libzmq3-dev package missing from the apt installs
• conf specifies rpcallowip=127.0.0.1 but this should be rpcconnect
• conf needs rpcport=12454 to allow sentinel to connect
• sentinel doesn't work - maybe too modern a dash version

Stratis (STRAT)

Stratis is a stable coin backed by a good project and they will be introducing masternodes to the network soon. Three different levels of masternodes will be available with successively higher collateral requirement and return.

Info coming soon!

EtherZero (ETZ)

ETZ are forking ETH at block #4936270 (January 19, 2018) and will be introducing a masternode mechanism during the year at some point which will require 10,00020,000 ETZ collateral.

Ionomy (ION)

This masternode is a bit steep for the returns, at about 7.5BTC yielding around $2500 per month as of March 2018. The project does seem to be quite active in the gaming area so may have some long term staying power.

• Official site
• How to set up an IONd based masternode
• Installing IONd on Ubuntu