<p>part 1 of the question has been replied by Tony. </p>

<p>witness data is more than signature, you can have a pub key "behind" the signature, or a redeem script or other smart contracts. Take a look at V_IN scripts as of non-Segwit tx. </p>

<p>on the second part of your question:
The number at the beginning (the flag) identifies the number of inputs, that have witness data. You might create a tx, that has 5 inputs, e.g. 2 non segwit, and 3 segwit. Then this flag has a value of "3". </p>

<p>See this example with two V_INs, and the flag value being "1", cause only one part of the tx has Segwit/witness data. Also see at the end the number of segwit elements for referenced V_IN (TX_IN[1]). The first two elements is signature (with OP_SIGHASHSINGLE - hex 03 at the end!), the third element is a pub key. </p>

<pre><code>01000000000102FE3DC9208094F3FFD12645477B3DC56F60EC4FA8E6F5D67C565D1C6B9216B36E000000004847304402200AF4E47C9B9629DBECC21F73AF989BDAA911F7E6F6C2E9394588A3AA68F81E9902204F3FCF6ADE7E5ABB1295B6774C8E0ABD94AE62217367096BC02EE5E435B67DA201FFFFFFFF0815CF020F013ED6CF91D29F4202E8A58726B1AC6C79DA47C23D1BEE0A6925F80000000000FFFFFFFF0100F2052A010000001976A914A30741F8145E5ACADF23F751864167F32E0963F788AC000347304402200DE66ACF4527789BFDA55FC5459E214FA6083F936B430A762C629656216805AC0220396F550692CD347171CBC1EF1F51E15282E837BB2B30860DC77C8F78BC8501E503473044022027DC95AD6B740FE5129E7E62A75DD00F291A2AEB1200B84B09D9E3789406B6C002201A9ECD315DD6A0E632AB20BBB98948BC0C6FB204F2C286963BB48517A7058E27034721026DCCC749ADC2A9D0D89497AC511F760F45C47DC5ED9CF352A58AC706453880AEADAB210255A9626AEBF5E29C0E6538428BA0D1DCF6CA98FFDF086AA8CED5E0D0215EA465AC00000000

VERSION
 01000000

SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01

TX_IN COUNT [var_int]: hex=02, decimal=2
  TX_IN[0]:       6EB316926B1C5D567CD6F5E6A84FEC606FC53D7B474526D1FFF3948020C93DFE
  TX_IN[0] hex=00000000, reversed=00000000, decimal=0
  TX_IN[0] Script Length hex=48, decimal=72
  TX_IN[0] Script Sig (uchar[]) 47304402200AF4E47C9B9629DBECC21F73AF989BDAA911F7E6F6C2E9394588A3AA68F81E9902204F3FCF6ADE7E5ABB1295B6774C8E0ABD94AE62217367096BC02EE5E435B67DA201       
  TX_IN[0] Sequence (uint32_t)
  FFFFFFFF
  TX_IN[1] F825690AEE1B3DC247DA796CACB12687A5E802429FD291CFD63E010F02CF1508
  TX_IN[1] hex=00000000, reversed=00000000, decimal=0
  TX_IN[1] Script Length hex=00, decimal=0
  TX_IN[1] Sequence (uint32_t) FFFFFFFF

TX_OUT COUNT, hex=01, decimal=1
  TX_OUT[0] Value: hex=00F2052A01000000, dec=5000000000
  TX_OUT[0] PK_Script Length hex=19, dec=25
  TX_OUT[0] pk_script 76A914A30741F8145E5ACADF23F751864167F32E0963F788AC
  This is a P2PKH script, and translates base58 encoded into this bitcoin address: mvNy8bVyGDyuCiS1zMzm61eDtCBbUVfHPD

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=03, decimal=3
 WITNESS[0] data length (var_int), hex=47, decimal=71, data(uchar[]):
  304402200DE66ACF4527789BFDA55FC5459E214FA6083F936B430A762C629656216805AC0220396F550692CD347171CBC1EF1F51E15282E837BB2B30860DC77C8F78BC8501E503
 WITNESS[1] data length (var_int), hex=47, decimal=71, data(uchar[]):
  3044022027DC95AD6B740FE5129E7E62A75DD00F291A2AEB1200B84B09D9E3789406B6C002201A9ECD315DD6A0E632AB20BBB98948BC0C6FB204F2C286963BB48517A7058E2703
 WITNESS[2] data length (var_int), hex=47, decimal=71, data(uchar[]):
  21026DCCC749ADC2A9D0D89497AC511F760F45C47DC5ED9CF352A58AC706453880AEADAB210255A9626AEBF5E29C0E6538428BA0D1DCF6CA98FFDF086AA8CED5E0D0215EA465AC

 LOCK_TIME
00000000
</code></pre>

CC BY-SA 3.0
2018-02-01T12:11:35.367Z
2018-02-01T12:11:35.367Z
pebwindkraft
<p>If by witness version you mean the script version that was added with the SegWit upgrade, <a href="https://bitcoincore.org/en/2016/01/26/segwit-benefits/" rel="nofollow noreferrer">this blog post</a> from Bitcoin Core explains the implications of this version number:</p>

<blockquote>
  <p>Segwit resolves this by including a version number for scripts, so that additional opcodes that would have required a hard-fork to be used in non-segwit transactions can instead be supported by simply increasing the script version.</p>
</blockquote>

<p>For your second question, your intuition is correct. The number corresponds to the number of inputs.</p>

CC BY-SA 3.0
2018-01-31T11:18:37.100Z
thank you for your answer. What about txins that are n-of-m signatures? Let's say I make a segwit tx with 4 txins: 3 regular p2wpkh and 1 p2wsh with 5-of-8 signatures. the leading var_int will be here 4 or 8?
skydanc3r
CC BY-SA 3.0
2018-01-31T21:07:10.607Z
@skydanc3r the protocol documentation describes the witness data as “A list of witnesses, one for each input...” under the table for the tx data structure. Ref: https://en.bitcoin.it/wiki/Protocol_documentation#tx
Tony Rizko
CC BY-SA 3.0
2018-01-31T21:38:26.863Z
in this case regarding my question in the second comment the witness will contain redeemScript + signatures (5 out of 8) and be counted as 1 witness element?
skydanc3r
CC BY-SA 3.0
2018-02-01T03:17:10.707Z
@skydanc3r i’m not exactly sure about that but I think that question would warrant another separate question post. I would also be very interested in the answer to that question.
Tony Rizko
CC BY-SA 3.0
2018-01-31T02:06:10.873Z
2018-02-01T05:04:23.553Z
2018-02-01T05:04:23.553Z
Tony Rizko
<p>What is the witness version and how is it used?</p>

<p>A segwit transaction is comprised of:
[nVersion][marker][flag][txins][txouts][witness][nLockTime]</p>

<p>From the BIP: "A witness field starts with a var_int to indicate the number of stack items for the txin."</p>

<p>Where does the witness version come in and in what scenarios can it be used?</p>

<p>Secondly, why does it say witness field starts with a var_int to indicate the number of stack items for the txin -- isn't witness data just signature? Or it simply refers to transactions that have more inputs, and the leading var_init just counts the number of inputs, thus signatures expected?</p>

<transactions><segregated-witness>
what is the explanation of "witness version" and its usage?
skydanc3r
# what is the explanation of "witness version" and its usage?

(Asked by: username_0 on 2018-01-31)

What is the witness version and how is it used?

A segwit transaction is comprised of:
[nVersion][marker][flag][txins][txouts][witness][nLockTime]

From the BIP: "A witness field starts with a var\_int to indicate the number of stack items for the txin."

Where does the witness version come in and in what scenarios can it be used?

Secondly, why does it say witness field starts with a var\_int to indicate the number of stack items for the txin -- isn't witness data just signature? Or it simply refers to transactions that have more inputs, and the leading var\_init just counts the number of inputs, thus signatures expected?

**Tags:** transactions, segregated-witness


---

## 2 answers

### Answer by username_1 on 2018-02-01. Score: 1 | Accepted answer

part 1 of the question has been replied by username_2.

witness data is more than signature, you can have a pub key "behind" the signature, or a redeem script or other smart contracts. Take a look at V\_IN scripts as of non-Segwit tx.

on the second part of your question:
The number at the beginning (the flag) identifies the number of inputs, that have witness data. You might create a tx, that has 5 inputs, e.g. 2 non segwit, and 3 segwit. Then this flag has a value of "3".

See this example with two V\_INs, and the flag value being "1", cause only one part of the tx has Segwit/witness data. Also see at the end the number of segwit elements for referenced V\_IN (TX\_IN[1]). The first two elements is signature (with OP\_SIGHASHSINGLE - hex 03 at the end!), the third element is a pub key.

```
01000000000102FE3DC9208094F3FFD12645477B3DC56F60EC4FA8E6F5D67C565D1C6B9216B36E000000004847304402200AF4E47C9B9629DBECC21F73AF989BDAA911F7E6F6C2E9394588A3AA68F81E9902204F3FCF6ADE7E5ABB1295B6774C8E0ABD94AE62217367096BC02EE5E435B67DA201FFFFFFFF0815CF020F013ED6CF91D29F4202E8A58726B1AC6C79DA47C23D1BEE0A6925F80000000000FFFFFFFF0100F2052A010000001976A914A30741F8145E5ACADF23F751864167F32E0963F788AC000347304402200DE66ACF4527789BFDA55FC5459E214FA6083F936B430A762C629656216805AC0220396F550692CD347171CBC1EF1F51E15282E837BB2B30860DC77C8F78BC8501E503473044022027DC95AD6B740FE5129E7E62A75DD00F291A2AEB1200B84B09D9E3789406B6C002201A9ECD315DD6A0E632AB20BBB98948BC0C6FB204F2C286963BB48517A7058E27034721026DCCC749ADC2A9D0D89497AC511F760F45C47DC5ED9CF352A58AC706453880AEADAB210255A9626AEBF5E29C0E6538428BA0D1DCF6CA98FFDF086AA8CED5E0D0215EA465AC00000000

VERSION
 01000000

SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01

TX_IN COUNT [var_int]: hex=02, decimal=2
  TX_IN[0]:       6EB316926B1C5D567CD6F5E6A84FEC606FC53D7B474526D1FFF3948020C93DFE
  TX_IN[0] hex=00000000, reversed=00000000, decimal=0
  TX_IN[0] Script Length hex=48, decimal=72
  TX_IN[0] Script Sig (uchar[]) 47304402200AF4E47C9B9629DBECC21F73AF989BDAA911F7E6F6C2E9394588A3AA68F81E9902204F3FCF6ADE7E5ABB1295B6774C8E0ABD94AE62217367096BC02EE5E435B67DA201       
  TX_IN[0] Sequence (uint32_t)
  FFFFFFFF
  TX_IN[1] F825690AEE1B3DC247DA796CACB12687A5E802429FD291CFD63E010F02CF1508
  TX_IN[1] hex=00000000, reversed=00000000, decimal=0
  TX_IN[1] Script Length hex=00, decimal=0
  TX_IN[1] Sequence (uint32_t) FFFFFFFF

TX_OUT COUNT, hex=01, decimal=1
  TX_OUT[0] Value: hex=00F2052A01000000, dec=5000000000
  TX_OUT[0] PK_Script Length hex=19, dec=25
  TX_OUT[0] pk_script 76A914A30741F8145E5ACADF23F751864167F32E0963F788AC
  This is a P2PKH script, and translates base58 encoded into this bitcoin address: mvNy8bVyGDyuCiS1zMzm61eDtCBbUVfHPD

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=03, decimal=3
 WITNESS[0] data length (var_int), hex=47, decimal=71, data(uchar[]):
  304402200DE66ACF4527789BFDA55FC5459E214FA6083F936B430A762C629656216805AC0220396F550692CD347171CBC1EF1F51E15282E837BB2B30860DC77C8F78BC8501E503
 WITNESS[1] data length (var_int), hex=47, decimal=71, data(uchar[]):
  3044022027DC95AD6B740FE5129E7E62A75DD00F291A2AEB1200B84B09D9E3789406B6C002201A9ECD315DD6A0E632AB20BBB98948BC0C6FB204F2C286963BB48517A7058E2703
 WITNESS[2] data length (var_int), hex=47, decimal=71, data(uchar[]):
  21026DCCC749ADC2A9D0D89497AC511F760F45C47DC5ED9CF352A58AC706453880AEADAB210255A9626AEBF5E29C0E6538428BA0D1DCF6CA98FFDF086AA8CED5E0D0215EA465AC

 LOCK_TIME
00000000

```


---

### Answer by username_2 on 2018-01-31. Score: 1

If by witness version you mean the script version that was added with the SegWit upgrade, [this blog post](https://bitcoincore.org/en/2016/01/26/segwit-benefits/) from Bitcoin Core explains the implications of this version number:

> Segwit resolves this by including a version number for scripts, so that additional opcodes that would have required a hard-fork to be used in non-segwit transactions can instead be supported by simply increasing the script version.

For your second question, your intuition is correct. The number corresponds to the number of inputs.

> **Comments:**
> **username_0**: thank you for your answer. What about txins that are n-of-m signatures? Let's say I make a segwit tx with 4 txins: 3 regular p2wpkh and 1 p2wsh with 5-of-8 signatures. the leading var_int will be here 4 or 8?  
> **username_2**: @username_0 the protocol documentation describes the witness data as “A list of witnesses, one for each input...” under the table for the tx data structure. Ref: https://en.bitcoin.it/wiki/Protocol_documentation#tx  
> **username_0**: in this case regarding my question in the second comment the witness will contain redeemScript + signatures (5 out of 8) and be counted as 1 witness element?  
> **username_2**: @username_0 i’m not exactly sure about that but I think that question would warrant another separate question post. I would also be very interested in the answer to that question.  

---

