Serialized transaction

Everything friendly about a transaction, the addresses, the amounts in your local currency, the labels, is decoration your wallet adds. What actually travels is a compact binary blob, typically 200 to 250 bytes for a simple payment, and it is fully self contained. Copy that hex from an offline computer to any online one and the payment can be broadcast from there.

How it works

Serialization is a fixed order with no field names, so parsers rely entirely on position and on length prefixes.

The blob opens with the four byte version. Segregated witness transactions then insert two flag bytes, 0x00 and 0x01, which older parsers would read as a transaction with zero inputs and therefore reject, a deliberate trick that let the new format coexist with the old. Next comes the input count as a compactSize integer, then each input: 36 bytes naming the coin being spent, a length prefixed unlocking script, and a four byte sequence number. The output count follows, then each output as an eight byte amount in satoshis plus a length prefixed locking script. Witness data, when present, sits near the end, and the final four bytes are always the locktime.

Numbers are stored little endian, smallest byte first, which is why an amount of 100,000 satoshis appears in the hex as a0 86 01 00 00 00 00 00. Hashes are stored in internal byte order, the reverse of what an explorer shows you, so transaction ids inside a raw blob look backwards.

Two hashes come out of this one structure. The transaction id is a double SHA-256 over the serialization with the marker, flag and witness stripped out, which is what makes signatures immune to being mangled after the fact. The witness transaction id, defined in BIP141, hashes the whole thing including the witness, and nodes use it for relay bookkeeping. A one input, two output native SegWit payment serializes to about 222 raw bytes and counts as roughly 141 virtual bytes, because the witness portion is discounted.

Where you see it

The raw form surfaces the moment you step outside a single app, which for most people means signing offline or rescuing a payment.

Hardware wallets and air-gapped setups export a finished transaction as hex or as a QR code holding the same bytes, and you paste it into the broadcast form on a block explorer to send it. Bitcoin Core's command line uses it in both directions: createrawtransaction and signrawtransactionwithwallet produce hex, decoderawtransaction turns hex back into readable JSON, and sendrawtransaction puts it on the network. Support tickets often ask for the raw hex rather than the transaction id, because the hex proves what the transaction contains rather than just naming it.

One safety note. A signed raw transaction is bearer information: anyone who has the hex can broadcast it, and nothing about it is confidential. Do not paste one into a public forum while asking for help unless you are content for the payment to be made.

Serialized transaction vs transaction id

The serialized transaction is the document; the transaction id is its file name. One is a few hundred bytes of hex that can run to five hundred characters on screen, and the other is always exactly 64 hexadecimal characters.

People mix them up because both look like long strings of hex. The test is length and what the string can do. A 64 character string can be looked up on an explorer and nothing else. A longer string can be decoded into fields, and if it is fully signed it can be broadcast by anyone who holds it, including a stranger you sent it to.