Is there a way to accurately gauge the global hashrate. Using getnetworkhash gives a pretty small number (2xx,xxx.xxx) unless that is KhS or MhS?
Its not worth it- we will have a new algorithm in just 1600 blocks which requires a regauging. In the mean time I think happy came closest. |
|
|
|
4 Hour of mining on pool and 407k h/s and get nothing?
Correct; I just checked the pool wallet and its last block found was 5388 @ 10:01 AM. |
|
|
|
Yeah, sorry I didn't have time until this morning to sit down and crank the numbers.
So I did two -reindexes under 1.0.2.3, and they were pretty successful, just wouldn't sync the last block or two very timely.
Went into <user>/AppData/Roaming/Biblepaycore/testnet3/... Blocks/ .... Chainstate/ and Blocks/Index. Deleted all the files in those folders. Restarted wallet, it got to the "no block sources available" message in about 20 seconds, again under 1.0.2.3.
Downloaded 1.0.2.4, installed, -reindex worked quickly, syched. Shut it down, deleted the files again, restarted. It rebuilt everything in under 1 min. Synched. Did one more -reindex, took a lot longer and wouldn't full sych, but I shut it down, the restarted without the -reindex and it got the last bit and was successful. My test balance was unfazed by all of this (no issues).
Used showblock on a handful of blocks, noticed I just narrowly missed testblock 666 (got 665 and 667). And noticed the genesis block does not contain a verse from Genesis. I'm still not very adept at reading the showblock stats, other than the very obvious ones. I wasn't sure on the block how to see "who" mined it to verify the blocks I mined in test showed that, but other than that, it was good.
LOL, that would be hilarious if we had "In the beginning, God created..." in the Genesis block, dang I wish I would have thought of that before we went live while mining the genesis block. I could have probably left it mine until it hit a verse from Genesis. Good, thanks for all the testing. My tests pretty much are equivalent to yours as far as resyncing and reindexing. Looks like we are close to make a 1.0.2.6 version for the mandatory, unless someone raises an issue within 2 days or so. EDIT: Hey, I think you just gave an idea for a new feature. We can probably hardcode In the beginning in the Prod chain for block 0, that would be a nice twist for this coin. |
|
|
|
I think the pool is down.
DEVs can probably give at least a few hours notice before cutting off people . now we have 100s CPUs running and not hitting the pool . it gets pretty frustrated . First of all, I will definitely be giving a notice for maintenance when the pool is in Prod and its going to go down. The pool is not even in Prod yet. As far as today is concerned, I had to move the rack and I left it plugged in and it went down without me knowing - sorry about that. Anyway, your clients will solo mine when you lose the pool connection, so its not really a problem. The latest version doesnt have the issue where it slows down as it only checks on pool health once every 5 minutes or so. |
|
|
|
On the pool issue, I had to throw the switch to enforce the new version.
Ensure you have 1.0.2.4+ running, and it should run fine.
all my workers < v.1.0.2.4 are cut off. could you point to clear instructions how to upgrade linux clients ? The same way you upgrade from 1.0.1.9 to 1.0.2.3, upgrade your client before mining. |
|
|
|
Right now the dev team is working on a new pool UI, this way we will have two pools soon, one in beta, on in alpha to split the load, and will give us the ability to debug the new alpha pool with a fallback plan.
I wanted to stop in real quick and ask that everyone consider writing a letter to one of our orphans (using the pool.biblepay.org site | Active Orphan Report | Write) option. We will be adding the ability to see orphans who have not received a letter within 30 days descending, with the goal in mind that every orphan receives at least one letter from us every 60 days minimum. Please ramp that up while we are developing the new features. (In the future you will also be able to add pictures.)
Once the letters are upvoted past 7+, our new API will automatically export the letters to compassion and mark them as sent (those columns will be exposed soon), so rest assured these letters will be delivered to the children we sponsor.
Great idea on the letter writing. In the future is this going to be the oversight of Sanctuaries? I would like to decentralize the whole thing. We could have a global sanctuary poll on which charities to fund, and make the "orphan wallet" the 'sanctuary charitable funds' wallet used for approved polls disbursements. They will have the power to allocate a % to each approved charity per monthly vote. I can see decentralizing the fund flow to the charity and continuing to sponsor orphans- but It is not clear how the web letter writing interface, being centralized currently, can be used to write letters to orphans in the future. Our IT dept will need to be nimble enough to provide tools to support the charities as they are funded, and provide ties between the poll guids and the UI entry so the community can execute the required function(s) per charity. |
|
|
|
So everything is passing in test? Westwarmoth, has anyone tried reindexing there blocks file yet in testnet?
Could you (or happy_merchant) explain how to do this? I'd be happy to do it, but I don't know where to start. Also: the pools on both testnet and main seem to have issues at the moment. All my miners have reverted to solo-mining. And it looks like a lot of other miners also disappeared from the leaderboard. On the pool issue, I had to throw the switch to enforce the new version. Ensure you have 1.0.2.4+ running, and it should run fine. On reindex block chain, start the wallet with '-testnet -reindex' and ensure it recovers with no errors to the top. Then start in -testnet mode with no blocks, database, and chainstate and ensure it syncs to the top? |
|
|
|
|
Right now the dev team is working on a new pool UI, this way we will have two pools soon, one in beta, on in alpha to split the load, and will give us the ability to debug the new alpha pool with a fallback plan.
I wanted to stop in real quick and ask that everyone consider writing a letter to one of our orphans (using the pool.biblepay.org site | Active Orphan Report | Write) option. We will be adding the ability to see orphans who have not received a letter within 30 days descending, with the goal in mind that every orphan receives at least one letter from us every 60 days minimum. Please ramp that up while we are developing the new features. (In the future you will also be able to add pictures.)
Once the letters are upvoted past 7+, our new API will automatically export the letters to compassion and mark them as sent (those columns will be exposed soon), so rest assured these letters will be delivered to the children we sponsor.
|
|
|
|
|
So everything is passing in test? Westwarmoth, has anyone tried reindexing there blocks file yet in testnet?
|
|
|
|
How can I use Mac Wallet? Is there any guide available?
Right now you would have to self compile it as we dont have a mac DMG file available (yet). You should be able to follow the linux compile instructions without any hitches. We are looking for a volunteer config manager to create DMGs for us when we create our slack team in about 15 days. |
|
|
|
Good Day !
I registered yesterday at the pool, create worker, etc... and i think everythings work well.
I check the withdraw menu, and i see i have xxxx immature balance. When change to available ? Few hour or 1-2 day?
Thank You !
The pool releases each mining credit 24 hours after mined. |
|
|
|
I pulled a good number of blocks in the testnet today but am unclear how to examine the blockchain for errors in the system. Also, the computer I was on hashes about 50KhS on production and dropped to about 1.5/2KhS on the new algo which is said for informational purposes only.
Happy wrote a program to check block spacing in testnet, and its drastically improved over prod. Primarily due to the late block threshhold happening less, (IE blocks over 30 minutes after the prior block), and when it does happen, the block is now solved closer to 30 (in contrast to 60 in prod). So we are pretty good on block spacing. Subsidy calc is good. The main thing you can test with block integrity is try to reindex the chain, verify it syncs to the top, try starting with no blocks file, verify it syncs, and restart with a full block file and verify it passes. You can do a 'showblock randomblocknumber' and ensure the txid lookup is at the end of the biblehashes. Ive already done this on 100 blocks, but you can do it for experience if you want. Ill try to think of more tests through the day. |
|
|
|
The Leaderboard page is empty. In the About page, it says that height is -1. The password field is of type="text", so the characters are seen when you type them. favicon.ico is being called on the Login page but it's missing, so it throws an error. You can remove it or maybe you can just put the one happy_merchant made: http://biblepay.inspect.network/favicon.icoYeah, there was an issue in the night, unfortunately, due to all the changes. Anyway that part is fixed, which caused the withdraw problem and the about: height problem. Favico: Fixed Password on Login: Apparently .NET 4.5 requires a new control: FIXED Looking into AJAX next. |
|
|
|
I've tried.
I received the same error with core generated key.
Make sure you're on the main network on the pool and didn't accidentally click "switch to test net" or anything. If it's not that and you're sure the address is correct, it might just be a temporary issue with the pool or pool wallet. Yes, I am on the main network. Pool says: (Network ID: Main) I think, you are right. There is a problem with pool wallet. Pool wallet went down in the night; the error about the invalid recv address is something being interpreted wrong by our middleware. Fixed. Please withdraw again. |
|
|
|
Upgraded from 1.0.2.3 to 1.0.2.4 and back on the miningpool again
So, any problem with 1.0.2.3 version on the pool? I found that all HPS is zero, will it swap to solo mining with this issue? Just configuration issues on the pool side found in the middle of the night- fixed now, should not have anything to do with your end. Please report again if you see anything awry. |
|
|
|
Bittrex and Poloniex, and then others. Probably not for 30 days though, we need to get the pool from beta to prod first and we also have a mandatory at block 7000 coming up. After those things pass we can follow up with bittrex. |
|
|
|
|
ATTENTION:
The web server was just upgraded. The pool may be sporadically up and down over the next 30 minutes while I upgrade the database server.
|
|
|
|
Delighted to see BBP listed on coinmarketcap this morning, this will certainly help to attract new interest over time.
I see masternodes/sanctuarys in development toward the end of this year. How many coins are required to run a node?
Thanks for the update. Here is the link in case anyone missed it: https://coinmarketcap.com/currencies/biblepay/
Were #487, so we are on page 5. The nice thing about starting at the bottom, is we only have one way to go: UP. |
|
|
|
|
POOL FAVOR TO ASK:
The pool is under extreme load, and can barely handle new traffic.
As a stopgap, I ask that everyone upgrade to the newest version of Biblepay-qt (this version was just deployed at midnight last night) version 1.0.2.3. (If you already have v1.0.2.3 upgrade anyway).
It contains the enhanced miner packet. (The technical difference is the new version is more efficient on partial work packet communication and communication back-off). This should alleviate 65% of the pool traffic and give us time to upgrade the server (and or, opensource it and open more pools simultaneously).
I will give 24 hours for pool miners to upgrade, after that, a switch is thrown forcing upgrade to the newest version (The pool has the ability to require the higher version).
|
|
|
|
Is it safer to keep the coin on the exchange platform or in pool?
Both of those have risks. Exchange risk is the risk that the owner skips town with every last coin currently held by the exchange (or, simply they are forced out of business one day), and the pool risk is that the pool hot wallet is broken into by a hacker. I recommend withdrawing 75% or so regularly and leaving small amounts in both places. Password protect and back up your home wallet and keep a copy of it offsite. You can always recover your coins from a backup even if you go away for a few months, after wallet is re-synced, all coins are recovered. |
|
|
|
|
Show Posts
