Confusing Data Values in Bitcoin Transactions

5 replies 96 views
Posts: 252 · Reputation: 12
#1Oct 19, 2018, 01:40 PM
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?
3 Reply Quote Share
mr_apeNewbie
Posts: 401 · Reputation: 35
#2Oct 20, 2018, 01:22 PM
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.
3 Reply Quote Share
Posts: 252 · Reputation: 12
#3Oct 20, 2018, 06:24 PM
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.
0 Reply Quote Share
Posts: 252 · Reputation: 12
#4Oct 20, 2018, 10:40 PM
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.
4 Reply Quote Share
0xNodeMember
Posts: 671 · Reputation: 80
#5Oct 21, 2018, 01:23 AM
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.
6 Reply Quote Share
Posts: 252 · Reputation: 12
#6Oct 21, 2018, 06:30 AM
Yeah, that definitely seems like the case. Appreciate your breakdown!
4 Reply Quote Share

Related topics