[dump][testnet]tx version and sequence_no

[Frodek]

I run my dump program on testnet. Block 873032 is small and seems correct.
In block 873033 is all bad (in my dump):
inCounter=0 - no Coinbase; outCounter=1 but scriptlen= 0;
next transaction are version = 0;
transaction 3 has version=-1 and memory exception because of large scriptlen
This block is not normal ? (witness?) Bitcoin Core client can dump it?

In Google Drive are two dumps, I can't simply attach txt in this forum.

https://drive.google.com/open?id=0B7E799YMGCWTYzl3eDZpQ04wT00

https://drive.google.com/open?id=0B7E799YMGCWTZFN3b2hrR1dYU2c

[1714910780]

1714910780

[arubi]

The generation tx in that block does have a witness and you're probably parsing the marker byte ( 0x00 ) as if it means "zero inputs".

Try running the client with the -rpcserialversion=0 flag and try parsing it again.  You should look into bip141 for what segwit serialization looks like.

[Frodek]

Thanks, how recognize how block has witness (bip141) or not. I want write dump for both case: usual and witness but how recognize if is need it?

[Frodek]

Ok, transactions, not block may be witness..
I try dump 873033 from testnet:
Transaction 8:
transaction 8:
at 4487: version=1, len=4
at 4491: marker=0, varlen=1
at 4492: witness flag=1, len=1
at 4493: inCounter=1, varlen=1
  at 4494: input 0/1:
  hash 32 bytes
  prev tx=5b0705aa614f7a8579f868b65289b499f3ae4693cdd11b47364fc17b4f8d0bd1
  at 4526: inputTx.index(previous) len=4
  at 4530: scriptLen=23 varlen=1
  at 4531: input script[0](len=23)=1600146e5a9e498616fbf8ae1eff60c58fccde69b58673
  at 4554: sequence_no=-1 len=4
at 4558: outCounter=1, varlen=1
  at 4559: output 0/1 value=49900000 len=8
  at 4567: scriptLen=23 varlen=1
  at 4568: output script[0](len=23)=a9148145bd99ed2b6a539beadb478717cb43a3f9102287
Witness data at 4591:
at 4591: witCount=2, varlen=1
at 4592: witLen=72, varlen=1
at 4665: witLen=33, varlen=1
at 4699: lockTime=0 len=4

Why inCounter=1 is not equal witCount=2? How use witData having witLen length?

[Frodek]

I have Block 872730:
at 10006: witCount=2, varlen=1
at 10007: witLen=72, varlen=1
at 10080: witLen=33, varlen=1
<---- here inserted one byte !!!!
at 10115: lockTime=872729 len=4
transaction 44:
at 10119: version=1, len=4

Why I must insert one byte before transaction 44?
https://drive.google.com/open?id=0B7E799YMGCWTc3BUNFNndUVLS2c

[arubi]

Why inCounter=1 is not equal witCount=2? How use witData having witLen length?

Code:

5ca369bcf633ffdaef635b0778baf2543c191f565436504738a06f8c29dcb319 :

version : 01000000
ptr : 8
segwit_tx : 1
swmarker : 00
swflag : 01
ptr : 12
num_inputs : 1
ptr : 14
txid_index[0] : D10B8D4F7BC14F36471BD1CD9346AEF399B48952B668F879857A4F61AA05075B01000000
ptr : 86
in_script_size[0] : 17
ptr : 88
in_script[0] : 1600146E5A9E498616FBF8AE1EFF60C58FCCDE69B58673
ptr : 134
in_seq[0] : FFFFFFFF
ptr : 142
num_outputs : 1
ptr : 144
out_amount : E069F90200000000
ptr : 160
out_script_size[0] : 17
ptr : 162
out_script[0] : A9148145BD99ED2B6A539BEADB478717CB43A3F9102287
ptr : 208
num_wits[0] : 2
ptr : 210
wit_size : 48
ptr : 212
tmpwits[0] : 483045022100883892D8D95E33D2F3968702653E7005786F35D6CD2AB5AD25729A87BFA41BFE02202BAC1AD96DA21FEDF7CE0290E85BB34D7553E75766BBC2F8187B6CAE25ED863601
ptr : 356
wit_size : 21
ptr : 358
tmpwits[1] : 2102A7082D3C292129FD18D0F49B7614657E1613FCCC2BDEBE40AA8B828C01A69B66
ptr : 424
in_wits[0] : 483045022100883892D8D95E33D2F3968702653E7005786F35D6CD2AB5AD25729A87BFA41BFE02202BAC1AD96DA21FEDF7CE0290E85BB34D7553E75766BBC2F8187B6CAE25ED863601 2102A7082D3C292129FD18D0F49B7614657E1613FCCC2BDEBE40AA8B828C01A69B66
nlocktime : 00000000

That "witness count" is just how many items are in this current witness' stack.
For this witness there is the signature and the pubkey, so the witness count is "2".
This entire witness with its two items is used by the first input input in the transaction. You can see the transaction is redeeming a p2sh(p2wpkh).

--------------------

Why I must insert one byte before transaction 44?

Code:

118c83b2c7aa4b500e0c0333dbfef990ca6c324004d68f68acb10ddada918474 : 

version : 01000000
ptr : 8
segwit_tx : 1
swmarker : 00
swflag : 01
ptr : 12
num_inputs : 2
ptr : 14
txid_index[0] : 0D668D9CEE347DD5256BEAC4D3A6E6CB6AA6EA1AF197D0C3EC08359223139E1B00000000
ptr : 86
in_script_size[0] : 17
ptr : 88
in_script[0] : 1600143F0402FCB8BEEF28A89BE7E94794EC66D469FDB6
ptr : 134
in_seq[0] : FEFFFFFF
ptr : 142
txid_index[1] : 0D668D9CEE347DD5256BEAC4D3A6E6CB6AA6EA1AF197D0C3EC08359223139E1B01000000
ptr : 214
in_script_size[1] : 6B
ptr : 216
in_script[1] : 483045022100EACEEE00202693D7D54AA84BD8B216F62B1F041B16E08E0352EB1ED50F1EF10102201A90288F667F975CC8D524431D61BD8B15F5D189610D31A9BD12EE37C0674F06012103C4561CE27291B1730E5A429934F45FB4FF9B56E24B6E10E0D176F198FA029671
ptr : 430
in_seq[1] : FEFFFFFF
ptr : 438
num_outputs : 2
ptr : 440
out_amount : 506C980000000000
ptr : 456
out_script_size[0] : 19
ptr : 458
out_script[0] : 76A9140AF575373DAD17150D91B6A191A371B59E09D87F88AC
ptr : 508
out_amount : 001C4E0E00000000
ptr : 524
out_script_size[1] : 17
ptr : 526
out_script[1] : A91403572C975AEC5228C0E2982EF8A03B6830E0554F87
ptr : 572
num_wits[0] : 2
ptr : 574
wit_size : 48
ptr : 576
tmpwits[0] : 483045022100913D331B78A2C1A2EC0E2AF7A826181F26E15E0195CEF13F492D2E22B8DD9E2C02201F808621F9684574CBBD755933509F6BCE7536AA5C36DD4C57FD635E5485404901
ptr : 720
wit_size : 21
ptr : 722
tmpwits[1] : 2103E2728BDC007032F5B30C823F4A3CD9236EAB5E3A6F23C6AE6BE8BD63FF847922
ptr : 788
in_wits[0] : 483045022100913D331B78A2C1A2EC0E2AF7A826181F26E15E0195CEF13F492D2E22B8DD9E2C02201F808621F9684574CBBD755933509F6BCE7536AA5C36DD4C57FD635E5485404901 2103E2728BDC007032F5B30C823F4A3CD9236EAB5E3A6F23C6AE6BE8BD63FF847922
num_wits[1] : 0
ptr : 790
in_wits[1] :
nlocktime : 19510d00

In here the same thing happens with the first input.  It also redeems a p2sh(p2wpkh) so we see the normal witness stack of two items, the signature and the pubkey.
The second input redeems a non-segwit scriptpubkey.  By bip141 rules, when a segwit input and a non segwit input are redeemed in the same transaction, the non-segwit input will have an empty witness.  That is the single 0x00 byte that tells you "this is a witness stack of 0 items"
(note that because you didn't parse the "empty stack" byte, your nlocktime was shifted.  the final byte in the nlocktime is also 0x00, but it's not the same byte that you asked about) - sorry, my bad.  you asked about the right byte.