8th Alt coin thread. Or what to do now that asics are all over the place.

[shield132]

To come back to more practical things... I figured I'd ask in here:
How do you determine how to best set difficulty correctly for a rig manually? Vardiff nowadays is supposed to do it, but it often takes long to adjust and is often suboptimal. Is there a "golden rule" or "middle" for the amount of shares a rig should ideally submit per minute?

Golden rule is that you have to set difficulty high enough to reduce the network and mining delays, not more because it can result in opposite. For example if difficulty is very high, then miners generate shares too infrequently, as user above me posted, his earning start to decline once it taked longer than 5 minute to find a share. So not so hard to set difficulty yourself.

[1714066373]

1714066373

[1714066373]

1714066373

[JaredKaragen]

To come back to more practical things... I figured I'd ask in here:
How do you determine how to best set difficulty correctly for a rig manually? Vardiff nowadays is supposed to do it, but it often takes long to adjust and is often suboptimal. Is there a "golden rule" or "middle" for the amount of shares a rig should ideally submit per minute?

Golden rule is that you have to set difficulty high enough to reduce the network and mining delays, not more because it can result in opposite. For example if difficulty is very high, then miners generate shares too infrequently, as user above me posted, his earning start to decline once it taked longer than 5 minute to find a share. So not so hard to set difficulty yourself.

if Time was a function of the hash;  such like it is with SSL and other encryption schemes;  the difficulty/ASIC issue would be much less of an issue overall.... probably a non-existent issue.   Leaves things closer to the purely "random" concept of hash generation.... nullifying the speed aspect.

[dragonmike]

as user above me posted, his earning start to decline once it taked longer than 5 minute to find a share. So not so hard to set difficulty yourself.

That's essentially the piece of info I was looking for.
So basically if you submit a couple of shares a minute, you're pretty much where you should be - no profitability hit and no big strain on the network.

Cheers

[philipma1957]

as user above me posted, his earning start to decline once it taked longer than 5 minute to find a share. So not so hard to set difficulty yourself.

That's essentially the piece of info I was looking for.
So basically if you submit a couple of shares a minute, you're pretty much where you should be - no profitability hit and no big strain on the network.

Cheers

Yeah  1, 2 or 3 per minute  are all good.

[adaseb]

Did you guys know that if you've mined with F2Pool, and found a block, your username is permanently on the Bitcoin blockchain.

Check this out

https://blockchair.com/bitcoin/block/399594

�7七彩神仙鱼_�ϝj�(�^3ZmkT9S�w�PB�"�ƃU54🐟Mined by adaseb


So in 50 years, if bitcoin still exists, i can tell my kids kids that I mined block 399594.


I am pretty sure that block was found with an old Antminer S3 or an KnCMiner Jupiter.

Did any of you guys find any blocks with F2Pool and get your username permanently written on the bitcoin blockchain for the end of time?

[badfad]

as user above me posted, his earning start to decline once it taked longer than 5 minute to find a share. So not so hard to set difficulty yourself.

That's essentially the piece of info I was looking for.
So basically if you submit a couple of shares a minute, you're pretty much where you should be - no profitability hit and no big strain on the network.

Cheers

Does this apply to coins with fast blocktimes, under 1 min ?

[citronick]

ahhh... the good ole days, my S9s and A7s mined more than 20 blocks at kano and 2 solo blocks at ckpool.... I dont think there is a permanent signature inserted into the coinbase field at kano or solo ckpool.

If I could turn back time.....

Did you guys know that if you've mined with F2Pool, and found a block, your username is permanently on the Bitcoin blockchain.

Check this out

https://blockchair.com/bitcoin/block/399594

�7七彩神仙鱼_�ϝj�(�^3ZmkT9S�w�PB�"�ƃU54🐟Mined by adaseb


So in 50 years, if bitcoin still exists, i can tell my kids kids that I mined block 399594.


I am pretty sure that block was found with an old Antminer S3 or an KnCMiner Jupiter.

Did any of you guys find any blocks with F2Pool and get your username permanently written on the bitcoin blockchain for the end of time?

[philipma1957]

ahhh... the good ole days, my S9s and A7s mined more than 20 blocks at kano and 2 solo blocks at ckpool.... I dont think there is a permanent signature inserted into the coinbase field at kano or solo ckpool.

If I could turn back time.....

Did you guys know that if you've mined with F2Pool, and found a block, your username is permanently on the Bitcoin blockchain.

Check this out

https://blockchair.com/bitcoin/block/399594

�7七彩神仙鱼_�ϝj�(�^3ZmkT9S�w�PB�"�ƃU54🐟Mined by adaseb


So in 50 years, if bitcoin still exists, i can tell my kids kids that I mined block 399594.


I am pretty sure that block was found with an old Antminer S3 or an KnCMiner Jupiter.

Did any of you guys find any blocks with F2Pool and get your username permanently written on the bitcoin blockchain for the end of time?

I hit two blocks on ck solo
I hit two blocks on Mmpool
I hit two blocks on bitminter.

I used to mine a coin a day on bitminter.

The entire network was only 21th

[JaredKaragen]

The only time I shot for a BTC block solo was when BTC was sub 1K, and network diff was about 62 Million.......  The S7 was semi-new tech at the time, but more efficient miners were just around the corner.....

Luckily I was able to still sign my mining address on blockchain.info to add a custom label before Coinbase decided signing messages was no longer a feature for us peons:  https://www.blockchain.com/btc/address/1PHSDYvVp6HpqtuUPocK41DrdeHbbezaeP

[MagicSmoker]

That's essentially the piece of info I was looking for.
So basically if you submit a couple of shares a minute, you're pretty much where you should be - no profitability hit and no big strain on the network.

Cheers

Does this apply to coins with fast blocktimes, under 1 min ?

Good question, and the short answer is the time to find each share should be a minor fraction of the block time to minimize the amount of work wasted on blocks found elsewhere.

For example, say you are finding a share every 30 seconds on average and you receive a task from the pool at t+10 (that is, 10 seconds into the new block) with a block time of 60 seconds. You submit the share at t+50 and receive a new task, but at t+60 the block is solved by someone else, so the work you did from t+50 to t+60 is tossed out.

A good rule of thumb I use for coins that have short block times (under 2 minutes) is to set fixed diff so that I find shares every 10% of the block time. For example, if the block time is 120 seconds I'll set diff to find a share every 12 seconds. This may not be practical when block time drops below 30 seconds, however, at which point a significant loss of earnings from obsolete shares is inevitable.

[adaseb]

That's essentially the piece of info I was looking for.
So basically if you submit a couple of shares a minute, you're pretty much where you should be - no profitability hit and no big strain on the network.

Cheers

Does this apply to coins with fast blocktimes, under 1 min ?

Good question, and the short answer is the time to find each share should be a minor fraction of the block time to minimize the amount of work wasted on blocks found elsewhere.

For example, say you are finding a share every 30 seconds on average and you receive a task from the pool at t+10 (that is, 10 seconds into the new block) with a block time of 60 seconds. You submit the share at t+50 and receive a new task, but at t+60 the block is solved by someone else, so the work you did from t+50 to t+60 is tossed out.

A good rule of thumb I use for coins that have short block times (under 2 minutes) is to set fixed diff so that I find shares every 10% of the block time. For example, if the block time is 120 seconds I'll set diff to find a share every 12 seconds. This may not be practical when block time drops below 30 seconds, however, at which point a significant loss of earnings from obsolete shares is inevitable.

Depending on the pool, don't you still get creditted for the stale share if its found?

This is generally the issue with these crazy low block times. Because there can be times where a block is found every 5 seconds and due to the network latency and such, only the ones with close connections to the server would benefit.

Hence its why some pools pay for your stale shares.

Either way, in the end it should all balance out. You submit more stales, get less rewards but on another day some other miner submits more stales and gets less rewards and you get more.

Either way, your profits are in general about 95% of the value displayed with the WTM calculator.

[badfad]

That's essentially the piece of info I was looking for.
So basically if you submit a couple of shares a minute, you're pretty much where you should be - no profitability hit and no big strain on the network.

Cheers

Does this apply to coins with fast blocktimes, under 1 min ?

Good question, and the short answer is the time to find each share should be a minor fraction of the block time to minimize the amount of work wasted on blocks found elsewhere.

For example, say you are finding a share every 30 seconds on average and you receive a task from the pool at t+10 (that is, 10 seconds into the new block) with a block time of 60 seconds. You submit the share at t+50 and receive a new task, but at t+60 the block is solved by someone else, so the work you did from t+50 to t+60 is tossed out.

A good rule of thumb I use for coins that have short block times (under 2 minutes) is to set fixed diff so that I find shares every 10% of the block time. For example, if the block time is 120 seconds I'll set diff to find a share every 12 seconds. This may not be practical when block time drops below 30 seconds, however, at which point a significant loss of earnings from obsolete shares is inevitable.

This made me remember mining eth with one 380 2Gb on ethpool I think, I was getting a share every few minutes(I was counting them ). Profit was what within wtm margins though, nothing lost nothing gained.

[adaseb]

That's essentially the piece of info I was looking for.
So basically if you submit a couple of shares a minute, you're pretty much where you should be - no profitability hit and no big strain on the network.

Cheers

Does this apply to coins with fast blocktimes, under 1 min ?

Good question, and the short answer is the time to find each share should be a minor fraction of the block time to minimize the amount of work wasted on blocks found elsewhere.

For example, say you are finding a share every 30 seconds on average and you receive a task from the pool at t+10 (that is, 10 seconds into the new block) with a block time of 60 seconds. You submit the share at t+50 and receive a new task, but at t+60 the block is solved by someone else, so the work you did from t+50 to t+60 is tossed out.

A good rule of thumb I use for coins that have short block times (under 2 minutes) is to set fixed diff so that I find shares every 10% of the block time. For example, if the block time is 120 seconds I'll set diff to find a share every 12 seconds. This may not be practical when block time drops below 30 seconds, however, at which point a significant loss of earnings from obsolete shares is inevitable.

This made me remember mining eth with one 380 2Gb on ethpool I think, I was getting a share every few minutes(I was counting them ). Profit was what within wtm margins though, nothing lost nothing gained.

Yes because they use a fixed difficulty which is usually based on submitting 1 share every 30-60 seconds or so based on a typical rig with like 5 GPUs or so.

Some hours you might submit less shares, other hours you will submit more shares due to variance of your GPU and pretty much luck.

But in the long run, you will get more or less what you are suppose to.

The way the hashing and algos work, its completely random and there is no secret pattern.

[philipma1957]

So I got a lot of gear on sales and built a 1920x threadripper build for about 1124 usd.


a 1920x for 404
a nvme for 220
32gb ram for 220
a mobo for 280


I loaded nicehash and i am getting terrible hash  of 193h for the cpu which means the large page is not set I can not seem to set it correctly

Does anyone have a thread ripper mining on a windows 10 pro setup.

I could use some tips.




PHIL'STHREADRIPPER

is the pc name and I have it showing.

do I NEED to run as admin?

[N2DCRYPT]

So I got a lot of gear on sales and built a 1920x threadripper build for about 1124 usd.


a 1920x for 404
a nvme for 220
32gb ram for 220
a mobo for 280


I loaded nicehash and i am getting terrible hash  of 193h for the cpu which means the large page is not set I can not seem to set it correctly

Does anyone have a thread ripper mining on a windows 10 pro setup.

I could use some tips.




PHIL'STHREADRIPPER

is the pc name and I have it showing.

do I NEED to run as admin?

Phil, I run a 1950x on Windows 10 pro. Make sure you're alternating threads due to the hyperthreading, something like this:


"cpu_threads_conf" :
[
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 0 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 2 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 4 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 6 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 8 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 10 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 12 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 14 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 16 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 18 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 20 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 22 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 24 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 26 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 28 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 30 },

],

You'll want to delete the last four lines though as yours is 12 core. I'm assuming you're running xmr-stak, that's what I use.

[DevelopmentBank]

as user above me posted, his earning start to decline once it taked longer than 5 minute to find a share. So not so hard to set difficulty yourself.

That's essentially the piece of info I was looking for.
So basically if you submit a couple of shares a minute, you're pretty much where you should be - no profitability hit and no big strain on the network.

Cheers

Been mining for a year now but i feel like a passive miner for not looking into things like these.

If i understand from your post, please correct me if i'm wrong, it is better to set a "fixed" difficulty while mining so that earnings don't decline? If so, how does one do this with your regular mining software like Claymore or EWBF for example? All i know are the basic miner settings and configurations.

[MagicSmoker]

Good question, and the short answer is the time to find each share should be a minor fraction of the block time to minimize the amount of work wasted on blocks found elsewhere.
...

Depending on the pool, don't you still get creditted for the stale share if its found?
...

Hmm, none of the pools I regularly use give credit for stale shares. In fact, after I configured Claymore to not submit stale shares mining Musicoin my actual earnings are always within 1-2% of predicted (before it was 3-5%). That said, this might be a case of me mining at the wrong pools?! 

[dragonmike]

Good question, and the short answer is the time to find each share should be a minor fraction of the block time to minimize the amount of work wasted on blocks found elsewhere.
...

Depending on the pool, don't you still get creditted for the stale share if its found?
...

Hmm, none of the pools I regularly use give credit for stale shares. In fact, after I configured Claymore to not submit stale shares mining Musicoin my actual earnings are always within 1-2% of predicted (before it was 3-5%). That said, this might be a case of me mining at the wrong pools?! 

Doktor83 (the dev of SRBminer) noticed (after a lot of whinging by some noobs) that by submitting stale share the reported hashrates on some yiimp-based pools actually increased noticeably so he added the feature that could be used in the command line (-sendallstales).

[MagicSmoker]

Doktor83 (the dev of SRBminer) noticed (after a lot of whinging by some noobs) that by submitting stale share the reported hashrates on some yiimp-based pools actually increased noticeably so he added the feature that could be used in the command line (-sendallstales).

Yep, there was a similar discussion on Claymore's thread, except most people seemed to notice (me included) that hashrate might go up from submitting stale shares, but earnings did not. This makes the most sense to me because a pool operator would be taking a huge risk paying out on stale shares; anyone with a terrible ping and high difficulty could end up submitting nothing but stale shares, after all.

[dragonmike]

Doktor83 (the dev of SRBminer) noticed (after a lot of whinging by some noobs) that by submitting stale share the reported hashrates on some yiimp-based pools actually increased noticeably so he added the feature that could be used in the command line (-sendallstales).

Yep, there was a similar discussion on Claymore's thread, except most people seemed to notice (me included) that hashrate might go up from submitting stale shares, but earnings did not. This makes the most sense to me because a pool operator would be taking a huge risk paying out on stale shares; anyone with a terrible ping and high difficulty could end up submitting nothing but stale shares, after all.

I suppose it puts you on the safe side, as a miner.
If the pool shows a significantly lower effective hashrate coming from your rigs, there is probably an issue with the recognition of the shares. If sending stales makes the pool happy, then by all means...