Messages

181

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: December 12, 2024, 05:47:17 AM »

Thanks for the replies, Rob.

I just wanted to mention, Bololex is not allowing Doge deposits.  A bit hard to trade on there without funding the wallet with DOGE.  Also, other deposits and withdraws are disabled that I've noticed.

Ahh, I didnt realize that, thanks.  I did see that they installed some type of auto trading bot (AMM) on bololex, (similar to the way SX used to work). 
Maybe it is good for volume in the long run as people want to liquidate things.

I hope they are going to stay in business.

So on the bright side since Trump won, this will be a very good time for Crypto.
All, keep praying that a Christian exchange owner steps up and lists us on a large exchange, for more volume.


In the mean time Ill start putting the roadmap together.
With the goal of outlining all of our ideas and where they are in a succinct way.

182

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: December 11, 2024, 06:47:16 AM »

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

Correct, everything is still good in that doc to my knowledge (I created one relatively recently using the same old steps).
Except you are right, the receive address is in Receive now due to latest version of rebase, yes.
Just let me know if there is a specific area where you get a hang up now.

183

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: December 11, 2024, 06:43:45 AM »

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

Can it be any number, like 555,007?

Also, you said you imported the miner into this process.  Is this going to take more CPU/RAM than normal staking?

Hi CB and Good to hear from you and God bless you.

Because of many areas of the code, where we do collateral detection, it has to be exactly one of the three numbers (IE 4500001,450001,45000001).

The sanctuary will use more CPU only (not extra ram) during mining, yes, but its only doing it one thread in a non competitive way, so its something like 10% of the processor on a VM (not 100%).

184

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: November 23, 2024, 01:28:36 PM »

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.

185

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: November 23, 2024, 05:08:03 AM »

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.

186

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: November 10, 2024, 06:26:07 AM »

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.

187

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: October 29, 2024, 04:00:36 PM »

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.

188

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: October 09, 2024, 05:49:23 AM »

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.

189

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: October 09, 2024, 05:38:54 AM »

Does anyone know Bob personally, and could reach out to him?

Are you all referring to me?
I'm fine, just havent been on the forum with all the IT projects going on.
I'll have to elaborate on the CockroachDB, that is the biggest problem right now.
I spend over 200 hours getting CockroachDB to behave in a decentralized way for BBP, and at the end, its not going to work for us.

190

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: September 05, 2024, 07:25:24 PM »

Hi Rob,

Sorry, I didn't see this until now.

Thanks for acknowleding my post.

Yes, you understand what I'm saying.  It's up to you of course.  Its a type of design philosophy, UX as they say these days. 

User Experience (UX) is a big thing today in programming. 

I am upgrading to the wallet that was just released and will get it synced.

Sounds good.
You can always try to create an altar on the new version; and I look forward to our UX project.

191

Active Discussions / Re: June 2024 (Q2) - Babylon Falling Release

« on: August 18, 2024, 03:19:56 PM »

Anyone who wants to test RDP, lets continue testing this feature:

https://wiki.biblepay.org/RDP

The feature is part of the MainNet wallet.

Please launch it from there and comment here.

192

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: August 18, 2024, 03:18:19 PM »

The new wallet comes with BiblePay RDP, a feature that allows you to Remote Desktop (RDP) from one machine to another through a sanctuary.

You can read about it here:

https://wiki.biblepay.org/RDP

Lets talk about it in the TestNet thread, here:

https://forum.biblepay.org/index.php?topic=967.new#new

193

BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

« on: August 17, 2024, 07:30:37 PM »

BIBLEPAY v0.21.3
Mandatory Upgrade
For entire network including Sancs
Cutover Height: 526500
Release URL:
https://github.com/biblepay/biblepay/releases/tag/v0.21.3
https://www.biblepay.org/wallet/
Source code:
https://github.com/biblepay/biblepay/
Self build guide:
https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt

Note: Because we missed a few critical versions of Dash over the last year and the format of the Sanctuary record has changed, we will need to recreate our sancs.
Sorry for the inconvenience.

To get a safe start, I have recreated 3 of my sancs already and therefore the LLMQ's will be forming over the next 24 hours (that will allow instantsend and chainlocks to re-enable ~Aug 18th or so).

IMPORTANT:  Once you upgrade, be sure to restart with -reindex=1 if you have any trouble syncing to the latest block height.
Reference hash and height:
getblockhash 524382
hash: 000005b1821c81863ff01d949aa6efe35d03d72e6bea18fb1280ca722d4f7bb4

Block Explorer (Chainz) has upgraded:
https://chainz.cryptoid.info/bbp/


Good luck, and God Bless You.

PS As usual, you can create an altar, sanc or temple to become a sanctuary miner (and this puts your latent BBP to use giving you earnings).

194

Active Discussions / Re: June 2024 (Q2) - Babylon Falling Release

« on: August 14, 2024, 08:59:53 PM »

Looks like testing passed.

Thanks to all who helped test the wallet.

195

Active Discussions / Re: June 2024 (Q2) - Babylon Falling Release

« on: August 10, 2024, 05:06:48 AM »

So I created a Temple, and received payment and it is working as intended.
In my prior wave I created an altar and it is also receiving the correct amounts.

Wallet testing is coming to a close.

However I have a really positive surprise for this release that Im on the final stretch on.
We have something additional called BiblePay Extensions.
This menu option gets included with the new EXE, and it allows our development team to release BBP "Modules" or extensions that extend the code base.
These get upgraded automatically when versions change (due to bugs found in the extensions and feature releases in the extensions).

The first actual extension or use case is RDP.  This allows you to RDP from your work to your BBP machine or your BBP machine to work etc (actually its BBP machine to BBP machine).
One real use case for the BBP network to send the traffic through a sanctuary and back to your desktop.
The traffic is encrypted and private and the sanctuary cannot see it either because of the encryption and the keys.
It uses the BBP keypair as an "RDP address" to connect to etc.

Ill get this final leg finished and let you all know when we can test RDP 1.0 and BBP Extensions.