i found non linearity in pool.biblepay.org i added dual 2680v2 to my account and wonder how low hps2 it gets, so i did some investigation and found this: 10 computers on one account - dual 2680v2 had 2 days average about 19k hps2, maximum was 30k i put another same hw on new account and it did avg about 40k and max about 49k then i started turning off computers on first account and hps2 for dual 2680v2 was almost instantly above 2 days max (>30k), and with every computer turned off it goes higher and higher when it stayed alone in account i got same results as in second account 40k avg, 49k max so not only multiwallets helps, but also multi accounts  ps: it has nothing to do with pool performance or my internet or what, i used independent computers from different countries and when one account goes well, second had low hps2 I think you should test those large machines on purepool. It seems to have no weird calculations whatsoever but simply counts shares according to a CPUs capabilities.  A) Dave, why do you have 26 machines pointed to pool.biblepay.org if it has "weird calculations"? What am I missing? B) If pool.biblepay.org has any differences that can be exploited from multi-wallets or multi-accounts then we need to address it. I would rather not run people away - I would rather fix the problems - so we can rely on both pools. EDIT: Please test them both and tell us if they are the same. |
|
|
|
I tried to send coins from by biblepay core wallet 3 days ago and still has 0 confirmations. I am running the newest wallet version and have incoming transactions. How do I cancel or push this transaction? The amount I sent is no longer in my available balance. I am new to this, so sorry if this is a dumb question.
Here is what I have in my transaction details:
Transaction ID: f3c31a1c9c4929a5cfb5dc00dc292751ed4ebfd7cb3e3cb3f69923bb0d049015-000
Transaction:
CTransaction(hash=f3c31a1c9c, ver=1, vin.size=2, vout.size=2, nLockTime=108990)
CTxIn(COutPoint(2d58aaa2c5b8bca178e46146114eb88c9842837f18b77c0571687782816ca13c, 0), scriptSig=4730440220348f567ea346fe, nSequence=4294967294)
CTxIn(COutPoint(d1db70709bcb19cafd8b94c86c52b346196772136e37180acf1a87713e12a2c2, 0), scriptSig=4730440220323264115b680d, nSequence=4294967294)
CTxOut(nValue=0.00005490, scriptPubKey=76a91444b358094c9c83707958cb90)
CTxOut(nValue=379.32874630, scriptPubKey=76a914d2e6f89f3bda8d44cd4e7bb4)
Thanks in advance.
The good news is it never went out, so all you have to do is restart the wallet with ./biblepay-qt zapwallettxes=1 (We also have a Wallet Repair GUI in the wallet, if you are already running QT). After it restarts the transaction should not be in the list and balance is returned. |
|
|
|
Not thrilled to log in to the SX exchange and see the entire chat log filled with fights between BBP community members. Seriously....as much as I'd love it if we'd STOP fighting, if we won't...could we at least contain it? Find a dedicated forum where everyone can get crabby with each other and keep that stuff off of public exchanges?
Here's a good rule - if it isn't news about the coin, it doesn't need to be on "external" sites.
Disagree with each other, with the plans, with the hearts of people or whatever else - if we must - but do it somewhere that non-BBP people won't see. This makes us look ridiculous.
Full disclosure, nox just called me about 30 minutes ago and we had a real-life chat about this. I was actually a little convicted so I wanted to chime in. I'm normally happy to get things out into the open, and heaven knows noxpost and I don't always agree (brothers are like that)...but yeah, I have to agree with this one. Whatever's going on, it won't help. I suspect if we were to dig into the root of the arguments I would land somewhere different than he does, but we can all agree public fighting is no bueno. Let's give it a rest. I don't care if it comes from a good place, a bad place, a weird place, a green place, just give it a rest. If we don't agree we don't agree. I can think of lots of things I would like to change. I wouldn't take out a press release to talk about them or to air grievances though. If for no other reasons, the price won't recover, and we won't be able to get any more good qualified people to help grow this. I think just about everyone here cares about at least one of those two things. Thanks, this is a good quality post with good advice. Also, let's not hold grudges, Jesus commands us to forgive. I think we should go forward and invite the Holy Spirit into each of our hearts. The Holy Spirit will guide us to be positive and invite positive influences here. |
|
|
|
Not thrilled to log in to the SX exchange and see the entire chat log filled with fights between BBP community members. Seriously....as much as I'd love it if we'd STOP fighting, if we won't...could we at least contain it? Find a dedicated forum where everyone can get crabby with each other and keep that stuff off of public exchanges?
Here's a good rule - if it isn't news about the coin, it doesn't need to be on "external" sites.
Disagree with each other, with the plans, with the hearts of people or whatever else - if we must - but do it somewhere that non-BBP people won't see. This makes us look ridiculous.
Totally agree.... I noticed before/after we lost 15m or so from the buy orders. This should be highlighted. While we are indulging in bickering, real orders are being pulled. If we can set aside our pride for just a while... Exactly, I agree 100%. |
|
|
|
Its probably good that it finally came out in public anyway, as what is a little more redicules, is having people who claim to be *for* BBP secretly holding back so much anger and hatred, and consistently posting inaccurate info here on this board.
I always found it extremely disheartening to log into this board and see a page of hate, and I thought, what kind of intelligence does it take to bash our own Lead Dev, our own community and then expect the price to rise? To hurt our orphans and to contribute negatively to our image.
At least in other communities Ive seen the common sense to keep negativity and personal views out of public discussions and proofread posts before clicking the POST button, not start public fights and create turmoil on a regular basis.
So hopefully you agree that this is all true also?
I agree. I've posted several times about not wanting to come to this board to see vitriol, disagreements, bashing of the coin (or our team members, which OF COURSE includes you and MIP), or weird iamges of naked demon girls, or whatever. I don't want to start a fight. I don't want to join a fight. I don't particularly care if there IS a fight, but I don't want the first thing that people see whenever they click any of our links to be a fight. Our Discord, our ANN thread, our exchanges, our reddit, whatever - let's keep it clean and on-mission. For my PERSONAL perspective, in case I have confused or hurt anyone... I've said it before and I'll say it again - I attach extremely significant value to the work Rob and MIP are doing, to the vision that they have, and to the dedication that they both bring to this project and the mission to carry God's word to the masses via our charity sponsorships and other features. That's the bottom line, period. Anyone who understands anything different about my opinion is confused or wrong. If that's a situation I've created, then I thank you for bringing it to me and allowing me to clarify. I don't mean this as "taking a side" - nobody is perfect. But if I didn't support the team and the mission, I wouldn't be here at all, and I'd like to think other people have the same option and the good sense to make the same choice. Now people who genuinely care, and have issues/comments/concerns should be able to raise them in a RESPECTFUL way and get a RESPECTFUL answer. Nobody's perfect, and in many interactions between many different people (myself included, probably) there have been failures there on many sides. That's part of the human element, and moving past it is part of growth. I for one refuse to join in any more of this - I'll talk about features, roadmaps, adoption, reports, transparency, and promotion. About gratitude and when necessary uncertainty. I commit myself to being a part of solidarity and growth and not division and anger. Thanks brother Nox, I agree with you, and I am on board personally myself with replying in this way too (my replies on SX were actually born from love). So what this really means for everyone, is we need to proofread our e-mails, texts, discords, PMs, everything - before we hit send. To participate in this community I would like you to first check your information that you intend to spread, and verify every line of it is born OUT OF LOVE. Think: WWJD .... Please dont call me a hyprocrite, because I repented for this days ago, and todays communication was born out of love. Let's all do this. |
|
|
|
Not thrilled to log in to the SX exchange and see the entire chat log filled with fights between BBP community members. Seriously....as much as I'd love it if we'd STOP fighting, if we won't...could we at least contain it? Find a dedicated forum where everyone can get crabby with each other and keep that stuff off of public exchanges?
Here's a good rule - if it isn't news about the coin, it doesn't need to be on "external" sites.
Disagree with each other, with the plans, with the hearts of people or whatever else - if we must - but do it somewhere that non-BBP people won't see. This makes us look ridiculous.
Its probably good that it finally came out in public anyway, as what is a little more redicules, is having people who claim to be *for* BBP secretly holding back so much anger and hatred, and consistently posting inaccurate info here on this board. I always found it extremely disheartening to log into this board and see a page of hate, and I thought, what kind of intelligence does it take to bash our own Lead Dev, our own community and then expect the price to rise? To hurt our orphans and to contribute negatively to our image. At least in other communities Ive seen the common sense to keep negativity and personal views out of public discussions and proofread posts before clicking the POST button, not start public fights and create turmoil on a regular basis. So hopefully you agree that this is all true also? |
|
|
|
Masternodes.Online is still not synced for us https://masternodes.online/currencies/BBP/From their twitter post they may delist us this Friday https://twitter.com/_mn_o_/status/1105958103512571904I just sent them an email to check back up on them, 6 days ago I sent them update instructions Here is the email chain: using the latest version we are unable to keep the daemon running stable.
Syncing from scratch works fine and we are able to get to head according to the debug log:
2019-03-17 12:02:18 UpdateTip: new best=6c92f07b49206cbea33eb4bd39c85186413035f58461a11cfa396dbce2475408 height=107556 log2_work=59.19035 tx=910638 date=2019-03-17 12:01:52 progress=0.999999 cache=9.6MiB(25487tx)
2019-03-17 12:02:18 ProcessNewBlock : ACCEPTED
However, we are unable to run any RPC commands at this point, see the output from any of the commands we run.
biblepay-cli getinfo
error: couldn't parse reply from server
biblepay-cli getblockcount
error: couldn't parse reply from server
This has been replicated every time we run the daemon.
Upon restarting, we can still run getinfo as shown below:
biblepay-cli getinfo
{
"version": 1020001,
"protocolversion": 70717,
"walletversion": 61000,
"wallet_fullversion": "1.2.0.1",
"subversion": "/Biblepay Core:1.2.0.1/",
"balance": 0.00000000,
"privatesend_balance": 0.00000000,
"blocks": 0,
"timeoffset": 0,
"connections": 0,
"proxy": "",
"difficulty": 4.656542373906925e-09,
"testnet": false,
"keypoololdest": 1552807115,
"keypoolsize": 1001,
"paytxfee": 0.00000000,
"relayfee": 0.00010000,
"errors": ""
}
Do you have any solution? Looks like your on latest version hmmm Id probably recommend doing an update/install again, just to be sure, then a full clean (deletion) of the /blocks and /chainstate folders and the .dat files and then do a reindex again: https://www.reddit.com/r/BiblePay/comments/7nmvm8/how_to_update_clean_wallets/ I assume you guys are on Linux? cd biblepay/src ./biblepay-cli stop git pull origin master sudo make cd ~/.biblepaycore rm blocks -R rm chainstate -R rm banlist.dat fee_estimates.dat governance.dat mncache.dat mnpayments.dat netfulfilled.dat peers.dat cd biblepay/src ./biblepayd -daemon -reindex Let me know if this works for you guys Just checking back, Were you guys able to get BiblePay working? We run the daemon from scratch and have done it on multiple servers so the issue is not some stale block info.
All the daemons on MNO are our own builds - not the pre-compiled binaries. Can you confirm that the code in github is the latest version and is what you use to build the binaries? We are on LInux (Ubuntu 16.04)
Please note that we compile and deploy each and every commit. Biblepay is one of the most active coins in that regard - we have had 184 builds since adding it to MNO and all of them were deployed without issue.
This latest version is different though. As none of the other builds have had any kind of issue and we haven't changed our build settings could you please double check that the code is right? I recommend honing in this specific problem: biblepay-cli getinfo error: couldn't parse reply from server biblepay-cli getblockcount error: couldn't parse reply from server Could you tell them that Rob (and You) ran these two commands from biblepay-cli (from the compiled version in linux) these commands do not error out. See if you can reproduce either one, using biblepay-cli then tell them Rob believes there is no error - please provide us more details to reproduce. Feel free to send them my e-mail and Ill be glad to reply to them also. EDIT: Regarding that they made "184 builds" for us please tell them they should only rebuild during a mandatory (they can see this in our list here): https://github.com/biblepay/biblepay/releases |
|
|
|
a found another problem with pog
i'm trying to cleanup wallet, there is over 1000 chunks with ~1 bbp, if i select all of them and try to move it together, it throws: transaction too large (> 150kB)
so how can i cleanup wallet without clicking hundreds of chunks manualy?, also select all is not suitable as i have there tithe piles
there is definitely missing a tool to do this automaticaly
it was small wallet with only 1m bbp so not tithing frequently, what if i'll use large wallet with >10m bbp? there will be 10k chunks after while, impossible to cleanup manualy
Rob previously said an exec consolidate was not necessary. I've had to consolidate the dust manually. There's a GitHub issue for it already but looks like Rob is going to change pog based on what he learned with pog v1 and pog v2. Pog monkey 🐵 approves!!! Well I'm not contradicting myself though, the thing is if we had a successful POG lifecycle (IE, a full budget allocated to POG), we still might have enjoyed more widespread adoption over a year, and, naturally, I would have tweaked 'exec bankroll' to automatically consolidate dust (and more users would have theoretically resulted in less tithes per day per user). But, I like more efficient machines, and being aware of what we learned in POGv1, we might as well design the entire system to be as scalable and efficient as possible with no network spam. Looking at these new GSC requirements it appears we can do that without losing anything! You mentioned daily tithing. What are your thoughts for less network spam of tithing? All information will be released in the first GSC document by Monday. |
|
|
|
a found another problem with pog
i'm trying to cleanup wallet, there is over 1000 chunks with ~1 bbp, if i select all of them and try to move it together, it throws: transaction too large (> 150kB)
so how can i cleanup wallet without clicking hundreds of chunks manualy?, also select all is not suitable as i have there tithe piles
there is definitely missing a tool to do this automaticaly
it was small wallet with only 1m bbp so not tithing frequently, what if i'll use large wallet with >10m bbp? there will be 10k chunks after while, impossible to cleanup manualy
Rob previously said an exec consolidate was not necessary. I've had to consolidate the dust manually. There's a GitHub issue for it already but looks like Rob is going to change pog based on what he learned with pog v1 and pog v2. Pog monkey 🐵 approves!!! Well I'm not contradicting myself though, the thing is if we had a successful POG lifecycle (IE, a full budget allocated to POG), we still might have enjoyed more widespread adoption over a year, and, naturally, I would have tweaked 'exec bankroll' to automatically consolidate dust (and more users would have theoretically resulted in less tithes per day per user). But, I like more efficient machines, and being aware of what we learned in POGv1, we might as well design the entire system to be as scalable and efficient as possible with no network spam. Looking at these new GSC requirements it appears we can do that without losing anything! To a bright future.... |
|
|
|
a found another problem with pog
i'm trying to cleanup wallet, there is over 1000 chunks with ~1 bbp, if i select all of them and try to move it together, it throws: transaction too large (> 150kB)
so how can i cleanup wallet without clicking hundreds of chunks manualy?, also select all is not suitable as i have there tithe piles
there is definitely missing a tool to do this automaticaly
it was small wallet with only 1m bbp so not tithing frequently, what if i'll use large wallet with >10m bbp? there will be 10k chunks after while, impossible to cleanup manualy
Yeah, this is addressed in the next design. For now you can do some small exec bankroll commands to combine those back into bigger bills. Each exec bankroll just has to be small enough to keep each transaction below 100K in size. Since POG is off now, the problem won't re-emerge. (In the next design, everything we do is once per day.) |
|
|
|
We received these pictures from Cameroon One today: 1:  2:  3:  4:  5:  |
|
|
|
how do we check budget for upcoming superblocks?
And also you can see both the proposal list and the budget and the winning votes in : "Governance | Proposal List" in pool.biblepay.org. (This is the one thats already In production). You can also see a list of proposals in the core wallet under Proposal List (but I dont think it gives you the budget cap) for that you need 'getgovernanceinfo' from the RPC. doh brain fart sorry! Yes this is probably the better resource currently. I disagree. https://forum.biblepay.org/cc/governance has two advantages: 1) easy access to governance data without having to register an account 2) makes it easy for search engines to crawl all the pages site:pool.biblepay.org pool has PDF and other links visible, but nothing regarding governance. site:forum.biblepay.org inurl:governance forum.biblepay.org needs some more SEO work for the governance stuff. if you're interested. Governance is all JavaScript but I have some ideas to improve visibility. I can work directly with your thesnat21. the more data that is crawlable by search engines, it ends up being free advertising with long-term benefit. Until it's "released" i'd rather it not be setup as a "go-to" for everyone. I do like the free advertising Please, let's correct innacurate information as its posted, especially if it is spread in a way that misguides our users. Pool.biblepay.org does have all the governance information in it (as I posted earlier). It also has the ability to create proposals, deposit BBP, and list proposals, and list the budget, and the votes. Its used by every one of our partners except Compassion. |
|
|
|
how do we check budget for upcoming superblocks?
And also you can see both the proposal list and the budget and the winning votes in : "Governance | Proposal List" in pool.biblepay.org. (This is the one thats already In production). You can also see a list of proposals in the core wallet under Proposal List (but I dont think it gives you the budget cap) for that you need 'getgovernanceinfo' from the RPC. |
|
|
|
We're still on track for our Evolution testnet release and wiki page explaining our proposed enhancements within 4 days.
I believe this info will be released by next Monday.
At the very least, Evo will be in testnet Sunday night, so please get ready to test.
Please wait until I post the TestNet thread link.
It looks pretty good, Also would like to ask if there is any plan to cooperate with church institutions in the next few months? So far, we basically had a little bit of an infrastructure change in the underpinnings of BiblePay. Due to the Evo requirements adding in a couple new IT goals, we have to insert a couple of new but valuable and important items into the roadmap, however these will help us achieve the other roadmap goals over the long term (due to more devs in parallel). One of the items is the new non-financial transaction. This allows a church to create a vendor record in Evo (this basically allows tithes to reach a church from the congregation). Two of us are working on this, I'm working on allowing the tithe to be sent via the church's name and MIP is working on adding Tithing from mobiles. We will add this to the roadmap Monday also. |
|
|
|
|
We're still on track for our Evolution testnet release and wiki page explaining our proposed enhancements within 4 days.
I believe this info will be released by next Monday.
At the very least, Evo will be in testnet Sunday night, so please get ready to test.
Please wait until I post the TestNet thread link.
|
|
|
|
Economics in the reddit sidebar are still PODC-based. We should probably align to the new ANN post.
Hmmm, I noticed on my mobile phone the old version was cached, on PC you can click ctrl + shift + R to do a hard reload of the page, let me know if that works Right you are. How embarrassing for me. Not embarrassing at all! Im glad you checked! I wonder how long caches last >.> There is a meta cache tag max age attribute some sites use, so it depends on the use. |
|
|
|
I updated the website, reddit and ANN post: Reddit: https://www.reddit.com/r/BiblePay/Website: http://biblepay.org/ANN: https://pastebin.com/raw/NVYwJ72bLet me know if anything is incorrect or missing (Note: Rob you will have to apply the new ANN if you like it, its based on latest copy of yours with some slight modifications) = I also reached out to Masternodes.Online, they are having issue updating their daemon / syncing their chain, I gave them update/clean instructions Updated. Looks Good. Thanks a lot Togo for your work, its always appreciated! |
|
|
|
how long til sx is back?
Ill contact them and see if they would like to reopen in the next 48 hours. |
|
|
|
Just take a look at the BibleHash algo and how much estimated memory it would take to load the KJV array in the GPU executing environment (this is from kjv.cpp), and tell is if you believe its technically possible to duplicate the chained bible hash calls, the AES512 call, the hash call and the concatenated result call in a GPU. And how secure or not secure you feel that someone will figure it out knowing what you know about c libraries and GPU code programming.
Im not too worried about ASIC, I heard they have such limited memory that loading the bible in it would be preposterous also you need a specific designed chip with the bible that would cost a lot of R&D for the first batch.
Edit: btw guys when you execute one biblehash, it uses 33,000 verses of the bible in a certain hashed order (depending on each hash its different). IE its memory intensive since the entire bible is memorized.
I think it's possible, look at the memory requirement for cryptonight or ethereum, it may have a performance hit due to the extra pieces. ASIC's are possible, but not anywhere near cost effective (half a million R&D?) Ok, I have one reason I believe its not possible, let me e-mail you that reason and then please post if you believe it is not advantageous/feasible to port biblepay to GPU. |
|
|
|
|
Show Posts
