Actually you won't be losing the coins completely, as they're never send across the network, but you'd need to dump the privkey of your receiving address (or all receiving addresses), clear your wallet + blockchain data (backup first) and in a fresh, fully synchronized client you'd import the privkey(s) again and your funds should be back.

However, setting txfee to 0.01 and/or fixing the bug is surely the best way to solve it Just wanted to make sure that nobody will lose any coins, they're still there.

Thanks for the explanation Griffith, your input is greatly appreciated, I'm a bit disappointed that the dev team didn't acknowledge MY input at all, but it seems that's just the way they are..

Maybe if you help them, they'll get it fixed someday.

Intro
as much as i enjoyed reading that back and forth between you and the pool because i find every code fight on bitcointalk amusing as no one bothers to just go check the code itself, i feel like i should just clear the air.
it seems you dont quiteeee understand how transaction sizes work (your static sizes is a good example of a main concept that seems to be missing) so let me explain why it is a client problem and not a pool problem.

A little background
your MAX_BLOCK_SIZE is 15000000. or 15 MB and thats all fine and dandy. this is stated here: https://github.com/CryptoCoderz/Espers/blob/15c240ea22e693d06fc3ffb2cd587bd3f8b1e978/src/main.h#L30
a few lines below it, you set a MAX_STANDARD_TX_SIZE of MAX_BLOCK_SIZE_GEN/5 or 3MB. this is stated here: https://github.com/CryptoCoderz/Espers/blob/15c240ea22e693d06fc3ffb2cd587bd3f8b1e978/src/main.h#L36

now, someone pointed out earlier in the thread that transaction sizes are NOT static but are instead dynamic based on the number of inputs. this is true and has been the way it has been done since bitcoin does it this way.

so the pool is trying to send a transaction right? cool. thats fine. OCMiner said he entered the command ./Espersd sendtoaddress <address> 10000000 from his daemon that is running the pool. and is getting the error Transaction too large.

The code to send a transaction
if you look at the code for this... found here: https://github.com/CryptoCoderz/Espers/blob/62853947a2a87d923c5cbecf467d2abe29a38e8d/src/wallet.cpp#L1304

you will see that you limit the size a transaction can be. as you so nicely put a comment above it saying     // Espers: Added safety margin 4000 bytes and 160 transactions

transactions are limited to the following (this code is found under the previous link to wallet.cpp line 1304)  

THIS is the size of the transaction >>>>  unsigned int nBytes = ::GetSerializeSize(*(CTransaction*)&wtxNew, SER_NETWORK, PROTOCOL_VERSION);


                if ((nBytes + 4000 >= MAX_STANDARD_TX_SIZE) ||
                    (wtxNew.vin.size() >= 160))
                {
                    strFailReason = _("Transaction too large");
                    return false;
                }


now that code snippit above says that if the size of the transaction + 4000 bytes is greater than the limit you set in main.h (3MB or 3000000 bytes) OR the number of inputs to make the TX is more than 160 inputs. the transaction is rejected for being too large.

The rejection conditions
lets start with the first check, since you add 4000 to the transaction size, your max TX size is actually 3,000,000 - 4,000 = 2,996,000. it is highly unlikely that from mining 50k coin blocks you have passed this 2.9MB limit. but in the future if your inputs are smaller you could approach this number when trying to send larger amounts of coins. this is however not terribly likely. so lets look at the second conditional...

now we will go over the second scenario (HINT HINT THIS IS THE PROBLEM). if a block is 50,000 esp then to make a transaction send 10 million you need to have inputs from a MINIMUM of 200 blocks(where each block is an input) (50,000 * 200 = 10,000,000) making the transaction impossible and unable to send due to input limiting. (im assuming that no input is greater than 50,000 coins because it is a mining pool and that is the number coins per block)
MORE THAN LIKELY it will be the case that more than 200 inputs are needed if none of the inputs were from blocks were a large number of coins were received like the premine or even from regular mining. this is why his transaction is failing. too many inputs causing the transaction to be too large.

Im confused, how did 300 million get sent earlier???
well then how did you send 300 million to each person? well thats simple. the premine was probably mined in only a few blocks. that means when you sent from whatever the initial premine was. it only had a few inputs, making it possible to send the coins.


WOW what does this all mean?
based on this reasoning, the longer the coin is around and the more it is traded, the more inputs will be required in order to send a large amount of coins. this means that over time the amount of coins per transaction could be limited to as low as a few million even though there are 50 billion total. In order to fix this you either need to restructure the conditionals for a transaction to send (which would require a hard fork as was stated by OCMiner, nice job recognizing the problem btw buddy) OR raise the price of the coin up A LOT so that transactions containing a large number of coins become unlikely. (my guess for this would be each coin needs to be worth about 1 cent or somewhere close but with 50 billion coins this does not seem likely)

Why should i listen to you, you thread trooolll
Actually, i do a lot of dev work myself. and i can safely say i am fairly well versed in how the blockchain works. I was the first one to make a coin that has two different types of addresses that behave independently of each other (see flycoin thread for info on that) and that means that they also had to handle transactions differently. I understand every aspect of transactions from how they are created to how they are encoded and decoded to figure out who they came from and who they were sent to (which the wallet does for you and thats why when a TX is sent to you it shows up in your wallet). i have also made a wallet that runs more than one coin at a time, so i have a pretty good idea of how blockchain tech works.

but most importantly, the code speaks for itself.

Conclusion
I am in no way saying the dev team is a bad team, they seem to be attempting to do some interesting things with the coin and blockchain, but theres going to be a lack of reliability in the brand new stuff if the roots of where it comes from are neglected. So i would recommend going back and reviewing some of the basics of crypto (general theory around transaction and block generation) so the original ideas behind the tech dont become lost in the race for that brand new exciting feature.

Did that already, but i'm still getting errors:

./Espersd sendtoaddress <address> 10000000
error: {"code":-4,"message":"Transaction too large"}

A pools wallet is always different than a exchange wallet, the pool has lots of utxo's...

Guys i'd really appreciate if you withdraw your coins from the pool, i'm having a bad time sending out all the giant transactions by hand.

I appreciate your trust, honestly, but the pool is no bank

thanks

oc

Yes, something similar

Thanks, it's up again.

goroutine 51 [running]:
panic(0xe881a0, 0xc82000e0e0)
        /opt/golang/1.6.1/src/runtime/panic.go:464 +0x3e6
math/big.(*Int).Cmp(0xc823652800, 0x0, 0xc8200a62b0)
        /opt/golang/1.6.1/src/math/big/int.go:314 +0x24

The daemon crashed and I cannot get it synched back to the network currently.. i'm on it..

Likely the virus/Trojan dev... At least there is a Chance

And I guess the acc was hacked

I'm still fighting against some DDoS'es which always happen when i'm offline.

Everything is back up again now, i've put the other pools in the header, you can just put them into your batch file and sg/ccminer switches automatically when the pool goes down and returns back when it's running again.

Works again

Copy pasted from this:

https://bitcointalk.org/index.php?topic=1446070.0

And also from Blackcoin / Returncoin, if you do a little google search.

never underestimate the potential of someone who is bored for a weekend and decides they will get around to launching that coin they meant to launch 18 months ago