<p>For the segwit variants of an output (P2PKH becomes P2WPKH and P2SH becomes P2WSH), the witness contains the same data that would be found in the scriptSig. For P2PKH, in the scriptSig, you would have a signature and a pubkey. The same is in the witness for a P2WPKH.</p>

<p>For P2SH, you would have a redeemScript, signatures, and other stuff in the scriptSig. For P2WSH, those are in the witness and the redeemScript in the witness is referred to as the witnessScript.</p>

<p>It is important to note that the witness will look different than the scriptSig. This is because it is not actually a script but rather a stack of elements. A standard scriptSig is one which only pushes elements to the stack. The witness takes this a step farther by providing a stack to use instead of having to execute a script which produces the same stack.</p>

CC BY-SA 4.0
2018-07-13T19:08:04.763Z
2018-07-13T19:08:04.763Z
Ava Chow
<p>additional to JBaczuk and Andrew Chow, here is a detailed tx decoding.
This is a mixed transaction, with three "normal" inputs, and a 4th segwit type input (TX_IN[3]). Therefor after the version field of the tx we see bytes "0001", with 0x01 indicating a segwit data structure is included in the tx. In the input section, there are three following "standard" elements, also with multisig signatures. The fourth input element (TX_IN[3]) is the segwit part. The scripts is filled with no signatures, only the 0x0020{32-byte scripthash} structure. </p>

<p>At the end follows 0x00000004, each byte is the number of segwit elements per input. So the first three bytes are "0", meaning no segwit structure follows for these inputs, and then the fourth byte is 0x04, indicating four witness data elements: a "0x00" to compensate for the removal of the stack element during script evaluation, a signature, another signature and the redeem script. </p>

<pre><code>VERSION 01000000
SEGWIT (BIP141):       this is a segwit tx, marker=00
       (BIP141):       flag=01
TX_IN COUNT [var_int]: hex=04, decimal=4
 TX_IN[0]
  TX_IN[0] OutPoint hash  08A1266CED5EF064741BD4BC51C1202456F22509AE030231860D6E9BEF4ACD5E
  TX_IN[0] OutPoint index hex=62000000, reversed=00000062, decimal=98
  TX_IN[0] Script Length  hex=FC, decimal=252
  TX_IN[0] Script Sig     0047304402207E38831ECA394E472E...555C0E2D7A9D9915D6986BFC200453AE 
  TX_IN[0] Sequence       FFFFFFFF
 TX_IN[1]
  TX_IN[1] OutPoint hash  AD4C8508B8D5EECE6FD100B58D667DEA9C7A8C178C1B06602C1E3358D8105C0B
  TX_IN[1] OutPoint index hex=7D000000, reversed=0000007D, decimal=125
  TX_IN[1] Script Length  hex=FC, decimal=252
  TX_IN[1] Script Sig     0047304402203299B925B1F2C87282...ABDC12E55B0F545FFF14667A515F53AE 
  TX_IN[1] Sequence       FFFFFFFF
 TX_IN[2]
  TX_IN[2] OutPoint hash  C8066B798384B502F225BD89F7EB405265357CB0BDC0C169FE96B013310629B2
  TX_IN[2] OutPoint index hex=A3000000, reversed=000000A3, decimal=163
  TX_IN[2] Script Length  hex=00FD, decimal=253
  TX_IN[2] Script Sig     0047304402204D4DA5303BE178D649...B5A43BC43D60C844F65DB8FB78AD53AE 
  TX_IN[2] Sequence       FFFFFFFF
 TX_IN[3]
  TX_IN[3] OutPoint hash  D80FF02D0D9EB2DA8C8A1C47AB099901F447DD197E34220EA13ECA72D7D6D21D
  TX_IN[3] OutPoint index hex=9A000000, reversed=0000009A, decimal=154
  TX_IN[3] Script Length  hex=23, decimal=35
  TX_IN[3] Script Sig     22002044C55C1DA36A576217259C3BC21B0C3943F7EB3FF4E3C381D9FD3502434B9E87 
  TX_IN[3] Sequence       FFFFFFFF
TX_OUT COUNT, hex=05, decimal=5
 TX_OUT[0]
  TX_OUT[0] Value         hex=C0D4010000000000, reversed_hex=000000000001D4C0, dec=120000
  TX_OUT[0] PK_Script Len hex=17, dec=23
  TX_OUT[0] pk_script     A914A1932CFD432D928311B4ADA550BBC468D1E909B787
 TX_OUT[1]
  TX_OUT[1] Value         hex=A086010000000000, reversed_hex=00000000000186A0, dec=100000
  TX_OUT[1] PK_Script Len hex=17, dec=23
  TX_OUT[1] pk_script     A9146B0E7A66416F1D8598B5956576ADB22DAF79853E87
 TX_OUT[2]
  TX_OUT[2] Value         hex=3A4A000000000000, reversed_hex=0000000000004A3A, dec=19002
  TX_OUT[2] PK_Script Len hex=17, dec=23
  TX_OUT[2] pk_script     A914EC4C73145428ABBE0B1C40FBF58C59F0EF3C29F487
 TX_OUT[3]
  TX_OUT[3] Value         hex=382C050000000000, reversed_hex=0000000000052C38, dec=339000
  TX_OUT[3] PK_Script Len hex=17, dec=23
  TX_OUT[3] pk_script     A914ABB18A298E5B629BF5652F341D2CD8207CCC214A87
 TX_OUT[4]
  TX_OUT[4] Value         hex=8010020000000000, reversed_hex=0000000000021080, dec=135296
  TX_OUT[4] PK_Script Len hex=19, dec=25
  TX_OUT[4] pk_script     76A91438D769CF2899983022B5611AB4D35BF7907DAE2088AC

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=00, decimal=0
WITNESS TXIN[2] stack elements: hex=00, decimal=0
WITNESS TXIN[3] stack elements: hex=04, decimal=4
 WITNESS data[0]: 00
 WITNESS data[1]: 4730440220...D207D14D45945A6901
 WITNESS data[2]: 4730440220...36B45FAFAEB96E0F01
 WITNESS data[3]: 695221021E...3234312D684C6553AE

LOCK_TIME 00000000
</code></pre>

<p>A good summary of all the segwit details <a href="https://bitcoincore.org/en/segwit_wallet_dev/" rel="nofollow noreferrer">is here</a>. </p>

CC BY-SA 4.0
2018-07-14T12:36:25.777Z
Thank you for you reply. May I ask what do you use to decode a TX with such detail? I am using [chainquery.com](http://chainquery.com)
Robert
CC BY-SA 4.0
2018-07-14T12:42:10.000Z
I learned through the book of Andreas and the forum here, so I wrote some unixoide shell scripts. And if self marketing is allowed (shamelessly), then the code can be found here: https://github.com/pebwindkraft/trx_cl_suite. The transaction suite has the tool (shell script) „tcls_tx2txt.sh“, to decode in the way shown above (and then I beautified it a bit, somit better fits in the forum here).
pebwindkraft
CC BY-SA 4.0
2018-07-14T12:54:34.313Z
Excellent. I'll play with the script on bash soon, thank you! This is useful for anyone interested in the community so I don't think it is like advertising :)
Robert
CC BY-SA 4.0
2018-07-14T09:12:04.373Z
2018-07-14T09:12:04.373Z
pebwindkraft
<blockquote>
<p>This structure contains data required to check transaction validity
but not required to determine transaction effects. In particular,
scripts and signatures are moved into this new structure.</p>
<p>The witness is a serialization of all witness data of the transaction.
Each txin is associated with a witness field. A witness field starts
with a var_int to indicate the number of stack items for the txin. It
is followed by stack items, with each item starts with a var_int to
indicate the length. Witness data is NOT script. See <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#transaction-id" rel="nofollow noreferrer">BIP 141</a>.</p>
</blockquote>
<p><em><strong>Witness data depends on the type of transaction.</strong></em></p>
<h2>Input 3</h2>
<p>Looking at transaction input #3 in the <a href="https://blockchain.info/rawtx/80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369" rel="nofollow noreferrer">raw json</a>:<br />
script = <code>a914771962306e72e479245d48e879dd2a1862225b4c87</code></p>
<p>This has the structure of a Pay to Script Hash (P2SH) transaction. Because of the witness data, this is probably a multisig <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wsh-nested-in-bip16-p2sh" rel="nofollow noreferrer">P2WSH nested in BIP16 P2SH</a>:</p>
<pre><code>witness:      0 &lt;signature1&gt; &lt;1 &lt;pubkey1&gt; &lt;pubkey2&gt; 2 CHECKMULTISIG&gt;
scriptSig:    &lt;0 &lt;32-byte-hash&gt;&gt;
              (0x220020{32-byte-hash})
scriptPubKey: HASH160 &lt;20-byte-hash&gt; EQUAL
              (0xA914{20-byte-hash}87)
</code></pre>
<p>witness:<br />
<code>04</code> (4 stack elements)</p>
<p><code>00</code> (1st stack element, 0 Bytes)</p>
<p><code>47</code> (2nd stack element, first signature, hex: 0x47 decimal: 71 Bytes)
<code>304402202c3f94e5daf4057377d9f16d45b57e962de42fb42cb7e95a0382b7c66624980a02204098f6acd43b0391ea1b4a8102797e78895848fb7e883f98d207d14d45945a6901</code></p>
<p><code>47</code> (3rd stack element, second signature, hex: 0x47 decimal: 71 Bytes)
<code>30440220448460edd5291a548c571ccf3a72caf47b02364035dc84f420d311e3a0c5494802205bb1cc89f20dc1e2c1f6eadb74898f8eecc46fbf488b676636b45fafaeb96e0f01</code></p>
<p><code>69</code> (4th stack element, 2-of-3 multisig script, hex: 0x69 decimal: 105 Bytes)<br />
<code>&lt;52 OP_2&gt;</code><br />
<code>21</code>  (33 bytes)<br />
<code>&lt;021e6617e06bb90f621c3800e8c37ab081a445ae5527f6c5f68a022e7133f9b5fe pubkey1&gt;</code><br />
<code>21</code>  (33 bytes)<br />
<code>&lt;03bea1a8ce6369435bb74ff1584a136a7efeebfe4bc320b4d59113c92acd869f38 pubkey2&gt;</code><br />
<code>21</code> (33 bytes)<br />
<code>&lt;0280631b27700baf7d472483fadfe1c4a7340a458f28bf6bae5d3234312d684c65 pubkey3&gt;</code>
<code>&lt;53 OP_3&gt;&lt;ae OP_CHECKMULTISIG&gt;</code></p>
<p>Note that the <code>OP_2</code> and <code>OP_3</code> indicate this is a 2-of-3 multisig transaction script.  See <a href="https://en.bitcoin.it/wiki/Transaction" rel="nofollow noreferrer">Pay-to-Script-Hash | Transaction</a></p>

CC BY-SA 4.0
2018-07-14T12:31:42.733Z
Thanks! I understand witness data much better now. One final clarification please.  So the command `OP_1` says  _take these two signatures and add them to the stack_.  `OP_2` instructs to _add the following three pubKeys_, and `OP_3` says _to validate this TX, 2 of 3 signatures corresponding to `OP_1` are needed_? Or 2 of 3 signatures **will be** needed to complete the TX in next INPUT?

Decoding the `scriptSig` for **Input 3** is not resulting in multiSig. `002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87` gives `type: scripthash`. Thanks again.
Robert
CC BY-SA 4.0
2018-07-14T13:42:40.263Z
Someone will have to correct me if I'm wrong, but I believe the 0x04 tells you that there are 4 stack elements, there is no OP_1 (there is an empty stack element, not sure why), the format for a multisig P2SH is:

`m-of-n multi-signature transaction:
scriptSig: 0 <sig1> ... <script>
script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIG`

See https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash
JBaczuk
CC BY-SA 4.0
2020-02-18T14:44:13.430Z
I know it is an old topic, but I would like a little more of information about the 4th stack element, as I saw it is the redeem script, but once I use the pubkeys to generate a the multisig key, it is different. Any thoughts?
Allan Romanato
CC BY-SA 4.0
2018-07-13T21:30:06.290Z
2019-11-13T15:10:06.117Z
2020-06-16T11:10:03.350Z
JBaczuk
<p>I've learned about the Segregated Witness but couldn't find info on breaking it down. </p>

<p>I know usually when legacy addresses are used the public keys for example will be under <code>Scriptig</code>.  With P2SH, I can see that the <code>ScriptSig</code> contains the hash of the <code>redeemScript</code> which must match the hash of the address in the Output ( I think). But I am not sure about the <code>witness</code> data.</p>

<p>Let's take this TX:
<a href="https://www.blockchain.com/en/btc/tx/80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369" rel="noreferrer">80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369</a></p>

<p>What info is in the <code>witness</code>, can someone break it down please? </p>

<segregated-witness><p2sh><witness-data>
What is the Witness and what data does it contain?
Robert
# What is the Witness and what data does it contain?

(Asked by: username_0 on 2018-07-13)

I've learned about the Segregated Witness but couldn't find info on breaking it down.

I know usually when legacy addresses are used the public keys for example will be under `Scriptig`. With P2SH, I can see that the `ScriptSig` contains the hash of the `redeemScript` which must match the hash of the address in the Output ( I think). But I am not sure about the `witness` data.

Let's take this TX:
[80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369](https://www.blockchain.com/en/btc/tx/80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369)

What info is in the `witness`, can someone break it down please?

**Tags:** segregated-witness, p2sh, witness-data


---

## 3 answers

### Answer by username_3 on 2018-07-13. Score: 11 | Accepted answer

> This structure contains data required to check transaction validity
> but not required to determine transaction effects. In particular,
> scripts and signatures are moved into this new structure.
>
> The witness is a serialization of all witness data of the transaction.
> Each txin is associated with a witness field. A witness field starts
> with a var\_int to indicate the number of stack items for the txin. It
> is followed by stack items, with each item starts with a var\_int to
> indicate the length. Witness data is NOT script. See [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#transaction-id).

***Witness data depends on the type of transaction.***

## Input 3

Looking at transaction input #3 in the [raw json](https://blockchain.info/rawtx/80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369):  
script = `a914771962306e72e479245d48e879dd2a1862225b4c87`

This has the structure of a Pay to Script Hash (P2SH) transaction. Because of the witness data, this is probably a multisig [P2WSH nested in BIP16 P2SH](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wsh-nested-in-bip16-p2sh):

```
witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig:    <0 <32-byte-hash>>
              (0x220020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
              (0xA914{20-byte-hash}87)

```

witness:  
`04` (4 stack elements)

`00` (1st stack element, 0 Bytes)

`47` (2nd stack element, first signature, hex: 0x47 decimal: 71 Bytes)
`304402202c3f94e5daf4057377d9f16d45b57e962de42fb42cb7e95a0382b7c66624980a02204098f6acd43b0391ea1b4a8102797e78895848fb7e883f98d207d14d45945a6901`

`47` (3rd stack element, second signature, hex: 0x47 decimal: 71 Bytes)
`30440220448460edd5291a548c571ccf3a72caf47b02364035dc84f420d311e3a0c5494802205bb1cc89f20dc1e2c1f6eadb74898f8eecc46fbf488b676636b45fafaeb96e0f01`

`69` (4th stack element, 2-of-3 multisig script, hex: 0x69 decimal: 105 Bytes)  
`<52 OP_2>`  
`21` (33 bytes)  
`<021e6617e06bb90f621c3800e8c37ab081a445ae5527f6c5f68a022e7133f9b5fe pubkey1>`  
`21` (33 bytes)  
`<03bea1a8ce6369435bb74ff1584a136a7efeebfe4bc320b4d59113c92acd869f38 pubkey2>`  
`21` (33 bytes)  
`<0280631b27700baf7d472483fadfe1c4a7340a458f28bf6bae5d3234312d684c65 pubkey3>`
`<53 OP_3><ae OP_CHECKMULTISIG>`

Note that the `OP_2` and `OP_3` indicate this is a 2-of-3 multisig transaction script. See [Pay-to-Script-Hash | Transaction](https://en.bitcoin.it/wiki/Transaction)

> **Comments:**
> **username_0**: Thanks! I understand witness data much better now. One final clarification please.  So the command `OP_1` says  _take these two signatures and add them to the stack_.  `OP_2` instructs to _add the following three pubKeys_, and `OP_3` says _to validate this TX, 2 of 3 signatures corresponding to `OP_1` are needed_? Or 2 of 3 signatures **will be** needed to complete the TX in next INPUT?  Decoding the `scriptSig` for **Input 3** is not resulting in multiSig. `002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87` gives `type: scripthash`. Thanks again.  
> **username_3**: Someone will have to correct me if I'm wrong, but I believe the 0x04 tells you that there are 4 stack elements, there is no OP_1 (there is an empty stack element, not sure why), the format for a multisig P2SH is:  `m-of-n multi-signature transaction: scriptSig: 0 <sig1> ... <script> script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIG`  See https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash  
> **username_4**: I know it is an old topic, but I would like a little more of information about the 4th stack element, as I saw it is the redeem script, but once I use the pubkeys to generate a the multisig key, it is different. Any thoughts?  

---

### Answer by username_1 on 2018-07-13. Score: 4

For the segwit variants of an output (P2PKH becomes P2WPKH and P2SH becomes P2WSH), the witness contains the same data that would be found in the scriptSig. For P2PKH, in the scriptSig, you would have a signature and a pubkey. The same is in the witness for a P2WPKH.

For P2SH, you would have a redeemScript, signatures, and other stuff in the scriptSig. For P2WSH, those are in the witness and the redeemScript in the witness is referred to as the witnessScript.

It is important to note that the witness will look different than the scriptSig. This is because it is not actually a script but rather a stack of elements. A standard scriptSig is one which only pushes elements to the stack. The witness takes this a step farther by providing a stack to use instead of having to execute a script which produces the same stack.


---

### Answer by username_2 on 2018-07-14. Score: 3

additional to username_3 and Andrew username_1, here is a detailed tx decoding.
This is a mixed transaction, with three "normal" inputs, and a 4th segwit type input (TX\_IN[3]). Therefor after the version field of the tx we see bytes "0001", with 0x01 indicating a segwit data structure is included in the tx. In the input section, there are three following "standard" elements, also with multisig signatures. The fourth input element (TX\_IN[3]) is the segwit part. The scripts is filled with no signatures, only the 0x0020{32-byte scripthash} structure.

At the end follows 0x00000004, each byte is the number of segwit elements per input. So the first three bytes are "0", meaning no segwit structure follows for these inputs, and then the fourth byte is 0x04, indicating four witness data elements: a "0x00" to compensate for the removal of the stack element during script evaluation, a signature, another signature and the redeem script.

```
VERSION 01000000
SEGWIT (BIP141):       this is a segwit tx, marker=00
       (BIP141):       flag=01
TX_IN COUNT [var_int]: hex=04, decimal=4
 TX_IN[0]
  TX_IN[0] OutPoint hash  08A1266CED5EF064741BD4BC51C1202456F22509AE030231860D6E9BEF4ACD5E
  TX_IN[0] OutPoint index hex=62000000, reversed=00000062, decimal=98
  TX_IN[0] Script Length  hex=FC, decimal=252
  TX_IN[0] Script Sig     0047304402207E38831ECA394E472E...555C0E2D7A9D9915D6986BFC200453AE 
  TX_IN[0] Sequence       FFFFFFFF
 TX_IN[1]
  TX_IN[1] OutPoint hash  AD4C8508B8D5EECE6FD100B58D667DEA9C7A8C178C1B06602C1E3358D8105C0B
  TX_IN[1] OutPoint index hex=7D000000, reversed=0000007D, decimal=125
  TX_IN[1] Script Length  hex=FC, decimal=252
  TX_IN[1] Script Sig     0047304402203299B925B1F2C87282...ABDC12E55B0F545FFF14667A515F53AE 
  TX_IN[1] Sequence       FFFFFFFF
 TX_IN[2]
  TX_IN[2] OutPoint hash  C8066B798384B502F225BD89F7EB405265357CB0BDC0C169FE96B013310629B2
  TX_IN[2] OutPoint index hex=A3000000, reversed=000000A3, decimal=163
  TX_IN[2] Script Length  hex=00FD, decimal=253
  TX_IN[2] Script Sig     0047304402204D4DA5303BE178D649...B5A43BC43D60C844F65DB8FB78AD53AE 
  TX_IN[2] Sequence       FFFFFFFF
 TX_IN[3]
  TX_IN[3] OutPoint hash  D80FF02D0D9EB2DA8C8A1C47AB099901F447DD197E34220EA13ECA72D7D6D21D
  TX_IN[3] OutPoint index hex=9A000000, reversed=0000009A, decimal=154
  TX_IN[3] Script Length  hex=23, decimal=35
  TX_IN[3] Script Sig     22002044C55C1DA36A576217259C3BC21B0C3943F7EB3FF4E3C381D9FD3502434B9E87 
  TX_IN[3] Sequence       FFFFFFFF
TX_OUT COUNT, hex=05, decimal=5
 TX_OUT[0]
  TX_OUT[0] Value         hex=C0D4010000000000, reversed_hex=000000000001D4C0, dec=120000
  TX_OUT[0] PK_Script Len hex=17, dec=23
  TX_OUT[0] pk_script     A914A1932CFD432D928311B4ADA550BBC468D1E909B787
 TX_OUT[1]
  TX_OUT[1] Value         hex=A086010000000000, reversed_hex=00000000000186A0, dec=100000
  TX_OUT[1] PK_Script Len hex=17, dec=23
  TX_OUT[1] pk_script     A9146B0E7A66416F1D8598B5956576ADB22DAF79853E87
 TX_OUT[2]
  TX_OUT[2] Value         hex=3A4A000000000000, reversed_hex=0000000000004A3A, dec=19002
  TX_OUT[2] PK_Script Len hex=17, dec=23
  TX_OUT[2] pk_script     A914EC4C73145428ABBE0B1C40FBF58C59F0EF3C29F487
 TX_OUT[3]
  TX_OUT[3] Value         hex=382C050000000000, reversed_hex=0000000000052C38, dec=339000
  TX_OUT[3] PK_Script Len hex=17, dec=23
  TX_OUT[3] pk_script     A914ABB18A298E5B629BF5652F341D2CD8207CCC214A87
 TX_OUT[4]
  TX_OUT[4] Value         hex=8010020000000000, reversed_hex=0000000000021080, dec=135296
  TX_OUT[4] PK_Script Len hex=19, dec=25
  TX_OUT[4] pk_script     76A91438D769CF2899983022B5611AB4D35BF7907DAE2088AC

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=00, decimal=0
WITNESS TXIN[2] stack elements: hex=00, decimal=0
WITNESS TXIN[3] stack elements: hex=04, decimal=4
 WITNESS data[0]: 00
 WITNESS data[1]: 4730440220...D207D14D45945A6901
 WITNESS data[2]: 4730440220...36B45FAFAEB96E0F01
 WITNESS data[3]: 695221021E...3234312D684C6553AE

LOCK_TIME 00000000

```

A good summary of all the segwit details [is here](https://bitcoincore.org/en/segwit_wallet_dev/).

> **Comments:**
> **username_0**: Thank you for you reply. May I ask what do you use to decode a TX with such detail? I am using [chainquery.com](http://chainquery.com)  
> **username_2**: I learned through the book of Andreas and the forum here, so I wrote some unixoide shell scripts. And if self marketing is allowed (shamelessly), then the code can be found here: https://github.com/username_2/trx_cl_suite. The transaction suite has the tool (shell script) „tcls_tx2txt.sh“, to decode in the way shown above (and then I beautified it a bit, somit better fits in the forum here).  
> **username_0**: Excellent. I'll play with the script on bash soon, thank you! This is useful for anyone interested in the community so I don't think it is like advertising :)  

---

