Bible Pay

Recent Posts

Pages: [1] 2 3 4 5 6 7 8 ... 10
BiblePay - TestNet upgrade for TestNet

- Add checkpoint @ 5000 to enforce new testnet chain
- Make enforcement of sanctuary port # configurable.  Set sanctuary port enforcement to OFF (false).  This allows us to test creation of new sancs on non-standard ports in both Mainnet & Testnet.
- Implement Sanctuary Raise (from 25% to 35%) and GSC budget reduction to 25% from 30% ( @ block 8400 in testnet & TBD in MainNet
- Merge Prod changes into Develop up to
- Switch TestNet to 7 minute blocks (1 min blocks up to block 5000 to get us started quickly)
- Change chainparams to enable deterministic DIPS at block 5000, QT at 5000, ABN at 5000, however DIP3 enforcement is set at block 8400 (this gives us 3400 blocks to set up deterministic sancs after block 5000); we must have 3 sanc LLMQ quorums after 8400
- Added Chinese bible reader to QT
- Added exec masterclock RPC command
- Added masternode genkey legacy command for Apollon - to help support deterministic sancs in this branch

We are on block 5500~ or so.

Production Proposals / October payment for Kairos Childrens Fund
« Last post by AndrewScribner on Today at 06:12:35 am »
Kairos Children's Fund is a small sponsorship organization. We are a charity in the Philippines helping children to get a good education, knowing that this is the best way to help them climb out of poverty.

Go to our website to learn more about KCF. You can download our brochure and form here (

Pictures of the Biblepay Kids:

We also encourage sponsors who will want to develop a relationship with their scholar and desire to encourage them throughout their education.
I am requesting 763,258BBP, which at the current rate is $350 (as of Sept 22). This will cover the monthly expenses for 9 children, as well as allow them to pay school fees. We will also be giving their families rice during the quarterly assembly.
11B   Helena NARCISO1 - EL $20
14B   Princess CABUGNASAN4 - EL $20
12B   Tajana Veroso5 - EL $20
13B  Pepe Gabriel12 - SHS $25
16B   Earl Darren Chiu5 - EL $20
Rowena Paladar11 - SHS $25
12B   Dante Balansag10 - HS $23
10B   Jovelyn Cadusale11 - SHS $25
17B   Kate Rebutazo10 - HS $25
These 13 children have been placed under Biblepay but they are paid up until the year.

22SE19   Lorenzo Paladar  -  paid through 2019
23SE19   Brent Aaron Cresencio  -  paid through 2019
24SE19   Rhyejiam Cielo Alqiza  -  paid through 2019
25SE19   John Gabriel  -  paid through 2019
26SE19   Elijah Boladola  -  paid through 2019
27SE19   Eda Mae Omotong  -  paid through 2019
28SE19   Shane Marie Francisco  -  paid through 2019
29SE19   Wendy Domik  -  paid through 2019
30SE19   Jill Jangin  -  paid through 2019
31SE19   Ruth Alos  -  paid through 2019
32SE19   Angel Ozoa  -  paid through 2019
33SE19   John Dave Rendal  -  paid through 2019
34SE19   Diana Deguit -  paid through 2019

Production Proposals / Re: Remove Port Restriction on Hosted Sanctuaries
« Last post by sunk818 on September 21, 2019, 04:11:26 pm »
It is certainly cheaper because of consolidating nodes onto one server. You can rent one beefy server (hetzner, scaleway) and not have to pay for multiple IPs per month. Downside is that is a potential DDoS attack or network route going down will take all the sanctuaries (masternodes) offline. With (B) IPFS, having all nodes on the same server would be risky since one server or network down means all the IPFS nodes go offline.

Production Proposals / September Payroll (May 2019)
« Last post by Rob Andrews on September 21, 2019, 10:16:11 am »
Commits on May 31, 2019
OneClickSanctuary EVO instructions

masternode setup script for Evo Upgrade

biblepay committed on May 31
Commits on May 27, 2019 Upgrade

biblepay committed on May 27 Upgrade

biblepay committed on May 27 Upgrade

biblepay committed on May 27
Commits on May 20, 2019 - Evo RC6 - fix for MacOS compile

Commits on May 19, 2019 - Evo RC6

biblepay committed on May 19
Commits on May 18, 2019 RC5

biblepay committed on May 18
Commits on May 17, 2019 RC4

biblepay committed on May 17 RC3

biblepay committed on May 17 RC2

biblepay committed on May 17 RC1

biblepay committed on May 17
 Commits on May 7, 2019 upgrade for TestNet

biblepay committed on May 7 upgrade for TestNet

biblepay committed on May 7
Commits on May 4, 2019 Upgrade for TestNet

biblepay committed on May 4
Commits on May 3, 2019 Upgrade for TestNet

biblepay committed on May 3 Upgrade for TestNet

biblepay committed on May 3
Merge branch 'master' into develop

MIP committed on May 3
Commits on May 2, 2019 Upgrade for TestNet

biblepay committed on May 2

Capping at 1.25 MM

Thank you. Initially, the testnet sancs were enabled even when the entire VPS was off for extended periods of time; now when they temporarily drop connection, all of the sancs appear to be banned and none appear to gave recovered without intervention.

 sanc count
  "total": 6,
  "enabled": 0

Am I on the same chain as you, as all the sancs on this testnet chain appear banned?

So I was working on reviving my testnet nodes, and I agree, they all look banned.  The only reason I see 2 non-banned, is the local GUI on one of my banned sancs still has the old list. 

Anyway, I would like to notify everyone of this command.  I believe this is the command we need to unban a deterministic sanc without recreating it:

protx update_service proTxHash newIP:new_port masternodeblsprivKey

You can actually get all this info from the banned sanc itself (you can type masternode status, and get the IP, port, and original proTx hash, and you can get the blsPrivKey from the biblepay.conf on the sanc).  On a side note, if you want to do this from the controller, you can get the IP, port, blsPrivKey, and ProTxHash from the deterministic.conf.  So either should work to unban the node.  This command is also the one we use to Update an IP address for a non-banned sanc.

So, looking at the state of affairs, the reason the rest of the sancs are banned is because we failed to make the LLMQs correctly (with no minimum quorums).  The chain was in sync on 2 of my 3, so I believe we "would have" stayed in sync if we didnt lose the supermajority of our sancs.

Since MIP shut his down, and Oncoas is down, and mine need revived, I think we should take this opportunity to reset the testnet chain.
Primarily because I dont like the "666" trash that some joker transmitted, and of course, because we have 200,000 empty testnet blocks (therefore its harder to manage when we are away).

I think it would be best for us to slow the chain down to prod length blocks, and reset it and have us re-create our sancs at this point.

So in light of this please wait until the next version - it will need to be a mandatory upgrade (for testnet).

Thanks everyone for what you have already done!

Active Discussions / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)
« Last post by sunk818 on September 17, 2019, 05:17:19 pm »
The 20% POBH would be a standard calculation (692,193 * .20 = 138,438) per day.

Hi Rob - Can you clarify something for me? When a block is mined, the split between miner and sanctuary is split evenly. The amount that is split varies based (I think) on the difficulty set by Dark Gravity Wave (DGW) algorithm. So, your figure of 692,193 comes from a fixed difficulty value of some sort? I would think the PoBH and Sanctuary split will adhere to their respective percentages, but amount being split is not a fixed known is it?

I had considered that with ABN (anti bot net) being so successful, if you've considered making mined block values to be fixed or to dwindle on a fixed schedule of some sort like Bitcoin. It feels like to me that the economics breakdown is easier to project without the difficulty variable. Easier to market, easier to predict BBP earnings, and you don't have to change documentation as often.
Dear Rob,

Based on published data Ref:
And the approx current output, I have calculated the approx BBP allocation based on current QT, can you please confirm? Thank you.

Planned emission   

                %                BBP
Total monthly    51,914,467.00
Per day                  1,730,482.23
Curr QT    0.6        1,038,289.34

Sanc          0.25         259,572.34
PoBHv2    0.25         259,572.34
SB(?)         0.10         103,828.93
GSC           0.40          415,315.74

GSC breakdown:
POG            0.475     197,274.97
POOM        0.475     197,274.97
HEALING    0.050      20,765.79

Hi Oncoapop,

You almost have it perfectly right. 

Total monthly    51,914,467.00
Per day                  1,730,482.23
Curr QT    0.6        1,038,289.34

This is right, since we have 1.7MM per day emissions in 2019, with a QT level of 60%, that means we are emitting 692,193 per day (roughly) right now, yes.

On the block distribution, we recently had this change:

Changing it to :

20% - Charity and Governance (this is our 10% to orphan-charity + 10% to IT/PR/P2P/etc)
25% - GSC (this is for POG + Healing + Poom)
35% - Sanctuary budget  (This is currently 25% as you stated above but changes to 35% on our next mandatory upgrade)
20% - POBH/Security (This is for POBH Heat mining)

On the GSC breakdown:
Yes, 47.5% for POG, POOM=47.5%, and healing .05%, yes exactly.

So this means on a given day:

Total Gross emissions before QT = 1.7MM, minus 60% QT equals a gross daily emission of 692,193. 
Out of this (692,193 * 35%) 242,267 would go to the sanctuary in the future.

On the GSC, we actually will escrow 45% per block in advance - to cover the monthly and daily GSC budget - but pay out about 330K per day (total) for GSC - this is because the single monthly payment is only once but 330K is paid daily.  The 330K daily plus the monthly superblock amount equals the 45% per block escrow amount.

The 20% POBH would be a standard calculation (692,193 * .20 = 138,438) per day.

Production Proposals / Re: Remove Port Restriction on Hosted Sanctuaries
« Last post by inblue on September 16, 2019, 03:00:59 pm »
I support this. Another positive reason is less time spent on configuring and watching multiple servers.
Production Proposals / Remove Port Restriction on Hosted Sanctuaries
« Last post by Rob Andrews on September 15, 2019, 01:31:18 pm »
So this idea is spearheaded by Apollon and I also have heard of this idea from TheSnat before.

The idea is to remove the port restriction on sactuaries, and allow the sanc to be hosted from any port number.

Technically, we know this will work because XAP and BlockLogic (BLTG) are doing it already.

(The port restriction is this:  Dash must run on port 9999 only and if a user hosts from other than 9999, the Masternode will be rejected from the network.  For BiblePay they must run on port 40000).

Dash put the port restriction in to be more corporate friendly for Network Admins - IE - they wanted network admins to know that if port 9999 is to be open, its specifically for Dash traffic.

Initially I was slightly against the idea, when I imagined we would have one sanc per user, I figured each of us could afford the $5 hosting fee per month.

However, as we evolved I have seen another side to this situation:  During downward price spirals some of our users who are cost concious would like to run more than one sanc on a hosted VPS.  From my perspective, I changed my mind to neutral when I experienced a very bad service level with one of my last sanc hosts (not vultr), and I had to hurry and switch to Apollon (thank God they were available at the time).  What Im alluding to is, if removing the port restriction would have given me for example a path to create more instances per vultr node for example, it might have been a life saver.  (I dont mean financially for me, I mean for the sake of the GSC contracts being voted on by my nodes).

In light of this I've become neutral.  I obviously want high performance per node.

Please provide any opinions on this idea, if this will be a terrible move for some reason.

As far as Apollons perspective, they are in business to make money.  I realize our partners need to be healthy and make a profit, and if we lose our partners, we lose our ability to host sancs.  Lets think of this from all angles.

Possible Positive reason:
If less BBP is spent on hosting less is liquidated on the exchange for hosting fees to be paid

Possible Negative reason:
Will we look weak and fragile if we allow this?

Does anyone understand this problem?

I believe we have determined your coin-age was the problem via PM but I cant quite remember  --   Has this been resolved now?

I think you just need more BBP in your wallet :(.

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