Please PM us, this is not a client issue, the block size is MUCH larger than other clients, for instance, 020Londoncoin has a MUCH SMALLER block size limit with a total coin coint of 200Billion, yet ALL OTHER MINING POOLS HAVE NO ISSUES WITH THE LIMIT WITHDRAWAL.
So before accusing us and pointing to github links that have nothing to do with anything we would request that you work with us to resolve the issue.
If a 9MB chain has NO ISSUES how in the hell does this 15MB chain limit have them???
Also a 303Million transaction size usually runs ~600 bytes..... Explain to me how 10Million is mor ethan 15MB seems like a gross error on your end.
Introas 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 backgroundyour 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#L30a 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#L36now, 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 transactionif you look at the code for this... found here:
https://github.com/CryptoCoderz/Espers/blob/62853947a2a87d923c5cbecf467d2abe29a38e8d/src/wallet.cpp#L1304you 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 conditionslets 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 trooolllActually, 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.
ConclusionI 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.
