Skip to content
DonateБГ

Bitcoin from zero

Transactions

Bitcoin transaction structure: the fields of a raw transaction in order, the segwit additions, and one real transaction decoded byte by byte.

By Dimitar Zurnov · Updated 4 Nov 2026
Adapted from Learn Me a Bitcoin by Greg Walker.

A Bitcoin transaction is a string of bytes in a fixed order. It names earlier outputs to spend (its inputs), creates new outputs with their own locks, and can set a locktime. Nodes relay the transaction as raw data and miners include it in that same form, so the layout is the same whichever explorer or wallet shows it to you.

This page sets out every field in order, shows the legacy and segwit layouts, and decodes one real transaction byte by byte.

What does a transaction do?

A transaction does two jobs. It unlocks existing outputs by pointing at them and proving the right to spend. It also locks new outputs to the people who should receive the value.

An output is a package of satoshis with a locking script on it. An input does not hold a value. It names one earlier output, and the value sits in the transaction that created that output. The outputs of a transaction cannot add up to more than its inputs. Whatever is left over becomes the fee, which the miner who includes the transaction collects.

For the plain-English version, read the transaction word page first. The rest of this section is the field-level view.

What are the fields of a raw transaction?

Every transaction is built from the same fields. Some are only present in segwit transactions, as marked below.

Field Size Format What it holds
Version 4 bytes Little-endian The transaction version, such as 01 or 02. Version 2 enables relative locktime.
Marker 1 byte Fixed 00 Segwit only. Says that witness data follows.
Flag 1 byte Fixed 01 today Segwit only. Reserved for future formats.
Input count Variable Compact size How many inputs follow.
Inputs Variable Repeated Each input holds a TXID, a VOUT, a ScriptSig and a sequence.
Output count Variable Compact size How many outputs follow.
Outputs Variable Repeated Each output holds an amount and a ScriptPubKey.
Witness Variable One field per input Segwit only. The unlocking data for segwit inputs.
Locktime 4 bytes Little-endian The earliest block height or time the transaction can be mined.
A legacy transaction is version, inputs, outputs and locktime; segwit adds a marker, a flag and a witness. Version 4 bytes Marker 1 byte, segwit only Flag 1 byte, segwit only Input count compact size Inputs, one set per input TXID 32 bytes, VOUT 4 bytes ScriptSig size and ScriptSig Sequence 4 bytes Output count compact size Outputs, one set per output Amount 8 bytes, then the locking script Witness, one field per input Segwit only: the unlocking data Locktime 4 bytes
Blue fields appear only in segwit transactions. The witness sits after the outputs but belongs to each input.

Inputs and outputs repeat, so a transaction with three inputs has three sets of input fields. The witness is also one field per input, placed after all the outputs.

How are the fields encoded?

Three encodings cover almost every field.

  • Integers are little-endian. The least significant byte comes first, so the amount 100,000,000 is stored as 00e1f50500000000. See little-endian.
  • Counts and sizes use compact size. A value from 0 to 252 takes one byte. Larger values start with FD, FE or FF and then take 2, 4 or 8 bytes, also little-endian. A 25-byte P2PKH script is therefore written as 19 before its bytes. See compact size.
  • Hashes are stored in natural byte order. A TXID is a 32-byte hash, and the raw data holds it reversed compared with the form explorers show. The TXID page explains the flip.

What is the legacy layout?

A legacy transaction has no marker, flag or witness. Its fields run in this order: version, input count, inputs, output count, outputs, locktime. Every transaction created before the segwit upgrade has this layout, and so does any transaction that spends only legacy outputs.

Its TXID is the double SHA-256 of all of its bytes, so a legacy transaction's TXID and wTXID are the same.

How does segwit change the layout?

Segwit, defined in BIP 141, moved the unlocking data for segwit inputs out of the ScriptSig and into a witness field at the end of the transaction. BIP 144 describes how that data is serialized. Segwit went live at block 481,824 in August 2017. The upgrade adds three things:

  1. A marker byte 00 and a flag byte 01 straight after the version.
  2. A witness field for every input, after the outputs and before the locktime. An input that needs no witness still gets an empty one, a single 00.
  3. Nothing else changes in the inputs or outputs.

Segwit also changed how size is measured. The witness counts for less, so a segwit transaction pays less per byte of signature data. Bitcoin measures this in weight units: each non-witness byte counts four times and each witness byte counts once. Divide the weight by four and you get the virtual byte size that fees are based on.

Take the segwit transaction f8c24461e0a08ede06539433affaba93e303ca9929c300cfc00a8929e8025a80 as an example. It is 222 bytes in total. 113 of those bytes sit outside the witness, and the other 109 are the marker, the flag and the witness. Its weight is 113 × 4 + 109 = 561, and its virtual size is 141 vB, rounded up from 140.25.

What does one real transaction look like?

The transaction 251490baffd0d3d5175b77bf334ba866c4fd416fcc686a1001e188fba83b4ccb is a legacy transaction. It has one input, two outputs and 258 bytes. You can open it on our explorer at /tx/251490baffd0d3d5175b77bf334ba866c4fd416fcc686a1001e188fba83b4ccb. Here is its raw data:

010000000110ddd830599b17cc690535f7df28a84466eaca3c22f0d55b79023b6570f4fbc5010000008b483045022100e6186d6f344ce4df46b2e15d87093d34edbf5b50462b6b45f9bd499a6a62fbc4022055f56a1c4a24ea6be61564593c4196b47478a25cf596c1baf59f5a9a229b637c014104a41e997b6656bc4f5dd1f9b9df3b4884cbec254d3b71d928587695b0df0a80417432f4ca6276bc620b1f04308e82e70015a40f597d8260912f801e4b62ab089effffffff0200e9c829010000001976a9146f34d3811aded1df870359f311c2a11a015e945388ac00e40b54020000001976a91470d6734de69c1ac8913892f2df9be0e738d26c2d88ac00000000

Read it from the start, one field at a time. Offsets count from zero.

Offset Bytes Field Raw hex Meaning
0 to 3 4 Version 01000000 Version 1
4 1 Input count 01 One input
5 to 36 32 Input TXID 10ddd830…70f4fbc5 The earlier transaction, in natural byte order
37 to 40 4 VOUT 01000000 Output 1 of that transaction
41 1 ScriptSig size 8b 139 bytes
42 to 180 139 ScriptSig 483045…637c01 4104…89e A 72-byte signature with its sighash byte, then a 65-byte public key
181 to 184 4 Sequence ffffffff Final, with no locktime and no RBF
185 1 Output count 02 Two outputs
186 to 193 8 Amount 0 00e9c82901000000 4,996,000,000 satoshis (49.96 BTC)
194 1 ScriptPubKey size 19 25 bytes
195 to 219 25 ScriptPubKey 0 76a914…88ac P2PKH lock
220 to 227 8 Amount 1 00e40b5402000000 10,000,000,000 satoshis (100 BTC)
228 1 ScriptPubKey size 19 25 bytes
229 to 253 25 ScriptPubKey 1 76a914…88ac P2PKH lock
254 to 257 4 Locktime 00000000 No locktime

The table has the 258 bytes accounted for: 4 + 1 + 32 + 4 + 1 + 139 + 4 + 1 + 8 + 1 + 25 + 8 + 1 + 25 + 4. Every byte of it belongs to one field.

The 258 bytes of one legacy transaction, one cell per byte, coloured by field: the signature in the input is the largest block. byte 0 byte 1 byte 2 byte 3 byte 4 byte 5 byte 6 byte 7 byte 8 byte 9 byte 10 byte 11 byte 12 byte 13 byte 14 byte 15 byte 16 byte 17 byte 18 byte 19 byte 20 byte 21 byte 22 byte 23 byte 24 byte 25 byte 26 byte 27 byte 28 byte 29 byte 30 byte 31 byte 32 byte 33 byte 34 byte 35 byte 36 byte 37 byte 38 byte 39 byte 40 byte 41 byte 42 byte 43 byte 44 byte 45 byte 46 byte 47 byte 48 byte 49 byte 50 byte 51 byte 52 byte 53 byte 54 byte 55 byte 56 byte 57 byte 58 byte 59 byte 60 byte 61 byte 62 byte 63 byte 64 byte 65 byte 66 byte 67 byte 68 byte 69 byte 70 byte 71 byte 72 byte 73 byte 74 byte 75 byte 76 byte 77 byte 78 byte 79 byte 80 byte 81 byte 82 byte 83 byte 84 byte 85 byte 86 byte 87 byte 88 byte 89 byte 90 byte 91 byte 92 byte 93 byte 94 byte 95 byte 96 byte 97 byte 98 byte 99 byte 100 byte 101 byte 102 byte 103 byte 104 byte 105 byte 106 byte 107 byte 108 byte 109 byte 110 byte 111 byte 112 byte 113 byte 114 byte 115 byte 116 byte 117 byte 118 byte 119 byte 120 byte 121 byte 122 byte 123 byte 124 byte 125 byte 126 byte 127 byte 128 byte 129 byte 130 byte 131 byte 132 byte 133 byte 134 byte 135 byte 136 byte 137 byte 138 byte 139 byte 140 byte 141 byte 142 byte 143 byte 144 byte 145 byte 146 byte 147 byte 148 byte 149 byte 150 byte 151 byte 152 byte 153 byte 154 byte 155 byte 156 byte 157 byte 158 byte 159 byte 160 byte 161 byte 162 byte 163 byte 164 byte 165 byte 166 byte 167 byte 168 byte 169 byte 170 byte 171 byte 172 byte 173 byte 174 byte 175 byte 176 byte 177 byte 178 byte 179 byte 180 byte 181 byte 182 byte 183 byte 184 byte 185 byte 186 byte 187 byte 188 byte 189 byte 190 byte 191 byte 192 byte 193 byte 194 byte 195 byte 196 byte 197 byte 198 byte 199 byte 200 byte 201 byte 202 byte 203 byte 204 byte 205 byte 206 byte 207 byte 208 byte 209 byte 210 byte 211 byte 212 byte 213 byte 214 byte 215 byte 216 byte 217 byte 218 byte 219 byte 220 byte 221 byte 222 byte 223 byte 224 byte 225 byte 226 byte 227 byte 228 byte 229 byte 230 byte 231 byte 232 byte 233 byte 234 byte 235 byte 236 byte 237 byte 238 byte 239 byte 240 byte 241 byte 242 byte 243 byte 244 byte 245 byte 246 byte 247 byte 248 byte 249 byte 250 byte 251 byte 252 byte 253 byte 254 byte 255 byte 256 byte 257 Fixed fields: version, counts, sizes, locktime Input references: TXID, VOUT and sequence ScriptSig: signature and public key, 139 bytes Outputs: amounts and locking scripts
One cell for each of the 258 bytes. Orange is the unlocking code, which is 139 bytes on its own.

Two things stand out. The signature and public key take 139 of the 258 bytes, which is why legacy transactions are large. And the input's value is not in the transaction at all. To learn what the input held, you open the transaction that created the output it spends. Its TXID, computed from these same bytes, is covered on the TXID page.

Which pages cover each field?

Read the pages in this order. Each one covers a field in more detail than this overview.

  1. Input: what an input is and the fields it holds.
  2. TXID: the hash that names an earlier transaction.
  3. VOUT: the index of the output being spent.
  4. ScriptSig: the unlocking code in legacy inputs.
  5. Sequence: finality, RBF and relative locktime.
  6. Output: the amount and the lock on each new output.
  7. ScriptPubKey: the locking code itself.
  8. Witness: the unlocking data for segwit inputs.
  9. Locktime: the height or time before which a transaction cannot be mined.
  10. wTXID: the hash that includes the witness.
  11. UTXO: the outputs nobody has spent yet.
  12. Fee: what is left over after the outputs.
  13. Size: bytes, weight and virtual bytes.
  14. PSBT: the format for passing a transaction between signers.

Sources

In this section

  1. 1InputBitcoin transaction inputs explained: an input names an earlier output by TXID and VOUT, then unlocks it. Learn its five fields, sizes and examples.
  2. 2TXIDA Bitcoin TXID is the double SHA-256 hash of a transaction, shown reversed on explorers. Learn how it is built and how segwit changes it.
  3. 3VOUTA Bitcoin VOUT is the index of the output an input spends, counted from 0 and stored as 4 little-endian bytes. Learn how it pairs with a TXID.
  4. 4ScriptSigA Bitcoin ScriptSig is the unlocking code in a legacy transaction input. Learn how it holds a signature and public key, and how coinbase and P2SH differ.
  5. 5SequenceA Bitcoin sequence number is the 4-byte input field that sets locktime, replace-by-fee (RBF) and relative locktime. See its values and bit layout.
  6. 6OutputBitcoin transaction outputs hold an amount in satoshis and a lock. Learn the three fields, the 8-byte amount format, the 21 million BTC cap and change.
  7. 7ScriptPubKeyA Bitcoin scriptPubKey is the locking code on a transaction output. Learn the common templates, their byte sizes and how each lock is unlocked.
  8. 8WitnessBitcoin witness data holds the signatures and public keys that unlock each SegWit input. Learn its layout, a real example and why it weighs less.
  9. 9LocktimeBitcoin locktime is a 4-byte field that stops a transaction from being mined before a block height or a time. Learn how it is stored and enforced.
  10. 10wTXIDA bitcoin wTXID is a transaction's hash with its witness data included. Learn how it differs from the TXID and where blocks commit to it.
  11. 11UTXOA bitcoin UTXO is an unspent transaction output. Learn how the UTXO set lets nodes check transactions and count the balance of an address.
  12. 12FeeHow bitcoin transaction fees work: the fee is the inputs minus the outputs, and the fee rate in sat/vB decides which transactions a miner includes.
  13. 13SizeBitcoin transaction size is counted in bytes, weight units and virtual bytes. Learn how the weight formula and the 4,000,000 weight unit limit work.
  14. 14PSBTA PSBT, or partially signed Bitcoin transaction, carries an unsigned transaction and its signing data between wallets. Learn its BIP 174 format.

Something look wrong? Tell us