Next Major Release of BTC Core to be Smarter About Transaction Fees

Chief Scientist at the Bitcoin Foundation Gavin Andresen has taken to the Foundation’s official blog this Monday to discuss the topic of floating fees for the release of Bitcoin Core 0.10.

In short, floating fees add flexibility to the amount of fees paid depending on the amount transacted and acts as a smart tool to help determine which fee amount is most appropriate in order to ensure that transactions confirm quickly. These floating fees also determine whether or not the transaction is of high enough priority to be sent free of charge and still receive confirmations in a short amount of time.

Andresen writes:

There is a new option that lets you control how quickly you’d like your transactions to confirm: txconfirmtarget. The default value is 1, meaning “I’d like my transactions to be sent with enough fee or priority so they are very likely to be included in the next block.” Set it to 6 and it will take on average six blocks for your transactions to get their first confirmation.

Andresen notes that he’s been running a bitcoind node for several weeks and recording estimates on fee amounts and blocks to confirm the transactions.

Says Andresen with reference to the chart above:

The hard-coded fee rules in Bitcoin Core correspond to the red-yellow-green lines– they are taking anywhere from 2-6 blocks to confirm. The hard-coded rules evolved over time, and are much more complicated than they should be. But, simplified, today’s Bitcoin Core wallet code will make a typical 250-something-byte transaction pay 0.0001 BTC — or around 0.0004 BTC per kilobyte.

If your transaction has a lot of inputs or outputs and is 1,000 bytes big, today’s Bitcoin Core wallet code will still have you pay 0.0001 BTC (it rounds up to the nearest 1,000 bytes) — and it might take 15 blocks (over two hours on average!) to get its first confirmation. That is bad; the new code will give much more predictable behavior.

The current situation is even worse for free, high-priority transactions: the hard-coded “high-priority” constant is much too low, so transactions sent for free can take a very long time to confirm.

The dark blue, confirm-in-the-next-block line is interesting; somebody is already paying more for their transactions to confirm quickly, either by setting the paytxfee option of Bitcoin Core or using some other wallet implementation.

According to Andresen, the possibility for small, fixed fees is just out of the question, for those who were wondering.

And on the topic of the future of transaction fees, Andresen said the following:

I expect to see transaction fees rise until a good solution for optimizing the propagation of blocks across the network is deployed, because I expect transaction volume to increase and I don’t think miners will include more transactions in their blocks until somebody fixes the “bigger blocks take longer to broadcast” problem.

Happily, fixing that problem should be just a matter of some smart engineers figuring it out and then writing code to make it happen.

You can view the original post by Gavin by following this link.