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

[sunk818]

PoDC 2.0 payment issues from Dec 25, 2019 to Jan 16, 2020, I've identified 518,639 BBP (122 line items) that are candidates for reimbursement.

Option 1: Shall I submit sanctuary proposals for each CPK, detailing the payouts?
Option 2: Send me 518,639 BBP and I'll distribute it, with documentation. BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw
Option 3: There's 146k BBP in the bounty wallet I can use. Remainder 372,639 BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw

Full details and methodology is available to anyone wanting to review out of curiosity or validate my work.

Based on the payout each day, I created median value of BBP to RAC ratio per day. This is the multiplier I used based on the RAC of the cpid I retrieved from boincstats (same as WCG). If the CPK was overpaid overall (total payments equal more than 110% of estimated payments) then there is no reimbursement for that CPK since they received more already.

Some caveats in my analysis:
* the RAC to BBP multiplier is best effort and not always best value. If a RAC whale was underpaid, this can throw off the ratio
* GSC payments are lumped into one (PoDC, Healing, POOM, etc) making it difficult to separate out non-PODC payment without performing more analysis. I looked at leaderboard but some prominence seems to be current day not on gsc block day?
* I counted the BBP balance of the CPK when the GSC reward was transmitted. If their balance had enough stake based on the team they were on (BBP = ^1.3 and non-BBP = ^1.6), then I assumed they had enough stake. I realize balance may not reflect full coin age transmission.
* Some small incidents where the GSC transmission was not sent for the CPK automatically using RAC & BBP balance day of was the best way to be inclusive
* Since the code did not offer partial payments, I did not adjust for this and respected what the code was written to do

[bible_pay]

PoDC 2.0 payment issues from Dec 25, 2019 to Jan 16, 2020, I've identified 518,639 BBP (122 line items) that are candidates for reimbursement.

Option 1: Shall I submit sanctuary proposals for each CPK, detailing the payouts?
Option 2: Send me 518,639 BBP and I'll distribute it, with documentation. BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw
Option 3: There's 146k BBP in the bounty wallet I can use. Remainder 372,639 BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw

Full details and methodology is available to anyone wanting to review out of curiosity or validate my work.

Based on the payout each day, I created median value of BBP to RAC ratio per day. This is the multiplier I used based on the RAC of the cpid I retrieved from boincstats (same as WCG). If the CPK was overpaid overall (total payments equal more than 110% of estimated payments) then there is no reimbursement for that CPK since they received more already.

Some caveats in my analysis:
* the RAC to BBP multiplier is best effort and not always best value. If a RAC whale was underpaid, this can throw off the ratio
* GSC payments are lumped into one (PoDC, Healing, POOM, etc) making it difficult to separate out non-PODC payment without performing more analysis. I looked at leaderboard but some prominence seems to be current day not on gsc block day?
* I counted the BBP balance of the CPK when the GSC reward was transmitted. If their balance had enough stake based on the team they were on (BBP = ^1.3 and non-BBP = ^1.6), then I assumed they had enough stake. I realize balance may not reflect full coin age transmission.
* Some small incidents where the GSC transmission was not sent for the CPK automatically using RAC & BBP balance day of was the best way to be inclusive
* Since the code did not offer partial payments, I did not adjust for this and respected what the code was written to do

I sent you 518,640 from my wallet, please distribute it any way you want, and thank you for taking on this endeavor.

[shorty34]

PoDC 2.0 payment issues from Dec 25, 2019 to Jan 16, 2020, I've identified 518,639 BBP (122 line items) that are candidates for reimbursement.

Option 1: Shall I submit sanctuary proposals for each CPK, detailing the payouts?
Option 2: Send me 518,639 BBP and I'll distribute it, with documentation. BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw
Option 3: There's 146k BBP in the bounty wallet I can use. Remainder 372,639 BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw

Full details and methodology is available to anyone wanting to review out of curiosity or validate my work.

Based on the payout each day, I created median value of BBP to RAC ratio per day. This is the multiplier I used based on the RAC of the cpid I retrieved from boincstats (same as WCG). If the CPK was overpaid overall (total payments equal more than 110% of estimated payments) then there is no reimbursement for that CPK since they received more already.

Some caveats in my analysis:
* the RAC to BBP multiplier is best effort and not always best value. If a RAC whale was underpaid, this can throw off the ratio
* GSC payments are lumped into one (PoDC, Healing, POOM, etc) making it difficult to separate out non-PODC payment without performing more analysis. I looked at leaderboard but some prominence seems to be current day not on gsc block day?
* I counted the BBP balance of the CPK when the GSC reward was transmitted. If their balance had enough stake based on the team they were on (BBP = ^1.3 and non-BBP = ^1.6), then I assumed they had enough stake. I realize balance may not reflect full coin age transmission.
* Some small incidents where the GSC transmission was not sent for the CPK automatically using RAC & BBP balance day of was the best way to be inclusive
* Since the code did not offer partial payments, I did not adjust for this and respected what the code was written to do

I sent you 518,640 from my wallet, please distribute it any way you want, and thank you for taking on this endeavor.

Thank you guys!

I had missed a payment or two, but the focus on fairness and the effort put into correction is much more valuable than the compensation itself.

Sun, if you can come up with a tipping bot on Discord, I will be the first to chip in - I know you will use it for a good cause

[WhyMe]

Same problem on another machine. Upgrading from 1.4.8.5 to 1.4.8.7


Rebuild in progress, and after I'm pretty sure wallet will crash.

[sunk818]

Same problem on another machine. Upgrading from 1.4.8.5 to 1.4.8.7

Rebuild in progress, and after I'm pretty sure wallet will crash.

https://whitewalr.us/2019/biblepay-erasechain-not-reindex.html

Try this. If that doesn't work, DM and I'll provide a deeper cleaning but requires you do erase some files & folders manually. I've rarely have to do it and --erasechain seems to solve it for 99.9% of people. This is actually a nice feature that no other crypto wallet has, not even DASH with their wallet repair feature.

[bible_pay]

Same problem on another machine. Upgrading from 1.4.8.5 to 1.4.8.7

Rebuild in progress, and after I'm pretty sure wallet will crash.

Also, if you have been, please avoid killing the biblepay-qt process from task manager, please do not do that.  That is a big no no in crypto.

If you kill the wallet without gracefully exiting, you will corrupt all of your databases - both berkeley DB and the underlying blocks and chainstate and wallet and you will be in for nothing but trouble in the future.

I've had a good 1 year run now with the same database and no corruption simply by exiting from the menu.

- Just to clarify - that is not a crash.  That is a notification that you have a corrupt database file.  (A crash is an unhandled exit in the program, this was handled).

[WhyMe]

I'm not killing the process, just waiting it close itself.
Still processing blocks, will see result in few minutes.

[bible_pay]

I'm not killing the process, just waiting it close itself.
Still processing blocks, will see result in few minutes.

Ohh ok, sorry, I think I am seeing the picture now; anyone who is still live on the old fork is making a long chain of bad blocks;
Yes, if you simply restart and have a lot of bad blocks in the blockindex, the plain-vanilla block checker during boot incorrectly assumes you have a corrupt chain...
OK, yes, if that is the case, please restart like Sun mentioned:  "-erasechain=1"  at the end of biblepay-qt.

Btw, if we do crash during reindex (Would you like to rebuild block index now?  <YES>), if that actually crashes, please enter a github issue.

[bible_pay]

** DYNAMIC WHALE STAKING **

I see we have 916K of burns today (exec dwsquote).

I think this is going to be a good feature for potential new baghodlers.  Hopefully more people from the outside world will join biblepay and try this.

[WhyMe]

The new external miner seems not working. I've no share on pool with it. But with 1009 I have shares ( and lots invalid rate ... )

[cuarc001]

Same problem on another machine. Upgrading from 1.4.8.5 to 1.4.8.7

Rebuild in progress, and after I'm pretty sure wallet will crash.

Also, if you have been, please avoid killing the biblepay-qt process from task manager, please do not do that.  That is a big no no in crypto.

If you kill the wallet without gracefully exiting, you will corrupt all of your databases - both berkeley DB and the underlying blocks and chainstate and wallet and you will be in for nothing but trouble in the future.

I've had a good 1 year run now with the same database and no corruption simply by exiting from the menu.

- Just to clarify - that is not a crash.  That is a notification that you have a corrupt database file.  (A crash is an unhandled exit in the program, this was handled).

Mine did this when upgrading. When I started rebuilding, I let it do its thing. Came back hours later and the wallet had closed itself. Launched again and it started rebuilding all over again without prompting. It seems to have worked fine after that. Just wanted to add my experience in case it is a mass thing. My wallet was properly exited using the file menu. I just ran the update over the old. This was on Windows 10 64 bit.

[WhyMe]

Launched 2 wallets upgrade on 2 VM, at the same time ( same VM config, same fresh Windows 10 LTSB, same previous wallet 1.4.8.5 )
The 2 wallets had the same error on loading DB.
Relaunched the 2 wallets with -erasechain=1
1 is ok after rebuild, 1 crashed after rebuild. Relaunched the crashed wallet, he's processing blocks again ...
It's my 4th 1.4.8.7 upgrade, no one has been without error
I had no problem to migrate previously ~10 wallets from 1.4.8.4 to 1.4.8.5

Maybe applying 1.4.8.6 before can help ?

EDIT
2nd wallet is finally ok after 2nd rebuild

[togoshigekata]

I combined the two website newsletter subscriber email lists

and about 12 hours ago I sent out a quick email about the recent mandatory upgrade

879 total sent, and 127 opened so far

Newsletter Signup Link: https://www.biblepay.org/newsletter/

[WhyMe]

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

[Borgholio]

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

[slovakia]

I combined the two website newsletter subscriber email lists

and about 12 hours ago I sent out a quick email about the recent mandatory upgrade

879 total sent, and 127 opened so far

Newsletter Signup Link: https://www.biblepay.org/newsletter/

finally works email (received) about new version of wallet ,  good job togo  


MIP whats cmd for upgrade linux, forgot it, thanks...... good to add on main web in tutorials, missing it there

[mksmining]

give a link to the wallet

[WhyMe]

No answer on the High Nonce problem on a "standard" desktop cpu ?

[bible_pay]

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

[bible_pay]

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp).  If they are in team bbp, we do not have a minimum rac.

There should be no minimum coin*age reqt either.  The only minimum I am aware of is if a person generates less than .005% of the GSC contract  - then due to rounding, our payment system leaves off the payment (because it considers it zero).  But in this case you should still see some RAC in the leaderboard.  The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row.