Tags were calculated via tlbc as follows (request_flag is equal to 0x7fffffff and response flag is equal to 0x80000000):
crc32('transfer query_id:uint64 new_owner:MsgAddress response_destination:MsgAddress custom_payload:Maybe ^Cell forward_amount:VarUInteger 16 forward_payload:Either Cell ^Cell = InternalMsgBody') = 0x5fcc3d14 & 0x7fffffff = 0x5fcc3d14
crc32('ownership_assigned query_id:uint64 prev_owner:MsgAddress forward_payload:Either Cell ^Cell = InternalMsgBody') = 0x85138d91 & 0x7fffffff = 0x05138d91
more....
My question is why the first and second one got different result:
0x5fcc3d14 & 0x7fffffff => 0x5fcc3d14 🟢
0x85138d91 & 0x7fffffff => 0x05138d91 ❓
Answer
Hex digit 0xF has the binary representation 1111. Anything that is & with it will remain the same.
Hex digit 0x7 has this binary representation: 0111. Anything that is & with it will lost the first bit, or the first bit becomes zero.
In your first example, 0x5... & 0x7... remains 0x5... because 5 has binary represenation 0101 and the first bit is already 0.
In your second example, 0x8... & 0x7... changed to 0x0... because 8 has binary representation 1000 and after setting the first bit to 0 we will have 0000 or hex digit 0x0.
My question is why the first and second one got different result:
0x5fcc3d14 & 0x7fffffff => 0x5fcc3d14 🟢
0x85138d91 & 0x7fffffff => 0x05138d91 ❓
Answer
Hex digit
0xFhas the binary representation1111. Anything that is&with it will remain the same.Hex digit
0x7has this binary representation:0111. Anything that is&with it will lost the first bit, or the first bit becomes zero.In your first example,
0x5... & 0x7...remains0x5...because5has binary represenation0101and the first bit is already0.In your second example,
0x8... & 0x7...changed to0x0...because8has binary representation1000and after setting the first bit to0we will have0000or hex digit0x0.Original