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

[bible_pay]

Everyone, please check your POW difficulty.  If its less than 1000, you may be on a fork.

If so, please delete your blocks and chainstate folder and restart.

[zthomasz]

My wallet "Sanctuaries" tab shows only 1 out of 3 of masternodes are Enabled.

Is this accurate?

[togoshigekata]

Code:

getblockhash 63936
d88de07a3d8c9c3a81d8841e5d568ef89e2720fb56aec1d69b6ae71c54ded0ca

[zthomasz]

Everyone, please check your POW difficulty.  If its less than 1000, you may be on a fork.

If so, please delete your blocks and chainstate folder and restart.

Does this apply to masternodes running 1.1.3.8c successfully for 4 weeks, but is now Expired and the difficulty is around 300?

[thesnat21]

Everyone, please check your POW difficulty.  If its less than 1000, you may be on a fork.

If so, please delete your blocks and chainstate folder and restart.

Curious what caused it

[markovonline]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

[bible_pay]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

[macko20]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

Rob,

All my wallets works perfectly, without restart. 1.1.3.8 (64-bit) version (win7 64bit) about 30day+

[bible_pay]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

Rob,

All my wallets works perfectly, without restart. 1.1.3.8 (64-bit) version (win7 64bit) about 30day+

Thanks, that brings up a good point also.  My regular wallets (3) were on the right chain but 30% of my sanctuaries were on the wrong chain so I rebuilt the blocks on those and resynced properly.  Its something to consider that todays problem was due to sanc rules.  It is interesting to note that the Sancs re-memorize the PODC data once every 4 hours right before doing the internal 'exec dcc' command (that is where they try to come to a podc quorum).  But I still am seriously considering a feature that erases the chainstate and blocks and resyncs if a node is out of sync for more than an hour (which can be disabled if a user doesnt want it on).

[bible_pay]

All,  Jaap has paid Coinexchange.IO for our new exchange listing fee (2 BTC) - that was the entire treasury.

We will be listed on August 15th.

[thesnat21]

Thanks, that brings up a good point also.  My regular wallets (3) were on the right chain but 30% of my sanctuaries were on the wrong chain so I rebuilt the blocks on those and resynced properly.  Its something to consider that todays problem was due to sanc rules.  It is interesting to note that the Sancs re-memorize the PODC data once every 4 hours right before doing the internal 'exec dcc' command (that is where they try to come to a podc quorum).  But I still am seriously considering a feature that erases the chainstate and blocks and resyncs if a node is out of sync for more than an hour (which can be disabled if a user doesnt want it on).

My clients thought they were still current.. so not sure how that rule would help

As for the delete/rebuild interesting idea.  There is still the oddity of when you do that, the PODC key seems to get lost until you re-start the client.

I'm guessing the scanning routine isn't looking for/updating the key info when it gets to that part of the blockchain.
(just a guess, since I have not looked into it really)


I've done it several times and gotten the unable to sign cpid error.

[togoshigekata]

All, Jaap has paid Coinexchange.IO for our new exchange listing fee (2 BTC) - that was the entire treasury.

We will be listed on August 15th.

CoinExchange.io
https://www.coinexchange.io/

CoinMarketCap - 24 hour Volume
https://coinmarketcap.com/exchanges/coinexchange/

Doge Market (To see how Exchange Looks)
https://www.coinexchange.io/market/DOGE/BTC

BiblePay Proposal to be listed on CoinExchange.IO
https://forum.biblepay.org/index.php?topic=231.0
123 Yes Votes, 8 No Votes

[bible_pay]

Thanks, that brings up a good point also.  My regular wallets (3) were on the right chain but 30% of my sanctuaries were on the wrong chain so I rebuilt the blocks on those and resynced properly.  Its something to consider that todays problem was due to sanc rules.  It is interesting to note that the Sancs re-memorize the PODC data once every 4 hours right before doing the internal 'exec dcc' command (that is where they try to come to a podc quorum).  But I still am seriously considering a feature that erases the chainstate and blocks and resyncs if a node is out of sync for more than an hour (which can be disabled if a user doesnt want it on).

My clients thought they were still current.. so not sure how that rule would help

As for the delete/rebuild interesting idea.  There is still the oddity of when you do that, the PODC key seems to get lost until you re-start the client.

I'm guessing the scanning routine isn't looking for/updating the key info when it gets to that part of the blockchain.
(just a guess, since I have not looked into it really)


I've done it several times and gotten the unable to sign cpid error.

On the 'trigger' to delete the chain and restart, there are ways to do that.  The rule would be something like: an hour has passed since the last cold boot, and the difficulty is less than (say 1000) POW, and a fork exists (IE getchaintips > 1) and the longer chain contains a bad block.  Then we restart the wallet with an -erasechain parameter.

As far as the memorizeprayers function, just delete SAN/prayers_prod  for now and restart.  Ill have to make it honor a startup where the best block height is less than the prayer height in the file.  Correct, its not checking that right now, thats a bug.

[noxpost]

Also just so everyone is aware, iquidus (the software that powers the block explorers ) has a very very hard time recovering from a fork. Mine got on the wrong chain for a bit, and couldn't recover, so I'm once again rebuilding the full database. Sorry for any inconvenience, but there's little else I can do.

[slovakia]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

Rob,

All my wallets works perfectly, without restart. 1.1.3.8 (64-bit) version (win7 64bit) about 30day+

win version works perfect 40day+ .... but 2 masternodes crashed again= any problems with masternode chain=it happened that jumped to other chain

[bible_pay]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

Rob,

All my wallets works perfectly, without restart. 1.1.3.8 (64-bit) version (win7 64bit) about 30day+

win version works perfect 40day+ .... but 2 masternodes crashed again= any problems with masternode chain=it happened that jumped to other chain

If a Sanc crashes we need a volunteer to start the sanc like this:

valgrind ./biblepayd
or
valgrind ./biblepay-qt

and tell us the line # of the crash.

sudo apt get install valgrind

[bible_pay]

But I still am seriously considering a feature that erases the chainstate and blocks and resyncs if a node is out of sync for more than an hour (which can be disabled if a user doesnt want it on).

Great idea!

[thesnat21]

Strange this superblock it seems like I missed the unbanked payment..

Anyone else see something similar?

[togoshigekata]

An orphanage from India, Brynn Children Home, has been in contact with me over Facebook, I think they will be creating a proposal soon!
https://www.facebook.com/Brynn-Children-Home-1668615016742705/

[togoshigekata]

Bitcointalk Forum - Banner Ad

Proposal:
https://forum.biblepay.org/index.php?topic=83.0

We were rejected again by Theymos, Bitcointalk Forum Admin, on June 20th
https://bitcointalk.org/index.php?topic=4471292.msg40517470#msg40517470

I've decided that masternode coins can sometimes be acceptable, but Biblepay seems highly deceptive.
For example, you say "10% of the emission goes to sponsoring Orphans, with provable contributions," but:

 - 10% of the monthly emission should be somewhere around 6 million coins, but the monthly trade volume tends to be
only slightly higher than this, which is unbelievable if you're actually selling the coins in order to make donations.

 - This 10% goes to a hardcoded non-multisig address with no explanation.

 - "THE COIN HAS RPC COMMANDS THAT PROVE 100% OF CONTRIBUTIONS ARE SPENT THE WAY INTENDED" is completely false.
The RPC command just totals up all of the payments to the hardcoded address.
What happens after the coins go to that address is unexplained.

 - There is no non-profit registration, receipts for donations, any info about the people who are supposedly facilitating donations, etc.
 
Biblepay looks like a generic coin with hardcoded dev subsidy plus some probably-totally-fabricated marketing about orphans.

I posted the bad news in the forum and we had more conversation:
https://bitcointalk.org/index.php?topic=2388064.msg40625636#msg40625636

Here are my collection of notes below,
is there anything more we can add?
is there a better way to organize the information?

Did you talk with Theymos further Rob?
Should I try contacting Theymos again, with this summary below?

===========================================

BiblePay Team:
https://www.biblepay.org/cryptoguru/#_team

BiblePay Foundation - Non-Profit Texas Corporation (In Development):
https://wiki.biblepay.org/BiblePay_DAO

BiblePay White Paper:
https://pool.biblepay.org/Docs/BiblePay_White_Paper.pdf

===

What Evidence/Proof does BiblePay have of 10% Charity Donations?

Accountability: http://accountability.biblepay.org/

====================================
CHARITY #1



Compassion International
https://www.compassion.com/

"All of our Actual Orphan ID #s are listed in:
http://pool.biblepay.org/ >>> "Orphans" >>> "Sponsored Orphan List"

Also, the receipts I posted in EXPENSES are the actual payments I made on my credit card.
I have a copy here in case the IRS comes to my house." -Rob (Creator)

==

COMPASSION INTL
ORGANIZATION NAME: BIBLEPAY
ACCOUNT #: 07816292

PHONE# : (800) 336-7676
HOURS: Monday through Friday, 7 a.m. to 5:30 p.m.
Mailing address: Compassion International Colorado Springs, CO 80997
ORG CONTACT: ROBERT A.

=

thesnat21 called Compassion, confirmed 305 orphan sponsorships:
https://bitcointalk.org/index.php?topic=2388064.msg40663169#msg40663169

Brian879 called Compassion, confirmed 308 orphan sponsorships:
https://bitcointalk.org/index.php?topic=2388064.msg40664957#msg40664957

==

Contact:
Ginger Langehennig
Area Director of Donor Relations
https://www.linkedin.com/in/ginger-langehennig-4b31981b/
832-797-3749 or glangehennig@us.ci.org

Proposals:
December - https://forum.biblepay.org/index.php?topic=53.0
February - https://forum.biblepay.org/index.php?topic=105.0
March - https://forum.biblepay.org/index.php?topic=137.0
April - https://forum.biblepay.org/index.php?topic=162.0
May - https://forum.biblepay.org/index.php?topic=181.0
June - https://forum.biblepay.org/index.php?topic=195.0
July - https://forum.biblepay.org/index.php?topic=214.0
August - https://forum.biblepay.org/index.php?topic=229.0

Pictures:
https://pool.biblepay.org/ >>> Orphans >>> Sponsored Orphan List

Tmike talking to Ginger from Compassion:
https://bitcointalk.org/index.php?topic=2388064.msg39981340#msg39981340

Rob's Scan of Ginger's Pamphlet:
http://pool.biblepay.org/san/mission/CompassionMeetingGinger.pdf

Statement from Santiago “Jimmy” Mellado, President & CEO, Compassion International
https://medium.com/biblepay-news/charity-profile-compassion-international-75741753e1c8

Letter Writing
BiblePay rewards BBP to write letters to the sponspored orphans through the biblepay pool website
https://pool.biblepay.org/ >>> "Orphans" tab >>> "Write Letter"

====================================
CHARITY #2



BLOOM (Be Love Orphan Outreach Missions)
http://www.bloomworldwide.org/

Contact:
Executive Director, April Wareham
aprilw@nhoom.org

Proposals:
https://forum.biblepay.org/index.php?topic=73.0
https://forum.biblepay.org/index.php?topic=150.0
https://forum.biblepay.org/index.php?topic=186.0
https://forum.biblepay.org/index.php?topic=219.0
https://forum.biblepay.org/index.php?topic=227.0

Pictures:
https://biblepaysponsorkids.tumblr.com/

Facebook Mention:
https://www.facebook.com/Beloveorphanoutreach/posts/1603251943055348

Newsletter Mention:
https://mailchi.mp/bceb933b9ea4/updates-straight-from-africa

Testimonials from BLOOM and CameroonONE
https://bitcointalk.org/index.php?topic=2388064.msg39527580#msg39527580

====================================
CHARITY #3



CameroonONE
https://www.cameroonone.org/

Contact:
Director of Operations, Todd Finklestone

Proposals:
https://forum.biblepay.org/index.php?topic=86.0

Pictures:
https://www.facebook.com/CameroonONE/photos/2003983039625722
https://forum.biblepay.org/index.php?action=dlattach;topic=86.0;attach=164;image
https://forum.biblepay.org/index.php?action=dlattach;topic=86.0;attach=166;image
https://forum.biblepay.org/index.php?action=dlattach;topic=86.0;attach=168;image

Twitter Mention:
https://twitter.com/CameroonONE/status/1010845995188588549

====================================
CHARITY #4



Kairos Childrens Fund
https://www.facebook.com/kairoschildrensfund/
https://kcf.winnegor.org/

Contact:
Andrew Scribner
scribners@gmail.com

Proposals:
https://forum.biblepay.org/index.php?topic=201.0
https://forum.biblepay.org/index.php?topic=226.0

Pictures:
https://www.facebook.com/kairoschildrensfund/photos/2084557715144222
https://www.facebook.com/kairoschildrensfund/photos/2084557528477574

Website Mention:
https://kcf.winnegor.org/biblepay/

====================================

MISC:

Orphan Collage (NOTE: 12MB file):
http://pool.biblepay.org/docs/SponsorshipsAugust2018.pdf

BiblePay Proposals:
https://www.biblepay-central.org/en/proposals/

Console Command:

Code:

getgovernanceinfo

Understanding BiblePay Governance:
http://wiki.biblepay.org/UnderstandingGovernance