Sorry, the last page was a joke, there was no physorg article.

May block 66666 be our all time low!  May we give birth to a new beginning in Jesus Name!

John Ramirez performs an exorcism in mid-church:

https://www.youtube.com/watch?v=cbL_kfCr_dA

BiblePay - 1.1.4.6f
Leisure Upgrade

- Merge in Mac compiling change to crypter.cpp
- Prevent crash in getchaintips
- Modify Sanctuary business logic to help ensure the chain stays synced
- Add HealthCheckup feature to help recover during a fork
- Add deterministic ddos of invalid blocks to help prevent ddossing good nodes (help prevent forks)


I highly recommend sancs upgrade to this version within 7 days to prevent future forks.  Also any normal user who goes out of sync, please upgrade to the latest version.

** COMPASSION MONTHLY PAYMENTS MADE, and general update **

So with the 90% drop in masternode coin values in general, we have experienced a brutal month, with biblepay dropping in value approx. 50% and therefore all of our charity expenses facing extreme strain to maintain the same level of quality before the event.

The biggest challenge this month was our recurring payment to compassion.com.  We sponsor 309 monthly recurring orphans and usually pay a minimum of $11,742 plus any additional excess goes toward our 'prepaid sponsorship' program which aims for a 6 month buffer to prevent devastation of attrition (which we have only achieved half of).

Unfortunately this month we were only able to raise $7716 for Compassion, meaning we were unable to pay the premiums for 103 of our 309 children (IE we fell short by 33%), requiring us to seek funds from our prepaid sponsorship buffer to make up for the shortfall. 

The great news is we are still fully funded this month, but the bad news is we had to take a large step back by recording a prepaid sponsorship deficit of -103 children this month (See accountability | Expenses).

I think our most important mission at BiblePay is to fund our orphans before any other expenses.  In light of this, short of a miracle, during next month's governance process, I recommend that we allocate a higher portion of our expenses to Compassion, possibly as high as 90% of our entire budget, and let's cut back on every other expense including payroll unless it is absolutely mission critical.  I've skipped my payroll this month and my expense report for Exchange in order to push it into the future. 

I believe we should attempt to operate on a 70-80% reduction to our normal expense budget after leaving 90% available for compassion, unless our price recovers by more than 40% within the next 30 days.

The pool gets its info from the sancs once every 4 hours.

It can take up to 24 hours for the faucet to induct your RAC.  They just need to crunch 24 hours before trying.
(This is because both Rosetta and WCG have different data export rules for new RAC.   We don't use web sites, the sancs go directly to the boinc export files).

Jaap, we received 100 new pool users today, so it appears the airdrop is working!  Great Job!

If any of the devs want a fun project:

The linux wallet boots in roughly 10 seconds or so now, which appears to be great, with about half of that time consumed in memorizeprayers (in DeserializePrayersFromFile).

The windows wallet however boots quicker than the past, now that it is quickly checking blocks (same time as linux consumed), but memorizeprayers still seems to lag on windows.  You can try to figure out why windows is slower in DeserializePrayersFromFile() <-- thats the function that is 400% slower in windows. 

Since we are based off of Dash, we inherited a lot of those features, but once you have your initial set of addresses you should not keep seeing new ones, instead you have control over the small list - if you are in QT you have to manually add one in File | Receiving Addresses | Add.  But you can re-use the existing ones.

No, I think we are OK, because now you have to receive more than .01 BBP in the superblock for the pool to deny you, so lets see how it goes now.

There is no deadline; so you can start crunching today and in 30 days if you havent been paid by biblepay the faucet will still pay you.

The consternation is if you *buy* BBP first and have enough to Stake, and successfully receive > .01 bbp in a superblock the faucet will not pay you.

We could raise that threshhold during the airdrop if it becomes a problem.  But I think it will work as-is for most as they generally will be going to the faucet First, according to Jaap.

Hi and welcome aboard!

So for the time you were seeing the -2, that is an error code that the pool didnt see your CPID yet.
However I see the sancs inducted you into two superblocks (with 0 mag) but with a UTXO staked of 8 bbp.  So now the pool - seeing you in 2 superblocks stops payment.
Since you actually didnt get paid > 0 yet, I deleted your two superblock records in the pool, please try the faucet now.

EDIT:  I just modified the faucet to only enforce this superblock rule for CPIDs who received > 0 reward in the superblock.

Also it takes up to 24 hours for new CPID RAC to be inducted into the pool from the sancs.

How old is your CPID btw?  Please let me know if the faucet does not pay you and you are over 24 hours old - but do ensure the RAC is > 24 hours old also.

I've been working today on reducing the possibility of forks on sancs.  We are now going to test the changes.

Luckily I have a sanc in the hung state right now to test against.

Reindex tries to rebuild the chain using the blk* index files.  This works well for bitcoin but not as well for us, because the governance files arent rebuilt.

Erasechain erases the chainstate, blocks, and masternode payments and governance and resyncs from 0.  This gives the node the most chance to resync cleanly.

I'm determined to examine the root cause of the block that is marked dirty.

Just as an FYI; anyone on linux that already upgraded to 1.1.4.5: 
You can launch with "-erasechain" if you need to erase the chain while starting.

1.1.4.5 has not been officially released yet.

I'm doing a test to see if upgrading and restarting without reindexing works or not.

Ok, very curious if 1145 would have saved your node.

Unfortunately I didnt upgrade yet, so I cant answer that. 

In your case 1.1.4.5 should have helped it recover.

I just checked one and it says 'core dumped', so Im running my sanc in valgrind mode.  Lets hope it gives us the line # this next go around.

**** LETTER WRITING ORPHAN ADOPTION SYSTEM ****
released to Prod at https://pool.biblepay.org

Now you can adopt a child with the goal of having a closer letter-writing relationship with a child.

To Adopt a child:
Click Orphans | Adoption List | Right click on the Orphan | Click Adopt
(Note: Only non-adopted children are in this list).

To write to an adopted child:
Either click "Orphans | Write" or click the Write button from your Account settings page.

Adopted child info:
From Account | Account settings, you can see who you adopted and you have the option to Abandon an adopted child.

Deadlines:
You must write one letter per month to the adopted child.  To make this easy we set a deadline date in your Account Settings (see Letter Deadline date).  If you fail to write to the child by that date, we will send a friendly reminder via e-mail once per day until the 59th day.  After the 59th day, the child is automatically abandoned back to the adoption list.