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

[bible_pay]

Hi Dave,

Oh OK now Im starting to understand the problem a little deeper.  First of all since you have the utxooverride set in the primary controller wallet I think those are going out.  Just type 'exec utxoreport cpid' and you will see the pattern.  I dont believe there is a problem with gyrating amounts (as 2,000 people are using it now) I believe the gyrating amounts are being sent at intervals between your controller, your other wallets...  The utxoreport will reveal that.

As far as running the latest, yes - if your miners are not running the latest they should technically be OK- but are probably trying to send podc updates using the old default of 50,000.  So best advice there is to set 'utxoamount=-1' on the OLD mining wallets pre 1.1.1.6, or 'utxooverride=-1' on the new mining wallet (actualy just put both in the file), that should prevent it from being sent.  Notice - you cant use '=0' because zero means it will try to send 50K.....

Once you interpret the utxoreport then lets go from there - it should reveal that your mining wallets are sending in a small stake, preventing you from being paid.  Your Pool row is probably @ utxo below 5% meaning it drops to zero.

Hi Rob, thanks for the explanation; these commands were the ones I was looking for; I already assumed I could somehow prevent the other wallets from sending the updates.
I updated all wallets, put the lines into config and restarted those. I also removed the "utxooverride" line from my main controller wallet (windows, 1.1.1.7), restarted this and then wanted to freshly "podcupdate". Unfortunately now there is another strange problem:
exec podcupdate true gives me the following:

Code:

"Command": "podcupdate",
  "PODCUpdate": "Unable to create PODC UTXO::Balance (0.00) less than target UTXO (785509.00)."

exec statebalance says "0". 
getbalance however gives the correct amount (500k).

Is there some method to "reset" the whole thing?

exec stakebalance pulls coins with more than 6 confirms of age, so if you wait a couple blocks then enable coin control, then go into the Send page and take a look at each coins age in depth-in-chain, see if all coins are > 6 in depth, then the 'exec stakebalance' should be high again.

PODC update should work at that point automatically.

[1715119061]

1715119061

[1715119061]

1715119061

[orbis]

Since the UTXOWeight is set automatically, should I remove the uxtoamount=51000 in the biblepay.conf file?

Yes, try removing it, and just see if your 'exec utxoreport cpid' looks OK in about 8 hours .

Yes, but beware
I have running two wallets 24/7 (just for sure if 1 of them will fall down ) on linux 1.1.1.3 with setted utxoamount.
Then I've updated my win wallet to 1.1.1.7 and removed utxoamount to make it automatically
But then my win wallet made 1 podc update only with 11k BBP (it is less than 10% of my RAC), but I have seen it and I've made corection with podc update true. What is worst it made this bad podc update again (with 20k BBP) but I've not noticed it and now I have in next superblock only 10% utxo weight even if my others podcupdates from linux machines are correct. It looks, that my bad podcupdate was in worst time when new block rewards was formed
Now I've set my win wallet to utxooverride=-1, so I hope that it was for last time
Rob, maybe it will be really good to have there some rule, that if there was podcupdate in last for example 6 hours don't make the new one. I think that the problem was, that the last podcupdate from linux machine was less than 6 block from prior and my stakebalance was only 20k.

[bible_pay]

Since the UTXOWeight is set automatically, should I remove the uxtoamount=51000 in the biblepay.conf file?

Thanks Slovakia & Rob ... on a (maybe) related issue, pool.biblepay shows me with 0 (zero) for: TaskWeight UTXOWeight UTXOAmount

while exec getboincinfo shows: _TaskWeight": 100 _UTXOWeight": 164224,

Should they be the same?  I just removed uxtoamount=51000 from the biblepay.conf file.

Thanks in advance gentlemen.

Tom, it looks like the root of the issue in your case was you had a 1.54 day lag in your UTXO transmissions:
exec utxoreport fad380a01204898a8fe90271fe9205d5

You are actually good now, as the top record in this report was inducted by all the sancs, and the pool just updated its superblock view report and I see you have a 1.978 magnitude on the row now.

[dave_bbp]

exec stakebalance pulls coins with more than 6 confirms of age, so if you wait a couple blocks then enable coin control, then go into the Send page and take a look at each coins age in depth-in-chain, see if all coins are > 6 in depth, then the 'exec stakebalance' should be high again.

PODC update should work at that point automatically.

Lol, (as always) I have no idea what just happened or why all of the coins didn't have any age (since most of them never ever left my wallet...) but everything seems to work fine now!

Thank you and God bless!

[bible_pay]

Since the UTXOWeight is set automatically, should I remove the uxtoamount=51000 in the biblepay.conf file?

Yes, try removing it, and just see if your 'exec utxoreport cpid' looks OK in about 8 hours .

Yes, but beware
I have running two wallets 24/7 (just for sure if 1 of them will fall down ) on linux 1.1.1.3 with setted utxoamount.
Then I've updated my win wallet to 1.1.1.7 and removed utxoamount to make it automatically
But then my win wallet made 1 podc update only with 11k BBP (it is less than 10% of my RAC), but I have seen it and I've made corection with podc update true. What is worst it made this bad podc update again (with 20k BBP) but I've not noticed it and now I have in next superblock only 10% utxo weight even if my others podcupdates from linux machines are correct. It looks, that my bad podcupdate was in worst time when new block rewards was formed
Now I've set my win wallet to utxooverride=-1, so I hope that it was for last time
Rob, maybe it will be really good to have there some rule, that if there was podcupdate in last for example 6 hours don't make the new one. I think that the problem was, that the last podcupdate from linux machine was less than 6 block from prior and my stakebalance was only 20k.

Well the thing is we really just want them to run one controller wallet for the most part.  Currently, the main controller wallet does check the depth of the last transmission so it does not over-send these podcupdates unless one is due.

The lions share of the problem is people who run copies of the wallet.dat, the sub-nodes - we dont want those sending podc updates at all, so they just have to set the key 'utxooverride=-1' on those copy-cat nodes.

(I dont want to add a new rule because technically, we would not know which "last" podc to honor").  So its better if we tell people:
If you are going to copy your wallet.dat out to another machine, please set this key to prevent podc updates on that sub-node.

The other part of the issue is Id rather have the default be like it is now, where the controller sends a PODC update by default if it has an associated CPID in the wallet...  Thats how it is now for ease of use for the multitudes.

So unfortunately I dont have an easy way to make this automatic for heat miners except:  They have to do a little more work if they are heat miners

[bible_pay]

exec stakebalance pulls coins with more than 6 confirms of age, so if you wait a couple blocks then enable coin control, then go into the Send page and take a look at each coins age in depth-in-chain, see if all coins are > 6 in depth, then the 'exec stakebalance' should be high again.

PODC update should work at that point automatically.

Lol, (as always) I have no idea what just happened or why all of the coins didn't have any age (since most of them never ever left my wallet...) but everything seems to work fine now!

Thank you and God bless!

God Bless you too- the coins lose their age when a PODC update is sent, wallet breaks as many bills as necessary, sends the coins back to you, at that point they have a new birth and new depth in the chain again.

[jaapgvk]

I just adjusted the UTXO Reward chart on the wiki from 500BBP/MAG to 20BBP/RAC
Can anyone check if it's alright like this?

http://wiki.biblepay.org/Distributed_Computing

Biblepay UTXO Reward Chart
UTXO Level   UTXO CoinStake Amount   Percentage of Reward
Level 0   0-1 BBP per RAC   0%
Level 1   1-3 BBP per 1 RAC   10%
Level 2   3-5 BBP per 1 RAC   20%
Level 3   5-7 BBP per 1 RAC   30%
Level 4   7-9 BBP per 1 RAC   40%
Level 5   9-11 BBP per 1 RAC   50%
Level 6   11-13 BBP per 1 RAC   60%
Level 7   13-15 BBP per 1 RAC   70%
Level 8   15-17 BBP per 1 RAC   80%
Level 9   17-19 BBP per 1 RAC   90%
Level 10   20 BBP per 1 RAC   100%

[bible_pay]

Do you use PoS or PoW for mining?

We have both POW and PODC.  PODC also has some POS in it.

[noxpost]

Do you use PoS or PoW for mining?

PODC - which is staked, so it has some POS - is combined with POW heat mining. You can learn more on the wiki; here's a link:
http://wiki.biblepay.org/Distributed_Computing

[bible_pay]

I just adjusted the UTXO Reward chart on the wiki from 500BBP/MAG to 20BBP/RAC
Can anyone check if it's alright like this?

http://wiki.biblepay.org/Distributed_Computing

Biblepay UTXO Reward Chart
UTXO Level   UTXO CoinStake Amount   Percentage of Reward
Level 0   0-1 BBP per RAC   0%
Level 1   1-3 BBP per 1 RAC   10%
Level 2   3-5 BBP per 1 RAC   20%
Level 3   5-7 BBP per 1 RAC   30%
Level 4   7-9 BBP per 1 RAC   40%
Level 5   9-11 BBP per 1 RAC   50%
Level 6   11-13 BBP per 1 RAC   60%
Level 7   13-15 BBP per 1 RAC   70%
Level 8   15-17 BBP per 1 RAC   80%
Level 9   17-19 BBP per 1 RAC   90%
Level 10   20 BBP per 1 RAC   100%

We have one more special rule for people with UTXO amounts lower than 5%.  If you stake 0-4.9% you receive 0.
So you could either adjust row 0 & 1 to reflect that - or if you want you can multiply all these * 100 for bigger numbers, (IE 2000 bbp per 100 RAC) but either way it looks great and thank you for the contribution!

Note: that if you stake 5% - 9.99% you are in the 10% bracket.  As you know already.

[jaapgvk]

I just adjusted the UTXO Reward chart on the wiki from 500BBP/MAG to 20BBP/RAC
Can anyone check if it's alright like this?

http://wiki.biblepay.org/Distributed_Computing

Biblepay UTXO Reward Chart
UTXO Level   UTXO CoinStake Amount   Percentage of Reward
Level 0   0-1 BBP per RAC   0%
Level 1   1-3 BBP per 1 RAC   10%
Level 2   3-5 BBP per 1 RAC   20%
Level 3   5-7 BBP per 1 RAC   30%
Level 4   7-9 BBP per 1 RAC   40%
Level 5   9-11 BBP per 1 RAC   50%
Level 6   11-13 BBP per 1 RAC   60%
Level 7   13-15 BBP per 1 RAC   70%
Level 8   15-17 BBP per 1 RAC   80%
Level 9   17-19 BBP per 1 RAC   90%
Level 10   20 BBP per 1 RAC   100%

We have one more special rule for people with UTXO amounts lower than 5%.  If you stake 0-4.9% you receive 0.
So you could either adjust row 0 & 1 to reflect that - or if you want you can multiply all these * 100 for bigger numbers, (IE 2000 bbp per 100 RAC) but either way it looks great and thank you for the contribution!

Note: that if you stake 5% - 9.99% you are in the 10% bracket.  As you know already.

Thanks!

Maybe it's better to speak in terms of percentages instead of BBP .
The 0-1 BBP per RAC is actually the 0-5% UTXO amount, to I set it at 0%

[ang2]

Hello,

I have about 45000 utxo and 150000 RAC. After April 1st I get no coins. Weight is 0. If I understand clear I need at least 150000 bbp to receive 10% of the payment? That means that I should buy bbp or stop some workers from rosetta in order to reduce the RAC?

I use the latest version (1118).

Thank you.

[jaapgvk]

Hello,

I have about 45000 utxo and 150000 RAC. After April 1st I get no coins. Weight is 0. If I understand clear I need at least 150000 bbp to receive 10% of the payment? That means that I should buy bbp or stop some workers from rosetta in order to reduce the RAC?

I use the latest version (1118).

Thank you.

That's an enormous amount of RAC you got there! You're right. You would need at least 150000 BBP to get 10% of the rewards.

[Sparks1956]

I donot understand why my CPID is not showing up in wallet or debug tools window,  since today: (my cpid = bc841c3ed63ba0cfc68ff2b963f352df)



{
  "Command": "podcupdate",
  "PODCUpdate": "Unable to find any CPIDS.  Please try exec getboincinfo."
}

19:42:37

exec getboincinfo


19:42:38

{
  "Command": "getboincinfo",
  "CPID": "",
  "Address": "",
  "CPIDS": "",
  "CPID-Age (hours)": 422993,
  "NextSuperblockHeight": 38540,
  "NextSuperblockBudget": 1179301,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 29074,
  "Total Budget (One Day)": 1179301,
  "Total Budget (One Week)": 8255107,
  "Superblock Count (One Week)": 8,
  "Superblock Hit Count (One Week)": 8,
  "Superblock List": "38335,38130,37925,37720,37515,37310,37105,36900",
  "Last Superblock Height": 38335,
  "Last Superblock Budget": 1179301,
  "Last Superblock Payment": -2,
  "Magnitude (One-Day)": 0,
  "Magnitude (One-Week)": 3.521941023901932
}

I can see the CPID in the superblock view of this morning , having some reward??

[seeksilence1]

I'm shooting for knowing when a CPID creates a letter, and letter approval metrics by CPID.  Then in the future we may be able to add LetterWeight for part of POW mining and/or part of cancer mining (thats up in the air).  The primary goal being that each CPID writes one nice
 (upvoted) letter per 60 day period to an orphan to maintain 100% letterweight - or maybe letterweight is affected by upvote %. 

Should we vote this new feature before implementation since it affects everyone?

[orbis]

Well the thing is we really just want them to run one controller wallet for the most part.  Currently, the main controller wallet does check the depth of the last transmission so it does not over-send these podcupdates unless one is due.

The lions share of the problem is people who run copies of the wallet.dat, the sub-nodes - we dont want those sending podc updates at all, so they just have to set the key 'utxooverride=-1' on those copy-cat nodes.

But I have two running copies of wallet.dat just like a backup not like a POW miners, so sending PODC update was requested feature . It looks that it'll be better to run just one wallet and look on it once per day

[orbis]

I'm shooting for knowing when a CPID creates a letter, and letter approval metrics by CPID.  Then in the future we may be able to add LetterWeight for part of POW mining and/or part of cancer mining (thats up in the air).  The primary goal being that each CPID writes one nice
 (upvoted) letter per 60 day period to an orphan to maintain 100% letterweight - or maybe letterweight is affected by upvote %. 

Should we vote this new feature before implementation since it affects everyone?

I think that letter writing feature in wallet will be nice, but before implementing PoLW think of non-native speakers or non-english speaking people. Maybe this feature will be discriminating.

[bible_pay]

Check out this powerpoint that Jaap made:


https://pool.biblepay.org/Media/Biblepay-General Information.pptx


Sun has edited it with some enhancements today.

[bible_pay]

I'm shooting for knowing when a CPID creates a letter, and letter approval metrics by CPID.  Then in the future we may be able to add LetterWeight for part of POW mining and/or part of cancer mining (thats up in the air).  The primary goal being that each CPID writes one nice
 (upvoted) letter per 60 day period to an orphan to maintain 100% letterweight - or maybe letterweight is affected by upvote %. 

Should we vote this new feature before implementation since it affects everyone?

We'll vote on it once we know the scope and functional requirements.  Right now I have the dev figuring out how to allow letter writing from the core wallet, and I need to add the ability to send the letters to compassion from the core wallet.

Once the design is created on how upvotes and downvotes work then we will vote on the actual business logic change.

As a matter of fact, I think Ill create a wiki page with the design summary first so people can refer to what they are voting on.

This might take 90 days for this to get in testnet, so I think what we can do is vote on this after its proven to work in testnet.

[bible_pay]

I'm shooting for knowing when a CPID creates a letter, and letter approval metrics by CPID.  Then in the future we may be able to add LetterWeight for part of POW mining and/or part of cancer mining (thats up in the air).  The primary goal being that each CPID writes one nice
 (upvoted) letter per 60 day period to an orphan to maintain 100% letterweight - or maybe letterweight is affected by upvote %. 

Should we vote this new feature before implementation since it affects everyone?

I think that letter writing feature in wallet will be nice, but before implementing PoLW think of non-native speakers or non-english speaking people. Maybe this feature will be discriminating.

Thats actually a great point.  So to do this right, yes, we should ensure the editor he creates works in all languages.

We do support unicode letters, and the translators support any language.  So technically the only requirements I need to give Bhavani are:

- Ensure all language can be typed in the editor
- Ensure it is saved as unicode
- Ensure we have a language dropdown available so I can say "Written In:" on the PDF we send to compassion.

Good catch!

Ill add the requirements to this...