<p>The txid is the endian reversed value of the transaction hash. Therefore <code>Previous transaction hashes (in reversed byte-order)</code> is the same value as txid.</p>

CC BY-SA 4.0
2023-03-07T07:36:25.483Z
2023-03-07T07:36:25.483Z
Shigeyuki Azuchi
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki" rel="nofollow noreferrer">BIP-69</a> writes the following about how inputs should be ordered:</p>
<pre><code>Previous transaction hashes (in reversed byte-order) are to be sorted in ascending order, lexicographically.
</code></pre>
<p>But then, in the <a href="https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki#examples" rel="nofollow noreferrer">examples</a> section further down, it gives an example of a transaction which, from what I can tell, sorts lexicographically in bigEndian, the typical txid byte order we see in bitcoin-cli, block explorers, etc.</p>
<pre><code>Transaction 0a6a357e2f7796444e02638749d9611c008b253fb55f5dc88b739b230ed0c4c3:

Inputs:

 0: 0e53ec5dfb2cb8a71fec32dc9a634a35b7e24799295ddd5278217822e0b31f57[0]
 1: 26aa6e6d8b9e49bb0630aac301db6757c02e3619feb4ee0eea81eb1672947024[1]
 2: 28e0fdd185542f2c6ea19030b0796051e7772b6026dd5ddccd7a2f93b73e6fc2[0]
 3: 381de9b9ae1a94d9c17f6a08ef9d341a5ce29e2e60c36a52d333ff6203e58d5d[1]
 4: 3b8b2f8efceb60ba78ca8bba206a137f14cb5ea4035e761ee204302d46b98de2[0]
 5: 402b2c02411720bf409eff60d05adad684f135838962823f3614cc657dd7bc0a[1]
 6: 54ffff182965ed0957dba1239c27164ace5a73c9b62a660c74b7b7f15ff61e7a[1]
 7: 643e5f4e66373a57251fb173151e838ccd27d279aca882997e005016bb53d5aa[0]
 8: 6c1d56f31b2de4bfc6aaea28396b333102b1f600da9c6d6149e96ca43f1102b1[1]
 9: 7a1de137cbafb5c70405455c49c5104ca3057a1f1243e6563bb9245c9c88c191[0]
 10: 7d037ceb2ee0dc03e82f17be7935d238b35d1deabf953a892a4507bfbeeb3ba4[1]
 11: a5e899dddb28776ea9ddac0a502316d53a4a3fca607c72f66c470e0412e34086[0]
 12: b4112b8f900a7ca0c8b0e7c4dfad35c6be5f6be46b3458974988e1cdb2fa61b8[0]
 13: bafd65e3c7f3f9fdfdc1ddb026131b278c3be1af90a4a6ffa78c4658f9ec0c85[0]
 14: de0411a1e97484a2804ff1dbde260ac19de841bebad1880c782941aca883b4e9[1]
 15: f0a130a84912d03c1d284974f563c5949ac13f8342b8112edff52971599e6a45[0]
 16: f320832a9d2e2452af63154bc687493484a0e7745ebd3aaf9ca19eb80834ad60[0]
</code></pre>
<p>Am I just confusing &quot;reversed-byte order&quot; to mean little endian when it actually means big Endian (because txids are serialized in little endian in transactions)?</p>

CC BY-SA 4.0
2023-03-08T14:42:37.060Z
Relatedly, I would consider it best practice to shuffle the order of inputs and outputs rather than using BIP 69. There are some applications that cannot use BIP 69, and everyone shuffling inputs and outputs makes them stand out less than if everyone were to sort. If you need a pre-determined order, it would be better to shuffle them based pseudo-randomly per a pre-agreed seed.
Murch
CC BY-SA 4.0
2023-03-08T14:49:03.300Z
By the way, BIP 69 probably has less adoption than one things at first seeing that [“~63% txs are BIP-69 compliant”](https://transactionfee.info/charts/transactions-bip69-compliant/), because the ~24% 1-input-1-output txs are always compliant, and half of the 46% 1-input-2-output are compliant if they’re just shuffling—that’s already 47%. Add a quarter or 2-I-2-O txs, etc. the actual adoption is probably less than 15%.
Murch
CC BY-SA 4.0
2023-03-08T16:22:56.600Z
I'm trying to build a use case and minimize interaction steps / data needed to be shared. Specifically, the DLC spec [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Protocol.md) defines a pre-agreed algorithm like you suggest. But this seems like a waste of data & complexity.  

Your point about privacy does make sense. My specific use case would probably be transparent if it had a 100% adoption rate for BIP69.
Sachin Meier
<bip><endianness>
Does BIP-069 use littleEndian for txid comparison?
Sachin Meier
# Does BIP-069 use littleEndian for txid comparison?

(Asked by: username_0 on 2023-03-07)

[BIP-69](https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki) writes the following about how inputs should be ordered:

```
Previous transaction hashes (in reversed byte-order) are to be sorted in ascending order, lexicographically.

```

But then, in the [examples](https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki#examples) section further down, it gives an example of a transaction which, from what I can tell, sorts lexicographically in bigEndian, the typical txid byte order we see in bitcoin-cli, block explorers, etc.

```
Transaction 0a6a357e2f7796444e02638749d9611c008b253fb55f5dc88b739b230ed0c4c3:

Inputs:

 0: 0e53ec5dfb2cb8a71fec32dc9a634a35b7e24799295ddd5278217822e0b31f57[0]
 1: 26aa6e6d8b9e49bb0630aac301db6757c02e3619feb4ee0eea81eb1672947024[1]
 2: 28e0fdd185542f2c6ea19030b0796051e7772b6026dd5ddccd7a2f93b73e6fc2[0]
 3: 381de9b9ae1a94d9c17f6a08ef9d341a5ce29e2e60c36a52d333ff6203e58d5d[1]
 4: 3b8b2f8efceb60ba78ca8bba206a137f14cb5ea4035e761ee204302d46b98de2[0]
 5: 402b2c02411720bf409eff60d05adad684f135838962823f3614cc657dd7bc0a[1]
 6: 54ffff182965ed0957dba1239c27164ace5a73c9b62a660c74b7b7f15ff61e7a[1]
 7: 643e5f4e66373a57251fb173151e838ccd27d279aca882997e005016bb53d5aa[0]
 8: 6c1d56f31b2de4bfc6aaea28396b333102b1f600da9c6d6149e96ca43f1102b1[1]
 9: 7a1de137cbafb5c70405455c49c5104ca3057a1f1243e6563bb9245c9c88c191[0]
 10: 7d037ceb2ee0dc03e82f17be7935d238b35d1deabf953a892a4507bfbeeb3ba4[1]
 11: a5e899dddb28776ea9ddac0a502316d53a4a3fca607c72f66c470e0412e34086[0]
 12: b4112b8f900a7ca0c8b0e7c4dfad35c6be5f6be46b3458974988e1cdb2fa61b8[0]
 13: bafd65e3c7f3f9fdfdc1ddb026131b278c3be1af90a4a6ffa78c4658f9ec0c85[0]
 14: de0411a1e97484a2804ff1dbde260ac19de841bebad1880c782941aca883b4e9[1]
 15: f0a130a84912d03c1d284974f563c5949ac13f8342b8112edff52971599e6a45[0]
 16: f320832a9d2e2452af63154bc687493484a0e7745ebd3aaf9ca19eb80834ad60[0]

```

Am I just confusing "reversed-byte order" to mean little endian when it actually means big Endian (because txids are serialized in little endian in transactions)?

**Tags:** bip, endianness

> **Comments:**
> **username_1**: Relatedly, I would consider it best practice to shuffle the order of inputs and outputs rather than using BIP 69. There are some applications that cannot use BIP 69, and everyone shuffling inputs and outputs makes them stand out less than if everyone were to sort. If you need a pre-determined order, it would be better to shuffle them based pseudo-randomly per a pre-agreed seed.  
> **username_1**: By the way, BIP 69 probably has less adoption than one things at first seeing that [“~63% txs are BIP-69 compliant”](https://transactionfee.info/charts/transactions-bip69-compliant/), because the ~24% 1-input-1-output txs are always compliant, and half of the 46% 1-input-2-output are compliant if they’re just shuffling—that’s already 47%. Add a quarter or 2-I-2-O txs, etc. the actual adoption is probably less than 15%.  
> **username_0**: I'm trying to build a use case and minimize interaction steps / data needed to be shared. Specifically, the DLC spec [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Protocol.md) defines a pre-agreed algorithm like you suggest. But this seems like a waste of data & complexity.    Your point about privacy does make sense. My specific use case would probably be transparent if it had a 100% adoption rate for BIP69.  

---

## 1 answers

### Answer by username_2 on 2023-03-07. Score: 0

The txid is the endian reversed value of the transaction hash. Therefore `Previous transaction hashes (in reversed byte-order)` is the same value as txid.


---

