Hello BBP team,
I just install new wallet for linux with version 1450. but seem like the wallet dont sync. Ofcuz i try again with clean install or check .conf file add node ...etc..
"version": 1040500,
"protocolversion": 70737,
"walletversion": 61000,
"balance": 0.00000000,
"privatesend_balance": 0.00000000,
"blocks": 0,
"timeoffset": 0,
"connections": 0,
"proxy": "",
"difficulty": 4.656542373906925e-09,
"testnet": false,
"keypoololdest": 1571763216,
"keypoolsize": 999,
"paytxfee": 0.00000000,
"relayfee": 0.01000000,
"errors": ""
Please try 2 possibilities: 1) Ensure system time is correct within a minute or so, and time zone is correct (peers hang up otherwise). 2) If you still dont have a peers count, try: addnode 45.62.230.25 onetry addnode 91.121.217.70 onetry |
|
|
|
Does governance need to be fulled synced before mining can commence?
Yes, sort of, the default is the wallet wont start to mine until its fully synced. But you can add 'jackrabbitstart=1' if you want to override that. |
|
|
|
version 1007 port 3008 [2019-10-22 18:14:55] Binding thread 1 to cpu 1
[2019-10-22 18:14:55] Starting Stratum on stratum+tcp://nomp.biblepay.org:3008
[2019-10-22 18:14:55] 2 miner threads started, using 'pobh' algorithm.
[2019-10-22 18:14:55] Binding thread 0 to cpu 0
[2019-10-22 18:14:55] Stratum session id: deadbeefcafebabe0300000000000000
[2019-10-22 18:14:55] Stratum difficulty set to 7
[2019-10-22 18:14:55]
I believe what happens is you are awarded 1 share per diff, so we just see increments of 7 because the diff is 7 on port 3008. If that's the case then 7 is a nightmare for sharing. Wouldn't 10 be easier and leave less dust after sharing? Just a thought. I do plan on adjusting the 7 to something that takes a certain number of mins, but anyway let me update what I said earlier, I knew it was not as simple as I said: You solve a share at 7 diff, but you are awarded .80 of the share due to the hash conversion. Then the ui updates in 7 increments (because its looking at the share diff of the port). So the UI really does not match exactly to the settings, so lets let it run for a while and see if we can make it match later tonight or tomorrow. |
|
|
|
version 1007 port 3008 [2019-10-22 18:14:55] Binding thread 1 to cpu 1
[2019-10-22 18:14:55] Starting Stratum on stratum+tcp://nomp.biblepay.org:3008
[2019-10-22 18:14:55] 2 miner threads started, using 'pobh' algorithm.
[2019-10-22 18:14:55] Binding thread 0 to cpu 0
[2019-10-22 18:14:55] Stratum session id: deadbeefcafebabe0300000000000000
[2019-10-22 18:14:55] Stratum difficulty set to 7
[2019-10-22 18:14:55]
I believe what happens is you are awarded 1 share per diff, so we just see increments of 7 because the diff is 7 on port 3008. |
|
|
|
 Multiplier started at 2 right? then you changed to 7 but now its 1. There are 2 multipliers, the hashrate you mine against then the ABN multiplier. If you are mining against port 3008, that port has a difficulty of "5" right now (I just picked that setting for initial config purposes). A diff of 5 gives you about 7 shares when you solve a share. However, the payment processor should pick up the 7 as 14 if its an abn share. We need to test that a little more thoroughly, I think we need to run one side by side with and without an abn. miner 1007 on port 3008 gives this [c] [2019-10-22 18:04:49] Binding thread 1 to cpu 1 [2019-10-22 18:04:49] 2 miner threads started, using 'pobh' algorithm. [2019-10-22 18:04:49] Stratum session id: deadbeefcafebabe0700000000000000 [2019-10-22 18:04:49] Stratum difficulty set to 7 [2019-10-22 18:04:49] [/c] Yeah, I did change it from 5 to 7 yesterday; but, I also see the interval on the stats page is in divisors of 7. Let me do the math on an accepted block. |
|
|
|
Multiplier started at 2 right? then you changed to 7 but now its 1. There are 2 multipliers, the hashrate you mine against then the ABN multiplier. EDIT: Port 3008 has a static diff; I need to explain this. |
|
|
|
Yes, hope payout works now. 10 blocks found, 2 confirmed and only 1 paid out so... also is the orphan stuck as a pending block?
There were not actually 10 found; I believe 3 were found. And the orphan really was an orphan. Ok, thanks  hope we find a few more tonight. Yeah, I am watching the NOMP pool wallet solved blocks and trying to reconcile it. For some reason when I installed the server, it started at 7 total blocks (maybe it counted something prior solved by pool.biblepay or something), but from what I can see we solved 3 after we went live. The strange thing is when we solved the last 3, they were in a cluster all the same time - and the third was orphaned. So I believe the "1,2,1" is actually correct, so Im waiting for us to solve more to see these increment for sanity purposes. Out of the 3, You got the first. I dont know who was in round 2, I dont see anything in my wallet. Im trying to stay on for the future rounds to see if I can be included in the next payout. It should get clearer as we solve a few more. BTW everyone, the ABN stat was just corrected at : 16:47 CST US Time, so please lets look at it going forward now. If you have the easy setup, you should just see shares and 0 abn shares in Worker Stats. If you have the "hard" setup, you should see the abn shares match the worker shares. Starting at 16:47, your shares should be doubled (vs a non-funded worker), if you have an ABN. Maybe someone can run it both ways tonight? |
|
|
|
Yes, hope payout works now. 10 blocks found, 2 confirmed and only 1 paid out so... also is the orphan stuck as a pending block?
There were not actually 10 found; I believe 3 were found. And the orphan really was an orphan. |
|
|
|
Sorry all, been getting hit with some distractions today, but we have some progress now: - The Windows crash in the external miner has been reproduced - and has been fixed - and a release is coming out within 30 mins. (This also fixes a bug on the linux side). - The reason NOMP was down at 4am this morning (until around  is very, very strange. Its very strange that the first day the server was used, it was taken down by vultr. But, it appears to be an anomaly so I have rebooted it and now we can look forward to more successful uptime. - The pool server side did have an error during the first block payout - it paid one person and crashed, I had to fix that bug, so that is being corrected now. - The shares for ABN vs shares for "easy" are being calculated incorrectly! This is due to NOMP requiring the pool to multiply the hashrate * the shares solved; that is being fixed now; Ill give an update shortly. A release is being prepared now. Sorry guys, it was me that got paid. This explains the payment being for a whole block?? Sort of but I think in your case your payout was correct, cause I believe all the miners fell out of the round and you started new round - right before you solved it. To be sure lets see if the pool pays out a complex payout soon (IE more than 5 miners). |
|
|
|
From my browser history, looks like I filled out and submitted their listing form 3 weeks ago, I believe I put Robs email as the contact email, so not sure if they got back with him No - they didnt, I forwarded all the updates to you Togo that I received except Graviex - Im still talking to them. |
|
|
|
BiblePay - External Miner
1.0.0.7-Leisure Upgrade
- Fix windows crash - Fix issue where miner discards fresh work - Deal with block size dynamically, to avoid memory problems. https://github.com/biblepay/cpuminer/tree/master/binaries** The updated server side NOMP code has just been released, so please, start testing over again and let's look at the ABN shares vs. worker shares as we solve them and verify these are incrementing correctly now. Please upgrade to the new miner before NOMP mining as the prior version(s) had a work discard bug.
|
|
|
|
Sorry all, been getting hit with some distractions today, but we have some progress now: - The Windows crash in the external miner has been reproduced - and has been fixed - and a release is coming out within 30 mins. (This also fixes a bug on the linux side). - The reason NOMP was down at 4am this morning (until around is very, very strange. Its very strange that the first day the server was used, it was taken down by vultr. But, it appears to be an anomaly so I have rebooted it and now we can look forward to more successful uptime. - The pool server side did have an error during the first block payout - it paid one person and crashed, I had to fix that bug, so that is being corrected now. - The shares for ABN vs shares for "easy" are being calculated incorrectly! This is due to NOMP requiring the pool to multiply the hashrate * the shares solved; that is being fixed now; Ill give an update shortly. A release is being prepared now. |
|
|
|
|
** NOMP Pool Update **
The ABN code has been deployed. Now you can go down the "Hard" path in the documentation.
(Also, you will see a couple new UI fields in the pool, showing Worker ABN shares solved for the round, and Total ABN shares solved for the pool).
Please verify when you solve a "Hard" share, you should receive 2 shares in the stats.
Also please verify that an "Easy" worker only receives 1 share.
I am now looking at the Windows 10 crash.
|
|
|
|
some windows 10 users are stating the 1006 is crashing right away.
the error message is:
0xc00000fd stack_overflow
Have the person paste a screenshot showing the error, and a screenshot showing the configuration they typed in at launch, and conditions leading up to the crash. After that try to reproduce the problem on windows 10. 1006 crashes for me too right away on windows 10. either solo or pool mining. If I use 1004, miner doesn't crash on same machine... somone running on 1006 on linux said it runs fine. 0xc00000fd is stack overflow exception Faulting application name: bbpminer-x86.exe, version: 0.0.0.0, time stamp: 0x5dadcb48 Faulting module name: bbpminer-x86.exe, version: 0.0.0.0, time stamp: 0x5dadcb48 Exception code: 0xc00000fd Fault offset: 0x00000000001c2ed6 Faulting process id: 0x638 Faulting application start time: 0x01d5887e04746f7c Faulting application path: C:\bbp\bbpminer-x86.exe Faulting module path: C:\bbp\bbpminer-x86.exe Report Id: 75e09206-4569-4ebc-a399-ddc2b41be55e Faulting package full name: Faulting package-relative application ID: Ok, good to know we have a reproduceable issue on windows 10. Can you please tell me how many seconds in it crashes into solo mining, or how many hashes it takes with the "-D" switch on? |
|
|
|
Hopefully just a quick fix as I am also trying to make a "hard" account on NOMP pool Are you trying to register an account on the pool? Let's keep it user name as the BBP receiving address. The point is to keep the process simple for miners. Actually since pool.biblepay.org will be going away, we won't have usernames anymore, so that's why they will temporarily need to create a minername that matches their NOMP username. The NOMP username is the BBP receive address. (On a side note, making it simpler for the miner involves either removing ABN altogether, or, making a mandatory change that changes the nature of ABNs; if we keep ABNs, Ill probably make ABNs be embedded in the coinbase so that non ABN mined blocks pay half, but ABN mined blocks pay the full amount; this would remove the requirements from the pools and simplify bbp). In you instructions for using self funded abn on NOMP pool you want us to create a workerid= that is the BBP receive address but pool.biblepay.org will not accept it as it is too long. It truncates it to 19 characters Yes, I know, I thought you guys knew what I meant in this post: https://bitcointalk.org/index.php?topic=2388064.msg52833768#msg52833768This means : The code changes for ABN have not been deployed to both pool.biblepay.org, and also not to nomp.biblepay.org. I'm going to be working on these changes next, praise Jesus. |
|
|
|
Hopefully just a quick fix as I am also trying to make a "hard" account on NOMP pool Are you trying to register an account on the pool? Let's keep it user name as the BBP receiving address. The point is to keep the process simple for miners. Actually since pool.biblepay.org will be going away, we won't have usernames anymore, so that's why they will temporarily need to create a minername that matches their NOMP username. The NOMP username is the BBP receive address. (On a side note, making it simpler for the miner involves either removing ABN altogether, or, making a mandatory change that changes the nature of ABNs; if we keep ABNs, Ill probably make ABNs be embedded in the coinbase so that non ABN mined blocks pay half, but ABN mined blocks pay the full amount; this would remove the requirements from the pools and simplify bbp). |
|
|
|
some windows 10 users are stating the 1006 is crashing right away.
the error message is:
0xc00000fd stack_overflow
Have the person paste a screenshot showing the error, and a screenshot showing the configuration they typed in at launch, and conditions leading up to the crash. After that try to reproduce the problem on windows 10. |
|
|
|
** BiblePay - New NOMP Pool - Opening in BETA mode for testing **
I am proud to announce our new NOMP pool is now opening in Beta mode.
I want to create miner "harder" way, but it's not possible. When I put BBP receiving address as miner name it give me this result: Error while Adding Miner
Miner WorkerName must not be greater than 19 characters long. Record Not Saved. Miner Name updated to 19 length on page. (Error 60002) I haven't deployed the ABN changes yet; but I am trying to get to that next. |
|
|
|
** BiblePay - New NOMP Pool - Opening in BETA mode for testing **
I am proud to announce our new NOMP pool is now opening in Beta mode.
there is 1 worker and 220mhash? should not it be khash? Pool is using the defaults, which are probably ASIC. Yes, I will need to update this parameter to KH/S. |
|
|
|
|
Show Posts
