[ANN] New Client for PhenixCoin PXC ** PLEASE UPDATE YOUR CLIENTS **

[weav]

I found the issues... switching to version 6.4.7

Please clone the repo https://github.com/phenixcoin/Phenixcoin.git

I will compile the binaries now.

Great! That fixed it, wallet syncing properly now!  

While trying to debug the issue on my system I found another apparent dissonance in the code in src/main.cpp:

Code:

840 static const int64 nTargetTimespan = 0.5 * 24 * 60 * 60; // Phenixcoin: 2.5 days
841 static const int64 nTargetSpacing = 1.5 * 60; // Phenixcoin: 1.5 minutes
..
889 int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*4);
890 int64 nInterval = nTargetTimespanCurrent / nTargetSpacing;

Ignoring the comments (which don't fully match the code and are possibly just leftovers from the feathercoin repo or something) and assuming nInterval denotes the number of blocks until difficulty retarget we correctly get:

Code:

nInterval = (0.5 * 24 * 60 * 60) / (1.5 * 60) = 480 

which is the number of blocks for the new difficulty protocol, but for the old protocol we get:

Code:

nInterval = ((0.5 * 24 * 60 * 60) * 4) / (1.5 * 60) = 1920

which isn't the 2400 blocks as specified in the original forum announcement and on phenixcoin.com...  

(it would be for int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*5);)

Am I missing something?

that was not the old protocal ... the old was 2.5 * 24

Yes that is my point, currently the code does:

0.5 * (24 * 60 * 60) * 4 == 2.0 * (24 * 60 * 60)

but shouldn't it be:

0.5 * (24 * 60 * 60) * 5 == 2.5 * (24 * 60 * 60) ?

[AquaMan]

Updated client on my pool.

http://pxc.coinmine.pl

Pool has proportional payout system so you will get instant payouts after each block - start mining!

is your pool still up?

Several are up now...

[iamatrix]

I found the issues... switching to version 6.4.7

Please clone the repo https://github.com/phenixcoin/Phenixcoin.git

I will compile the binaries now.

Great! That fixed it, wallet syncing properly now!  

While trying to debug the issue on my system I found another apparent dissonance in the code in src/main.cpp:

Code:

840 static const int64 nTargetTimespan = 0.5 * 24 * 60 * 60; // Phenixcoin: 2.5 days
841 static const int64 nTargetSpacing = 1.5 * 60; // Phenixcoin: 1.5 minutes
..
889 int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*4);
890 int64 nInterval = nTargetTimespanCurrent / nTargetSpacing;

Ignoring the comments (which don't fully match the code and are possibly just leftovers from the feathercoin repo or something) and assuming nInterval denotes the number of blocks until difficulty retarget we correctly get:

Code:

nInterval = (0.5 * 24 * 60 * 60) / (1.5 * 60) = 480 

which is the number of blocks for the new difficulty protocol, but for the old protocol we get:

Code:

nInterval = ((0.5 * 24 * 60 * 60) * 4) / (1.5 * 60) = 1920

which isn't the 2400 blocks as specified in the original forum announcement and on phenixcoin.com...  

(it would be for int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*5);)

Am I missing something?

that was not the old protocal ... the old was 2.5 * 24

Yes that is my point, currently the code does:

0.5 * (24 * 60 * 60) * 4 == 2.0 * (24 * 60 * 60)

but shouldn't it be:

0.5 * (24 * 60 * 60) * 5 == 2.5 * (24 * 60 * 60) ?

You looking at 6.4.5 code..  6.4.7 is (5 * 24 * 60 * 60) / 8

[feeleep]

Updated client on my pool.

http://pxc.coinmine.pl

Pool has proportional payout system so you will get instant payouts after each block - start mining!

is your pool still up?

updated client on my pool to the latest - you are welcome to start mining!

http://pxc.coinmine.pl:9095

[weav]

that was not the old protocal ... the old was 2.5 * 24

Yes that is my point, currently the code does:

0.5 * (24 * 60 * 60) * 4 == 2.0 * (24 * 60 * 60)

but shouldn't it be:

0.5 * (24 * 60 * 60) * 5 == 2.5 * (24 * 60 * 60) ?

You looking at 6.4.5 code..  6.4.7 is (5 * 24 * 60 * 60) / 8

Oh right, so you've addressed that already together with the sync issue (or it was actually causing it). Now I'm seeing it:

https://github.com/phenixcoin/Phenixcoin/commit/075d96d75873007d3d8997204cfaa2f3bf7507c2

I was only looking at the most recent commit earlier:

https://github.com/phenixcoin/Phenixcoin/commit/48e6768f2bae47df679244108962fb67b1b89809

But actually I think this introduces an even more severe bug because now it affects the future blockchain instead of just the verification of the existing chain prior to the difficulty protocol change.

Look at the current code in the repo https://github.com/phenixcoin/Phenixcoin/blob/master/src/main.cpp:

Code:

840 static const int64 nTargetTimespan = (5 * 24 * 60 * 60) / 8; // Phenixcoin: 2.5 days
841 static const int64 nTargetSpacing = 1.5 * 60; // Phenixcoin: 1.5 minutes
..
886 int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*4);
887 int64 nInterval = nTargetTimespanCurrent / nTargetSpacing;

Apart from the comment still not matching the code:

(5 * 24 * 60 * 60) / 8 == (5/8) * (24 * 60 * 60) == 0.625 * (24 * 60 * 60) == 0.625 days

the far more serious issue is that now the nInterval isn't 480 anymore if fNewDifficultyProtocol is true, that is if we are past block 46500 where the difficulty protocol adjustment applies.

Now it's basically the other way around, for the old protocol we do correctly get:

Code:

nInterval = (((5 * 24 * 60 * 60) / 8) * 4) / (1.5 * 60) = 2400

which is the number of blocks until difficulty retarget as specified in the original forum announcement and on phenixcoin.com, and which in part explains why the block verification during the wallet sync doesn't fail anymore for retarget blocks which caused the sync to get stuck.

But now for the new protocol we get:

Code:

nInterval = ((5 * 24 * 60 * 60) / 8) / (1.5 * 60) = 600 

which isn't the 480 blocks as defined in the recent difficulty protocol fix!

I guess this should be fixed urgently before the next difficulty retarget occurs

And I still think this would fully fix it:

Code:

840 static const int64 nTargetTimespan = 0.5 * 24 * 60 * 60; // Phenixcoin: 12 hours
841 static const int64 nTargetSpacing  = 1.5 * 60; // Phenixcoin: 1.5 minutes
..
886 int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*5); // NOTE THE *5 HERE
887 int64 nInterval = nTargetTimespanCurrent / nTargetSpacing;

[MaGNeT]

that was not the old protocal ... the old was 2.5 * 24

Yes that is my point, currently the code does:

0.5 * (24 * 60 * 60) * 4 == 2.0 * (24 * 60 * 60)

but shouldn't it be:

0.5 * (24 * 60 * 60) * 5 == 2.5 * (24 * 60 * 60) ?

You looking at 6.4.5 code..  6.4.7 is (5 * 24 * 60 * 60) / 8

Oh right, so you've addressed that already together with the sync issue (or it was actually causing it). Now I'm seeing it:

https://github.com/phenixcoin/Phenixcoin/commit/075d96d75873007d3d8997204cfaa2f3bf7507c2

I was only looking at the most recent commit earlier:

https://github.com/phenixcoin/Phenixcoin/commit/48e6768f2bae47df679244108962fb67b1b89809

But actually I think this introduces an even more severe bug because now it affects the future blockchain instead of just the verification of the existing chain prior to the difficulty protocol change.

Look at the current code in the repo https://github.com/phenixcoin/Phenixcoin/blob/master/src/main.cpp:

Code:

840 static const int64 nTargetTimespan = (5 * 24 * 60 * 60) / 8; // Phenixcoin: 2.5 days
841 static const int64 nTargetSpacing = 1.5 * 60; // Phenixcoin: 1.5 minutes
..
886 int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*4);
887 int64 nInterval = nTargetTimespanCurrent / nTargetSpacing;

Apart from the comment still not matching the code:

(5 * 24 * 60 * 60) / 8 == (5/8) * (24 * 60 * 60) == 0.625 * (24 * 60 * 60) == 0.625 days

the far more serious issue is that now the nInterval isn't 480 anymore if fNewDifficultyProtocol is true, that is if we are past block 46500 where the difficulty protocol adjustment applies.

Now it's basically the other way around, for the old protocol we do correctly get:

Code:

nInterval = (((5 * 24 * 60 * 60) / 8) * 4) / (1.5 * 60) = 2400

which is the number of blocks until difficulty retarget as specified in the original forum announcement and on phenixcoin.com, and which in part explains why the block verification during the wallet sync doesn't fail anymore for retarget blocks which caused the sync to get stuck.

But now for the new protocol we get:

Code:

nInterval = ((5 * 24 * 60 * 60) / 8) / (1.5 * 60) = 600 

which isn't the 480 blocks as defined in the recent difficulty protocol fix!

I guess this should be fixed urgently before the next difficulty retarget occurs

And I still think this would fully fix it:

Code:

840 static const int64 nTargetTimespan = 0.5 * 24 * 60 * 60; // Phenixcoin: 12 hours
841 static const int64 nTargetSpacing  = 1.5 * 60; // Phenixcoin: 1.5 minutes
..
886 int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*5); // NOTE THE *5 HERE
887 int64 nInterval = nTargetTimespanCurrent / nTargetSpacing;

Don't understand all you say but if it needs to be fixed, I guess it needs to be fixed  

Iamatrix needs a twin-brother

[iamatrix]

Code:

840 static const int64 nTargetTimespan = 0.5 * 24 * 60 * 60; // Phenixcoin: 12 hours
841 static const int64 nTargetSpacing  = 1.5 * 60; // Phenixcoin: 1.5 minutes
..
886 int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*5); // NOTE THE *5 HERE
887 int64 nInterval = nTargetTimespanCurrent / nTargetSpacing;

Yes, with the last update I made, it changed the diff change at 600 blocks instead of 480, and increased the time from 12hrs to 15hrs..

The 46500 marker came up way faster then I expected, I was thinking late thursday, early friday for the change over..

I will talk it over with John and see what we come up with.

[weav]

Code:

840 static const int64 nTargetTimespan = 0.5 * 24 * 60 * 60; // Phenixcoin: 12 hours
841 static const int64 nTargetSpacing  = 1.5 * 60; // Phenixcoin: 1.5 minutes
..
886 int64 nTargetTimespanCurrent = fNewDifficultyProtocol? nTargetTimespan : (nTargetTimespan*5); // NOTE THE *5 HERE
887 int64 nInterval = nTargetTimespanCurrent / nTargetSpacing;

Yes, with the last update I made, it changed the diff change at 600 blocks instead of 480, and increased the time from 12hrs to 15hrs..

The 46500 marker came up way faster then I expected, I was thinking late thursday, early friday for the change over..

I will talk it over with John and see what we come up with.

Oh, so this was intentional I was assuming it must be a bug because it wasn't mentioned anywhere in the announcements or on phenixcoin.com

I kinda like the "symmetry" between block reward halves every 840k blocks and difficulty changes every 480 blocks but by all means what's best for the coin! 

[weav]

Just for general transparency, can you please explain why users of the binaries you guys provide were unaffected by the bug which just got fixed in the official code repository on https://github.com/phenixcoin/Phenixcoin ?

Apparently the issue only occured for linux users who compiled their own binaries from the public source, and noticeably so because the wallet sync got completely stuck. I cannot imagine a setting or environment where the former code wouldn't cause this behavior.

Are you compiling the binaries you release on phenixcoin.com from a separate codebase which differs from the repo on github, and if so, why?

Thanks

[iamatrix]

Just for general transparency, can you please explain why users of the binaries you guys provide were unaffected by the bug which just got fixed in the official code repository on https://github.com/phenixcoin/Phenixcoin ?

Apparently the issue only occured for linux users who compiled their own binaries from the public source, and noticeably so because the wallet sync got completely stuck. I cannot imagine a setting or environment where the former code wouldn't cause this behavior.

Are you compiling the binaries you release on phenixcoin.com from a separate codebase which differs from the repo on github, and if so, why?

Thanks

I was kind of wondering the same thing as well, I delete my block chain and it downloaded fine.. its not a different code base.

Most people where not effected because they already had the block chain and it was stalling on a block with a diff change.

trust me, I will be looking into why the windows binary worked..

its pretty easy to setup a mingw compile env for windows, grab the code for 6.4.5 and try it..

we have full transparency with the coin..

[weav]

Just for general transparency, can you please explain why users of the binaries you guys provide were unaffected by the bug which just got fixed in the official code repository on https://github.com/phenixcoin/Phenixcoin ?

Apparently the issue only occured for linux users who compiled their own binaries from the public source, and noticeably so because the wallet sync got completely stuck. I cannot imagine a setting or environment where the former code wouldn't cause this behavior.

Are you compiling the binaries you release on phenixcoin.com from a separate codebase which differs from the repo on github, and if so, why?

Thanks

I was kind of wondering the same thing as well, I delete my block chain and it downloaded fine.. its not a different code base.

Most people where not effected because they already had the block chain and it was stalling on a block with a diff change.

trust me, I will be looking into why the windows binary worked..

its pretty easy to setup a mingw compile env for windows, grab the code for 6.4.5 and try it..

we have full transparency with the coin..

Thanks, sounds reasonable, in particular that most people probably already had the complete blockchain with the latest retarget block in their wallets. Must be some really weird windows side effect then.

[iamatrix]

Just for general transparency, can you please explain why users of the binaries you guys provide were unaffected by the bug which just got fixed in the official code repository on https://github.com/phenixcoin/Phenixcoin ?

Apparently the issue only occured for linux users who compiled their own binaries from the public source, and noticeably so because the wallet sync got completely stuck. I cannot imagine a setting or environment where the former code wouldn't cause this behavior.

Are you compiling the binaries you release on phenixcoin.com from a separate codebase which differs from the repo on github, and if so, why?

Thanks

I was kind of wondering the same thing as well, I delete my block chain and it downloaded fine.. its not a different code base.

Most people where not effected because they already had the block chain and it was stalling on a block with a diff change.

trust me, I will be looking into why the windows binary worked..

its pretty easy to setup a mingw compile env for windows, grab the code for 6.4.5 and try it..

we have full transparency with the coin..

Thanks, sounds reasonable, in particular that most people probably already had the complete blockchain with the latest retarget block in their wallets. Must be some really weird windows side effect then.

Ya but I still want to know why..

[weav]

Just for general transparency, can you please explain why users of the binaries you guys provide were unaffected by the bug which just got fixed in the official code repository on https://github.com/phenixcoin/Phenixcoin ?

Apparently the issue only occured for linux users who compiled their own binaries from the public source, and noticeably so because the wallet sync got completely stuck. I cannot imagine a setting or environment where the former code wouldn't cause this behavior.

Are you compiling the binaries you release on phenixcoin.com from a separate codebase which differs from the repo on github, and if so, why?

Thanks

I was kind of wondering the same thing as well, I delete my block chain and it downloaded fine.. its not a different code base.

Most people where not effected because they already had the block chain and it was stalling on a block with a diff change.

trust me, I will be looking into why the windows binary worked..

its pretty easy to setup a mingw compile env for windows, grab the code for 6.4.5 and try it..

we have full transparency with the coin..

Thanks, sounds reasonable, in particular that most people probably already had the complete blockchain with the latest retarget block in their wallets. Must be some really weird windows side effect then.

Ya but I still want to know why..

Yeah

[weav]

Another bug, mentioned earlier, still occurs:

after running the wallet for a while (hours) the "Synchronizing with network.." progress bar reappears saying:

327431 blocks remaining

 and when hovering over it with the mouse:

Downloaded block 46579 of 374010

although there are only 46579 blocks in total by now.

Errors like the following show up in the -printtoconsole log:

Code:

ERROR: FetchInputs() : 7f86e710b0 mempool Tx prev not found 73a5af9661
stored orphan tx 7f86e710b0 (mapsz 15)
ERROR: FetchInputs() : d02d4ba85b mempool Tx prev not found 8ca4687af1
stored orphan tx d02d4ba85b (mapsz 16)
received getdata for: tx de72b672826e9013aa7f
ResendWalletTransactions()
ERROR: FetchInputs() : 38b44facd9 mempool Tx prev not found c39f7dc03d
stored orphan tx 38b44facd9 (mapsz 17)

[nearmiss]

not to spam, but brand new pool up:

http://pxc.scryptmining.com

* stratum-only
* proportional payouts per block (no pplns warmup!)
* variable diff per worker (lots of hashpower? reduce your bandwidth. low hashpower? Don't get stung by a high static pool-wide diff!)

Come check us out

[MaGNeT]

Another bug, mentioned earlier, still occurs:

after running the wallet for a while (hours) the "Synchronizing with network.." progress bar reappears saying:

327431 blocks remaining

 and when hovering over it with the mouse:

Downloaded block 46579 of 374010

although there are only 46579 blocks in total by now.

Errors like the following show up in the -printtoconsole log:

Code:

ERROR: FetchInputs() : 7f86e710b0 mempool Tx prev not found 73a5af9661
stored orphan tx 7f86e710b0 (mapsz 15)
ERROR: FetchInputs() : d02d4ba85b mempool Tx prev not found 8ca4687af1
stored orphan tx d02d4ba85b (mapsz 16)
received getdata for: tx de72b672826e9013aa7f
ResendWalletTransactions()
ERROR: FetchInputs() : 38b44facd9 mempool Tx prev not found c39f7dc03d
stored orphan tx 38b44facd9 (mapsz 17)

Not really a bug, just one or more people who are trying to get us on the LTC (or another) chain.
Just ignore it

[weav]

Another bug, mentioned earlier, still occurs:

after running the wallet for a while (hours) the "Synchronizing with network.." progress bar reappears saying:

327431 blocks remaining

 and when hovering over it with the mouse:

Downloaded block 46579 of 374010

although there are only 46579 blocks in total by now.

Errors like the following show up in the -printtoconsole log:

Code:

ERROR: FetchInputs() : 7f86e710b0 mempool Tx prev not found 73a5af9661
stored orphan tx 7f86e710b0 (mapsz 15)
ERROR: FetchInputs() : d02d4ba85b mempool Tx prev not found 8ca4687af1
stored orphan tx d02d4ba85b (mapsz 16)
received getdata for: tx de72b672826e9013aa7f
ResendWalletTransactions()
ERROR: FetchInputs() : 38b44facd9 mempool Tx prev not found c39f7dc03d
stored orphan tx 38b44facd9 (mapsz 17)

Not really a bug, just one or more people who are trying to get us on the LTC (or another) chain.
Just ignore it

Oh  Weird. How do they do it?

[HuuHachu]

Another bug, mentioned earlier, still occurs:

after running the wallet for a while (hours) the "Synchronizing with network.." progress bar reappears saying:

327431 blocks remaining

 and when hovering over it with the mouse:

Downloaded block 46579 of 374010

although there are only 46579 blocks in total by now.

Errors like the following show up in the -printtoconsole log:

Code:

ERROR: FetchInputs() : 7f86e710b0 mempool Tx prev not found 73a5af9661
stored orphan tx 7f86e710b0 (mapsz 15)
ERROR: FetchInputs() : d02d4ba85b mempool Tx prev not found 8ca4687af1
stored orphan tx d02d4ba85b (mapsz 16)
received getdata for: tx de72b672826e9013aa7f
ResendWalletTransactions()
ERROR: FetchInputs() : 38b44facd9 mempool Tx prev not found c39f7dc03d
stored orphan tx 38b44facd9 (mapsz 17)

Not really a bug, just one or more people who are trying to get us on the LTC (or another) chain.
Just ignore it

Oh   Weird. How do they do it?

Not sure *how* they do it ... probably a misconfigured port somewhere.
But normally this should not happen because litecoin clients should not be allowed to talk to phenixcoin clients.
Each coin should use a different identifier (often called "magic number"), but pxc and most other coins did not change this identifier when copying the code base of litecoin
(this identifier is 4 bytes, in the pchMessageStart variable)

With a correct setting of this variable to something else (as long as it is not used by another coin), it would take at least someone manually copying the litecoin blockchain into pxc directory to have this problem.

[JohnCar]

Morning bump...

[maxpower]

I updated my Mac build of the PhenixCoin wallet to version 0.6.4.7, which resolved a syncing problem for me. The URL is at the Mac Wallets thread listed in my signature. Enjoy!