Create Masternode

From BiblePay Wiki
Jump to: navigation, search


use these newer guides:

BiblePay Sanctuaries Setup - Linux Server


Updated 10-10-2017

This guide is for a single masternode, on a Ubuntu 16.04 64bit server, hosted by and will be controlled from the wallet on your local computer.

If you do not already have one, get an account at Choose a Location, Ubuntu 16.04 x64, 25 GB SSD (currently $5/month) with 1 CPU, 1024MB Memory and 1000GB bandwidth.

Install the Linux wallet (follow the guide for Linux at Reddit)

After you’ve got your sanctuary linux instance started, you need to go through some initial setup before you do anything Sanctuary related.

    First the basic requirements:
  • 500,000 BBP
  • A home computer (Your everyday computer) - This is called the Controller Wallet
  • Sanctuary Node (The computer that will be on 24/7 on the rented server with the public IP)
  • A unique IP address for EACH sanctuary
  • (For security reasons, you’re going to need a different IP for each masternode you plan to host) The basic reasoning for these requirements is that, you get to keep your BBP in your local wallet, and host your sanctuary remotely, securely.

For this guide, the home computer’s wallet will be referred to as the CONTROLLER WALLET, and the sanctuary node wallet as the SANCTUARY WALLET.

Storing escrow funds on a sanctuary wallet is not recommended (this is called a HOT SANCTUARY). Storing escrow funds on the controller wallet is called a COLD SANCTUARY.

I will also be simulating the install using a Ubuntu server using the command line. If you're using biblepayd, all commands should be proceeded by ./biblepay-cli

1) Using the SANCTUARY WALLET: Enter this command:

masternode genkey

Log the private key in notepad as your "SANCTUARY PRIVATE KEY".

2) Using the 'CONTROLLER Wallet', enter the debug console. Type the following commands:

      getaccountaddress [MASTERNODE_ALIAS]
    (BTW, Masternode Alias is just a very short ID for your masternode only known by the controller wallet.

So masternode 1 might be MN1. Masternode 2 might be MN2. Keep it short, simple, uppercase, and without spaces. (Otherwise, you will hose your masternode.conf file !).

Record the BBP Address that is emitted from the above command in notepad as ESCROW_ADDRESS).

Next, send some escrow funds to the new escrow address you created in the above step; this escrow is used by sanctuary to provide cool services to users, such as instantsend and retirement account trading:

      sendtoaddress <ESCROW_ADDRESS> 500000

(Record the output of this command in notepad as ESCROW_TXID). Then type this:

      masternode outputs

    (Record the output of this command in notepad as ESCROW_TXID and ESCROW_VOUT).

2) Still on the CONTROLLER WALLET computer, go into the BBP app-data directory, by default in Windows it is: %Appdata%/biblepaycore (or ~ on linux):

Find masternode.conf and add the following line to it: (*** NOTE: For TestNet, you must modify testnet3\masternode.conf ***):



3) Still on the controller wallet computer, open the biblepay.conf - find it or use the edit config file in client under tools %appdata%\biblepaycore\biblepayconf file:

  • rpcuser=long random username
  • rpcpassword=longer random password (special characters in rpcuser and/or rpcpassword have caused issues in Dash masternodes, use alphanumeric characters only)
  • rpcallowip=
  • rpcport=40009
  • listen=0
  • server=1
  • daemon=1
  • logtimestamps=1
  • maxconnections=256

Save it, close and restart the wallet

4) Now on the SANCTUARY WALLET, open biblepay.conf from (Linux: ~/.biblepaycore).


  • rpcuser=long random username
  • rpcpassword=longer random password
  • rpcallowip=
  • rpcport=40009
  • listen=1
  • server=1
  • daemon=1
  • logtimestamps=1
  • externalip=SANCTUARY_PUBLIC_IP:40001 (if this doesn't work, try just IP without :40001 and restart)
  • maxconnections=256
  • masternode=1
  • masternodeprivkey=SANCTUARY_PRIVATE_KEY

Make sure to replace rpcuser and rpcpassword with your own.

5) Close and restart this sanctuary node.

6) Now, you need to do this from the Controller Wallet computer: (make sure wallet is unlocked)

masternode start-alias SANCTUARY_ALIAS

If you did it right you will see:

overall: Successfully started 1 masternode, failed to start0


alias: MnName result:successful

7) Use the following command to check status:

masternode status

You should see something like:

  “vin” : “CTxIn(COutPoint(masternode output, index), scriptSig=)”,
  “service” : “ip:40001”, "pubkey” : “masternode address

Next, the sanctuary needs watchman-on-the-wall running, so that your node can broadcase Proof-of-service to the network and create superblocks.

Please follow these instructions from the sanctuary linux node terminal:

sudo apt update
sudo apt install git python-virtualenv virtualenv
cd ~/.biblepaycore
git clone
cd watchman
virtualenv venv
venv/bin/pip install -r requirements.txt

In the next step, modify watchman.conf to point the watchman at either test or prod. (#network=mainnet or #network=testnet). To run watchman against testnet, ensure a pound exists in front of #network=mainnet, and uncomment the # symbol in front of network=testnet.

nano watchman.conf

To test watchman, run the watchman python program like this, and ensure it outputs nothing (that means there are no errors and it works):

venv/bin/python bin/

Next, you will want to install watchman in the cron so it runs every 5 minutes. This way, whether biblepayd is rebooted, or regardless of the status of our superblocks, watchman will keep reporting the status of your sanctuary to the network:

Install Watchman in cron:

crontab -e

Add this line:

* * * * * cd ~/.biblepaycore/watchman && ./venv/bin/python bin/ >/dev/null 2>&1

NOTE: To run BiblePay daemon in testnet mode: ./biblepayd -testnet

Next, to set up the firewall (this keeps your node from being attacked, and locks down most of the ports except the necessary ports).

Note that port 40000 is biblepay-prod, while 40001 is biblepay-testnet.

SSH is opened to allow you to access the sanctuary via SSH for administration.

Port 137,138,139, and 445 are the Samba ports.

This is only necessary if you want to share files between an SMB fileshare and your controller wallet.

Please remove that step if you do not want to use Samba.

  • apt-get update
  • apt-get install ufw
  • ufw allow ssh/tcp
  • ufw limit ssh/tcp
  • ufw allow 40000/tcp
  • ufw allow 40001/tcp
  • ufw logging on
  • The following is for Samba:
  • ufw allow 137/udp
  • ufw allow 138/udp
  • ufw allow 139/tcp
  • ufw allow 445/tcp
  • End of Samba Section
  • ufw enable
  • ufw status


QUESTION: Are we sending coins to ourself?

-> It is OK to send the balance to yourself or from another node (I tested both). The important thing is to make the amount exactly 500000 and dont click instant send or any other options.

If you are creating a Hot wallet (IE funds live on the masternode) you would send the 500k to the masternode wallet. Now that we know cold wallets work, the recommended way is to send the funds To the cold wallet (IE the home controller wallet).

QUESTION: Which node is the Masternode?

-> The masternode is the sanctuary running at the hosting company with the static IP.

QUESTION: Does the Masternode actually hold coins? -> In a Hot masternode scenario, the masternode holds the coins, otherwise the masternode wallet is empty. Biblepay puts a lock on the escrow when the masternode starts.

QUESTION: Is there a certain label that should be used for getaccountaddress?

One pitfall I noticed is if you use the same label more than once sometimes I get a new address. I would recommend something short such as "MN1". To ensure its only in the book once, click Receiving addresses and if it is already there as MN1, copy it to clipboard.

QUESTION: How to deal with fees when sending? Does amount have to be 500,000 exactly?

Fees are OK as long as you dont click the checkbox to Subtract fees. Fees are stored in a different vector, so the vout is still 500,000.

QUESTION: What IP address goes in this part of the config? "externalip=your_public_ip"

-> When you rent your VM, and click into its hosted properties, you should see a public IP. You should copy that and make it like this: externalip=your_masternode_public_ip NOTE: This is only required on the sanctuary side, not on the controller wallet side.

QUESTION: What are these config settings doing? Can the Home Wallet now control the Linux Wallet? or reverse of that?

-> These config settings only allow the home controller wallet to start and stop the masternode. This is not only to safeguard your eventual 1 million BBP escrow if it goes up in value (to prevent vultr host from stealing it), but also because of Proof-Of-Service. Dash has created POSE, which monitors how much uptime your masternode has stayed up and eventually becomes important if we have more than about 800 masternodes, these nodes start falling to the back of the payment queue and do not get paid if they need restarts. When they fail and need restarted, it is easy for home computer controller wallet to start the masternode again.

QUESTION: Im stuck, help! :) I opened /testnet3 debug.log with baretail and I see action happening, is their a syncing Period? -> Yes, unfortunately this is a very frustrating, thats one reason I had to go to 1 minute blocks in testnet. The wallet requires blocks to be moving for the 'mnsync status' command to iterate to the next step. Do a setgenerate true 5, to keep blocks moving. After 'mnsync status' shows 999, then you can start and stop the masternode and see the masternode list 'masternodelist'.

QUESTION: Where does Watchman fit in the process? What is Watchman? what is it doing? -> Yes, I know. Why we have to have yet another piece of software called Watchman-on-the-wall? Watchman implements proof of service and one major superblock budget feature. Let us say without it, Dashs POSE system would be in tatters. Basically, if BBP ever reaches say $50 million market cap and then we have 1000 masternodes, situation A is without watchman, all the nodes who do a start on windows and then start playing video games a few hours later and kill the node by accident those nodes would not be doing anything for us, and would still get paid fully. With watchman, every node has to send a watchdog alert every couple hundred blocks and prove their static IP and how long they been online. This means as competition heats up you really have to have provided good service to stay in the payment queue. The other thing watchman does is collects a database of gobjects. Governance objects are stored in tables. Votes are kept. It allows deleting governance objects by masternode. The most important thing it does is when we create a very complicated budget that got approved from a proposal, it creates a text file of budget items for the superblock. Without it the superblocks dont work very well. Dash probably could have added code to masternode governance for all of it, but they chose this modular design in case they want to have masternodes upgrade the superblock code side and NOT the entire network to upgrade the wallet. We inherited it so we have to embrace it now - what I am hoping is the version we ported is already stable and I can code a lot more on the web side and sort of freeze what we have for a year and grow as we are until we have our extra few IT devs helping me out to ensure we have the bitcoin commits committed constantly.

Watchman on the wall error: Cannot connect to biblepayd. Please ensure biblepayd is running and the JSONRPC port is open to watchman. STUCK: What am I doing wrong here? -> In this case I would go to the masternode and edit the biblepay.conf, and ensure rpcallowip= is set. Also check to make sure watchman.conf has testnet uncommented and prod commented.


Good luck and stay close to God.