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.
Hey OCMiner,
Because i know a mining pool is a business in a sense, and i hate to see a business lose money at no fault of their own and earn a bad rep, im going to give you this bit of friendly advice because i saw it in the code and have since tested it to make sure i wasnt mistaken.
actually... this goes for all services/users that are running a daemon as opposed to a gui client.
Do NOT send a transaction of less than 0.01 from the daemon. there is NO check in the code for a lower limit free transaction that the miner will later consider too low of a priority and never send. you will lose all outputs from that missing input branch. if your services code does not automatically pay a fee to send a tx, then you might lose coins due to this bug.
what i mean by this is:
say you mine a block and get 50,000 coins. you then send 0.001 from the daemon to another wallet (for whatever reason) and it uses that 50k esper block you just mined as input. this is what will happen. it will take that 50k input. mark it as spent. and create a transaction that sends the 0.001 to another wallet and returns the 49999.999 to your wallet. this is the standard for every transaction ever, including bitcoin so dont think this is weird, this is how the system works. that part is normal.
what the problem is, is that the espers daemon (Espersd) will not warn you or preform a check to see if that makes the priority too low for the transaction to be passed into a block due to the way the min tx fee is structured (there isnt one, esp allows free transactions) and will in turn NEVER process that tx into a block. since the 0.001 transaction was not processed, the 49,999.999 is also never reconnected to your wallet and you lose those coins. (they will still show up in your wallet, but because the input for any transaction that includes those coins is now reliant on the 0.001 transaction that was never processed it is impossible to send them anywhere as they too will never be processed due to missing inputs).
until they fix this with the daemon (to be honest the gui client might also do this but i havent tested it and wont be testing it tonight) you should add
paytxfee=0.01
to your Espers.conf file so that this fee will stop you from accidentally losing coins by sending a too low priority transaction because a fee will raise the priority of the transaction causing it to be packaged. i did test it and it does ensure that all transactions down to the lowest sendable amount (0.00055) will be send and will be processed by the miners.
i would go over this in code but its 3:45 am, so you can test it if you'd like (although send coins, say 100 coins, to a NEW wallet on a SEPARATE MACHINE before testing it, you WILL LOSE COINS DURING TEST) or you can take my word for it because i already tested it.
[FULL DISCLOSURE: i originally thought this was a merkle building problem and that is why small transactions with no fee are never processed, but the addition of the fee, which i know for a fact raises the priority in the miner for that transaction, causes the small transactions to be processed leads me to believe it is more than likely a priority issue]
-Griffith
edit: i know from reading this the most obvious fix is just to check to see if the amount sent is below 0.01, which yes. does patch the issue for the future, but it doesnt fix the actual problem at heart. just covers it up, like the government on a tuesday (that last part is a joke for anyone who doesnt get it, its supposed to be funny)
