About Masternode Configuration

Setting up a masternode requires a basic understanding of Linux and blockchain technology, as well as an ability to follow instructions closely. It also requires regular maintenance and careful security, particularly if you are not storing your BitGreen on a hardware wallet. There are some decisions to be made along the way, and optional extra steps to take for increased security. There are many reliable masternode management services available, see Discord for a full list.

NOTE: This documentation is for experts only. For a step-by-step guide, see our BitGreen Masternode Setup Guide on Medium.

Masternode Setup Process

Before you begin..

This guide assumes you are setting up a single mainnet masternode for the first time. If you are updating a masternode, see here instead. You will need:

  • 2500 BitGreen
  • A wallet to store your BitGreen, currently must be the BitGreen Core wallet-- Trezor hardware wallet support to be added January 2020
  • A Linux server, preferably a Virtual Private Server (VPS)

BitGreen 1.0.4 and later implement DIP003, (originally implemented in Dash 0.13.0) which introduces several changes to how a typical masternode is set up and operated. While this network upgrade was first implemented in early 2019, a list of available documentation appears below:

This documentation describes the commands as if they were entered in the BitGreen Core GUI by opening the console from Tools > Debug console, but the same result can be achieved on a masternode by entering the same commands and adding the prefix ~/.bitgreen/bitgreen-cli to each command.

NOTE: This documentation is for experts only. For a step-by-step guide, see our BitGreen Masternode Setup Guide on Medium.

Send the collateral

A BitGreen address with a single unspent transaction output (UTXO) of exactly 2500 BITG is required to operate a masternode. Once it has been sent, various keys regarding the transaction must be extracted for later entry in a configuration file and registration transaction as proof to write the configuration to the blockchain so the masternode can be included in the deterministic list. A masternode can be registered from the official BitGreen Core wallet (or a hardware wallet later). Once available, a hardware wallet is highly recommended to enhance security and protect yourself against hacking. This guide will describe the steps for BitGreen Core, hardware wallet steps will be added later.

Sending from BitGreen Core wallet

Open BitGreen Core wallet and wait for it to synchronize with the network.

Click Tools > Debug console to open the console. Type the following command into the console to generate a new BitGreen address for the collateral, or use the receiving address tab to create a new receiving address:

getnewaddress

The console will return a new address similar to the following format:

GZBwJs7TEACxE8m5wcAWzwDKGv2otwJMwg

Take note of the collateral address since we will need it later (perhaps in a Notepad app as you will need a few pieces of data handy to set up your Masternode!). The next step is to secure your wallet (if you have not already done so). First, encrypt the wallet by selecting Settings > Encrypt wallet. You should use a strong, new password that you have never used somewhere else. Take note of your password and store it somewhere safe or you will be permanently locked out of your wallet and lose access to your funds. Next, back up your wallet file by selecting File > Backup Wallet. Save the file to a secure location physically separate to your computer, since this will be the only way you can access your funds if anything happens to your computer.

Now send exactly 2500 BITG in a single transaction to the new address you generated in the previous step for your Masternode collateral. This may be sent from another wallet, or from funds already held in your current wallet. Once the transaction is complete, view the transaction in a blockchain explorer by searching for the address. You will need 6 confirmations before you can start the registration process for the masternode, but you can continue with the next step at this point already: generating your masternode operator key.

NOTE: This documentation is for experts only. For a step-by-step guide, see our BitGreen Masternode Setup Guide on Medium.

Registering from BitGreen Core wallet

Identify the funding transaction

Now that you have sent the collateral transaction, you need to find the txid of the transaction. Click Tools > Debug console and enter the following command:

masternode outputs

This should return a string of characters similar to the following:

{
  "a77afc91c21255ab0afd7889489739bb46fd0ebdb0b8d99b545786245ffe834a" : "1",
}

The first long string is your collateralHash, while the last number is the collateralIndex.

Generate a BLS key pair

A public/private BLS key pair is required to operate a masternode. The BLS private key replaces what was prior called “masternodeprivkey,” generated by your desktop wallet for use in your VPS wallet. The BLS private key is locked to your masternode itself, and allows it to be included in the deterministic masternode list once a provider registration transaction (proTx) with the corresponding public key has been submitted (which is what we’re about to do!).

If you are using a hosting service, they may provide you with their public key, and you can skip this step. If you are hosting your own masternode or have agreed to provide your host with the BLS private key, generate a BLS public/private keypair in BitGreen Core by clicking Tools > Debug console and entering the following command:

bls generate

The console will return something similar to:

{
  "secret": "39c83f203064bea6e12d304318816d45b4130f6feb298961ccc61880b02a2f31",
  "public": "0e345b81ed2386500c54edc3af2901e86df7a47080a0391cd2f71090e9a3b3de563ac67cdeaf3c2334c600b4523b79b8"
}

These keys are NOT stored by the wallet and must be kept secure, similar to the value provided in the past by the masternode genkey command.

Add the private key to your masternode configuration

The public key will be used in following steps. The private key must be entered in the bitgreen.conf file on the masternode. This allows the masternode to watch the blockchain for relevant Pro*Tx transactions, and will cause it to start serving as a masternode when the signed ProRegTx is broadcast by the owner (final step below). Log in to your masternode using ssh or PuTTY and edit the configuration file as follows:

nano ~/.bitgreen/bitgreen.conf

The editor appears with the existing masternode configuration. Add or uncomment these lines in the file, replacing the key with your BLS private key generated above:

masternode=1
masternodeblsprivkey=39c83f203064bea6e12d304318816d45b4130f6feb298961ccc61880b02a2f31

Press enter to make sure there is a blank line at the end of the file, then press Ctrl + X to close the editor and Y and Enter save the file. We now need to restart the masternode for this change to take effect. Enter the following commands, waiting a few seconds in between to give Dash Core time to shut down:

~/.bitgreen/bitgreen-cli stop
sleep 15
~/.bitgreen/bitgreend

We will now prepare the transaction used to register the masternode on the network.

Prepare a ProRegTx transaction

A pair of BLS keys for the operator were already generated above, and the private key was entered on the masternode. The public key is used in this transaction as the operatorPubKey.

First, we need to get a new, unused address from the wallet to serve as the owner key address(ownerKeyAddr). This is not the same as the collateral address holding 2500 BITG. Generate a new address as follows:

getnewaddress

This address can also be used as the voting key address (votingKeyAddr). Alternatively, you can specify an address provided to you by your chosen voting delegate, or simply generate a new voting key address as follows:

getnewaddress

Then either generate or choose an existing address to receive the owner’s masternode payouts (payoutAddress). THIS ADDRESS MUST BE A SegWit-type address WHICH BEGINS with a 3. This address may be reused in subsequent Masternode Registrations. It is also possible to use an address external to the wallet. Generate a SegWit address by taking a new or existing address and inputting:

getnewaddress <address> p2sh-segwit

The console will return a segwit address similar to the following:

3XHC6aW5DcY1mqbjyY7kGP7shdWukAatic

You can also optionally generate and fund another address as the transaction fee source (feeSourceAddress). If you selected an external payout address, you must specify a fee source address. Either the payout address or fee source address must have enough balance to pay the transaction fee, or the final register_submit transaction will fail.

It is suggested to make a standard “FeeAddress” to use for all your Masternode registrations if you plan to set up many at once, or on an ongoing basis. This makes doing multiple ProTx easier for copy and pasting purposes.

The private keys to the owner and fee source addresses must exist in the wallet submitting the transaction to the network. If your wallet is protected by a password, it must now be unlocked to perform the following commands. Unlock your wallet for 5 minutes (300 seconds):

walletpassphrase <yourSecretPassword> 300

We will now prepare an unsigned ProRegTx special transaction using the protx register_prepare command. This command has the following syntax:

protx register_prepare <collateralHash> <collateralIndex> <ipAndPort> <ownerKeyAddr> <operatorPubKey> <votingKeyAddr> <operatorReward> <payoutAddress> <feeSourceAddress>

Open a text editor such as notepad to prepare this command. Replace each argument to the command as follows:

  • collateralHash: The txid of the 2500 BITG collateral funding transaction
  • collateralIndex: The output index of the 2500 BITG funding transaction
  • ipAndPort: Masternode IP address and port, in the format x.x.x.x:yyyy
  • ownerKeyAddr: The new BitGreen address generated above for the owner/voting address (cannot be the same for 2 Masternodes)
  • operatorPubKey: The BLS public key generated above (or provided by your hosting service)
  • votingKeyAddr: The new BitGreen address generated above (or ownerKeyAddr), or the address of a delegate, used for proposal voting 
  • operatorReward: The percentage of the block reward allocated to the operator as payment
  • payoutAddress: A new or existing BitGreen p2sh-Segwit address to receive the owner’s masternode rewards
  • feeSourceAddress: An (optional) address used to fund ProTx fee. payoutAddress will be used if not specified.

Note that the operator is responsible for specifying their own reward address in a separate update_service transaction if you specify a non-zero operatorReward. The owner of the masternode collateral does not specify the operator's payout address.

Example (remove line breaks if copying):

protx register_prepare
  a77afc91c21255ab0afd7889489739bb46fd0ebdb0b8d99b545786245ffe834a
  1
  78.47.106.254:9031
  GMJiGvLZzrxUgVojU9UqdWxgY5t8ijfYkK
  89cb58570a2a311609cae4a57411c52729b93cb9ff5e40a8f28f68653d4d387fe80cd93ab296ede8f5a590dd43908609
  GMJiGvLZzrxUgVojU9UqdWxgY5t8ijfYkK
  0
  3XHC6aW5DcY1mqbjyY7kGP7shdWukAatic
  GTjajT6ZDLwwyn7GxNPg7zBEcyyGqQAE77

Output:

{
  "tx": "02000200014a83fe5f248657549bd9b8b0bd0efd46bb3997488978fd0aab5512c291fc7aa70200000000feffffff015fd00b54020000001976a9146c7e54a40a77e09a1a21a3267452f5b49eaa4dfe88ac00000000cf0100000000004a83fe5f248657549bd9b8b0bd0efd46bb3997488978fd0aab5512c291fc7aa70100000000000000000000000000ffff4e2f6afe234725f9791dbc922bd44e57e3aaf7633f2149137d4e89cb58570a2a311609cae4a57411c52729b93cb9ff5e40a8f28f68653d4d387fe80cd93ab296ede8f5a590dd4390860925f9791dbc922bd44e57e3aaf7633f2149137d4e000017a9144492484d83d79176316454221c152ca71329039787a2de7f77997aefee04568eb363d0e7cf57f8c44d24ffcf98f6381d1e3d53511100",
  "collateralAddress": "GZBwJs7TEACxE8m5wcAWzwDKGv2otwJMwg",
  "signMessage": "3XHC6aW5DcY1mqbjyY7kGP7shdWukAatic|0|GMJiGvLZzrxUgVojU9UqdWxgY5t8ijfYkK|GMJiGvLZzrxUgVojU9UqdWxgY5t8ijfYkK|e4731f9fdfa83703f3d39a31fc0a08e68784f9222c2288c010053d68acf6b9c1"
}

Next we will use the collateralAddress and signMessage fields to sign the transaction, and the output of the tx field to submit the transaction.

Sign the ProRegTx transaction

We will now sign the content of the signMessage field using the private key for the collateral address as specified in collateralAddress. Note that no internet connection is required for this step, meaning that the wallet can remain disconnected from the internet in cold storage to sign the message. In this example we will again use Dash Core, but it is equally possible to use the signing function of a hardware wallet once released. The command takes the following syntax:

signmessage <collateralAddress> <signMessage>

Example:

signmessage GZBwJs7TEACxE8m5wcAWzwDKGv2otwJMwg
3XHC6aW5DcY1mqbjyY7kGP7shdWukAatic|0|GMJiGvLZzrxUgVojU9UqdWxgY5t8ijfYkK|GMJiGvLZzrxUgVojU9UqdWxgY5t8ijfYkK|e4731f9fdfa83703f3d39a31fc0a08e68784f9222c2288c010053d68acf6b9c1

Output:

H7qPzptU3p/5N1+L5uGu6O0ZRxZ7t1rgQtXuvaKFDv5gVc/ISchyvz3BbNJj1vafFieTaCIkFR7yBlT/QrqOOS4=

Submit the signed message

We will now submit the ProRegTx special transaction to the blockchain to register the masternode. This command must be sent from a BitGreen Core wallet holding a balance on either the feeSourceAddress or payoutAddress, since a standard transaction fee is involved. The command takes the following syntax:

protx register_submit <tx> <sig>

Where:

  • tx: The serialized transaction previously returned in the tx output field from the protx register_prepare command
  • sig: The message signed with the collateral key from the signmessage command

Example:

protx register_submit 02000200014a83fe5f248657549bd9b8b0bd0efd46bb3997488978fd0aab5512c291fc7aa70200000000feffffff015fd00b54020000001976a9146c7e54a40a77e09a1a21a3267452f5b49eaa4dfe88ac00000000cf0100000000004a83fe5f248657549bd9b8b0bd0efd46bb3997488978fd0aab5512c291fc7aa70100000000000000000000000000ffff4e2f6afe234725f9791dbc922bd44e57e3aaf7633f2149137d4e89cb58570a2a311609cae4a57411c52729b93cb9ff5e40a8f28f68653d4d387fe80cd93ab296ede8f5a590dd4390860925f9791dbc922bd44e57e3aaf7633f2149137d4e000017a9144492484d83d79176316454221c152ca71329039787a2de7f77997aefee04568eb363d0e7cf57f8c44d24ffcf98f6381d1e3d53511100 H7qPzptU3p/5N1+L5uGu6O0ZRxZ7t1rgQtXuvaKFDv5gVc/ISchyvz3BbNJj1vafFieTaCIkFR7yBlT/QrqOOS4=

Output:

c4384f39747de212c06a3afaa5157442fc761f34dde255cf5855d1de158f8d49

Your masternode is now registered and will appear on the Deterministic Masternode List after the transaction is mined to a block. You can view this list on the DIP003 Masternodes -> My Masternodes tab of the BitGreen Core wallet, or in the console using the command protx list valid, where the txid of the final protx register_submit transaction identifies your masternode.

Did this answer your question?