sort by prevTxHash in little-endian, descending order, lexicographically

1 files changed, 2 insertions, 3 deletions

diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki
index 250787c..85e3fdd 100644
--- a/bip-0069.mediawiki
+++ b/bip-0069.mediawiki
@@ -92,9 +92,8 @@ N.B. These comparisons do not need to operate in constant time since they are no
 For sorting inputs, the hash of the previous transaction and the output index within that transaction are sufficient for sorting purposes; each transaction hash has an extremely high probability of being unique in the blockchain — this is enforced for coinbase transactions by BIP30 — and output indices within a transaction are unique.
 For the sake of efficiency, transaction hashes should be compared first before output indices, since output indices from different transactions are often equivalent, while all bytes of the transaction hash are effectively random variables.
 
-Previous transaction hashes are considered for the purposes of this BIP in their big-endian, byte array format in order to match the human-readable string representation of the hashes.
-They must be sorted in accordance with the output of the bytearr_cmp() function above: the hash with the earliest lesser byte is ordered first, and shorter hashes are ordered before longer ones as a tie-breaker.
-In the event of two matching transaction hashes, output indices will be compared based on their integer value, with the smaller value ordered first.
+Previous transaction hashes (in their little-endian, byte-array form) are to be sorted in descending order, lexicographically.
+In the event of two matching transaction hashes, the respective output indices will be compared by their integer value, in ascending order.
 A further tie is extremely improbable for the aforementioned reasons.
 
 Because the hash of previous transactions and output indices must be included in a signed transaction, wallet clients capable of signing transactions will necessarily have access to this data.