NPosts: 252 · Reputation: 12
Hey everyone,
I'm diving into Wireshark to get a better grasp on Bitcoin transactions, but I'm hitting some weird stuff.
Like, when I filter a transaction using its hex data, the values I see in the Tx message don't add up at all. They look way off compared to what's in the mempool. For instance, the transaction output values and scripts are super long. Not to mention the block lock time and block ID seem all messed up. Any thoughts?
MrPosts: 401 · Reputation: 35
What do you mean by 'long'?
Just to clarify, output amounts are always 8 bytes (or 64 bits). So whether you're sending 10,000 satoshis or whatever, it'll show up as 0xa086010000000000 in little-endian format.
Lock time is actually 4 bytes, found at the end of the tx hex. Setting it to 777655 shows 0xb7dd0b00 in hex. Also, there shouldn’t be any block ID in a tx message.
NPosts: 252 · Reputation: 12
Here’s what I see when I filter 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: 875bb05d...
Block lock time or...
This is confusing me.
NPosts: 252 · Reputation: 12
I noticed the same when I filtered INV messages with: bitcoin.inv.hash == TXID.
It only shows INV messages from INBOUND peers. No signals from outbound peers, which seems odd.
0Posts: 671 · Reputation: 80
Sounds like the packets might not be parsed right or there’s an endianness issue with the first packet.
Take a look at that script for the first packet:
875bb05d7ffc73aa57300b826cd2227a6c9f0bab7713be420000000000fdffffff...
It ends with 14ac3ec5, which is also the start of the first output in the next packet. The 0x16 matches the script length too.
There’s some weird overlap in values.
NPosts: 252 · Reputation: 12
Yeah, that definitely seems like the case. Appreciate your breakdown!