Topic: Abnormally high fee of 0.0025BTC for a 324 byte transaction (Read 914 times)

ISAWHIM has been spamming the forum with his nonsense and drivel. He doesn't like the enforced fees, but he hasn't botherd taking the time to understand how things work.  Instead he's made it his own personal quest to announce as often as he can how he thinks it works and how he thinks it should work.  Your best option is to just put him on ignore.


I'm not a dev, but if you didn't change your optional fee to 0.0025, then there definitely appears to be a bug.  Looking at that transaction, I don't see any other reason for Bitcoin-Qt to have enforced a fee greater than 0.0005 BTC.

Dude, i understand change and how transactions work, but the matter now is that there were only 2 inputs and the whole transaction was 300+ bytes!


If the fee is calculated from "dust" which is not even used, then it is a serious bug in the client where you are paying for dust which is not even being gotten rid of. The min tx fee is set at 0.0001. Im using v0.80 so the spam fee is 0.0005, but thats the maximum that should be used for a <1kB txn with low-priority txns!

Could any of the devs help here?

$0.32 for a total of two transactions that total $18.25 is high... Could be that someone REALY wanted that $16 transaction to go through fast. Or they were real generous. Or simply have manually set a high-set "min tx fee" in the settings, and just don't care.

Or, it could be that the $2 transaction was derived from all change, and the "change" just didn't show in the block. (Though the "fee" may have been "calculated" from the dust, which just wasn't actually used in the actual transaction. Could also happen if a "new arriving transaction "fits" the amount, after the "fee" was calculated from the dust.)

EG, one was 0.0005 (for the $2.00 tx)
one was 0.002 (for the $16.00 tx)

Merged transactions look like this... (Note, some browsers do not show merged transactions. Some do? Might be the HTML-5 code is not compatible with some browsers.) Normally it looks like this...

s9d8f769s8df68s76f87sdfd544
9ds6f6s87d6f87s6f87s6f6s8rff
s8d7f687sd6f87s6df87s6f87sd
sd56f78sdf5s76df5s67df7sd6f5
sf87sdf87s6f876sdf876s8d7f64
sd87f87s6df876sd8f76s87f68sf -> 9ds7f9s7f8ds7f98sd7f79

(Not actual data, lol...)

EG, if you have a lot of "change" (your unseen walletTXaddress), or if you send 3BTC, but there is only 1BTC in one add, 1.5BTC in another address, and 0.5BTC removed form another address in your wallet. (That will generate a "change", at-least 1-change, of the last address "balance" - "tx" - "txfees" for those 3 merged "individual" transactions that turn into one send...)

For "simplicity", the "change" and individual fragments of an actual transaction are hidden in a "wallet" program. Some additional info is available on the "blockchain", but some is still "hidden".

Yeah there aren't many transactions:

http://blockchain.info/address/1Af3bFEEPeJmnfWo7dCdsGpjf8jL8TDQdn
http://blockchain.info/address/17xvUU6Y5jeNSta9FagQL1Yx19SRKcacRx

The bitcoin protocol does merging of input transactions?
That's news to me.

How is this merging recorded in the blockchain?
Blockchain.info does not seem to show/reflect this at all.

Or are you assuming that i have many inputs without checking out the transaction(It's only 2 inputs)?

I answered this in a prior post... this is a repost... I am not going to play the "linking game"... lol

There is a command you can give to remove the "forced" leeching fees. (Added down below)

The issue is that your 0.01BTC transaction may actually include "change" from your wallet. It is looking at the "change" not the "send amount".

EG... You are trying to send 0.01BTC but that is being sent from all these mini-transactions.
- 0.0000012312 (What you actually send, as "change")
- 0.0000322323
- 0.0000032123
- 0.0000223223
...
...
---------------
= 0.0100000000 (What you think you are sending as ONE tx)

Thus, if you have 40 change files, it is attempting to add 0.0005 x40 = 0.02BTC to your 0.01BTC, for a total of 0.03BTC expected to "send" the 0.01BTC

EG, poor code.
 CHANGE --------------Expected FEE to send this change
- 0.0000012312 + 0.0005 = 0.0005012312
- 0.0000322323 + 0.0005 = 0.0005322323
- 0.0000032123 + 0.0005 = 0.0005032123
- 0.0000223223 + 0.0005 = 0.0005223223
... (36x more times)
...
---------------
= 0.0100000000 + 0.02000000 = 0.03000000

Thus, "leeching" you of your funds, that you are not even aware of. It does not show you the "change". That, and the code stupidly "makes change" on most transactions that do not need to. (That is called job stability.)

Even though it IS actually merging them into ONE out (send), it is charging YOU as if they were 40 separate sends. (That is the "poor programming" the "leeching". The only one winning is the pool-operators who withhold the tx fees from the miners. Guess who imposed that minimum... the pool operators!)


EG add the commands -mintxfee=0.000001 and minrelaytxfee=0.000001 to your STARTUP-ICON, to make it more "realistic", but realize it may take a LITTLE longer to process those transactions with lots of change-files.

P.S. Version 8.2 will be only 0.0001 for minrelaytxfee and mintxfee, due to the MANY MANY MANY complaints... (Though they are not fixing the actual "poor code" that calculates the fee, so the fees are still going to be "wrongly calculated", as stated above.)
http://www.btcpedia.com/bitcoin-qt-0-8-2-lower-fee/
https://en.bitcoin.it/wiki/Transaction_fees

http://blockchain.info/tx/e5883f31409a7cefc0b15307671e166c90f74ab619adf42665dac2f153155c5f

Not really sure why bitcoind paid such a high fee for a transaction with only 2 inputs.

Anyone have a clue?