The current fee mechanism is confusing and difficult to implement.

The current fee system uses transaction size and the size of the block the transaction is due to appear in to calculate the fee. If you're writing a Bitcoin client such as a web wallet or android app this is not easy to implement.

Is there any reason we couldn't have a well documented fee mechanism along the following lines ?

  • Fixed fee, or
  • % of transaction amount, or
  • % of transaction amount capped or floored.

I was also giving the problem a bit of thought, and here are some conclusions I reached:

  • It is impossible to set a fixed fee once and for all, as one does not know the volume of transactions that will appear in the future, nor how big an exponent of Bitcoins will be a "common sight" (before Bitcoins became popular, someone paid 10kBTC for a pizza for example). So the fee would need to be adjusted over time, a bit like difficulty.
  • Percentage of transaction amount would be harming the people owning large amount of Bitcoins in one address, as in order to spend some of their Bitcoins, they need to send the rest back to themselves. This would encourage people to spread their Bitcoins over many addresses, creating an accounting mess at times.
  • Calculating the fee based on real-world value of 1BTC would be too hard, as it would require a lot of knowledge form outside the network.
  • Calculating the fee based on current difficulty can be slippery for transactions sent around the difficulty adjustment block.

So in general, the current way of calculating the fee might not be that good, but nobody smart enough has come up with anything better.

  • Why would spreading your coins over many addresses help if the transaction fee was a flat percentage? EDIT: forget my comment, I see what you're saying: there's less change in a transaction if your coins are spread out. – jl6 Jan 12 '12 at 22:00

The current fee schedule exists to defend against spamming the network. The load on the network has nothing to do with the amount transferred and everything to do with the size of the transaction. The likelihood that a transaction is intended as spam rather than legitimate is influenced by the use of recent coins (since an attacker will rapidly use the same coins again and again).

If you enforce a fee which is independent of those, you'll allow attackers to overload the network by broadcasting rapid, huge transactions and having to pay only 0.005 BTC fee each.

The value 0.005 BTC specifically is a lot for legitimate microtransactions.

In the future the way fees work will be completely different, but nobody knows exactly how.

  • 1
    Not saying your statement is wrong, but I don't believe microtransactions are a design goal of Bitcoin. – jl6 Jan 12 '12 at 21:57
  • @jl6: Agree that microtransactions are not as good a match for Bitcoin as it initially seemed, but if there is real Bitcoin adoption, 0.005 BTC could be a lot of money. – Thilo Jan 13 '12 at 7:46
  • 1
    @jl6: Depends on how "micro". The transaction fee shouldn't be much more than the amortized cost of a transaction in the network, which I believe is much less than $0.03. I think raw Bitcoin should aspire to enable transfers of below $1 without having to worry about tx fees taking a large chunk. – Meni Rosenfeld Jan 13 '12 at 8:19
  • There are some people who think the potential for microtransactions is one of the core value propositions of bitcoin. The cost of transmitting and storing data is dropping. – Kinnard Hockenhull Mar 14 '13 at 8:22
  • @KinnardHockenhull: They're dropping but they still exist. Nanotransactions are more likely to be achieved with en.bitcoin.it/wiki/User:Aakselrod/Draft. – Meni Rosenfeld Mar 14 '13 at 16:15

Why set a fee, when the market can very well find it?

How do you know 0.005 BTC is "the right amount"? This is important, because it will become the main incentive to mine, when the block reward drops to zero. It's impossible to predict now what the best amount will be ... too low, and not enough miners will mine, opening the network to double spend. Too high, users suffer.

Practically speaking - for the time being, just use a constant 0.005. APIs will be available in the future to determine a recommended TX fee, based on actual statistics.


We could make the cost related to the current difficulty (of generating a new block) but quite frankly this slightly complex system is just fine. It only kicks in on strange or really small transactions and it's not that high.

Not only that but it's only the default with which the standard Bitcoin client now works. If you think a much lower fee would also suffice, why don't you starting mining including everything with that fee?

There's a clear difference between a profit driven fee and an anti-spam measure. I think this is still solidly in the latter category.


Miners can choose any fee schedule they want. However, a fixed fee has proven problematic on scamcoin chains like Solidcoin, when people create huge (data-size) transactions.


Why can't fees be calculated based on current network activity, so that people wanting cheaper fees will send money at quieter times? This will mean a more even volume of transactions which will enable fewer miners and so increasing their revenue?

I don't know about block size is this the same thing, I still don't totally understand the mechanics of it but it would seem logical to reduce waste in the network, so zero fee payers might only get there transactions processed at quieter times.

  • Ideally, there won't be a quieter time. Financial transactions are a 24/7 thing. There might be a perceived "quiet time" right now because most of the Bitcoin community is based in Europe and North America. That will go away when Bitcoin catches on more strongly in Asia. – Colin Dean Mar 3 '13 at 19:48
  • The major scaling pain of bitcoin is diskspace and the time it takes for a client to bootstrap into the network. For both of those, it doesn't really matter when a transaction is made. – Nick ODell Mar 3 '13 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.