|
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!
|
|
|
|
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 **
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? 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, 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, 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/ |
|
|
|
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...  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 |
|
|
|
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 **
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? 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). |
|
|
|
|
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.
|
|
|
|
what happend?
my pc is win10 and ver:1.4.4.4
"poolinfo5": "Internal ABN: Invalid 1563959825; ",
"abninfo": "Received a stale block from the pool... Please wait... ;
Pool is resyncing now, give it 10 more mins and it should be fine. 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... 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). |
|
|
|
what happend?
my pc is win10 and ver:1.4.4.4
"poolinfo5": "Internal ABN: Invalid 1563959825; ",
"abninfo": "Received a stale block from the pool... Please wait... ;
Pool is resyncing now, give it 10 more mins and it should be fine. |
|
|
|
This testing in testnet could not be having some impact on the pool mining could it? Seems as if the leaderboard is barren and miners are either unable to connect or the pool is not showing them connected. Investigating... 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. |
|
|
|
This testing in testnet could not be having some impact on the pool mining could it? Seems as if the leaderboard is barren and miners are either unable to connect or the pool is not showing them connected. Investigating... |
|
|
|
Great! So the whole time, I make the assumption that the internal BiblePay node was synced, but due to the bug in processing empty coinbases, we generally broke the iquidis explorer regularly. LOL. This is a great step forward though, it should help us ensure we are fork free for long periods of time. Lets shoot for being fork free until Chain Locks is deployed, and then fork free forever. We need 100% accuracy going forward. |
|
|
|
*** HAPPY SECOND BIRTHDAY, BIBLE PAY! ***
 May this year bring you the rich blessings promised to the Gentiles and God's chosen people, and may we as a community bring God fruit worthy of repentance and salvation. Each year, I will attempt to make the cake higher as we add more successful features.
|
|
|
|
Awesome! 2 years might not sound like a lot, but in the crypto-sphere - in my opinion - that makes us veterans  Thank you Jaap for your inspiring words! You beat me to the punch. This calls for a Birthday Cake. Thank you Loyal BiblePay Veterans - and All Users - for making us who and what we are! Thank you God for getting us this far, and may we be a blessing for your Kingdom, Jesus! May we bear good Christian fruit for you over the Long Term. |
|
|
|
Rob, I worry I'm in a lose lose situation,
if I'm honest with you I believe I am going to upset you, and by not responding I've upset you
Is it okay for me to be fully honest with you?
If so, I will write back soon
To everyone else, the core of the conversation is about moderation in the Discord
Well - its not just about Discord because I've worked with you on all kinds of things from advice for DAHF, exchange implementations, helping me with BLOOM, the wikis and previous features - but Discord was just the issue that came up last month when MIPs call was reversed. But we can talk about it via Email because some parts of things I discuss with you arent public knowledge yet. I always wanted you to be honest with me and never have changed. Im sorry that the perception was somehow created that I want to be glorified in some way with only positive information or surround myself with people that are loving. The truth of the matter is I surround myself with intelligent advisors that tend to make good calls and these resonate with me (over the LONG term) and they also resonate with God (in that I bring issues to God in the prayer closet) and some go and some stay. I admitted PODC dragged everyone through something that the Holy spirit did not necessarily approve of (in the way we implemented it) and changed course to be more aligned with God's policies and as you can see Ive been very persistent and supportive. So yes, I invite you to first open up a conversation with me about this problem and then we will move on to the other topics. And yes I want you to be brutally honest. Just like I was when I mentioned the problem (or my perception of it) to you. I want to work with you, absolutely, and thats why Im being persistent because of how much time you have invested in this project and how valuable and committed you have been over the long term. |
|
|
|
|
BiblePay
1.4.4.4 - Leisure Upgrade
- Remove log spam
- Upgrade BiblePay Pool protocol to v2.0 (Upgrade busywait to mutex, add
two-way comm and handling of reply commands, add pool deadline support,
allow funded & non-funded mining at the same time per user)
- Handle bad nBits in pool mined blocks gracefully (and ddos
gracefully), and remove Pool log spam
- Disconnect nodes who spam us with bad block headers
** Pool Miners: please upgrade within 7 days **
|
|
|
|
Had a random no error crash on one machine this morning. Saw this as the last entry in my debug log, any thoughts? Thanks!
2019-07-22 15:07:07
ContextualCheckBlockHeader::FAILED incorrect proof of work at 133375, block.nbits 469826094.000000, next work 469809611.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 133375, block.nbits 469826094.000000, next work 469809611.000000 (code 16)
2019-07-22 15:07:08
ContextualCheckBlockHeader::FAILED incorrect proof of work at 133375, block.nbits 469826094.000000, next work 469809611.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 133375, block.nbits 469826094.000000, next work 469809611.000000 (code 16)
2019-07-22 15:10:24 MASTERNODEPAYMENTSYNC -- Sent Masternode payment votes to peer=193
Thats actually the pool error Im working on now; that will be eliminated in this new version. Its harmless though and should not cause a crash, or the node to go out of sync. |
|
|
|
|
** Today's Goal **
- We are currently running 1.4.4.3.
- We successfully support funded and non funded mining. I think the ABN endeavor is turning out to be a success, as we are attracting new users, and this environment is satisfying both newbies who do not want to hold bbp and satisfying old-timers who want to provide the ABNs.
- The pool is still running in protocol v1.0.
- Some log spam exists related to ABN/funded mining activing, checkblock errors due to stale blocks from the pool, and some nodes seem to get banned occasionally.
Proposed Solution:
- Release pool mining protocol version 2.0. This allows funded or non-funded mining in the pool without limitations, and provides more accurate health info.
- Remove log spam.
- Ensure blocks from the pool are not causing log spam issues. Address any pool checkblockvaliditylite errors. Ensure miners are not being d-dossed for bad block nBits or blockheaders.
I will notify when the new version is ready. This is a leisure upgrade.
** Near Term Future **
- Update the roadmap goals for Q3. Share the BiblePay goals (as related to Christian Spaces/HTML5) with the forum.
- Make the users aware of a new project we will implement towards the end of the year and how they can help with this project.
|
|
|
|
If anyone is interested in Ken Peters "I saw the Tribulation" (and personally, I think it is very valuable and prophetic), I found this transcript of it: https://z3news.com/w/ken-peters-tribulation/Keep in mind he saw this in 1980 which is even more fascinating. |
|
|
|
https://chainz.cryptoid.info/bbp/http://explorer.biblepay.org/Updated explorer to latest version, performed an erasechain, its synced back up now I think its been pretty reliable, and I think its good to have a backup explorer (from our history) Id be totally fine with the url being set to the chainz one though and I will gladly pass on the job of running the 2nd explorer to anyone interested! (or if there is some other service we could use) Iquidus explorer is slow, and has higher costs Chainz explorer is fast, and has more features Note: Theres a guy working on multithreading (clustering) Iquidus if anyone is interested to help him https://github.com/iquidus/explorer/pull/257 This is more related to some prior projects - not iquidis, but its worth a try, could you try this in the config: rpcthreads=500 litemode=1 And resync? I was under the impression with Evo we were communicating much faster with Iquidis (I remember you said there is a big difference), but apparently iquidis gets hung occasionally. So also could you clarify if the node itself is stuck 200 blocks behind, or is it iquidis that ceases to sync? (If its not the node, there is no need to resync the entire chain, if its iquidis we would just resync the iquidis database. But the rpc settings might help if its too dumb to recover). Maybe the daemon is dying, maybe research how to persistenly keep the daemon running also. The daemon is running fine, its fully synced, checked blockhashes (Theres a crontab firing every 5 minutes to make sure its running and restart it if it isnt) I checked mongodb, log file was 5.3GB, not sure if that is slowing things down, deleted it I edited the mongod.conf file to try to limit the logging [set quiet to enabled] (easy worst case I can add a crontab to just delete the log file every day) Running everything again, everything is going, but the website is not updating with latest blocks, weird, but if you type in a block number it will show/load it I started looking into the indexing process more, and it fires off and then disappears quick, I sent the output to a file, theres an error in Iquidus /home/explorer/lib/explorer.js:310
if (vout[0].scriptPubKey.type == 'nonstandard') {
^
TypeError: Cannot read property 'scriptPubKey' of undefined
at /home/explorer/lib/explorer.js:310:18
at Object.loop.next (/home/explorer/lib/explorer.js:194:24)
at Object.module.exports.syncLoop (/home/explorer/lib/explorer.js:205:10)
at Object.module.exports.prepare_vout (/home/explorer/lib/explorer.js:284:20)
at /home/explorer/lib/database.js:141:17
at /home/explorer/lib/explorer.js:392:14
at Object.loop.next (/home/explorer/lib/explorer.js:194:24)
at Object.module.exports.syncLoop (/home/explorer/lib/explorer.js:205:10)
at Object.module.exports.prepare_vin (/home/explorer/lib/explorer.js:369:20)
at /home/explorer/lib/database.js:140:15
at Request._callback (/home/explorer/lib/explorer.js:107:14)
at Request.self.callback (/home/explorer/node_modules/request/request.js:187:22)
at emitTwo (events.js:87:13)
at Request.emit (events.js:172:7)
at Request.<anonymous> (/home/explorer/node_modules/request/request.js:1044:10)
at emitOne (events.js:77:13) Looks like its happening in the 3rd parameter, an anonymous function, getting passed into syncLoop() prepare_vout(): https://github.com/iquidus/explorer/blob/master/lib/explorer.js#L310syncLoop(): https://github.com/iquidus/explorer/blob/c8ac131aed4f065b4f327ec379eaef2a006e5f50/lib/explorer.js#L169Looks like this guy ran into similar issue https://github.com/iquidus/explorer/issues/60and posted this solution: https://github.com/cryptorex/bitcoinz-explorer/commit/267a0dfd8015bc90488b2b53ae9c49be2da83bffIll try adding it and report back === Iquidus Block Explorer Guide https://www.reddit.com/r/BiblePay/comments/7elm7r/iquidus_block_explorer_guide/=== Options: 1. Try to pinpoint the bug 2. Reset the mongo database to last backup and sync from there 3. Reset the mongo database entirely and sync from the beginning 4. Retire the explorer 5. Change URL to point to Chainz 6. Find and setup 2nd explorer service 1) Can you try applying this .js patch to the code right above the .type == 'nonstandard' in explorer.js and burn it in? https://github.com/DeckerSU/explorer/commit/ac74e41c6162871fcaa6973d34f09f1cf3e5a1ceIf it works we can either find zcashs iquidis branch, and use it, or patch it based on a config setting in Iquidis' settings and push it to their github. 2) Are you going to address my comment about the PMs and emails? |
|
|
|
|
Show Posts
