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

I have put a new pc to test solo mining @ 1.4.4.5

Is it can be ignore the message in "poolinfo5" if that ensure the wallet have enough ABN weight?


  "poolinfo5": "Internal ABN: Invalid 1564161497; ",
  "abninfo": "ABN: OK; ",


"weight 125000.00": 161401.5844444444,
  "total_required 125000.00": 403854

I believe all 45 Presidents of the United States, including Ronald Reagan, Donald Trump, George Washington, Theodore Roosevelt, Andrew Jackson, Jimmy Carter and John F. Kennedy would approve of BiblePay for it's goodwill towards helping orphans globally and spreading the word of God, and also for our cutting edge technology we inherited from Bitcoin and DASH, and for our original accomplishments.

Did you know all 45 American Presidents were Christian for most of their lives? 

Out of our 45 presidents, only Abraham Lincoln and Thomas Jefferson departed or distanced themselves from Christianity.  Jefferson was a staunch follower of Jesus until late in his life when he questioned Jesus' divine nature.  Lincoln's friends all said he was Christian, but he believed in the separation of Church & State to a degree that he would not talk about religion while President.

The other 43 presidents proudly maintain that they are Christian, being inaugurated with bibles.   37 of these 43 are Protestant.

Imho, I feel we should give God praise and Glory for what has been accomplished in America by people who hold the highest post and executed their best judgement from a Christian perspective.  I do not include what some conspiracy theorists say more recently about the Deep State (that the US are warmongers) -- but I am referring to the general 200 year span and the accomplishments in the industrial revolution. 

Unfortunately, some believe Satan has secretly infiltrated the highest office over the last 20 years, ushering in an era where politicians are elected and disguise themselves as Christians but execute non Christian policies. 

God Bless the US, and all Countries!  God bless all appointed Christian positions!

That's right Rob, we currently have 3 hurdles piling one over the next:
- We need to know how to create PPA dependency for relic toolkit library used by chia-bls
- Then find out how to create chia-bls as PPA using the relic PPA as dependency.
- Finally, the chia-bls library used by Dash (and us) is not even the official upstream, but a heavily customized one by Dash devs, so we need to know how to add the Dash patch to chia-bls to the PPA buid process.

That's why we are currently compiling our own linux binaries for Intel and ARM 32/64 architectures
You will find all of them in the "Wallet" menu options of www.biblepay.org website.

Or you can also compile yourself. I you have problems to compile you can contact me on Discord channel.

Hi Rob,

Thank you so much i now get it.

Really appreciate it.

I now know were my coins are.

Thanks

Hi Prof Budinga,

So to enable coin control, please go to settings | Options | Wallet | Enable Coin Control Features | Ok.
Once you do that you can go to Send Coins | Inputs | Tree Mode.  Find one address with a lot of coins | Right Click | Copy Address.
Then you can paste it into chainz.  That will show just the coins in tree mode associated with that address.
Chainz does have an expirimental tool that guesses at the owners balance, but Im not sure how close it is.
Yes, that txid - address you pasted just shows the history of that particular address.

Chainz:

https://chainz.cryptoid.info/bbp/

No, I don't believe that PPA issue was ever cracked yet, right MIP?  We still can't build chia-bls due to chia not being available in the PPA upstream.

So, to upgrade a node you compiled yourself is very easy:  See the Upgrade biblepay section:
https://github.com/biblepay/biblepay-evolution/blob/master/BuildBiblePay.txt

Are the PPA Ubuntu packages ready to upgrade the wallet?
I remember that last time I had to compile the wallet. And I don't remember how I did it... 

Hi,

Thank you for the quick reply much appreciated.

the transaction hash for the 10k is: 02912cdd6be98a11c38dc54a01764f0c22907580c84eb7e63a6501cf4ad99cc2
that seems to be working fine. as i am just waiting for confirmation on the exchange 21/40. my funds all seem to be there now, as with the backup wallet restore it just works.

ah ok i think i get what you mean. what do u mean by coin control, Im using the windows version.
Although i think i may have found the right address well at least half the coins show up on the chain in there.

Thanks

Hi Prof Budinga,

Thank you for being a veteran member, and thanks for the compliments. 

So on this issue, on a side note, if you have any empty (orphaned) transaction rows in your wallet, you can start once with '-zapwallettxes=1' and they will be removed (but that doesn't sound like the issue).

For this can you please paste the txid of the 10k you sent, and Ill look? 

I think the issue is that each distinct keypair created in the wallet can hold a certain balance (for anonymity purposes).  So the BX can only see what that particular address started with (not your entire wallet balance).  If you go to coin control, and sort by Address, and pick another address where you have most of your funds, you can navigate to chainz, and paste in *that* address and most likely your full history will be shown (for that address).

Hi Rob,

By the way great job with the coin, i have been a supporter from day 1.

I seem to have run in to a slight problem. After upgrading i wasn't receiving any coins sent to me.
I then did a complete re-index and my balance was missing loads. it said i just have 6k. so i restored a backup wallet, all my coins were there. So i sent to the exchange 10k just to test,
and it worked. Now my issue is the block chain explorer shows i had 6k, something strange is going on?

I was able to upgrade daemon to v1.4.4.5 for the explorer successfully,
But I am getting build errors on my local ubuntu machine for .o files


Ill try deleting the .o files and remaking and report back

UPDATE: Ran command:
Builds successfully now

MacOS DMG and Linux Intel 32/64 bits binaries ready
Linux Arm 32/64 binaries still compiling

EDIT: ARM binaries also ready

looking forward to the linux update

BiblePay
1.4.4.5-Mandatory Upgrade

- Ensure gobjects are propagated through entire network
- Add configurable key : changequantity=n (this allows you to specify
how many change outputs you wish to receive from GSC transmissions,
default is 10)


** Mac/Linux will not be ready for 3~ hours **

** This upgrade is for the entire network:  Users and Sanctuaries
Except:  Exchanges may run in litemode=1 if they wish to wait for the next mandatory **

** It is recommended that you delete banlist.dat **

Technical explanation that I believe explains all prior forks (as of Biblepay-Evolutions start date), and most (if not all) sync issues, and why we have a propensity to have certain nodes 'repeat' behavior (as in fall out of sync more than others):

So back in the days of PODC (Dash < 0.12.0 days), our sanctuaries had no gobject rate limiter in place.  This means that although each sanctuary was only allowed to create one PODC contract per day, all the votes for that contract would be accepted by every node without fail, as the votes propagated.

After Dash 0.13.0, a rate limit was put in place to prevent a sanctuary from spamming the network with invalid gobjects and invalid votes (and basically ddossing them with a lot of extra processing work, and space to hold the objects).  We inherited this, but the reason it didnt break until now, is because it took an analysis to find out the nodes that failed propagation had a gobject creation rate just above the threshhold (.00000040 objects per second-cycle).  In laymans terms this means our sancs in this world could create one contract per week, but if the same sanc was unlucky enough to create an extra contract, the create would succeed, but the data would fail to propagate to the entire network (I have proof of this).  This is because the *receiving* rate limiter was rejecting the data (not the creation limiter).

So now how do we explain this split-network and d-dos issue.  Luckily we have a smoking gun (our gobject cache) that shows 20% of the sancs were voting in their own "private" network.  Not because they were nefarious, but it formed naturally when they refused the daily gobject, they created their own, they voted on their own private channel. 

So now lets find out how did the same nodes repeatedly fall out of sync?  Because during mnsync, peers.dat is used to find the first connected sanctuary to pull gobjects from.  I assume the peers.dat order (being unchanged on a resynced node) would cause a node to repeatedly try the same sanc for gobject sync (which has 20% of the votes) to pull data from *again* (unless peers.dat is deleted).  Then this viscious cycle continues, because the node stays in sync for N-205 blocks until the next GSC, failing to approve the voted for contract.

So here is the mitigation plan, and I believe this is going to be a solid upgrade:

- Fix the math required in the wallet for BiblePay specifically, for the receive rate buffer
- Ensure Cameroon One is merged in to minimize impact over the next 30 days
- Release a mandatory for the entire network
- Give exchanges the option to run in litemode=1 and wait until October, or to upgrade now


Once this is ready, I will notify everyone.

We also need to modify testnet as I believe this is affecting testnet as well.

Your machines are probably out of sync again.
I finally discovered the root of the problem that causes those same machines to repeatedly go out of sync; thank God for this. 
There is always an IT explanation for things.

For now, please check your hash against chainz, then resync if necessary.

Ill announce a mandatory as soon as possible (Im trying to make sure we have what Cameroon will need in first, so we dont bother people more than once in the next 30 days!).

Ive asked our exchanges to run in litemode (which makes them immune to this issue).


(You can also try litemode=1 if you want, but you must be in sync first).

With the latest version of the wallet, shouldn't it automatically recover from a stale block after a period of time?  None of mine seem to be doing that...

Pool is resyncing now, give it 10 more mins and it should be fine.

OK, so fortunately I have the forensic data from the pool that explains this situation.  When the pool worked through the GSC superblock height @ 09:30 PM CST last night, it didnt have the govobj in its govobj cache, therefore it didnt believe the GSC superblock was valid, so it rejected it.  

2019-07-24 02:24:47 CMasternodeMan::CheckAndRemove -- Masternodes: 184, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, nDsqCount: 0
2019-07-24 02:24:48 block.vtx[0]->GetValueOut() 4270 <= blockReward 4270
2019-07-24 02:24:48 IsSuperblockTriggered::SmartContract -- WARNING: No GSC superblock triggered at this height 133680. IsSuperblockTriggered::SmartContract -- WARNING: No GSC superblock triggered at this height 133680. Memorizing prayers tip height 133679 @ time 1563935088 deserialized height 0 ...Finished MemorizeBlockChainPrayers @ 1563935088 EGSCQP 133680.000000 CHAIN_NOT_SYNCEDUpdateTip: new best=d850e653f734dea6db8741b4b45b836a1d23e7df2d3af24313a7d5e255241d70 height=133680 version=0x20000000 log2_work=59.51628264 tx=1101419 date='2019-07-24 02:24:37' progress=1.000000 cache=6.9MiB(0txo)
2019-07-24 02:24:48 AddToWallet 89caca51d79e173646a21e4d8b18c9e7dccb25bc133a8c37a9db2c3e333bffcf  update
2019-07-24 02:24:48 {PNB}: ACC   Prayer Modulus 0  Prayer Modulus 0 complete ERROR: AcceptBlockHeader: prev block not found
2019-07-24 02:25:05 ERROR: ProcessNewBlock: AcceptBlock FAILED: bad-prevblk (code 0)

(I'm resyncing the pool now).

As far as our current network state:
The chainz and the explorer.biblepay explorers seem to be correct.  SX is correct.   My sanctuary report is 98% correct-- however I see one sanc has chosen this shorter chain with low diff.

(If everyone could just double check their hash against one of our explorers, just make sure your diff > 2000 right now and the hash is correct).

I've seen this happen to the pool specifically a few times now.  We are going to need to address this issue permanently as its unacceptable.

We need 100% accuracy going forward.

I'll investigate this gobject propagation failure and make this a higher priority than our next release and our next set of features - And I will put a plan into place that gives us a failsafe method to receive the data for the GSC superblock.  (I feel as if the older protocol (when we had PODC) was much more resilient in that nodes missing the contract recovered.)    I believe we have more of a propensity for nodes to miss gobjects in the current environment.  If we need an emergency patch that puts the gobject in memory (IE an emergency sync) within 20 blocks of the GSC height, then we will need to have this in place as its unacceptable for any node to miss the govobj sync when 98% of our nodes have the object in memory.


PS  One very interesting thing I found, the sanc that went out of sync is the same exact sanc that went out of sync during the last instance.  I find it extremely odd that after deleting the chain files and dat files the same sanc goes out of sync.  Its almost as if one particular network segment is getting hit (unless I forgot to delete the banlist.dat, but those bans usually expire in one day).  We'll get to the bottom of this, we will search for the actual gobject hash.

PS2:  The great news is I can see that this is not a network banlist issue; I can see the winning superblock govobj hash from 133680 was e317c284687997da7ea8994adcb40b3ac1304b2315afee156df098db0ee0ed01 and I can see in the log on the pool when the pool received this object, it was rejected:
CGovernanceManager::MasternodeRateCheck -- Rate too high: object hash = e317c284687997da7ea8994adcb40b3ac1304b2315afee156df098db0ee0ed01, masternode = 4882a52f01fd0f1c93ce58f7a8372f8214396cab5bbdd1080e564099e644b6f3-1, object timestamp = 1563849021, rate = 0.000005, max rate = 0.000004.  This is great news because this means we can find the root cause and correct it.  Im confident that all of our GSC problems from day 1 are similarly related (including all forks) - this is a gobject replication issue; stemming from "success" when Distinct sanctuaries submit new GSC triggers per day (causing no propagation issue), but when the Same sanc creates a new gobject within N days (probably 7 or so, based on the math of the superblock cycle), its causing the rest of the network to refuse to add that gobject and all of the child votes- which is elusive but now we have the information to fix it.  I also believe this can be fixed in the core code without any workarounds which makes me very happy.

Investigating...