Create Sanctuary

From BiblePay Wiki
Jump to: navigation, search

BiblePay Sanctuaries Setup - Linux Server


Updated 12-7-2017

This guide is for a single Sanctuary, 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:
  • 1,550,001 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 sanctuary 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 [SANCTUARY_ALIAS]
    (BTW, Sanctuary Alias is just a very short ID for your sanctuary only known by the controller wallet.

So Sanctuary 1 might be SN1. Sanctuary 2 might be SN2. 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> 1550001

(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 Sanctuaries, use alphanumeric characters only)
  • rpcport=40009
  • rpcallowip=
  • 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
  • rpcport=40009
  • rpcallowip=
  • listen=1
  • server=1
  • daemon=1
  • logtimestamps=1
  • externalip=SANCTUARY_PUBLIC_IP:40000 (if this doesn't work, try just IP without :40000 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 sanctuary, 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:40000”, "pubkey” : “sanctuary 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: Step of Huge Importance ** If watchman is not running, Proof-Of-Service will fail and your node will report WATCHDOG_EXPIRED in the controller sanctuary list. To verify watchman is running, run the command you typed in the crontab above as the actual user. For example, if biblepay runs as user bible, login as bible, then copy the command from above like this: cd ~/.biblepaycore/watchman && ./venv/bin/python bin/ Without the trailing /dev/null 2>&1. Run the command. Verify the output is empty. If so, you have successfully configured watchman!

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 1550001 and dont click instant send or any other options.

If you are creating a Hot wallet (IE funds live on the Sanctuary) you would send the 1,550,001 to the Sanctuary 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 Sanctuary?

-> The Sanctuary is the wallet running at the hosting company with the static IP.

QUESTION: Does the Sanctuary actually hold coins? -> In a Hot Sanctuary scenario, the Sanctuary holds the coins, otherwise the Sanctuary wallet is empty. Biblepay puts a lock on the escrow when the Sanctuary 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 1,550,001 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 1,550,001.

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_sanctuary_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 Sanctuary. 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 Sanctuary has stayed up and eventually becomes important if we have more than about 800 Sanctuaries, 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 Sanctuary 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 sanctuary and see the masternode list 'masternodelist'.

QUESTION: Where does Watchman fit in the process? What is Watchman? what is it doing? -> Peace be still and bear with us, why do 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. The watchman requires Pro-players for Sanctuaries and shuns the lackadaisical nodes [such as one that is on a video game PC that is rebooted]. 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. This feature allows internal deleting governance objects by sanctuary. 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 properly. The code developed and ported to Watchman was created for a modular design, in case the sanctuary needs to upgrade the superblock code side and NOT the entire network (to upgrade the wallet). We inherited this design and embrace it.

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 sanctuary 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.