Bitcoin Forum
April 29, 2017, 11:44:12 PM *
News: If the forum does not load normally for you, please send me a traceroute.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: varint in client version 3210 not according to spec?  (Read 658 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
1493509452
Hero Member
*
Offline Offline

Posts: 1493509452

View Profile Personal Message (Offline)

Ignore
1493509452
Reply with quote  #2

1493509452
Report to moderator
1493509452
Hero Member
*
Offline Offline

Posts: 1493509452

View Profile Personal Message (Offline)

Ignore
1493509452
Reply with quote  #2

1493509452
Report to moderator
1493509452
Hero Member
*
Offline Offline

Posts: 1493509452

View Profile Personal Message (Offline)

Ignore
1493509452
Reply with quote  #2

1493509452
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
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!