Bitcoin Forum
December 07, 2016, 04:44:32 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: Bitcoin messages implementation  (Read 1008 times)
ThePiachu
Sr. Member
****
Offline Offline

Activity: 442



View Profile WWW
September 29, 2011, 11:42:56 PM
 #1

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.

1HWbVLhxj7bhewhyapMZpyhqWAeAhJd51E
My Bitcoin Calculator:
http://tpbitcalc.appspot.com/
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481129072
Hero Member
*
Offline Offline

Posts: 1481129072

View Profile Personal Message (Offline)

Ignore
1481129072
Reply with quote  #2

1481129072
Report to moderator
Atheros
Sr. Member
****
Offline Offline

Activity: 249



View Profile WWW
September 30, 2011, 12:47:05 AM
 #2

 Sad
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 or send me inv messages. Let me know how you do with these.

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

BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY
Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
September 30, 2011, 02:07:06 AM
 #3

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ThePiachu
Sr. Member
****
Offline Offline

Activity: 442



View Profile WWW
September 30, 2011, 09:45:51 PM
 #4

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)

1HWbVLhxj7bhewhyapMZpyhqWAeAhJd51E
My Bitcoin Calculator:
http://tpbitcalc.appspot.com/
Atheros
Sr. Member
****
Offline Offline

Activity: 249



View Profile WWW
October 02, 2011, 06:18:04 PM
 #5

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.

BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY
Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
ThePiachu
Sr. Member
****
Offline Offline

Activity: 442



View Profile WWW
October 02, 2011, 07:37:39 PM
 #6

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

1HWbVLhxj7bhewhyapMZpyhqWAeAhJd51E
My Bitcoin Calculator:
http://tpbitcalc.appspot.com/
Atheros
Sr. Member
****
Offline Offline

Activity: 249



View Profile WWW
October 03, 2011, 12:58:00 AM
 #7

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

BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY
Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
nibor
Sr. Member
****
Offline Offline

Activity: 348


View Profile
October 03, 2011, 10:06:54 AM
 #8


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.
ThePiachu
Sr. Member
****
Offline Offline

Activity: 442



View Profile WWW
October 03, 2011, 04:57:25 PM
 #9

Thanks for the help.

1HWbVLhxj7bhewhyapMZpyhqWAeAhJd51E
My Bitcoin Calculator:
http://tpbitcalc.appspot.com/
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
October 06, 2011, 06:18:44 AM
 #10

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

PoolServerJ Home Page - High performance java mining pool engine

1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq - http://payb.tc/shads

Quote from: Matthew N. Wright
Stop wasting the internet.
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!