There should be no endianness issues here at all.
Bitcoin's handing of endianness is sometimes weird in its human interfaces (e.g. transaction and block hashes are printed in reverse order, because Bitcoin interprets them as little-endian numbers, which then get printed for human consumption in big-endian order). No such issues exist at the binary protocol level, or inside the script interpreter, though.
I compute the Hash160 of the public key you posted correctly, with this Python code (it needs the ripemd160 module, since recent version of Python do not ship with it built-in anymore):
import hashlib
import ripemd160
pubkey = bytes.fromhex("03a6a9b25d8cd811af3162222d5e6ddaf876f915ae37ccb4b4b3f2ba56c39e26d2")
pkhash = ripemd160.ripemd160(hashlib.sha256(pubkey).digest())
print("%s" % pkhash.hex())Output:
$ python3 testhash.py 55391f93c7409df890be2804aa3cf85b22a903c1
I obviously can't tell you what you're doing wrong without seeing the actual code you're using, but it must not be exactly the same as what this code does.
You can get bonuses upto $100 FREE BONUS when you:
💰 Install these recommended apps:
💲 SocialGood - 100% Crypto Back on Everyday Shopping
💲 xPortal - The DeFi For The Next Billion
💲 CryptoTab Browser - Lightweight, fast, and ready to mine!
💰 Register on these recommended exchanges:
🟡 Binance🟡 Bitfinex🟡 Bitmart🟡 Bittrex🟡 Bitget
🟡 CoinEx🟡 Crypto.com🟡 Gate.io🟡 Huobi🟡 Kucoin.
Comments