How exactly are we losing profitability against LTC if it's profit-switching? Surely it would switch to LTC if it's more profitable instead of mining lower profitable coins I just don't see the logic there.

I need to make some changes in the core app to make it work with multiple regions/servers in a synchronized way (with shared profits and unified stats, not like separate pools). This requires more or less a day of my work.

I don't have this time because the pool is having performance problems which I'm working on almost 24/7. I already deployed a more powerful server which helped a bit but didn't solve the issue completely because it's a software issue. There's a performance problem in an underlying 3rd party software that I use and I need to either rewrite significant part of this software or change it to something else.

I'm working on these software issues at the moment. I'm developing some changes that are quickest to do and have potential to release the load - to try to make everything run smooth with the amount of hashpower that came to the pool. I hope to deploy some of these changes tonight.

Then I'm going to decide wether to significantly rewrite this 3rd party software or to use a different one (which in that case would also need to be significantly changed to suit our coin-switching needs). I will most likely choose a different one because the one that I'm using now is just crappy and all different technical problems that the pool has been experiencing since its launch were caused by it. This will probably take me 2-3 days.

After I deploy these quick fixes I wrote about two paragraphs above, I will decide what to do first: A) to do what's in the previous paragraph, rewrite the underlying software and solve the performance issues once for good (and then launch new regions); or B) launch the multi-region architecture first hoping that the load will be split between servers and it will buy me some time to do the A).

I plan to launch three new servers: Europe, Asia and US East and also move US West server from Oregon to California, so there will be four servers in total.

That said, fixing performance is my main objective now and I'm working on it almost 24/7.

what about vardiff? i read that it was enabled in the recent past and then the pool switched to a fixed diff=512. will we be able in the future to mine at vardiff with low end miners or to choose the diff by ourself?

Terk can you change the hash refresh time frame? an hour is way too long.

Also waiting for this. us server gave me around 8 % rejects. waaaaay to much

Ok, I'll bite.  In this scenario there are two ledgers.  One is the bitcoin block chain and the second is SR2 escrow service.

The interacton/use case goes like this:

1) Vendor A withdraws some money from SR2 escrow
2) the SR2 escrow sends a payment to the bitcoin P2P network
3) SR2 escrow records the payment's txid in it's database
4) waits for confirm (a miner to include it in the block)
5) before it's confirmed, Vendor A changes the txid (using malleability)
6) Vendor A broadcasts this transaction to the bitcoin network
7) Since, the inputs are the same, bitcoin network code sees this as a double spend
8 ) bitcoin marks the orignal transaction as dead (no miners will include it in a block)
9) SR2 escrow receives notification that the oridinal txid is dead
Note: this where all the websites are changing their code base, like SR2 should have when the bug exploit was discovered>
10)  SR2 escrow credits the vendors account for the "dead" funds, believing they are still in the escrow wallet (escrow ledger is now out of synch)
11)  the malleability transaction gets confirmed by miners
12) Vendor A now owns those bitcoins
13) Vendor A now goes into the SR2 escrow service and requests payment again
14) Vendor A is now at step 1 again and continues until the escrow wallet is no longer able to fulfill withdraw requests
14a) Process complete: SR2 sends out a sad message about their wallet being empty


so yes you can lose BTC with transaction malleability.

How do you defeat this?  

There are several ways:

• you send a request to the network for transactions on your wallet address and look to see if there are any between you and Vendor A on the network (check that the inputs aren't still in use)
• Flag the account for human intervention/review when fraud conditions are met
• Re-use the same inputs, so if there is another transaction (mutant) the network will not allow the double pay

or

• use multi-sig transactions with the SR2 service acting as the "Oracle" (What SR2 is talking about in the sad message)

man relax, its just that the stats are frozen.

''middlecoin.com published data: 1 hour ago''