I’m also running into this exact same issue with my parser, now I understand
why the relay field behavior I was seeing doesn’tmatch the wiki.
So to parse a version message, you can’t rely on the protocol version? You have
to know how long the payload is, and then parse the message accordingly? I
agree with Turkey Breast, this seems a bit sloppy to me.
Paul
P.S. I’ve never used a dev mailing list before and I want to get involved with
the Bitcoin dev community, so let me know if I’m horribly violating any mailing
list etiquette. 😊
From: Mike Hearn
Sent: Wednesday, June 19, 2013 7:43 AM
To: Turkey Breast
Cc: bitcoin-development@lists.sourceforge.net
Bitcoin-Qt on master does send it now although it doesn't affect anything, but
as old pre-filtering versions will continue to exist, you'll always have to be
able to deserialize version messages without it.
Bitcoin version messages have always had variable length, look at how the code
is written in main.cpp. If you didn't experience issues until now all it means
is that no sufficiently old nodes were talking to yours.
The standard does not say it should appear. Read it again - BIP 37 says about
the new version message field:
If false then broadcast transactions will not be announced until a
filter{load,add,clear} command is received. If missing or true, no change in
protocol behaviour occurs.
On Wed, Jun 19, 2013 at 12:33 PM, Turkey Breast <turkeybre...@yahoo.com> wrote:
It's a problem if you work with iterators to deserialize the byte stream. Even
failing that, it's just sloppy programming. What happens in the future when new
fields are added to the version message? It's not a big deal to say that this
protocol version has X number of fields, that (higher) protocol version message
has X + N number of fields. Deterministic number of fields per protocol version
is sensical and how Bitcoin has been for a long time.
And yes, it was a problem for me that caused a lot of confusion why this byte
didn't exist in many version messages despite the standard saying it should and
the code in bitcoind indicating it should. Nowhere was this written. It doesn't
help other implementations to have an unclear behaviour that depends on some
magic from one implementation.
From: Mike Hearn <m...@plan99.net>
To: Turkey Breast <turkeybre...@yahoo.com>
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Sent: Wednesday, June 19, 2013 11:39 AM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message
It has to be optional because old clients don't send it, obviously.
Why is this even an issue? There's no problem with variable length messages in
any codebase that I'm aware of. Is this solving some actual problem?
On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast <turkeybre...@yahoo.com> wrote:
That's me. I never said to make all messages fixed length. I said to make a
fixed number of fields per protocol. So given a protocol version number, you
know the number of fields in a message. This is not only easier for parsing
messages, but just good practice. I don't see why a 1 byte flag needs to be
optional anyway.
From: Mike Hearn <m...@plan99.net>
To: Turkey Breast <turkeybre...@yahoo.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Sent: Tuesday, June 18, 2013 9:48 PM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message
It's not a bug (although there was recently a change to make bitcoind/qt always
send this field anyway).
I don't know where Amir is going with BIP 60. Version messages have always been
variable length. There's nothing inherent in the Bitcoin protocol that says all
messages are fixed length, indeed, tx messages are allowed to have arbitrary
data appended after them that gets relayed.
On Tue, Jun 18, 2013 at 7:45 PM, Turkey Breast <turkeybre...@yahoo.com> wrote:
See this BIP. I'm not sure if this is a bug or what, but it would be good if
messages always had a fixed number of fields per protocol version.
https://en.bitcoin.it/wiki/BIP_0060#Code_Updates
This BIP details everything that needs to be done and proposes a protocol
upgrade.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
