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?
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_0followed 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_0followed 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_1followed 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_16followed by a push of something between 2 and 40 bytes (except
OP_1followed 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_HASH160 or anything like that, they're just stubs that push some data. The segwit (and taproot) consensus rules know how to interpret them.
1It'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. Feb 27 at 15:34
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. Feb 27 at 15:55
Are they followed by op_return? as per bitcoin.stackexchange.com/questions/87832/… Feb 27 at 16:02
1@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 en.bitcoin.it/wiki/Protocol_documentation e.g. Feb 27 at 19:52
1I 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. Feb 27 at 19:55
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.
1I 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 ♦Feb 27 at 15:24
Thanks @Murch. Updated. Feb 27 at 17:36