user140253: As the title says I'm trying to extract bc1 addresses by using opcodes I've found from reading about bitcoin online. However, I cannot actually find the opcodes associated with bc1. The segwit outputs here are described as, from what I gather, not having OP codes. How can this be? Surely I'm misunderstanding something. Can anyone elaborate?

user47827: I think you may be misunderstanding how an address is constructed and where scripting opcodes fit into that. The bc1 indicates the use of the bech32 address format for SegWit versions as defined in BIP 173 and also broken down here. The hash of the witness script (SegWit version 0) or the tweaked internal key (SegWit version 1) is included within that address. The opcodes used in the witness script or the tweak of the internal key are only revealed on spending from the address. So to view and analyze the opcodes you need to look at the transactions spending from a particular address rather than the transactions sending to a particular address.

user208: Native segwit scriptPubKeys are of the form OP_n + <data>, so first a single number opcode followed by a push of some data (called the witness program). Specifically:

For P2WPKH (pay to witness pubkey hash, BIP141), OP_0 followed by a push of 20 bytes. Those 20 bytes are the Hash160 of a public key. Their corresponding address format is defined by BIP173.
For P2WSH (pay to witness script hash, BIP141), OP_0 followed by a push of 32 bytes. Those 32 bytes are the SHA256 of a script. Their corresponding address format is defined by BIP173 as well.
For P2TR (pay to taproot, BIP341), OP_1 followed by a push of 32 bytes. Those 32 bytes are a tweaked x-only public key. Their corresponding address format is defined by BIP350.
For future witness versions, any OP_1 through OP_16 followed by a push of something between 2 and 40 bytes (except OP_1 followed by 32 bytes, which is P2TR). These too have addresses associated with them in BIP350, but no semantics (yet).

In general, native segwit outputs do not contain any "active" opcodes like OP_CHECKSIG or OP_HASH160 or anything like that, they're just stubs that push some data. The segwit (and taproot) consensus rules know how to interpret them.

140253: <p>As the title says I'm trying to extract bc1 addresses by using opcodes I've found from reading about bitcoin online. However, I cannot actually find the opcodes associated with bc1. The segwit outputs <a href="https://bitcoin.stackexchange.com/questions/87832/how-i-can-extract-all-bitcoin-output-addresses-from-tx-message">here</a> are described as, from what I gather, not having OP codes. How can this be? Surely I'm misunderstanding something. Can anyone elaborate?</p>
 47827: <p>I think you may be misunderstanding how an address is constructed and where scripting opcodes fit into that. The <code>bc1</code> indicates the use of the bech32 address format for SegWit versions as defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP 173</a> and also broken down <a href="https://bitcoin.stackexchange.com/questions/100508/can-you-break-down-what-data-is-encoded-into-a-bech32-address">here</a>. The hash of the witness script (SegWit version 0) or the tweaked internal key (SegWit version 1) is included within that address. The opcodes used in the witness script or the tweak of the internal key are only revealed on spending from the address. So to view and analyze the opcodes you need to look at the transactions spending from a particular address rather than the transactions sending to a particular address.</p>
 208: <p>Native segwit scriptPubKeys are of the form <code>OP_n + &lt;data&gt;</code>, so first a single number opcode followed by a push of some data (called the witness program). Specifically:</p>
<ul>
<li>For P2WPKH (pay to witness pubkey hash, <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="noreferrer">BIP141</a>), <code>OP_0</code> followed by a push of 20 bytes. Those 20 bytes are the Hash160 of a public key. Their corresponding address format is defined by <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="noreferrer">BIP173</a>.</li>
<li>For P2WSH (pay to witness script hash, <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="noreferrer">BIP141</a>), <code>OP_0</code> followed by a push of 32 bytes. Those 32 bytes are the SHA256 of a script. Their corresponding address format is defined by <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="noreferrer">BIP173</a> as well.</li>
<li>For P2TR (pay to taproot, <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="noreferrer">BIP341</a>), <code>OP_1</code> followed by a push of 32 bytes. Those 32 bytes are a tweaked x-only public key. Their corresponding address format is defined by <a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="noreferrer">BIP350</a>.</li>
<li>For future witness versions, any <code>OP_1</code> through <code>OP_16</code> followed by a push of something between 2 and 40 bytes (except <code>OP_1</code> followed by 32 bytes, which is P2TR). These too have addresses associated with them in <a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="noreferrer">BIP350</a>, but no semantics (yet).</li>
</ul>
<p>In general, native segwit outputs do not contain any &quot;active&quot; opcodes like <code>OP_CHECKSIG</code> or <code>OP_HASH160</code> or anything like that, they're just stubs that push some data. The segwit (and taproot) consensus rules know how to interpret them.</p>
