Topic: There has to be an explanation as to why Caps keeps forking, for the community. (Read 719 times)

I agree. These guys are doing a good job fixing issues as they surface and their following is showing that. Lesser dev teams would have had their coins killed by now from this

Ok so this topic is useful -

it seems to be that PoS currency is in some way more inclined to these errors , because of why?

the issue relating to the Code that needs to be implemented with regard to Stratum and the orphan issue?

Don't stress Bitjohn if the community can see action this topic is not political , if the community see action that will help .

the best policy is communication . 

No worries. As long as its being looked at - definitely something odd with the v1.4 windows qt build.

Otherwise I'll have a go with it myself in a few days maybe.

Cheers!

The Original fork was created due to a ntework communication issue it seems. In 1.4 I added the necessary checkpoints and a few other minor adjustments.

In order to correct the communication issue I paid out of pocket to setup 2 fully connectable Dedicated bnodes to keep the network communicating. They are running an average of 40 connections each. I have also setup my own personal server for this task as well

In 1.4.1 I will be adding hardened checkpoints, DNS seeds, and IRC changes if nessecary.

The issues in the past few days have been isolated to 1 pool. www.bottlecaps.com It is mining its own separate chain with nobody else on the network.

When speaking to the pool operator this morning he was not running the nodes I had setup and he now is directly connected to them. This should prevent the issue in the future.

Besides this pool the network has stayed together very nicely. Orphan rate has dropped substantially. We are no longer seeing strings of multiple orphaned blocks at smaller pools

BitcoinFX

You have been very patient about the issue with your wallet. I did get a little time to attempt to recreate the issue and will be doing so  right now even more.

Ill try to compile a fresh client and get it to you soon to see if in fact it was a compiling error with the release

Thank you for your support and patience

The issue is pools going off on their own forks its more of an issue with Proof of Stake pools and the code folks are using them. The coin itself has not forked.

I'm not criticizing Bitjohn  - I'm saying lets learn as to what is going on .

OK two forks then , do we count this one?

anyhow its a lot of forks in a short time , and it was a new PoS type clone , so maybe we can learn from it .

which in turn will help fix the problem.

Where are you getting 3 CAPs forks from? There was one fork that forked the fork. Since 1.4 after that there was one pool that lost its connections and started its own thing not really a fork but a pool issue. Not aware of any forks but the original 1.3 fork.

Nods.

Something major is wrong with the current v1.4 qt build. It crashes on sending coins from all of my CAP wallets on 3 different Windows PC's.

A linux build seems to be OK. Although these forks are also of concern and need investigating.

Personally i sold all my Caps last major fork.

but Caps just now forked again with Verns pool starting block that i noticed had 9 then 21 thousand blocks , basically like it started a new chain.

My question(s) are these :

its the Re-target or some other parameter related to the potential to fork?

it was my suspicion that originally Verns pool was having the "image" of the pool that could effectively handle Stratum and this led to everyone being on his pool .

but since then Caps has forked 3 more times?

so surely there is something to take away from all this ?

I do see a lot of PoS NVC type clones coming in the future so it would be useful to learn and understand.