I will post in big BOLD letters when it is.

Is the pool back up?

Quote from: bytemaster on November 11, 2013, 07:58:30 PM
Good news everyone... initial testing with hosting protosharesd on my mac shows things are working.

I have also made some improvements to the miner to support more threads, and best of all, mine 30% faster.    I will be releasing the new miner and pool within the hour.

Yay! Can't wait to get back into the pool.

New pool is incompatible with prior miners because of protocol updates.

Still waiting on word from FreeTrade on his progress with the checkpoint update.   Could someone integrate the version number patch presented above as a pull request for me?  Thanks.

Good news everyone... initial testing with hosting protosharesd on my mac shows things are working.

I have also made some improvements to the miner to support more threads, and best of all, mine 30% faster.    I will be releasing the new miner and pool within the hour. 

Quote from: bytemaster on November 11, 2013, 07:03:27 PM

Quote from: barwizi on November 11, 2013, 06:59:16 PM

Quote from: bytemaster on November 11, 2013, 06:50:16 PM
Ok, it appears that crash may be limited to linux only.   FreeTrade is working to add a checkpoint right after the fork and hopefully that will fix that issue.

In the mean time, I am going to work on a hack to allow me to host protosharesd from my mac client and if that works without crashing then the pool will be up soon.

i think a checkpoint is a step in the right direction, but when someone starts the current client they run the risk on syncing the wrong chain since it's all the same up to now. we need to make a clear distinction in the next one and ensure that it refuses to connect to older versions, otherwise we run the risk of having three versions of clients out there.

I agree.  So we need to have a two phased release.  One with a partial solution that increments the client version number and then uses the checkpoint validation.  Then after that has been widely distributed, the next version should only talk to clients that are using the new version.   

Can you recommend how to do these version numbers.  I am not terribly familiar with all the inner workings of the Bitcoin Qt implementation.

see here https://github.com/Petr1fied/gamecoin/blob/master/src/version.h

i'd have just done it myself and saved you the trouble...but i cant git from windows.

Quote from: NineLives on November 11, 2013, 07:24:42 PM
byte or Amazon, will you escrow for me please?

Sorry I am stuck with some other work and don't have controllable BTC/PTS wallet in hand.

Quote from: NineLives on November 11, 2013, 07:24:42 PM
byte or Amazon, will you escrow for me please?

I would normally, but am too busy right now.

byte or Amazon, will you escrow for me please?

Quote from: bytemaster on November 11, 2013, 07:03:27 PM

Quote from: barwizi on November 11, 2013, 06:59:16 PM

Quote from: bytemaster on November 11, 2013, 06:50:16 PM
Ok, it appears that crash may be limited to linux only.   FreeTrade is working to add a checkpoint right after the fork and hopefully that will fix that issue.

In the mean time, I am going to work on a hack to allow me to host protosharesd from my mac client and if that works without crashing then the pool will be up soon.

i think a checkpoint is a step in the right direction, but when someone starts the current client they run the risk on syncing the wrong chain since it's all the same up to now. we need to make a clear distinction in the next one and ensure that it refuses to connect to older versions, otherwise we run the risk of having three versions of clients out there.

I agree.  So we need to have a two phased release.  One with a partial solution that increments the client version number and then uses the checkpoint validation.  Then after that has been widely distributed, the next version should only talk to clients that are using the new version.   

Can you recommend how to do these version numbers.  I am not terribly familiar with all the inner workings of the Bitcoin Qt implementation.

currently reading through the various implementations done before. i'll get back to you in five minutes

Quote from: barwizi on November 11, 2013, 06:59:16 PM

Quote from: bytemaster on November 11, 2013, 06:50:16 PM
Ok, it appears that crash may be limited to linux only.   FreeTrade is working to add a checkpoint right after the fork and hopefully that will fix that issue.

In the mean time, I am going to work on a hack to allow me to host protosharesd from my mac client and if that works without crashing then the pool will be up soon.

i think a checkpoint is a step in the right direction, but when someone starts the current client they run the risk on syncing the wrong chain since it's all the same up to now. we need to make a clear distinction in the next one and ensure that it refuses to connect to older versions, otherwise we run the risk of having three versions of clients out there.

I agree.  So we need to have a two phased release.  One with a partial solution that increments the client version number and then uses the checkpoint validation.  Then after that has been widely distributed, the next version should only talk to clients that are using the new version.   

Can you recommend how to do these version numbers.  I am not terribly familiar with all the inner workings of the Bitcoin Qt implementation.

I've also had very good stability on my mac client.    Only crashed one time over the last few days.   That crash occurred when I typed the "getwork" command in the console.   I was solo mining at the time.

Quote from: bytemaster on November 11, 2013, 06:50:16 PM
Ok, it appears that crash may be limited to linux only.   FreeTrade is working to add a checkpoint right after the fork and hopefully that will fix that issue.

In the mean time, I am going to work on a hack to allow me to host protosharesd from my mac client and if that works without crashing then the pool will be up soon.

i think a checkpoint is a step in the right direction, but when someone starts the current client they run the risk on syncing the wrong chain since it's all the same up to now. we need to make a clear distinction in the next one and ensure that it refuses to connect to older versions, otherwise we run the risk of having three versions of clients out there.

Quote from: glongsword on November 11, 2013, 06:52:51 PM

Quote from: bytemaster on November 11, 2013, 06:50:16 PM
Ok, it appears that crash may be limited to linux only.   FreeTrade is working to add a checkpoint right after the fork and hopefully that will fix that issue.

In the mean time, I am going to work on a hack to allow me to host protosharesd from my mac client and if that works without crashing then the pool will be up soon.

You should still be careful though, since your pool is so large.  I don't know about the mac client, but my windows wallet crashes every few hours when I'm mining, and even when I'm not, it occasionally stops receiving the block chain, and mines orphans continuously until I restart it.  This is true for both the first and second versions.

Similar to me, my windows client stops receiving the blockchain every couple of hours.  I need to close it and reopen to get synced, although it never crash.

Quote from: glongsword on November 11, 2013, 06:52:51 PM

Quote from: bytemaster on November 11, 2013, 06:50:16 PM
Ok, it appears that crash may be limited to linux only.   FreeTrade is working to add a checkpoint right after the fork and hopefully that will fix that issue.

In the mean time, I am going to work on a hack to allow me to host protosharesd from my mac client and if that works without crashing then the pool will be up soon.

You should still be careful though, since your pool is so large.  I don't know about the mac client, but my windows wallet crashes every few hours when I'm mining, and even when I'm not, it occasionally stops receiving the block chain, and mines orphans continuously until I restart it.  This is true for both the first and second versions.

So far, knock on wood, I have never had my mac client show these problems...  the thing I find amazing is that we cloned from the latest Bitcoin Qt code base and then only modified the proof-of-work and a few chain parameters and then we have all of this instability on the network side.