[CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers

[Tigggger]

So we are finally going to have closed shifts with no blocks found...

Cry

[1714198327]

1714198327

[1714198327]

1714198327

[1714198327]

1714198327

[guytechie]

Has NMC moved one bit, too?

Edit:  we found one finally!  No 0 block yet closed yet, but it was damn close!

[Sir Alan]

(Sigh) Over 12½ hours.  I was just about to start sticking pins in a wax effigy of Ghash.io.

[Tigggger]

Has NMC moved one bit, too?

Edit:  we found one finally!  No 0 block yet closed yet, but it was damn close!

It's on the stats page, and on the blockchain but not on the PPLNS stats, so we have a closed 0 shift after that block was found ??



EDIT: It just updated to show 1 block.

[guytechie]

Has NMC moved one bit, too?

Edit:  we found one finally!  No 0 block yet closed yet, but it was damn close!

It's on the stats page, and on the blockchain but not on the PPLNS stats, so we have a closed 0 shift after that block was found ??



EDIT: It just updated to show 1 block.

That's because the block was found when that shift was open.  It's not when the block is confirmed.

[kendog77]

Can we please go back to average luck? 80-90% luck seems like the new normal. 

I really don't want to switch over to the dark side (GHash.IO).

[DaveF]

Dev and IXC only add about 0.1% more to your profits and it's another coin you have to send to an exchange and then dump for Bitcoin (assuming you only want BTC).  I think the uptime and security affording by this pool and others like Bitminter and Elegius exceed the paltry add on of those coins.

Not counting uptime/security (unlikely to be affected), the real issue is extra load on the servers.  As you pointed out, DVC+IXC are virtually worthless.  I'm not even sure if they're 0.1% actually.  Adding extra coins to each pool server means each server will be wasting time accessing the SSDs/RAM for those coins, a few CPU cycles, and some bandwidth every time they get a block.  That will at least minimally impact bitcoind performance.  How much?  I can't say, and nobody else really can either.  But it is a non-0 impact, and for how worthless they are, I'm not willing to risk ANY performance for junk coins on BTC Guild.

I'm asking this because I don't know / understand not to be a pain:

Could they were on a physically separate server? With some of the databases I deal with 90%+ of the work is done on the main box 10% is done on other ones. The 10% does not "matter" it's what we term "live irrelevant data". It's for the programmers to use live data / connections to test work, if it all goes boom or lags behind no big deal the main database servers don't even know about it. The front end application servers here (I'm assuming the stratum servers for you) know about it and talk to it at the lowest priority, but if the test back end fails no big deal.

I don't know enough about the stratum protocol to know if that's even possible.

And no, I don't think it's worth the time to mine the other coins, but I do want to understand more.

-Dave

[guytechie]

Can we please go back to average luck? 80-90% luck seems like the new normal.  

I really don't want to switch over to the dark side (GHash.IO).

If this keeps up, it's no wonder why our pool hash is dropping.  Probably for ghash...

It's going to take a buttload of good luck to dig us out of this 80-90% new norm.

[sconklin321]

Dev and IXC only add about 0.1% more to your profits and it's another coin you have to send to an exchange and then dump for Bitcoin (assuming you only want BTC).  I think the uptime and security affording by this pool and others like Bitminter and Elegius exceed the paltry add on of those coins.

Not counting uptime/security (unlikely to be affected), the real issue is extra load on the servers.  As you pointed out, DVC+IXC are virtually worthless.  I'm not even sure if they're 0.1% actually.  Adding extra coins to each pool server means each server will be wasting time accessing the SSDs/RAM for those coins, a few CPU cycles, and some bandwidth every time they get a block.  That will at least minimally impact bitcoind performance.  How much?  I can't say, and nobody else really can either.  But it is a non-0 impact, and for how worthless they are, I'm not willing to risk ANY performance for junk coins on BTC Guild.

I'm asking this because I don't know / understand not to be a pain:

Could they were on a physically separate server? With some of the databases I deal with 90%+ of the work is done on the main box 10% is done on other ones. The 10% does not "matter" it's what we term "live irrelevant data". It's for the programmers to use live data / connections to test work, if it all goes boom or lags behind no big deal the main database servers don't even know about it. The front end application servers here (I'm assuming the stratum servers for you) know about it and talk to it at the lowest priority, but if the test back end fails no big deal.

I don't know enough about the stratum protocol to know if that's even possible.

And no, I don't think it's worth the time to mine the other coins, but I do want to understand more.

-Dave

I'm not 100% sure here, but I think a lot of this comes down to just mitigating the sheer latency.  To start with, it is my understanding that the second a new block is found, all the work that is currently being worked on for the old expires.  So you lose clock cycles/bandwidth there, trying to send out new work to all the workers currently connected so that they are all working on the current block.  Definitely don't want to be wasting clock cycles checking/updating work to worthless coins then.  Also, when you find a block, you need to get this from the accepted share that found it, to the blockchain and broadcast it as fast as the server/network will allow this.  Sometimes, a matter of a few fractions of a second could be the difference between a block being accepted or orphaned.  Better to keep the resources available for the coins that are worth it than waste it on coins that are more or less worthless.

[incin]

Like today when BTCGuild lost block 308770 to slush. 

[Majixagi]

Dev and IXC only add about 0.1% more to your profits and it's another coin you have to send to an exchange and then dump for Bitcoin (assuming you only want BTC).  I think the uptime and security affording by this pool and others like Bitminter and Elegius exceed the paltry add on of those coins.

Not counting uptime/security (unlikely to be affected), the real issue is extra load on the servers.  As you pointed out, DVC+IXC are virtually worthless.  I'm not even sure if they're 0.1% actually.  Adding extra coins to each pool server means each server will be wasting time accessing the SSDs/RAM for those coins, a few CPU cycles, and some bandwidth every time they get a block.  That will at least minimally impact bitcoind performance.  How much?  I can't say, and nobody else really can either.  But it is a non-0 impact, and for how worthless they are, I'm not willing to risk ANY performance for junk coins on BTC Guild.

I'm asking this because I don't know / understand not to be a pain:

Could they were on a physically separate server? With some of the databases I deal with 90%+ of the work is done on the main box 10% is done on other ones. The 10% does not "matter" it's what we term "live irrelevant data". It's for the programmers to use live data / connections to test work, if it all goes boom or lags behind no big deal the main database servers don't even know about it. The front end application servers here (I'm assuming the stratum servers for you) know about it and talk to it at the lowest priority, but if the test back end fails no big deal.

I don't know enough about the stratum protocol to know if that's even possible.

And no, I don't think it's worth the time to mine the other coins, but I do want to understand more.

-Dave

I'm not 100% sure here, but I think a lot of this comes down to just mitigating the sheer latency.  To start with, it is my understanding that the second a new block is found, all the work that is currently being worked on for the old expires.  So you lose clock cycles/bandwidth there, trying to send out new work to all the workers currently connected so that they are all working on the current block.  Definitely don't want to be wasting clock cycles checking/updating work to worthless coins then.  Also, when you find a block, you need to get this from the accepted share that found it, to the blockchain and broadcast it as fast as the server/network will allow this.  Sometimes, a matter of a few fractions of a second could be the difference between a block being accepted or orphaned.  Better to keep the resources available for the coins that are worth it than waste it on coins that are more or less worthless.

Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins. BTCGuild should be able to figure it out. I'd just like to see more feature parity with the biggest pool because I don't think the current system is going to get better on its own. If I were making some amount of my income based on how much market share my pool had, I would be looking for any way possible to keep that income reasonably high without exceeding a certain threshold that would endanger the network.

Pick ajax stats, split payouts, merged mining, something anything to close the gap. Just my 2 bits.

Yes, I am currently mining here because it is the most stable pool there is. I'm also mining here because I want this pool to survive. As the mining corporations gather more network share, more private miners will tend to consolidate to fewer higher hash rate pools to reduce their variance. p2pool and Eligius can survive because they don't rely on a fee to run. I'm just worried about BTCGuild eventually becoming an abandoned pool like a few others have. Maybe I'm thinking too far ahead or being alarmist, but I thought I would try to share my concerns while there is still a chance to do something about it. It really has much less to do with the income those coins would provide than it does with the perception of value the pool provides.

[psahx]

Approximate Pool Luck
     24H    /     3D     /     1W     /     2W     /     1M     /     3M     / All Time
55.512% / 74.217% / 80.471% / 92.197% / 91.989% / 90.556% / 97.749%

                                                                              



All we need now is just some GOOD LUCK...

[eleuthria]

Approximate Pool Luck
     24H    /     3D     /     1W     /     2W     /     1M     /     3M     / All Time
55.512% / 74.217% / 80.471% / 92.197% / 91.989% / 90.556% / 97.749%

                                                                              



All we need now is just some GOOD LUCK...

With only about 12 blocks/day expected, it doesn't take much to swing those numbers anymore.  Yesterday's 13 hour block pretty much guaranteed the weekly average is going to stay low until that round rolls out of the average, yet it wasn't a record in terms of shares vs diff.  It wasn't even 7x.  Yet that single day had a multiple-percent impact on the 1-month average because of how small the sample size is becoming.  During our last run of luck (Jun 18 - Jun 21) the 24H - 2W numbers were all over 100% again.

You're going to see more extremes now, that's what happens when you're a smaller share of the overall network.  The bad days will be extremely low, the good days will be much higher.  Each block is ~13% of expectation, so getting 4 blocks more than expected is now huge (160%), whereas in the past it was only a minor bump (115-125%).  In the same vein, 4 blocks less than expectation is now a 40% instead of 80%.

[sconklin321]

Dev and IXC only add about 0.1% more to your profits and it's another coin you have to send to an exchange and then dump for Bitcoin (assuming you only want BTC).  I think the uptime and security affording by this pool and others like Bitminter and Elegius exceed the paltry add on of those coins.

Not counting uptime/security (unlikely to be affected), the real issue is extra load on the servers.  As you pointed out, DVC+IXC are virtually worthless.  I'm not even sure if they're 0.1% actually.  Adding extra coins to each pool server means each server will be wasting time accessing the SSDs/RAM for those coins, a few CPU cycles, and some bandwidth every time they get a block.  That will at least minimally impact bitcoind performance.  How much?  I can't say, and nobody else really can either.  But it is a non-0 impact, and for how worthless they are, I'm not willing to risk ANY performance for junk coins on BTC Guild.

I'm asking this because I don't know / understand not to be a pain:

Could they were on a physically separate server? With some of the databases I deal with 90%+ of the work is done on the main box 10% is done on other ones. The 10% does not "matter" it's what we term "live irrelevant data". It's for the programmers to use live data / connections to test work, if it all goes boom or lags behind no big deal the main database servers don't even know about it. The front end application servers here (I'm assuming the stratum servers for you) know about it and talk to it at the lowest priority, but if the test back end fails no big deal.

I don't know enough about the stratum protocol to know if that's even possible.

And no, I don't think it's worth the time to mine the other coins, but I do want to understand more.

-Dave

I'm not 100% sure here, but I think a lot of this comes down to just mitigating the sheer latency.  To start with, it is my understanding that the second a new block is found, all the work that is currently being worked on for the old expires.  So you lose clock cycles/bandwidth there, trying to send out new work to all the workers currently connected so that they are all working on the current block.  Definitely don't want to be wasting clock cycles checking/updating work to worthless coins then.  Also, when you find a block, you need to get this from the accepted share that found it, to the blockchain and broadcast it as fast as the server/network will allow this.  Sometimes, a matter of a few fractions of a second could be the difference between a block being accepted or orphaned.  Better to keep the resources available for the coins that are worth it than waste it on coins that are more or less worthless.

Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins. BTCGuild should be able to figure it out. I'd just like to see more feature parity with the biggest pool because I don't think the current system is going to get better on its own. If I were making some amount of my income based on how much market share my pool had, I would be looking for any way possible to keep that income reasonably high without exceeding a certain threshold that would endanger the network.

Pick ajax stats, split payouts, merged mining, something anything to close the gap. Just my 2 bits.

Yes, I am currently mining here because it is the most stable pool there is. I'm also mining here because I want this pool to survive. As the mining corporations gather more network share, more private miners will tend to consolidate to fewer higher hash rate pools to reduce their variance. p2pool and Eligius can survive because they don't rely on a fee to run. I'm just worried about BTCGuild eventually becoming an abandoned pool like a few others have. Maybe I'm thinking too far ahead or being alarmist, but I thought I would try to share my concerns while there is still a chance to do something about it. It really has much less to do with the income those coins would provide than it does with the perception of value the pool provides.

I hear what you're saying, unfortunately we don't find the hashrate they do either.  When you have over 1/3 of the hashrate you can minimize your latency risk because you have a 1 in 3 chance of finding the next block and preventing it from being orphaned.  While we're at just shy of 10% of the network hashrate.  So, we have a 1 in 10 chance of finding the next block, so we need every advantage we can get.  Risking latency for some worthless coins isn't worth the risk of a block being orphaned because we're not likely to find the next block. I do get what you're saying though.

[psahx]

You're going to see more extremes now, that's what happens when you're a smaller share of the overall network.  The bad days will be extremely low, the good days will be much higher.  Each block is ~13% of expectation, so getting 4 blocks more than expected is now huge (160%), whereas in the past it was only a minor bump (115-125%).  In the same vein, 4 blocks less than expectation is now a 40% instead of 80%.

Thanks

Then, let's hope for good days to came sooner.

Cheers!

[eleuthria]

Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins.

They didn't "figure it out".  There is the very real chance that one or more of their Bitcoin orphans were the result of worthless crapcoin daemons adding extra latency to their pool knowing of a new block or pushing out a new block.

Like today when BTCGuild lost block 308770 to slush. 

That was just adding insult to injury after last night's block .  But our luck with orphans has been fairly good, that was our first orphan in the last 300 blocks.

[-ck]

This:

Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins.

and this:

Yes, I am currently mining here because it is the most stable pool there is.

are contradicting themselves, no?

[Majixagi]

This:

Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins.

and this:

Yes, I am currently mining here because it is the most stable pool there is.

are contradicting themselves, no?

There is no contradiction whatsoever in those statements. If anything it is a validation of what eleuthria said about stability here. I have always attributed the stability of BTCGuild to eleuthria's skills as an operator and suspect that if he were running ghash.io it would be more stable. I still think that is the case, but I also believe him when he says that keeping merged mining simple is a significant reason for that stability here.

The marketing message to newer or less informed miners is that ghash.io has more value because of its lower variance and merged mining. It doesn't matter if that reason should not be significant, it only matters that the marketing works. People believe it and mine there.

Just sad to see the industrialization of mining. I am nostalgic for the time when it took effort and thought instead of just capital to get involved.

[Minor Miner]

Can anyone tell me if I am completely missing something here?
If I go to bitcoinwisdom.com and look at difficulty, it predicts the next adjustment as being +13% even though the average block time is 10 minutes.   I realize their predictions are not accurate for the first days of a change, but is the average is 10 minutes shouldn't they be predicting 0%?

[os2sam]

Can anyone tell me if I am completely missing something here?
If I go to bitcoinwisdom.com and look at difficulty, it predicts the next adjustment as being +13% even though the average block time is 10 minutes.   I realize their predictions are not accurate for the first days of a change, but is the average is 10 minutes shouldn't they be predicting 0%?

We're only a quarter of the way into this difficulty.  So there is allot of room to go either way.  But yes, if 6 blocks per hour is maintained all the way through then difficulty would stay the same, pretty much.  But I doubt that will happen and they probably doubt it too.