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: Why port 51472? And does it need to be changed in any firewalls?
-> Oh no, this is a mistake, I will modify the guide. This should be 40001. Also in the UFW command list, it should be 40001.
Port 40001 is BBP testnets P2P port, 40000 is Prod BBP p2p port.
QUESTION: What IP address goes in this part of the config? "externalip=your_public_ip"
-> So 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.
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=127.0.0.1 is set.
Also check to make sure watchman.conf has testnet uncommented and prod commented.