Trying to move to eligius with Cointerra

[davedj79]

Hi there,

Hoping someone can help.  I've been mining happily on ghash.io, I'm trying a move to eligius.st.

I've double checked all settings in the cointerra setup.  After restarting the CT with the new pool details saved, the hashrate starts at 1.6TH/s and very quickly slows to 200ghs and then goes onto stop.

I cannot see an option to change difficulty on eligius, is that because I'm a new user?

The config on the CT I am using is stratum+tcp://stratum.mining.eligius.st:3334 then my BTC address, then 1 for Priority and Qouta.

Any help appreciated.

David

[davedj79]

So this is strange, I tried it on another account using my BTC Android address and voila it works perfectly.  So I created a new payment address from my home wallet in Bitcoin-QT on my mac and same problem, dropping hashrates.

Any ideas?

[HellDiverUK]

Eligius has automatic variable difficulty.  You can't set it manually.  Other than that, I've no clue, other than maybe DDoS?

[eleuthria]

Is CoinTerra one where it's either locked at 1024 difficulty, or requires difficulty to be specified in the hardware?  I know at least one newer ASIC would only run at 1024, which means you need to be able to specify your miner starts at that difficulty instead of using vardiff.

[-ck]

Is CoinTerra one where it's either locked at 1024 difficulty, or requires difficulty to be specified in the hardware?  I know at least one newer ASIC would only run at 1024, which means you need to be able to specify your miner starts at that difficulty instead of using vardiff.

No, the cointerra driver can use any arbitrary diff the pool tells it; even sub diff1 if you desired.

[kano]

Avoid Eligius - their stratum implementation makes you mine empty blocks, losing transaction fees and bad for bitcoin.

[wizkid057]

Avoid Eligius - their stratum implementation makes you mine empty blocks, losing transaction fees and bad for bitcoin.

I seriously am growing tired of kano's continuous trolling... here is legitimate debunking of kano's nonsense from the official Eligius thread:

This is the reasonable, well known, and expected behavior and not something to be concerned about.

Standard behavior for pool software is when a new block is accepted to immediately generate new work before the new transaction list is computed and then long poll again later to update. It can take bitcoind several hundred milliseconds to generate an actual block with content, especially if the mempool is large, and otherwise in that time you'd be twiddling your thumbs doing nothing or uselessly working on an old block. As a result, all miners will produce an empty block here and there, even when there is a backlog (E.g. for a 1 second dwell time it would be 0.16% of blocks).

In the last 1000 block there were 9 empty blocks, that rate suggests an aggregate dwell time of about 5 seconds. According to bc.i they were created by Discus Fish, Slush, Discus Fish, Discus Fish, Discus Fish, Eligius, KnC, Eligius, and Discus Fish.  Perhaps one pool's over-representation there suggests their long-polling behavior could use some tuning, but it isn't Eligius…

The obvious optimizations like precomputing the next block don't work, because someone else will usually have produced this one, and your 'next' will likely conflict with it... though it would be possible to do something like a 'fast tx list now!' that only guarantees validity, and perhaps makes idiotic choices wrt priority/fees.

Fortunately the timing of blocks are independent, e.g. that someone found a block 10 seconds after the last with nothing in it doesn't actually delay the finding of the next block with something in it.

It's sad I have to waste time on this.

[kano]

Avoid Eligius - their stratum implementation makes you mine empty blocks, losing transaction fees and bad for bitcoin.

I seriously am growing tired of kano's continuous trolling... here is legitimate debunking of kano's nonsense from the official Eligius thread:

Where he deleted all my posts proving I was right and banned me from posting the truth.
Yeah that's gonna make it true isn't it

Again: avoid Eligius.

This is the reasonable, well known, and expected behavior and not something to be concerned about.

Standard behavior for pool software is when a new block is accepted to immediately generate new work before the new transaction list is computed and then long poll again later to update. It can take bitcoind several hundred milliseconds to generate an actual block with content, especially if the mempool is large, and otherwise in that time you'd be twiddling your thumbs doing nothing or uselessly working on an old block. As a result, all miners will produce an empty block here and there, even when there is a backlog (E.g. for a 1 second dwell time it would be 0.16% of blocks).

In the last 1000 block there were 9 empty blocks, that rate suggests an aggregate dwell time of about 5 seconds. According to bc.i they were created by Discus Fish, Slush, Discus Fish, Discus Fish, Discus Fish, Eligius, KnC, Eligius, and Discus Fish.  Perhaps one pool's over-representation there suggests their long-polling behavior could use some tuning, but it isn't Eligius…

The obvious optimizations like precomputing the next block don't work, because someone else will usually have produced this one, and your 'next' will likely conflict with it... though it would be possible to do something like a 'fast tx list now!' that only guarantees validity, and perhaps makes idiotic choices wrt priority/fees.

Fortunately the timing of blocks are independent, e.g. that someone found a block 10 seconds after the last with nothing in it doesn't actually delay the finding of the next block with something in it.

It's sad I have to waste time on this.

It's sad your pool sends ALL stratum workers blocks with no transactions.
This work can be making empty bitcoin network blocks 14 seconds after the block change ...


Though I gotta love this one from above:

... though it would be possible to do something like a 'fast tx list now!' that only guarantees validity, and perhaps makes idiotic choices wrt priority/fees.

So, instead make ? choices to mine empty blocks?
I wonder what word could be used for "?"

[wizkid057]

When you start equally going after Discus Fish, Slush, KnC, EMC, and every other pool that has ever made an "empty" block, then I might believe you have some sincere, albeit misunderstood, concern for your fellow bitcoin users.

Until then it should be very obvious to everyone you're just trolling and spreading anti-Eligius FUD for no real reason.

Though I gotta love this one from above:

... though it would be possible to do something like a 'fast tx list now!' that only guarantees validity, and perhaps makes idiotic choices wrt priority/fees.

Mining spam-filled blocks (ie, the idiotic choices pointed out by gmaxwell) is much worse than mining a block with only a coinbase transaction.  The latter doesn't fill the blockchain with nonsense while also building on the existing chain further securing the network against double spends... you know, one of the main purposes of the blockchain?

Since a few more nails in this coffin can't hurt, I'll just nitpick a bit more at your ignorance.  You said before I should force stratum users to do a full restart immediately upon having a valid transaction list, but after they've already been given valid work for the current block...

Eligius actually immediately updates stratum work as soon as bitcoind returns a template.  Since Eligius actually generates some of the the largest blocks on the network, with thousands of txns at times, this actually can take a couple of seconds at times, but usually is pretty immediate. However, the mining hardware/software on the other end is free to continue working on the original work until it expires as per the stratum protocol.

i.e. you don't use it correctly.
In this case you should force them to start new work.

Doing a full work restart for new work which has the same previous block hash would obviously be ridiculous.  For those of you who don't understand why, let me explain...

Invalidating work that could still result in a current, valid block (you know, earnings for the miner?) is not in the miner's best interest, obviously.  I'm sure you won't find any miner out there that would give up earnings based on your trolling.

You, kano, work on a piece of software used for mining... why do you of all people not realize that there is a more than insignificant amount of time lost during a full work restart? Time and earnings lost for the *miner*.  Some hardware can take several seconds to do a full work restart.  Some worse than that even.  Full work restarts are to be used as little as possible, because every single one is lost time and earnings for the miner, and that time does add up even under normal conditions on all pools.  The *only* time they are actually necessary is when a new network block is found.  The pool quickly getting new, valid work out is helpful to the miners, as pointed out above, and expected to ensure that there is _minimal_ lost time during network block changes.  It would be ludicrous to tell them moments later to double up on that wasted time instead of just allowing the mining software to transition into the new, also valid, work as the hardware finishes previous, equally valid, work.

You're suggesting that miners sacrifice earnings for something that you consider to be 'bad' with no real reasons to back that thinking that can hold up to even trivial scrutiny.  Either that or you're suggesting they mine blocks potentially filled with nonsense.  The current implementation that pools use makes sense, is not capable of harming bitcoin in any way, and results in the least possible amount of work time lost for the miner.

Personally, I waste time battling your incessant trolling against Eligius because I feel that for whatever reason you have something against me and Eligius, when I've done nothing to warrant that kind of resentment.

[-ck]

Mining spam-filled blocks (ie, the idiotic choices pointed out by gmaxwell) is much worse than mining a block with only a coinbase transaction.

Interesting. I know eligius has always chosen its own transactions to include when mining but I didn't realise you thought the default choices of the bitcoind client were so bad as to call them spam.

[wizkid057]

Mining spam-filled blocks (ie, the idiotic choices pointed out by gmaxwell) is much worse than mining a block with only a coinbase transaction.

Interesting. I know eligius has always chosen its own transactions to include when mining but I didn't realise you thought the default choices of the bitcoind client were so bad as to call them spam.

Come on, ckolivas, please don't join in on kano's nonsense...

This has nothing to do with the default choices of bitcoind.  I was referring to what gmaxwell was referring to, which is something that doesn't actually exist: a way to get a list of transactions to mine immediately, before bitcoind has processed the new block but after the pool knows of the new block.

it would be possible to do something like a 'fast tx list now!' that only guarantees validity, and perhaps makes idiotic choices wrt priority/fees.

[kano]

When you start equally going after Discus Fish, Slush, KnC, EMC, and every other pool that has ever made an "empty" block, then I might believe you have some sincere, albeit misunderstood, concern for your fellow bitcoin users.

Ah, I see now, you've verified that some other pools do some crappy bad shortcut that's bad for bitcoin, so when Eligius chooses to do it also, it's OK.
Wow, makes Eligius sounds like trash.
Though, I wonder which of those use the same pool software as Eligius that sends out the empty blocks?

Eligius actually immediately updates stratum work as soon as bitcoind returns a template.  Since Eligius actually generates some of the the largest blocks on the network, with thousands of txns at times, this actually can take a couple of seconds at times, but usually is pretty immediate. However, the mining hardware/software on the other end is free to continue working on the original work until it expires as per the stratum protocol.

i.e. you don't use it correctly.
In this case you should force them to start new work.

Doing a full work restart for new work which has the same previous block hash would obviously be ridiculous.  For those of you who don't understand why, let me explain...

Invalidating work that could still result in a current, valid block (you know, earnings for the miner?) is not in the miner's best interest, obviously.  I'm sure you won't find any miner out there that would give up earnings based on your trolling.

You, kano, work on a piece of software used for mining... why do you of all people not realize that there is a more than insignificant amount of time lost during a full work restart?
...

Coz there is ONLY an insignificant amount of time lost during a full work restart on most hardware.
Most hardware supports a work restart at any time.
Some limited amount of hardware does NOT support a work restart at any time - and that SAME hardware has the same problem every single block change since that of course requires a ...... full work restart ........................

It is amusing to take a step back and see what you are doing here - giving excuses why you think it is OK for Eligius to mine empty blocks

Edit: oh I didn't point out something that is obviously false in there ...

Invalidating work that could still result in a current, valid block

cgminer, by default, always sends out the work found when a work restart happens.
If the pool rejects it even though it is a valid block ... then yeah don't mine on that pool ...

This was also a well know issue with p2pool long ago that was fixed on p2pool long ago.

[-ck]

Mining spam-filled blocks (ie, the idiotic choices pointed out by gmaxwell) is much worse than mining a block with only a coinbase transaction.

Interesting. I know eligius has always chosen its own transactions to include when mining but I didn't realise you thought the default choices of the bitcoind client were so bad as to call them spam.

Come on, ckolivas, please don't join in on kano's nonsense...

This has nothing to do with the default choices of bitcoind.  I was referring to what gmaxwell was referring to, which is something that doesn't actually exist: a way to get a list of transactions to mine immediately, before bitcoind has processed the new block but after the pool knows of the new block.

I wasn't, I honestly thought that's what you were referring to because I had no idea bitcoind was too slow to generate a new set of transactions after you've submitted a block to it that would delay you sending out new work based on it.

[wizkid057]

Mining spam-filled blocks (ie, the idiotic choices pointed out by gmaxwell) is much worse than mining a block with only a coinbase transaction.

Interesting. I know eligius has always chosen its own transactions to include when mining but I didn't realise you thought the default choices of the bitcoind client were so bad as to call them spam.

Come on, ckolivas, please don't join in on kano's nonsense...

This has nothing to do with the default choices of bitcoind.  I was referring to what gmaxwell was referring to, which is something that doesn't actually exist: a way to get a list of transactions to mine immediately, before bitcoind has processed the new block but after the pool knows of the new block.

I wasn't, I honestly thought that's what you were referring to because I had no idea bitcoind was too slow to generate a new set of transactions after you've submitted a block to it that would delay you sending out new work based on it.

It can be several real-time seconds between seeing the new block on the network and bitcoind responding to a getblocktemplate request with the updated transaction list built upon the new block.  So, a pool immediately knows the new block exists and it creates work quickly containing just the coinbase transaction but it is work that builds upon the newly seen block which keeps the miners busy working on valid work, well before bitcoind has had time to sort everything out regarding the newly seen block.

As soon as bitcoind returns an updated txn list, a stratum work update is pushed with that data to all miners.  An update, not a restart, since a restart would cause the miners to abandon valid work.

[-ck]

It can be several real-time seconds between seeing the new block on the network and bitcoind responding to a getblocktemplate request with the updated transaction list built upon the new block. 

The principle behind the optimisation I understood, but the timeframe sounds like there's something fundamentally wrong. It should only take milliseconds for bitcoind to be able to generate a new template. I've never looked at the code so now I'm just speculating, but I can't imagine why it would take that long. It's not that complicated a workload for a modern CPU. Does it need some kind of confirmation from other nodes?

[kano]

...
An update, not a restart, since a restart would cause the miners to abandon valid work.

"abandon valid work" ... which is done all the time ... look at "Discarded" - that's valid work that has been "abandoned"
But it doesn't matter.

Yes a restart would cause the miners to abandon valid work, and replace it with better valid work that on average generates more BTC for the pool.
... and see my edit in my previous post ...

Another interesting thing in this is that there are 2 issues that wizkid is trying to obfuscate.

1) The pool always sending empty blocks to every user every single block change

2) The pool not forcing the miner to restart work on the new better work provided to replace the empty blocks

[wizkid057]

...
An update, not a restart, since a restart would cause the miners to abandon valid work.

"abandon valid work" ... which is done all the time ... look at "Discarded" - that's valid work that has been "abandoned"
But it doesn't matter.

Yes a restart would cause the miners to abandon valid work, and replace it with better valid work that on average generates more BTC for the pool.
... and see my edit in my previous post ...

Another interesting thing in this is that there are 2 issues that wizkid is trying to obfuscate.

1) The pool always sending empty blocks to every user every single block change

2) The pool not forcing the miner to restart work on the new better work provided to replace the empty blocks

You're showing your ignorance here yet again.

Not obfuscating anything at all, it's you who is trying to play down the actual effects of a full work restart.

The pool sends valid work to every miner immediately upon seeing a new block containing a single output coinbase transaction.

Immediately upon having a valid transaction list it sends this work to the miners also but does NOT require a full restart, since this would cause the miners to waste time abandoning work that is valid.  There is an actual amount of time taken to abandon the work and load new work into the hardware, regardless of whether or not the pool would reject the old work or not.  Per the stratum protocol, a full restart invalidates the old work, so the pool should reject old submissions at this point.

The currently discarded work is fine, because it is for blocks that are no longer valid.  Abandoning work for a block that is valid (the coinbase transaction block) would be stupid and waste the miners' time.

[kano]

...
An update, not a restart, since a restart would cause the miners to abandon valid work.

"abandon valid work" ... which is done all the time ... look at "Discarded" - that's valid work that has been "abandoned"
But it doesn't matter.

Yes a restart would cause the miners to abandon valid work, and replace it with better valid work that on average generates more BTC for the pool.
... and see my edit in my previous post ...

Another interesting thing in this is that there are 2 issues that wizkid is trying to obfuscate.

1) The pool always sending empty blocks to every user every single block change

2) The pool not forcing the miner to restart work on the new better work provided to replace the empty blocks

You're showing your ignorance here yet again.

Not obfuscating anything at all, it's you who is trying to play down the actual effects of a full work restart.

The pool sends valid work to every miner immediately upon seeing a new block containing a single output coinbase transaction.

Immediately upon having a valid transaction list it sends this work to the miners also but does NOT require a full restart, since this would cause the miners to waste time abandoning work that is valid.  There is an actual amount of time taken to abandon the work and load new work into the hardware, regardless of whether or not the pool would reject the old work or not.  Per the stratum protocol, a full restart invalidates the old work, so the pool should reject old submissions at this point.

The currently discarded work is fine, because it is for blocks that are no longer valid.  Abandoning work for a block that is valid (the coinbase transaction block) would be stupid and waste the miners' time.

Heh, see you have even confused yourself there.
You are referring to shares, or "Proof of Work" (PoW), not "Work".

cgminer always sends the "Proof of Work" (PoW) to the pool even if it might be stale, unless you explicitly tell it to NOT send it.

If you are unable to deal with this at the pool and then throw valid blocks away, then that is indeed an issue of you simply not being able to program that.
As I mentioned above, this is an issue that existed in p2pool LONG ago and was resolved LONG ago since p2pool sends a full restart on average every 30s even though PoW blocks produced but not sent before the restart are still valid network blocks, on average 95% of the time when difficulty isn't changing.
Go read the p2pool code and learn how to do that.

[wizkid057]

...
An update, not a restart, since a restart would cause the miners to abandon valid work.

"abandon valid work" ... which is done all the time ... look at "Discarded" - that's valid work that has been "abandoned"
But it doesn't matter.

Yes a restart would cause the miners to abandon valid work, and replace it with better valid work that on average generates more BTC for the pool.
... and see my edit in my previous post ...

Another interesting thing in this is that there are 2 issues that wizkid is trying to obfuscate.

1) The pool always sending empty blocks to every user every single block change

2) The pool not forcing the miner to restart work on the new better work provided to replace the empty blocks

You're showing your ignorance here yet again.

Not obfuscating anything at all, it's you who is trying to play down the actual effects of a full work restart.

The pool sends valid work to every miner immediately upon seeing a new block containing a single output coinbase transaction.

Immediately upon having a valid transaction list it sends this work to the miners also but does NOT require a full restart, since this would cause the miners to waste time abandoning work that is valid.  There is an actual amount of time taken to abandon the work and load new work into the hardware, regardless of whether or not the pool would reject the old work or not.  Per the stratum protocol, a full restart invalidates the old work, so the pool should reject old submissions at this point.

The currently discarded work is fine, because it is for blocks that are no longer valid.  Abandoning work for a block that is valid (the coinbase transaction block) would be stupid and waste the miners' time.

Heh, see you have even confused yourself there.
You are referring to shares, or "Proof of Work" (PoW), not "Work".

cgminer always sends the "Proof of Work" (PoW) to the pool even if it might be stale, unless you explicitly tell it to NOT send it.

If you are unable to deal with this at the pool and then throw valid blocks away, then that is indeed an issue of you simply not being able to program that.
As I mentioned above, this is an issue that existed in p2pool LONG ago and was resolved LONG ago since p2pool sends a full restart on average every 30s even though PoW blocks produced but not sent before the restart are still valid network blocks, on average 95% of the time when difficulty isn't changing.
Go read the p2pool code and learn how to do that.

So basically you're saying to keep doing what I'm already doing, except send a force restart to update the work, but still accept the coinbase-only network blocks when they're found, even if they're submitted after the work restart?  As in, exactly what I'm doing already without the forced full restart?  Which will have virtually the same result as it does currently and still put out coinbase-only blocks?

Now I am confused.  Wouldn't that basically just translate to you saying, "yes, I've been making a big deal out of this for no reason." ?

[wizkid057]

Let me just get the next few rounds of trolling out of the way...

*puts on best kano impersonation*

<kano_impression> The work restart will make the empty blocks that your pool abuses the network with less likely to happen

*takes off kano hat* Not bad, eh?

But you still forget about the time the miner loses abandoning the old work, regardless of if it submits the already found results or not, it still takes an actual amount of time for the software and hardware to perform the full restart, which is lost time for the miner.  This is one of the reasons different types of hardware have widely varying results on fast-restart type situations like p2pool since a huge percentage of their time could be spent doing nothing useful do to the restarts.

If the restarts were seamless then there should never be a dip in shares submitted when a new network block is found and all miners should just smooth into it like nothing happened.  However, in reality, share submissions drop substantially at a full restart for some substantial amount of real time when it happens.

Heres some proof: Eligius block 301,134.  Found in 12 seconds after the previous block using the "empty" template work.  The pool wide hash rate average for the previous block: 5.8Ph/sec.  The pool-wide hash-rate for the 12 seconds between blocks: 4.1Ph.  That means about 30% of the miners had not even caught up to the full work restart yet after 12 full seconds.  And you're suggesting doing multiple full restarts for the same block?  No real pool does this.

This happens for every fast block.  A large percentage of miners haven't even caught up to the restart yet.  Just look at http://eligius.st/~wizkid057/newstats/blocks.php and look at the >9,000% luck blocks and the ones around them.  Its a recurring theme: miners do not quickly update work and lose real mining time for every restart.