summaryrefslogtreecommitdiff
path: root/bip-0069.mediawiki
diff options
context:
space:
mode:
authorDaniel Cousens <github@dcousens.com>2015-08-21 08:47:06 +1000
committerDaniel Cousens <github@dcousens.com>2015-08-21 09:10:00 +1000
commit66cb8346fed16c407b84416923130422bb9c5036 (patch)
tree10a069fdc6a3e300480d628f5b5726736dabb182 /bip-0069.mediawiki
parentd9acdcb6b12cd52424e8fec7cae89eef6bafcad9 (diff)
downloadbips-66cb8346fed16c407b84416923130422bb9c5036.tar.xz
human-readable string representation is big-endian
Diffstat (limited to 'bip-0069.mediawiki')
-rw-r--r--bip-0069.mediawiki2
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki
index d4a9a23..250787c 100644
--- a/bip-0069.mediawiki
+++ b/bip-0069.mediawiki
@@ -92,7 +92,7 @@ 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.
-Hashes of previous transactions are considered for the purposes of this BIP in their little-endian, byte array format in order to match the traditional, human-readable string representation of the hashes.
+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.
A further tie is extremely improbable for the aforementioned reasons.