-1

BIP-69 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 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)?

Improve this question
3
  • 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 ♦
    Mar 8 at 14:42
  • By the way, BIP 69 probably has less adoption than one things at first seeing that “~63% txs are BIP-69 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 ♦
    Mar 8 at 14:49
  • I'm trying to build a use case and minimize interaction steps / data needed to be shared. Specifically, the DLC spec here 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
    Mar 8 at 16:22

1 Answer 1

Reset to default
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.

Improve this answer

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.