Couple of thoughts, these are just my opinions and not the canon belief of the coin, but I think could spawn some good discussion.

On the thought of removing the Team BiblePay requirement to PoDC.  I understand we would gain more users, but I fear we would alienate our current mining base.  I'm pretty sure without the team requirement it will be harder to show our value to the scientific community.  Sure, we can show how many people get BBP and user BOINC, but we could no longer claim those as our unique users.  While we've not been able to capitalize on the potential PR value of Team BiblePay yet, I think it is there.

We have enough exchanges: With the addition of Cryptobridge and the upcoming addition of Coinexchange, in addition to SouthXchange, QIEX and C-Cex, we have enough markets to provide stability.  Sure, the last two have had some issues, but the first two should provide enough market stability.  The only other exchanges we should be courting would be top 40 exchanges and many of those don't accept paid listings so for all practical purposes, I think we are where we need to be with that.

I do believe we need to seriously consider two moderate changes to the coin.

The first is to remove the Dark Gravity Wave component from the PoDC and Sanctuary payments and keep it solely for the PoBH (heat mining) payments.  This would still protect against an influx of hash rate, but would allow investors to have a more dependable ROI for Sanctuaries.  In the last month I've seen payments range from approximately 3900 to approximately 4600.  This is a variation of nearly 20%, and adds too much complexity to the coin, skews the potential maximum emissions and I believe would be of benefit to change.  It would also make Sanctuaries and PoDC miners get equal rewards, whereas right now, PoDC gets more in a day than the collective sum of winning Sanctuaries.  In short, give the lucky Sanctuary 38.5% of the current block maximum, rather than the DGW Modified value.

The second is put a lower cap on the emission, preventing it from going below 200 BBP per block (before accounting for the budgetary parameters).  This would mean no max supply, but would only add approximately 7% to the current theoretical maximum every 50 years.  This would send a message that 1) we intended to be around more than 50 years and 2) Will still be supporting our charities and having a workable budget.

While we could discuss either of these points further down the line, I think considering them now, while we're still relatively young, would be best.

Just checked my miner and can confirm.
Just getting connectionrefusederror

Why don't you invite him to post in our thread and challenge even one point and we will prove him wrong every time, and then lets ask him why we cant advertise a Christian charity that is helping 339 orphans every month?

I imported your address as watch-only and see the right balance (the same seen on the explorer)

What wallet version do you have?

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.

getgovernanceinfo

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).

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).

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.