Topic: varint in client version 3210 not according to spec? (Read 867 times)
Ah yes makes perfect sense. Thank you (both)
According to the spec, varint should do:
<= 0xffff 3 0xfd + uint16_t
So what it seems to do is only setting the total value in the next two bytes without subtracting 253 of it.
<= 0xffff 3 0xfd + uint16_t
So what it seems to do is only setting the total value in the next two bytes without subtracting 253 of it.
Not a bug. The "+" here is meant as concatenation of bytes.
One byte with 0xFD, then 2 bytes with the value.
According to the spec, varint should do:
<= 0xffff 3 0xfd + uint16_t
So what it seems to do is only setting the total value in the next two bytes without subtracting 253 of it.
<= 0xffff 3 0xfd + uint16_t
So what it seems to do is only setting the total value in the next two bytes without subtracting 253 of it.
The mainstream client is the only spec that matters at the moment. From serialize.h
Code:
void WriteCompactSize(Stream& os, uint64 nSize)
{
if (nSize < 253)
{
unsigned char chSize = nSize;
WRITEDATA(os, chSize);
}
else if (nSize <= USHRT_MAX)
{
unsigned char chSize = 253;
unsigned short xSize = nSize;
WRITEDATA(os, chSize);
WRITEDATA(os, xSize);
}
etc...
{
if (nSize < 253)
{
unsigned char chSize = nSize;
WRITEDATA(os, chSize);
}
else if (nSize <= USHRT_MAX)
{
unsigned char chSize = 253;
unsigned short xSize = nSize;
WRITEDATA(os, chSize);
WRITEDATA(os, xSize);
}
etc...
So yes, small numbers have multiple representations.
ByteCoin
Hi all,
As I am rebuilding the protocol in python and testing it out with some tcpdumps gathered with the official client, I noticed that my client (version 3210) on a getdata message sends out the wrong count.
The offending hex is: FD9A01
After investigating I found that for this particular example my count is 663 while the actual entries are 410
According to the spec, varint should do:
<= 0xffff 3 0xfd + uint16_t
So what it seems to do is only setting the total value in the next two bytes without subtracting 253 of it.
Is this a known error in this older build and is it solved in a newer version (I am on FreeBSD btw)?
On a side note, is this forum the appropriate media to report such unconfirmed things or should I shout somewhere else, perhaps a more stable medium?
Cheers and Thanks,
Martin
As I am rebuilding the protocol in python and testing it out with some tcpdumps gathered with the official client, I noticed that my client (version 3210) on a getdata message sends out the wrong count.
The offending hex is: FD9A01
After investigating I found that for this particular example my count is 663 while the actual entries are 410
According to the spec, varint should do:
<= 0xffff 3 0xfd + uint16_t
So what it seems to do is only setting the total value in the next two bytes without subtracting 253 of it.
Is this a known error in this older build and is it solved in a newer version (I am on FreeBSD btw)?
On a side note, is this forum the appropriate media to report such unconfirmed things or should I shout somewhere else, perhaps a more stable medium?
Cheers and Thanks,
Martin
Jump to: