<p>The representation of data is from site to site different. The hexcode "01" is a SIGHASH ALL Opcode, <a href="https://en.bitcoin.it/wiki/Contract#Theory" rel="nofollow noreferrer">defined here</a>. </p>

<p>I show here all the opcodes and their definition of your example. Basically sigscript of this example consists of . The signature is an ASN1 DER structure, followed by the public key as hex chars. Drilling deeper, it gets this: </p>

<pre><code>49: OP_DATA_0x49:        push hex 49 (decimal 73) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
46: OP_LENGTH_0x46:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
21: OP_LENGTH_0x21:      this is SIG R (33 Bytes)
02: OP_INT_0x02:         type tag INTEGER indicating length
21: OP_LENGTH_0x21:      this is SIG S (33 Bytes)
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)
21: OP_DATA_0x21:        length compressed Public Key (X9.63 form, 33 Bytes)
</code></pre>

<p>So [ALL] and "01" indicate the same. One format is showing the OpCodes (see also in the scriptPubKey section), one is plain hex representation, to make cut&amp;paste easy. All <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">opcodes are here</a>. </p>

CC BY-SA 3.0
2018-03-17T00:11:39.913Z
It's strange to prefix all those things with "OP_". They're not opcodes; just part of the DER serialization. And the sighash ALL flag is appended by Bitcoin to the ECDSA signature; it's not part of it, and certainly not DER encoded.
Pieter Wuille
CC BY-SA 3.0
2018-03-17T11:42:52.063Z
yup, sure. Got that, no Op_Codes, maybe operators, or TT for type tags. In the ASN1 specs they talk a lot about byte values, maybe BV instead.
pebwindkraft
CC BY-SA 3.0
2018-03-16T22:38:41.483Z
2018-03-16T22:38:41.483Z
pebwindkraft


<pre><code>.\bitcoin-cli.exe getrawtransaction af66f73a42d33a446e52f1c8e82a99fcd9d788a0ec5c70de6f633
213a7546cdb true
</code></pre>

<p>"scriptSig": {"asm": "30460221009c8...acc0a2a <strong>[ALL]</strong></p>

<p>the same transaction on <a href="https://blockchain.info/tx/af66f73a42d33a446e52f1c8e82a99fcd9d788a0ec5c70de6f633213a7546cdb" rel="nofollow noreferrer">blockchain</a></p>

<p>ScriptSig[30460221009c82db110da31acc0a2a<strong>01</strong></p>

<p>Why different line endings?</p>

<p>cc0a<strong>2a[ALL]</strong> <em>and</em> cc0a<strong>2a01</strong></p>

<p>A through <a href="https://blockchain.info/decode-tx" rel="nofollow noreferrer">blockchain-decode-tx</a> returns the cc0a<strong>2a0121</strong></p>



<pre><code>{
  "txid": "af66f73a42d33a446e52f1c8e82a99fcd9d788a0ec5c70de6f633213a7546cdb",
  "hash": "af66f73a42d33a446e52f1c8e82a99fcd9d788a0ec5c70de6f633213a7546cdb",
  "version": 1,
  "size": 227,
  "vsize": 227,
  "locktime": 0,
  "vin": [
    {
      "txid": "dfeeaf1d64c003bbdbff64d75ad3138474df0dc3e7abd44ed89e4cfc09273b6e",
      "vout": 1,
      "scriptSig": {
        "asm": "30460221009c82db1849470f912523be8ca42dc8d0b827ba2f1092466a006e724536f83fe0022100cf357fb7926658759f753b371156c8a60359e4f1e414c80d2aa8dba31acc0a2a[ALL] 03b84aeff9f0cc653b3a0f0cf292b9e0be25e7c8d88396dd9c3206c382cf081ffd",
        "hex": "4930460221009c82db1849470f912523be8ca42dc8d0b827ba2f1092466a006e724536f83fe0022100cf357fb7926658759f753b371156c8a60359e4f1e414c80d2aa8dba31acc0a2a012103b84aeff9f0cc653b3a0f0cf292b9e0be25e7c8d88396dd9c3206c382cf081ffd"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 43.25325000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 97056a6636c0b58969d45977a0a341387725af77 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91497056a6636c0b58969d45977a0a341387725af7788ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1EmXXFXQWQBqkLdo1kVFzVCRRQkMQovCNz"
        ]
      }
    },
    {
      "value": 0.95020000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 3959a306ea4339d6c8cfbadb89ff2b75cb8471a4 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9143959a306ea4339d6c8cfbadb89ff2b75cb8471a488ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "16EEu1asfV9YjZCif8LPrLdgM3ubCtn1GW"
        ]
      }
    }
  ],
  "hex": "01000000016e3b2709fc4c9ed84ed4abe7c30ddf748413d35ad764ffdbbb03c0641dafeedf010000006c4930460221009c82db1849470f912523be8ca42dc8d0b827ba2f1092466a006e724536f83fe0022100cf357fb7926658759f753b371156c8a60359e4f1e414c80d2aa8dba31acc0a2a012103b84aeff9f0cc653b3a0f0cf292b9e0be25e7c8d88396dd9c3206c382cf081ffdffffffff02c838cf01010000001976a91497056a6636c0b58969d45977a0a341387725af7788ace0e3a905000000001976a9143959a306ea4339d6c8cfbadb89ff2b75cb8471a488ac00000000",
  "blockhash": "00000000000001177a798a519a857d5726e2e823cc1a540dbc27d46f245553c3",
  "confirmations": 100799,
  "time": 1369935773,
  "blocktime": 1369935773
}
</code></pre>



<bitcoind><json-rpc><hash><bitcoin-core-development><raw-transaction>
getrawtransaction asm returns with [ALL], should it be?
Андрей
# getrawtransaction asm returns with [ALL], should it be?

(Asked by: username_0 on 2018-03-16)

.\bitcoin-cli.exe getrawtransaction af66f73a42d33a446e52f1c8e82a99fcd9d788a0ec5c70de6f633
213a7546cdb true

"scriptSig": {"asm": "30460221009c8...acc0a2a [ALL]
the same transaction on blockchain
ScriptSig[30460221009c82db110da31acc0a2a01
Why different line endings?
cc0a2a[ALL] and cc0a2a01
A through blockchain-decode-tx returns the cc0a2a0121
{
  "txid": "af66f73a42d33a446e52f1c8e82a99fcd9d788a0ec5c70de6f633213a7546cdb",
  "hash": "af66f73a42d33a446e52f1c8e82a99fcd9d788a0ec5c70de6f633213a7546cdb",
  "version": 1,
  "size": 227,
  "vsize": 227,
  "locktime": 0,
  "vin": [
    {
      "txid": "dfeeaf1d64c003bbdbff64d75ad3138474df0dc3e7abd44ed89e4cfc09273b6e",
      "vout": 1,
      "scriptSig": {
        "asm": "30460221009c82db1849470f912523be8ca42dc8d0b827ba2f1092466a006e724536f83fe0022100cf357fb7926658759f753b371156c8a60359e4f1e414c80d2aa8dba31acc0a2a[ALL] 03b84aeff9f0cc653b3a0f0cf292b9e0be25e7c8d88396dd9c3206c382cf081ffd",
        "hex": "4930460221009c82db1849470f912523be8ca42dc8d0b827ba2f1092466a006e724536f83fe0022100cf357fb7926658759f753b371156c8a60359e4f1e414c80d2aa8dba31acc0a2a012103b84aeff9f0cc653b3a0f0cf292b9e0be25e7c8d88396dd9c3206c382cf081ffd"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 43.25325000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 97056a6636c0b58969d45977a0a341387725af77 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91497056a6636c0b58969d45977a0a341387725af7788ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1EmXXFXQWQBqkLdo1kVFzVCRRQkMQovCNz"
        ]
      }
    },
    {
      "value": 0.95020000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 3959a306ea4339d6c8cfbadb89ff2b75cb8471a4 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9143959a306ea4339d6c8cfbadb89ff2b75cb8471a488ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "16EEu1asfV9YjZCif8LPrLdgM3ubCtn1GW"
        ]
      }
    }
  ],
  "hex": "01000000016e3b2709fc4c9ed84ed4abe7c30ddf748413d35ad764ffdbbb03c0641dafeedf010000006c4930460221009c82db1849470f912523be8ca42dc8d0b827ba2f1092466a006e724536f83fe0022100cf357fb7926658759f753b371156c8a60359e4f1e414c80d2aa8dba31acc0a2a012103b84aeff9f0cc653b3a0f0cf292b9e0be25e7c8d88396dd9c3206c382cf081ffdffffffff02c838cf01010000001976a91497056a6636c0b58969d45977a0a341387725af7788ace0e3a905000000001976a9143959a306ea4339d6c8cfbadb89ff2b75cb8471a488ac00000000",
  "blockhash": "00000000000001177a798a519a857d5726e2e823cc1a540dbc27d46f245553c3",
  "confirmations": 100799,
  "time": 1369935773,
  "blocktime": 1369935773
}

**Tags:** bitcoind, json-rpc, hash, bitcoin-core-development, raw-transaction


---

## 1 answers

### Answer by username_1 on 2018-03-16. Score: 1

The representation of data is from site to site different. The hexcode "01" is a SIGHASH ALL Opcode, defined here. 
I show here all the opcodes and their definition of your example. Basically sigscript of this example consists of . The signature is an ASN1 DER structure, followed by the public key as hex chars. Drilling deeper, it gets this: 
49: OP_DATA_0x49:        push hex 49 (decimal 73) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
46: OP_LENGTH_0x46:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
21: OP_LENGTH_0x21:      this is SIG R (33 Bytes)
02: OP_INT_0x02:         type tag INTEGER indicating length
21: OP_LENGTH_0x21:      this is SIG S (33 Bytes)
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)
21: OP_DATA_0x21:        length compressed Public Key (X9.63 form, 33 Bytes)

So [ALL] and "01" indicate the same. One format is showing the OpCodes (see also in the scriptPubKey section), one is plain hex representation, to make cut&paste easy. All opcodes are here.

> **Comments:**
> **username_2**: It's strange to prefix all those things with "OP_". They're not opcodes; just part of the DER serialization. And the sighash ALL flag is appended by Bitcoin to the ECDSA signature; it's not part of it, and certainly not DER encoded.  
> **username_1**: yup, sure. Got that, no Op_Codes, maybe operators, or TT for type tags. In the ASN1 specs they talk a lot about byte values, maybe BV instead.  

---

