[ANN] Philosopherstone - PHS | No Premine | Mandatory update 1.2Beta3

[monocolor]

need a consensus, if the community will go back to 1.1 chain, we should probably do it, but it seems to me that 1.1 chain is not a good one, it is a forked one, not the original one.

[Palmdetroit]

need a consensus, if the community will go back to 1.1 chain, we should probably do it, but it seems to me that 1.1 chain is not a good one, it is a forked one, not the original one.

The current chain the pools and everyone is on is the 1.1 chain (even though using 1.2client), that is why the 1.2 client is not able to download then chain by itself and why you need to run 1.1 first.  The choice is pretty much go on 1.1 as we have been doing or go back ~6000 blocks to 1.2, if that is possible.  Community will have to decide this for sure.

As john said and which seems to be the case by how the client works "It seems to me that someone forked the PHS chain and it is no longer the original chain."


edit* It's also possible 1.2 chain is correct and 1.1 is the wrong chain, will find out.

And I do know 100% for sure there are up to 6 other forks lol

edit2 and they are all at much lower height than the 'main' one

[bholzer]

We will prolly have to stick with 1.1 and work from there, not sure anyone would want to lose last 6k blocks lol

Even though I haven't been mining on the 1.1 chain, I'm willing to lose the blocks I've mined on the original chain if it means far fewer people get screwed. For a while, most of the hash power remained on the original chain (which is why I continued to mine it) but this thread kept going a different direction.

My #1 concern is saving PHS and getting everything back on track. The majority of my PHS was pre-incident so as long as that is secure I can live with the direction things go.

[Tony116]

http://phs.minar.cc/
same scam pool. :|

[Balthazar]

The bug is ridiculously simple.

Code:

if(GetAdjustedTime() > RWD_SWITCH_TIME)
    nSubsidy /= 64;

GetAdjustedTime() call MUST be replaced with nTime. After this you should re-download block chain and add the new checkpoint. It's the only way to continue operation correctly.

[Palmdetroit]

We will prolly have to stick with 1.1 and work from there, not sure anyone would want to lose last 6k blocks lol

My #1 concern is saving PHS and getting everything back on track. The majority of my PHS was pre-incident so as long as that is secure I can live with the direction things go.

ya we shall try but it won't be easy

[Palmdetroit]

The bug is ridiculously simple.

Code:

if(GetAdjustedTime() > RWD_SWITCH_TIME)
    nSubsidy /= 64;

GetAdjustedTime() call MUST be replaced with nTime. After this you should re-download block chain and add the new checkpoint. It's the only way to continue operation correctly.

P.S. I really have no idea why anyone would try to use GetAdjustedTime() here.

nvm 1.2 will try quick...

https://github.com/palmd/philosopherstone/commit/21b1b93e860c307914feca1d799c37e9db181942

made it past good ol' 6084

[monocolor]

The bug is ridiculously simple.

Code:

if(GetAdjustedTime() > RWD_SWITCH_TIME)
    nSubsidy /= 64;

GetAdjustedTime() call MUST be replaced with nTime. After this you should re-download block chain and add the new checkpoint. It's the only way to continue operation correctly.

P.S. I really have no idea why anyone would try to use GetAdjustedTime() here.

hmm thanks Balthazar... with expert's word can someone please fix the issue and recompile the client? John does not have access to his build env and someone else please fix the problem and publish the client? Then we should be back on track...

[Palmdetroit]

The bug is ridiculously simple.

Code:

if(GetAdjustedTime() > RWD_SWITCH_TIME)
    nSubsidy /= 64;

GetAdjustedTime() call MUST be replaced with nTime. After this you should re-download block chain and add the new checkpoint. It's the only way to continue operation correctly.

P.S. I really have no idea why anyone would try to use GetAdjustedTime() here.

hmm thanks Balthazar... with expert's word can someone please fix the issue and recompile the client? John does not have access to his build env and someone else please fix the problem and publish the client? Then we should be back on track...

just above your post

https://github.com/palmd/philosopherstone

[monocolor]

The bug is ridiculously simple.

Code:

if(GetAdjustedTime() > RWD_SWITCH_TIME)
    nSubsidy /= 64;

GetAdjustedTime() call MUST be replaced with nTime. After this you should re-download block chain and add the new checkpoint. It's the only way to continue operation correctly.

P.S. I really have no idea why anyone would try to use GetAdjustedTime() here.

hmm thanks Balthazar... with expert's word can someone please fix the issue and recompile the client? John does not have access to his build env and someone else please fix the problem and publish the client? Then we should be back on track...

just above your post

nice, sorry I missed it, will try now..

oh, do you have a windows client?

[Palmdetroit]

The bug is ridiculously simple.

Code:

if(GetAdjustedTime() > RWD_SWITCH_TIME)
    nSubsidy /= 64;

GetAdjustedTime() call MUST be replaced with nTime. After this you should re-download block chain and add the new checkpoint. It's the only way to continue operation correctly.

P.S. I really have no idea why anyone would try to use GetAdjustedTime() here.

1.2 made it past 6084 but seems to go very very slow now 8332,..8333..8334  very slow

[Palmdetroit]

The bug is ridiculously simple.

Code:

if(GetAdjustedTime() > RWD_SWITCH_TIME)
    nSubsidy /= 64;

GetAdjustedTime() call MUST be replaced with nTime. After this you should re-download block chain and add the new checkpoint. It's the only way to continue operation correctly.

P.S. I really have no idea why anyone would try to use GetAdjustedTime() here.

hmm thanks Balthazar... with expert's word can someone please fix the issue and recompile the client? John does not have access to his build env and someone else please fix the problem and publish the client? Then we should be back on track...

just above your post

nice, sorry I missed it, will try now..

oh, do you have a windows client?

i do but id rather not post it , not sure what this will do tbh might fry your wallet or something, if you can compile tho go for it, and if it works ill post it of course

[Balthazar]

Actually it's recommended to compare project with an appropriate NVC sources tree revision and perform the differences review... Because it's possible, that another logical bomb waiting for the moment.

1.2 made it past 6084 but seems to go very very slow now 8332,..8333..8334  very slow

It's normal, because there are not so much nodes on the right chain. Add checkpoints on block 8332 and publish your build, it will help to resolve this problem.

[monocolor]

The bug is ridiculously simple.

Code:

if(GetAdjustedTime() > RWD_SWITCH_TIME)
    nSubsidy /= 64;

GetAdjustedTime() call MUST be replaced with nTime. After this you should re-download block chain and add the new checkpoint. It's the only way to continue operation correctly.

P.S. I really have no idea why anyone would try to use GetAdjustedTime() here.

1.2 made it past 6084 but seems to go very very slow now 8332,..8333..8334  very slow

I am using the existing 1.2 client, and it has been very slow now at block 8337, the block still advance but slowly. It seems that it's been sync'ing the pos blocks... Oh well, seems to me all the recent pow/pos coin have problems, HBN, CAP, STR, GRW, etc. Looks like there base code may not be as mature as Litecoin...

[Balthazar]

Looks like there base code may not be as mature as Litecoin...

Elacoin and many another examples can prove that you are wrong. Shitty code could be done using any codebase.

[Palmdetroit]

Actually it's recommended to compare project with an appropriate NVC sources tree revision and perform the differences review... Because it's possible, that another logical bomb waiting for the moment.

1.2 made it past 6084 but seems to go very very slow now 8332,..8333..8334  very slow

It's normal, because there are not so much nodes on the right chain. Add checkpoints on block 8332 and publish your build, it will help to resolve this problem.

just for 8332? like this?
https://github.com/palmd/philosopherstone/commit/00b856b38be0af3b3142ef599f5eac9551a9a79f

[Palmdetroit]

just jumped back 2500 blocks or so.. going up fast now


now slow again 8353

[Balthazar]

just for 8332? like this?
https://github.com/palmd/philosopherstone/commit/00b856b38be0af3b3142ef599f5eac9551a9a79f

You can place it on any 9000+ block, but 8332 will be enough.

[Palmdetroit]

Actually it's recommended to compare project with an appropriate NVC sources tree revision and perform the differences review... Because it's possible, that another logical bomb waiting for the moment.

1.2 made it past 6084 but seems to go very very slow now 8332,..8333..8334  very slow

It's normal, because there are not so much nodes on the right chain. Add checkpoints on block 8332 and publish your build, it will help to resolve this problem.

just for 8332? like this?
https://github.com/palmd/philosopherstone/commit/00b856b38be0af3b3142ef599f5eac9551a9a79f

block has is now 8332 000000010fdba3893a3129400f6bf820d068833426c8454c1fc93b9a1994bc07 and not 000000003738edb294dda617def727991d763efbe7c328a2c4d26e46d39d9ea9

WTF?

block 11111 now

[Balthazar]

WTF?

Reorganize happened, there is another fork and this chain has a higher weight.

OK, remove this checkpoint and wait until syncronization will be completed.