November BiblePay update:
- Today, I had a conf. call with MIP and we were discussing some ideas for 2020. For example, ideas that utilize the hashing power of POBH 2.0 for a useful activity such as video encoding.
Any possibility of this concept being also tied to PODC 2.0 by utilizing BURP? http://burp.renderfarming.net/(I have participated in BURP a long time ago so I am familiar with what they do), but this idea is more along the lines of making a hash function in dotnetcore (the cross platform dotnet) that splits its time doing some hashing for "Part A" and does something useful in "Part B" - but the parts are tied together. The Part B, I was thinking would do something to the effect of finding a random Christian youtube video - along with its metadata - and scanning a chunk of it (converting it to mp4). Then verifying the hash with a sanctuary - if the converted chunk matches. Another words, this 'useful part' has to be small and quick to verify. BURP is good for a longer job and better for rendering - but this is more of a conversion from the youtube format to mp4 so the file can be hosted outside of google (so that a backup exists during the tribulation). Anyway this 'part B' in this case is not really the main driver - part of this effort is to create a new type of hash function that still maintains its integrity for chain rollbacks while doing some type of useful work; and Id like to make it so the 'brain' can be upgraded for Part B - another words its resilient to forks and has some type of abstraction layer above it. |
|
|
|
|
November BiblePay update:
- Today, I had a conf. call with MIP and we were discussing some ideas for 2020. For example, ideas that utilize the hashing power of POBH 2.0 for a useful activity such as video encoding.
- Bhavani has pulled down the latest branch, and is working on the governance expense graph. She had to visit a sick relative in India, so she had some delays in getting started with the .14 branch.
- PODC 2.0, phase 1 is almost ready for TestNet. ETA: Within 48 hours. I believe we will need to test PODC, make a punchlist of enhancements and do an addl round of testing to attempt to shoot for a December release.
- Ive been notifying Cameroon and Kairos about the DSS poll that won, and ramifications on sponsorships. We still have at least 60 days of credit left with Compassion, so I will reach out to them in 30 days or so and notify them of the wind down. So, with Cameroon, we have 11 core children that are not in POOM that we have paid until the end of the year. I mentioned to Todd, we will need to cancel these children as of the end of the year, but alternatively, we will be glad to pick them up in POOM. If anyone wants to sponsor them please notify Todd that you are taking one of our 11. If no one does by mid December I will sponsor them in POOM. Very similar situation with Kairos; I explained the integration reqs to Andy at Kairos, and mentioned we will need to cancel the 21 children, unless - they can convert to POOM by the end of the year. I mentioned to Andy, we will pick these kids up via POOM one way or another -- if Andy integrates. Ill keep everyone informed if Kairos decides to implement POOM.
- MIP is working on mobile church tithing.
|
|
|
|
Just wanted to express my gratitude to sunk818 for all the informative blog articles! Awesome community spirit.
And thank you Rob of course for the amazing perseverance and coding talent.
Thanks! And thanks to everyone that has helped turn this project into something truly special for the benefit of humanity, both in this dimension and in the one coming  . |
|
|
|
Hi, I changed my Sanctuary station IP, and copy the content of one station to another. Now I get this after starting Sanctuary: bbp@stationu1:~/zminer$ ./biblepay-cli masternode status { "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295", "service": "78.47.86.179:40000", "status": "Not capable masternode: Masternode collateral is a ProTx and ProTx address does not match local address" } How can I fix it ? By the way, the DIP3 link is not working : https://wiki.biblepay.org/Evolution_UpgradeWhen I set up my sanctuary (masternode), I didn't have to do upgradesanc to receive daily payments. I don't think DIP3 is required yet. Correct - right now you do not have to be deterministic to get rewarded.If you did upgrade to deterministic, you will still be paid. We are running in hybrid mode currently. I will check with Apollon on our integration status and report back within 30 days. For now, its safe to run either way. |
|
|
|
Hi, I changed my Sanctuary station IP, and copy the content of one station to another. Now I get this after starting Sanctuary: bbp@stationu1:~/zminer$ ./biblepay-cli masternode status { "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295", "service": "78.47.86.179:40000", "status": "Not capable masternode: Masternode collateral is a ProTx and ProTx address does not match local address" } How can I fix it ? By the way, the DIP3 link is not working : https://wiki.biblepay.org/Evolution_UpgradeI don't know if you already resolved this; but if you didnt; let me say this: In our .14 branch, we will have an addl command that lets you revive a moved sanc - but its not in our current live branch yet (.13). The other thing: DIP3 is partially enabled in Prod - you can have a non deterministic (legacy) sanc *or* a new deterministic sanc. It will probably be this way for 60 more days, while we find out the status of Apollons integration. Next, the easiest way to recover from this currently is to just destroy your sanctuary. If you do this: - Spend the collateral, back to yourself by unlocking it - Create a new sanc with a new name Later after its running again, you can do the 'upgradesanc' command on it to make it deterministic. Good luck. |
|
|
|
@bible_pay
On the installation of NOMP pool you said it is installed as root. So all files and directories under /pool should be owned by root? Mine has half of it in my username instead.
It's all in root now. Still has issues but I will work them out.
I think its basically an issue where we have to re-write the guide from the ground up after installing the Biblepay daemon as a user, and use that same user account to install nomp and any extraneous circumstances encountered as the user need addl rows of docs (Ie missing libs encountered with the user install). |
|
|
|
I got my test pool working. I still have more testing to do, but the basic mechanics of submitting shares, getting historical stats, and payout is working. How do I install NOMP pool for BiblePay? https://whitewalr.us/2019/install-nomp-pool-biblepay.htmlI added troubleshooting notes and my thoughts on setting up the pool. Did you resolve the nTime issue? I don't have that issue on nomp.biblepay.org; the submitted time of each miner *is* falling between the acceptable time range window. Basically your biblepay core server has to have an acceptable nTime in UTC agreeing with the UTC time of the NOMP node.js server (within 60 secs or so) and that time is used to check the share submission time window range (-300 to +7200 etc). |
|
|
|
** Nomp Pool Admins update **
We have successfully decreased invalid shares < 10%.
...
I realize some of you might want to lower the vardiff below 4, and that is fine, you can do that -- I'm only posting what worked for me. Hopefully, rebooting the server (or redis-cli shutdown) reset the stats and the pool payout mechanism. I was the only one mining, so the first block belonged to me anyway... LOL I got three blocks last night, so hopefully those pay out to their respective miners. Lots of changes... but without ABN, the non BBP owners are really hogging all the blocks. Its okay, it is only temporary as PoDC 2.0 comes online. Re: pool -- I'm beginning to think the threshold to submit an acceptable nonce on the lower end causes more resubmission of the duplicate shares. So, I'll try your minimum of diff 4 and see how it goes. Reboot should not clear redis, but if you want to start over you can do the 'redis-cli flushall' To erase certain stats: redis-cli HGETALL biblepay:stats hset biblepay:stats validShares 0 hset biblepay:stats invalidShares 0 I don't know about the other keys; this is all Ive changed so far to get it to this point. I tried redis-cli shutdown and removing /var/lib/dump.rdb instead - Maybe that was a bit harsh but I didn't know how to get rid of the bad pool address error. Did you notice historical data is not from most recent block height? The numbers are out of order sometimes. for nomp.biblepay.org 154814 and then it is 154869 I'm going to leave my min diff 0.777 but set the difficulty retarget low so high hashers should move up in difficulty quickly. This way, computers with low power can participate more regularly and be encouraged by accepted shares (yay!!!) realizing that they may get more rejected shares from duplicates. "3032": {
"diff": 0.777,
"varDiff": {
"minDiff": 0.777,
"maxDiff": 64,
"targetTime": 90,
"retargetTime": 6,
"variancePercent": 1
}
},
Well the history doesn't backfill until the block gets confirmed (I believe its the value they use for solved vs. confirmed) - so I think that part is OK. The page just needs a javascript sort on the block height descending, one of us can add that as a pool issue once we get the github enabled. Edit: The diff idea is cool, as long as your rejects stay relatively low then thats good. |
|
|
|
|
BiblePay
1.4.5.2-Leisure Upgrade
- Fix exec paycameroon feature to use current bbp price
- Fix exec price to show current bbp price
** This is the windows release. MIP will update when linux is ready **
|
|
|
|
** Nomp Pool Admins update **
We have successfully decreased invalid shares < 10%.
...
I realize some of you might want to lower the vardiff below 4, and that is fine, you can do that -- I'm only posting what worked for me. Hopefully, rebooting the server (or redis-cli shutdown) reset the stats and the pool payout mechanism. I was the only one mining, so the first block belonged to me anyway... LOL I got three blocks last night, so hopefully those pay out to their respective miners. Lots of changes... but without ABN, the non BBP owners are really hogging all the blocks. Its okay, it is only temporary as PoDC 2.0 comes online. Re: pool -- I'm beginning to think the threshold to submit an acceptable nonce on the lower end causes more resubmission of the duplicate shares. So, I'll try your minimum of diff 4 and see how it goes. Reboot should not clear redis, but if you want to start over you can do the 'redis-cli flushall' To erase certain stats: redis-cli HGETALL biblepay:stats hset biblepay:stats validShares 0 hset biblepay:stats invalidShares 0 I don't know about the other keys; this is all Ive changed so far to get it to this point. |
|
|
|
Now that qt_phrase is 0, does this impact consensus_price? Does CameroonONE orphans get paid based on the consensus_price?
exec price

{
"Command": "price",
"consensus_price": 0,
"qt_phase": 0,
"qt_prior_phase": 0,
"qt_future_phase": 0,
"qt_enabled": true,
"cur_price": "0.000319340000",
"BBP/BTC": "0.000000035000",
"BTC/USD": 9124
}
exec paycameroon xxxxxx 40 test
{
"Command": "paycameroon",
"BBP/USD_Price": 1e-005,
"Error": "BBP Price too low to use feature. Price must be above .00001USD/BBP Running in dry run mode. ",
"BBPAmount": 4000000,
"USDAmount": 40
}
What? Yesterday, I checked the cameroon GSC related code to make sure turning off QT wouldnt affect the generation of GSCs, and they look good, but I forgot we had pay cameroon. Apparently my life is still not going to get any simpler. Ill check that out next, thanks.... |
|
|
|
** QT Disabled Permanently **
In the spirit of following our DSS projected-currency-model and the winning vote, QT has been retired permanently.
Congratulations on the raise, miners!
Now you should see a 60% raise, minus the difficulty increase in DGW.
NOTE to investors: This raise does not cause us to veer away from our original launch parameters. QT was enacted to temporarily control costs - but - it was not a net success.
Did the change occur as of block 154713? I looked for qt_pct in raw transaction, but all the blocks appear as qt_pct=0 so I guess the raw block appears as whatever the current status? Yes, 154713. Yes, blocks prefer the spork setting first, then the chain historical price only if need be. This is so we don't fork in a reorg (plus for efficiency purposes). |
|
|
|
|
** QT Disabled Permanently **
In the spirit of following our DSS projected-currency-model and the winning vote, QT has been retired permanently.
Congratulations on the raise, miners!
Now you should see a 60% raise, minus the difficulty increase in DGW.
NOTE to investors: This raise does not cause us to veer away from our original launch parameters. QT was enacted to temporarily control costs - but - it was not a net success.
|
|
|
|
Also, I didn't hear feedback on if you sync from zero when these breakdowns occur; but I do recommend restarting all the governance files from empty - at least once - when these are installed. This will ensure all the old gobjects are in the cache.
When I set those sancs up, I initially replaced block database from a bootstrap copy that is like 4 weeks old, as well as peers.dat. But all the other .DAT files including governance files are recreated from empty. I will try to be awake by the time you say, however it will be around 1-2 am European time, I hope to make it. Ok if mncache and gov*.dat is recreated from empty - then the node should be doing its mnsync correctly, by default. So it still points to Germany not having any 'friendly neighbors' as far as peers who peer correctly with governance - which is a very, strange thing to think. I wouldnt worry about staying up for this. If you want you can send me your IPs and Ill run the pool report for you at that time, and you can read it tomorrow morning. I find it hard to believe these can go down this often, but anyway now you can hone in on the block # of the gsc tomorrow morning if it is out of sync, and verify it went out right at the superblock height. |
|
|
|
Oh ok, I see what you mean, thats a good idea. ... we need to also allow a lower barrier of entry for say, cpids who have < 500 RAC. Not just for unbanked, but for all signups. Android miners have Linux/Windows/mac QT desktop wallets already. I seriously doubt there were any unbanked in PoDC 1.0 that only had Android. BBP has been perceived as hard to join, so whatever we can do to make not seem like an exclusive walled off garden is good right? - MIP looks at making the associate message on the mobile - I look into making this a zero fee tx (since these are going to be relatively rare, I think they will be included in blocks). Ill look into implementing these things as I think this helps bring the barriers down. Awesome, thank you! I agree for the most part, about not making it a walled off garden, but we do need a rule that authorizes the zero cost fee to keep it from being abused. I think we can say, if the CPID is in team biblepay, and it has rac > 1 and less than the unbanked threshhold, then we allow the zero tx fee to propagate. We can allow it for mobiles also in this case. Its just that, with a CPID with > say 250 RAC, they will by default pay the fee because they need to stake daily stakes from the external purse anyway. But overall, yes, I think we are making PODC 2.0 much less painless. The external purse + staking from the main wallet thread just means a user needs to leave one core wallet running but not the pobh miner etc. Ill also be adding better defaults for cameroon one - so that it only uses .25 bbp in its daily stake by default (in contrast to the coin-age percent). I believe we already fixed the Healing defaults (to not use up a lot of coin-age). These two rules above are basically designed to not waste coin-age that will be highly valuable in the external purse for the podc stake each day. The external purse will still need denominated change for this to work; so we will need to remember to fix exec bankroll. |
|
|
|
Do you have swap space on this machine btw?
And when you install bbp, do you let it sync from zero?
It seems like your nodes do have multiple recurring consecutive issues - but I usually see 90 days of uptime per run.
When I have problems I see it is confined down to the same few problem nodes though - somethign to do with region.
Something is going on with your nodes being able to gather votes from the network.
Is your firewall set up in a way to block our gobjects propagation somehow?
Please check exec health and make sure it matches the exec health in the pool.biblepay.org | reports | Sanc health report?
I see the same 10 nodes appear over and over ; could be a Country issue - where nodes aren't reaching out to propagate the votes; but first we need to ensure your votes are falling behind and creating a discrepency with the network?
I have enough resources. Server is placed in Germany. I set up firewall allow rules for each of the sanc ports (I guess that if they were closed I would not have been able to start them in first place). Also, that would not explain why they are seen by pool and masternodes,online for 16 hours then suddenly stall... Let's see what happens in the next hours, thank you! I would say to hone in on the most suspicious part - each day, we have our GSC superblock spaced 205 apart; typing exec health reveals the next one is at 154795 - thats in 85 blocks - to reveal the most suspicious cause - take a look at the exec health vote level about 20 blocks before and see if it sways from the supermajority on the pool. If it does, then you have definitely discovered the problem is gobject propagation receive issues in Germany. Also, I didn't hear feedback on if you sync from zero when these breakdowns occur; but I do recommend restarting all the governance files from empty - at least once - when these are installed. This will ensure all the old gobjects are in the cache. |
|
|
|
It wouldn't make sense to design 0 bbp requirement when 100% of our use cases require bbp now. Cameroon requires bbp to pay the bill, podc requires a daily stake, and POG requires a tithe, etc. If you're going to make PoDC the main GSC contract, I would consider not starting the exponential stake until after you go past a certain RAC like 5k RAC. So, from 1 RAC to 5,000 RAC no stake is required. Why do this? If you create zero barrier to entry, you will get more BBP members. That's also where zero (0) fee registration comes in. You should be able to participate in PoDC 2.0 with 0 BBP in your wallet. Otherwise, you will need to do airdrop or faucet like last time to get people to BBP. That created a lot of support work and we're just repeating the same scenarios from PoDC 1.0 all over again. Let's learn from the previous pain points. in the nomp pool, I see shares rejected with this error message: ntime out of range nTime 1572528879, rpctime 1572528877 That means the share was rejected due to being out of range - we have a window of -320 seconds and +7200 (IE the standard for asic). Please check the server and ensure the timezone is correct and the time is correct? Is it only happening on your mining against your own server, or .... I've seen it happen on nomp.biblepay.org before. You can see the console error when you run with the -P (protocol) parameter. I see it on my test pool too but takes some time (10 minutes?) before it shows up. The rejected shares are primarily duplicate, but this out of range shows up less frequently. Oh ok, I see what you mean, thats a good idea. You basically mean we need to also allow a lower barrier of entry for say, cpids who have < 500 RAC. MIP and I were discussing unbanked last night (maybe leaving a zero stake requirement for mobiles who are unbanked with < 100 RAC, and giving them a way to associate the CPID on the biblepay-mobile wallet). Yeah, we could actually create a method that would allow association for unbanked with 0 bbp. Im not sure if this will be ready in testnet first release; but the first baby step is: - Allow zero staking requirements for cpids with < 100 RAC - so we find these unbanked cpids, as long as they are in team BBP or GRC, they pass and get included - MIP looks at making the associate message on the mobile - I look into making this a zero fee tx (since these are going to be relatively rare, I think they will be included in blocks). I've already got the external purse working; Ill look into implementing these things as I think this helps bring the barriers down. As far as the nomp, I tweaked a few things just now and it appears to be working; Ive reset the servers shares found counters - if we can get below 10% rejects, I believe its fixed. You cant get much below 5% as there are a lot of chatty unexpected breaks in the protocol. Besides, a rejected share is not necessarily meaning the hashes were wasted; a lot of these mean the stratum job was changed on the server side before the miner submitted the solution for work that was 15 secs old; IE sometimes, the server finds a new merkleroot - changes the job for its 50 clients - while at the same time the client is sending a solution for work that is 20 secs old - so those are not actually hurting the team as far as finding a block. But I agree, efficiency rejections should be fixed. So if we get below 10% again Ill share the params. |
|
|
|
|
Show Posts
