How to interpret the asm section of scriptSig

alex-lt-kong commented at 1:36 pm on January 30, 2023: none

I tried asking the question in this post on bitcoin.stackexchange.com but got no answer. The question is this:

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:

 0"vout": [
 1    {
 2      "value": 0.63918136,
 3      "n": 0,
 4      "scriptPubKey": {
 5        "asm": "OP_DUP OP_HASH160 28dce60cf7ba4d749afce5fd9781a403d293b74a OP_EQUALVERIFY OP_CHECKSIG",
 6        "hex": "76a91428dce60cf7ba4d749afce5fd9781a403d293b74a88ac",
 7        "address": "14j4eyoxaAwA4SHj9YcEyVJ7FsqyWvUh9B",
 8        "type": "pubkeyhash"
 9      }
10    },
11...
12]

The question arises when it comes to the asm section of scriptSig:

0{
1  "txid": "b66e78c919e36a6c563ceb1b29cfec26f7dec3c3fc1b3631c84056f3ae147f2f",
2  "vout": 1,
3  "scriptSig": {
4    "asm": "3045022100dceb566dec99cf195aba5d6313f1e95eb7bfc74c93a794c4bfd6dd9f4082d8a002203b495b70b917b3dffdcbe70fc6ff7de910d1697efccc14f3eea6944bda87d21c[ALL] 0445554717c4d3240d818f400ab66fd4de438f2fd9174641ea76480b95cd6e883ec274a10b0691d85ac2cb87dcb9eef58b3abb8ee4bd277c8d6fea09eace2bc24a",
5    "hex": "483045022100dceb566dec99cf195aba5d6313f1e95eb7bfc74c93a794c4bfd6dd9f4082d8a002203b495b70b917b3dffdcbe70fc6ff7de910d1697efccc14f3eea6944bda87d21c01410445554717c4d3240d818f400ab66fd4de438f2fd9174641ea76480b95cd6e883ec274a10b0691d85ac2cb87dcb9eef58b3abb8ee4bd277c8d6fea09eace2bc24a"
6}

As you can see, it is 304502206ee08c76923816e4ba287142e9f147fe9cd0f26e6bd58b9a43f2283b1c614f46022100d5de298b627407bc7d5ac0a40259cafb865c30c6a67db926c7284da96ff71abd[ALL] 040841958a405ca1c05de4dcf04dfdfd6e7de5e7cb106744977e3d99eab3e59a2b5bc2441e0ad179055c14200745feb2da2d1b4485087e3a9a2a88a6531a6d6b02, which isn’t really decoded.

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 byte arrays into the Bitcoin VM’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? (Perhaps you can just give me a RTFM link?)

maflcko added the label Docs on Jan 30, 2023

maflcko added the label RPC/REST/ZMQ on Jan 30, 2023

maflcko added the label Questions and Help on Jan 30, 2023

willcl-ark commented at 2:01 pm on January 30, 2023: contributor

I am not totally sure why the output was chosen to be like this for the input scriptSigs. I do note though that you can further decode a script using e.g.:

 0➜ bitcoin-cli decodescript "483045022100dceb566dec99cf195aba5d6313f1e95eb7bfc74c93a794c4bfd6dd9f4082d8a002203b495b70b917b3dffdcbe70fc6ff7de910d1697efccc14f3eea6944bda87d21c01410445554717c4d3240d818f400ab66fd4de438f2fd9174641ea76480b95cd6e883ec274a10b0691d85ac2cb87dcb9eef58b3abb8ee4bd277c8d6fea09eace2bc24a"
 1{
 2  "asm": "3045022100dceb566dec99cf195aba5d6313f1e95eb7bfc74c93a794c4bfd6dd9f4082d8a002203b495b70b917b3dffdcbe70fc6ff7de910d1697efccc14f3eea6944bda87d21c01 0445554717c4d3240d818f400ab66fd4de438f2fd9174641ea76480b95cd6e883ec274a10b0691d85ac2cb87dcb9eef58b3abb8ee4bd277c8d6fea09eace2bc24a",
 3  "desc": "raw(483045022100dceb566dec99cf195aba5d6313f1e95eb7bfc74c93a794c4bfd6dd9f4082d8a002203b495b70b917b3dffdcbe70fc6ff7de910d1697efccc14f3eea6944bda87d21c01410445554717c4d3240d818f400ab66fd4de438f2fd9174641ea76480b95cd6e883ec274a10b0691d85ac2cb87dcb9eef58b3abb8ee4bd277c8d6fea09eace2bc24a)#dcqn8yev",
 4  "type": "nonstandard",
 5  "p2sh": "3ADYqKp8owLNmKiGHw3NVqzCuHi3nzbRAV",
 6  "segwit": {
 7    "asm": "0 ca6146c398fa98e0ac0a332056ce0f8d0f4cd023cde04980739b1c9f850d532c",
 8    "desc": "addr(bc1qefs5dsucl2vwptq2xvs9dns03585e5prehsynqrnnvwflpgd2vkq2pvxy3)#9emuhxa6",
 9    "hex": "0020ca6146c398fa98e0ac0a332056ce0f8d0f4cd023cde04980739b1c9f850d532c",
10    "address": "bc1qefs5dsucl2vwptq2xvs9dns03585e5prehsynqrnnvwflpgd2vkq2pvxy3",
11    "type": "witness_v0_scripthash",
12    "p2sh-segwit": "32yY6f1MeGVNnsuwxzzTg89fJhJpUpY7j6"
13  }
14}

Regarding [ALL] in the output, this refers to the sighash type which the signature should be verified against. You can see in the blockstream.info they have left the SIGHASH_ALL in at the end of the data, represented by hex 0x01. IMO [ALL] is actually clearer here, but it’s subjective I suppose.

alex-lt-kong commented at 3:05 pm on January 30, 2023: none

@willcl-ark : After reading your post it is a bit more clear to me. However, as I am still learning the Bitcoin’s serialization protocol (and I am still at the stage of serializing/deserializing byte code for Bitcoin’s VM), I have a rather naive question…

Can I summarize your 2nd point as below?:

if a byte array ends with 0x01, it will be replaced by [ALL]; Or
if bitcoin-cli’s scriptSig.asm contains [ALL], I can assume it is from 0x01.

The point of the question is, I want to cross-check my bitcoin library’s serialization/deserialization output with bitcoin-cli’s, so I want follow the convention used by bitcoin-cli.

willcl-ark commented at 5:05 pm on January 30, 2023: contributor

You can see roughly how the text is inserted between the square brackets here:

https://github.com/bitcoin/bitcoin/blob/82903a7a8dc327f94eff0bbbb97d8a0eb04e9044/src/core_write.cpp#L127-L128

And find the sighash type string casts here:

https://github.com/bitcoin/bitcoin/blob/82903a7a8dc327f94eff0bbbb97d8a0eb04e9044/src/core_write.cpp#L75-L82

And finally the sighash flags here:

https://github.com/bitcoin/bitcoin/blob/82903a7a8dc327f94eff0bbbb97d8a0eb04e9044/src/script/interpreter.h#L25-L36

alex-lt-kong commented at 1:15 pm on January 31, 2023: none

ah yes, this solves my issue. Thanks!

alex-lt-kong closed this on Jan 31, 2023

bitcoin locked this on Jan 31, 2024

How to interpret the asm section of scriptSig #26993