Hello all,

It seems Griffith and ocminer have made it their duty to ensure to point out any possible flaw with the system.
big thank you to them for saving us a ton of work and headache in the future.

In addition to the tx size limit issue that we will be addressing today we will also address the tx fee to ensure that no one "loses coins".

Although we may be less active in the forum today it is because we are correcting the pointed out issues in this alpha launch.

The updates will not affect your coin balance. We will announce the update and what the changes entail later this evening.

Again Thank you all for being a part of this project!

so i am ready to pick esp on yobit nice to hear this ESP on yobit  

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.

Right, you get  another 2 days to arrange some BTCBTCBTC then 

Right, you get  another 2 days to arrange some BTCBTCBTC then 

sorry to rain on your parade but we don't give a fuck about Litecoin.....we want satoshi only, not fucking Litoshi.....SATOSHI!!!!

In a sense PoR will be a very different PoS.
However unlike PoS it will not be totally biased for large bag holders.
Also it will not have the eventual CPU usage pitfall of most current PoS systems while distributing the remaining amount of tokens to be generated at arelativity even rate with a bonus account to holders as a perk.
If you're interested in knowing exactly how the system well work just head over to our website and take look at the "Proof of" tab and select "Reliability"

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...