Messages

151

Active Discussions / BIBLEPAY - DOGE DECENTRALIZED EXCHANGE

« on: January 06, 2025, 01:08:46 PM »

This is our TestNet thread for our new BBP - DOGE Decentralized Exchange!

Welcome!

Please sign up here if you can help us test the feature.


Wallet download:

https://biblepay.org/wallet

Or

Self Build:  https://github.com/biblepay/biblepay/commit/2ba1eb9386960e0749f1cab64414019cc2502fea

Or

Direct link to win64:
https://biblepay.org/biblepay-win64.exe

152

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

« on: December 30, 2024, 06:02:30 PM »

Hi Rob and Happy (belated) Christmas
I haven't posted in a while but still checking in from time to time.
Sorry to see that BBP still has no listing on any exchanges.
An idea came to me - not sure how feasible that would be - but here goes :

XRP ledger has a built-in dex (see XRPmarket and Sologenic)
So would it be possible to convert BBP to an XRP ledger token and have it trade on the XRP range of DEX's.
Best wishes.
PM

Hey Mr. D, nice to see you back and Merry Christmas to you too!

Yes, this is a horrible debacle to go through with Bololex, absolutely.  I am not making an unfounded accusation, but thinking worst case possible, the crypto price appreciation lately would have caused quite an increase in value in their wallets, and maybe they took off with the funds.  On the bright side if that happened I am glad not to be associated with any exchange that is "puny" or "unethical".  If so, I lost 10MM bbp myself so hopefully others realize they are not alone on this.  (I almost withdrew half the other week but forgot).

So, I have looked into XRPs ledger and that is cool, however there are some issues with it that are very long to go into here that make it very hard to create the market making oracle.  Id have to pull up the thread I have offline to explain all that.  There was also an SEC consideration.  It affects both using the ledger for XRP and XLM (both coins that I love, btw).  Ill check out that thread and see what the block is asap. 

But in the mean time, I have some good news, we may actually turn this situation into a positive.

I believe I can write the first in-wallet DOGE exchange inside the BBP wallet.  Basically, what we will do is have the wallet generate a DOGE address when it boots (DOGE-TRADING), and allow users to deposit DOGE into the BBP chain.  We can create an atomic transaction that will execute only if the BBP from the Seller has sent the special TX on chain and the DOGE is verified in a block.  Otherwise the BBP will not get mined by a sanc (yes, I know we can enforce this because Ive been studying the code).  We can have an orderbook with limit buy/sells in the RPC, and let people place trades right in the wallet (limit orders).  When they match, they generate atomic transactions.  This will be completely decentralized.

If DOGE is not sent by the rogue wallet, the BBP atomic TX will not mine (meaning the Seller did not lose any funds).
If the DOGE is sent by a good wallet and the Rogue bbp user does not send the bbp atomic TX, it will not be in the memory pool with an IS lock, therefore the DOGE will not actually be sent by the other wallet.
This can all be automated too with the matching process, so no work is actually done by the user.

The amazing thing about this is then we would be listed on every exchange in the world where DOGE is listed, so liquidity would be unlimited.

However, before putting on rose colored glasses, we are still limited by the number of users using the core wallet and actually trading.
But it would be a good use case for BBP (first wallet to have built in exchange).

It would also be good to talk about on the BTCTalk DOGE thread for new DOGE users to come onboard.

Thoughts community?

153

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

« on: December 25, 2024, 11:39:00 AM »

On the side chain and document storage and decentralized database:
We still have a conduit to store all of our BBP documents (IE prophecy videos, images of Foundation activity such as childrens letters and wells, images of NFTs, and all of the user stored documents) on STORJ, which works.  We have a working sanctuary feature, where we can charge a rental fee for documents that are stored on the BBP chain as metadata (which points to the Storj bytes that store the image or doc), can be billed to the user monthly automatically.  All that works.
NFTs are decentralized now.  Yes, the marketplace needs re-released on unchained, but it works again (working on that release currently) which allows you to edit your Native BBP NFTs and mark them as marketable, etc.

A story about CockroachDB and PerconaDB.
CockroachDB was "close".  We almost used cockroachdb to be our decentralized database to store BBP sidechain data.  However in the end, the problem with cockroachdb was it could be made to be fragile by nefarious Temples.  I went through a set of steps that could take it down and put it in a corrupt state by manipulating my timestamps and once a new temple comes on and syncs, if there is a minority of temples (IE their algorithm does not work like bitcoin supermajority rules), the whole cluster comes down.  That in itself is not a problem, however rebuilding the cluster is just too much work for an amateur (the user would need to be at the shell for hours to get the node back up).  I finally gave up on cockroachdb (and percona previously).  I decided we have to have our own decentralized db that is fault tolerant for even dummies (IE it just self heals under all conditions).  So we do have BBPDB 1.0 now and it is running on one Sanc, and now we need this whole release cycle so that unchained honors BBPDB, and all of our data (think Orphan  expenses, fundraising revenue, sidechain metadata, User records, everything that lives in Cockroach) is being migrated to BBPDB.  This BBPDB is 100% decentralized!  Note that I will not even be required after this is fully deployed in 2025!  So that is exciting for our future as well.

Regarding social media, I feel like social.biblepay.org was excellent and we are actually missing something.
Some of the features I would like BBP to thrive on is:
- An enhanced user friendly prayer room that is "fun" to use.  I think our current attempts at this were "drab".
- A social media system that is chain based.
- A Prophecy room where we can take modern day prophets, like Amanda Grace, Julie Green, Elijah Streams prophets, etc, and make rooms for them.  We can sync their open source content to our prophet rooms.  We can add new prophecies in real time.
- A "salvation Dashboard".  This allows you to keep track of salvations of your freinds, that you are working on.  Think current Status.  History of entries.

A cryptocurrency index that is an investment vehicle for BBP that is "your keys your money".
This is novel, because all of our old attempts at this were not really decentralized.
We need to have volunteer market makers, one for each small upcoming and established crypto (my list is :  XRP, XLM, DOGE, BBP, BTC) as an example, and these market makers will be paid to "make a market" to run an AMM that will auto exchange XLM-BTC for example, but in a decentralized way.  What is the purpose.  If we had 4 market makers fro the above example (BBP not included), here is how this works:
New User A comes in and wants to buy $500 of the BBP CryptoIndex. (BBPCI).
When the trade is placed, 4 of the market makers execute $100 each of the above tickers and each of those result in the user receiving $100 of the native currency inside the *home wallet* private key.  Lets say you have a private key called "CPK".  The home wallet will derive private keys for these 5 currencies without the key material ever leaving your machine.  We can do that with a BBP extension.

So what this means in effect, a church comes in and buys $1000 of the index, and in their home wallet, they now 5 cryptos equally weighted (with $200 being in BBP) held in their own *private key* that never left the wallet.  This is totally decentralized.  I really feel we can make this market making happen by offering sanctuaries a reward to be a market maker.  It can look something like this:
Lets say you run sanctuary #1 and want to be an XRP market maker. The requirement is you deposit $1000 of XRP in your sanctuary private key and $1000 of BBP in your sanctuary private key.  Whenever a customer buys the index, you receive a market making fee of say 1% (or whatever the free market dictates to make this happen).  If they Bought BBP, you now have $100 more of BBP and $100 less of XRP, but you have $10 more of BBP as the reward for market making.  Something like that.  The algorithm in the BBP wallet would automatically AMM the trade so you dont have to actually do anything except replenish your balances when they get low.  Say XRP draws down to $100, then you need to sell BBP on the exchange and buy XRP on the exhchage to get these back to $1000 so our index stays in business. 

From the user standpoint they get a decentralized index that offers crypto exposure into the future, legally without us needing to be a hedge fund.  So its useful to churches and our users.  Who have Fiat to protect, they can invest in the BBP index.  And its useful for people who want one click crypto exposure and we do the rest.  They just come in once every 90 days and buy $5k more.  And their balance is safe because its "their key their money", its stored in their home wallet and the key never leaves the machine.

154

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

« on: December 25, 2024, 10:20:19 AM »

Since it is Christmas, and Merry Christmas to everyone as we celebrate Jesus Birth!

Lets talk about Biblepay, where we are and where we can go in 2025-2026.  I am actively writing the roadmap backing doc so we will have more details very soon also but in the mean time lets discuss RDP, sidechains, gospel features, social media, and the move to be 100% decentralized in one year.

First RDP.  The use case is this:  Some people have dynamic IPs, some are behind firewalls and some do not want to configure their network to allow traffic in on certain ports that would allow RDP (IE the ability for you to remote into your PC and control it, or into your work machine, or into your server and control it).

This is where the BBP network comes in.  Using OpenZiti technology we can create a BiblePay mesh network that will allow you to remote in to your PC even without opening the extenal port 3389, and without having a public IP.  And what is exciting is this is decentralized.

Before discussing the RDP tech, lets talk about how the software runs.  We have something called BBP Extensions, that can be launched from the wallet.  This is a list of BiblePay programs that can run on your machine, and as they are enhanced, the extensions automatically upgrade themselves.  So when you launch BBP Extensions, you really see a list of programs that we wrote that do specific functions and as releases occur they upgrade themselves.

One of the programs is BBPRDP.

In this case when you launch BBPRDP, the program will create a BBP keypair, one that designates the machines public network address (the BBP pubkey).  The private key is used to generate the public key and to store cold wallet funds for the service (currently the service is free, but we can do a pay-as-you-go plan in the future if this takes off, IE a certain amount say $5 a month or depending on the bytes sent over the BBP network, per month for use).

You can then create a virtual network between two BBP addresses (you must own them both).  The bytes sent and received are encrypted, so there is no way for anyone on the network to see or decrypt those bytes (those are using the bbp account connected to the ziti overlay, which is private to you).

The machine guid and public and private key are stored on your own machine.  The connection records are stored on our sidechain (so that the remote host can see and accept connections created by you).  Once the network conduit is started, those bytes are encrypted and sent through one volunteer sanctuary (one of the temples) and delivered to your private network.

The latest release, Hamans-Hanging 0.21.9 now has BBPExtensions v1.26 in it.
Note this was just released today.  In order to use this software, please re-download the windows wallet from www.biblepay.org | Wallet.
Once you launch it you can then click "BBP Extensions" from the left menu.

Wiki Guide:
https://wiki.biblepay.org/RDP

155

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

« on: December 25, 2024, 09:01:28 AM »

One sanc is still not in the ENABLED State although local command `masternode status` shows READY and the hash checks out...

Anyway, that's for later.

Wishing Rob and everyone at Biblepay a very Happy and Blessed Christmas!

Blessings
oncoapop

Ok, I attached a screenshot of your sancs.
I see that all are good except the one running on 40000.
The issue on that one is when I telnet to it from my house it does not answer, hence the reason it stayed as investor.

You have a Merry Christmas also.

And please let me know if you are interested in testing the RDP feature.
This network underlay based on OpenZiti network technology is decentralized, thats why Im excited to integrate it into biblepay.

156

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

« on: December 23, 2024, 06:11:41 AM »

Just an update:
Chainz did upgrade their wallet and they are back up again:
https://chainz.cryptoid.info/bbp/

Their hash and height does agree with all my nodes (and their historical height to the one I posted a couple posts back).
Oncoapop just let me know if yours does not agree with Chainz now or if there is a new issue.

Does anyone want to test the new BBPRDP feature?  Its ready for release.
This allows you to RDP to your home PC from a remote PC (using the BBP network as the conduit).  It is similar to GoToMyPC.com, except as a BBP service.

PS I renotified Bololex to upgrade.

PSII: Great news, we must be doing something right.  If you do an instantsend of 7 transactions in a row, (you can do this by
sendtoaddress youraddress 1000) * 7, check out how 100% lock using IS now.  Also chainlocks are locking.  So we finally have a fully functional rebase and working wallet with sidechain capability.  There is a lot of other great news as well in the ecosystem, but I will finish the roadmap doc first.

157

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

« on: December 20, 2024, 01:20:34 PM »

Dear Rob,

Thank you for that tip!

I changed my port using the command "protx update_service <protx_hash> "<ip:new_port>" <operator_privkey>" as the proposed "exec upgradesanc sancNN" command gave the error "bad-protx-dup-key (code -1)" and chatGPT gave me the solution (which I shared!)

Thank you - my updated sanc appears to be ONLY ENABLED SANCTUARY on the BBP Blockchain at the moment! Time to update my other sancs...

Blessings
Oncoapop

Hi Oncoapop,

I do not see the same sanctuary view as you do.  On my end 50% of the regular sancs are up and 90% of the temples are up.

Please confirm that you have updated your sancs to the latest version?  V0.21.8 - Hamans Hanging II.  And your home node?


10:54:02
getblockhash 552842


10:54:02
0000013a9221fdd81e13939ffb22b2e7bc1ebb53ab6b8dc24ddd0bc77f588e1f


I do believe there is a problem on bololex and chainz however, probably due to the Sancs agreeing on the latest quorum rules.
I asked Chainz to reindex, and I sent the upgrade to bololex.

Can you please try stopping your sanc wallet, delete all files but wallet.dat and reindex from scratch? (This is different than a -reindex=1, I call it an erase chain).

I did confirm on two of my sancs, after an erasechain, I do agree with the hash above (IE nothing changed on my end before or after the erasechain, but it confirms the hash is correct as I agree on all my nodes, which is more than 6).

Note that 'revivesanctuary' should work, if you were synced.  The problem with protx update is it does not update the deterministic.conf file.

Have a good one,
Rob

158

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

« on: December 19, 2024, 01:51:24 PM »

Dear Ale,
Thanks for your question. I have them both behind NAT and also in a datacenter.

This is the one behind NAT.
$ cli masternode status
{
  "outpoint": "a164e846e4166e9a0ecf9cfc33bc4bdc4a5676f54e430c11af3e441ce3ce8193-0",
  "service": "108.180.46.33:41000",
  "proTxHash": "f64ce28c46d989035dc00e48fd5c2906050d20ad471b9ef7188d3fc32e3365a5",
  "type": "Regular",
  "collateralHash": "a164e846e4166e9a0ecf9cfc33bc4bdc4a5676f54e430c11af3e441ce3ce8193",
  "collateralIndex": 0,
  "dmnState": {
    "version": 2,
    "service": "108.180.46.33:41000",
    "registeredHeight": 551815,
    "lastPaidHeight": 552264,
    "consecutivePayments": 0,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": -1,
    "revocationReason": 0,
    "ownerAddress": "B6Ud6beY9gcLwXF6j5UXTrL81hdaHqr3kL",
    "votingAddress": "B6Ud6beY9gcLwXF6j5UXTrL81hdaHqr3kL",
    "payoutAddress": "BKcbU8zYxfHGfaytRowYQLkyVA1U2BDYx4",
    "pubKeyOperator": "a8aba6cd5915acb888c5b7c689808f015b1c417d7fa9edbf3042a1ee1168ba17446cfdb1f0b5492fcaf6924629d0081c"
  },
  "state": "READY",
  "status": "Ready"
}
To make this work, as an example, I needed to go to my router IP 108.180.46.33 (get this from whatsmyip.com) and map 41000 to an internal port 41000 in this case, on my internal server 192.168.1.16 (get this from ifconfig)

Add this to your biblepay.conf

externalip=108.180.46.33:41000
masternodeaddr=192.168.1.16:41000
port=41000
maxconnections=128
masternodeblsprivkey=......132b9d4ef47f91bdc7a692820e.....

Blessings
oncoapop

Hi Oncoapop,

I believe you have everything set up correctly, because I can telnet to your port 41000 from my house, and as you show above you have the masternode status returning successfully.

The issue is within our code, we have specific requirements for non-investors:
if (nPort == 40000 || (nPort >= 10000 && nPort <= 10100))
    fPortPassed=true;

The public port has to either be 40000 (Prod), or 10000-10100 in Prod.

If its not in our docs, I will add a todo to put that in asap.
Sorry for the inconvenience.

Once you recreate your sanc on one of those ports, it should switch to non investor.

On a side note, it is possible to edit your deterministic.conf and masternode.conf (both entries) with the new port number and do an 'exec upgradesanc sancNN' and that should also change your port number on chain.

Good luck,
Rob

159

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

« on: December 14, 2024, 08:46:56 AM »

Biblepay v0.21.8
Mandatory Upgrade - Cutover Height 555,000


- Make LLMQ quorums ignore investor nodes (more reliable quorums)

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

160

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

« on: December 14, 2024, 06:53:51 AM »

We will be having a mandatory upgrade in about 10 days (trying to give plenty of notice on this).

The primary driver is to finally seal up the LLMQ (Instantsend) - Quorums code to be fully operational.

A little back story on this.
We always had deterministic masternodes and LLMQs, since Dash released those.  However there is a mix of problems between the version we were on prior to the rebase and where we are today.

At one point, when we had the hybrid (non deterministic Sanc plus LLMQ bolted on), instantsend worked fine.
It was during the period where our sanctuary count decreased and people started to run Investor nodes, where the quorums started to be less reliable.
This caused instant send to revert to non deterministic rules (IE it worked, but it used Dashs legacy code and not LLMQs).
Dash eventually removed that code, which caused our LLMQs to switch between deterministic (IE pure LLMQ instantsend) and LLMQ being off (if a quorum wasnt active at that height).

To remove all the bore of this story, over the last 9 months of releases Ive been trying to ensure these are 100% reliable and always on.

Reason being is, instantsend and chainlocks are actually required for unchained.biblepay.org and our sidechain and for NFTs to work correctly (if you lose instantsend, the experience becomes severely bad for the user, simply because they buy an NFT and it takes 20 mins to lock the tx.  Meaning, they cant see the NFT on the screen for 20 mins.  (The rule prevails that says do not accept a tx in a block until at least 1 block has passed after it was mined).  For us, thats a minimum of 14 mins (7 min block times) which is not acceptable.

So finally, InstantSend is fixed.  Release will be out this weekend.

161

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.

162

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.

163

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%).

164

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.

165

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.