Where are you getting 1.4.2? The links on the first post all still link to 1.4.1? I have refreshed a million times, and the only links and descriptions are for 1.4.1 still. I think he just screwed-up the title...

P.S. It's almost 01:00 here, that is when mass-genocide happens for connections... watching like a hawk again. lol. OOps... forgot it is military time 13:00 not 01:00...

You could still allow internal trades... since that doesn't use the wallet until deposit or withdraw...

Eg, Just inform them that deposits and withdraws are the only limitation for the coins. But they can still trade to any coin that you have listed, which is working, since you KNOW the coins you have already received are in your possession.

Just saying, that that might be a future upgrade to your system, if you implemented it, to reduce or alleviate some issues with coins that all eventually have a fork. Stopping all trades, internal and external is kind-of silly.

It is only the "newly minted coins", or "transfer-blocks" that are the issue with the exchanges. You could trade any coins already confirmed and in your possession, without any issues. (Just blocking withdrawals and deposits with a notice to those depositing and withdrawing. With a little baby-sitting, you know how to get on the right chain, and get accidental deposits which you can't control.)

An internal trade is one that someone has already sent and been confirmed as being "on the right chain".

Unless the fork is longer than the number of confirms... but by that point, it is already too late anyways, those have already been traded and would be lost at that point. If you know there is a fork, and you know where it is... roughly... you know which coins to "not trust" that came-in beyond block-x or within x-blocks...

But if someone deposited 20000 blocks at 5000-height, and the fork is 7000+... then you can safely allow those coins to move to any internal account on an exchange. Since those coins are not physically moved in a wallet, just tracked by the database as having a new owner.

When you trade CAP for BTC on an exchange, you don't get it instantly deposited into a personal wallet. It stays in the exchanges wallet, until you decide to withdraw it to your external wallet. Then it just checks that you are the owner, and if you are, they get pushed to a block for withdraw.

Internally, issues with a wallet only impede deposits, because someone may be depositing on the wrong chain, which is not detected by the other chain. (So it can't be collected, or would be erased if it came in after the fork, from another block, or didn't come in at all.)

But internally, it doesn't matter. On an exchange. (Not to a trader, who doesn't actually withdraw, but simply exchanges CAP->BTC then uses that BTC to buy WDC... from that same exchange. Not being able to remove it to your personal wallet is simply a hinderance. That can be instantly warned, prior to exchange, if the system takes that into consideration. Not everyone "cashes-out", many just keep trading from coin to coin.)

The short solution is to temporarily raise the "confirm acceptance" for the exchange to something crazy like 10,000 confirms for deposits, and stop all withdraws. Then, inform anyone making a trade, that they will not be able to withdraw that coin, only trade for another coin, which can be withdrawn. While any pending deposits will be notified on a similar level, alerting them that pending deposits will not be available for trade, until the fork has found a resolution. Asking them not to deposit, until the fork is over, and alerting them that pending deposits may not come through, and may have to be resent, if they were sent from the wrong fork. (If sent from the wrong fork, the coins would return to the wallet of the sender, once the bad fork disappears.)

Got it from here and it is still working well.

One problem... there is no 1.4.2 yet... The title of the post says 1.4.2 but the program is only 1.4.1...

Who compiled that version? Where is the source? Why is it not listed on page 1?

Just asking before I download some strangers personal version of a program that might be a backdoor broadcasting my wallet or doing something that can't be monitored.

V1.4.1 listed on post 1 of this thread is still functioning at the moment... and indicates no-where, other than the title, there is a v1.4.2 made by the creator/manager "John Eden".

Excuse my paranoia... lol

ISAWHIM: Just in case you did not know, mullick is the active maintainer/developer of CAP, may be you can reduce a bit the paranoia setting

Woirked 16 hours. Came home apent another 3 getting that client to sync and get it out. Just forgot to update the main page and change version # before I pushed to github

 The pool has stayed on the correct chain and both clients I updated to 1.4.2 have stayed on the right chain. I still think the issue will be fixed once everyone gets disconnected for the old peers. If you get on the right chain and leave it peer bans will slowly be lifted and your connections will grow. Went to bed last night one had 3 connections woke up to 23 the other has maintained 20+ all nihgt

Gotta go to work again.

Version 7000 is the protocol version not the wallet version. Its what is used to classify older peers before the protocol switch. There is no need to up protocol version in this release

updated on http://cap.coinmine.pl

So is 1.4.1 still OK to connect with, and run if it connects for us?

I really wish the POS blocks were on a separate chain. Every time a POS is found, it forces all our half-finished work to stop, and get a new hash, essentially starting the hunt for a normal POW block, which has to be built off that POS block, which is not circulating through the net fast enough.

If it was a separate chain, built off the same seed, running along side of the POW chain... except POS only having to match the hash of the "seed" and the "last hard-coded POW block"... (In addition to being valid with your signature and valid block that was staked...) Then it wouldn't matter if they were out of order, as long as they were valid, until the point where they had to move back to the POW chain as a normal TX. But that would not interfere with the POW chain that does require successive building, to prevent tampering.

Though, because POS moves too fast, with low diff... it is inevitable that many POS that are honestly earned, will be rejected due to slow distribution through the net. (Might be a little faster if it was a separate chain also, with a variable diff too.)

But that is not a tiny thing that can be changed by adjusting a setting. It would require a lot more programming to make it reality. (Just thinking out loud here, not demanding anything. )