REQUIREMENTS

you are setting up a Sanctuary on a remote Linux cloud server (Sanctuary Wallet)
and storing BiblePay coins on a local Windows PC (Controller Wallet)

This is called a Cold setup, your coins are stored safely on your own machine in the controller wallet,
compared to a Hot setup, where the coins are stored on the remote server in the sanctuary wallet (not recommended)

PART C - Install Sanctuary Linux Wallet

NOTE: this part can be automated by downloading a script.
1. Download the script on the cloud machine:
cd ~
wget https://raw.githubusercontent.com/biblepay/biblepay/master/contrib/masternode-install.sh
2. Ensure script is executable:
chmod 777 masternode-install.sh
3. Run the script:
./masternode-install.sh
Follow the prompts. If your Cloud Machine has less than 2GB RAM, please allow the script to create a Swap File. After the setup is complete, you can continue at PART E step 2 (and you can skip PART F). Alternatively, you can set up manually by starting at step 1 below.

SANCTUARY_NAME: The name/label that you set for your sanctuary address in step 2 SANCTUARY_PUBLIC_IP: Your sanctuary IP (Your sanctuary Linux VPS/Cloud machine IP) SANCTUARY_PRIVATE_KEY: This is the private key that you placed in your remote configuration TRANSACTIONHASH: This is the transaction hash for the transaction in which you got your 1550001 BBP deposited. INDEX: This is the Index of your transaction for that address I'll show you how to get it in a bit.

NOTE: Replace YOURUSERNAME with the username where biblepay is stored: root, ubuntu, etc

NOTE: (If using vi, press i for insert mode, add the line at the end of the file
press ESC for command mode, type :wq to save and exit)

NOTE: 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:

SANCTUARY FAQ

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: 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: 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: What are the rpc 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,550,001 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: 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 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 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.

QUESTION: Sanctuaries are only Linux? Or will there be a Windows solution to this?
They are linux only, primarily because the proof-of-service software we use only runs on linux.
No windows solution is currently scheduled, unless our stratis Proof-of-concept is really well received.
If it is, Ill port watchman-on-the-wall to c# so that then you can run a Pose-enabled biblepay node in c#.

QUESTION: Is a static IP required?
Static ip is required, thats primarily why we recommend web hosts for this.
If your node fails to vote when its asked to you lose your sanctuary payment.

QUESTION: Is much bandwidth required ? Any calculations on this?
Very low bandwidth is required, only 10% more than a normal node,
Except since you are a full PoSE node you would be servicing inbound connections, however these are split among all the nodes.
Im running one with 1023 connections and its taking 40kbps so its pretty low.
You can see the network graph in the qt wallet btw (Tools | Network Traffic).

QUESTION: Is it OK to run a masternode on a dedicated machine with a high speed internet connection?
You can run your own sanctuary even on home dynamic IP, as long as its on linux running watchman on the wall, however you have two big risks:
1) If you do go down, you will lose your sanctuary payment, and if you fall out of the payment queue it might take 24 hours to get back in.
2) If your dynamic IP changes, you will have to re-create your whole sanctuary! The Escrow is tied to the static IP. <- This is a real pain..

QUESTION: How long will masternode with 40 GB storage last?
Our blockchain size is only 17 Megs right now with 21000 blocks,
with our small blockchain size and 7 minute blocks, we should technically sync fast and stay small for a long time

QUESTION: My wallet has multiple receiving addresses including masternode address.
If I send coin to other address, will it affect masternode?
Or when I run the masternode, is that masternode address locked?
1) Enable coin control features:

Settings > options > wallet > enable coin control features.

2) Go to send and click on "Inputs..", you should see the escrow amount being locked (you can unlock it by right clicking on it > unlock).

QUESTION: Why use cold wallet setup vs hot wallet setup?
To not leave your 1.55M BBP vulnerable on a web host. A cold Sanctuary means you can keep your BBP off site, in an encrypted wallet (in your controller wallet) where the coins are safer.

Would your computer withstand a DOS attack:
You can shut off your RPC port at home and run a private node, and add a firewall, and encrypt the wallet and even leave the coins in cold storage.

Easier and cheaper to run a VPS:
Based on my experience with the pool the only way to have 99.9% uptime is on a VPS. Too much happens on home networks that make it unreliable. Because we implement proof-of-service, you should consider the VPS option to keep your IP from changing and to ensure you receive your sanctuary rewards.

QUESTION: For a cold masternode setup, does the Controller Wallet have to stay online 24/7 like the Masternode Wallet?
No- controller only needs to be online to start the sanctuary.

QUESTION: Is it possible to setup multiple masternodes on one VPS?
Since you need a static IP per sanctuary, it can only be done via a lot of hacking, so without hacking - its not possible, and if you do pay for a block of IPs at the VPS, then it requires extremely advanced network config scripts to get it to work.

SANCTUARY PAYMENTS

QUESTION: How to view sanctuary payments?

masternode winners 100

As far as "luck" of winning the spot, we are using an algorithm where the nodes rank is determined by how close its vin is to the blockhash its voting on, so its really luck. Its ranking the winner based on blockhash uint256 minus masternode vin (this is called sanctuary delta), with the smallest delta ascending.

PRE_ENABLED means no chance of winning the vote, as the sanctuary is not trusted yet.

NOTE: If a sanctuary goes offline or falls into a bad state like "WATCHDOG_EXPIRED" it takes 30 hours for the sanctuary to fall out of the payment queue

NOTE: With Windows or Linux GUI Wallet, you can find your Receiving Address by clicking File >> Receiving Addresses
and right click copy Address, you can also create new addresses (and can also label them!)

Approval occurs when yes votes minus no votes equals 10% or more of the total available votes.

QUESTION: How to sell BiblePay after I get funded?
BiblePay is listed for trade on a few exchange, you can trade it for Bitcoin, Litecoin, USD (Dollars), etc
and then you may have to send Bitcoin somewhere else to convert it to Dollars

QUESTION: Are proposals funded all at once or in payments throughout the month? All at once.

QUESTION: What happens to budget funds that do not get allocated/spent on any proposals?
Coins are destroyed (equivalent to burnt, or not expanding the money supply) and opportunity to spend that allocation is lost for one month.

QUESTION: What is our current budget/proposal schedule? how to look it up? How many coins are in the budget?

View next Superblock and Check Budget:

getgovernanceinfo
getsuperblockbudget 24600

Subtract the Super Block from the Current Block https://biblepay-explorer.org/
Multiply 7 minute block rate, divide by 60 minutes, divide by 24 hours, and that is how many days until the superblock runs. ~3 Days before that the approved proposals will be moved into budgets, they will need to be voted on and then ~1 Day before the superblock the budgets will be frozen.

QUESTION: Are the budget categories hardcoded in? It seems like its just one big budget and we have to do some work ourselves to balance it out correctly?
Yes, as far as figuring it ourself, we do have to multiply our superblock budget by the percents currently

NOTE: Proposals are not the same as budgets. The proposals become budgets after they reach a supermajority and have a triggerheight for a superblock.

There are two phases each expense has to go through: proposal and budget.
The week before the superblock, we need to run the budget process (from the pool), and what happens is every proposal that fits in the budget will move to the Budget voting list. (Sorted by expense type (IE Charity, IT, PR, or P2P), votes descending , while Charity has the highest priority).

Anyway, once the budget is established it needs to be voted on by the sanctuaries. They need to vote on the budget before the deadline which is 24 hours before the superblock hits. So we need to be voting on it Id say T-3. Then T-1 the budget is frozen and cannot be changed.

When we believe the budget is frozen, we issue a superblock trigger in the chain (the pool is programmed to automatically do this for us). At this point the "triggerheight" that equals the superblock will be on all the budget records.

Then we sit back and pray that the superblock is generated. After this happens, the budget items are moved to Funded.

NOTE: I was trying to reconcile the 2.8MM coin emission in the 30 day superblock cycle for one month of charity expenses, vs. the huge amount of coins we initially sold for the very first month of existence (7MM), and I was thinking, why less than half?

It turns out the reason why is our superblocks use the assumption of maximum diff and minimum block payment, to ensure that enough BBP is held back during the period regardless of the dynamic emission level - another words, it assumes each days minimum subsidy is paid to comprise the 30 day 20% total.

So if you are trying to reconcile this 5.78MM budget for one month, its based on the minimum 5,000 BBP block minus deflation (1.5% per month) * .20.

REMEMBER ALL: (Note from Lead Dev) We have IT integration with compassion for the inbound letters, the outbound letters, the orphan row click (biographies), and they have translators, so remember we potentially lose all that if we sponsor children from another charity.

When it comes to Charity, our entire mission is based on Charity, in this case I recommend we sacrifice every other department for Charity

Ill try to be more careful and only sponsor new children where the amount extends out to One Year (of premiums), so we have a buffer (we talked about that in the beginning)

1. There is no need to kill biblepayd if you simply first do biblepay-cli stop, and then edit the conf file, so you can just reverse the steps and first put the step to stop biblepay, then you can edit the conf file without problems with rpc, so then you can start biblepayd again normally

2. Sometimes two commands can be one, I don't know if it's easier for beginners to follow if there are two simple commands, or it's easier if there is just one command if they just copy/paste anyway: for example, instead of:
cd ~/.biblepaycore/
vi biblepay.conf
it could be just
vi ~/.biblepaycore/biblepay.conf

3. For beginners it can be really hard to find the AppData folder on their PC (being hidden and all) to edit the conf files, so I suggest you simply replace that with GUI (wallet) instructions, which is as easy as: Tools => Open Wallet Configuration File (for biblepay.conf) and Tools => Open Masternode Configuration File (for masternode.conf)

4. "getaccountaddress SANCTUARY_NAME" can also be easily done in GUI, File => Receiving addresses... => New, also the Start alias part, there's simply a button there in GUI, but since other commands can't avoid debug console, then perhaps I would leave that as is.(edited)
5. I would move the "Financing your masternode" part somewhere above previous steps, because waiting for confirmations about the collateral tx takes more than one hour, and then you just have to wait if you did everything else already. I think it's more rational to first just do the transaction and then setup the Linux wallet in the meantime while the tx is being confirmed.