<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>

CC BY-SA 4.0
2023-02-27T15:24:13.747Z
I think you’re mixing up “witness script” and “witness program”. Native segwit output scripts are defined as consisting of `<version> <witness_program>`. In P2WSH the witness program is the hash of the witness script, so your third sentence should therefore read “The hash of the witness script…”.
Murch
CC BY-SA 4.0
2023-02-27T17:36:43.493Z
Thanks @Murch. Updated.
Michael Folkson
CC BY-SA 4.0
2023-02-27T14:41:40.513Z
2023-02-27T17:36:26.370Z
2023-02-27T17:36:26.370Z
Michael Folkson
<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>

CC BY-SA 4.0
2023-02-27T15:34:54.067Z
It's listed under "N/A" there, because direct pushes aren't considered opcodes. Pushing 32 bytes is just `0x20` (hex value of 32) followed by the 32 bytes being pushed in the script encoding.
Pieter Wuille
CC BY-SA 4.0
2023-02-27T15:55:26.713Z
One last question. I realize that you have shown me the op codes that are in front of the public key. What about the op codes following the public keys? I deleted my reference to the op codes form that site since it's not actually for bitcoin.
bitcoinluvr6969
CC BY-SA 4.0
2023-02-27T16:02:55.957Z
Are they followed by op_return? as per https://bitcoin.stackexchange.com/questions/87832/how-i-can-extract-all-bitcoin-output-addresses-from-tx-message?noredirect=1&lq=1
bitcoinluvr6969
CC BY-SA 4.0
2023-02-27T18:30:44.027Z
No, OP_RETURN makes any output unspendable. It's only included in so called "data carrier" outputs which are deliberately not intended to be spensable. As I stated in my answer, native segwit outputs are of the form OP_n + some data push. There are never any other opcodes involved in the scriptPubKey.
Pieter Wuille
CC BY-SA 4.0
2023-02-27T19:51:03.667Z
I'm sorry to keep bringing up more questions but this is fascinating. So, how exactly do you signify the end of what needs to be decoded as the public key then? If it's OP_n, then it signifies exactly how many bytes to pull out?
bitcoinluvr6969
CC BY-SA 4.0
2023-02-27T19:52:44.913Z
@bitcoinluvr6969 Look, I get that you're trying to reverse engineer the entire transaction format based on just a hex dump. This is foolish, it'll make you miss all sorts of edge cases even if it works. Implement a proper transaction decoder, and if need be, a Script parser. You don't need to guess these things; the script field has a well-defined length in a transaction, so with a proper decoder you'll never need to guess. Just trying to pattern match for known byte sequences will only work some of the time. You'll find the basics on https://en.bitcoin.it/wiki/Protocol_documentation e.g.
Pieter Wuille
CC BY-SA 4.0
2023-02-27T19:55:36.460Z
I understand that you're somehow constrained to not use existing libraries to do this parsing for you. But that means there is only one option: learn how the actual protocol works. And that means starting with the beginning: learn how messages are encoded on the wire. Then learn how transactions (and maybe block) messages are encoded. And when you have all that, you'll see where the scripts appear and what to send a script decoder.
Pieter Wuille
CC BY-SA 4.0
2023-02-27T15:10:34.397Z
2023-02-27T15:10:34.397Z
Pieter Wuille
<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>

<transactions><address><segregated-witness><opcodes>
What are the OP codes associated with bc1?
bitcoinluvr6969
# What are the OP codes associated with bc1?

(Asked by: username_0 on 2023-02-27)

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](https://bitcoin.stackexchange.com/questions/87832/how-i-can-extract-all-bitcoin-output-addresses-from-tx-message) are described as, from what I gather, not having OP codes. How can this be? Surely I'm misunderstanding something. Can anyone elaborate?

**Tags:** transactions, address, segregated-witness, opcodes


---

## 2 answers

### Answer by username_3 on 2023-02-27. Score: 5 | Accepted answer

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](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)), `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](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki).
* For P2WSH (pay to witness script hash, [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)), `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](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) as well.
* For P2TR (pay to taproot, [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)), `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](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki).
* 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](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki), 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.

> **Comments:**
> **username_3**: It's listed under "N/A" there, because direct pushes aren't considered opcodes. Pushing 32 bytes is just `0x20` (hex value of 32) followed by the 32 bytes being pushed in the script encoding.  
> **username_0**: One last question. I realize that you have shown me the op codes that are in front of the public key. What about the op codes following the public keys? I deleted my reference to the op codes form that site since it's not actually for bitcoin.  
> **username_0**: Are they followed by op_return? as per https://bitcoin.stackexchange.com/questions/87832/how-i-can-extract-all-bitcoin-output-addresses-from-tx-message?noredirect=1&lq=1  
> **username_3**: No, OP_RETURN makes any output unspendable. It's only included in so called "data carrier" outputs which are deliberately not intended to be spensable. As I stated in my answer, native segwit outputs are of the form OP_n + some data push. There are never any other opcodes involved in the scriptPubKey.  
> **username_0**: I'm sorry to keep bringing up more questions but this is fascinating. So, how exactly do you signify the end of what needs to be decoded as the public key then? If it's OP_n, then it signifies exactly how many bytes to pull out?  
> **username_3**: @username_0 Look, I get that you're trying to reverse engineer the entire transaction format based on just a hex dump. This is foolish, it'll make you miss all sorts of edge cases even if it works. Implement a proper transaction decoder, and if need be, a Script parser. You don't need to guess these things; the script field has a well-defined length in a transaction, so with a proper decoder you'll never need to guess. Just trying to pattern match for known byte sequences will only work some of the time. You'll find the basics on https://en.bitcoin.it/wiki/Protocol_documentation e.g.  
> **username_3**: I understand that you're somehow constrained to not use existing libraries to do this parsing for you. But that means there is only one option: learn how the actual protocol works. And that means starting with the beginning: learn how messages are encoded on the wire. Then learn how transactions (and maybe block) messages are encoded. And when you have all that, you'll see where the scripts appear and what to send a script decoder.  

---

### Answer by username_1 on 2023-02-27. Score: 1

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](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) and also broken down [here](https://bitcoin.stackexchange.com/questions/100508/can-you-break-down-what-data-is-encoded-into-a-bech32-address). 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.

> **Comments:**
> **username_2**: I think you’re mixing up “witness script” and “witness program”. Native segwit output scripts are defined as consisting of `<version> <witness_program>`. In P2WSH the witness program is the hash of the witness script, so your third sentence should therefore read “The hash of the witness script…”.  
> **username_1**: Thanks @username_2. Updated.  

---

