4

I've been reading about transaction fees here.

From the aritcle,

Transaction priority is calculated as a value-weighted sum of input age, divided by transaction size in bytes: priority = sum(input_value_in_base_units * input_age)/size_in_bytes Transactions need to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21).

There are rules for determining the transaction fees needed depending on client etc. My question is does paying a fee increase the priority or else how does it increase the chances that the transaction will be accepted by the network. If it changes the priority, what is the formula for determining priority. If you pay more than the default fee does it increase the priority even more?

10

Currently no. Any "required fees" are enforced only by the client not the network or protocol.

It is up to each individual miners which transactions to include in a block. If forced to make a choice a miner would choose a paying transaction over a nonpaying one however current transaction volume is so low that all transactions (paying and otherwise) can fit into next block with significant room to spare. If you used a modified client with no fees most miners would simply include your fee transactions. Some pools (Eligius) will exclude free transactions that "should" (based on mainline client rules) have a fee.

As for what fee is the minimum to guarantee access to the next block. Most miners and mining pools prioritize transactions by fees and then priority. If you include any fee (even 1 satoshi) even if it is less than what is required by mainline client it likely will be included in the next block. Paying more is likely of negligible value as paying anything almost guarantees access to the next block. The block size limit isn't much of a capacity constraint to warrant higher fees (and move further up transaction list ordering). I can't see any miner excluding a valid paying transaction from any block at current transaction volume.

The current fee structure (or lack thereof) brings up some scalability issues when block reward aproaches zero. The development team has indicated an improved fee structure is something planned for later releases. It is an issue which will need to be addresses as left as it is now one could simply include 1 satoshi fee with every transaction and it would drive block fees down to ~ (transactions per second) / 166,667 BTC per block. Even at high volume of say 1,000 tps it would be a tiny number and thus network hashing power would fall to a tiny fraction of current hashing power leaving the network vulnerable.

  • Thanks. I'm really thinking about a possible future with much higher transaction volumes and there is competition to be included in a block - I believe the maximum block size is 1MB. So say there are more transactions than can be included in a block (sum of the transactions is >1MB) and the miner has to prioritize transactions, would it be correct to say the ranking would go largest fee to smallest, then largest priority to smallest. i.e. a transaction with even a 1 satoshi fee would trump a transaction of large priority with no fee. – kirian Oct 26 '11 at 0:18
  • @kirian Yes if the block was capacity constrained any smart miner would choose 1 satoshi fee over no fee and thus unless there were so many transactions that not all 1 satoshi fee transactions would fit it would guarantee a spot in the next block. Of course this dynamic leads to the problem in my third paragraph as everyone is likely to do this. – DeathAndTaxes Oct 26 '11 at 1:16
4

There's a very nice visualization of the most recent 4 hours' worth of transactions and whether they paid a fee or not, and how long it took each one to be confirmed:

http://bitcoinstats.org/

Sometimes it looks like fee-offering transactions have a significant advantage over no-fee transactions, other times it looks random.

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.