Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rob Andrews

Pages: [1] 2 3 4 5 6 7 8 ... 259
Thank you for that. Looks okay.

The temple appears to be receiving 16,830 bbp for when it is ENABLED but if for some reason they are out of sync, their payment is not halved but appears to be only 841 bbp (ie half a sanctuary's). Is this expected and correct behaviour?

Since the temple is the only BBP wallet running on the server, we have no way of knowing when it is out of sync, At least if there were 10 sancs as a temple, I could calculate the consensus and reset the lagging sancs. The only that we know a temple may be lagging if it fails to receive the full payment amount.

Thank you for looking into this.

So far the network appears to be more stable, now that we have kicked off older sancs that are years old on any protocol version.  The LLMQs are 90% correct now, but there are still two weird sancs in there that I have no idea if they are mischevious or not, will need to dig into that.  But for now since the quorum has an 80% good consensus, DM IX has restarted and DM Chainlocks have restarted, all Glory to God.  Now we are waiting for SX to upgrade; I notified them.

To determine if your sanc is in sync, I would prefer using chainz to any internal script anyway:

Regarding being docked 50%, that happens if the other nodes cant see your sanc.  Try verifying you can telnet to the port from another machine to your external address.
Also, if you do not agree with chainz, do a ./biblepayd -erasechain=1 to start on solid ground as you might have started after the mandatory on your own chain.


BiblePay - - Mandatory Upgrade for Entire Network

- Added checkpoint @ 440K
- Filter out misbehaving sanc peers in LLMQ for one duration
- Prevent division by zero in LLMQ class
- Require Sancs to be on protoversion >= 70790
- Enable ReviveSanctuaries batch job for Altars and Sancs but not Temples
- Edit release name to be 'Latter Rain'

Github Release:

Hey All,

A bug has been found in the newest release and since our exchanges have not upgraded yet, I am re-releasing tonight.

Thank you all for your understanding.

Production Proposals / September 2023 Orphan Expenses - Cameroon One
« on: September 24, 2023, 06:33:28 AM »
We currently sponsor 35 orphans from cameroon-one, and this proposal is for the primary payment to cameroon-one.

I am seeking 7MM bbp (approx $600) covering a high proportion of the orphans (we pay $40 per month for each orphan). 

Payout going directly to cameroon-one: BF6qmwBMmnmb4FbSmRGTeWQL1m3rwh5n7b

BiblePay - - Mandatory Upgrade for Entire Network

Cutover Height : 449485

- We now have Dynamically Sized Sancs (Temple,Sanctuary,Altar)
- LLMQ Quorums now work with Temples to maximize reliability of chainlocks
- Masternodelist returns the Tribe of the Temple
- Ensure governance monthly emission amount is correct per schedule
- Passive Sancs still get 50% reward due to being POSE banned


You can now create an Altar (455,001), Sanctuary (4,500,001) or a Temple (45,000,001).
Use the existing documentation for creating a sanctuary; then execute 'exec upgradesanc sancname' and your new sanctuary should register.
Be sure to do this after the cutover height.

Active Discussions / Re: Nov 2023 - Latter Rain Release
« on: September 23, 2023, 02:34:21 PM »
Verify Temple coins are Locked and Altar coins are locked in Coin Control: PASS
Verify Instantsend Quorums Work now : PASS
(Sent 555 to myself and saw the lightning bolt!)  Temples are keeping the quorum!

Active Discussions / Re: Nov 2023 - Latter Rain Release
« on: September 23, 2023, 02:29:11 PM »

Verify getgovernanceinfo returns the correct monthly superblock amount:  PASS
Verify we can create a Temple and fund it and that it registers after LATTER_RAIN_HEIGHT: PASS
Verify Block Reward on Temple is 10* amount: PASS
Verify block reward on Altar is 10% of the amount: PASS
Verify block reward on Sanc still the same: PASS
Verify Passive sancs still get docked 50%: PASS
Verify only Temples participate in LLMQ Quorums: PASS
Verify the quorum Forms: PASS
(I looked at each of my 3 temples and they each had 2 connections) and the quorum is in phase 6.
Verify masternodelist shows the Temple Tribe: PASS

Active Discussions / Re: Nov 2023 - Latter Rain Release
« on: September 23, 2023, 02:18:19 PM »
Dear Rob,

Oncoapop reporting :

getblockhash 192206


testnet wallet.dat backed up


Great!  Looks like you are synced.

I actually had one bug fix I have to release to testnet.
But since we are having prod problems, Im going to go ahead and test these changes right now, so we can have a faster testnet release (blocks are lagging on Chainz, and SouthXChange has stopped).  In light of that I think we need an emergency prod release today.

Active Discussions / BiblePay Dynamic Sanctuaries
« on: September 18, 2023, 05:08:42 PM »

Our wallet gives you the ability to choose the size of the sanctuary you can afford.  Choose between Altar (455,001 collateral), Sanctuary (4,500,001 collateral), or Temple (45,000,001 collateral).

This gives you the ability to participate in BBP rewards no matter what your budget is: small, medium or large.
The Altar pays at a rate of 10%, the Sanctuary 100%, and the Temple at 1000% of the block reward rate.

You can run your sanctuary in Active or Passive mode.

For active sanctuaries you will receive a 100% reward, while passive sanctuaries receive a 50% reward.
Passive sanctuaries are a good place for people to lock latent BBP funds to earn a reward.
Each sanctuary automatically mines blocks, and only sanctuaries may mine on the BBP network, giving the sanctuary both the mining reward plus the Sanctuary reward.

Sanctuaries perform important functions such as Instant Send Locking (facilitating instant transactions), Chainlocks (preventing 51% attacks), Governance proposal payments, LLMQ Quorums, and they even provide blocks for our network creating a strong backbone for the BBP network.

With deterministic sanctuaries, all payments are stored in an orderly fashion, in an ordered list on chain and paid round robin in order. 

This feature accomplishes a truly decentralized sanctuary network that latent funds can be stored in a safe way, since its Your Key, Your Funds.

I'm excited about this feature for the future of BBP.  This has the potential to attract thousands of users that gave up on mining because of monopolies stealing their hashpower, and also crypto enthusiasts who believe in the future investment power of crypto as an alternative to conventional banking to store latent BBP.

Active Discussions / Re: Nov 2023 - Latter Rain Release
« on: September 18, 2023, 04:52:52 PM »
Hey Oncoapop, I know you wanted to participate.
Once you get synced up in testnet let me know that you passed the blockhash check.

If you want to start up a temple, let me know your recv address and Ill send you 50MM, but please note, if you could definitely keep the funds available for us for the future because we have limited funds available in testnet total (we may need them back for something later).

In the mean time, feel free to fire up an Altar in investor only mode and see if it gets 1/10th the payment?
You should be past the cutover height by now.

Hey All,
Whoever wants to participate in our next testnet release, please check it out here:

Active Discussions / Re: Nov 2023 - Latter Rain Release
« on: September 17, 2023, 06:51:31 PM »
Here's a good testnet block hash after the cutover height:

getblockhash 192206


Active Discussions / Nov 2023 - Latter Rain Release
« on: September 17, 2023, 04:29:40 PM »

November 2023 Release - Latter Rain

Welcome to TestNet - Latter Rain!

Testing Starts: September 18th, 2023
Testing Ends: November 1, 2023

In this thread we will be testing:

- New sanctuary sizes (Altar, Sanctuary, Temple) with collateral amounts (455,001, 4,500,001, and 45,000,001) and corresponding payments of (10%, 100%, 1000%)
  a. Verify each size of sanc can register properly and appear in the deterministic masternode list
  b. Verify the payment amount on each sanc
  c. Verify the chain can sync from 0 after we solve some temple blocks
- Verify the monthly superblock still works and emits and is the correct amount
- Our background batch job has been retired (ReviveSanctuaries); this is because now investors should not interfere with LLMQ quorums
- Verify Quorums form for Temples only (this increases the reliability for Chainlocks)
- Verify Temple and Altar coins in wallet lock in coin control and require an unlock (like regular sancs) so they dont get spent by accident
- Verify inactive sanctuaries (IE investor nodes) receive 50%
- Verify masternodelist shows the Tribe for a Temple
- This release includes a fix in RX miner to sleep after solving a block in MAINNET to attempt to prevent the CLSIG (Chainlock) lagging block scenario
- Cutover height 192200

Explain Changes to Entire BiblePay Network:   

- Explanation of the Sanc sizes and benefits:

- Explain usage instructions

Wiki Articles:

Older - Create a Sanc:

Starting Version:

(Please ensure your version is greater than this, in order to sync.  See post #2 for current hash.

Testnet Download Links:

     Windows 64-bit:
     Linux 64 bits II (QT/biblepayd/biblepay-cli) zip:

NOT READY (ask before trying):
     (Inquire first before downloading) MacOS QT:

To self compile:
git pull origin develop


Create a biblepaytest.conf file with the following contents:

Place the file in ~/.biblepay

Start testnet by typing:
./biblepay-qt -conf=biblepaytest.conf

(Note the blocks and chainstate will sync into the ./biblepay/testnet3 folder.

NOTE: If you only have one machine, you can run in testnet side by side a prod node.

To create a TestNet Sanctuary:


                                                                   OUR BIBLEPAY CORE TESTERS

#1 - Oncoapop

#2 -

#3 - Rob Andrews

#4 -

** Update for Mining Sanctuaries that have Lagging Blocks **

So I've been pulling my hair out trying to find out why 'sometimes' (and this also was reported by Oncoapop recently) out of 10 nodes in a Temple, 1 or 2 will start lagging behind on the block count and eventually they need restarted with -erasechain=1 (that was the recommended current solution at least).

Today I finally got the raw logs from one sanc that was doing that and I found part of the root cause:
2023-09-15T23:47:39Z CChainLocksHandler::EnforceBestChainLock -- CLSIG (CChainLockSig(nHeight=447722, blockHash=b6202fdf5ffdf1b315577a2d4ab53f141212f2b8652b7aaff426d781c956bff9)) marked block 494b4e05928fd613d1d831c40fbeb3c2af0044333e793c5ae09e15fbfcddc91e as conflicting
2023-09-15T23:47:39Z ConflictingChainFound: conflicting block=494b4e05928fd613d1d831c40fbeb3c2af0044333e793c5ae09e15fbfcddc91e  height=447720  log2_work=60.28583982  date=2023-09-15T23:40:31Z
2023-09-15T23:47:39Z ConflictingChainFound:  current best=dd261ab9c7215d3e4acde9d8b4fa2e24c7dccd822b294734798b8f406220b81d  height=447717  log2_work=60.28583982  date=2023-09-15T23:25:08Z
2023-09-15T23:47:39Z CChainLocksHandler::EnforceBestChainLock -- CLSIG (CChainLockSig(nHeight=447722, blockHash=b6202fdf5ffdf1b315577a2d4ab53f141212f2b8652b7aaff426d781c956bff9)) marked block 494b4e05928fd613d1d831c40fbeb3c2af0044333e793c5ae09e15fbfcddc91e as conflicting

In llmq for chainlocks we go round robin around all the sancs and form quorums.  When the chainlocks is Active, blocks must be enforced by the whole quorum for the best chain.  Now we have a unique scenario where the actual sancs are mining also.  So if a sanc finds two blocks in a row, I believe quicker than those can be locked by the rest of the network, while another sanc solves a block at the same height that gets locked before the first sanc, it ends up in an internal conflicting state (its pindex status for the conflicting blocks keep getting stored in memory as a conflict and does not get updated).  The real question is why does it not reorganize when the main chain grows larger (the chainlocked chain).  That part is still is not solved.

But I have a partial solution for now:

If this happens to your node, you can simply stop it with './biblepay-cli -conf=/configs/yournodenumber.conf stop\r\n./biblepayd -conf=/configs/yournodenumber.conf &' to stop and start the node, and when it restarts, the conflicting block will be purged from ram and it will sync to the tip (which is a big relief because I did not want to recommend resyncing the chain in this case as that gets old pretty quick).

I will keep looking into the root cause to see if we can make the node recover when this happens.

Pages: [1] 2 3 4 5 6 7 8 ... 259