ALL: I believe I have found a few issues - thank you for sending me the error log! The block IS being solved. As I said before there was no way to tell this without the error logs.
I am working on a fix (several), we will need to fork within 24 hours of its release and I will need to coordinate with all pools and BTER.
Few things I need to work out as to the exact cause, but I should have a fix tonight, with a work by tomorrow later in the day/night (central time).
Good stuff. What's the exact nature of the issue? its something with how POB/POT checking is being interpreted by the pools. Remember, before BTER most mining was solo-mining. I had no clue it could be this because no one provided any error logs or stated their pool was seeing errors - so then we just assume its some other issue - how could anyone know without seeing the mining daemon's logs (I stated numerous times that without logs or rejects mining the chain is fine). Trying still determine the calculation that is off, then I will get a fix built today sometime and binaries released. Its not POB/POT itself, but the block checking thats screwing up somehow. |
|
|
|
So, I have spent a little time browsing through blocks on the block chain to see if there was any patterns in the blocks that are "stuck", and there is. I can with some confidence say that block 11649 will have the following characteristics The coinbase transaction will have 2 output transactions of equal size The coinbase sig will be 26-28 characters long, and the last 14 characters of the sig will be 062f503253482f The block will not be found by either of the pools mention in OP (Crunchharder, Bitember, Miningwithus or Cloudminers) March 17, 2014, 08:47:45 - Found after 1h 29m
Block 11352
Coinbase 02582c02700d062f503253482f
2x 545.5 output
FAvrAQn2cpYFaowSwYiJvuQrwT7PSGp4Rc
FTkUQFwLKW8mWbdks6j2p6UxDdHY49qhkx
March 17, 2014, 06:42:02 - Found after 6h 14m
Block 11303
Coinbase 02272c03fe9a00062f503253482f
2x 1340 output
F6jNAcmpdPVP4CCZWRUZXmocbj5zcjowyN
FNG4aSWm5x6Wa8tsz8hK3XJy2itQeB8fTJ
March 16, 2014, 23:09:08 - Found after 2h 3m
Block 11214
Coinbase 02cf2b0349ae00062f503253482f
2x 2051 output
FDrYFMuhDgRJjRu72EQ7aK6rsYdZMg3L94
F88MAHkFJFX1yEKnB5faMXp11EQJj1rHL5
March 16, 2014, 20:06:49 - Found after 47m
Block 11171
Coinbase 02a32b02f034062f503253482f
2x 4632 output
FQCPgk19Ayax4wg8Sjv3jeMgrmZeQYB7jD
FHPhyaH5FcN3c3csNRGxc7KYS4NQUUxUxE
March 16, 2014, 17:20:48 - Found after 1h 27m
Block 11079
Coinbase 02472b02cf3c062f503253482f
2x 1319.5 output
FBU7EV9RacSCAKmiMnsuem4WHP2u2u82nq
F79mS72WxdQjHQLpZXm2EC5hrrLc24grH3
March 16, 2014, 09:33:52 - Found after 2h 58m
Block 10870
Coinbase 02762a02737d062f503253482f
2x 2487.5 output
FBU7EV9RacSCAKmiMnsuem4WHP2u2u82nq
FJ9ihcwZ7Lcf2JuwKZ6cmoUDc3YFYxc9UC
March 15, 2014, 19:00:29 - Found after 1h 9m
Block 10436
Coinbase 02c428027e66062f503253482f
2x 2054 output
FDrYFMuhDgRJjRu72EQ7aK6rsYdZMg3L94
FJ9ihcwZ7Lcf2JuwKZ6cmoUDc3YFYxc9UC
March 15, 2014, 17:37:15 - Found after 1h 33m
Block 10406
Coinbase 02a6280390af00062f503253482f
2x 4104 output
FMf3Y9hLxsSuotSUsYqeCQyu4FQZENkGyp
FQCXJjAjEhwKgwLHyG9DxKCgLaPPz3hVAt
Coinbase sig for the latest block found by each of the pools for comparison: 11648 02802d062f503253482f04f910275308100004840f0000000d2f7374726174756d506f6f6c2f Cruncharder
11647 027f2d062f503253482f04a310275308980178fa150000000d2f7374726174756d506f6f6c2f Bitember
11646 027e2d062f503253482f041410275308f8003861490000000d2f7374726174756d506f6f6c2f Miningwithus
11644 027c2d062f503253482f04790f275308f800368fa50000000d2f7374726174756d506f6f6c2f Cloudminers
I have no idea how to interpret the information above as I have very little technical insight to the inner workings of crypto coins and how blocks are generated. But, assuming some of the information for the next block is known to the entire network (besides transactions), may guess is there could be some parameter or information in the upcoming block that the pools are unable to process correctly, and thus we have to wait for a non-pool miner to solve the block. Edit: Of course thekidcoin found the problem while I was typing all this up  thanks for the info, good stuff Bitember actually found the block... Without their log data I had no real leg to stand on. Its something being interpreted wrong causing the block to be rejected (nice info too thanks I just added so many printf's to my test binary I nearly filled up my drive LOL)... Which means likely that someone else needs to solve it. OK OK I can't post anymore need to work on this LOL |
|
|
|
|
ALL: I believe I have found a few issues - thank you for sending me the error log! The block IS being solved. As I said before there was no way to tell this without the error logs.
I am working on a fix (several), we will need to fork within 24 hours of its release and I will need to coordinate with all pools and BTER.
Few things I need to work out as to the exact cause, but I should have a fix tonight, with a work by tomorrow later in the day/night (central time).
|
|
|
|
Maybe the guys from fedoracoin (TIPS) can help?
They also had very long block times now and then but thats solved somehow
thanks for the tip will see what they did |
|
|
|
|
We need logs from these pools or at least for them to search the logs for: checkblock or connectblock errors - that would give us the ammo needed to fix an issue
anyways enough debate i need to modify/test repeat until i hear from any people i have looking into this, the only thing I can do is test code and see if i can spot the hangup
Another possibility though far-fetched is that someone with big hashrate modded the client to try and disable POB/POT effectively nullifying their hashrate as 1) if they didn't disable the checking it would never be accepted (only they would see this in the logs) 2) if they disabled the checking it would be rejected elsewhere (we would see that in the logs though)
thanks also for the info godwits
|
|
|
|
Another strange thing is that I ca I am testing, do you think I'm sitting here blaming pools without good reason?
Well, you keep mentioning the fact there's a pool with over 50%. That should have no effect, so I don't know why you keep mentioning it. The problem IS difficulty related - just not too high of difficulty, I believe someone is dropping their hashrate - who or why is the question of the day.
If there were any other issues pools would report rejected blocks.
As of the last block, net hashrate was at 2GH/s. Looking at the pools right now, there is at least 600MH/s there. Assuming that no one is solo mining (which isn't the case), that puts the absolute minimum net hashrate at 30% of what it was at the last block, and is probably much more like 60-70%. That's not enough to cause blocks to be stuck for such a long period. So the problem is not people actively dropping their hashrate during stuck blocks. That's certain. So what other causes for dropped hashrate could there be? All I can think is with the stratum implementation - did you compile this or did one of the pool operators? While I work on what the cause is ask yourself why after the next long block is solved hashrate will skyrocket again (as identifiable by the fast mining that will occur)
I already mentioned that a few pages back, that as soon as a stuck block is solved, several more follow immediately, and you questioned whether I knew how mining works to say such a thing, lol? I stand by my point. They are found quickly because difficulty is too low after the block is solved because difficulty adjusts. Then hashrate skyrockets again for another cycle of this. Again, are these miners just jumping right back on board next block?  I guess I am the only one that finds it curious that the coin worked issue free save for forking once that entire week when bitember was using 75% of the hasrate. I pointed out stratum as a possible issue 2 days ago. There is a stratum exploit that allows people to inflate their hashrate 1000x what they have. How in the world can that possibly cause issues? |
|
|
|
I don't use any fork over another - there is central checkpointing. |
|
|
|
Someone note the coinbase value of the next block when it hits.
how? when its mined LOL. Its will be worth though 4689.00 |
|
|
|
|
I am testing, do you think I'm sitting here blaming pools without good reason?
The problem IS difficulty related - just not too high of difficulty, I believe someone is dropping their hashrate - who or why is the question of the day.
If there were any other issues pools would report rejected blocks.
The next block will be worth 4689.00 - most of these stuck blocks seem to be below 5000. That is what i am now looking at.
While I work on what the cause is ask yourself why after the next long block is solved hashrate will skyrocket again (as identifiable by the fast mining that will occur)
|
|
|
|
|
Someone note the coinbase value of the next block when it hits.
|
|
|
|
maybe we should message them and let them know people are being disgruntled about their pool service because of the hash issue. might be enough reason for them to pause it for a day.
I mean maybe I'm insane, but my only theory is that they, with most of the hashrate get stuck for whatever reason (its there difficulty adjusted on these pools??), maybe a miner exploiting stratum, maybe a config issue, and because they usually find the most blocks, they essentially halt the network as no one else has the hashrate or luck to find blocks. Everything needs to be vetted at this point. I still believe this to be an incorrect approach to start at the pools. Why? I'm no programmer, but logic tells me that pools (in general) are tried and tested when it comes to scrypt coins. They behave as expected and are using software for the pools that (at this point) has been pretty well vetted. I believe the stalling on the pools when the hashrate spikes is a symptom. We presume you used a "proven" coin for the foundation of FLT. Hopefully a coin that was (at least at one point) heavily mined. If so, you should check the forums for any similar issues the coin might have had. If there are none that are similar, you have to look at your code and what you've added to it. To me, this is the most obvious starting point because again, pools & mining are pretty well tested and this isn't some weird DDOS to stall out the coin, no one is getting coins when it's stuck. Again, I don't even know if what i'd propose is plausible, but if this was my project team and they were stuck i'd start trying to troubleshoot with big, broad strokes. - Go into the coin, "turn off" the POB stuff altogether (if possible), release a patch, see if it gets stuck - If same thing happens, do the same with the POS stuff, release patch, see if it gets stuck I just don't see how you're not starting at what you've added to the coin as the potential problem. You said it yourself - your not a programmer. You don't realease patches to test things number 1, number 2 POB has no bearing - it's not even considered until a block is mined, POS will not be active for weeks. Pools kill coins all the time. If these things were the issue we would have seen it before. The base for this coin as you say is NVC and PPC. I find it hard to believe how people find it OK that a pool had 50% of the hashrate. |
|
|
|
I think it's also in your best interest (and the coin's) to reach out to some other developers for help. I PM'ed you the names of the 2 guys who helped rescue GPU coin. I had chatted with them in IRC during that launch and they were super mellow, they might be willing to help. But lots of coin devs are on IRC, i think as the developer you should reach out if you're stuck.
Already been reaching out... |
|
|
|
|
Could something like this combined with say a pool with 50% + of the network hashrate (at times up to 75%) cause a blockchain to stall, say for 1 1/2 hours at times with no found block?
At my last straw here LOL
|
|
|
|
Proof-Of-Stak Anyone got any staked coins? I've seen this feature on other coins yet never experienced it. Might be the unicorn of cryptocoins! i like proof-of-steak personally |
|
|
|
morning kidcoin. i've been keeping the night watch lol. lots of blocks mined, not quite 1200 tho. but u were right about the pace of blocks picking up
should only be 720 blocks mined per day... |
|
|
|
maybe we should message them and let them know people are being disgruntled about their pool service because of the hash issue. might be enough reason for them to pause it for a day.
I mean maybe I'm insane, but my only theory is that they, with most of the hashrate get stuck for whatever reason (its there difficulty adjusted on these pools??), maybe a miner exploiting stratum, maybe a config issue, and because they usually find the most blocks, they essentially halt the network as no one else has the hashrate or luck to find blocks. Everything needs to be vetted at this point. |
|
|
|
|
I still say we need to abandon bitember for a day to see if it's sticking the blocks. It's possible
|
|
|
|
Hello. I just started to mine this coin.. What's the IRC for this coin? and why does the bitember pool have 90% of the total coin's hashrate?  #fluttercoin And yes that's a problem. |
|
|
|
What about the nethashrate vs total poolshashrate? At stuck block 11302 it says 2092mH/s but the total poolshashrate is now about 926mH/s. Shouldn't the nethashrate also be adjusted or is it fixed when started a new block? http://explorer.fluttercoin.us/block_crawler.phpStill don't understand why the nethashrate isn't the same as the total poolshashrate. If a pool can be offline and the nethashrate isn't drops than that pool isn't registered to the nethashrate? http://explorer.litecoin.net/block/11302http://explorer.litecoin.net/block/00000000019c7d2d21bcbe9d7ff2d9d5715c734229e13dc613b15ab63644a3b5Pool Hash Rate491.136 MH/s Pool Efficiency99.07 % Current Active Workers339 Next Network Block11303 (Current: 11302) Last Block Found11302 Est. Avg. Time per Round (Network)1 minute 5 seconds Est. Avg. Time per Round (Pool)4 minutes 41 seconds Est. Shares this Round32,932 (done: 9,441.60 %) Time Since Last Block5 hours 31 minutes 47 seconds again block was found by bitember but we are still finding block 11302. This pool could be the issue if it's not updating... It's per new block - it's a calculation |
|
|
|
What about the nethashrate vs total poolshashrate? At stuck block 11302 it says 2092mH/s but the total poolshashrate is now about 926mH/s. Shouldn't the nethashrate also be adjusted or is it fixed when started a new block? http://explorer.fluttercoin.us/block_crawler.phpStill don't understand why the nethashrate isn't the same as the total poolshashrate. If a pool can be offline and the nethashrate isn't drops than that pool isn't registered to the nethashrate? http://explorer.litecoin.net/block/11302http://explorer.litecoin.net/block/00000000019c7d2d21bcbe9d7ff2d9d5715c734229e13dc613b15ab63644a3b5Pool Hash Rate491.136 MH/s Pool Efficiency99.07 % Current Active Workers339 Next Network Block11303 (Current: 11302) Last Block Found11302 Est. Avg. Time per Round (Network)1 minute 5 seconds Est. Avg. Time per Round (Pool)4 minutes 41 seconds Est. Shares this Round32,932 (done: 9,441.60 %) Time Since Last Block5 hours 31 minutes 47 seconds again block was found by bitember but we are still finding block 11302. This pool could be the issue if it's not updating... |
|
|
|
|
Show Posts
