Ill look at this a little later today, but the key is setting up your auto-withdrawals so you get paid automatically once per morning @ 9am.

Thanks, but unfortunately his wiki shows the results to be 50% or more edge for people that run BiblePay of 10 instances of 10 VMs inside one computer, vs the One computer simply running on all threads, so I don't feel we can discount it as marginal without proving it completely wrong.

I do agree with you, if someone had a 1% edge after installing 5 copies of biblepay on a machine, it wouldnt be worth checking.

So I need help, I do want to prioritize checking this, and give a professional opinion of what caused it in 2017, but first I want to prove its completely mitigated.  Ill fire a couple up today and do some tests, but I really want help from someone with a more powerful machine to test it and also this gives cross-reference to the issue.

Im happy that they created a small feature (as compared to some of the other valuable features they have in the arsenal) to address 'distributing currency equally' to a group in a decentralized chain, but lets put this one in perspective.  Its one thing to develop Rain V2 (thats a way to mass crypto pay the group) as compared to being a truly decentralized autonomous charity.

The one thing that stops us from being a full fledged DAC is not having a sub-market for 'orphan shares' - sort of like the thing the housing market did with the collaterlized debt obligations (slicing them up into shares and selling them in the sub-markets), and I think we should take a look at that in our GSM in 20 days as I feal its technically feasible over the long term.  If we could pull that off we could truly be a 100% decentralized DAC, that would be impressive. 

No - incorrect - this was posted in September 2017, back when we had V2 of POBH.  Thats before we released Sanctuaries.


Thats why we have to prove this is no longer an exploit for miners since V3 of POBH (we are up to V14 now).

Yes, we need letter writers, only 10 written out of 80.  Reward is above 8K BBP.

Well, sort of, it was back when I only had post 115 lol, and did forget we made Inblues results into a wiki page at the time yes, but, in addition, I remember we had 12 versions of POBH, and this testing was done during the 2nd or 3rd iteration, Inblue ran those tests, and we specifically addressed those exploits in later versions of POBH - so after time, I believed there was no longer a multi-wallet exploit, and forgot about the whole original situation. 

So let's dig this back up and see how this fits in today.

I never saw this document, and I think what I want to do now is have someone test this publically here, and tell me if there really is any multiwallet exploit Now, and let us fix our hash algo if there is before we reopen the exchanges.

I want progress halted until I know the truth, and will not re-open on the exchanges until we work through this together!

There should be NO EXPLOITS IN OUR PRODUCTION ENVIRONMENT FOR USERS WHO ATTEMPT TO STEAL COINS THROUGH SYSTEM CONFIGURATIONS!

Yes, this is exactly right, BiblePay Evolution is going to be our next version, and it includes all the features of Dash Evolution (deterministic sanctuaries, chainlocks, non-financial transactions, atomic trade and lightning support, daaps, decentralized api, segwit, all the new DIPS, all the latest bitcoin commits for security, all the stuff that happened over the last year in Dash, the Depends system for devs, c++14 source code, new compiler support, easier building, etc) lots of good things to be a base from.  And we do whats called a "re-base", meaning we merge our biblepay code into Evolution, and offer a new release. 

This will be in testnet in 5-6 days.  I don't anticipate a huge change or learning curve or problems in test, as Ive confirmed we have 95% compatibility now. 

Yes, I see the difficulty is now reading correctly, the latest block is the right hash, great!  Thanks a lot, you da man.

Diff 17K!  Alright, now we're back on track!

Thanks.  On the upgrades, yes absolutely.  Its not only absolutely, but I think you will be pleased when you see the next plan completely demarcates all future prod updates, and adheres to the Dash release schedule instead. 

To see the plan, check back in about 5 more days and look for the announcement for the new Testnet thread.  Im going to outline the entire plan in that wiki and it should be a very positive change for biblepay.

We believe we removed the cause of the crash in the latest version.   (After upgrading start with cleared .dat files).


The explorer should technically be able to handle forks;  Ill email you.

It looks like explorer.biblepay.org is still syncing.  No unfortunately I believe Slovakia shut his down.

TheSnat was building a backup explorer, Im not sure if its done and ready for beta yet, Snat?

Please see if TheSnat will help you first.  We are trying to grow.

What chart do you like the most that we could add to pool.biblepay?

What thing about pool.biblepay's UI do you dislike?

Just give us one wish-list-item from each point would be best.

Yes, it might take us 24 hours to get back on track - due to the way 'masternode winners' works, but anyway, everything is the same as before, except the reward should be more like 6K for a while (since we have a 20% gov. escrow from the gross block, then we split the net block POW reward with the sanctuary).

Not required anymore; please see 'exec hexblocktocoinbase' in the core, where the pool calls to find the legalnarr, notice how it skips over that subprocedure now.  

POG is temporarily gone for now, we are 100% POBH (with a higher reward 50-50 after governance).

We will be discussing a new smart contract in testnet in 7 days.  This will have a 'cost center' and 'campaign' concept in it, and I believe it will have a form of POG campaign in it also.
Ill post more info about it asap.

Most likely we will be on POW for 60-90 days while we make a quality product that does not require Upgrades to make changes...  Things are going to change around here, and I hope that new beginning already occurred with 1201.

I don't want to see updates if we don't need them until we release Evolution.

Its very clear when you look at the code that was checked in on 1.2.0.1 and it fixed the problem.

Yeah it was the chicken & egg problem.  You cant have Sancs agreeing on the payment height without a POW consensus, and we couldnt have a POW consensus without Sancs telling us the exact list of sanc-public-addresses and amounts to pay (so we went in loops).  Then we disabled the payment checking rule and made it into a future spork rule - and now the nodes at the highest height are not rejecting blocks, and now the sancs are coming back online.

With minersleep=-1,  the tithe parameters removed, and genproclimit=10 Im seeing 100% cpu use on windows7.

Please try that.