user139755: 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.

user139612: 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
[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.

139755: <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>
 139612: <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>
