Bitcoin Forum
June 14, 2024, 05:54:37 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Abnormally high fee of 0.0025BTC for a 324 byte transaction  (Read 885 times)
Nagato (OP)
Full Member
***
Offline Offline

Activity: 150
Merit: 100



View Profile WWW
May 28, 2013, 03:24:27 AM
 #1

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?

ISAWHIM
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
May 28, 2013, 10:02:01 AM
 #2

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!)

Quote
The default fee policy can be overridden using the -mintxfee and -minrelaytxfee command-line options, but note that developers intend to replace the hard-coded fees with code that automatically calculates and suggests appropriate fees in the 0.9 release and note that if you set a fee policy significantly different from the rest of the network your transactions may never confirm.

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
Nagato (OP)
Full Member
***
Offline Offline

Activity: 150
Merit: 100



View Profile WWW
May 28, 2013, 10:44:05 AM
 #3

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)?

Abdussamad
Legendary
*
Offline Offline

Activity: 3626
Merit: 1568



View Profile
May 28, 2013, 12:14:18 PM
 #4

Yeah there aren't many transactions:

http://blockchain.info/address/1Af3bFEEPeJmnfWo7dCdsGpjf8jL8TDQdn
http://blockchain.info/address/17xvUU6Y5jeNSta9FagQL1Yx19SRKcacRx
ISAWHIM
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
May 28, 2013, 12:20:06 PM
Last edit: May 28, 2013, 12:35:05 PM by ISAWHIM
 #5

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".
ISAWHIM
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
May 28, 2013, 12:34:27 PM
 #6


$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) Huh
one was 0.002 (for the $16.00 tx) Huh
Nagato (OP)
Full Member
***
Offline Offline

Activity: 150
Merit: 100



View Profile WWW
May 28, 2013, 12:56:20 PM
 #7

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

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!


$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) Huh
one was 0.002 (for the $16.00 tx) Huh

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?

DannyHamilton
Legendary
*
Offline Offline

Activity: 3416
Merit: 4658



View Profile
May 28, 2013, 02:22:50 PM
 #8

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!

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.

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?

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!