Where do transaction fees go?

[Furyan]

In the traditional world, transaction fees don't disappear, they still end up in someone's account somewhere.

If I'm grokking this correctly - bitcoin transaction fees simply disappear. Nobody gets them, they simply cease to exist in the system.

Someone please tell me I'm wrong, and explain where they really go

[1714647697]

1714647697

[1714647697]

1714647697

[1714647697]

1714647697

[1714647697]

1714647697

[1714647697]

1714647697

[NetTecture]

You are wrong.

Tx fees goes to whoever processe s the block that contains the transaction. Additional reward for miners.

[etotheipi]

You are wrong.

Ouch!  That's a little harsh, don't you think?   

Each block contains a list of transactions since the last block.  As we all know already, whichever miner solves the next block gets to include a transaction for 50 BTC to themself from "coinbase."  It turns out that  that if any of the transactions the miner included in your block had a fee attached to it, then the miner gets to include those, too.  Therefore, when a miner solves a block, it typically gets something like 50.75 BTC instead of 50.  The more transactions there were, the more fees received.

If you look at the BTC webpage description about what happens when there's no more rewards for solving blocks, it mentions that they expect the network to be big enough by then that it will be worth solving blocks solely for the fees.  If there are 10,000 transactions per block, at 0.005 per transaction fee, that's 50 BTC in fees.  If BTC really catches on, this is a realistic volume of transactions

Right now, because of the low volume of transactions, most pools only distribute the 50 BTC coinbase, and keep the transaction fees, which are small, but add up over time...

[Furyan]

You are wrong.

Ouch!  That's a little harsh, don't you think?  

Each block contains a list of transactions since the last block.  As we all know already, whichever miner solves the next block gets to include a transaction for 50 BTC to themself from "coinbase."  It turns out that  that if any of the transactions the miner included in your block had a fee attached to it, then the miner gets to include those, too.  Therefore, when a miner solves a block, it typically gets something like 50.75 BTC instead of 50.  The more transactions there were, the more fees received.

If you look at the BTC webpage description about what happens when there's no more rewards for solving blocks, it mentions that they expect the network to be big enough by then that it will be worth solving blocks solely for the fees.  If there are 10,000 transactions per block, at 0.005 per transaction fee, that's 50 BTC in fees.  If BTC really catches on, this is a realistic volume of transactions

Right now, because of the low volume of transactions, most pools only distribute the 50 BTC coinbase, and keep the transaction fees, which are small, but add up over time...

THIS is a fantastic explanation.  Thank you!!  I ask because it has a small but not insignificant impact on how I code something and I wanted to make sure I understood the process correctly. You also answered something else I was wondering about, which was what would happen after all the available BTC had been mined - what would be the financial incentive to continue mining.  Let us hope you're right about the network being big enough to be worth it!

WRT it being harsh, I did, after all, ask for someone to tell me I was wrong

Even if I hadn't, I have been around long enough that such things never penetrate the thick internet skin I've developed.

[etotheipi]

Now my turn to ask a question:  I notice from looking at the blockexplorer that most transactions don't actually have any fees.  I thought fees were generally required by the miners in order to prevent DoS/penny-flood attacks.  If the zero-fee transactions do actually go through, what is stopping someone from executing such an attack?

I know that the client has a built-in node-disconnect if it starts getting spammed from that node.   But what is stopping the node from connecting to each of 5000 peers and giving them each 20, zero-fee transactions?  Seems like that would be a pretty big inconvenience for the entire network...

[Maged]

Now my turn to ask a question:  I notice from looking at the blockexplorer that most transactions don't actually have any fees.  I thought fees were generally required by the miners in order to prevent DoS/penny-flood attacks.  If the zero-fee transactions do actually go through, what is stopping someone from executing such an attack?

I know that the client has a built-in node-disconnect if it starts getting spammed from that node.   But what is stopping the node from connecting to each of 5000 peers and giving them each 20, zero-fee transactions?  Seems like that would be a pretty big inconvenience for the entire network...

Transactions are prioritized based on the age of the TxOuts that are being used, the amount of bitcoins transferred in the transaction, and the physical size of the transaction.

[gmaxwell]

Now my turn to ask a question:  I notice from looking at the blockexplorer that most transactions don't actually have any fees.  I thought fees were generally required by the miners in order to prevent DoS/penny-flood attacks.  If the zero-fee transactions do actually go through, what is stopping someone from executing such an attack?

I know that the client has a built-in node-disconnect if it starts getting spammed from that node.   But what is stopping the node from connecting to each of 5000 peers and giving them each 20, zero-fee transactions?  Seems like that would be a pretty big inconvenience for the entire network...

You're misunderstanding a bit how it works.  Most transactions don't need to pay a fee at all— but transactions that appear to be indicative of a DOS attack based on a simple objective criteria need to pay a fee or most nodes will simply drop them (they won't disconnect, the anti-flooding stuff is totally separate).

It works like this,  take the value of each input and multiply it by the number of confirmations it has. Sum that and divide by the size of the txn in bytes.   This is the transactions priority.  If the priority is less than a typical 1 BTC txn aged one day would have, then the transaction is low priority and needs a fee. Additionally transactions with outputs smaller than 0.01 need to pay a fee, just to make open-transaction bloating attacks more costly.

This way, holding the coins itself is the "proof of work" that shows you are probably not attacking.  It's a simple objective measure that can't really be gamed (except by simply using enormous amounts of bitcoin in your attack) and which doesn't require any additional communication or coordination between nodes and doesn't care if you connect to one node or 100.

[JoelKatz]

Two things are built into the protocol:

1) A miner has absolute freedom to include no transactions or whatever valid transactions he wishes in the block he mines.

2) A client has absolute freedom to accept and relay whatever valid transactions it wishes.

So if the priority scheme needs to change, it can. If the expected transaction fees need to change, they will (and they have). It won't break the protocol or cause any incompatibilities. Except that people who don't follow the new majority rules may have a hard time getting their transactions accepted.

Right now, there are still quite a few client operators and miners who will relay and include in a block all valid transactions. So pretty much any valid transaction will currently get into the block chain eventually. (Especially if you make a special effort to connect to and relay to these clients/miners.)

[etotheipi]

I recognize the freedom of miners to include whatever transactions they want, and the flexibility of transaction fee schedules.  My question was more about why this particular scheme was chosen in the default client configuration?  I thought part of the purpose of the transaction fees was to discourage penny-flood attacks, but it would seem that most transactions are currently going through without any fees, so I don't see what's stopping a someone from executing an attack right now.
 
I'm also a little biased because one time I didn't include a tx fee and 3 months later it's still 0/Unconfirmed.  I assumed that it was because the network was designed to reject zero-fee tx's.  Clearly this is not the case...

[TiagoTiago]

With lots of coins you can do such an attack, but only for so long, and then either you start loosing your coins with transaction fees or your transactions get throttle 'cause the coins are too fresh in the wallet to be transfered again without a txfee (if you only got a few coins the amount of different transfers that won't have a mandatory fee will be much smaller, so either the attack will not be too strong, or will end quickly as you run out of money)

[JoelKatz]

I recognize the freedom of miners to include whatever transactions they want, and the flexibility of transaction fee schedules.  My question was more about why this particular scheme was chosen in the default client configuration?  I thought part of the purpose of the transaction fees was to discourage penny-flood attacks, but it would seem that most transactions are currently going through without any fees, so I don't see what's stopping a someone from executing an attack right now.

The priority scheme stops the attack. The idea is that any attack would have to consist of transactions that legitimate transactions could easily out-priority. So while the attack might, at worst, flood the block chain with junk, it can't stop legitimate transactions in the short term.

If someone attacks the network with low-priority transactions, just make sure your legitimate transactions exceed their prioritity, which they probably will anyway. Even if they don't now, they will eventually as your coins age. An attacker can't have an unlimited supply of old transaction outputs. You can't, in general, use 100 old bitcoins to fund 100 transactions. Once the old coins fund one transaction, they are no longer old.

The current scheme is not perfect and may not even be great, but it does seem to be adequate. And it can evolve, and has evolve, as needed.

[etotheipi]

I'm actually less concerned about flooding out other transactions, than I am concerned that someone could inject gigabytes of bloat to the blockchain (for free!), making it even more prohibitive for regular/light users to use the software.  Both in terms of computation time and disk space resources.

So, are there any transactions that the default client won't accept without a transaction fee?  If a node/miner doesn't want to process the transaction, it still forwards it to other nodes that might process it, correct?

It sounds like it's still possible for one individual to connect to each of a thousand nodes and pass off 20 tx each, and without a single fee.  He could just transfer to himself.   That would add 10 MB of pointless Tx data to the blockchain, in a relatively short time.   Seems like a good way for someone who does like BTC to cause "deterioration" in the network... or at least cause the core developers to have to switch to optimizations they weren't planning to implement yet.

[JoelKatz]

So, are there any transactions that the default client won't accept without a transaction fee?  If a node/miner doesn't want to process the transaction, it still forwards it to other nodes that might process it, correct?

The default client will refuse to relay some no-fee transactions. If my memory serves me correctly, it will actually rate-limit free transactions based (sort of) on total size of all free transactions seen in a 10 minute window. This should ensure any such attack would have to run for a very long time to do real damage, giving us plenty of time to react.

I believe the current scheme is adequate but not great.