Thanks for the info;  If we were not (imho) so far moving into the end-times, I would call Pirzolo from Fidelity myself and see if we could make some kind of partnership.
 (That) almost sounds like a match made in heaven- tax deductible crypto donations being sought by people already with bitcoin.

(I spoke to MIP about something similar last year - we talked about having a 501c3, and accepting 'slices of' orphan donations - something to the effect of one $40 donation for an orphan-month of charity, tax deductible, in bitcoin, and the donor receives not only the tax deductible donation, but a slice of BBP's governance reward - therefore the sponsor gets an asset back and a compssion child gets paid).

Im going to post a lot about these ideas, and see what we can do.  We don't have the room to make any mistakes, our next step has to be exactly right, and compatible, and useful.
I was thinking last night of (on a similar subject) of a service that would make biblepay useful (that is not related to the killer use case for crypto), but a use case for bbp.

Something to the effect of BBP sanctuaries become a marketplace to connect charity expenses to charitable donors.
Something for example, where the donor is happy to use us as a broker for the donation (because they receive a BBP reward back, coming from our charity budget) for doing it; but the deal is we get to list the item as a brokered charity donation on our web site.  So basically, the world helps support and continue orphans/babies/efficient charities, we get to show our help and progress, and they get some type of asset (BBP coins) to hold for the future.  (Something to make people happy to use the service).

As far as brokering, we would need to seek discounts from charities, so either we can make a commission or give the end user a discount and that would sweeten the deal.

I was also thinking it might be good for us to withhold 90 days of sanctuary payments to all sancs, in an escrow.
And we make each sanctuary a broker - then they must perform on the called upon duty, otherwise they lose their sanctuary and they lose the escrow.

One duty might be for example:  Donor A wants to donate $120 in fiat to compassion child B.  Sanctuary 105 facilitates the transfer and stores a record with the PDF for us using the public key of the sanc and signs it.  This tx also uploads to our web site.  Then we become fully decentralized, etc.  A random sanc would be chosen each time a donation is facilitated through bbp.

Also, this type of thing would remove market pressure as we would seek donations from the world for all sponsorships, and all we would spend is our 1-10% charity expense as a reward to go back to the donor (to entice them to hold bbp and repeat the process).  (And on a side note I was thinking, maybe we should also decrease our monthly superblock and charity expenses to be based on our price - IE 1-10% emission, on a scale depending on our price level.  Our 10% charity only is fully 10% if we are above .01 cent).

We would act as a charity broker.

One big reason I havent mentioned all this yet is Ive been praying to try to find out (an answer related to 501c3 / DAC).
At this point, I'm feeling we should still do this as a DAC (dec autonomous charity) (not a centralized 501c3, with an individual country presence).
The benefit of DAC is its decentralized, its global, its resilient.  The only negative about the DAC is there is no tax deduction available to give for an individual direct donation into Biblepay;
But that may possibly be overcome, depending on how these transactions work (after all the fiat or crypto source might go directly to a charity and we might be an agent etc).

I need to do some charting of what all the possible transactions would be, and how they would each work.  We also need to research pass-through donations tax deduction laws.

Ohhh that.  Yeah, I thought the wording was funny when you said "orphaned vote", it made me wonder if it was in the pool code or something.

So that just means that a particular node does not have the entire govobj cache loaded - so therefore the vote has no parent to refer to.  The vote hash should point to the govobj proposal-or-trig hash, and therefore it doesnt so its orphaned.

It just means the node should completely resync the govdata.  The node does this automatically every so often (it does an mnsync reset) to ensure it has all parents.

To manually do it of course we would just delete the mncache and gov*.dat files and restart, but thats unecessary.

1) All my running sancs agree with the explorer:
https://chainz.cryptoid.info/bbp/block.dws?169523.htm

Therefore there is no fork.  And we have not had any forks since we went deterministic.
Even the cutover height to the latest mandatory wasn't an unintended fork - it was a planned fork.

I caution you to proofread what you write before you post.  One person who is out of sync is not a sign that we have a fork.  Its a sign the person is out of sync.

And especially for forks, you need a lot of evidence (like checking 5 of your nodes) before posting that.


(I didn't receive a reply to my question).

Andy from Kairos has updated the BIOS, so now the children are available in the URLs in the core wallets listchildren all.

Note:  Now everyone can see the orphan bios from 'web.biblepay.org' in the Orphan Collage and in the Orphan List.

NOTE:  Afaik, this list will update automatically as it changes going forward.

Everyone, please keep the Philippines in your prayers.  They are experiencing great natural disasters:  Volcanoes, earthquakes, typhoons, cyclones, etc.  6 years ago, Sundar prophesied that the nation would see these calamities if the churches did not repent; and they are coming to pass just as he said; including the building fires.  Pray these inhabitants find peace and safety and are delivered from harms way!

Where does this occur, btw? 

On Kairos, yeah, I meant - Andy is supposed to provision the child within ~14 days or so.
Let me e-mail him the question now.  It's up to Kairos to expose the Bio's for each child.  Once I see they are working I will finish testing the orphan list and collage (and make it automatically refresh when it changes).

Thats very interesting, I think there is something preventing your miner from actually looping at 30KH/S.  After running it for a minute or so, you should see lines that say its speed (called the hashmeter).

Could you try removing the "-p x" at the end and try again?

If you dont see the hashmeter and still dont show up with shares, please try looking at the 'bbpminer' help options and see if we have the --verbose option.  Maybe your miner is not running in XBBP/Stratum with one of those switches.  Then also you can try re-downloading the binary and replacing it, it could be missing a dll.  Maybe run it as admin, maybe windows is blocking access to the dll.  (I doubt that).

But the key would be to see yourself with at least 1 valid share, then you will know you will enter shares in history...

You can also try different port (IE 3008, with the verbose flag on).

This is really nice; especially when you realize how much we take for granted in crypto. 

Great job!

You can also do that (send funds to a new wallet).

The advantage is the wallet will be smaller.
The disadvantage is if you have any sancs, they would need re-created.

So its up to you!

Ok thats the problem; when you go back to an old wallet, before the associate, we lose all the metadata for :  *External purse, *CPK, *Associate.
So we need to go through a recovery process.
First, go to 'biblepay.conf' and remove any long lines that reference pubkey or privkey (they are the only lines over 80 chars long).
Then stop and restart the wallet.

Next, go to Receive addresses, and edit the name of your 'christian-public-key' to be 'deleted'.
Then start the process over:  run 'exec associate user code true' (Note the true at the end).  exec join wcg.
Then send your bankroll to your new cpk.  (Note that it changed).
Then wait a few blocks and see if you have a balance in your external purse (with exec rac, and with 'exec boinc1').

Sounds like this wallet was not created the conventional way; was this wallet imported, and was the importkey command used?
As I dont think you have all the key value pairs for your external purse.
Did you run exec associate on this wallet btw?

Could you please type : exec boinc1
and paste the results?  This should show the external purse configuration.

Ok, so, let's scratch my prior reply anyway, because it turns out- when you originally pasted your command line to connect to the pool, I searched for bg4*, and found 5 payments to BG4qh*, who is a different guy, and replied about him, sorry about that.

Anyway, let me reply a different way;  first, nomp pays out 102 blocks after you find a block in the round;
next, you should immediately know you are successfully pool mining against nomp.  When you find the fractional shares, your BG4cah* address should appear in the "rounds" on the worker status.  I dont see you mining against the pool.  First check that, and once you ensure you are really getting shares, as long as you are in the solved round you will end up in the historical table.  I dont see BG4cah* in the historical table either.  I think something was wrong with the config preventing you from showing up in "Worker Stats" table...

Well, it's not that it's fair or not, it was an unintended buffering problem, and some got more and some got less randomly.

But Id be willing to put in 256,000 bbp towards the problem, if you can make a list of people who complained and distribute it.  No, I don't have a history of the rac.  You can estimate the amounts if you want, by complaint level.

I think I replied to this regarding 'http://nomp.biblepay.org', so you never got a payment? Whats the public payment address again? 

1) To let bbpminer4 die off and bbpminer to start, you just need to reassociate the CPID once using 'bbpminer'.  Do the 'exec associate user vercode true' with this wallet, and after 7 blocks, the leaderboard should start showing bbpminer, and bbpminer4 will fall off later.  You can 'exec unjoin wcg' on the bbpminer4 optionally but only if you have access to that old wallet.  Dont worry about the unjoin, it will dissapear when bbpminer starts using the cpid.

2) After exec bankroll is ran, it usually takes 3-4 confirms then exec rac shows the 'extern purse total coin age' increase.  This can lead to some complicated questions, so why dont we go down to the easiest path.  First just check again.  If you dont have coin age in exec rac, go to coin control, and see what balance do you have in your CPK?  BMSknmPYhs8NAdTcFAq86ZrshRkqJoGECV?  Then come back, and tell us if you still dont have coin age and what the CPK balance is...  As by now you should have coin age....  After 3-5 confirms....

1) The foundation funds are only to be spent on charity expenses (not payroll or new exchange fund).  We can let them accumulate until we have another charity expense to pay.  While POOM is being used, we don't have any currently, but for example in a few months when we have time for it we can make a proposal to donate it to something very useful (like an Israeli orphan, or something we havent done before, like babies for compassion etc). Remember, technically we do take donations in BBP using the wallet "Donate to foundation", so those go to the same place.  Just because we have POOM does not mean we completely shut down the ability to donate to the foundation. 

2) If you type 'listchildren all' and click on a Kairos bio, I see they aren't completed.  Here is Andy's email so you can follow up on that.  Let me know if you find one that is finished and then I will finish the code for the importer that syncs both Cameroon and Kairos in the collage:
Kairos Children's Fund <kairoschildren@gmail.com>

3) I updated the accountability expenses and revenue.  Now all of the tithe blocks, governance charity expenses, donations to us, and all manually handled liquidated revenue and expenses are in the table from inception.  It's accurate up to today.  The only thing I anticipate that needs done once per month (in our current POOM ecosystem) is ensuring that we have a script that dumps the : POOM expenses and revenue into the table.  Ill check to see if that works in February (for the end of Jan 2020's entries for Kairos and Cameroon-one).

** PODC 2.0 Bad transmission amounts - missing payments **


So the lion's share of the problem has been corrected related to bad gsc transmission stake amounts and missing payments (for all those who have enough collateral in the wallet).

Please restart your baseline from today if you missed a payment or had an invalid transmission.

The only issue we have left with PODC 2.0 is for those who don't have enough collateral; the wallet does not reward the correct amount of RAC in that case in the leaderboard.  The problem has been corrected in the current version, but we have not required a mandatory sanctuary upgrade yet (hence the code is not running in prod yet).  I believe we will roll this out towards the end of the month.

The only points calc I am aware of that doesnt work for anyone is those with not enough stake collateral not in team bbp, correct?  They are not passing the threshhold for a reward.

This is part of the next sanc mandatory upgrade, due out on Feb 1.

Ill look into the icon for the superblock payment. 

Otherwise please open a ticket with an exact traceable and reproducible issue with real rac.

The wordpress site is the only site left running on our web host company (but its the only thing on the box, wiki.biblepay.org is on a different server).
Im pretty sure the problem is one of the many plugins added back when the first expirimental version was being developed - I think Tom added a bunch of plugins to try to get various things to work in an easier way than editing the wordpress sections.

First could you try deleting any unused plugin.  Then if its still a problem come back and ask me to jump in and Ill move the server to the higher powered servers that we have access to the linux OS on.  Id rather do that as a last resort because that involves moving all of the development scripts that allow downloading biblepay and uploading biblepay binaries.

Please try decentralized web from a machine either not logged in as root (on linux) or on a windows box, and first ensure your 'exec rac' works as that decentralized web requires your cpk to have an external purse set up.

Then if it does it again please send me the logs and if any strange message is on the console.

Otherwise it generally works.