<p>For normal transactions¹, there are no constraints on the order of outputs. The general standard seems to be that people randomize all inputs and outputs after assembling their transaction before signing. There is also a Bitcoin Improvement Proposal (<a href="https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki" rel="nofollow noreferrer">BIP69</a>) which suggests a lexicographical order for inputs and outputs. Uniform sorting is meant to help transactions from various wallets look more alike. It is explicitly declared as optional, since it interferes with some other use cases and some respondents considered it worse than just randomized order.</p>
<hr />
<p><sup>¹There are some exceptions, for example if you use the <code>sighash_single</code> sighash flag, your input will only commit to the one output with the same index.</sup></p>

CC BY-SA 4.0
2021-11-27T21:00:01.477Z
2021-11-27T21:00:01.477Z
Murch
<p><a href="https://bitcoin.stackexchange.com/questions/100997/what-exactly-is-the-vout-field/101016#101016">This</a> question and its answers discussed the meaning and purpose of the vout array of a transaction in good detail. However, I have so far not been able to find any good information about how outputs in <code>vout</code> are ordered.</p>
<p>For example, suppose a collaborative transaction involves two inputs and three outputs, where two of the outputs are change utxos that are sent to the respective parties who owned the inputs, would the 0-index vout always be the non-change output? Alternatively, would it be the highest value output (i.e. outputs are arranged in descending value order)? If neither is accurate, what is the vout ordering logic?</p>
<p>For a general transaction, are there any constraints in Bitcoin's consensus/conventions surrounding the ordering of vouts (and I suppose inputs, while we're on the subject)? I.e. is there a possibility that a transaction could be rejected by nodes for having an 'invalid' vout ordering?</p>

<transactions><consensus><validation>
What is the standard logic behind the ordering of outputs in the vout array for a transaction?
satirn
# What is the standard logic behind the ordering of outputs in the vout array for a transaction?

(Asked by: username_0 on 2021-11-27)

[This](https://bitcoin.stackexchange.com/questions/100997/what-exactly-is-the-vout-field/101016#101016) question and its answers discussed the meaning and purpose of the vout array of a transaction in good detail. However, I have so far not been able to find any good information about how outputs in `vout` are ordered.

For example, suppose a collaborative transaction involves two inputs and three outputs, where two of the outputs are change utxos that are sent to the respective parties who owned the inputs, would the 0-index vout always be the non-change output? Alternatively, would it be the highest value output (i.e. outputs are arranged in descending value order)? If neither is accurate, what is the vout ordering logic?

For a general transaction, are there any constraints in Bitcoin's consensus/conventions surrounding the ordering of vouts (and I suppose inputs, while we're on the subject)? I.e. is there a possibility that a transaction could be rejected by nodes for having an 'invalid' vout ordering?

**Tags:** transactions, consensus, validation


---

## 1 answers

### Answer by username_1 on 2021-11-27. Score: 3 | Accepted answer

For normal transactions¹, there are no constraints on the order of outputs. The general standard seems to be that people randomize all inputs and outputs after assembling their transaction before signing. There is also a Bitcoin Improvement Proposal ([BIP69](https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki)) which suggests a lexicographical order for inputs and outputs. Uniform sorting is meant to help transactions from various wallets look more alike. It is explicitly declared as optional, since it interferes with some other use cases and some respondents considered it worse than just randomized order.

---

¹There are some exceptions, for example if you use the `sighash_single` sighash flag, your input will only commit to the one output with the same index.


---

