Start enforcing block.nVersion=3

wrapper

Thanks for all the hard work, Lizhi.
We need a major pool switch, but the new change over method means it doesn’t have to be done in one 51% change over.
You’ve started warning members now, and we need to look to include it in publicity. Have the new version available so that is the easy option …

Wellenreiter

Is it possible to run a mixed network of 0.8.7/0.9.3 and 0.9.5?

About 75% of wallets seem be on 0.8.7.X, still.

https://bitinfocharts.com/feathercoin/

mirrax

So that might be the reason why my balance was not showing correctly!

lizhi

@Wellenreiter because wallet 0.8.7 reject version 3 , must upgrade it. a typical user can run 0.9.3/0.9.5 and 0.11.1 ,but pool daemon must run wallet 0.9.5 or 0.11.1 .

lizhi

@mirrax NO , block version 3 not start.

Wellenreiter

So, how can Mirrax work with his 0.9.5 version, and get connected to the BC, if most of wallets are on 0.8.7.x?

I know, that the local data of a 0.8.7 can’t be used, but I thought, that a 0.9.5 client can connect to a 0.8.7.1 or a 0.9.3.0

@Mirrax: can you do a ‘getpeerinfo’ from your 0.9.5 wallet’s console and check for the versions of the connected peers?

mirrax

@Wellenreiter

Hi, I use 0.9.3 in linux, here is the command line output:

14:05:21

getpeerinfo

14:05:21

[
{
“addr” : “96.126.116.100:9336”,
“services” : “00000003”,
“lastsend” : 1450789453,
“lastrecv” : 1450789453,
“bytessent” : 145778,
“bytesrecv” : 629608,
“conntime” : 1450789226,
“pingtime” : 0.00000000,
“version” : 60007,
“subver” : “/Satoshi:0.8.7/”,
“inbound” : false,
“startingheight” : 1014116,
“banscore” : 0,
“syncnode” : true
},
{
“addr” : “104.236.34.9:9336”,
“services” : “00000003”,
“lastsend” : 1450789453,
“lastrecv” : 1450789454,
“bytessent” : 465638,
“bytesrecv” : 488933,
“conntime” : 1450789227,
“pingtime” : 0.00000000,
“version” : 60007,
“subver” : “/Satoshi:0.8.7.1/”,
“inbound” : false,
“startingheight” : 1014116,
“banscore” : 0,
“syncnode” : false
},
{
“addr” : “195.166.157.97:9336”,
“services” : “00000003”,
“lastsend” : 1450789453,
“lastrecv” : 1450789482,
“bytessent” : 86951,
“bytesrecv” : 495407,
“conntime” : 1450789233,
“pingtime” : 0.00000000,
“version” : 60007,
“subver” : “/Satoshi:0.8.7.1/”,
“inbound” : false,
“startingheight” : 1014117,
“banscore” : 0,
“syncnode” : false
},
{
“addr” : “185.26.124.95:9336”,
“services” : “00000003”,
“lastsend” : 1450789453,
“lastrecv” : 1450789453,
“bytessent” : 84163,
“bytesrecv” : 175738,
“conntime” : 1450789265,
“pingtime” : 0.00000000,
“version” : 60007,
“subver” : “/Satoshi:0.8.7.1/”,
“inbound” : false,
“startingheight” : 1014118,
“banscore” : 0,
“syncnode” : false
},
{
“addr” : “188.165.223.132:9336”,
“services” : “00000003”,
“lastsend” : 1450789453,
“lastrecv” : 1450789453,
“bytessent” : 363145,
“bytesrecv” : 682622,
“conntime” : 1450789272,
“pingtime” : 0.00000000,
“version” : 60007,
“subver” : “/Satoshi:0.8.7.1/”,
“inbound” : false,
“startingheight” : 1014118,
“banscore” : 0,
“syncnode” : false
},
{
“addr” : “115.28.24.213:9336”,
“services” : “00000001”,
“lastsend” : 1450789453,
“lastrecv” : 1450789431,
“bytessent” : 28675,
“bytesrecv” : 114868,
“conntime” : 1450789274,
“pingtime” : 0.00000000,
“version” : 70002,
“subver” : “/Satoshi:0.9.5/”,
“inbound” : false,
“startingheight” : 1014118,
“banscore” : 0,
“syncnode” : false
},
{
“addr” : “89.254.146.188:9336”,
“services” : “00000003”,
“lastsend” : 1450789521,
“lastrecv” : 1450789521,
“bytessent” : 512482,
“bytesrecv” : 429402,
“conntime” : 1450789280,
“pingtime” : 0.00000000,
“version” : 60007,
“subver” : “/Satoshi:0.8.7.1/”,
“inbound” : false,
“startingheight” : 817411,
“banscore” : 0,
“syncnode” : false
},
{
“addr” : “120.24.208.220:9336”,
“services” : “00000001”,
“lastsend” : 1450789453,
“lastrecv” : 1450789431,
“bytessent” : 17398,
“bytesrecv” : 113644,
“conntime” : 1450789281,
“pingtime” : 0.00000000,
“version” : 70002,
“subver” : “/Satoshi:0.9.5/”,
“inbound” : false,
“startingheight” : 1014118,
“banscore” : 0,
“syncnode” : false
}
]

Wellenreiter

@mirrax : So you have a mixed peer connection, where most peers are 0.8.x and only one peer is on 0.9.5.

This means, that 0.9.5 clients and 0.8.7.x clients talk to each other and exchange information.

@ Lizhi: It seems, that I don’t understand the problem

ghostlander

Just update to BIP66 and keep nVersion=2. v0.8.7 is already DER compatible, though doesn’t enforce it.

Wellenreiter

@ghostlander: thanks for the clarification :D

AmDD

Guys, if we want to push the newer version Id think a good place to start is feathercoin.com. it still showing the 0.8.7.1 version.

wrapper

I have no direct input, as some people are paying money, that’s not the fault of anyone doing the work at the moment. It’s a technical / change over to issue which is already been worked on as part of the forum open source update ‘plan’.

As the technical discussion showed (not a rush) and the limited number of moderators / testers, better to be slow and sure.

As someone limited in how I can help and with experience of similar projects in industry, progress has been remarkable compared to the negative possibilities.

Wellenreiter

@lizhi: I see a peer with version 0.11.1 among others with 0.8.7 and 0.8.7.1.
I’m on 0.9.3.s

This means, that all versions can connect to each other.
Is that a valid prove aready, that the versions are working well with each other?

lizhi

Yes, all versions can connect to each other.
But pool daemon should run 0.11.1 ,it make block 2 or block 3. but 0.8.7 only make block 2 and don’t accept blocks 3.

main.cpp ,line 2249.
/* Don’t accept blocks with bogus nVersion numbers after this point */
if((nHeight >= nForkFour) || (fTestNet && (nHeight >= nTestnetFork))) {
if(nVersion != 2)
return(state.DoS(100, error(“AcceptBlock() : incorrect block version”)));
}