Bip143 hashing examples question

[Valle]

Hi! I'm checking out examples of Bip143 hashing from https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki and there is one thing I don't quite understand, looks like it's a bug in the example.

First example hashes second input with outPoint ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a. I reproduced hash calculation, no problems here but the example then provides resulted signed transaction where the second input with outPoint ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a is empty and instead there is signature for first input(?):

The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0 0000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5c dd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eef fffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000 ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9 093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402 203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4 518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1 ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000
 
    nVersion:  01000000
    marker:    00
    flag:      01
    txin:      02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be0 22040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01 eeffffff

                  ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff
    txout:     02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac
                  9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac
    witness    00
               02 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a02205 73a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357
    nLockTime: 11000000

Is this really a bug in the example or I miss something?

[1714143284]

1714143284

[1714143284]

1714143284

[1714143284]

1714143284

[achow101]

Is this really a bug in the example or I miss something?

You are missing something. The first input is not a segwit input, so the hash calculation for that was ignored and skipped over. The second input is a segwit input, and is P2WPKH. This means that the scriptSig will be empty. The txwitness field contains the signature for the second input.

[Valle]

Is this really a bug in the example or I miss something?

You are missing something. The first input is not a segwit input, so the hash calculation for that was ignored and skipped over. The second input is a segwit input, and is P2WPKH. This means that the scriptSig will be empty. The txwitness field contains the signature for the second input.

OK, thank you!

[Valle]

This actually raises another question that how VerifyScript() works if scriptSig is empty and scriptPubKey "OP_DUP OP_HASH160 1d0f172a0ecb48aee1be1f2687d2963ae33f71a1 OP_EQUALVERIFY OP_CHECKSIG" which fails on OP_DUP with empty stack but it's something I'll have to figure out by myself.

[achow101]

This actually raises another question that how VerifyScript() works if scriptSig is empty and scriptPubKey "OP_DUP OP_HASH160 1d0f172a0ecb48aee1be1f2687d2963ae33f71a1 OP_EQUALVERIFY OP_CHECKSIG" which fails on OP_DUP with empty stack but it's something I'll have to figure out by myself.

Segwit does not use that as the scriptPubKey. Only segwit output scripts use BIP 143.