Dash masternodes are full nodes which are incentivized by receiving a share of the block reward as payment in return for the tasks they perform for the network, of which the most important include participation in InstantSend and PrivateSend/CoinJoin transactions. In order to run a masternode, apart from setting up a server which runs the software, you must dedicate 1000 Dash as collateral, which is “tied up” in your node as long as you want it to be considered a masternode by the network. It is worth mentioning that the private key controlling the funds can (and for security reasons, should) be kept separately from the masternode server itself.
A server with the Dash daemon software installed will operate as a Dash full node, but before the rest of the network accepts it as a legitimate masternode, one more thing must happen: the person controlling the node must prove that they also have control of the private key associated with the 1000 Dash collateral assigned to that node. This is achieved by sending a special transaction (i.e. ProRegTx) to the network, signed by the collateral private key.
Here you can see that certain key actions – like starting the masternode or changing some of its parameters – require access to the private key associated with the collateral. Although it can be stored within Dash Core wallet and thus allow to conveniently perform those activities, but for security reasons this is highly discouraged. A much better solution for most users will be to use a so-called hardware wallet that secures private keys from outside access, while giving the ability to perform certain operations related to those keys in a secure manner, i.e., controlled by the physical buttons of the device.
Having such a device, the operations related to masternode management can be performed in two main ways:
- using the Dash Core app – in this case, you have to take into account the necessity to execute several text commands from the Debug console;
- using additional apps, such as Dash Masternode Tool, where most operations can be performed graphically by simply clicking.
The main purpose of the application is to help you perform the most important operations related to registering and managing a masternode if the collateral is controlled by hardware wallets such as Trezor, Keepkey, Ledger. In addition to these features, the application also allows you to perform some additional operations mainly related to Dash governance and hardware wallet setup&management.
In order to work properly, the application needs to communicate with the Dash network, which is done via so-called Dash RPC nodes. Technically, an RPC node is simply a running Dash Core or dashd program with the RPC API enabled. It does not matter whether it runs locally on the same computer as DMT or on some remote server on the Internet. All that matters is to ensure the network is properly configured, so that the RPC service is accessible from the computer you are running your DMT instance from.
To make it as easy as possible for new users to use the application, it comes with a predefined network configuration for so-called “public” RPC nodes (nodes that are maintained by the DMT app developer). This is the default scenario after the first start of the application and in this case no additional actions are required. If you need to restore the default configuration (e.g. after user changes), take a look at this document: Connection to “public” Dash RPC nodes.
For those who choose to use their own RPC nodes, here are two scenarios to achieve this:
- Direct connection to a local node, for example to Dash Core running on your normal computer.
- Connection to a remote node through an SSH tunnel, if you want to work with a remote Dash daemon (like your masternode) through an SSH tunnel.
The application currently supports the following command-line parameters:
- -data-dir: a path to a directory in which the application will create all the needed files, such as: configuration file, cache and log files; it can be useful for users who want to avoid leaving any of the application files on the computer – which by default are created in the user’s home directory – and instead to keep them on an external drive
- -config: a non-standard path to a configuration file. Example: DashMasternodeTool.exe -config=C:dmt-configsconfig1.ini
This is the main functionality of the Dash Masternode Tool application.
The basis of a masternode is a Dash daemon running on a server 24/7, having its own IP address reachable from the Internet. To ensure the required availability, the most optimal solution is to use a so-called Virtual Private Server (VPS) rented from a reliable service provider. While you can run the masternode daemon on your own server (even Rapberry Pi) and use your home internet connection to make it public, it’s not very reliable in most cases, so in this documentation we will refer to that server simply as a VPS. If in your case, it will actually be a physical server, then all the steps described for installing software on it will still be valid.
After obtaining the appropriate VPS service, it is necessary to install (and properly configure) the software that will make up the Dash node being the basis of the masternode.
In this documentation, we will focus on two scenarios of such installation:
- manual installation of the Dash node
- automatic installation of the Dash node using Ansible
For masternode registration it is necessary to prepare a so-called collateral transaction in advance by sending 1000 Dash to one of the addresses from your own hardware wallet.
Masternode registration is the act of broadcasting to the Dash network that we have a node configured to act as a Dash masternode.
This topic is covered here.
This topic is covered here.
This topic is covered here.
This topic is covered here.
This topic is covered here.
In general, this functionality is a graphical interface to hardware wallets, the main task of which is to send funds to specified addresses. It therefore implements functions similar to those provided by official device manufacturers’ applications, but has a few additional features that can be quite important for masternode owners:
- hiding by default collateral transactions to protect them from accidental spending and thus dostroying the associated masternode;
- the ability to send UTXOs (aka coins) of a new transaction type (DIP-3) which is not supported by all official vendor applications.
This topic is covered here.
Voting on proposals is a very important part of Dash governance, as it provides funding for both the core of the project (the work of the Dash Core Group) and community-led side projects to support the entire ecosystem.
This topic is covered here.
This topic is covered here.
This topic is covered here.
This topic is covered here.
The topic is covered here.
The topic is covered here.
The topic is covered here.
- Trezor (model One and T)
- KeepKey
- Ledger Nano (mode S and X)
In order for USB devices to be properly recognized under Linux, their so-called udev rules have to be added. As hardware wallets are USB devices, this also applies to them. Below is a list of commands that add udev rules for hardware wallets supported by this application, i.e. Trezor, Keepkey and Ledger. If, after installing them, you have a problem with the correct detection of the device, look for the appropriate rules on the manufacturer’s website.
Trezor:
KeepKey:
Ledger Nano:
This application is written in Python 3, but requires several additional libraries to properly function. These libraries in turn require the installation of a C++ compiler. All in all, compiling DMT from source is not trivial for non-technical users.
For this reason, in addition to providing the source code on GitHub, binary versions for all three major operating systems (macOS, Windows 32/64-bit and Linux) are available for download directly. The binaries are compiled and tested under the following OS distributions:
- Windows 10 64-bit
- macOS 10.13
- Ubuntu Linux 18.04
Binary versions of the latest release can be downloaded from: https://github.com/Bertrand256/dash-masternode-tool/releases/latest.
Each binary file being part of a release has a corresponding signature file that you can use to verify the authenticity of the downloaded binary file (to make sure it has not been corrupted or replaced with a counterfeit) and confirm that it has been signed by the application author (Keybase user: bertrand256).
The verification method described below is based on use of the Keybase application, so if you have not already done so, download the installer from https://keybase.io/download and install the app.
Verification steps
-
Open your OS command line terminal
-
Change the current directory to the folder where the DMT release files were downloaded:
cd DOWNLOAD_DIR
After invoking the list directory command (ls for Mac/Linux, dir for Windows ) you should see both the archived executable (.tar.gz, .zip) and the corresponding signature file (.asc):
-
Verify the signature by executing the following command:
You should see something similar to the following if verification was successful:
The goal is to build a binary version yourself using the source code available on GitHub. Although the procedure is not very complicated, some technical knowledge is required, because the operating systems for which this documentation was created are constantly changing, so it is quite possible that you will encounter some problems that you will have to solve on your own.
The procedure differs depending on the operating system and, in the case of Linux, also on its distribution:
- Building the DMT executable file on Ubuntu Linux
- Building the DMT executable file on Fedora Linux
- Building the DMT executable file on macOS
- Building the DMT executable file on Windows
This topic is covered here.
Changelog is available here.
