user133967: 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)?

user13866: Transaction structure after introduction of Segwit
In an answer to In what format does a block store the transaction data? 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.





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


Witness component 2




21
varint
Length of witness component (0x21 = 33)


03d96e3819b52245 e42c76f869c9a875 f6ea5344cf1aee2e 6b3ab03adcfef0d8 0e
33 octets
witness


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 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 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.
Scripts
The locking script and the unlocking script are tiny programs written in the Bitcoin scripting language - 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?
In what format does a block store the transaction data?
How can I get the destination address from raw transaction data?


133967: <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>
 13866: <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.</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</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</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 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><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>
</ul>
