BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

Without going into all the boring technical details, we adopted CockroachDB as our back-end decentralized database in hopes that Temples could run an instance of CockroachDB, and that would be the storage engine of choice for us to host the sidechain.

Most of the hurdles were solved, like the HTTPS certificates, the automatic syncing, the install, the data format, the blocks, the content, etc.
However, one thing ended up killing the project in the end (and it is very similar to other non decentralized clustered databases):  It does not gracefully handle the loss of nodes during volatile periods.  We had 3 nodes in the cluster for months without a problem but after some expirimentation, I found that if BBP temples would join/unjoin sporadically, it would corrupt the database, and after spending an exorbitant amount of time to try to restore the db in those situations, I realized its just not going to work for us long term. 

So Im back to creating our own flavor of decentralized dbase, one that the Users own (I wont even be required in this project once I check in the code); all the keys are going to belong to the Temples who run this dbase.  Im migrating cockroach data down to JSON first.  Working on this in the background.

So to keep this decentralized it looks something like this:
- You host a temple
- Your temple runs this BBPDB
- Keys and configuration are embedded in the program, so Im not required

A second project is required for our Phone and Storj storage:
- Since Storj hosts our video content
- Since our PBX provides phone service
- We need a generic layer that will allow more than one, preferably 3, users to "volunteer" to run a "service type" (like phone or storage),
and the code will encrypt the keys, and use them in the temple.  Then when people drop off who no longer host a PBX or a Storj account,
they will get replaced with the other keys automatically.  This would be similar to a decentralized "market making" service.

This way I will not be needed for that particular function, and its keys can be used and protected by a temple (node).


So that is the plan for the time being and Im actively working on the BBPDB.

This is so messed up! I thought we were going towards user-friendly interface but now back to the not so user-friendly interface!
I know we do not have bunch of users, but this layout is difficult for new users.
Long Live BBP!

Dear brothers.
I started the new version wallet and synched well.
I executed the masternode status command, below the results..... I'm on right way ?

15:43:13
masternode status


15:43:13
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "[::]:0",
  "state": "WAITING_FOR_PROTX",
  "status": "Waiting for ProTx to appear on-chain"
}

Thank you...

Dear brothers.
I started the new version wallet and synched well.
I executed the masternode status command, below the results..... I'm on right way ?

15:43:13
masternode status


15:43:13
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "[::]:0",
  "state": "WAITING_FOR_PROTX",
  "status": "Waiting for ProTx to appear on-chain"
}

Thank you...

Yeah, you seem to be on the right track.
If you did an exec upgradesanc, the protx went out, but it takes a few blocks to register itself.

Just try the status again after a couple hours.

Rob the community wants to know are you still there?

Yeah, you seem to be on the right track.
If you did an exec upgradesanc, the protx went out, but it takes a few blocks to register itself.

Just try the status again after a couple hours.

Brother Rob,
still the same today...

Dear brothers.
I started the new version wallet and synched well.
I executed the masternode status command, below the results..... I'm on right way ?

15:43:13
masternode status


15:43:13
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "[::]:0",
  "state": "WAITING_FOR_PROTX",
  "status": "Waiting for ProTx to appear on-chain"
}

Thank you...

Brother Rob,
still the same today...

Rob, brother.

The wallet is crashed during the "exec upgradesanc AltareSanto 1" command.

Now the situation is changed to this.


11:02:52
exec upgradesanc AltareSanto 0


11:02:52
{
  "Command": "upgradesanc",
  "Summary": "Creating protx_register command for Sanctuary AltareSanto with IP *.*.*.66:40000 with TXID 13cb0827e303d05604481be19dab67ae401357a9c2fe48b15936cb48e03d29c6",
  "bls_public_key": "b82a0249b0323c05f89448b9246b63ac2d3c91bec2431e8596581b664ea95484382c46c718c70a92c1016c089c838f2b",
  "bls_private_key": "61a3a78031ebf958832fb960ded4160f353d64a16591e286a41a2713713133b8",
  "pro_reg_txid": "0300010001df2ed6b028f35f75f28d21cb82bd415901acef3edcad869ea90f126bf1920f2a0100000000feffffff016c661903000000001976a914da266fc172389feffdd44105e460b996a3cd826588ac0000000000d1020000000000c6293de048cb3659b148fec2a9571340ae67ab9de11b480456d003e32708cb130100000000000000000000000000ffff5d37fc429c40a0761b3fffcf408d157197fa366d771db5835f0eb82a0249b0323c05f89448b9246b63ac2d3c91bec2431e8596581b664ea95484382c46c718c70a92c1016c089c838f2ba0761b3fffcf408d157197fa366d771db5835f0e00001976a914da266fc172389feffdd44105e460b996a3cd826588ac0db6b50e182f58cc86674b55a713e6304e94b86bd611f00da54793759a5072eb00",
  "pro_reg_collateral_address": "BKcqLFDfZZUJWyaivmZR3WRMVdFCv1p6Qy",
  "pro_reg_signed_message": "BQLYy9oNyiCdbym3Vd7dd8nqiP2xAipdYc|0|BK5XDb4TrZHRzTQnVEQhaqV3DbhX65b7zY|BK5XDb4TrZHRzTQnVEQhaqV3DbhX65b7zY|d8a79a5a10e600c12ee6c759e86772df3a3233de8326a72c7930d4eecc11c80b",
  "pro_reg_signature": "IGBCLghtakvYladlI8To5LJiBqeZ1z7A5FjssRSB1756C5BEH4QY+TGVwD2Y7cphWE5k7vSepP5Xz4aKxdlDV0E=",
  "sent_txid": ""
}

The IP add is masked by me


11:04:22
exec upgradesanc AltareSanto 1


11:04:22
bad-protx-collateral-01 (code -1)


The transaction message from wallet appear




11:05:44
masternode status


11:05:44
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "[::]:0",
  "state": "ERROR",
  "status": "Error. Can't detect valid external address. Please consider using the externalip configuration option if problem persists. Make sure to use IPv4 address only."
}


Is this a bug or something like it ?

Thanks
Ale

Rob, brother.

The wallet is crashed during the "exec upgradesanc AltareSanto 1" command.

Now the situation is changed to this.


11:02:52
exec upgradesanc AltareSanto 0


11:02:52
{
  "Command": "upgradesanc",
  "Summary": "Creating protx_register command for Sanctuary AltareSanto with IP *.*.*.66:40000 with TXID 13cb0827e303d05604481be19dab67ae401357a9c2fe48b15936cb48e03d29c6",
  "bls_public_key": "b82a0249b0323c05f89448b9246b63ac2d3c91bec2431e8596581b664ea95484382c46c718c70a92c1016c089c838f2b",
  "bls_private_key": "61a3a78031ebf958832fb960ded4160f353d64a16591e286a41a2713713133b8",
  "pro_reg_txid": "0300010001df2ed6b028f35f75f28d21cb82bd415901acef3edcad869ea90f126bf1920f2a0100000000feffffff016c661903000000001976a914da266fc172389feffdd44105e460b996a3cd826588ac0000000000d1020000000000c6293de048cb3659b148fec2a9571340ae67ab9de11b480456d003e32708cb130100000000000000000000000000ffff5d37fc429c40a0761b3fffcf408d157197fa366d771db5835f0eb82a0249b0323c05f89448b9246b63ac2d3c91bec2431e8596581b664ea95484382c46c718c70a92c1016c089c838f2ba0761b3fffcf408d157197fa366d771db5835f0e00001976a914da266fc172389feffdd44105e460b996a3cd826588ac0db6b50e182f58cc86674b55a713e6304e94b86bd611f00da54793759a5072eb00",
  "pro_reg_collateral_address": "BKcqLFDfZZUJWyaivmZR3WRMVdFCv1p6Qy",
  "pro_reg_signed_message": "BQLYy9oNyiCdbym3Vd7dd8nqiP2xAipdYc|0|BK5XDb4TrZHRzTQnVEQhaqV3DbhX65b7zY|BK5XDb4TrZHRzTQnVEQhaqV3DbhX65b7zY|d8a79a5a10e600c12ee6c759e86772df3a3233de8326a72c7930d4eecc11c80b",
  "pro_reg_signature": "IGBCLghtakvYladlI8To5LJiBqeZ1z7A5FjssRSB1756C5BEH4QY+TGVwD2Y7cphWE5k7vSepP5Xz4aKxdlDV0E=",
  "sent_txid": ""
}

The IP add is masked by me


11:04:22
exec upgradesanc AltareSanto 1


11:04:22
bad-protx-collateral-01 (code -1)


The transaction message from wallet appear




11:05:44
masternode status


11:05:44
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "[::]:0",
  "state": "ERROR",
  "status": "Error. Can't detect valid external address. Please consider using the externalip configuration option if problem persists. Make sure to use IPv4 address only."
}


Is this a bug or something like it ?

Thanks
Ale

Hi Lalex,

So when you issue the command upgradesanc, usually, its not actually a "crash" (crash means that the wallet either threw an unhandled exception and ended the program), but instead was sitting there with no RPC response, right?  Ive seen that behavior in this new RPC, and I believe we inherited a UI deadlock.
It does respond to me after 3 minutes however.

The bad-pro-tx-collateral error must be resolved first to get a fully functioning sanc.  It means that your collateral has either not been sent or not matured.  I would start over, and when you do your 'getrawtransaction txid ordinal' ensure it is actually there, has the right amount, and has matured a few blocks before going to the next step.

Hey Rob,

So when you issue the command upgradesanc, usually, its not actually a "crash" (crash means that the wallet either threw an unhandled exception and ended the program), but instead was sitting there with no RPC response, right?
Yes, but 3 minutes it's not enough.
After al lot of time, hrs, still "hang" and need to be killed.
 
"Masternode command at Italian time"

10:44:48
masternode status

10:44:48
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "[::]:0",
  "state": "WAITING_FOR_PROTX",
  "status": "Waiting for ProTx to appear on-chain"
}


Now, the question is:
How many time need the ProTx to appear on the chain ?

Thanks

Hey Rob,

So when you issue the command upgradesanc, usually, its not actually a "crash" (crash means that the wallet either threw an unhandled exception and ended the program), but instead was sitting there with no RPC response, right?
Yes, but 3 minutes it's not enough.
After al lot of time, hrs, still "hang" and need to be killed.
 
"Masternode command at Italian time"

10:44:48
masternode status

10:44:48
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "[::]:0",
  "state": "WAITING_FOR_PROTX",
  "status": "Waiting for ProTx to appear on-chain"
}


Now, the question is:
How many time need the ProTx to appear on the chain ?

Thanks

Hi Ale,
Sorry for the delay, I have been working on re-creating our native NFT feature on chain rather than in arbitrum.

I guess your machine is slightly different than mine, because I was seeing a 3.1 minute delay, but, I am glad you confirm it is not a crash, yes.
One hint to avoid that altogether is to just restart the wallet then do the upgradesanc within 10 mins of rebooting, and you should not see the deadlock.  I have discovered where that is in the code and will be pushing an update any day now once fixed.

Regarding this question "How many time need the ProTx to appear on the chain ?"
It just needs to appear once.

Biblepay - v0.21.5
Mandatory Upgrade

Summary of Changes:


- Added NFT add,edit,delete capability to core wallet.
- Reinstituted SideChain transactions.
- Incremented min_masternode_proto_version to 70783 so as to facilitate a mandatory upgrade for LLMQ messages.
(Requires Temples to enforce our global LLMQ).
- Added CheckMemPoolTransactionBiblepay, which is our facility
to check mempool txs.  In this version we enforce the NFT buy rules, to allow the safe transfer of NFT.
- Reinstituted embedded sTxOutMessage in CreateRawTransaction (allows longer messages, such as NFTs to go in the chain).
- Prevent Sancs from continually adding false governance triggers due to a bug.
The code checks for an existing govobj first, and also caches the last one created (preventing dupes).
- Ensure sancs do not vote on triggers that already won.
- Make temples handle WatchmanOnTheWall, but not Sancs.
- Added exec listnfts.
- Removed UI deadlock (affecting various RPC commands
like sendrawtransaction and upgradesanc, and possibly the LLMQ
timeouts).
- Modified the LLMQ rules to work with Temples.
- Modified Pose background thread to only deal with one
sanctuary at a time (solves the deadlock).

Github:
https://github.com/biblepay/biblepay/releases

 You can download the wallet for windows from either Github or www.biblepay.org.

Biblepay - v0.21.5
Mandatory Upgrade

Summary of Changes:


- Added NFT add,edit,delete capability to core wallet.
- Reinstituted SideChain transactions.
- Incremented min_masternode_proto_version to 70783 so as to facilitate a mandatory upgrade for LLMQ messages.
(Requires Temples to enforce our global LLMQ).
- Added CheckMemPoolTransactionBiblepay, which is our facility
to check mempool txs.  In this version we enforce the NFT buy rules, to allow the safe transfer of NFT.
- Reinstituted embedded sTxOutMessage in CreateRawTransaction (allows longer messages, such as NFTs to go in the chain).
- Prevent Sancs from continually adding false governance triggers due to a bug.
The code checks for an existing govobj first, and also caches the last one created (preventing dupes).
- Ensure sancs do not vote on triggers that already won.
- Make temples handle WatchmanOnTheWall, but not Sancs.
- Added exec listnfts.
- Removed UI deadlock (affecting various RPC commands
like sendrawtransaction and upgradesanc, and possibly the LLMQ
timeouts).
- Modified the LLMQ rules to work with Temples.
- Modified Pose background thread to only deal with one
sanctuary at a time (solves the deadlock).

Github:
https://github.com/biblepay/biblepay/releases

 You can download the wallet for windows from either Github or www.biblepay.org.

Thanks Rob, updating now.

I upgraded too.

Can someone help correct the info so I can set up a sanc and start staking?  The first step at least seems to have changed with the new wallet:

I asked Google: How to set up a sanctuary with BiblePay

I got:

Create Sanctuary
How to create a deterministic Sanctuary


Ground Rules: You must have a controller wallet (this is your home wallet that is used to manage one or more sanctuaries). The lines below marked with controller must be run by your home wallet. The Sanctuary wallet is your VPS that runs the actual Sanctuary Software.



Step 1:
From the Controller Wallet, launch Biblepay QT. Go to File | Receiving Addresses.

xx This step now seems wrong.  I don't see that under file.   So I just selected Receive to get a wallet address.

Create a new address for your sanctuary (by clicking new), then edit it and label it with a good name (for example, sanc1) Write this sanctuary name down in notepad. Copy that address to your clipboard. Close the dialog.
Step 2:
Now we will fund the sanctuary. Go to Send. Paste the Address of the Sanctuary (from the first step) in the To box. Populate amount 4,500,001. Send.

Am I required to have 4,500,001 as an amount or can I put in a lesser amount?

I guess the rest is correct, if not, please let me know.

Step 3:
Go to the Transaction List, and find the transaction that you sent. Double click on it. Copy the transaction ID to your clipboard. Now we need to find out the TXID ordinal. Launch Notepad, and paste the txid in notepad and label it Collateral TXID. Now go to Tools | Debug Console. Type:
getrawtransaction txid 1
The command will show the details of the transaction you just sent. Scan the output of this command for the leg of the transaction that has an amount of 4,500,001. Once you find that leg, copy the "n" value of it. Usually, this will be 0 or 1. Copy that "n" value to notepad and label it "txid-ordinal".

Step 4:
Now we need to add an entry to the Controller wallets masternode.conf file. In mainnet, this file is located at ~/.biblepay/masternode.conf. In TestNet, this is located at ~/.biblepay/testnet3/masternode.conf. Note that on windows, you need to replace ~/.biblepay with %appdata%\biblepay. Nano this file. We need to store a new entry in it like this:
sanctuary_name sanctuary_vms_ip:sanctuary_port mnp collateral_txid collateral_txid_ordinal
You should replace sanctuary_name with the name that you wrote in notepad. Replace vms_ip with the ip address of your sanctuary. Replace port with 40000 for mainnet, or 40001 for testnet. Leave mnp as is. Replace collateral_txid with the TXID in notepad. Replace txid_vout_ordinal with the TXID ordinal from notepad. Save the file. Exit nano.

Step 5:
Now we need to upgrade the sanctuary to deterministic from the Controller wallet. From the RPC console, type:
upgradesanc sanc_name
Note! If the response says: 'unable to find funds at address nnn', this simply means you need a little BBP to cover maintenance. In this case send 1000 bbp from your controller wallet to the address on the screen (copy it to clipboard) and send to it, then wait 3 blocks then try again.

If the command is successful, it will emit about 10 lines of technical details about your new sanctuary. You are primarily concerned with the BLS public and private keys. Copy the BLS public and private keys to notepad and label them the same names.

Step 6:
Now we are ready to spin up the actual VMS sanctuary. From the VMS Sanctuary, first install either biblepay-qt or biblepayd (the sanctuary will run from either one). Most people use biblepayd. cd ~/.biblepay From here, we need to enter the BLS_PRIVATE_KEY in the biblepay.conf file! nano ~/.biblepay/biblepay.conf (this is for mainnet). For Testnet: nano ~/.biblepay/biblepaytest.conf Insert the following line
masternodeblsprivkey=nnn
Replace nnn with your actual bls_private_key (from notepad). Save the file.

Step 7:
Now we can start the sanctuary. Start the sanctuary, wait for it to sync, then type:
masternode status
At this point if it says READY: you have a perfectly running sanctuary. Now all you need to do is monitor the POSE status from the controller, and ensure it stays at 0. If it goes up, you can always revive your sanctuary with 'exec revivesanc sancname'.

No, thats cool, I dont mind going into more detail where need be.  We also do have some wiki guides on some of these concepts and when one is discovered that is really necessary to document we do make an end-to-end tutorial as a wiki.

First of the reason there are 3 flavors of Sancs now is because some people cant afford 4.55MM bbp for a sanctuary; so now we offer one flavor of sanc for 455,001 bbp and also a Temple for 45MM bbp.  They each have really the same reward (IE the altar pays 10%, the Sanc 100% and the Temple 1000%).

With a sanc you get a bigger reward because its doing the randomx mining in the pool, and you end up with the entire block reward every time your deterministic sanctuary is scheduled for payment. 

If you are an investor you will get 50% of the reward, but an active hosted sanc on a VM, you get 100%.

I would suggest to go back to the release where we ask you to create a deterministic sanctuary, and simply ask questions on any area that is confusing and I can try to help.
Most of this documentation was already established dash; so any terminology on the basics, you can get that from googling that term and Dash Masternode.

Weve simply enhanced and extended those Masternodes to become deterministic sancs with different sizes, and we ported the block miner into the sanc.  And we added the 50% active/passive rules.

Here is the guide to set up a sanc:
https://wiki.biblepay.org/Create_Sanctuary

Just let me know what you need help with.  If you simply want to set up one without renting an actual VM (IE as a passive investor) you just follow the guide, but you point it to your own IP address.

Substitute the 4,500,001 with 450001 to create an altar.