As explained in


there are many types of scriptPubKey and scriptSig like:

<sig> <pubKey>
<sig> <pubKey> <pubKey> 
<sig> <pubKey> <pubHashA> 
<sig> <pubKey> <pubHashA> <pubKeyHash>

how can we detect type of ScriptSig and separate each part? In other words is there a length variable or something like that to parse each part separately?


Really, the only way to detect the type is to parse it as a program.

All scripts Bitcoin are written in the Bitcoin Script language. Much like any other programming language, certain symbols have special meaning, and correspond to specific op codes, which appear in the raw hex form. You can find a list of op codes on the Bitcoin Wiki: https://en.bitcoin.it/wiki/Script#Opcodes

The standardized scripts, which are usually what we see presented as addresses, are really just specific snippets of Bitcoin Script programs. For example, a P2PKH "address" is really just half a program in the form of:


When combined with the remaining half of the program, which is provided as the ScriptSig when spending the coins, you get a complete program which can be evaluated.

To determine the script type, you really just need to parse the program (or partial program, in the event of an output) and see if it matches a known, standardized type.

  • I mean how I can parse a scriptsig which is like this : scriptSig: <sig> <pubKey> in other words, i want to find it's public key to generate related address.
    – Saeed
    Jun 16 '19 at 8:48
  • A script sig is just a bitcoin script fragment - even simpler, they are restricted to only use OP_PUSH, so to read the signature and public key, you read the first byte for the push length, then read that many bytes as data, then read the next byte, and read that many bytes as data again - The first chunk of data is a DER encoded signature, and the second chunk is the public key Jun 16 '19 at 9:44
  • Naturally, the above only works for P2PKH/P2PK addresses - P2SH and segwit addresses will require more effort Jun 16 '19 at 9:45
  • 1
    Because they also look at the output being spent. That's how validation works. That's what you need to do to get any insight in what's going on. Also, addresses are not relevant for balance validation: the question is simply whether or not the output being spent was previously spent or not already, and if not, what value it had. Addresses are a human-level abstraction into the authentication mechanism, but don't exist at all at the protocol level. In particular, there is no such thing as an address balance. Just UTXOs. Jun 17 '19 at 5:07
  • 1
    As I advised you elsewhere, stop looking at protocol dumps and trying to match that information up with block explorers. If you want to understand what's going on, read how transactions and other things in the protocol work. Jun 17 '19 at 5:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.