Does anyone know about purepool?

Try this to launch the gui:
cd ~/biblepay-evolution/src/qt
./biblepay-qt

We have no incidences of crashes; try deleting all your files except wallet dat and resyncing.

Also, we would need more info - as you could be referring to something other than a crash.

For example, if the wallet exits with a message, post the message as that's not a crash.

Hi Sun,

Although I don't have a lot of time to reply right this second as I am babysitting - I want you to know I accept your apology because I feel that Jesus Christ would want us to make amends for one, and for two, I want you to know I have the love and mercy of God in me.  Love is patient and kind and always gives second, and third, and fourth chances as long as both parties are willing to meet in the middle then there is hope.  

Welcome back.  I will ensure your name is not on any ban list.

Thanks, and welcome back, and best wishes to our new family.

I'm surprised no one else has helped you yet.

Please see this page:

http://wiki.biblepay.org/Evolution_Upgrade

An utterly fascinating conclusion, and thank you for your insight, and its always good to bring in fresh wisdom.

Ok, the release process has been updated to always ask us for the version, and to update the version automatically.

Please refresh the page now.

Where does it say that, we have multiple pages and links, and OSs and bitnesses, and is it doing it from an installer or from the output of a page when you view it?

Awesome, this is so great to have a renewed MacOSX signing license, and it opens up the possibility for BiblePay to release the Mobile BiblePay Wallet for iPhone (Finally); as we promised.

Mobile Staking and Mobile Tithing, here we come (eventually), for iOS.

Yes, and I think its easier to explain 'why' I say this to give you the freedom to do it whichever way you want.

First of all, you can use one wallet (globally) if you want, but I don't recommend copying the home controller wallet out to mining machines because of the security risk.

So thats the primary reason I mention creating a second wallet.dat for mining.

The reason we use one wallet.dat for all the miners is to allow you to easily manage funding it with ABN funds, and setting up One CPK for mining.
The CPK is required on the mining machines to sign the ABN mining transaction.

The other thing to know is the miner will not be able to create a block if the wallet is locked; we have a command (./biblepay-cli headlesspassword password) that will unlock a locked wallet.  If its a mining wallet with less funds in it, you might choose not to encrypt it and therefore not deal with this command.  However I believe you can script this command to unlock the wallet if you decide to encrypt it.

A nice chap at CoinMarketCap volunteered to allow us to write a short description of our coin:

https://coinmarketcap.com/currencies/biblepay/

I'm excited about the exposure this gets.  May BiblePay expand, for the orphans First, in Jesus Name.

You just make one wallet.dat for home and one for the miners, and make one cpk at home and one on the mining wallet.
Could you please expand on what part is hazy still, as from my perspective the miner only needs the genproclimit and the CPK is a one-time command.

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

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.

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.

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

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.