BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[MIP]

is this coin still only CPU mining ?

Yes: see "Heat Mining" section here:

https://wiki.biblepay.org/Quick_Start

[SEO_Account]

so jw if half the POG rewards that now go to POOM are basically burned coins until we reach peak POOM? or if there are only a few peopling using POOM do the coins go back to POG?

[afeno]

Hi BBP gurus,
What does it means the following errors in getmininginfo output:

Code:

  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "poolinfo5": "Internal ABN: Invalid 1567673794; ",
  "abninfo": "No block to mine...  Please wait... 1567673839; No block to mine...  Please wait... 1567673838; No block to mine...  Please wait... 1567673836; No block to mine.......................
  "gsc_errors": "low abn weight 0",
  "poolmining": false,
  "pool_url": "",
  "required_abn_weight": 125000

I have more than 125000 BBP in my wallet with enough age.

Any idea what the message means?

[bible_pay]

Hi BBP gurus,
What does it means the following errors in getmininginfo output:

Code:

  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "poolinfo5": "Internal ABN: Invalid 1567673794; ",
  "abninfo": "No block to mine...  Please wait... 1567673839; No block to mine...  Please wait... 1567673838; No block to mine...  Please wait... 1567673836; No block to mine.......................
  "gsc_errors": "low abn weight 0",
  "poolmining": false,
  "pool_url": "",
  "required_abn_weight": 125000

I have more than 125000 BBP in my wallet with enough age.

Any idea what the message means?

could you please paste 'exec createabn 125000' if it is still happening?
This sometimes happens if you recently spent your coin-age and the confirms are < 5 (see coin control depth of each UTXO).

[bible_pay]

so jw if half the POG rewards that now go to POOM are basically burned coins until we reach peak POOM? or if there are only a few peopling using POOM do the coins go back to POG?

Right now in this cameroon-one startup phase, the excess coins are not emitted (so like you say, in effect they are burned).

[MIP]

*** Cameroon-One Go-Live ***


We are proud to announce our partnership with Cameroon-One and POOM (Proof of Orphan Mining) and this program will go live on September 5th, 2019.

In POOM you may sponsor a personal child directly with Cameroon-One (and this is a tax deductible contribution), and this personal sponsorship will reward you "points" daily in our GSC campaign for Cameroon-One, currently at a rate of 100%!

This is a great achievement, let's hope this increases children sponsorships.

[fenin0018]

Hi BBP gurus,
What does it means the following errors in getmininginfo output:

Code:

  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "poolinfo5": "Internal ABN: Invalid 1567673794; ",
  "abninfo": "No block to mine...  Please wait... 1567673839; No block to mine...  Please wait... 1567673838; No block to mine...  Please wait... 1567673836; No block to mine.......................
  "gsc_errors": "low abn weight 0",
  "poolmining": false,
  "pool_url": "",
  "required_abn_weight": 125000

I have more than 125000 BBP in my wallet with enough age.

Any idea what the message means?

I'm having the same problem.

[afeno]

Hi BBP gurus,
What does it means the following errors in getmininginfo output:

Code:

  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "poolinfo5": "Internal ABN: Invalid 1567673794; ",
  "abninfo": "No block to mine...  Please wait... 1567673839; No block to mine...  Please wait... 1567673838; No block to mine...  Please wait... 1567673836; No block to mine.......................
  "gsc_errors": "low abn weight 0",
  "poolmining": false,
  "pool_url": "",
  "required_abn_weight": 125000

I have more than 125000 BBP in my wallet with enough age.

Any idea what the message means?

could you please paste 'exec createabn 125000' if it is still happening?
This sometimes happens if you recently spent your coin-age and the confirms are < 5 (see coin control depth of each UTXO).

Thank you Rob. You are right. It was a problem with the Age that I wrongly check.

[jsheets1970]

It might just be my system but has anyone else noticed within the last week or so MASTERNODE_SYNC_GOVERNANCE seems to be taking much longer. Here is a an example of that where it took 810 Seconds to sync.. Configuration file has not changed in months but this seems to be just acting a little slow.. Anyone else see this or have an idea how to speed up this process?

2019-09-05 15:34:17 CMasternodeSync::SwitchToNextAsset -- Starting MASTERNODE_SYNC_GOVERNANCE
2019-09-05 15:37:49 UpdateTip: new best=6bd356c3656f535beeb651dd6c5eea03b51210ce75c0e9bfd431e0b65e4028cf height=142967 version=0x20000000 log2_work=59.54057831 tx=1131662 date='2019-09-05 15:37:45' progress=1.000000 cache=0.0MiB(0txo)
2019-09-05 15:37:49 {PNB}: ACC  UpdateTip: new best=333dbc8d077e827e2a5931aef78fbd2e88c26bf60977f922bf63dc8cbe22ad70 height=142968 version=0x20000000 log2_work=59.54058279 tx=1131664 date='2019-09-05 15:41:29' progress=0.999999 cache=0.0MiB(0txo)
2019-09-05 15:42:58 {PNB}: ACC  CMasternodeSync::SwitchToNextAsset -- Completed MASTERNODE_SYNC_GOVERNANCE in 810s

[bible_pay]

It might just be my system but has anyone else noticed within the last week or so MASTERNODE_SYNC_GOVERNANCE seems to be taking much longer. Here is a an example of that where it took 810 Seconds to sync.. Configuration file has not changed in months but this seems to be just acting a little slow.. Anyone else see this or have an idea how to speed up this process?

2019-09-05 15:34:17 CMasternodeSync::SwitchToNextAsset -- Starting MASTERNODE_SYNC_GOVERNANCE
2019-09-05 15:37:49 UpdateTip: new best=6bd356c3656f535beeb651dd6c5eea03b51210ce75c0e9bfd431e0b65e4028cf height=142967 version=0x20000000 log2_work=59.54057831 tx=1131662 date='2019-09-05 15:37:45' progress=1.000000 cache=0.0MiB(0txo)
2019-09-05 15:37:49 {PNB}: ACC  UpdateTip: new best=333dbc8d077e827e2a5931aef78fbd2e88c26bf60977f922bf63dc8cbe22ad70 height=142968 version=0x20000000 log2_work=59.54058279 tx=1131664 date='2019-09-05 15:41:29' progress=0.999999 cache=0.0MiB(0txo)
2019-09-05 15:42:58 {PNB}: ACC  CMasternodeSync::SwitchToNextAsset -- Completed MASTERNODE_SYNC_GOVERNANCE in 810s

It does seem rather long; let me check into this.

[bible_pay]

It might just be my system but has anyone else noticed within the last week or so MASTERNODE_SYNC_GOVERNANCE seems to be taking much longer. Here is a an example of that where it took 810 Seconds to sync.. Configuration file has not changed in months but this seems to be just acting a little slow.. Anyone else see this or have an idea how to speed up this process?

2019-09-05 15:34:17 CMasternodeSync::SwitchToNextAsset -- Starting MASTERNODE_SYNC_GOVERNANCE
2019-09-05 15:37:49 UpdateTip: new best=6bd356c3656f535beeb651dd6c5eea03b51210ce75c0e9bfd431e0b65e4028cf height=142967 version=0x20000000 log2_work=59.54057831 tx=1131662 date='2019-09-05 15:37:45' progress=1.000000 cache=0.0MiB(0txo)
2019-09-05 15:37:49 {PNB}: ACC  UpdateTip: new best=333dbc8d077e827e2a5931aef78fbd2e88c26bf60977f922bf63dc8cbe22ad70 height=142968 version=0x20000000 log2_work=59.54058279 tx=1131664 date='2019-09-05 15:41:29' progress=0.999999 cache=0.0MiB(0txo)
2019-09-05 15:42:58 {PNB}: ACC  CMasternodeSync::SwitchToNextAsset -- Completed MASTERNODE_SYNC_GOVERNANCE in 810s

So it looks like a couple problems did exist.

First of all we have had a lot of Sanctuary migration over to Apollon in the last two days.  The old sanctuary votes that existed on expired nodes have been floating around and being purged causing a lot of extra traffic (as the new nodes recreate new votes, etc).  So that is coming to a close now, I see most of that activity is finished.

The second problem is we had a network setting - for certain gobjects - set wrong - causing higher than normal governance traffic levels.  This has been corrected.

Note, if you want to re-test the governance sync time, please make sure the sync occurs in one shot (IE it doesnt say : Attempt #8 etc).  (If sync is failing thats a different problem - that means the node you are pulling from is ddossing your request).  The true sync time for mnsync step 4 should be that it asks for the gobjects and succeeds in receiving all in one shot and moves to the next mnsync level.  Theoretically we should be syncing gobjects in less than 3 minutes now.

Regarding the complaint about network traffic that NSummy posted I have been monitoring network traffic and after, and I see a very large decrease now.  With our old settings, I sent and received 1 gig of data in 2 days.  Today, I see that has decreased to about 200 meg (that sounds relatively normal).  So feel free to confirm and if it still seems high we need a volunteer to set up a baseline comparison with Bitcoin and Dash.  Ill keep monitoring my local node to see if we stay low.

[togoshigekata]

Hey Rob, great work!

Any updates on Tokok?
A user from our telegram and another from CPU Miners Club discord were both asking

CPU Miners Club
- Discord: https://discord.gg/cc4jCB6

[bible_pay]

Hey Rob, great work!

Any updates on Tokok?
A user from our telegram and another from CPU Miners Club discord were both asking

CPU Miners Club
- Discord: https://discord.gg/cc4jCB6

They reached out to me last night, that they received the airdrop funds (1.35MM), and we decided to potentially go live on 9/17.

They still have to confirm this, the ticker pairs, the airdrop info, etc.  I will post go-live info as soon as I hear further confirmation back.

[orbis]

Hi Rob,
please can you take a look o PoBH mining?
Maybe two days ago my miners stoped hiiting a blocks.
Today I found, that it looks that there is "some problem"

Code:

 "Version": "Popularity,Percent %",
  "1432": "53; 25.85%",
  "1445": "124; 60.48%",
  "1446": "28; 13.66%"

I tlooks that there are miners with wallet version 1432, but mandatory was 1145....
When I took a look to last 500 bloks it looks that first 3 miners are 1432...

Code:

cpk number of blocks
B96CBZ3ZEAXYp8v8fHD4U4wL8B9PYHSNqf 43
BHVaitQvSJpWqzLJg9N2owCq1W893KQvYP 42
B5Us6y2DSVF9U4w4R4CpBvJfcN1ZF236N1 41

It is OK?
Thanks

[bible_pay]

Hi Rob,
please can you take a look o PoBH mining?
Maybe two days ago my miners stoped hiiting a blocks.
Today I found, that it looks that there is "some problem"

Code:

 "Version": "Popularity,Percent %",
  "1432": "53; 25.85%",
  "1445": "124; 60.48%",
  "1446": "28; 13.66%"

I tlooks that there are miners with wallet version 1432, but mandatory was 1145....
When I took a look to last 500 bloks it looks that first 3 miners are 1432...

Code:

cpk number of blocks
B96CBZ3ZEAXYp8v8fHD4U4wL8B9PYHSNqf 43
BHVaitQvSJpWqzLJg9N2owCq1W893KQvYP 42
B5Us6y2DSVF9U4w4R4CpBvJfcN1ZF236N1 41

It is OK?
Thanks

Its interesting that 26% havent upgraded from 1432 yet.
In pool.biblepay.org, we enforce the version must be > 1.4.4.4 btw, so the 26% who did not upgrade are definitely solo mining.

As far as how they are doing it, the mandatory upgrade with 1445 actually was mostly related to govobj propagation + cameroon 1 bus logic.  So, we did make it mandatory so that the sancs upgraded (and we know they did because the sanc protocol version is enforced).  

But getting very specific, 1.4.3.2 will actually still stay in sync and mine technically (because it wasnt a hardfork consensus breaker).  The main reason it was a mandatory was the older versions had a problem with gobject propagation - this basically means those 1432 nodes do not have a complete picture of the daily GSC contract; they are more apt to go out of sync if they miss a gobject; and worse they might not forward a gobject over to a friend node.  We probably should enforce it in the next leisure (by ddossing or banning versions earlier than 1440).  Most likely these miners are not full nodes anyway (meaning they arent sharing the data much) as miners are usually behind their own firewalls (they arent sancs), so the problem is relatively low risk.

But yes we could consider banning them in our next release so they upgrade.

Thanks for pointing this out.

From a mining perspective this should not be causing a problem though since they can't pool mine, they must be self funded abns.

But as far as hitting blocks, the pool is still hitting 33%.  I havent seen a big change recently. 
(So these 3 CPKs are solo mining 25% of the blocks I see.  I wonder how many machines are being used; I don't think we can tell.)

[orbis]

But as far as hitting blocks, the pool is still hitting 33%.  I havent seen a big change recently.  
(So these 3 CPKs are solo mining 25% of the blocks I see.  I wonder how many machines are being used; I don't think we can tell.)

Ok, I accept that.
But I don't have as much luck as you (pool)
I hit 90% less blocks. It was after 1146 update (maybe it's coincidence). But I don't remember these 1132 miners before. I'm almost sure, that those miners (except BHVaitQvSJpWqzLJg9N2owCq1W893KQvYP) are new, not "not upgraded". Maybe it is their own version.
But yes, they must have enough coins to mine, so from this point of view it looks that's OK.

[bible_pay]

But as far as hitting blocks, the pool is still hitting 33%.  I havent seen a big change recently.  
(So these 3 CPKs are solo mining 25% of the blocks I see.  I wonder how many machines are being used; I don't think we can tell.)

Ok, I accept that.
But I don't have as much luck as you (pool)
I hit 90% less blocks. It was after 1146 update (maybe it's coincidence). But I don't remember these 1132 miners before. I'm almost sure, that those miners (except BHVaitQvSJpWqzLJg9N2owCq1W893KQvYP) are new, not "not upgraded". Maybe it is their own version.
But yes, they must have enough coins to mine, so from this point of view it looks that's OK.

I see these 3 cpk's never registered their nickname or joined pog, so maybe they are either trying to be anonymous, or simply want dedicated cpks for the mining wallets.

I don't know of any way they would be gaming the system since they have to solve the POBH block and come up with the funded abn. 

It could be they had that particular binary conveninent for them on their nodes so they didnt bother pulling the new version.

Id check with Capulo, he stopped pool mining and usually has more than 20 machines and could probably solve at least 15 a day.

[yaronidon]

Hello
I have two questions.

1)
I have one station pool mining successfully.
I want to add several stations using same wallet
Is it possible ?
How can I do it ?
Just copy wallet.dat and biblepay.conf to the other stations ?

2)
I am confused regarding POG, I understand its related coin age, I see few people are getting a-lot of money and most are getting few.
it seems like a Casino where the experienced users wait(take the time for the coins to age) for the right time to gamble.
If its true it seems not so fair.
Am I missing something ?

[bible_pay]

*** Orphan Partnership Update ***



I've been working with Pastor Joshua in Kenya at HFOC (Hope for Orphan Center) for 90 days.  Although we have gotten to the point close to compliance - where our partner creates a PDF package, bios, liquidates BBP->BTC, accepts letters, etc., unfortunately some elements of the partnership were not completed entirely (for example, creating a forum thread and answering investor questions directly from pastor Joshua to our users).  I wanted this for full transparency so no one outside of BiblePay could ever accuse us of spending even a penny that has not gone to the poor, and true account of each and every orphan.  (And to reiterate, all of our expenses have gone to help orphans with 0 overhead).   (During the interim months I have been manually paying out of my personal account to keep the relationship).

But now I feel the HFOC will need to be closed down, and instead, I feel it is in our best interests to scale up our 501c3 relationships to give our investors more of a warm and fuzzy feeling.

Therefore I have begun to close the relationship with HFOC today.

So please realize we will have some changes to our orphan records appearing in the pool.

Over the last 30 days, I have increased sponsorships with Kairos, as Pastor Andy Scribner has been phenomenal and located some children in desperate need in the Philipines in a very cost effective way - therefore I jumped on the opportunity for us to help them.  

So in summary, we will see a decrease of 26 kids from Kenya, but an increase of 11 kids from Kairos, and an increase of approx. 10 kids from Compassion.

Since we still have a credit at Compassion, I will also ensure we increase our compassion count by at least 5 kids, and then we can reassess our 6 month buffer with Compassion.

We now have 4 new kids coming this week thanks to POOM.  I will look into adding a POOM figure to our pool.biblepay home page also.

[nsummy]

Hi Rob,
please can you take a look o PoBH mining?
Maybe two days ago my miners stoped hiiting a blocks.
Today I found, that it looks that there is "some problem"

Code:

 "Version": "Popularity,Percent %",
  "1432": "53; 25.85%",
  "1445": "124; 60.48%",
  "1446": "28; 13.66%"

I tlooks that there are miners with wallet version 1432, but mandatory was 1145....
When I took a look to last 500 bloks it looks that first 3 miners are 1432...

Code:

cpk number of blocks
B96CBZ3ZEAXYp8v8fHD4U4wL8B9PYHSNqf 43
BHVaitQvSJpWqzLJg9N2owCq1W893KQvYP 42
B5Us6y2DSVF9U4w4R4CpBvJfcN1ZF236N1 41

It is OK?
Thanks

Its interesting that 26% havent upgraded from 1432 yet.
In pool.biblepay.org, we enforce the version must be > 1.4.4.4 btw, so the 26% who did not upgrade are definitely solo mining.

As far as how they are doing it, the mandatory upgrade with 1445 actually was mostly related to govobj propagation + cameroon 1 bus logic.  So, we did make it mandatory so that the sancs upgraded (and we know they did because the sanc protocol version is enforced).  

But getting very specific, 1.4.3.2 will actually still stay in sync and mine technically (because it wasnt a hardfork consensus breaker).  The main reason it was a mandatory was the older versions had a problem with gobject propagation - this basically means those 1432 nodes do not have a complete picture of the daily GSC contract; they are more apt to go out of sync if they miss a gobject; and worse they might not forward a gobject over to a friend node.  We probably should enforce it in the next leisure (by ddossing or banning versions earlier than 1440).  Most likely these miners are not full nodes anyway (meaning they arent sharing the data much) as miners are usually behind their own firewalls (they arent sancs), so the problem is relatively low risk.

But yes we could consider banning them in our next release so they upgrade.

Thanks for pointing this out.

From a mining perspective this should not be causing a problem though since they can't pool mine, they must be self funded abns.

But as far as hitting blocks, the pool is still hitting 33%.  I havent seen a big change recently. 
(So these 3 CPKs are solo mining 25% of the blocks I see.  I wonder how many machines are being used; I don't think we can tell.)

Is it possible to put a notification in the wallet whenever there is a new version.  I'm thinking like a link on the overview page that says "Client out of date - version 1.X.X.X now available."  Something like that.