Bitcoin Forum
May 14, 2024, 02:30:06 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Why not automatically apply the TX fee to ANY transaction by default?  (Read 828 times)
Chrithu (OP)
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
June 01, 2014, 09:49:22 PM
 #1

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.

1715653806
Hero Member
*
Offline Offline

Posts: 1715653806

View Profile Personal Message (Offline)

Ignore
1715653806
Reply with quote  #2

1715653806
Report to moderator
1715653806
Hero Member
*
Offline Offline

Posts: 1715653806

View Profile Personal Message (Offline)

Ignore
1715653806
Reply with quote  #2

1715653806
Report to moderator
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715653806
Hero Member
*
Offline Offline

Posts: 1715653806

View Profile Personal Message (Offline)

Ignore
1715653806
Reply with quote  #2

1715653806
Report to moderator
1715653806
Hero Member
*
Offline Offline

Posts: 1715653806

View Profile Personal Message (Offline)

Ignore
1715653806
Reply with quote  #2

1715653806
Report to moderator
1715653806
Hero Member
*
Offline Offline

Posts: 1715653806

View Profile Personal Message (Offline)

Ignore
1715653806
Reply with quote  #2

1715653806
Report to moderator
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
June 01, 2014, 10:06:14 PM
 #2

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
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2216


Chief Scientist


View Profile WWW
June 01, 2014, 11:10:59 PM
 #3

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.

How often do you get the chance to work on a potentially world-changing project?
Gyrsur
Legendary
*
Offline Offline

Activity: 2856
Merit: 1520


Bitcoin Legal Tender Countries: 2 of 206


View Profile WWW
June 01, 2014, 11:20:41 PM
Last edit: June 01, 2014, 11:36:14 PM by Gyrsur
 #4

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

Activity: 224
Merit: 100


View Profile
June 02, 2014, 08:05:07 AM
 #5

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
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
June 02, 2014, 03:40:47 PM
 #6

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

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2216


Chief Scientist


View Profile WWW
June 02, 2014, 04:01:51 PM
 #7

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.


How often do you get the chance to work on a potentially world-changing project?
Cryddit
Legendary
*
Offline Offline

Activity: 924
Merit: 1129


View Profile
June 04, 2014, 01:27:48 AM
 #8


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.

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!