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

[bible_pay]

BiblePay - v1.1.2.2
Leisure upgrade for Exchanges
Note: All users and Sanctuaries must be on version 1.1.2.1+
(Required to propagate PODC contracts properly)


- Merged in Anton G's Hand-of-God icon updates (and splash screen update)
- 1.1.2.1 fixed the WCG rounding error and also extended the max govobj size to allow 32,767 CPIDs

The windows wallet on biblepay.org is still 1.1.1.9.

It was updated 3 minutes ago.

Hmmm, I just downloaded the 64 bit version and it's still 1.1.1.9. Maybe something is wrong with my computer, although the file size is the same as before.

Yes, file shows as version 1.1.1.9 in Properties-Details and shows 18,300 KB in size which is identical to the other 1.1.1.9 file I have in the folders.

Same here

Installed 1.1.2.2 (according to description on website) win version, but its still 1.1.1.9. No comment.

I redeployed- will someone please confirm they have upgrade to 1.1.2.2?

Thanks!

[1715020049]

1715020049

[1715020049]

1715020049

[1715020049]

1715020049

[bible_pay]

Hi Bible_pay,

It looks like the staking bug isn't actually fixed?

https://www.biblepay-central.org/en/podc/user/1995180/

He has a RAC of 184,677, stake of 3,388,035 and he is still getting a 100% UTXO weight.  Shouldn't he at least stake 3,693,540 to get 100% UTXO weight?

184677*20*0.9=3324186 so he is ok

Why *0.9? Isn't it just 20 bbp per RAC?

I believe your % is rounded up, except when below 5% when it is rounded down to 0

I don't think it should be that way. It shouldn't be rounded up or down, and then by how much? 10%? The client is already rounding up by 10% just in case if you use the automatic update, I don't think the sanctuaries should round up anything.

Its rounded down below 5.00% participation so that people who aren't contributing the minimum UTXO don't abuse the system and end up with 10%.

Its rounded up in 10% breaks to make the consensus system work in grids, which is much more efficient for the sanctuaries.

[proofodc]

I redeployed- will someone please confirm they have upgrade to 1.1.2.2?

Thanks!

just download and installed... its still 1.1.1.9

[bible_pay]

I redeployed- will someone please confirm they have upgrade to 1.1.2.2?

Thanks!

just download and installed... its still 1.1.1.9

Alright, sorry about the inconvenience all, deployment system has been fixed.

Now you should be able to download 1.1.2.2.

[jaapgvk]

I redeployed- will someone please confirm they have upgrade to 1.1.2.2?

Thanks!

just download and installed... its still 1.1.1.9

Alright, sorry about the inconvenience all, deployment system has been fixed.

Now you should be able to download 1.1.2.2.

Confirmed! 

[bible_pay]

Hi Bible_pay,

It looks like the staking bug isn't actually fixed?

https://www.biblepay-central.org/en/podc/user/1995180/

He has a RAC of 184,677, stake of 3,388,035 and he is still getting a 100% UTXO weight.  Shouldn't he at least stake 3,693,540 to get 100% UTXO weight?

184677*20*0.9=3324186 so he is ok

Why *0.9? Isn't it just 20 bbp per RAC?

I believe your % is rounded up, except when below 5% when it is rounded down to 0

I don't think it should be that way. It shouldn't be rounded up or down, and then by how much? 10%? The client is already rounding up by 10% just in case if you use the automatic update, I don't think the sanctuaries should round up anything.

RAC on site is not what I can see in by exec totalrac.
My totalrac is 1226.98
site has
RAC:   670
Biblepay RAC:     495

I think utxo weight is calculated from totalrac.

1. Regarding BBP stake, everything above 90% means 100% utxo.

2. Regarding the RAC: RAC means Rosetta RAC; Biblepay RAC means TotalRAC * utxo%; TotalRAC (via exec totalrac) means Rosetta RAC plus WCG RAC

I am talking about the combined RAC.

https://wiki.biblepay.org/Distributed_Computing

The table is clear here. You need 20 BBP per RAC to get 100%. Not less.

17-19 BBP per RAC should only give you 90% UTXO weight.

184,677 * 20 = 3,693,540. That's what should be required to get 100% UTXO weight, yet it looks like he is still getting 100% by only staking 3,388,035.

Looks like he increased his stake now but the issue still persist since he didn't have to.

I made that table and I see my error.

Code:

Level 9	 17-19 BBP per 1 RAC	90%
Level 10	20 BBP per 1 RAC	100%

A whole category is missing, namely, there is nothing from 19 to 20 BBP/RAC. Everything above 19 BBP/RAC would give you 100% rewards, since everything is indeed rounded up to the nearest bracket. I will adjust the table so it will say 19+ BBP per 1 RAC.

Regarding what we voted on and how the snap-to-grid consensus rule works, nothing was being hidden or changed by me after the vote outcome.   Even before stake-per-RAC was introduced we had stake-per-Mag, and that also adhered to the grid breaks table.

Let me explain the rules another way, with stake-per-RAC included:
We voted in a 20BBP per RAC requirement.
The Users RAC * 20 equals the Target_UTXO_Amount.

When the sanctuary assesses one users UTXO level, it does this:
ResearcherUTXOLevel = Users_Sent_UTXO / Target_UTXO_Amount

It then takes this percentage as the "UTXO Achievement Percentage".
(So one who sent in 9001 BBP out of a stake target of 10,000 bbp is at .9001% in this phase).
But the sanctuaries use an internal breaks table for consensus that has these two rules:

90.00% - 100% = 100%
80.00% - 89.999% = 90%
...
0% - 4.99999% = 0%

This allows the sanctuaries to place any researcher in a bracket of 10 conditions, for an easier consensus during periods of quick changes (resulting in the same contract when someone changes a UTXO by a small amount etc)...

So another words, the vote was adhered to politically, but the IT department already imposed Phase B during the original specification of the PODC algorithm.

[bible_pay]

I'll be meeting Ginger from Compassion.Com tomorrow, she is passing through...

[thesnat21]

Upgrading now..

There is an issue with the in-wallet alert..   A machine I already had the wallet open on doesn't report an upgrade requirement but any new opens it does.

Perhaps a periodic check routine is in order?

[616westwarmoth]

So far I've got 2 smaller machines that have been up for a week and are showing mid 2300 under host average credit (in BOINC), and the two identical machines to those were showing 3800 RAC.

I did fire up four identical heavier computers last night ,two on R@h and two on WCG, it will take until the end of the weekend to begin to get meaningful data from those.

Would you mind telling exactly which processors are in the "smaller" and "heavier" computers? I am wondering approximately how much RAC is obtained in regard to computing power. Thank you.

https://boinc.bakerlab.org/rosetta/cpu_list.php will give you a lot of insight on what you can do per processor in the real world.  GLOPS * 200 = RAC.

[noxpost]

Hey Rob -
Could you send me a PM? I don't think you accept from people still tagged as newbies, and I wanted to share something with you privately.

Thanks

[zthomasz]

I redeployed- will someone please confirm they have upgrade to 1.1.2.2?

Thanks!

just download and installed... its still 1.1.1.9

Alright, sorry about the inconvenience all, deployment system has been fixed.

Now you should be able to download 1.1.2.2.

Confirmed! 

fyi .. anyone who tried to download windows 64 wallet earlier may have to clear their browser cache to get the updated link to work.

[slovakia]

win updated to 1122

working

[616westwarmoth]

I don't think it should be that way. It shouldn't be rounded up or down, and then by how much? 10%? The client is already rounding up by 10% just in case if you use the automatic update, I don't think the sanctuaries should round up anything.

The client rounds up by 10% via PoDCUpdate because in part, it's only checking your RAC one time a day.  So if you were the normal expected user, had one PC on BOINC and decided you could put your spouse's computer on it, then the first day it was up it could very well get enough RAC to push you out of 100% without the buffer.  RAC does vary day to day, I've seen swings on an individual computer by as much as 10%, so again, the 10% buffer should protect against that.

I would generally agree with your point that 20 should be 20 (even though that was not my vote).  Which I guess three ways to accomplish this:
The first would the least work, get close enough to "correct" and that would be use normal rounding, so 4.99% would be 0%, 5.0% would be 10%, 94.999% would be 90%, and 95.0% would be 100%.  Really I think this is a good solution as it would simplify the "current less than 5% special case".
The second would be to round everything down to a multiple of 10% (which would either change the 5% special case or require it to be written as en exception.
The third would be to add a 2nd special case and 90% go from 80.1%-99.9% and 100% only trigger at 100%, which doesn't seem entirely unfair, but really seems like far more work than the first idea.

[bible_pay]

I don't think it should be that way. It shouldn't be rounded up or down, and then by how much? 10%? The client is already rounding up by 10% just in case if you use the automatic update, I don't think the sanctuaries should round up anything.

The client rounds up by 10% via PoDCUpdate because in part, it's only checking your RAC one time a day.  So if you were the normal expected user, had one PC on BOINC and decided you could put your spouse's computer on it, then the first day it was up it could very well get enough RAC to push you out of 100% without the buffer.  RAC does vary day to day, I've seen swings on an individual computer by as much as 10%, so again, the 10% buffer should protect against that.

I would generally agree with your point that 20 should be 20 (even though that was not my vote).  Which I guess three ways to accomplish this:
The first would the least work, get close enough to "correct" and that would be use normal rounding, so 4.99% would be 0%, 5.0% would be 10%, 94.999% would be 90%, and 95.0% would be 100%.  Really I think this is a good solution as it would simplify the "current less than 5% special case".
The second would be to round everything down to a multiple of 10% (which would either change the 5% special case or require it to be written as en exception.
The third would be to add a 2nd special case and 90% go from 80.1%-99.9% and 100% only trigger at 100%, which doesn't seem entirely unfair, but really seems like far more work than the first idea.

I really don't understand why you wrote all this West, as it doesn't take into account the Snap-to-Grid IT requirement in the actual PODC protocol.

It's sort of confusing everyone, as it's alluding to "a possible change" in the protocol, when we already voted the protocol in.

The UTXO requirement is 20 bbp per RAC.  The UTXO breaks chart rounds up to the nearest 10%.  Lower than 5% rounds DOWN to zero %.

The only potential recommendation I have is to ask Jaap if he wants to create a 2nd chart in percentages, so people have a chart with a larger scale (maybe they understand percentages better than static BBP amounts per break, thats up to him).

[dave_bbp]

I really don't understand why you wrote all this West, as it doesn't take into account the Snap-to-Grid IT requirement in the actual PODC protocol.

It's sort of confusing everyone, as it's alluding to "a possible change" in the protocol, when we already voted the protocol in.

The UTXO requirement is 20 bbp per RAC.  The UTXO breaks chart rounds up to the nearest 10%.  Lower than 5% rounds DOWN to zero %.

The only potential recommendation I have is to ask Jaap if he wants to create a 2nd chart in percentages, so people have a chart with a larger scale (maybe they understand percentages better than static BBP amounts per break, thats up to him).

I'm not sure you understood the problem people have with the current rules: There was a vote for how much there should be staked to get full PODC reward. The vote came down to "(at least) 20 BBP per RAC" for full reward (meaning 100%). This voting result should be the corner stone (the anchor) of every "grid" that is applied to determine the amount of payout.
Right now people can stake "only" 91% of the 20BBP/RAC and nevertheless receive the full payout (contrary to the voting result). So west tried to come up with some ways to circumvent this dilemma.

Don't get me wrong, I myself don't want it to change right now because last time I checked I also was only staking something around 93%.

[616westwarmoth]

I don't think it should be that way. It shouldn't be rounded up or down, and then by how much? 10%? The client is already rounding up by 10% just in case if you use the automatic update, I don't think the sanctuaries should round up anything.

The client rounds up by 10% via PoDCUpdate because in part, it's only checking your RAC one time a day.  So if you were the normal expected user, had one PC on BOINC and decided you could put your spouse's computer on it, then the first day it was up it could very well get enough RAC to push you out of 100% without the buffer.  RAC does vary day to day, I've seen swings on an individual computer by as much as 10%, so again, the 10% buffer should protect against that.

I would generally agree with your point that 20 should be 20 (even though that was not my vote).  Which I guess three ways to accomplish this:
The first would the least work, get close enough to "correct" and that would be use normal rounding, so 4.99% would be 0%, 5.0% would be 10%, 94.999% would be 90%, and 95.0% would be 100%.  Really I think this is a good solution as it would simplify the "current less than 5% special case".
The second would be to round everything down to a multiple of 10% (which would either change the 5% special case or require it to be written as en exception.
The third would be to add a 2nd special case and 90% go from 80.1%-99.9% and 100% only trigger at 100%, which doesn't seem entirely unfair, but really seems like far more work than the first idea.

I really don't understand why you wrote all this West, as it doesn't take into account the Snap-to-Grid IT requirement in the actual PODC protocol.

It's sort of confusing everyone, as it's alluding to "a possible change" in the protocol, when we already voted the protocol in.

The UTXO requirement is 20 bbp per RAC.  The UTXO breaks chart rounds up to the nearest 10%.  Lower than 5% rounds DOWN to zero %.

The only potential recommendation I have is to ask Jaap if he wants to create a 2nd chart in percentages, so people have a chart with a larger scale (maybe they understand percentages better than static BBP amounts per break, thats up to him).

I wrote to explain why the 10% round up in staking occurs.  I also agree that the current rounding seems slightly out of correspondence with the vote of 20 BBP per RAC to get 100%.  

I am not claiming the system works in any way other than round up to 10% except in the under 5% special case.  I trimmed too much of the quote I suppose to keep that part in context.  I was merely stating the three possible ways of handling this although I never stated this as a "possible change".  Merely as a way to spark discussion on if there were a sufficient number of users that felt the system was in need of a small tweak.  And really, if it were up to me (which it's not, short of making a proposal and seeing if it passes) I think rounding to the nearest 10% is easier to explain and eliminates the need for a special case for the 5% rule.  But I do think that discussion deserves some consideration if for no other reason than simplification.

[seeksilence1]

Try to update win wallet but it stucks on sync. What should I do? Delete some dat files?

[zthomasz]

Try to update win wallet but it stucks on sync. What should I do? Delete some dat files?

Here's a simple Win wallet cleanup guide:

Windows Cleanup:
- In Windows File Explorer enter: %appdata%/BiblePayCore
- Delete blocks and chainstate folders,
- Delete these files: banlist, fee_estimates, governance, mncache, netfulfiled and peers
- Add this line to biblepay.conf: addnode=node.biblepay-explorer.org
- In Wallet do Tools >> Wallet Repair >> Rebuild index

[seeksilence1]

Thanks. Adding the node works.

[noxpost]

Strangely, after updating both of my sancs oh, 13 hours ago, I've run into a problem.

They both ran ok for quite a while, but now both have stopped getting new blocks and a getinfo call shows 41632 as the block index (my Windows, and other block explorers, show 41638).

Anybody else running into any problems? Masternode sync status is 999, nothing is throwing errors...I'm not sure what's going on.