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 9 ... 137
Thank you for the advice.

All mine were still waiting for ProTx but when i added the port to the IP and restarted it immediately went to ready, so the port ( even if default 40001) is needed in the conf.

I’ll try a non standard port later tonight.

Well, I think it was the reboot that did it.  After poring through the code yesterday on that non default port stuff, the code uses the testnet default port if its missing the port #.

But more specifically in our case, I think what happens is we set up a sanctuary, we run it, and if the pro-tx is sent after the sanc boots, (I think) the sanc actually starts up and goes to enabled, but -- I could be wrong about this -- but I think the activeMasternodeInfo (this is the struct that displays its status) isnt actually updated until you reboot.

My big question on that will actually need an answer soon for apollon, because they want us to provision a deterministic sanctuary without asking them to reboot the node :).  So we will have to figure this out for sure soon.

Thank you for the tBBP - I have set up 2 DIP3 sancs.

Although they both appear to be enabled on the masternode list (and both receiving block rewards on consecutive blocks 5802,3), masternode status on both say
"status": "Waiting for ProTx to appear on-chain"

I struggled for quite a while in the set up as unlike previously, this time the VoteAdd must be the same as the OwnAdd.  As can be seen from my post (on Jul 31, 2019, for example, my last sancs had different addresses for both, as I set them up from scratch using the dash method.

Thank you also for the tip about the deletion of the SAN directory, the VPS are now mining without ABN.

I can see both of your sancs as enabled (however in the phase we are in, we arent in LLMQs yet, so they wont be pose banned anyway until after block 8400). Anyway when I right click on those I can see the Pro-tx.  Did your status ever update in the sancs themselves to Enabled?

I just created 3 sancs.  In my case, one of the three already went to enabled (in the masternode status in the sanc) with all of its info.  In the other 2, I also see waiting for pro-tx to appear on chain.  So Im going to leave mine like this and see if that changes later.

In my case, I used our upgradesanc command.  Heres how I created a deterministic using the legacy with upgrade method:
- Send 4,500,001 to myself using QT wallet
- Type masternode outputs - copy the TXID and ordinal
- Edit the controllers testnet3/masternode.conf file
- Past IP:Port MNP txid ordinal (in the file)
- Type 'upgradesanc sancname 0' .  Verify this will work.
- Type 'upgradesanc sancname 1'.  Copy the masternode bls priv key to the Sanc "biblepay.conf" file.  Also ensure the sanc has masternode=1 in it.
- Reboot the sanc so it uses the bls priv key.

On another note, Im testing an upcoming feature that will let Apollon host deterministic sancs, and let Apollon (or biblepay users) host sancs on nonstandard ports.
I wanted to see - do we need any code changes in testnet (or in the upgradesanc command) to support nonstandard ports.

So I did this:  In the sanctuary itself, in the biblepay.conf, add "port=nnnn" where nnnn is your non standard port #.  In my case I used 39998 (as you can see from the sanctuary list now).
Then in the masternode.conf file, I changed 40001 to 39998 (in my controller wallet).
I see our upgradesanc command did honor that without any changes, and - because we have recently merged in a change that allows nonstandard ports for pro-tx the tx was broadcast.

I was able to successfully create two more sancs on non standard ports.

So now you all should be able to see in the masternode list:  ports 40001, 39998, 39999.  Lets see if these nodes survive.

Starting testnet from scratch

cli getblockhash 5682

New address:

I cannot mine and accumulate tBBP due to ABN. Can you please send enough for setting up of Sancs if that’s required. Thank you.

Thats awesome you are firing up 5!  Thanks!  Yeah, Im firing up 3 sancs + 1 controller, so we should have most of the bases covered this time.

I sent something like 12 mil-13 mil I believe to you.


I forgot an important note for everyone; Oncoa can you please do this also;
please delete your SAN/prayers*.* files and restart (just delete the whole directory SAN if you want), and then you will see that ABN isn't required.

This is because in testnet, our sporks are cached (until they get replaced with a new value).  Since we restarted the chain, the wallet thinks its still in ABN required mode.

(ABN is currently not required in testnet).


Yes, our hashes match, great job!

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 / September Payroll (May 2019)
« 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!

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 / Remove Port Restriction on Hosted Sanctuaries
« 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 :(.

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

Hi Oncoapop,

I see people have been replying to this thread; sorry, I was relying on an email notification and I didnt get one this time.

Anyhoo - Ill start with POSE.  The reason you were not banned for the first 99% of releases (Except, our last 3 releases!), is because, this branch, the dash .14 deterministic branch - has a major change compared to our Prod (.13) branch.  This branch POSE bans based on LLMQ quorum enforcement.

So the partial answer is - up til the last 3 releases - we did not have that spork enabled.  So your sancs were free to do anything they wanted (be off, anything).  The prod branch (.13) works a different way - those guys are banned based on Masternode Pings.

Moving on to the last two releases - at the point when we enabled LLMQs:  We now need 3 sanctuaries Keeping track of the network quorums (these are 60 minute heartbeats written into mined blocks).  They appear to be very strict.  But we also have had a network in tatters in testnet.  Im half tempted to change the block time back to 7 mins and have us start over!  Since we generated 200,000 empty blocks LOL.

Ill get back on and address some of these other things asap.  Im trying to finish some things up with BMS so we can merge that into a testnet thread also.

Ill restart my sancs and check the chain asap, also.

I switched off mine in the Vultr VPS. I made a snapshot so maybe I can take it back again.

Apart from that, what else do you need from me to test?

We need to have a reliable network of sanctuaries online to test LLMQs and Chainlocks. 

I have the following machines on testnet but all my sancs have been pose banned so i need to reactivate them but this back-to-school week is a bit busy for me.

Thanks guys!

Yeah, one of my 3 was pose banned too.  I have been deliberately waiting to see if it revives by itself.

As the Dash-Evo code hints at an automatic revival process; but - when I read about people who were POSE banned, they generally recreate their nodes.  But that doesnt make too much sense to me, because there is a strict control on not being able to re-use the same IP.

I have one well known working method to undo a POSE ban - but its like using a cannon - you can spend the output and recreate the sanc using upgradesanc - and that is allowed - because the network sees it as spent and undoes the lock on it first - and allows recreation.

Before I recreate my third sanc, let me do some more expirimentation.

Let me know when our sancs have upgraded, because I would like to set the spork to slow the testnet chain down to keep the testnet chain from generating thousands of empty one minute blocks (causing longer sync times in the future).

I believe Im the only 2 sancs left; MIP & Oncoapop are you guys still participating?

Jaap said he would, but we havent heard back from him after that.  I havent seen Togo here either despite coming back on the payroll.

Let me know when our sancs have upgraded, because I would like to set the spork to slow the testnet chain down to keep the testnet chain from generating thousands of empty one minute blocks (causing longer sync times in the future).

30 - Mandatory Upgrade for TestNet

- Merge in Prod changes up to
- Merge in Reindex fix (MIP)
- Add feature to slow mining of empty blocks in TestNet only
- Add feature to upload nested folder into BIPFS
- Add transparent background image for windows toolbar

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