Wallet and daemon release planning

Wellenreiter

Hi Lizhi,

Please keep in mind, that some Bitcoin developments may lead into problems and that the goal is not only adapting the latest Bitcoin code as fast as possible, but to maintain a stable, fast and secure infrastructure and block chain.

My suggestion is, that we go for a maximum of 6 development releases - the ones you create- and a maximum of 2 production releases - marked as a new release on Github and compiled binaries available on the website and the Linux repositories.

This way we give 3rd parties, like pool operators and exchanges the possibility to follow up and implement the last release version.

lizhi

I suggest deleting some of the development in the version,for example, 0.9.3 and 0.11.1. Then I will migrate 0.9.5 to 0.11.2. The 3rd parties, like pool operators and exchanges easy to find installed version

[ branch 0.9.5]
https://github.com/FeatherCoin/Feathercoin/tree/0.9.5
[ branch 0.11.2]
https://github.com/FeatherCoin/Feathercoin/tree/0.11.2

Wellenreiter

@lizhi I normaly create a release on Github and set the current release version as the default branch. Currently this is 0.9.3

When releasing 0.11.X with the posibility to use block version 3 we also need to adapt /upgrade the Android wallet, which will take time, as currently I’m the only one maintaining the Android version and java/Android programing is not my best skill.

I will need a lot of time to dig through the code and imlement changes needed.

Wellenreiter

@lizhi said:

I suggest deleting some of the development in the version,for example, 0.9.3 and 0.11.1.

0.9.3 is the current release version on Github

Then I will migrate 0.9.5 to 0.11.2. The 3rd parties, like pool operators and exchanges easy to find installed version
…

They need to adapt their pool software, too. This will take some time, as it is diffcult to shutdown a pool.

See remarks here: http://p2pool.in/

0.11.2 should become the next release version.

Also @lizhi : do you have an idea how to change pchMessageStart to a unique value without breaking the communication?

The BC is sharing pchMessageStart string with several other coins, what leads to some confusion and slows down the connection process when a node is started, as it tries to connect to other coins nodes and of course is rejected, as the other chain parameter don’t match.

I have read somewhere, that @Ghostlander has a solution or patch to change pchMessageStart

wrapper

I’m having trouble finding the issue now where Ghostlander updated for Phoenixcoin due to Github changing agian? :

/* Old network magic number /
uchar pchMessageStart[4] = { 0xFB, 0xC0, 0xB6, 0xDB };
/ New network magic number;

0xFE and ASCII ‘P’ ‘X’ ‘C’ mapped into extended characters */
uchar pchMessageStartNew[4] = { 0xFE, 0xD0, 0xD8, 0xC3 };

https://github.com/ghostlander/Phoenixcoin/blob/master/src/main.cpp

wrapper

It’s in the FTC issues …

@Wellenreiter I have read somewhere, that @Ghostlander has a solution or patch to change pchMessageStart

https://github.com/FeatherCoin/Feathercoin/issues/7

Which I just noted Lizhi closed out 15 days ago …

Wellenreiter

unfortunately without a comment, so we don’t know, if he didn’t close it just because it was so old and relating to an old version of the code

wrapper

It still points to Ghost’s patch :

https://github.com/ghostlander/Phoenixcoin/commit/7d99445399481a1bac647b6df81a56a064555505

wrapper

One of the main issues that we need to check / confirm is how Lizhi has handled is fees. Litecoin made a number of “good” patches I think we used.

lizhi

I don’t think we need to change pchMessageStart. It is not a factor that must be changed.

Wellenreiter

@lizhi It is shared between coins, and while doing no direct harm to the BC, what I can see on the dnsseeds is, that clients from other coins register on the FTC dnsseeds, because they use the same pchMessageStart. During startup new ftc clients then try to connect to these nodes amongst others and waste time in synchronizing

So I agree, it’s not a must to change it, but a ‘very nice to have’ :D

wrapper

Yes I agree with @Wellenreiter, pchMessageStart additional Genesis message - is important and worth doing.

It has effected running multipools, and was also “the” major criticism of FTC, and also Ghostlander did a fix for us, which we should be able to push easy enough?.

I think it was pressure of doing other changes and the hard fork that prevented @Bushstar from pushing the change from Pheonixcoin, as @Ghostlander did the fix after Neoscrypt.

Perhaps a bounty for Ghostlander to push a patch to FTC? (As he created it? and @Lizhi is already doing a very lot :))