<blockquote>
  <p>or should I implement more sophisticated script parser which can
  detect "non-standard" scripts as well?</p>
</blockquote>

<p>You can create two "virtual" accounts while parsing the blockchain.</p>

<p>First account receives all non-standard transactions which are provable unspendable.
There will be no spendings from this "account". The amount of this account will be the answer to a question "How many bitcoins are lost"</p>

<p>Second account receives all other non-standard outputs.</p>

CC BY-SA 3.0
2015-01-14T10:45:33.077Z
2015-01-14T10:45:33.077Z
amaclin
<p>These are the scriptPubKey's that are standard, arranged in order of popularity:</p>

<ol>
<li><p>P2PKH (Pay to public key hash)</p>

<pre><code>OP_DUP OP_HASH160 &lt;20 bytes of public key hash&gt; OP_EQUALVERIFY OP_CHECKSIG
</code></pre></li>
<li><p>P2SH (Pay to script hash)</p>

<pre><code>OP_HASH160 &lt;20 bytes of script hash&gt; OP_EQUAL
</code></pre></li>
<li><p>P2PK (Pay to public key)</p>

<p>This is now mostly unused, except by miners, but there are still unspent outputs in the form:</p>

<pre><code>&lt;33 or 65 bytes of public key&gt; OP_CHECKSIG
</code></pre></li>
<li><p>Segregated witness outputs</p>

<p>There are two ways of signaling that a scriptPubKey should be interpreted as a segregated witness program:</p>

<ul>
<li><p>Native witness program</p>

<pre><code>&lt;version byte&gt; &lt;2 to 40 bytes of witness data&gt;
</code></pre>

<p>The version byte must be equal to or less than 16.</p></li>
<li><p>P2SH wrapped witness program</p>

<pre><code>OP_HASH160 &lt;20 bytes of script hash&gt; OP_EQUAL
</code></pre>

<p>The scriptSig must have exactly one item. That item is interpreted as a witness program, as above.</p></li>
</ul>

<p>&nbsp;</p>

<p>Once you extract the witness program, you must match it to one of the witness program types:</p>

<ul>
<li><p>P2WPKH</p>

<pre><code>0 &lt;20 bytes of public key hash&gt;
</code></pre>

<p>This is hashed identically to P2PKH.</p></li>
<li><p>P2WSH</p>

<pre><code>0 &lt;32 bytes of witness script hash&gt;
</code></pre>

<p>This is pretty similar to P2SH, except that the script hash is SHA256, not HASH160. </p></li>
<li><p>Other version 0 scripts, not 20 or 32 bytes in length, are nobody-can-spend, so ignore them.</p></li>
</ul>

<p>&nbsp;</p>

<p>Note that any witness program format can be combined with any witness program. For example, you can have P2SH wrapping P2WSH, like this:</p>

<p>scriptPubKey:</p>

<pre><code>OP_HASH160 &lt;20 byte hash of scriptSig element&gt; OP_EQUAL
</code></pre>

<p>scriptSig:</p>

<pre><code>&lt;34 byte serialized witness program&gt;
</code></pre>

<p>unserialized witness program:</p>

<pre><code>0 &lt;32 byte hash of first witness item&gt;
</code></pre>

<p>Then, the first witness item is unpacked and interpreted as the actual program.</p>

<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Witness_program" rel="nofollow noreferrer">More information here.</a></p></li>
<li><p>m-of-n bare multisig</p>

<p>Also pretty rare.</p>

<pre><code>&lt;m&gt; [n &lt;public key&gt;s] &lt;n&gt; OP_CHECKMULTISIG
</code></pre></li>
<li><p>Data-carrying output</p>

<p>Only one of these is allowed per transaction. These outputs can never be spent, so you probably don't need to detect them.</p>

<pre><code>OP_RETURN &lt;less than 80 bytes of data&gt;
</code></pre></li>
</ol>

<blockquote>
  <p>Should I implement more sophisticated script parser which can detect "non-standard" scripts as well?</p>
</blockquote>

<p>No. It's a waste of development time, when nobody uses transactions like that. (If they did, those transaction types would be added to the list of standard transactions. :))</p>

<p>It's also going to be very difficult to implement correctly. If you don't do it correctly, then you'll think you have coins when you really don't. For example, imagine someone sends you a transaction with a scriptPubKey like this:</p>

<pre><code>OP_DUP OP_HASH160 &lt;20 bytes of public key hash&gt; OP_2DROP OP_CHECKSIG
</code></pre>

<p>Note that this is like a P2PKH output, except that OP_EQUALVERIFY has been replaced by OP_2DROP. That means that the script checks that the signature is correct, but <em>doesn't</em> check that it's signed by the right key.</p>

<p>That means that <em>anybody</em> can spend it, not just you. Correctly detecting edge cases like these make writing a program that can understand nonstandard outputs more trouble than it's worth.</p>

CC BY-SA 3.0
2015-01-14T10:42:28.433Z
You have forgot about bare multisig outputs
amaclin
CC BY-SA 3.0
2017-12-31T14:19:02.053Z
Isn't multisig also wrapped inside P2SH?
Jus12
CC BY-SA 3.0
2017-12-31T20:08:21.840Z
@Jus12 Conventionally, but there's no protocol rule requiring that.
Nick ODell
CC BY-SA 3.0
2015-01-12T22:50:53.000Z
2017-12-08T18:04:38.247Z
2017-12-08T18:04:38.247Z
Nick ODell
<p>I am implementing a library for tracking wallet balance of given bitcoin addresses.</p>

<p>How should the transaction output script be parsed to find if the output belongs to the given address?</p>

<p>Is it dirty if I just match <em>pay-to-pubkey-hash</em> and <em>pay-to-script-hash</em> transaction by simply matching</p>

<pre><code>OP_DUP OP_HASH160 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

<p>and </p>

<pre><code>OP_HASH160 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx OP_EQUAL
</code></pre>

<p>or should I implement more sophisticated script parser which can detect "non-standard" scripts as well?</p>

<transactions><script>
Which bitcoin script forms should be detected when tracking wallet balance?
Zouppen
# Which bitcoin script forms should be detected when tracking wallet balance?

(Asked by: username_0 on 2015-01-12)

I am implementing a library for tracking wallet balance of given bitcoin addresses.

How should the transaction output script be parsed to find if the output belongs to the given address?

Is it dirty if I just match *pay-to-pubkey-hash* and *pay-to-script-hash* transaction by simply matching

```
OP_DUP OP_HASH160 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx OP_EQUALVERIFY OP_CHECKSIG

```

and

```
OP_HASH160 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx OP_EQUAL

```

or should I implement more sophisticated script parser which can detect "non-standard" scripts as well?

**Tags:** transactions, script


---

## 2 answers

### Answer by username_2 on 2015-01-12. Score: 9 | Accepted answer

These are the scriptPubKey's that are standard, arranged in order of popularity:

1. P2PKH (Pay to public key hash)

   ```
   OP_DUP OP_HASH160 <20 bytes of public key hash> OP_EQUALVERIFY OP_CHECKSIG

   ```
2. P2SH (Pay to script hash)

   ```
   OP_HASH160 <20 bytes of script hash> OP_EQUAL

   ```
3. P2PK (Pay to public key)

   This is now mostly unused, except by miners, but there are still unspent outputs in the form:

   ```
   <33 or 65 bytes of public key> OP_CHECKSIG

   ```
4. Segregated witness outputs

   There are two ways of signaling that a scriptPubKey should be interpreted as a segregated witness program:

   * Native witness program

     ```
     <version byte> <2 to 40 bytes of witness data>

     ```

     The version byte must be equal to or less than 16.
   * P2SH wrapped witness program

     ```
     OP_HASH160 <20 bytes of script hash> OP_EQUAL

     ```

     The scriptSig must have exactly one item. That item is interpreted as a witness program, as above.

   Once you extract the witness program, you must match it to one of the witness program types:

   * P2WPKH

     ```
     0 <20 bytes of public key hash>

     ```

     This is hashed identically to P2PKH.
   * P2WSH

     ```
     0 <32 bytes of witness script hash>

     ```

     This is pretty similar to P2SH, except that the script hash is SHA256, not HASH160.
   * Other version 0 scripts, not 20 or 32 bytes in length, are nobody-can-spend, so ignore them.

   Note that any witness program format can be combined with any witness program. For example, you can have P2SH wrapping P2WSH, like this:

   scriptPubKey:

   ```
   OP_HASH160 <20 byte hash of scriptSig element> OP_EQUAL

   ```

   scriptSig:

   ```
   <34 byte serialized witness program>

   ```

   unserialized witness program:

   ```
   0 <32 byte hash of first witness item>

   ```

   Then, the first witness item is unpacked and interpreted as the actual program.

   [More information here.](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Witness_program)
5. m-of-n bare multisig

   Also pretty rare.

   ```
   <m> [n <public key>s] <n> OP_CHECKMULTISIG

   ```
6. Data-carrying output

   Only one of these is allowed per transaction. These outputs can never be spent, so you probably don't need to detect them.

   ```
   OP_RETURN <less than 80 bytes of data>

   ```

> Should I implement more sophisticated script parser which can detect "non-standard" scripts as well?

No. It's a waste of development time, when nobody uses transactions like that. (If they did, those transaction types would be added to the list of standard transactions. :))

It's also going to be very difficult to implement correctly. If you don't do it correctly, then you'll think you have coins when you really don't. For example, imagine someone sends you a transaction with a scriptPubKey like this:

```
OP_DUP OP_HASH160 <20 bytes of public key hash> OP_2DROP OP_CHECKSIG

```

Note that this is like a P2PKH output, except that OP\_EQUALVERIFY has been replaced by OP\_2DROP. That means that the script checks that the signature is correct, but *doesn't* check that it's signed by the right key.

That means that *anybody* can spend it, not just you. Correctly detecting edge cases like these make writing a program that can understand nonstandard outputs more trouble than it's worth.

> **Comments:**
> **username_1**: You have forgot about bare multisig outputs  
> **username_3**: Isn't multisig also wrapped inside P2SH?  
> **username_2**: @username_3 Conventionally, but there's no protocol rule requiring that.  

---

### Answer by username_1 on 2015-01-14. Score: 0

> or should I implement more sophisticated script parser which can
> detect "non-standard" scripts as well?

You can create two "virtual" accounts while parsing the blockchain.

First account receives all non-standard transactions which are provable unspendable.
There will be no spendings from this "account". The amount of this account will be the answer to a question "How many bitcoins are lost"

Second account receives all other non-standard outputs.


---

