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

[bible_pay]

BiblePay
1.4.3.3-Leisure Upgrade

- Remove Log Spam
- Fix astronomical getmininginfo hashps
- Fix getnetworkhashps, and calibrate networkhashps
- Make leaderboard show the exact BBP payment amount per participant
(Note: This will work after sancs upgrade)
- Make Sanc Quorum disregard GSC payments < 1BBP
- Fix RPC help command
- Add ability to delete an address book entry (rename it to 'del') from
the address book list UI in QT.  (The entry will be removed during the next boot).

** Note: Sancs, please upgrade within 21 days at your convenience **
** Linux and Mac is building **

[1713534272]

1713534272

[1713534272]

1713534272

[1713534272]

1713534272

[1713534272]

1713534272

[capulo]

is hps in pool (leaderboard) recalculated somehow? if tyes then it is wrong, i shoud have about 1/4-1/3 of pool total hps

[yaronidon]

Sorry I am confused
I thought that Sanctuaries were 40% and will remain 40%
But now I need 3 times more BBP to create a Sanctuary, so I expected 3 times less total number of Sanctuaries, and 3 Times more payout per Sanctuary.

1) Sancs always get half of the net reward - half goes to the heat miner and half to the sanc.  The 40% figure was the amount a sanc would receive with 10% for governance, but now we have 48.5% for governance when including the GSC amount.  But the sancs still get half of what is left.

2) You do get 3* the reward now for a sanctuary as compared to legacy sancs - this is a function of how many sancs are online (1/3rd), so the rewards are more frequent per sanc now that we only have 125 to pay.

How can web site like this one calculate our Sanctuary profit :
https://masternodecap.com/
Our web site is still showing that 40% goes to Sanctuaries.
Should we change it to (100-48.5) / 2 = 25.75% ?


Thanks for supporting Hash code, one more request:
Maybe this is better for Wallet Menu :

WALLET ->
     Windows
         -> 64bit
             -> Installation
             -> Hash code  
         -> 32bit
             -> Installation
             -> Hash code
     Mac
        -> Installation
        -> Hash code  
     Linux
        -> GUI (=QT)
             -> 64bit
                -> Installation
                -> Hash code  
             -> 32bit
                -> Installation
                -> Hash code  
        -> Deamon
           -> 64bit
              -> Installation
              -> Hash code  
           -> 32bit
              -> Installation
              -> Hash code  
           -> Arch 64bit
              -> Installation
              -> Hash code  
           -> Arm 64bit
              -> Installation
              -> Hash code  

[MIP]

BiblePay
1.4.3.3-Leisure Upgrade


** Note: Sancs, please upgrade within 21 days at your convenience **
** Linux and Mac is building **

Mac and Intel Linux (32/64 bit) compiles are ready, ARM (32/64) still building.

[lalexcross]

Hi All, thanks for yor immense and very good job.

How to mining with a multiple wallet on multiple machine, how is the correct config file ?

Thanks again
Cheers
Ale

[MIP]

BiblePay
1.4.3.3-Leisure Upgrade


** Note: Sancs, please upgrade within 21 days at your convenience **
** Linux and Mac is building **

Mac and Intel Linux (32/64 bit) compiles are ready, ARM (32/64) still building.

ARM (32/64) binaries ready.

[bible_pay]

Hi All, thanks for yor immense and very good job.

How to mining with a multiple wallet on multiple machine, how is the correct config file ?

Thanks again
Cheers
Ale

I think the lowest maintenace way to do this is to leave the bulk of your BBP on your home controller wallet, and leave its dedicated CPK on the controller wallet for future voting rights and for the POG campaign.

Step 2:
Create one new wallet.dat on one mining machine, and copy the same wallet out to the other miners.
Create a CPK on one of those miners.
Fund that wallet with any BBP required by ABN (which is currently 0, but will most likely be 256,000 bbp relatively soon).  (Ill announce it when it changes).

All of the miners will share the same CPK and wallet.dat.  

[bible_pay]

is hps in pool (leaderboard) recalculated somehow? if tyes then it is wrong, i shoud have about 1/4-1/3 of pool total hps

The HPS is temporarily being calculated off of how many shares you solved in the pool - until everyone upgrades to the new version then I will look at it again, as the last version had the astronomical diff and couldnt be reconciled to the pool.

[bible_pay]

Sorry I am confused
I thought that Sanctuaries were 40% and will remain 40%
But now I need 3 times more BBP to create a Sanctuary, so I expected 3 times less total number of Sanctuaries, and 3 Times more payout per Sanctuary.

1) Sancs always get half of the net reward - half goes to the heat miner and half to the sanc.  The 40% figure was the amount a sanc would receive with 10% for governance, but now we have 48.5% for governance when including the GSC amount.  But the sancs still get half of what is left.

2) You do get 3* the reward now for a sanctuary as compared to legacy sancs - this is a function of how many sancs are online (1/3rd), so the rewards are more frequent per sanc now that we only have 125 to pay.

How can web site like this one calculate our Sanctuary profit :
https://masternodecap.com/
Our web site is still showing that 40% goes to Sanctuaries.
Should we change it to (100-48.5) / 2 = 25.75% ?


Thanks for supporting Hash code, one more request:
Maybe this is better for Wallet Menu :

WALLET ->
     Windows
         -> 64bit
             -> Installation
             -> Hash code  
         -> 32bit
             -> Installation
             -> Hash code
     Mac
        -> Installation
        -> Hash code  
     Linux
        -> GUI (=QT)
             -> 64bit
                -> Installation
                -> Hash code  
             -> 32bit
                -> Installation
                -> Hash code  
        -> Deamon
           -> 64bit
              -> Installation
              -> Hash code  
           -> 32bit
              -> Installation
              -> Hash code  
           -> Arch 64bit
              -> Installation
              -> Hash code  
           -> Arm 64bit
              -> Installation
              -> Hash code  

Thanks, I e-mailed masternode cap with our changes.  Yes you are correct (regarding the MN ROI portion).  I would have opted to vote to keep sanc payout the same during the release of POG/GSC - but this would be at the expense of our security (pobh rewards would suffer), and I dont think thats a good idea (at least not until we have ChainLocks in Prod, for it to be floated), and I feel it would be better if the community itself approaches with the idea (of entering that proposal) rather than me.

I like the idea on the menu.  I believe that was almost done - but I was too lazy to make a 4 level menu.  We will keep this in mind when the next change occurs on the menu and I will evaluate possibly adding the OS type as the top level selector.

[inblue]

I agree Evolution was a smooth and amazing upgrade to BiblePay! If I may ask some questions as I am trying to understand GSCs.

Shouldn't the leaderboard reset after every superblock? I mean remove the users from it. And then populate it again as the transmissions start to come in? I may be wrong, but I think the leaderboard retains the users and points for 2 cycles (between 3 superblocks) and combines them somehow, so I'm never sure how much points I and others have today, and how much is from yesterday. The only way I've found consistent data is to look at exec health, but that's for the previous cycle, not the current one.

Also, the 'leaderboard' RPC command does not output equal results as the GUI leaderboard - I presume this was already taken care of after the majority of sancs upgrade to 1.4.3.3?

And about these votes:

Code:

"votes": 26,
  "required_votes": 25,

Every day we seem to "barely" pass the required votes. Is voting automatic? If so, why don't the 136 sanctuaries vote? And why are the votes slowly coming in over the day?

Oh and just now I saw the votes number go down from 27 to 26, how does that happen and what does it mean?

Thank you very much and keep up the amazing work.

[bible_pay]

I agree Evolution was a smooth and amazing upgrade to BiblePay! If I may ask some questions as I am trying to understand GSCs.

Shouldn't the leaderboard reset after every superblock? I mean remove the users from it. And then populate it again as the transmissions start to come in? I may be wrong, but I think the leaderboard retains the users and points for 2 cycles (between 3 superblocks) and combines them somehow, so I'm never sure how much points I and others have today, and how much is from yesterday. The only way I've found consistent data is to look at exec health, but that's for the previous cycle, not the current one.

Also, the 'leaderboard' RPC command does not output equal results as the GUI leaderboard - I presume this was already taken care of after the majority of sancs upgrade to 1.4.3.3?

And about these votes:

Code:

"votes": 26,
  "required_votes": 25,

Every day we seem to "barely" pass the required votes. Is voting automatic? If so, why don't the 136 sanctuaries vote? And why are the votes slowly coming in over the day?

Oh and just now I saw the votes number go down from 27 to 26, how does that happen and what does it mean?

Thank you very much and keep up the amazing work.

Thanks for the compliments!

On the GUI leaderboard being different than the 'leaderboard' command, I see the issue.  The GUI is still using the amounts driven by the prominence % (like leaderboard used to do) and not the amounts from the GSC; OK that is an easy fix, we will fix this in the next release then the GUI will also match the leaderboard output to the penny - good catch.  Until the next update note everyone - its not off by much (its basically multiplying by a % that has a couple digits cut off).

So on the votes first.  Prod requires contracts to have at least 20% of the enabled sanc count (thats about 26 now) in order for the GSC to pass.  So that explains the required_votes value.
The reason we end up with barely enough every day is because the sancs are currently programmed to only vote if they need to (IE they check to see if the contract is passing) and ignore it if its already got more than enough votes.  However, they have a very intelligent rule.  If the sanc finds the popular contract hash disagrees with its internal view of the contract it will always vote against the popular one (and then it will create a new one and vote for it).    So remember at the time we had 500+ sancs, I was thinking along the lines of efficiency (IE not to make every sanc do the work if we had 20% in agreement).  I also think with this current logic - the other facet is if the contract changes - the sanc quorum must be nimble enough to make a quick change (and not have to reverse the entire farms votes of 100% being wrong) - since they do actively watch and monitor the voting outcome every 5 blocks, so they *will* jump in and vote for it if necessary.  So Im thinking this is still predominantly good given the volatile potential nature of a competetive change in contract(s).  Now on the downvote, that can happen if the contract changes (like right now we had a leisure upgrade that changed consensus).  You will see the nodes who upgraded will be voting on the new style contract, and the old nodes on the old and only one will win.  (We have a tie breaker piece of code in there also).

Finally on the leaderboard view itself resetting.  So the way this works currently is the GUI leaderboard checks the height of the *next* superblock every time it updates (see exec health).  We do report on the *future*.  So right now with the next superblock being 124045, leaderboard gui is reporting on everything from 124045 down to 123840 for its contents.
(The reason you dont see a sharp reset at the modulus point (IE the point when block 123840 ticked to 123841) is because at that point in time, we already have tithes and POGs in the chain from 123841 to 123636.  So this is the reason there is never an absolute reset - because people are contributing to the future right now as each block passes (for the next superblocks view).

[bible_pay]

** Pool letter writing reward increased to 19K **

[inblue]

Thank you for the thorough response!

Now on the downvote, that can happen if the contract changes (like right now we had a leisure upgrade that changed consensus).  You will see the nodes who upgraded will be voting on the new style contract, and the old nodes on the old and only one will win.  (We have a tie breaker piece of code in there also).

So if all or most nodes are on the same contract, the superblock should always pass with enough positive votes, correct? So that should not be a concern?

So the way this works currently is the GUI leaderboard checks the height of the *next* superblock every time it updates (see exec health).  We do report on the *future*.

Hm, but why show the future instead of the present, the current state? I mean even you got confused when you pasted the rewards from a different superblock, which is completely understandable. I am also very confused by this representation, could it be possible to make the leaderboard only show the present state? (see my next paragraph below)

The reason you dont see a sharp reset at the modulus point (IE the point when block 123840 ticked to 123841) is because at that point in time, we already have tithes and POGs in the chain from 123841 to 123636.

How do we have tithes from before the last superblock? Why are they extending to the next cycle?

So right now with the next superblock being 124045, leaderboard gui is reporting on everything from 124045 down to 123840 for its contents.

I manually sent a transmission between superblocks 123635 and 123840. After that, I didn't send any transmissions (I disabled automatic transmissions). So I shouldn't be in the leaderboard now if it reports on everything from 123840 to 124045, right? But I am there. So it looks like it's showing the past, not the future, hm?

By the way, when I wanted to disable automatic transmissions, I used the the config key disablegsctransmission=1, but it denied manual transmissions too, like disableclientsidetransmission=1. But then when you said that miner needs to run for automatic transmissions, I just use gen=0 as a workaround.

[bible_pay]

Thank you for the thorough response!

Now on the downvote, that can happen if the contract changes (like right now we had a leisure upgrade that changed consensus).  You will see the nodes who upgraded will be voting on the new style contract, and the old nodes on the old and only one will win.  (We have a tie breaker piece of code in there also).

So if all or most nodes are on the same contract, the superblock should always pass with enough positive votes, correct? So that should not be a concern?

So the way this works currently is the GUI leaderboard checks the height of the *next* superblock every time it updates (see exec health).  We do report on the *future*.

Hm, but why show the future instead of the present, the current state? I mean even you got confused when you pasted the rewards from a different superblock, which is completely understandable. I am also very confused by this representation, could it be possible to make the leaderboard only show the present state? (see my next paragraph below)

The reason you dont see a sharp reset at the modulus point (IE the point when block 123840 ticked to 123841) is because at that point in time, we already have tithes and POGs in the chain from 123841 to 123636.

How do we have tithes from before the last superblock? Why are they extending to the next cycle?

So right now with the next superblock being 124045, leaderboard gui is reporting on everything from 124045 down to 123840 for its contents.

I manually sent a transmission between superblocks 123635 and 123840. After that, I didn't send any transmissions (I disabled automatic transmissions). So I shouldn't be in the leaderboard now if it reports on everything from 123840 to 124045, right? But I am there. So it looks like it's showing the past, not the future, hm?

By the way, when I wanted to disable automatic transmissions, I used the the config key disablegsctransmission=1, but it denied manual transmissions too, like disableclientsidetransmission=1. But then when you said that miner needs to run for automatic transmissions, I just use gen=0 as a workaround.

The superblock should always pass, unless a high percentage of sanctuaries are off line (regardless of the version they are running).

The future superblock is the current state(s) representation, so it is already that way.  We are tithing now, these are going into blocks that are assessed in the next superblock height.

They aren't extending into the next cycle.  If you look at exec health, get the next superblock height, subtract 205 from that, and that shows that height (NextSuperblock to NextSuperblock-205) is what is in the gui leaderboard.  We could put a heading on it that says "N - N+205" for example.

I actually didn't get confused when I pasted it, I pasted the output of 'leaderboard false last' which was the last superblock as of the morning, and Snat pasted the chain explorer of the last one he observed that passed - so technically neither of us were confused.  (I deliberately waited a day, because worldpeace took up the first one being early).  I just said sorry to make him know that I was not blaming him for pasting the current height.

Hopefully this answers all your questions and clarifies all of it now.

[capulo]

Hi All, thanks for yor immense and very good job.

How to mining with a multiple wallet on multiple machine, how is the correct config file ?

Thanks again
Cheers
Ale

I think the lowest maintenace way to do this is to leave the bulk of your BBP on your home controller wallet, and leave its dedicated CPK on the controller wallet for future voting rights and for the POG campaign.

Step 2:
Create one new wallet.dat on one mining machine, and copy the same wallet out to the other miners.
Create a CPK on one of those miners.
Fund that wallet with any BBP required by ABN (which is currently 0, but will most likely be 256,000 bbp relatively soon).  (Ill announce it when it changes).

All of the miners will share the same CPK and wallet.dat.  

soo i will need only one main wallet with bbp and some cpk and several miners wallets without bbp which will share main cpk to mine?

[bible_pay]

Hi All, thanks for yor immense and very good job.

How to mining with a multiple wallet on multiple machine, how is the correct config file ?

Thanks again
Cheers
Ale

I think the lowest maintenace way to do this is to leave the bulk of your BBP on your home controller wallet, and leave its dedicated CPK on the controller wallet for future voting rights and for the POG campaign.

Step 2:
Create one new wallet.dat on one mining machine, and copy the same wallet out to the other miners.
Create a CPK on one of those miners.
Fund that wallet with any BBP required by ABN (which is currently 0, but will most likely be 256,000 bbp relatively soon).  (Ill announce it when it changes).

All of the miners will share the same CPK and wallet.dat.  

soo i will need only one main wallet with bbp and some cpk and several miners wallets without bbp which will share main cpk to mine?

You can do it either way.  One CPK across the board, and manually unlock all your miners with the headless password every time you reboot them, or two cpks, one for the mining machines and one for the controller wallet.

No, but the mining machines wallet.dat would need funded if our ABN required weight > 0.  Otherwise they will stall out when that height passes.

[afeno]

Is pool.biblepay.org working fine?
I see my miner (named pccd2) disappearing from "My Leaderboard". However, the Wallet is still active and in theory mining in the pool.

EDIT: After restarting the wallet, it is showing up again in the pool. I will keep monitoring it

[dave_bbp]

BiblePay
1.4.3.3-Leisure Upgrade


** Note: Sancs, please upgrade within 21 days at your convenience **
** Linux and Mac is building **

Mac and Intel Linux (32/64 bit) compiles are ready, ARM (32/64) still building.

ARM (32/64) binaries ready.

Excuse my stupid question, but where do I find these? The website doesn't list anything for ARM; the latest release on github is 1.4.3.1 and there seems to be no repository for ARM.

btw: up to now my windows QT wallet hasn't crashed again

[capulo]

Hi All, thanks for yor immense and very good job.

How to mining with a multiple wallet on multiple machine, how is the correct config file ?

Thanks again
Cheers
Ale

I think the lowest maintenace way to do this is to leave the bulk of your BBP on your home controller wallet, and leave its dedicated CPK on the controller wallet for future voting rights and for the POG campaign.

Step 2:
Create one new wallet.dat on one mining machine, and copy the same wallet out to the other miners.
Create a CPK on one of those miners.
Fund that wallet with any BBP required by ABN (which is currently 0, but will most likely be 256,000 bbp relatively soon).  (Ill announce it when it changes).

All of the miners will share the same CPK and wallet.dat.  

soo i will need only one main wallet with bbp and some cpk and several miners wallets without bbp which will share main cpk to mine?

You can do it either way.  One CPK across the board, and manually unlock all your miners with the headless password every time you reboot them, or two cpks, one for the mining machines and one for the controller wallet.

No, but the mining machines wallet.dat would need funded if our ABN required weight > 0.  Otherwise they will stall out when that height passes.

i dont understand , i'll wait for some howto

[bible_pay]

BiblePay
1.4.3.3-Leisure Upgrade


** Note: Sancs, please upgrade within 21 days at your convenience **
** Linux and Mac is building **

Mac and Intel Linux (32/64 bit) compiles are ready, ARM (32/64) still building.

ARM (32/64) binaries ready.

Excuse my stupid question, but where do I find these? The website doesn't list anything for ARM; the latest release on github is 1.4.3.1 and there seems to be no repository for ARM.

btw: up to now my windows QT wallet hasn't crashed again

Sweet, thats awesome!  I was hoping it is that, as the only known error is maybe some old unspent output from classic that zapwallettxes gets rid of.


You can find ARM under biblepay.org | top level menu | Linux Daemon | Arm | then expand that menu to see the bitness.
(I'll look into making a better top level menu during next deploy).