Status quo in a nutshell:

* mining now happens on EC2 instances, DNS records for stratum.bitcoin.cz have been updated
* you might need to restart long running workers & make sure DNS changes propagated to you. Use netstat & nslookup, or just flush the dns cache and restart workers.
https://bitcointalk.org/index.php?topic=1976.msg1926436#msg1926436
* the website is not up at the moment, but mining is possible

Hope this helps,
   T

I just used netstat and reverse lookup to confirm where the existing stratum connections were going (they were still opened to ovh address 94.23.174.94 in my case).
Restarted workers where it was needed to make sure they connect to EC, 54.214.x.x.

Hope this helps.
   T

You are absolutely right. The point was merely there is no need to predict the next OTP. Especially with Trudy having physical access.

I'd guess he is using a vasco or rsa token with appropriate key size...

If I agreed with you, we both would be wrong. Never mind, no offence taken on my side whatsoever.

Can you please shed some light on this comment?

Stratum is back, great job!

Cheers,
   T

Ok, that is clear now. Thanks.

Cheers,
   T

Thanks for sharing this. For the reference of others readers, a description of Double Geometric Method can be found here: https://bitcointalk.org/index.php?topic=39497.0
I enjoyed reading it. Note points on periodic rescaling and logarithmic scale.

Cheers,
   T

Unfortunately I did not see this reset documented when Slush explained the scoring calculation (to which I did include the link). We observed that score resets are happening periodically, I assume the reason is to prevent an arithmetic overflow.

The cheapest way (in terms of both db performance and implementation effort) of performing a reset is zeroing out all the scores and simply carrying on the calculation without touching C or scaling back the round time (both of which would be the same). This would obviously not maintain the same characteristics, especially, if the round ends very close to the reset. What I have written is 'scaling down' rather then resetting existing scores, I hope the difference is clear - to maintain the proportions of the scores while also getting rid of digits.

Again, I am drawing conclusions based on observations since I could not find info about how resets are performed - the conclusions might therefore be right or wrong, and I try to be correct/careful about the wording as well. Does anyone know more details of how exactly the scores are currently reset?

Cheers,
   T

Well, they do make a difference, as it had been pointed out before. My initial thought was to perform the following instead of the reset:

1) Divide by a big number & round everyones score to maintain the proportions but get rid of a lot of digits.
2) Adjust the constant C (currently always 300) according to the big number used for the division - logarithmic. (so at the end, the algorithm maintains the same curve, scaled down)

I do not want to raise a flame war, and note that I was not complaining either - but am open to any discussion on the maths behind this.

Cheers,
   T

I am happy with the score based calculation as well, re-introducing PPS would not be a good idea. Supporting multiple payout plans would just add unnecessary complexity and demand a lot of effort.

Having said this, I do have some thoughts on the periodic resets:

• I could not find the periodic reset documented at https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002 which is the "official description" of how rewards are calculated AFAIK.
• Theoretically, the exponential nature of the scoring algorithm without the resets would do a great job against hopping.
• In practice, for long running rounds, the scores might get very large, causing an arithmetic overflow. Maybe this is the only reason for the resets, but I am just guessing. If so, a mathematically correct fade out instead of the reset might be a viable option.

I might be missing something, so just correct me in case...

Cheers,
   T

Thanks Slush for taking action on the weird block.

I confirm, corrected here as well.

Cheers,
   T

joolzg,

here are the details of how the score based rewarding works: https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002
This is to prevent pool hopping / protect "honest miners".

Additionally, the scores are reset periodically, as Kruncha said - this reset has bitten us right now based on his observations.

Cheers,
   T

I have read the details of the reward calculation. Even without a periodic reset, the exponential nature of the calculation would be effective against pool hopping, correct?
Do you know for a fact, that scores were reset just immediately before the end of the block?
My fastest miner is around 800MHash/s, I know there are beefier rigs out there but 3% is really out of normal, isn't it?

Cheers,
   T

Yes, that seems really strange to me as well. It might just be the side effect of the scoring algorithm, but this one block seems so much out of normal there might some other reason.
In my case, the reward from block is 3% of my earning from the previous block, although all 3 of my miners were constantly hashing.

Seems I am not the only one wondering...  Does anybody have any idea/theory?

Cheers,
   T

Strange enough, but you can also get restricted again... I guess someone might have deleted a topic I responded , causing my # of posts to drop from 6 to 4 yesterday.
Anyone else had similar experience? This should not happen IMHO.

Cheers,
   T

It only takes 5 posts and 4 hours to get to "the next level".

Before investing in hardware, let this site do the maths for you: https://bitclockers.com/calc
On the page, make sure you modify the Difficulty change from monthly 2% to something more realistic. Currently it is around 15% each other week.
For your reference: http://bitcoin.sipa.be/

Hope this helps,
   T