FeatherCoin Mining Conundrum

[wndrbr3d]

So I've run into this problem on several FC pools and thought I'd throw this out there to the general community to see everyone's thoughts.

Because FC generates blocks so quickly (compared to LTC/BTC), my client barely has time to even start hashing on the CPU before a new block is found and work needs to start all over. There was a period this morning after pointing one of my LTC miners to FC, where an i5-3770 went seven minutes before generating a single share of work due to the rate at which new blocks were generated on the network.

This might be an issue with both FC itself (block generation is just too fast for Scrypt clients) but also the pools need to lower their share difficulty. The issue here is that it'll put a heavier load on the pools and eventually drive up costs for hosting them, which could mean trouble for the coin.

Curious folks' thoughts on this

Cheers!

EDIT (for those who apparently need it):

The reason this is an issue specifically for Feathercoin compared to BTC/LTC is that BTC wants to issue 6 blocks per hour. If there's a CRAZY jump in hashing power, that can hit 10-15 generating a new block every 7-10 minutes. Faster, but plenty of time for miners to still submit shares.

With Feathercoin, new blocks are generated every 2.5 minutes. If hashing power doubles or more (as it has been since it's a small, growing network), blocks can be issued every ~45sec-1 minute. Depending on the share difficulty of a pool, this isn't enough time (on average) for a miner to even complete working on a share.

A workaround to mask this issue (as I stated prior), is for a pool to lower the share difficulty so miners submit shares more frequently.

[1715161140]

1715161140

[Thracky]

It's only happening so fast because of the crazy amounts of mining power compared to the current difficulty.  The actual target block time is identical to LTC (as is almost all of the Feathercoin code).  Also, difficulty is way too high to be CPU mining, its utterly pointless right now, as it is for LTC and BTC.

[wndrbr3d]

It's only happening so fast because of the crazy amounts of mining power compared to the current difficulty.  The actual target block time is identical to LTC (as is almost all of the Feathercoin code).  Also, difficulty is way too high to be CPU mining, its utterly pointless right now, as it is for LTC and BTC.

I think you completely missed the point of my post. Thanks for the troll though 

The issue is with pools and the shares generated vs. new block generated and resetting the miners efforts. Network difficulty has nothing to do with my concern.

[503guy]

It's only happening so fast because of the crazy amounts of mining power compared to the current difficulty.  The actual target block time is identical to LTC (as is almost all of the Feathercoin code).  Also, difficulty is way too high to be CPU mining, its utterly pointless right now, as it is for LTC and BTC.

I think you completely missed the point of my post. Thanks for the troll though 

The issue is with pools and the shares generated vs. new block generated and resetting the miners efforts. Network difficulty has nothing to do with my concern.

Actually, your problem has everything to do with network difficulty.  Low net diff + high hash rate = high rate of new blocks.  New blocks are solved so quickly that you aren't even able to solve one single share during the time frame.

[wndrbr3d]

It's only happening so fast because of the crazy amounts of mining power compared to the current difficulty.  The actual target block time is identical to LTC (as is almost all of the Feathercoin code).  Also, difficulty is way too high to be CPU mining, its utterly pointless right now, as it is for LTC and BTC.

I think you completely missed the point of my post. Thanks for the troll though  

The issue is with pools and the shares generated vs. new block generated and resetting the miners efforts. Network difficulty has nothing to do with my concern.

Actually, your problem has everything to do with network difficulty.  Low net diff + high hash rate = high rate of new blocks.  New blocks are solved so quickly that you aren't even able to solve one single share during the time frame.

So you can say then that with FC, miners will begin making less the closer a network gets to retarget then.

And specifically with FC and the rate of blocks generated, this becomes a larger issue. I mean, in my example, I lose 30-40% of my income as the network continues to grow prior to retarget. In my OP I mention how pools might overcome this by lowering their share difficulty (resulting in more shares generated), but it would still only be masking the issue.

How is this not a problem?

[Thracky]

It's an issue with ANY cryptocurrency that experiences huge increases in mining power.  This has nothing to do with Feathercoin, it's codebase is 99% identical to litecoin.  But of course I was just trying to troll you before right?

[drawingthesun]

The only thing I have ever been able to do in this situation is set these flags in cgminer:

Code:

--expiry 1 --queue 0

This helps the miner get shares in faster, if your already doing this then maybe contact the pool operators about the share difficulty. I'm not sure why the pools difficulty is so high, even the Litecoin pools I use accept lower difficulty shares. Maybe its a FTC thing?

[wndrbr3d]

It's an issue with ANY cryptocurrency that experiences huge increases in mining power.  This has nothing to do with Feathercoin, it's codebase is 99% identical to litecoin.  But of course I was just trying to troll you before right?

Trolls gonna Troll. You're refusing to see why this is more an issue when it comes to FC.

The issue here is block generation time on the network and the impact on workers. Although I agree this issue impacts ALL cryptocurrencies (technically), it shows itself more prominently with Feathercoin because of the rate of blocks being generated (every 2.5 minutes "target") vs. LTC or BTC. Throw in a good rate of network growth and you see the same issue like I did where miners lose a significant amount of income as the network comes up to retarget.

[wndrbr3d]

Here's a good visualization of the issue I'm talking about here:



You can see my worker hash rate starts to tank after re-target because of the rate at which new blocks are being generated causes my worker to abandon the current work and start over on a new block.

I say again, I believe this issue is caused by blockchains that generate new blocks too quickly and pools that don't lower their share difficulty. For currencies like Feathercoin (and any other hyper-issued currency), pools will probably have to adjust to mask this issue.

The example above is just an i5-3770 (~45khash) running against the pool for 24 hours.

How has this not been called out as an issue for these currencies yet?

[thep33t]

Here's a good visualization of the issue I'm talking about here:



You can see my worker hash rate starts to tank after re-target because of the rate at which new blocks are being generated causes my worker to abandon the current work and start over on a new block.

I say again, I believe this issue is caused by blockchains that generate new blocks too quickly and pools that don't lower their share difficulty. For currencies like Feathercoin (and any other hyper-issued currency), pools will probably have to adjust to mask this issue.

The example above is just an i5-3770 (~45khash) running against the pool for 24 hours.

How has this not been called out as an issue for these currencies yet?

I don't think you understand how this who mining thing, especially the pools and their hashrate displays, work.

Firt of all, any pool from a copy/paste to slushs himself do not report true hashrates. It is impossible. If your machine AVERAGES 45kh/s (which your post shows), it is working properly.

In other words, average to your hashrate to a longer period of time, and you will see it equal (within a few percent) to your actual hashrate.

[wndrbr3d]

I don't think you understand how this who mining thing, especially the pools and their hashrate displays, work.

Firt of all, any pool from a copy/paste to slushs himself do not report true hashrates. It is impossible. If your machine AVERAGES 45kh/s (which your post shows), it is working properly.

In other words, average to your hashrate to a longer period of time, and you will see it equal (within a few percent) to your actual hashrate.

I don't think you read the whole post, but that's cool. I'll start over from the top.

The issue I see is that my miner, because of the issuance of new blocks on the network, doesn't have an opportunity to even submit a share prior to a new block being discovered. Because of this, on a growing network, any worker will submit fewer and fewer shares prior to retarget because of the rate at which new blocks are issued causing workers to abandon any work they've done and restart hashing shares on the new block.

I've seen instances where a miner went 7-10min before submitting a single share because new blocks were issued so quickly.

Anyone want to have a well thought out discussion on the topic or are there only trolls here?

[thep33t]

I don't think you understand how this who mining thing, especially the pools and their hashrate displays, work.

Firt of all, any pool from a copy/paste to slushs himself do not report true hashrates. It is impossible. If your machine AVERAGES 45kh/s (which your post shows), it is working properly.

In other words, average to your hashrate to a longer period of time, and you will see it equal (within a few percent) to your actual hashrate.

I don't think you read the whole post, but that's cool. I'll start over from the top.

The issue I see is that my miner, because of the issuance of new blocks on the network, doesn't have an opportunity to even submit a share prior to a new block being discovered. Because of this, on a growing network, any worker will submit fewer and fewer shares prior to retarget because of the rate at which new blocks are issued causing workers to abandon any work they've done and restart hashing shares on the new block.

I've seen instances where a miner went 7-10min before submitting a single share because new blocks were issued so quickly.

Anyone want to have a well thought out discussion on the topic or are there only trolls here?

I did read your post.

Your miner has no better chance of solving a block after 2 seconds than it does after 30 minutes.

Put in other words. The chance of you finding a block is independent of the amount of time spent.

if retarget was 30 minutes, you still are not guaranteed to find a block in that time, you just are more likely.

[wormbog]

I believe this is a non-issue, rooted in the concept of "abandoned" work. With mining there is no cumulative effect for mining. Thousands (or millions) of times per second you either find a share or you don't, and each failure is immediately and forever worthless. New blocks will only lose you the time between when a new block is found and when your miner is notified of it. If you find a share during this lag period you get a stale share. Unless you're seeing an increase in stales your mining efficiency is not effected by the fast block time or higher difficulty.

[thep33t]

I believe this is a non-issue, rooted in the concept of "abandoned" work. With mining there is no cumulative effect for mining. Thousands (or millions) of times per second you either find a share or you don't, and each failure is immediately and forever worthless. New blocks will only lose you the time between when a new block is found and when your miner is notified of it. If you find a share during this lag period you get a stale share. Unless you're seeing an increase in stales your mining efficiency is not effected by the fast block time or higher difficulty.

What I was trying to say, said more elegantly.

[wndrbr3d]

I believe this is a non-issue, rooted in the concept of "abandoned" work. With mining there is no cumulative effect for mining. Thousands (or millions) of times per second you either find a share or you don't, and each failure is immediately and forever worthless. New blocks will only lose you the time between when a new block is found and when your miner is notified of it. If you find a share during this lag period you get a stale share. Unless you're seeing an increase in stales your mining efficiency is not effected by the fast block time or higher difficulty.

What I was trying to say, said more elegantly.

I still disagree.

Stale shares would be a solved share submitted after a new block has been issued on the network, prior to the client being notified.

What I'm saying is that if it takes X time to solve a share (based on share difficulty of a pool), and Y time for a block to be issued (2.5 minutes for Feathercoin), then it goes to reason that if X is static but Y continues to go down prior to retarget that my miner would generate less and less income.

The issue with Feathercoin (and any hyper-issued crypto) is that Y is already low and on a growing network gets very low, so the issue shows itself more. A prior post made the point that true, ANY crypto runs into this, but where as on BTC it's a non-issue and LTC is less of an issue, on Feathercoin it seems to be a legit issue.

[thep33t]

I believe this is a non-issue, rooted in the concept of "abandoned" work. With mining there is no cumulative effect for mining. Thousands (or millions) of times per second you either find a share or you don't, and each failure is immediately and forever worthless. New blocks will only lose you the time between when a new block is found and when your miner is notified of it. If you find a share during this lag period you get a stale share. Unless you're seeing an increase in stales your mining efficiency is not effected by the fast block time or higher difficulty.

What I was trying to say, said more elegantly.

I still disagree.

Stale shares would be a solved share submitted after a new block has been issued on the network, prior to the client being notified.

What I'm saying is that if it takes X time to solve a share (based on share difficulty of a pool), and Y time for a block to be issued (2.5 minutes for Feathercoin), then it goes to reason that if X is static but Y continues to go down prior to retarget that my miner would generate less and less income.

The issue with Feathercoin (and any hyper-issued crypto) is that Y is already low and on a growing network gets very low, so the issue shows itself more. A prior post made the point that true, ANY crypto runs into this, but where as on BTC it's a non-issue and LTC is less of an issue, on Feathercoin it seems to be a legit issue.

So now you go from talking about complete lack of shares to increased stales? That is a completely different topic than you originally posted.

In a nutshell, faster block times= increased chance for stales if miners and pools are not set up correctly (mostly the miners)

I am done with this conversition(s).

[wndrbr3d]

So now you go from talking about complete lack of shares to increased stales? That is a completely different topic than you originally posted.

In a nutshell, faster block times= increased chance for stales if miners and pools are not set up correctly (mostly the miners)

I am done with this conversition(s).

I didn't say anything about increased stale shares. I was disagreeing with the previous point of trying to say what I was talking about was stale shares, which I'm not.

My overall point here again is that with increased network hashing power prior to retarget is that miners have less and less of a chance of submitting shares prior to a new block being discovered, leading to a decrease in mining income after a retarget, with the lowest point being just prior to retarget.

Again, the issue here is that pools (most) set a static share difficulty X saying that it should take a certain amount of time/hashing power for a share to be submitted. The network WANTS to generate blocks at Y rate, but as network hashing power goes up, Y continues to drop until retarget. As Y drops, the miner of a pool with static share difficulty X has less and less of a chance to solve a share prior to a new block on the network.

EDIT (for those who apparently need it):

The reason this is an issue specifically for Feathercoin compared to BTC/LTC is that BTC wants to issue 6 blocks per hour. If there's a CRAZY jump in hashing power, that can hit 10-15 generating a new block every 7-10 minutes. Faster, but plenty of time for miners to still submit shares.

With Feathercoin, new blocks are generated every 2.5 minutes. If hashing power doubles or more (as it has been since it's a small, growing network), blocks can be issued every ~45sec-1 minute. Depending on the share difficulty of a pool, this isn't enough time (on average) for a miner to even complete working on a share.

A workaround to mask this issue (as I stated prior), is for a pool to lower the share difficulty so miners submit shares more frequently.

[markm]

The issue is that in order to pre-mine as many coins as possible, the designers of new coins, starting as far back as Litecoin, deliberately screwed around with the initial difficulty, not to make it more difficult to correct for the vast amount more mining power that can be expected / prediicted to instantly jump on the chain than jumped instantly on Satoshi's original chain but, in fact, totally the opposite: they lowered it, to make sure they could rake in massive numbers of blocks as fast as possible in the first few minutes.

Basically it was and is a total scam based on trying to semantically loophole/game by pretending they did not pre-mine while nonetheless actually having many seconds and thus many blocks of pre-mining quickly accomplished right out in plain sight upon launch.

Litecoin started it, the others have simply made it even less difficult at launch than even litecoin did.

By the way, previous poster, the 2.5 minute target time is just simply the same target as litecoin, cloned from litecoin.

The problem is the actual at-launch target time, targetted by adjusting the starting difficulty, was less than a second.

-MarkM-