<p>The <code>asm</code> section is a symbolic representation of a Bitcoin script. For inputs, the <code>scriptSig</code> is the &quot;unlocking script,&quot; proving that the input can be spent in this transaction.</p>
<p>In your specific example, the scriptSig asm can be broken down as follows:</p>
<ul>
<li><code>304..abd</code> is the DER encoding of an ECDSA signature. You can find more information about this structure here: <a href="https://bitcoin.stackexchange.com/questions/92680/what-are-the-der-signature-and-sec-format">What are the DER signature and SEC format</a></li>
<li><code>[ALL]</code> is the sighash flag, indicating the signature is for all inputs and outputs. This is the most common sighash flag</li>
<li><code>044...24a</code> is the public key of the input</li>
</ul>
<p><code>bitcoin-cli</code> does not give the human-readable <code>OP_CODE</code> names when translating from hex to asm, but different block explorers may do so. This explains why you saw a different representation when looking up the transaction with <a href="https://blockstream.info" rel="nofollow noreferrer">https://blockstream.info</a>.</p>

CC BY-SA 4.0
2023-01-30T15:04:34.727Z
2023-01-30T15:04:34.727Z
josie
<p>I am trying to understand the output from bitcoin-cli. The sample transaction's txid is <code>061959f1a3360d3781a870b2d43f73f7105b194b22f3765fcb9b8f545f9c8317</code>, from block 222,222.</p>
<p>The <code>asm</code> section of <code>scriptPubKey</code> (i.e., <code>OP_DUP OP_HASH160 28dce60cf7ba4d749afce5fd9781a403d293b74a OP_EQUALVERIFY OP_CHECKSIG</code>) is more understandable, it decodes <code>hex</code> and shows the assembly in a (sort of) human-readable format:</p>
<pre><code>&quot;vout&quot;: [
    {
      &quot;value&quot;: 0.63918136,
      &quot;n&quot;: 0,
      &quot;scriptPubKey&quot;: {
        &quot;asm&quot;: &quot;OP_DUP OP_HASH160 28dce60cf7ba4d749afce5fd9781a403d293b74a OP_EQUALVERIFY OP_CHECKSIG&quot;,
        &quot;hex&quot;: &quot;76a91428dce60cf7ba4d749afce5fd9781a403d293b74a88ac&quot;,
        &quot;address&quot;: &quot;14j4eyoxaAwA4SHj9YcEyVJ7FsqyWvUh9B&quot;,
        &quot;type&quot;: &quot;pubkeyhash&quot;
      }
    },
...
]
</code></pre>
<p>The question arises when it comes to the <code>asm</code> section of <code>scriptSig</code>:</p>
<pre><code>{
  &quot;txid&quot;: &quot;b66e78c919e36a6c563ceb1b29cfec26f7dec3c3fc1b3631c84056f3ae147f2f&quot;,
  &quot;vout&quot;: 1,
  &quot;scriptSig&quot;: {
    &quot;asm&quot;: &quot;3045022100dceb566dec99cf195aba5d6313f1e95eb7bfc74c93a794c4bfd6dd9f4082d8a002203b495b70b917b3dffdcbe70fc6ff7de910d1697efccc14f3eea6944bda87d21c[ALL] 0445554717c4d3240d818f400ab66fd4de438f2fd9174641ea76480b95cd6e883ec274a10b0691d85ac2cb87dcb9eef58b3abb8ee4bd277c8d6fea09eace2bc24a&quot;,
    &quot;hex&quot;: &quot;483045022100dceb566dec99cf195aba5d6313f1e95eb7bfc74c93a794c4bfd6dd9f4082d8a002203b495b70b917b3dffdcbe70fc6ff7de910d1697efccc14f3eea6944bda87d21c01410445554717c4d3240d818f400ab66fd4de438f2fd9174641ea76480b95cd6e883ec274a10b0691d85ac2cb87dcb9eef58b3abb8ee4bd277c8d6fea09eace2bc24a&quot;
}
</code></pre>
<p>As you can see, it is <code>304502206ee08c76923816e4ba287142e9f147fe9cd0f26e6bd58b9a43f2283b1c614f46022100d5de298b627407bc7d5ac0a40259cafb865c30c6a67db926c7284da96ff71abd[ALL] 040841958a405ca1c05de4dcf04dfdfd6e7de5e7cb106744977e3d99eab3e59a2b5bc2441e0ad179055c14200745feb2da2d1b4485087e3a9a2a88a6531a6d6b02</code>, which is not decoded at all.</p>
<p>I checked the same transaction from <a href="https://blockstream.info/api/block/00000000000000b8b49d0b61b14994b5c0a511c4b48a1e251ff2b479b2e6f678/txs/725" rel="nofollow noreferrer">blockstream.info</a>. It's result is: <code>OP_PUSHBYTES_72 304502206ee08c76923816e4ba287142e9f147fe9cd0f26e6bd58b9a43f2283b1c614f46022100d5de298b627407bc7d5ac0a40259cafb865c30c6a67db926c7284da96ff71abd01 OP_PUSHBYTES_65 040841958a405ca1c05de4dcf04dfdfd6e7de5e7cb106744977e3d99eab3e59a2b5bc2441e0ad179055c14200745feb2da2d1b4485087e3a9a2a88a6531a6d6b02</code>
which looks more readable and I can understand that this <code>scriptSig</code> pushes two bytes arrays into the Bitcoin's stack.</p>
<p>So the questions are:</p>
<ol>
<li>Why <code>bitcoin-cli</code>'s output is like this?</li>
<li>How to interpret it? Especially, how to understand the <code>[ALL]</code> part in its <code>asm</code>?</li>
</ol>
<p><strong>EDIT:</strong></p>
<p>While the answer below is quite informative, <a href="https://github.com/bitcoin/bitcoin/issues/26993" rel="nofollow noreferrer">the issue</a> I raised on Bitcoin Core's Github is worth taking a look as well.</p>

<script><bitcoin-cli>
What is the asm section of scriptSig
D.J. Elkind
# What is the asm section of scriptSig

(Asked by: username_0 on 2023-01-29)

I am trying to understand the output from bitcoin-cli. The sample transaction's txid is 061959f1a3360d3781a870b2d43f73f7105b194b22f3765fcb9b8f545f9c8317, from block 222,222.
The asm section of scriptPubKey (i.e., OP_DUP OP_HASH160 28dce60cf7ba4d749afce5fd9781a403d293b74a OP_EQUALVERIFY OP_CHECKSIG) is more understandable, it decodes hex and shows the assembly in a (sort of) human-readable format:
"vout": [
    {
      "value": 0.63918136,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 28dce60cf7ba4d749afce5fd9781a403d293b74a OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91428dce60cf7ba4d749afce5fd9781a403d293b74a88ac",
        "address": "14j4eyoxaAwA4SHj9YcEyVJ7FsqyWvUh9B",
        "type": "pubkeyhash"
      }
    },
...
]

The question arises when it comes to the asm section of scriptSig:
{
  "txid": "b66e78c919e36a6c563ceb1b29cfec26f7dec3c3fc1b3631c84056f3ae147f2f",
  "vout": 1,
  "scriptSig": {
    "asm": "3045022100dceb566dec99cf195aba5d6313f1e95eb7bfc74c93a794c4bfd6dd9f4082d8a002203b495b70b917b3dffdcbe70fc6ff7de910d1697efccc14f3eea6944bda87d21c[ALL] 0445554717c4d3240d818f400ab66fd4de438f2fd9174641ea76480b95cd6e883ec274a10b0691d85ac2cb87dcb9eef58b3abb8ee4bd277c8d6fea09eace2bc24a",
    "hex": "483045022100dceb566dec99cf195aba5d6313f1e95eb7bfc74c93a794c4bfd6dd9f4082d8a002203b495b70b917b3dffdcbe70fc6ff7de910d1697efccc14f3eea6944bda87d21c01410445554717c4d3240d818f400ab66fd4de438f2fd9174641ea76480b95cd6e883ec274a10b0691d85ac2cb87dcb9eef58b3abb8ee4bd277c8d6fea09eace2bc24a"
}

As you can see, it is 304502206ee08c76923816e4ba287142e9f147fe9cd0f26e6bd58b9a43f2283b1c614f46022100d5de298b627407bc7d5ac0a40259cafb865c30c6a67db926c7284da96ff71abd[ALL] 040841958a405ca1c05de4dcf04dfdfd6e7de5e7cb106744977e3d99eab3e59a2b5bc2441e0ad179055c14200745feb2da2d1b4485087e3a9a2a88a6531a6d6b02, which is not decoded at all.
I checked the same transaction from blockstream.info. It's result is: OP_PUSHBYTES_72 304502206ee08c76923816e4ba287142e9f147fe9cd0f26e6bd58b9a43f2283b1c614f46022100d5de298b627407bc7d5ac0a40259cafb865c30c6a67db926c7284da96ff71abd01 OP_PUSHBYTES_65 040841958a405ca1c05de4dcf04dfdfd6e7de5e7cb106744977e3d99eab3e59a2b5bc2441e0ad179055c14200745feb2da2d1b4485087e3a9a2a88a6531a6d6b02
which looks more readable and I can understand that this scriptSig pushes two bytes arrays into the Bitcoin's stack.
So the questions are:

Why bitcoin-cli's output is like this?
How to interpret it? Especially, how to understand the [ALL] part in its asm?

EDIT:
While the answer below is quite informative, the issue I raised on Bitcoin Core's Github is worth taking a look as well.

**Tags:** script, bitcoin-cli


---

## 1 answers

### Answer by username_1 on 2023-01-30. Score: 2 | Accepted answer

The `asm` section is a symbolic representation of a Bitcoin script. For inputs, the `scriptSig` is the "unlocking script," proving that the input can be spent in this transaction.

In your specific example, the scriptSig asm can be broken down as follows:

* `304..abd` is the DER encoding of an ECDSA signature. You can find more information about this structure here: [What are the DER signature and SEC format](https://bitcoin.stackexchange.com/questions/92680/what-are-the-der-signature-and-sec-format)
* `[ALL]` is the sighash flag, indicating the signature is for all inputs and outputs. This is the most common sighash flag
* `044...24a` is the public key of the input

`bitcoin-cli` does not give the human-readable `OP_CODE` names when translating from hex to asm, but different block explorers may do so. This explains why you saw a different representation when looking up the transaction with <https://blockstream.info>.


---

