*confirmed*
works great thatway ..

I personally use 2 different VPS instances to do that ..
and wrote a little python script to simplify 'switching' of active delegates

That is my current procedure.

Quote from: emski on August 26, 2014, 03:23:12 PM

Quote from: DACSunlimited on August 26, 2014, 03:21:08 PM
Regardless of possible bug in the client, this behavior is still harmful to the network, topics related to this have already been discussed in the DPOS thread.

Quote from: emski on August 26, 2014, 03:16:51 PM

Quote from: DACSunlimited on August 26, 2014, 03:10:11 PM

Quote from: xeroc on August 26, 2014, 03:06:49 PM
We should start a new thread and reflag delegates that are produce forks ...
not missing blocks is VERY easy that way but does no good to the network! You just fail your responsibilities against the network ..

I see missing a block A LOT less harmful for the network than producing forks!!

The block must be in the same block number, and be produced by the same delegate, here is a example just taken.

Even though falling into a fork might be a bug in latest version, but we definitely need to enable the auto fire operation.

QuoteFORKED BLOCK              FORKING BLOCK ID              SIGNING DELEGATE      TXN COUNT      SIZE           TIMESTAMP   LATENCY   VALID    IN CURRENT CHAIN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
         321979
     ef96dea7b653c7292c790935114360eee84708c7                        e.coin              1       766 2014-08-26T14:17:10       169     YES                 YES
     7aad16dc0e47e06a093888568bf268a1f2c1a188                        btsnow             13      3857 2014-08-26T14:29:20         0     N/A                  NO
         322117
     f402e661aeff4ba1704dc59441e7ba05b4d83981         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         0     YES                 YES
     44cc35cf2a4afe38a3e8a4480e7c8f0953991e5a         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         1     N/A                  NO
         322131
     133db0ce1040b169226753ee8d2dc7735ff2a3b5             google.helloworld              1       402 2014-08-26T14:42:50         0     YES                 YES
     0fad4bd06f03ab6c98a3d1b1094ac331f2d78b03             google.helloworld              1       402 2014-08-26T14:42:50         1     N/A                  NO
         322136
     8208884d226913d653520c52e65c75e58dcdb14f          microsoft.helloworld              0       166 2014-08-26T14:43:40         0     YES                 YES
     3e4d2d05f9d86382eaeb5c320c73323e5a2b6add          microsoft.helloworld              0       166 2014-08-26T14:43:40         1     N/A                  NO
         322139
     c6ce76317addf5f1b78e6700ea30da5f443f5e03                        x.ebit              0       166 2014-08-26T14:44:10         0     N/A                  NO
     4322211b2f74a2d43183a17042c057da64c4486c                        x.ebit              0       166 2014-08-26T14:44:10         1     N/A                  NO

Have you considered the possibility of BUG in the client?
What if it exists prior 0.4.8 ?

If it is a bug in the client then how replacing the delegate will help the network ?

Build and run your client in another screen process first, input

info

to get the "wallet_next_block_production_time"

Catch a good operation time window, lock one, and unlock another.

Quote from: DACSunlimited on August 26, 2014, 03:21:08 PM
Regardless of possible bug in the client, this behavior is still harmful to the network, topics related to this have already been discussed in the DPOS thread.

Quote from: emski on August 26, 2014, 03:16:51 PM

Quote from: DACSunlimited on August 26, 2014, 03:10:11 PM

Quote from: xeroc on August 26, 2014, 03:06:49 PM
We should start a new thread and reflag delegates that are produce forks ...
not missing blocks is VERY easy that way but does no good to the network! You just fail your responsibilities against the network ..

I see missing a block A LOT less harmful for the network than producing forks!!

The block must be in the same block number, and be produced by the same delegate, here is a example just taken.

Even though falling into a fork might be a bug in latest version, but we definitely need to enable the auto fire operation.

QuoteFORKED BLOCK              FORKING BLOCK ID              SIGNING DELEGATE      TXN COUNT      SIZE           TIMESTAMP   LATENCY   VALID    IN CURRENT CHAIN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
         321979
     ef96dea7b653c7292c790935114360eee84708c7                        e.coin              1       766 2014-08-26T14:17:10       169     YES                 YES
     7aad16dc0e47e06a093888568bf268a1f2c1a188                        btsnow             13      3857 2014-08-26T14:29:20         0     N/A                  NO
         322117
     f402e661aeff4ba1704dc59441e7ba05b4d83981         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         0     YES                 YES
     44cc35cf2a4afe38a3e8a4480e7c8f0953991e5a         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         1     N/A                  NO
         322131
     133db0ce1040b169226753ee8d2dc7735ff2a3b5             google.helloworld              1       402 2014-08-26T14:42:50         0     YES                 YES
     0fad4bd06f03ab6c98a3d1b1094ac331f2d78b03             google.helloworld              1       402 2014-08-26T14:42:50         1     N/A                  NO
         322136
     8208884d226913d653520c52e65c75e58dcdb14f          microsoft.helloworld              0       166 2014-08-26T14:43:40         0     YES                 YES
     3e4d2d05f9d86382eaeb5c320c73323e5a2b6add          microsoft.helloworld              0       166 2014-08-26T14:43:40         1     N/A                  NO
         322139
     c6ce76317addf5f1b78e6700ea30da5f443f5e03                        x.ebit              0       166 2014-08-26T14:44:10         0     N/A                  NO
     4322211b2f74a2d43183a17042c057da64c4486c                        x.ebit              0       166 2014-08-26T14:44:10         1     N/A                  NO

Have you considered the possibility of BUG in the client?
What if it exists prior 0.4.8 ?

If it is a bug in the client then how replacing the delegate will help the network ?
This was discussed extensively indeed. And there are a lot of people using backups and simultaneous instances. That is harmful.

Regardless of possible bug in the client, this behavior is still harmful to the network, topics related to this have already been discussed in the DPOS thread.

Quote from: emski on August 26, 2014, 03:16:51 PM

Quote from: DACSunlimited on August 26, 2014, 03:10:11 PM

Quote from: xeroc on August 26, 2014, 03:06:49 PM
We should start a new thread and reflag delegates that are produce forks ...
not missing blocks is VERY easy that way but does no good to the network! You just fail your responsibilities against the network ..

I see missing a block A LOT less harmful for the network than producing forks!!

The block must be in the same block number, and be produced by the same delegate, here is a example just taken.

Even though falling into a fork might be a bug in latest version, but we definitely need to enable the auto fire operation.

QuoteFORKED BLOCK              FORKING BLOCK ID              SIGNING DELEGATE      TXN COUNT      SIZE           TIMESTAMP   LATENCY   VALID    IN CURRENT CHAIN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
         321979
     ef96dea7b653c7292c790935114360eee84708c7                        e.coin              1       766 2014-08-26T14:17:10       169     YES                 YES
     7aad16dc0e47e06a093888568bf268a1f2c1a188                        btsnow             13      3857 2014-08-26T14:29:20         0     N/A                  NO
         322117
     f402e661aeff4ba1704dc59441e7ba05b4d83981         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         0     YES                 YES
     44cc35cf2a4afe38a3e8a4480e7c8f0953991e5a         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         1     N/A                  NO
         322131
     133db0ce1040b169226753ee8d2dc7735ff2a3b5             google.helloworld              1       402 2014-08-26T14:42:50         0     YES                 YES
     0fad4bd06f03ab6c98a3d1b1094ac331f2d78b03             google.helloworld              1       402 2014-08-26T14:42:50         1     N/A                  NO
         322136
     8208884d226913d653520c52e65c75e58dcdb14f          microsoft.helloworld              0       166 2014-08-26T14:43:40         0     YES                 YES
     3e4d2d05f9d86382eaeb5c320c73323e5a2b6add          microsoft.helloworld              0       166 2014-08-26T14:43:40         1     N/A                  NO
         322139
     c6ce76317addf5f1b78e6700ea30da5f443f5e03                        x.ebit              0       166 2014-08-26T14:44:10         0     N/A                  NO
     4322211b2f74a2d43183a17042c057da64c4486c                        x.ebit              0       166 2014-08-26T14:44:10         1     N/A                  NO

Have you considered the possibility of BUG in the client?
What if it exists prior 0.4.8 ?

Quote from: DACSunlimited on August 26, 2014, 03:10:11 PM
The block must be in the same block number, and be produced by the same delegate, here is a example just taken.

That is perfectly clear

Quote
Even though falling into a fork might be a bug in latest version, but we definitely need to enable the auto fire operation

*agreed* .. but be prepared to loose some active delegates ... maybe also consider a fired-window such that delegates are not fired indefinitely for skrewing up once ...

much like a 2 weeks penalty .. or kind of

Quote from: DACSunlimited on August 26, 2014, 03:10:11 PM

Quote from: xeroc on August 26, 2014, 03:06:49 PM
We should start a new thread and reflag delegates that are produce forks ...
not missing blocks is VERY easy that way but does no good to the network! You just fail your responsibilities against the network ..

I see missing a block A LOT less harmful for the network than producing forks!!

The block must be in the same block number, and be produced by the same delegate, here is a example just taken.

Even though falling into a fork might be a bug in latest version, but we definitely need to enable the auto fire operation.

QuoteFORKED BLOCK              FORKING BLOCK ID              SIGNING DELEGATE      TXN COUNT      SIZE           TIMESTAMP   LATENCY   VALID    IN CURRENT CHAIN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
         321979
     ef96dea7b653c7292c790935114360eee84708c7                        e.coin              1       766 2014-08-26T14:17:10       169     YES                 YES
     7aad16dc0e47e06a093888568bf268a1f2c1a188                        btsnow             13      3857 2014-08-26T14:29:20         0     N/A                  NO
         322117
     f402e661aeff4ba1704dc59441e7ba05b4d83981         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         0     YES                 YES
     44cc35cf2a4afe38a3e8a4480e7c8f0953991e5a         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         1     N/A                  NO
         322131
     133db0ce1040b169226753ee8d2dc7735ff2a3b5             google.helloworld              1       402 2014-08-26T14:42:50         0     YES                 YES
     0fad4bd06f03ab6c98a3d1b1094ac331f2d78b03             google.helloworld              1       402 2014-08-26T14:42:50         1     N/A                  NO
         322136
     8208884d226913d653520c52e65c75e58dcdb14f          microsoft.helloworld              0       166 2014-08-26T14:43:40         0     YES                 YES
     3e4d2d05f9d86382eaeb5c320c73323e5a2b6add          microsoft.helloworld              0       166 2014-08-26T14:43:40         1     N/A                  NO
         322139
     c6ce76317addf5f1b78e6700ea30da5f443f5e03                        x.ebit              0       166 2014-08-26T14:44:10         0     N/A                  NO
     4322211b2f74a2d43183a17042c057da64c4486c                        x.ebit              0       166 2014-08-26T14:44:10         1     N/A                  NO

Have you considered the possibility of BUG in the client?
What if it exists prior 0.4.8 ?

Quote from: xeroc on August 26, 2014, 03:06:49 PM
We should start a new thread and reflag delegates that are produce forks ...
not missing blocks is VERY easy that way but does no good to the network! You just fail your responsibilities against the network ..

I see missing a block A LOT less harmful for the network than producing forks!!

The block must be in the same block number, and be produced by the same delegate, here is a example just taken.

Even though falling into a fork might be a bug in latest version, but we definitely need to enable the auto fire operation.

QuoteFORKED BLOCK              FORKING BLOCK ID              SIGNING DELEGATE      TXN COUNT      SIZE           TIMESTAMP   LATENCY   VALID    IN CURRENT CHAIN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
         321979
     ef96dea7b653c7292c790935114360eee84708c7                        e.coin              1       766 2014-08-26T14:17:10       169     YES                 YES
     7aad16dc0e47e06a093888568bf268a1f2c1a188                        btsnow             13      3857 2014-08-26T14:29:20         0     N/A                  NO
         322117
     f402e661aeff4ba1704dc59441e7ba05b4d83981         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         0     YES                 YES
     44cc35cf2a4afe38a3e8a4480e7c8f0953991e5a         btsx.chinesecommunity              0       166 2014-08-26T14:40:30         1     N/A                  NO
         322131
     133db0ce1040b169226753ee8d2dc7735ff2a3b5             google.helloworld              1       402 2014-08-26T14:42:50         0     YES                 YES
     0fad4bd06f03ab6c98a3d1b1094ac331f2d78b03             google.helloworld              1       402 2014-08-26T14:42:50         1     N/A                  NO
         322136
     8208884d226913d653520c52e65c75e58dcdb14f          microsoft.helloworld              0       166 2014-08-26T14:43:40         0     YES                 YES
     3e4d2d05f9d86382eaeb5c320c73323e5a2b6add          microsoft.helloworld              0       166 2014-08-26T14:43:40         1     N/A                  NO
         322139
     c6ce76317addf5f1b78e6700ea30da5f443f5e03                        x.ebit              0       166 2014-08-26T14:44:10         0     N/A                  NO
     4322211b2f74a2d43183a17042c057da64c4486c                        x.ebit              0       166 2014-08-26T14:44:10         1     N/A                  NO

We should start a new thread and reflag delegates that are produce forks ...
not missing blocks is VERY easy that way but does no good to the network! You just fail your responsibilities against the network ..

I see missing a block A LOT less harmful for the network than producing forks!!

Quote from: DACSunlimited on August 26, 2014, 02:59:08 PM
To All delegates:

Please NOT running your delegates in two clients at the same time, otherwise, any one post evidence like following

Code Select Expand

   c6ce76317addf5f1b78e6700ea30da5f443f5e03                        x.x              0       166 2014-08-26T14:44:10         0     N/A                  NO
     4322211b2f74a2d43183a17042c057da64c4486c                        x.x              0       166 2014-08-26T14:44:10         1     N/A                  NO

We will strongly recommend others to vote them out.

Quote from: liondani on August 26, 2014, 11:41:37 AM


only when I opened the backup json file with an txt editor and erased the last coma ( , ) from the last page, saved the file and tried again I managed to restore my backup...
(I read it here on the forum somewhere as a solution and it worked, in case you don't read/found it yet)

Backup procedure had a bug in the last version .. (the comma at the end)
The bug was fixed in the new version ... so just create a NEW backup ... that should work well

only when I opened the backup json file with an txt editor and erased the last coma ( , ) from the last page, saved the file and tried again I managed to restore my backup...
(I read it here on the forum somewhere as a solution and it worked, in case you don't read/found it yet)

Quote from: puppies on August 26, 2014, 07:03:03 AM
My seed node has been crashing and forking like nothing else.

When you have wallet open with enabled block production for a delegate (it doesn't need to be in top 101) it synchronizes.

My seed node has been crashing and forking like nothing else.

Website client had more connections this morning but was still stuck, but --rebuild-index got it back on the good fork now, apologies to people trying to use the site over the last few hours.