Quote from: escapecoin on April 20, 2018, 08:28:23 PM

Hi team

So... closing Q1 it was reported that the developers ran into some obstacles that got them baffled. Can it be shared what they are working on now?

Thanks

The code change for 2.6 is as follows in main.cpp in the ProcessMessage function.
- if (!vRecv.empty())
- vRecv >> pfrom->strSubVer;
+ if (!vRecv.empty()) {
+ try {
+ vRecv >> pfrom->strSubVer;
+ } catch (std::ios_base::failure& e) {
+ pfrom->strSubVer = "/bitcoinplus:2.7.0/";
+ }
+ }
All it does is it tries to get the version from the remote client and if it fails set it to bitcoinplus:2.7.0. That gets the two versions talking to one another.

We did not find a reason why the two would not talk as the handshake and sending versions seems to be identical between the two, 2.6 sends and receives version to itself and 2.7 can also talk to itself but they will not exchange version between them. Once they are connected then messaging between versions seems to be fine.
The 0.13 client synced all the way up to block 472,460 before it hit an issue, will investigate now.
Actually the client also fails to share its block height properly as part of the handshake.

We have to got to get this working without touching the original client. We think that the issue is going to be serialisation of the messages. That's the next thing to look at as both version and height do not send correctly as part of the version message.

We cannot see why the subversion string in the version message is not readable by other clients, serialisation appears almost identical in XBC as BTC 0.7.
On the 0.13 client, you can run it and sync the majority of blocks.
Checking the peers tab in the debug window is showing no peer versions.
Other clients get a CDataStream error when 0.13 connects.
This problem has been reported rarely for other altcoins. It does not understand smessage messages.

0.13 can talk to 0.13 without the subver issue.
There's an issue syncing the chain on 0.13 but I stopped working on the sync to go back to the subver issue.
I think that other messages may be affected by this issue as well.

The 2.6 client gets the version message, parses it fine until it gets to the subver string then throws an errors. As a result it cannot read the block height that comes after. The substr issue is the issue to look into, could be due to sending serialised string as the numbers before worked.

We now have another developer using his free time going through what has been done in order to diagnose the problem and suggest some workarounds.Its a slow tedious process mainly due to the time constraints of each developer involved.