Different data values for the same transaction for outbound x inbound connection

[Thomason222]

Hi,

just doing some analysis in Wireshark for my deeper Bitcoin transaction understanding, and I find some things I do not understand.
When I filter the transaction by the hex value, which is raw transaction data, it finds me some records, but the values in the Tx message is really weird, they do not correspond to the ones find in the mempool space. For example, in the Transaction output, the Value and Script are so long. Same for the Block lock time or block ID. Each of this records points me toward outband peer.

When I filter for example the exact ScriptPubKey (HEX), it points me again to the previous records, but it finds also the record, that is corresponding exactly with the data find in the mempool.space. The interesting thing is, that when the records are exactly the same as in the mempool.space, its for the inbound connections.

My question is, why is it like this?
Transaction is: 3ceee5608d357b2f8d7f39ab8c441eb688ef54efb8051b49fb141787fe26aa7b

[1714549062]

1714549062

[1714549062]

1714549062

[1714549062]

1714549062

[pooya87]

For example, in the Transaction output, the Value and Script are so long.

What do you consider long?
For example the output amount value is always 8 bytes (64 bits) so it doesn't matter if you are paying 10000 satoshis like in your second output, the value will be: 0xa086010000000000 in little endian order.

Same for the Block lock time or block ID.

Transactions have lock time (not blocks) and it should be 4 bytes at the end of the tx hex. So when you set it to 777655 the hex value for it is 0xb7dd0b00.
There also should not be any block ID in a tx message.

Posting exactly what Wireshark shows may get you a better answer.

[Thomason222]

This is what I see when filtering by raw transaction data:
Bitcoin protocol
    Packet magic: 0xf9beb4d9
    Command name: tx
    Payload Length: 370
    Payload checksum: 0x7e0ee856
    Tx message
        Transaction version: 2
        Input Count: 0
        Output Count: 1
        Transaction output
            Value: 4883631285645190914
            Script Length: 89
            Script: 875bb05d7ffc73aa57300b826cd2227a6c9f0bab7713be420000000000fdffffff2f6f5c6a81926 8a4c95435dc4ed7182a262408217017cad749b504cdbb00a2650000000000fdffffff02bb840100 00000000160014ac3ec5
        Block lock time or block ID: 1849243303

And when filtering by ScriptPubKey I see the above but also this in some records:
Bitcoin protocol
    Packet magic: 0xf9beb4d9
    Command name: tx
    Payload Length: 154
    Payload checksum: 0x7baa26fe
    Tx message
        Transaction version: 2
        Input Count: 2
        Transaction input
        Transaction input
        Output Count: 2
        Transaction output
            Value: 99515
            Script Length: 22
            Script: 0014ac3ec5a736396e82c09cd23e878d4b2ff6fdd528
        Transaction output
            Value: 100000
            Script Length: 22
            Script: 001441fa737e6b1c886a6ddf535fa944e1af08c9fad8
        Block lock time or block ID: 777655

[Thomason222]

++ I was able to filter the INV messages by applying: bitcoin.inv.hash == TXID (Natural Byte Order), it shows me INV messages only through INBOUND peers. For outbound peers, it does not show anything, which is strange.

[NotATether]

This is what I see when filtering by raw transaction data:
Bitcoin protocol
    Packet magic: 0xf9beb4d9
    Command name: tx
    Payload Length: 370
    Payload checksum: 0x7e0ee856
    Tx message
        Transaction version: 2
        Input Count: 0
        Output Count: 1
        Transaction output
            Value: 4883631285645190914
            Script Length: 89
            Script: 875bb05d7ffc73aa57300b826cd2227a6c9f0bab7713be420000000000fdffffff2f6f5c6a81926 8a4c95435dc4ed7182a262408217017cad749b504cdbb00a2650000000000fdffffff02bb840100 00000000160014ac3ec5
        Block lock time or block ID: 1849243303

And when filtering by ScriptPubKey I see the above but also this in some records:
Bitcoin protocol
    Packet magic: 0xf9beb4d9
    Command name: tx
    Payload Length: 154
    Payload checksum: 0x7baa26fe
    Tx message
        Transaction version: 2
        Input Count: 2
        Transaction input
        Transaction input
        Output Count: 2
        Transaction output
            Value: 99515
            Script Length: 22
            Script: 0014ac3ec5a736396e82c09cd23e878d4b2ff6fdd528
        Transaction output
            Value: 100000
            Script Length: 22
            Script: 001441fa737e6b1c886a6ddf535fa944e1af08c9fad8
        Block lock time or block ID: 777655

To me it looks like the packets are not being parsed properly or there is an endianness error in the first packet at least.

Look at the script for the first packet for example:

875bb05d7ffc73aa57300b826cd2227a6c9f0bab7713be420000000000fdffffff2f6f5c6a81926 8a4c95435dc4ed7182a262408217017cad749b504cdbb00a2650000000000fdffffff02bb840100 00000000160014ac3ec5

It ends with 14ac3ec5 which is what the script of the first output in the second packet also starts with.

The 0x16 before it also aligns with the script length of 22. Same with the transaction output value immediately before that too.

My hunch is that Wireshark is not interpreting your packets properly.

[Thomason222]

It seems like the likeliest option. Thanks for the analysis