<p>The priority of a transaction is (the sum of (coin age in blocks * coin value in satoshis) over all the inputs in the transaction) divided by the size of the transaction in bytes.</p>

<p>Here's a <a href="http://bitcoincharts.com/bitcoin/txlist/#634144b781af98f6953f035d00fb7750d96df56709e89ff87bd2d9ca98cba810" rel="nofollow noreferrer">random example transaction</a> copied from <a href="http://bitcoincharts.com/bitcoin/txlist/" rel="nofollow noreferrer">http://bitcoincharts.com/bitcoin/txlist/</a>:</p>

<p><img src="https://i.sstatic.net/nVK40.png" alt="enter image description here"></p>

<p>It has 2 inputs (both of which have since been spent in other (confirmed) transactions rendering this transaction unconfirmable):</p>

<ul>
<li>one for 0.1005 BTC from block 165774</li>
<li>one for 0.0995 BTC from block 165777</li>
</ul>

<p>It is 439 bytes long, and has a priority of 432,232,688.</p>

<p>The most recent blocks in the blockchain is 175262 at the time of writing.</p>

<p>I sum the (age * values) for each transaction and divide by size.  The <code>+ 1</code> is because transactions confirmed in the newest block are considered to have an age of 1, not 0:</p>

<pre><code>&gt;&gt;&gt; current_block = 175262
&gt;&gt;&gt; ((current_block - 165774 + 1) * 0.1005e8 +
     (current_block - 165777 + 1) * 0.0995e8) / 439
432232687.92710704
</code></pre>

<p>As you can see, the priority of a transaction will go up as new blocks are found.</p>

CC BY-SA 3.0
2012-04-12T01:35:43.953Z
This is the priority the client uses to decide which transactions to include in mined blocks. This is most likely what someone wants to know when they ask about transaction priority.
David Schwartz
CC BY-SA 3.0
2012-04-12T01:42:22.957Z
Agreed. Great answer but not to the right question. It would be an excellent answer to [this](http://bitcoin.stackexchange.com/questions/1077/what-is-the-coin-selection-algorithm) question, I'd suggest you copy it there and remove it from here.
BinaryMage
CC BY-SA 3.0
2012-04-12T06:35:05.560Z
I think this is the calculation the question was referring to.  It's just that it's not used to decide which transactions to relay.  There's no priority calculation when deciding which transactions to relay.
Chris Moore
CC BY-SA 3.0
2012-04-11T18:06:14.830Z
2012-04-11T18:11:24.433Z
2012-04-11T18:11:24.433Z
Chris Moore
<p>The rules for the Bitcoin.org client are to keep the first transaction in which a bitcoin address is spent and to discard without relaying any others that might arrive.</p>

<p>So the priority is based on chronological time of arrival.</p>

<p>There has been <a href="http://bitcointalk.org/index.php?topic=67739.msg845100#msg845100" rel="nofollow noreferrer">talk of variations</a> that would allow a replacement transaction with a higher fee to supercede an earlier transaction that has not yet been confirmed.</p>

<p>And there is an attack vector that describes how this priority can be modified to <a href="https://bitcoin.stackexchange.com/questions/3315/double-spend-attack-by-sending-higher-fee-transaction-directly-to-the-pools-poss">facilitate double spending</a>.</p>

CC BY-SA 3.0
2012-04-12T05:17:42.330Z
2012-04-12T05:17:42.330Z
2017-04-13T12:47:33.283Z
Stephen Gornick
<p>I've heard that the standard client prioritizes which transaction to relay based on the Bitcoin Days Destroyed and the fee paid on the transaction, but what is the exact formula used to determine which transaction has higher priority? That is, how does the standard client prioritize which transaction to send to other nodes first?</p>

CC BY-SA 3.0
2012-04-11T01:19:52.470Z
possible duplicate of [What is the coin selection algorithm?](http://bitcoin.stackexchange.com/questions/1077/what-is-the-coin-selection-algorithm)
Stephen Gornick
CC BY-SA 3.0
2012-04-11T05:08:04.987Z
@StephenGornick Not a duplicate, this relates to _relaying_ transactions while the one you linked relates to prioritizing coins used in transactions.
BinaryMage
CC BY-SA 3.0
2012-04-11T21:42:41.163Z
Maybe you should precise what you mean by *relay*. Are you interested in the order transactions are relayed to other peers, or the order (and maybe  quantity) that are considered to build new blocks?
Stéphane Gimenez
<transactions><bitcoin-core><protocol><bitcoin-days-destroyed><coin-age-priority>
How does the standard client prioritize transactions?
ThePiachu
# How does the standard client prioritize transactions?

(Asked by: username_0 on 2012-04-10)

I've heard that the standard client prioritizes which transaction to relay based on the Bitcoin Days Destroyed and the fee paid on the transaction, but what is the exact formula used to determine which transaction has higher priority? That is, how does the standard client prioritize which transaction to send to other nodes first?

**Tags:** transactions, bitcoin-core, protocol, bitcoin-days-destroyed, coin-age-priority

> **Comments:**
> **username_1**: possible duplicate of [What is the coin selection algorithm?](http://bitcoin.stackexchange.com/questions/1077/what-is-the-coin-selection-algorithm)  
> **username_2**: @username_1 Not a duplicate, this relates to _relaying_ transactions while the one you linked relates to prioritizing coins used in transactions.  
> **username_3**: Maybe you should precise what you mean by *relay*. Are you interested in the order transactions are relayed to other peers, or the order (and maybe  quantity) that are considered to build new blocks?  

---

## 2 answers

### Answer by username_4 on 2012-04-11. Score: 2

The priority of a transaction is (the sum of (coin age in blocks \* coin value in satoshis) over all the inputs in the transaction) divided by the size of the transaction in bytes.

Here's a [random example transaction](http://bitcoincharts.com/bitcoin/txlist/#634144b781af98f6953f035d00fb7750d96df56709e89ff87bd2d9ca98cba810) copied from <http://bitcoincharts.com/bitcoin/txlist/>:

![enter image description here](https://i.sstatic.net/nVK40.png)

It has 2 inputs (both of which have since been spent in other (confirmed) transactions rendering this transaction unconfirmable):

* one for 0.1005 BTC from block 165774
* one for 0.0995 BTC from block 165777

It is 439 bytes long, and has a priority of 432,232,688.

The most recent blocks in the blockchain is 175262 at the time of writing.

I sum the (age \* values) for each transaction and divide by size. The `+ 1` is because transactions confirmed in the newest block are considered to have an age of 1, not 0:

```
>>> current_block = 175262
>>> ((current_block - 165774 + 1) * 0.1005e8 +
     (current_block - 165777 + 1) * 0.0995e8) / 439
432232687.92710704

```

As you can see, the priority of a transaction will go up as new blocks are found.

> **Comments:**
> **username_5**: This is the priority the client uses to decide which transactions to include in mined blocks. This is most likely what someone wants to know when they ask about transaction priority.  
> **username_2**: Agreed. Great answer but not to the right question. It would be an excellent answer to [this](http://bitcoin.stackexchange.com/questions/1077/what-is-the-coin-selection-algorithm) question, I'd suggest you copy it there and remove it from here.  
> **username_4**: I think this is the calculation the question was referring to.  It's just that it's not used to decide which transactions to relay.  There's no priority calculation when deciding which transactions to relay.  

---

### Answer by username_1 on 2012-04-12. Score: 1

The rules for the Bitcoin.org client are to keep the first transaction in which a bitcoin address is spent and to discard without relaying any others that might arrive.

So the priority is based on chronological time of arrival.

There has been [talk of variations](http://bitcointalk.org/index.php?topic=67739.msg845100#msg845100) that would allow a replacement transaction with a higher fee to supercede an earlier transaction that has not yet been confirmed.

And there is an attack vector that describes how this priority can be modified to [facilitate double spending](https://bitcoin.stackexchange.com/questions/3315/double-spend-attack-by-sending-higher-fee-transaction-directly-to-the-pools-poss).


---

