Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 157. (Read 243386 times)

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.

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?

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.

Thank you for the thorough response!


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?


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)


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


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.

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

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).

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:

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, 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.

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.

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.  

ARM (32/64) binaries ready.

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

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

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  

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

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 **

Awesome, thanks for answering. Of course I did not unlock the wallet before trying to exec cpk. Stupid me.
Now it worked and I am in the leaderboard (sending the payment manually because I don't like to leave my wallet unlocked ...

I also tried the zapwallettx 1, let's see if it helps with the random wallet crash.


Other than that it seems like the transition to EVO went smooth. I'm excited to see what the future holds for this coin.

Yeah, whats happening is the class is looping through every RPC command to gather help() and when it hits that command there is no help so it tries to run it.

I'm fixing it now then help will work again and it won't get executed by accident.

Now I unlocked the wallet and typed 'help' again and got this:


There was also a small payment to myself.

But I didn't understand why 'help' triggers any other command instead of listing the available commands.

Edit:


Alright, thanks!

We will fix this today before tonights release.