<h2>Transaction structure after introduction of Segwit</h2>
<p>In an answer to <a href="https://bitcoin.stackexchange.com/q/113631/13866">In what format does a block store the transaction data?</a> I gave an example of hand decoding  the structure of the earliest Bitcoin transactions from a hex dump.</p>
<p>A Segwit transaction adds some fields that are an optional part of the transaction structure. In non-Segwit transactions, those Segwit fields are absent (have zero length).</p>
<p>The first such optional field is the witness flag just after the version number</p>
<p>The second optional field is the witness data just before the final lock-time field. The witness data has one witness for each input in the transaction. The signature script (unlocking script) in each input is empty because that data is now placed in a witness. Each witness can have several components.</p>
<blockquote>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Field Size</th>
<th>Description</th>
<th>Data type</th>
<th>Comments</th>
</tr>
</thead>
<tbody>
<tr>
<td>4</td>
<td>version</td>
<td>uint32_t</td>
<td></td>
</tr>
<tr>
<td><strong>0</strong> or 2</td>
<td>flag</td>
<td><strong>optional</strong>  uint8_t[2]</td>
<td>If present, always 0001, and indicates the presence of witness data</td>
</tr>
<tr>
<td>1+</td>
<td>tx_in count</td>
<td>var_int</td>
<td></td>
</tr>
<tr>
<td>...</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td><strong>0+</strong></td>
<td>tx_witnesses</td>
<td>tx_witness[]</td>
<td>A list of witnesses, one for each input; <strong>omitted if flag is omitted above</strong></td>
</tr>
<tr>
<td>4 lock_time</td>
<td>uint32_t</td>
<td>...</td>
<td></td>
</tr>
</tbody>
</table>
</div></blockquote>
<p>So any parser has to look at 2 bytes following the version number and decide if it is a segwit flag (0x0001 big-endian!) or a tx_in_count varint and maybe part of a tx_in structure.</p>
<hr />
<h2>Example of decoding from hex a Segwit transaction</h2>
<p>Just for fun, a randomly chosen example, transaction b0dce2eccbd85f9391e108c8f8f3735cc7b9e6a30f13f82a7fdfaa090d4d093c</p>
<p><code>0200000000010179</code> <code>aaafbe7c9d3b0812</code> <code>a489facaf77508c0</code> <code>8c190ec7dfd82f12</code> <code>9aeb995aca23ab00</code> <code>00000000fdffffff</code> <code>020bd21900000000</code> <code>00160014d2caa7b0</code> <code>8db89cd62c9af34d</code> <code>a53332d30e53bb15</code> <code>98151b0000000000</code> <code>1600143d4427468c</code> <code>be7ae396427a1aa9</code> <code>128fa05b18c7db02</code> <code>4730440220573fd2</code> <code>7574cfdde4843476</code> <code>21e1f48f85ae975c</code> <code>b8c2265a04496ded</code> <code>038896822302204a</code> <code>5e04a3a2d160c315</code> <code>8caa39b58bfc91ac</code> <code>64c484078ec0225a</code> <code>7d4d2d4454661f01</code> <code>2103d96e3819b522</code> <code>45e42c76f869c9a8</code> <code>75f6ea5344cf1aee</code> <code>2e6b3ab03adcfef0</code> <code>d80ede3b0b00</code></p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Hex Data</th>
<th>Type</th>
<th>Meaning</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>02000000</code></td>
<td>uint32</td>
<td>version 2</td>
</tr>
<tr>
<td><code>0001</code></td>
<td>2 octets</td>
<td>witness flag</td>
</tr>
<tr>
<td><code>01</code></td>
<td>varint</td>
<td>count of transaction inputs</td>
</tr>
<tr>
<td>Input 1</td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>79aaafbe7c9d3b08</code> <code>12a489facaf77508</code> <code>c08c190ec7dfd82f</code> <code>129aeb995aca23ab</code></td>
<td>32 octets</td>
<td>Hash of referenced Tx</td>
</tr>
<tr>
<td><code>00000000</code></td>
<td>uint32</td>
<td>index of previous output</td>
</tr>
<tr>
<td><code>00</code></td>
<td>varint</td>
<td>length of signature script (0 because segwit?)</td>
</tr>
<tr>
<td><code>fdffffff</code></td>
<td>4 octets</td>
<td>Sequence (n.b. RBF)</td>
</tr>
<tr>
<td><code>02</code></td>
<td>varint</td>
<td>Count of transaction outputs</td>
</tr>
<tr>
<td>Output 1</td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>0bd2190000000000</code></td>
<td>int64</td>
<td>Amount in Satoshi (0.01692171 BTC)</td>
</tr>
<tr>
<td><code>16</code></td>
<td>varint</td>
<td>length of script (0x16 = 22)</td>
</tr>
<tr>
<td><code>0014d2caa7b08db8</code> <code>9cd62c9af34da533</code> <code>32d30e53bb15</code></td>
<td>22 octets</td>
<td>locking script</td>
</tr>
<tr>
<td>Output 2</td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>98151b0000000000</code></td>
<td>int64</td>
<td>Amount in Satoshi</td>
</tr>
<tr>
<td><code>16</code></td>
<td>varint</td>
<td>length of script (0x16 = 22)</td>
</tr>
<tr>
<td><code>00143d4427468cbe</code> <code>7ae396427a1aa912</code> <code>8fa05b18c7db</code></td>
<td>22 octets</td>
<td>locking script</td>
</tr>
<tr>
<td>Witness data</td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>02</code></td>
<td>varint</td>
<td>Count of witness components</td>
</tr>
<tr>
<td>Witness component 1</td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>47</code></td>
<td>varint</td>
<td>Length of witness component (0x47 = 71)</td>
</tr>
<tr>
<td><code>30440220573fd275</code> <code>74cfdde484347621</code> <code>e1f48f85ae975cb8</code> <code>c2265a04496ded03</code> <code>8896822302204a5e</code> <code>04a3a2d160c3158c</code> <code>aa39b58bfc91ac64</code> <code>c484078ec0225a7d</code> <code>4d2d4454661f01</code></td>
<td>71 octets</td>
<td>Witness data. The length and the initial bytes reveal that this is a signature. See also <a href="https://bitcoin.stackexchange.com/q/107872/13866">witness contents for each tx output type</a></td>
</tr>
<tr>
<td>Witness component 2</td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>21</code></td>
<td>varint</td>
<td>Length of witness component (0x21 = 33)</td>
</tr>
<tr>
<td><code>03d96e3819b52245</code> <code>e42c76f869c9a875</code> <code>f6ea5344cf1aee2e</code> <code>6b3ab03adcfef0d8</code> <code>0e</code></td>
<td>33 octets</td>
<td>Witness data. Length is consistent with public key and that is what P2WPKH expects here.</td>
</tr>
<tr>
<td><code>de3b0b00</code></td>
<td>unit32</td>
<td>Lock time: 000b3bde = block 736222</td>
</tr>
</tbody>
</table>
</div>
<p>This transaction appears as the 9th in block 736223</p>
<hr />
<h2>Notes</h2>
<p><strong>Transaction-IDs</strong></p>
<p>A Transaction ID is a hash of most of the transaction data. It is usually used by nodes as a retrieval index into a stored list of earlier transactions.</p>
<p>This is what is shown above as &quot;Hash of referenced Tx&quot;.</p>
<p><strong>Addresses</strong></p>
<p>Note that a transaction does not contain Bitcoin addresses. In particular it does not contain sending addresses and amounts. What it cointains is a pointer to an unspent ouput of an earlier transaction, a pointer to a UTXO. The pointer takes the form of the Transaction-ID of the earlier transaction and an index number of the outputs of that transaction. For example it might say this transaction spends the first (index <code>0</code>) output created in the earlier transaction with hash (TXID) <code>79...ab</code>.</p>
<p>Blockchain explorers will typically follow that pointer, get amounts and other details from the earlier transaction outputs, calculate the sending addresses and present that information as if it were part of this transaction even though it isn't.</p>
<p>Bitcoin addresses can be regarded as a kind of abstract of a script. An address is a way for a payee to provide a payer with the information needed by the payer to create a locking-script in a transaction that pays the payee.</p>
<p><strong>Endianness</strong></p>
<p>We see that version 2 is shown in hex as <code>02000000</code>. This is because the Bitcoin network protocols mostly use <a href="https://en.wikipedia.org/wiki/Endianness" rel="nofollow noreferrer">little-endian</a> byte ordering rather than the big-endian byte-ordering that most of us find more natural.</p>
<p><code>02000000</code> little endian is <code>00000002</code> big endian. You just reverse the order of the bytes remembering that one byte is two hex digits. So you reverse the pairs of digits (not individual digits).</p>
<p><strong>Witness components</strong></p>
<p>SegWit is short for Segregated Witness. It was a change that separated (segregated) certain data into a separate part of the transaction.</p>
<p>The input count is also a count of witnesses (if Segwit flag is set). Each witness starts with a count of witness components.</p>
<p>The witness components are things like digital-signatures that would have been part of the unlocking scripts in pre-segwit transactions.</p>
<p>The exact meaning depends on the transaction output type, which is determined by inspecting the locking script on the earlier transaction whose output is being spent as an input in this transaction.</p>
<p>See <a href="https://bitcoin.stackexchange.com/q/107872/13866">list of witness contents for each output type</a></p>
<p><strong>Scripts</strong></p>
<p>The <em>locking script</em> and the <em>unlocking script</em> are tiny programs written in the <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">Bitcoin scripting language</a> - which is specially designed to be simple enough that it can't be used to make attacks on the Bitcoin network.</p>
<p>Sometimes other names are used such as <em>ScriptSig</em> (signature script) or <em>ScriptPubKey</em> (public key script) - but these names are historical and are somewhat inappropriate names for the standard scripts in newer types of transaction outputs.</p>
<hr />
<h2>Related questions with relevant answers</h2>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/114108/13866">What are the components of the raw block shown in this image?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/113631/13866">In what format does a block store the transaction data?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/107944/13866">How can I get the destination address from raw transaction data?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/111098/13866">What is the script assembly and execution in P2TR spend (spend from Taproot)</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/118988/13866">How to differentiate between BTC transactions and BRC20 transactions on a blockchain?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/107872/13866">What are the scriptPubKey, scriptSig, redeem script and witness for the various output types?</a></li>
</ul>

CC BY-SA 4.0
2022-06-29T10:18:12.523Z
I have added some notes about the reference transaction and wallet addresses.
RedGrittyBrick
CC BY-SA 4.0
2023-07-23T04:04:01.710Z
I would add that there is one witness field **per input**, so if the tx has three inputs, then after the output fields, will be 3 witness fields.
Zenul_Abidin
CC BY-SA 4.0
2023-07-23T08:34:30.193Z
Hello Zenul - My answer does already say **"A list of witnesses, one for each input;"**  - However I have added a longer explanation to make it clearer.
RedGrittyBrick
CC BY-SA 4.0
2022-05-14T02:41:13.603Z
Thanks for the super great answer, however, what is the Hash of the reference transaction and in which component are the wallet-addresses stored for the transaction?
Jamo
CC BY-SA 4.0
2022-05-13T14:01:00.323Z
2023-10-20T10:32:16.167Z
2023-10-20T10:32:16.167Z
RedGrittyBrick
<p>I know that pre-segwit transactions looked like the following (This is the hash of the transaction in block 170 - the 10000 bitcoin pizza exchange):</p>
<p>0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704000000004847304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901ffffffff0200ca9a3b00000000434104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac00286bee0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000</p>
<p>However, is this the way all transactions are structured? If not, how do they look (I'm assuming they use segwit)?</p>

CC BY-SA 4.0
2022-05-13T13:07:21.007Z
This is not a hash of a transaction. This is a transaction itself, in hex format.
Pieter Wuille
CC BY-SA 4.0
2022-05-13T13:16:57.500Z
You may find https://learnmeabitcoin.com/technical/transaction-data interesting
Murch
CC BY-SA 4.0
2022-05-13T14:43:26.997Z
The Pizza transaction is in [block 57043](https://blockchair.com/bitcoin/block/57043) not 170.  That is believed to be the first commercial transaction in which actual goods were purchased using Bitcoin. Block 170 is the first payment from one person to another and was a gift, not a purchase.
RedGrittyBrick
<transactions><segregated-witness><serialization>
What are the parts of a Bitcoin transaction in segwit format?
Jamo
# What are the parts of a Bitcoin transaction in segwit format?

(Asked by: username_0 on 2022-05-13)

I know that pre-segwit transactions looked like the following (This is the hash of the transaction in block 170 - the 10000 bitcoin pizza exchange):

0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704000000004847304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901ffffffff0200ca9a3b00000000434104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac00286bee0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000

However, is this the way all transactions are structured? If not, how do they look (I'm assuming they use segwit)?

**Tags:** transactions, segregated-witness, serialization

> **Comments:**
> **username_1**: This is not a hash of a transaction. This is a transaction itself, in hex format.  
> **username_2**: You may find https://learnmeabitcoin.com/technical/transaction-data interesting  
> **username_3**: The Pizza transaction is in [block 57043](https://blockchair.com/bitcoin/block/57043) not 170.  That is believed to be the first commercial transaction in which actual goods were purchased using Bitcoin. Block 170 is the first payment from one person to another and was a gift, not a purchase.  

---

## 1 answers

### Answer by username_3 on 2022-05-13. Score: 3 | Accepted answer

## Transaction structure after introduction of Segwit

In an answer to [In what format does a block store the transaction data?](https://bitcoin.stackexchange.com/q/113631/13866) I gave an example of hand decoding the structure of the earliest Bitcoin transactions from a hex dump.

A Segwit transaction adds some fields that are an optional part of the transaction structure. In non-Segwit transactions, those Segwit fields are absent (have zero length).

The first such optional field is the witness flag just after the version number

The second optional field is the witness data just before the final lock-time field. The witness data has one witness for each input in the transaction. The signature script (unlocking script) in each input is empty because that data is now placed in a witness. Each witness can have several components.

> | Field Size | Description | Data type | Comments |
> | --- | --- | --- | --- |
> | 4 | version | uint32\_t |  |
> | **0** or 2 | flag | **optional** uint8\_t[2] | If present, always 0001, and indicates the presence of witness data |
> | 1+ | tx\_in count | var\_int |  |
> | ... |  |  |  |
> | **0+** | tx\_witnesses | tx\_witness[] | A list of witnesses, one for each input; **omitted if flag is omitted above** |
> | 4 lock\_time | uint32\_t | ... |  |

So any parser has to look at 2 bytes following the version number and decide if it is a segwit flag (0x0001 big-endian!) or a tx\_in\_count varint and maybe part of a tx\_in structure.

---

## Example of decoding from hex a Segwit transaction

Just for fun, a randomly chosen example, transaction b0dce2eccbd85f9391e108c8f8f3735cc7b9e6a30f13f82a7fdfaa090d4d093c

`0200000000010179` `aaafbe7c9d3b0812` `a489facaf77508c0` `8c190ec7dfd82f12` `9aeb995aca23ab00` `00000000fdffffff` `020bd21900000000` `00160014d2caa7b0` `8db89cd62c9af34d` `a53332d30e53bb15` `98151b0000000000` `1600143d4427468c` `be7ae396427a1aa9` `128fa05b18c7db02` `4730440220573fd2` `7574cfdde4843476` `21e1f48f85ae975c` `b8c2265a04496ded` `038896822302204a` `5e04a3a2d160c315` `8caa39b58bfc91ac` `64c484078ec0225a` `7d4d2d4454661f01` `2103d96e3819b522` `45e42c76f869c9a8` `75f6ea5344cf1aee` `2e6b3ab03adcfef0` `d80ede3b0b00`

| Hex Data | Type | Meaning |
| --- | --- | --- |
| `02000000` | uint32 | version 2 |
| `0001` | 2 octets | witness flag |
| `01` | varint | count of transaction inputs |
| Input 1 |  |  |
| `79aaafbe7c9d3b08` `12a489facaf77508` `c08c190ec7dfd82f` `129aeb995aca23ab` | 32 octets | Hash of referenced Tx |
| `00000000` | uint32 | index of previous output |
| `00` | varint | length of signature script (0 because segwit?) |
| `fdffffff` | 4 octets | Sequence (n.b. RBF) |
| `02` | varint | Count of transaction outputs |
| Output 1 |  |  |
| `0bd2190000000000` | int64 | Amount in Satoshi (0.01692171 BTC) |
| `16` | varint | length of script (0x16 = 22) |
| `0014d2caa7b08db8` `9cd62c9af34da533` `32d30e53bb15` | 22 octets | locking script |
| Output 2 |  |  |
| `98151b0000000000` | int64 | Amount in Satoshi |
| `16` | varint | length of script (0x16 = 22) |
| `00143d4427468cbe` `7ae396427a1aa912` `8fa05b18c7db` | 22 octets | locking script |
| Witness data |  |  |
| `02` | varint | Count of witness components |
| Witness component 1 |  |  |
| `47` | varint | Length of witness component (0x47 = 71) |
| `30440220573fd275` `74cfdde484347621` `e1f48f85ae975cb8` `c2265a04496ded03` `8896822302204a5e` `04a3a2d160c3158c` `aa39b58bfc91ac64` `c484078ec0225a7d` `4d2d4454661f01` | 71 octets | Witness data. The length and the initial bytes reveal that this is a signature. See also [witness contents for each tx output type](https://bitcoin.stackexchange.com/q/107872/13866) |
| Witness component 2 |  |  |
| `21` | varint | Length of witness component (0x21 = 33) |
| `03d96e3819b52245` `e42c76f869c9a875` `f6ea5344cf1aee2e` `6b3ab03adcfef0d8` `0e` | 33 octets | Witness data. Length is consistent with public key and that is what P2WPKH expects here. |
| `de3b0b00` | unit32 | Lock time: 000b3bde = block 736222 |

This transaction appears as the 9th in block 736223

---

## Notes

**Transaction-IDs**

A Transaction ID is a hash of most of the transaction data. It is usually used by nodes as a retrieval index into a stored list of earlier transactions.

This is what is shown above as "Hash of referenced Tx".

**Addresses**

Note that a transaction does not contain Bitcoin addresses. In particular it does not contain sending addresses and amounts. What it cointains is a pointer to an unspent ouput of an earlier transaction, a pointer to a UTXO. The pointer takes the form of the Transaction-ID of the earlier transaction and an index number of the outputs of that transaction. For example it might say this transaction spends the first (index `0`) output created in the earlier transaction with hash (TXID) `79...ab`.

Blockchain explorers will typically follow that pointer, get amounts and other details from the earlier transaction outputs, calculate the sending addresses and present that information as if it were part of this transaction even though it isn't.

Bitcoin addresses can be regarded as a kind of abstract of a script. An address is a way for a payee to provide a payer with the information needed by the payer to create a locking-script in a transaction that pays the payee.

**Endianness**

We see that version 2 is shown in hex as `02000000`. This is because the Bitcoin network protocols mostly use [little-endian](https://en.wikipedia.org/wiki/Endianness) byte ordering rather than the big-endian byte-ordering that most of us find more natural.

`02000000` little endian is `00000002` big endian. You just reverse the order of the bytes remembering that one byte is two hex digits. So you reverse the pairs of digits (not individual digits).

**Witness components**

SegWit is short for Segregated Witness. It was a change that separated (segregated) certain data into a separate part of the transaction.

The input count is also a count of witnesses (if Segwit flag is set). Each witness starts with a count of witness components.

The witness components are things like digital-signatures that would have been part of the unlocking scripts in pre-segwit transactions.

The exact meaning depends on the transaction output type, which is determined by inspecting the locking script on the earlier transaction whose output is being spent as an input in this transaction.

See [list of witness contents for each output type](https://bitcoin.stackexchange.com/q/107872/13866)

**Scripts**

The *locking script* and the *unlocking script* are tiny programs written in the [Bitcoin scripting language](https://en.bitcoin.it/wiki/Script) - which is specially designed to be simple enough that it can't be used to make attacks on the Bitcoin network.

Sometimes other names are used such as *ScriptSig* (signature script) or *ScriptPubKey* (public key script) - but these names are historical and are somewhat inappropriate names for the standard scripts in newer types of transaction outputs.

---

## Related questions with relevant answers

* [What are the components of the raw block shown in this image?](https://bitcoin.stackexchange.com/q/114108/13866)
* [In what format does a block store the transaction data?](https://bitcoin.stackexchange.com/q/113631/13866)
* [How can I get the destination address from raw transaction data?](https://bitcoin.stackexchange.com/q/107944/13866)
* [What is the script assembly and execution in P2TR spend (spend from Taproot)](https://bitcoin.stackexchange.com/q/111098/13866)
* [How to differentiate between BTC transactions and BRC20 transactions on a blockchain?](https://bitcoin.stackexchange.com/q/118988/13866)
* [What are the scriptPubKey, scriptSig, redeem script and witness for the various output types?](https://bitcoin.stackexchange.com/q/107872/13866)

> **Comments:**
> **username_0**: Thanks for the super great answer, however, what is the Hash of the reference transaction and in which component are the wallet-addresses stored for the transaction?  
> **username_3**: I have added some notes about the reference transaction and wallet addresses.  
> **username_4**: I would add that there is one witness field **per input**, so if the tx has three inputs, then after the output fields, will be 3 witness fields.  
> **username_3**: Hello Zenul - My answer does already say **"A list of witnesses, one for each input;"**  - However I have added a longer explanation to make it clearer.  

---

