Inconsistent data for the same transaction between outbound and inbound connections

Hey folks, I'm diving into some analysis with Wireshark to better understand Bitcoin transactions, but I've hit a bit of a snag. When I filter transactions using the hex value, which is the raw transaction data, I get some records, but the values in the Tx message look really off. They don't match what I see in the mempool space. Like, the Transaction output has super long Value and Script fields. Same goes for the Block lock time or block ID. All these records seem to point back to an outbound peer. Then, when I filter by the exact ScriptPubKey (HEX), I see the same earlier records, but also one that matches exactly with the data from mempool.space. The weird part is that when the records match the mempool.space data, they're tied to inbound connections. So, why does this happen? Transaction ID: 3ceee5608d357b2f8d7f39ab8c441eb688ef54efb8051b49fb141787fe26aa7b

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. 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.

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

++ 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.

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.

It seems like the likeliest option. Thanks for the analysis