Pages:
Author

Topic: [ANN] New Client for PhenixCoin PXC ** PLEASE UPDATE YOUR CLIENTS ** - page 2. (Read 4360 times)

sr. member
Activity: 350
Merit: 250
- "Bitcore (BTX) - Airdrops every Monday"
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
full member
Activity: 168
Merit: 100
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..
sr. member
Activity: 350
Merit: 250
- "Bitcore (BTX) - Airdrops every Monday"
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.
full member
Activity: 168
Merit: 100
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..
sr. member
Activity: 350
Merit: 250
- "Bitcore (BTX) - Airdrops every Monday"
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
sr. member
Activity: 350
Merit: 250
- "Bitcore (BTX) - Airdrops every Monday"
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 Cheesy 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!  Cool
full member
Activity: 168
Merit: 100
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.
legendary
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na


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  Grin

Iamatrix needs a twin-brother Grin
sr. member
Activity: 350
Merit: 250
- "Bitcore (BTX) - Airdrops every Monday"


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;
legendary
Activity: 1197
Merit: 1000
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
full member
Activity: 168
Merit: 100
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!  Grin

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

(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
newbie
Activity: 42
Merit: 0
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...
sr. member
Activity: 350
Merit: 250
- "Bitcore (BTX) - Airdrops every Monday"
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!  Grin

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

(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) ?
sr. member
Activity: 462
Merit: 250
PXC Research Team
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?

You can mine in the official pools now I think they are good now.

http://phoen01.phenixpool.com/

http://amst01.phenixpool.com/
full member
Activity: 168
Merit: 100
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!  Grin

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

(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
sr. member
Activity: 356
Merit: 250
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?
sr. member
Activity: 350
Merit: 250
- "Bitcore (BTX) - Airdrops every Monday"
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!  Grin

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

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

Am I missing something?
legendary
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
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.


Nobody is perfect Smiley
edit: I see it's updated at http://www.phenixcoin.com Smiley
full member
Activity: 168
Merit: 100
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.


sr. member
Activity: 350
Merit: 250
- "Bitcore (BTX) - Airdrops every Monday"
I added some debug output in src/main.cpp:

Code:
    // Check proof of work
    if (nBits != GetNextWorkRequired(pindexPrev, this)) {
        printf("pindexPrev: %u\n", pindexPrev);
        printf("nBits: %u\n", nBits);
        printf("GetNextWorkRequired(pindexPrev, this): %u\n", GetNextWorkRequired(pindexPrev, this));
        return DoS(100, error("AcceptBlock() : incorrect proof of work"));
    }

and compiled it again, now I get:

Code:
received block 240ba90dc2981bed8761
pindexPrev: 40149344
nBits: 504365055
GetNextWorkRequired(pindexPrev, this): 504365040
ERROR: AcceptBlock() : incorrect proof of work
ERROR: ProcessBlock() : AcceptBlock FAILED

EDIT: not sure if relevant but after running it several times I noticed the value of pindexPrev (the "prev block index" according to the comments, sounds pretty static to me considering that my wallet is stuck at block 2400) seems to vary randomly:

Code:
pindexPrev: 44792240
..
pindexPrev: 29553056
..
pindexPrev: 41622112
..
pindexPrev: 51966576
..
pindexPrev: 41933584

Both nBits and GetNextWorkRequired(pindexPrev, this) are static across different runs.
Pages:
Jump to: