Two hashes worked out by hand
Where does the long string in a crypto receipt come from? It can be recomputed by anyone holding the transaction’s raw bytes, and that was done for this entry on November 10, 2026.
The Bitcoin example sits in block 975,283, stamped 10:06:06 UTC. Explorer mempool.space serves the transaction as 222 bytes, which shrink to 113 once the witness section holding the signatures is removed. Hashing those 113 bytes twice with SHA-256, the method the Bitcoin developer reference gives for a TXID, produced a value starting 19f29a5b.
That isn’t what the explorer prints. Read backwards, two characters at a time, it becomes 0bf4c3f9…af219, the ID on the page. The Bitcoin developer glossary calls the flipped form RPC byte order and notes that Bitcoin Core and many block explorers use it.
Ethereum is simpler. A USDC transfer in block 26,383,842, stamped 10:14:11 UTC, came back from a public node as 176 bytes of signed raw data. Their Keccak-256 hash was 0x701c42d8…374f, the exact hash the node listed for the transaction.
Why Bitcoin leaves the signature out
The Bitcoin ID skips the signatures on purpose. BIP 141, the Segregated Witness proposal assigned on December 21, 2015 and now deployed, kept the TXID as the hash of the old format and added a second ID, the wtxid, that includes the witness. For the transaction above the wtxid starts 2afed711.
The reason given is malleability. Since signature data is no longer part of the hash, the proposal says, changes to how a transaction was signed no longer change how it is identified.
Where you see it
Exchanges call it a TXID, transaction ID or hash. On exchange Kraken, according to its support page, it sits behind each entry in the Funding transactions list under Portfolio, with a copy button. Kraken’s ledger export files leave these IDs out, and the Portfolio page shows them for crypto transactions up to three months old.
The same page says the ID retrieves the sending or receiving address, how many confirmations a transaction has and when the funds were sent, which is what a block explorer shows once you paste it in.
Two mistakes with a hash
The first is assuming the ID an exchange shows is the transfer you sent. Kraken’s API notes say that for deposits its txid field “often provided the transaction ID for the transfer to our hot wallet,” the exchange’s own sweep, and users had to look in a separate field for the original. Its newer EVM deposit methods report the customer’s transaction.
The second is treating a hash as proof of payment. Ethereum.org’s transaction guide says the hash is generated first, and only then is the transaction broadcast into a pool of pending ones. It counts as successful once a validator includes it in a block, so a hash can exist for a payment that never arrives. If someone sends you one as proof, look it up yourself and check that it has confirmations.