Title: Bitcoin messages implementation Post by: ThePiachu on September 29, 2011, 11:42:56 PM I`m working on implementing different Bitcoin messages. Currently workin on "version" message (https://en.bitcoin.it/wiki/Protocol_specification#version) and I have a couple simple questions:
What is the current protocol version to use in the message? How do different protocol versions differ? From what I can see I assume they correlate to main blient release version, but I'd rather make sure. Services part - it can be set to 1 if node has full blocks, but can it also be set to 0? (a bit of a trivial question, but there might be something I don't know) What is the secondary version for (if anything at the moment)? Any other advice or resources you can give for developing the communication between the Bitcoin clients? For now I`m following the wiki on Protocol Specification and Network pages, but they are a bit hard to read at times. Title: Re: Bitcoin messages implementation Post by: Atheros on September 30, 2011, 12:47:05 AM :(
I had trouble trying the same thing. When I connected to my local bitcoin client, when exchanging simple getaddr and addr messages, Bitcoin spat out errors in the debug log and I could never figure out why. The error messages it printed were definitely not accurate; for example I could get it to accept an addr message if I copied and repeated the exact addr message I received. But when I changed a single bit in the IP address of the addr message, Bitcoin complained to the debug log that the message length was incorrect. I could never get it to respond to getdata messages EDIT: I went and ran this part of the program again and it worked just fine. Since I last ran it, I fixed the way I handle TCP streams. I must have fixed it. It was my own fault. :( Title: Re: Bitcoin messages implementation Post by: theymos on September 30, 2011, 02:07:06 AM Most messages have separate version numbers, but for version messages the version is indeed the client version. 0.3.19.3 is 31903. 0.4 (the latest stable version) is 40000.
Services can be 0. subVer was intended to be used for releases like 0.3.19.3.1, but this is unlikely nowadays. The purpose of this field might change to something else later -- maybe it will identify user agents. But when I changed a single bit in the IP address of the addr message, Bitcoin complained to the debug log that the message length was incorrect. You didn't update the message header length/checksum. Title: Re: Bitcoin messages implementation Post by: ThePiachu on September 30, 2011, 09:45:51 PM Can someone double check this message for correctness:
F9BEB4D976657273696F6E00000000005500000086234FCA409C00000100000000000000A135864 E00000000010000000000000000000000000000000000FFFFFFFFFF008D20010000000000000000 000000000000000000FFFF7F0000018D20549774EE243F8BFC0001000000 F9BEB4D9 - magic 76657273696F6E0000000000 - command version 55000000 - length 86234FCA - checksum 409C0000 - version 4.0 0100000000000000 - services A135864E00000000 - time 010000000000000000000000000000000000FFFFFFFFFF008D20 - 255.255.255.0:8333 010000000000000000000000000000000000FFFF7F0000018D20 - 127.0.0.1:8333 549774EE243F8BFC - random nonce 00 - sub version number 01000000 - start height (1) Title: Re: Bitcoin messages implementation Post by: Atheros on October 02, 2011, 06:18:04 PM subVer was intended to be used for releases like 0.3.19.3.1, but this is unlikely nowadays. The purpose of this field might change to something else later -- maybe it will identify user agents. A user agent field would be glorious. I found myself changing the protocol version number from something like 32400 to 32407 just to differentiate my experimental program from normal nodes. A user agent field would also optionally let us go back to actually using the protocol version number as a protocol version number rather than a client version number. EDIT: Although I'm seeing that that client version number is pretty solidly coded into things like alerting. hmm.. Some day different clients will have to relay each others' alerts and that will be a little hairy. Title: Re: Bitcoin messages implementation Post by: ThePiachu on October 02, 2011, 07:37:39 PM I also agree that protocol version and client version should be separate, and both should be present. For example, the main client could identify itself as "Main Client version 5.1 protocol version 2.5", and someone else's implementation could be still compatible, but distinguish itself as "Billy's Client version 0.3 protocol version 2.5".
Title: Re: Bitcoin messages implementation Post by: Atheros on October 03, 2011, 12:58:00 AM Can someone double check this message for correctness: 010000000000000000000000000000000000FFFFFFFFFF008D20 - 255.255.255.0:8333 010000000000000000000000000000000000FFFF7F0000018D20 - 127.0.0.1:8333 I didn't check everything but I noticed that your port is not in big-endian. It should be 208D Title: Re: Bitcoin messages implementation Post by: nibor on October 03, 2011, 10:06:54 AM Take a look at: http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/core/VersionMessage.java and: http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/core/Message.java might help you. Title: Re: Bitcoin messages implementation Post by: ThePiachu on October 03, 2011, 04:57:25 PM Thanks for the help.
Title: Re: Bitcoin messages implementation Post by: shads on October 06, 2011, 06:18:44 AM Also take a look at Network Address, it's other common one that varies by version and is embedded in version message.
http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/core/PeerAddress.java |