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

Also, any individual miner/user who is on the short chain, to find out if you are on the wrong chain:
getblockhash 128510
53a832eee6d4120be9ab84cb34747b6cf59878c50c1f96eb30d12d104508cea1

If your hash does not match, please clean your data files directory, deleting everything except wallet.dat and restart.
Or restart with -erasechain=1

confirmed #128510 blockhash in 1.4.3.9 version: 53a832eee6d4120be9ab84cb34747b6cf59878c50c1f96eb30d12d104508cea1

I don't know when happen, I am trying to reindex the wallet now.

To Sancs:

Just to clarify all, any of you who upgraded your sancs over the last 10 days or so, you do not need to upgrade if you are on 70734 (regardless of the biblepay version #).

Type 'getinfo' and see the protocolversion to find out (from a sanc). 

SX, CX, and Chainz have been notified.

Once we see 75% of our sancs on 70734, we can open back up, and we can try a 1000 ABN to start with (when the weather clears up).

Does your chain currently match this one:
getblockhash 128510
53a832eee6d4120be9ab84cb34747b6cf59878c50c1f96eb30d12d104508cea1
As Im currently mining right now.

 

One more things , in the POBH mining mode, the usage of CPU is down to 0% now.
It seems need a transition period to fix.

**** SANCTUARY MANDATORY UPGRADE REQUIRED TODAY ****


1.  Due to 40% of our network still running the old incompatible protocol version (70732) which caused a fork overnight, we must ask everyone to upgrade to 70734 immediately.  This is BiblePay v1.4.3.9.  https://github.com/biblepay/biblepay-evolution/commits/master
2.  I have set the enforcement spork requiring all sanctuaries to be on 70734 as of later today.
3.  Sanctuaries who do not upgrade will start to lose payments (the upgraded sancs will vote against the old sancs).
4.  Older sancs who do not upgrade will automatically fall out of the GSC quorum (therefore they will not hurt BiblePay in a negative way) after this setting is enabled.

I asked SX to go into maintenance.

So, great news!  As you all know, you know how dissapointed I am when I hear the word "fork".  
I can see exactly what happened here.  It's so refreshing to know there is a clear cut reason this happened at block 128350.  (IE it wasn't a POW or ABN problem, it was a clear cut sanctuary supermajority problem).

Yesterday, during our superblock quorum, at block 128350, with gsc gobject b25ad15f4c53cad63150f586babab2fe9ee1d26e3b06407fe68256624ac6408b, we had 89 yes votes and 52 no votes.  (I didnt realize the sanc network was floundering to this great of a degree, otherwise I would have done something).  So basically what this means is the GSC vote barely passed with enough votes to satisfy the superblock to emit, but with enough detractors to cause a split (when taking into account the view on the lower protocol version on half of the network - ie version 70732).  I see we still have 40% of our sancs on 70732, and we gave them 7 days for the mandatory upgrade, and they did not listen to us.  They are still running the old version now.

Just for those that are interested to know that I know what Im talking about,  the forkpoint of the chain that followed 70732 sanctuaries was here:
     height": 128485,
    "superblock": false,
    "hash": "0bed6db1c540a32966bfce73f774307c9c80eb60e10efa74ba25198882e4d359",
    "difficulty": 911.7417531655889,
    "chainwork": "0000000000000000000000000000000000000000000000000b484140289a2873",
    "branchlen": 136,
    "forkpoint": "a8e5dca07cd1543d42985948fce2f40cf7ed216e3ad3114c8ed0aa903d09b438",
    "forkheight": 128349,
    "status": "headers-only"
The fork occurred at block 128350 and the branch is 136 long now with a diff of 911 (and chainz is following the lower work branch right now).


So what we need to do is recover from this fork with our partners first, then we need to force a mandatory upgrade on all the sancs today.

Fortunately, in our last two versions, we have added a method to help force a mandatory (if those 70732 sancs dont upgrade they wont get paid in the future).

Let me take a look at the root block of this issue.  For now, explorer.biblepay is the right chain (it had a 30K diff).

I would assume the official one which is longer and has higher difficulty

edit: Looks like southxchange is on the shorter chain... so I would avoid depositing/withdrawing from there until it is all sorted

It has been forked.

#128437
Official :a28fe792d0e02399d7a4a796ea2f6d04b38ace29111d7eb2d17580df322d0030
chainz.cryptoid.info : 924943f072d2c99f8e2c16efd8c50c27307edadb28664d26f49874466d3d0af7

so , which way is right?

Which Block is correct chain ?
http://explorer.biblepay.org/
https://chainz.cryptoid.info/bbp/

I think so. Also as sunk said, LLMQ could add extra protection but first of all we need a strong foundation.

i had similar thoughts before, that anb will be increasing over time, if abn 256k will no be enough. but in this case 256k seem to be much so lents start with something lower
do you know how much coins was used for pow mining? i think we must cover 205 blocks and at least 4x to have some better diff so ~ 200m bbp staked. i'm not sure if there was so much coins staked. we have 1600m coins mined yet. ~ 1000m are in masternodes. ~200m pow, maybe same or more in pog, ~200m, not everybody is mining, so there must be a lot of unused coins... so this is more than optimistic scenario

but i think we will be fine with 64k abn or maybe start with 32k to be sure and increase by 5% per month or so

These two explorers do not match. Which fork is correct?

http://explorer.biblepay.org/
https://chainz.cryptoid.info/bbp/

Previous 30 Day Statistics from Monstersights plugin for BiblePay.org

Please do not PM me again -- it is unwelcome communication. As a benefit to you, I will not post here again. Sound good? Please leave me alone.

Sun, please see your PMs.

Updated.

Thank you for the heads up.

Hi,
Please update www.biblepay.org main page, especially this:
40.0% Masternodes (Sanctuaries)