Bitcoin Forum
December 04, 2016, 06:37:02 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: varint in client version 3210 not according to spec?  (Read 618 times)
Martin P. Hellwig
Jr. Member
*
Offline Offline

Activity: 33


View Profile
June 14, 2011, 11:24:52 PM
 #1

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
1480876622
Hero Member
*
Offline Offline

Posts: 1480876622

View Profile Personal Message (Offline)

Ignore
1480876622
Reply with quote  #2

1480876622
Report to moderator
1480876622
Hero Member
*
Offline Offline

Posts: 1480876622

View Profile Personal Message (Offline)

Ignore
1480876622
Reply with quote  #2

1480876622
Report to moderator
1480876622
Hero Member
*
Offline Offline

Posts: 1480876622

View Profile Personal Message (Offline)

Ignore
1480876622
Reply with quote  #2

1480876622
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480876622
Hero Member
*
Offline Offline

Posts: 1480876622

View Profile Personal Message (Offline)

Ignore
1480876622
Reply with quote  #2

1480876622
Report to moderator
1480876622
Hero Member
*
Offline Offline

Posts: 1480876622

View Profile Personal Message (Offline)

Ignore
1480876622
Reply with quote  #2

1480876622
Report to moderator
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
June 15, 2011, 12:02:32 AM
 #2

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.

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

So yes, small numbers have multiple representations.

ByteCoin
joan
Jr. Member
*
Offline Offline

Activity: 56



View Profile
June 15, 2011, 09:18:33 AM
 #3

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.

Not a bug. The "+" here is meant as concatenation of bytes.
One byte with 0xFD, then 2 bytes with the value.
Martin P. Hellwig
Jr. Member
*
Offline Offline

Activity: 33


View Profile
June 15, 2011, 11:45:47 AM
 #4

Ah yes makes perfect sense. Thank you (both)
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!