Update bip-0352.mediawiki

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>

bip-0352.mediawiki

@@ -135,7 +135,7 @@ This gives Bob an alternative to using BIP32 for managing change, while still al
 
 We use the following functions and conventions:
 
-* ''outpoint'' (36 bytes): the <code>COutPoint</code> of an input (32-byte txid, least significant byte first || 4-byte vout, least significant byte first)<ref name="why_little_endian">'''Why are outpoints little-endian?''' Despite using big endian throughout the rest of the BIP, outpoints are sorted and hashed matching their transaction serialization, which is little-endian. This allows a wallet to parse a serialized transaction for use in silent payments without needing to re-order the bytes when compute the outpoint hash. Note: despite outpoints being stored and serialized as little-endian, the transaction hash (txid) is always displayed as big-endian.</ref>
+* ''outpoint'' (36 bytes): the <code>COutPoint</code> of an input (32-byte txid, least significant byte first || 4-byte vout, least significant byte first)<ref name="why_little_endian">'''Why are outpoints little-endian?''' Despite using big endian throughout the rest of the BIP, outpoints are sorted and hashed matching their transaction serialization, which is little-endian. This allows a wallet to parse a serialized transaction for use in silent payments without needing to re-order the bytes when computing the outpoint hash. Note: despite outpoints being stored and serialized as little-endian, the transaction hash (txid) is always displayed as big-endian.</ref>
 * sort<sub>outpoints</sub>(v): sorts a vector ''v'' of ''outpoints'' in ascending order by doing a byte by byte comparison lexicographically.
 * ser<sub>32</sub>(i): serializes a 32-bit unsigned integer ''i'' as a 4-byte sequence, most significant byte first.
 * ser<sub>256</sub>(p): serializes the integer p as a 32-byte sequence, most significant byte first.