Why not automatically apply the TX fee to ANY transaction by default?

[Chrithu]

Well,

today I found out that at least in Bitcoin-Core there are cases in which the client does NOT automatically deduct a fee from a transaction (Before today it always did for any transaction I made). My guess is the rationale behind this is that such transactions aren't stressing the network much and thus should be handled for free. Obviously though the democratic vote of the miners is: Add a fee or GTFO. Which means such transactions are punished by taking ages to be confirmed.

So my question is, why do we need to manually force Bitcoin-Core to apply a fee to EVERY transaction regardless of size and number of coins? Imo that should be default behaviour. Slow transactions are one of the biggest flaws of Bitcoin anyways and the current default settings do not exactly help the situation.

Saying bitcoin transactions would be free of fees is a lie either way (and this lie is overlooked by most only because the fee is an extremely small amount of money if converted into FIAT currencies). And come the day that block rewards hit 0 (all bitcoin are mined) the fees will rise substantially and may even exceed what is charged by "traditional" payment providers.

[jonald_fyookball]

Obviously though the democratic vote of the miners is: Add a fee or GTFO.

Where did you get this assumption from? 
Bitcoin has a free structure that seems to be working fine,
and most mining profits are from the coinbase reward, not the fees.

[Gavin Andresen]

See https://github.com/bitcoin/bitcoin/pull/4250 and https://github.com/bitcoin/bitcoin/pull/3959

A future release will automagically figure out the right fee (or will figure out it doesn't need a fee) to get into a block quickly (or slowly, if you want to pay lower fees and are willing to wait).

As for your original question: set the -paytxfee command-line option for current Core releases and you WILL always pay a fee.

[Gyrsur]

a little off-topic but Gavin thanks so much for your talk and outlook at Bitcoin2014 in Amsterdam! you appears to me so clear minded in this growd of selfish people. thank you very much and yes price should go down! it's to early for such a rally.

EDIT: block size is still too low. as you mentioned the fear to get a block orphaned because of the higher time to propagate larger blocks to the network could be the reason for the limited blocksize of the miners and mining pools.

[Chrithu]

Obviously though the democratic vote of the miners is: Add a fee or GTFO.

Where did you get this assumption from?  
Bitcoin has a free structure that seems to be working fine,
and most mining profits are from the coinbase reward, not the fees.

Just my uneducated thought process of logical thinking:

Bitcoin-Core normally deducts the needed fee from transactions bigger than 1 KB and from transactions that use just one input regardless of size, but it does not deduct a fee if you use more than one input but still land below 1 KB in size, as I found out by playing around with the "coin control" function after this "no fee deducted" thing happened to me.

Since Bitcoin-Core is the reference client that defines the standards my logical assumption is that those transactions are meant to be handled for free in the same way that transactions that need a fee are handled, which includes being confirmed at the same speed. Since this didn't happen and instead said transaction took 6 hours to confirm the logical explanation for me was that miners didn't follow the standard rules of the Bitcoin-Core client.

If it isn't the miners' fault, then fine by me I made a wrong assumption. Nevertheless a thing like that shouldn't happen as it is extremely inconvenient for the user. In my view a reference client shouldn't resort to just setting the standards in terms of pure technical functionality but also in usability.

As to Gavin's answer:

Thanks for that info, that is good to know. Also I already set the client to always pay a fee in the preferences right after this incident. My rationale though is that we shouldn't need to do this by hand. It should be default behavior if paying a fee is the only valid way to make 100% sure that transactions are handled in a timely manor.

[jonald_fyookball]

You may be right. I was just challenging the notion that miners are overly concerned abut fees right now.

[Gavin Andresen]

My rationale though is that we shouldn't need to do this by hand. It should be default behavior if paying a fee is the only valid way to make 100% sure that transactions are handled in a timely manor.

The hard-coded setting for "high priority" is just wrong (it is much too low for the number of free transactions competing to be included in blocks these days).  The "smart fees" pull request fixes that, and will (by default) only send a transaction for free if it is pretty darn sure it will confirm quickly.

[Cryddit]

If you're spending a large output, and it's been sitting in your possession for a long time, your transaction will have a  high priority.  If the priority is higher than all of the other potentially-free transactions, it will usually get into a block immediately, even without fees. 

I recall this happening once last year when some very old coins moved - there was a single input of well over 1000 BTC, which was more than 18 months old at that time, and the transaction was sent with no fee whatsoever.  Of course it got into the very next block, because the priority was in the millions! 

In practical terms if I have a simple transaction that uses over 100 bitcoin-days, I assume it will go through immediately whether I add fees or not.