[ANN][CDC] CLOUDCOIN REVIVAL. PoW/PoS. ** LATEST MARCH 2015 OPENSSL FIX **

[almightyruler]

Someone is throwing over 170 MHs at it...

Where are you getting that figure from? If it's the "networkhashps" value in getmininginfo, that won't be correct, because it doesn't account for PoS blocks being generated separately to the PoW network.

[darksoft]

it was from getmininginfo and difficulty was up to 1.7 or thereabouts...

[acckiller]

how can anyone deposit in to bter it saids cdc coin disabled when the fck are they goin to enable deposits again

[okaypool]

Something is WRONG with CDC. I think there are multiple forks. Because wallet syncs for 5 mins, then it shows "out of sync", then it is 50 blocks behind and so on....No deposits showed on bter .  Which one is the official chain??

There are two issues with CDC that I'm going to address in this reply. I'm going to key out some possible solutions in the hope of provoking further discussion.

As mentioned previously, CDC places a lot of (I would say almost extreme) weight on PoS blocks. Around 10 hours ago I saw a massive 286 block correction on the official nodes. Someone generating PoS blocks managed to override/reverse nearly 3 hours worth of blocks minted on the network. Within a few seconds the height dropped from 284909 to 284623, and 14325.14 CDC disappeared from the money supply. That sort of thing is unprecedented AFAIK, and to be honest I didn't think it was even possible to correct that large a number of blocks or time period.

Problem 1: Chain can be influenced by someone holding a large balance who locks (or keeps closed) their wallet, then unlocks it. PoS blocks can be generated very fast by a client, sometimes every few seconds. The huge reversal was started by a client that generated 33 PoS blocks in 4 minutes. In addition, they seem to have started minting PoS at a lower height than the rest of the network, so their fork extended from a lower point in the chain, which is why the network reversal was ultimately so large.

A possible solution is to limit the allowable correction to a maximum number of blocks so such massive reversals are impossible. The limit does need to be chosen carefully, because if it's too small it will cause everyone to continue on their own private fork if there's some issue that causes them to be more than X blocks ahead (their client will refuse to snap back to the main chain)

Problem 2: Miners are sometimes dropping off the main chain, and need to resync. This has happened to me also. I've been struggling to understand why, and the reason hit me 30 mins ago: the client refuses to allow you to mine until you have at least one peer connected, but it doesn't actually care about whether that peer is properly synced. I think what is happening is that the first peer a client is connecting to is on the old chain, so the client starts allowing PoS and PoW mining, which has the potential to create a private fork once you start minting blocks. It won't happen every time, but there's enough peers sitting on the old chain that it's likely to happen at some point.

example:

1. new chain is at height 100
2. old chain is at height 20
3. your client is at height 75 when you start it
4. your client connects to peer on old chain, client permits mining even though new and old chain will never exchange/agree upon minted blocks
5. if you mint a block before connecting to a peer on the new chain, it will be minted at height 76 instead of height 101; you're now on a private fork

I think that segregating the network to ignore the old chain will fix the second problem, and will actually go some way to fixing the first (remember the client that did the huge reversal started minting PoS at a lower height). I am working on that code change right now.

When solving the forking problem, when to release the new version?

[breakbeater]

Deposit addresses on bter starting with "B" : BwZqNy6JxvbJhgf..................
WTF?

[almightyruler]

Cloudcoin v1.3 released

This release will deliberately ban peers on the wrong chain. This should improve network stability and reduce the chance of forking.

Updating is strongly recommended, especially if you are mining.

Download from:

https://www.dropbox.com/sh/9ex30gqpw78s15k/f-AYOkjBql

[almightyruler]

Deposit addresses on bter starting with "B" : BwZqNy6JxvbJhgf..................
WTF?

That's normal. Do 'getnewaddress' a few times in the debug console and you'll see that CDC addresses start with both B and C.

[okaypool]

Cloudcoin v1.3 released

This release will deliberately ban peers on the wrong chain. This should improve network stability and reduce the chance of forking.

Updating is strongly recommended, especially if you are mining.

Download from:

https://www.dropbox.com/sh/9ex30gqpw78s15k/f-AYOkjBql

OH My God, the  version 1.3 without little effect, node can not synchronous

We found bter's wallet is not synchronous

[almightyruler]

OH My God, the  version 1.3 without little effect, node can not synchronous

It looks like there are still nodes which are not on the correct chain, so if you happen to sync via them you'll end up stuck on their fork. It's a real gamble right now.

Starting the client with an empty database and the following options should get you synced to the official chain:

-listen=0 -connect=85.17.81.169 -connect=107.170.49.232

This will ONLY connect to these two IPs, and will also disable inbound connections. Once you are synced you will need to restart the client as normal. (I would delete peers.dat before you restart.)

Your deposits to bter are not showing because they are also having some issues syncing. I will send the same advice to the admin.

[okaypool]

http://cdc.okaypool.com   Back online

[szvr]

http://ww2.sinaimg.cn/bmiddle/a7e6241btw1efcf6pi9pcg207c09qkev.gif
LOVE THE GIRL

http://cdc.okaypool.com

LOVE THE POOL

https://bter.com/trade/cdc_btc

LOVE THE EXCHAGES

LETS GO

[okaypool]

-listen=0 -connect=85.17.81.169 -connect=107.170.49.232


root@2049idc:~# cloudcoind getinfo
{
    "version" : "v1.3.0.0",
    "protocolversion" : 60006,
    "walletversion" : 60000,
    "balance" : 2824.86716400,
    "newmint" : 550.00000000,
    "stake" : 0.00000000,
    "blocks" : 287449,
    "moneysupply" : 5398722.35600000,
    "connections" : 0,
    "proxy" : "",
    "ip" : "98.126.98.138",
    "difficulty" : 0.20381855,
    "testnet" : false,
    "keypoololdest" : 1397279565,
    "keypoolsize" : 102,
    "paytxfee" : 0.00000000,
    "errors" : ""
}
root@2049idc:~#



Please put the mine pool node 98.126.98.138 into the two IP firewall white list

Now is the firewall

It does not connect the two nodes, wallet again cannot be synchronized

[wulagui]

Something is WRONG with CDC. I think there are multiple forks. Because wallet syncs for 5 mins, then it shows "out of sync", then it is 50 blocks behind and so on....No deposits showed on bter .  Which one is the official chain??

[almightyruler]

Please put the mine pool node 98.126.98.138 into the two IP firewall white list

Now is the firewall

It does not connect the two nodes, wallet again cannot be synchronized

Your client is being banned because it is supplying the wrong proof of work for a specific block, which probably means it has forked from the network again.

I don't know whether it's your mining that is causing the fork, or one of your peers. If it is a peer, as a short term solution, you can run your client with those commandline options I mentioned earlier (don't remove the options once you sync, keep them on)

cloudcoind -listen=0 -connect=85.17.81.169 -connect=107.170.49.232   (for daemon)

cloudcoin-qt.exe -listen=0 -connect=85.17.81.169 -connect=107.170.49.232   (for Windows QT client)

This should keep you tied to the two main nodes and prevent other peers influencing your chain. Obviously this is not a long term solution, since it centralises the network. I think the problem is that there is at least one fork which at least a couple of clients are on, so they end up being banned by the official nodes. They may be influencing other clients in the meantime, causing those to hop chains and/or be banned by peers on the opposing chain.

Can we please get as many people as possible trying this, to see if we can get rid of the other fork for good. It's difficult for me to see other chains because my clients ban peers on the "wrong" chain immediately.

[almightyruler]

Something is WRONG with CDC. I think there are multiple forks. Because wallet syncs for 5 mins, then it shows "out of sync", then it is 50 blocks behind and so on....No deposits showed on bter .  Which one is the official chain??

Try the commandline options I suggest above. Temporary solution but hopefully it works. My Windows client has lost sync so I will test this myself.

[okaypool]

Please put the mine pool node 98.126.98.138 into the two IP firewall white list

Now is the firewall

It does not connect the two nodes, wallet again cannot be synchronized

Your client is being banned because it is supplying the wrong proof of work for a specific block, which probably means it has forked from the network again.

I don't know whether it's your mining that is causing the fork, or one of your peers. If it is a peer, as a short term solution, you can run your client with those commandline options I mentioned earlier (don't remove the options once you sync, keep them on)

cloudcoind -listen=0 -connect=85.17.81.169 -connect=107.170.49.232   (for daemon)

cloudcoin-qt.exe -listen=0 -connect=85.17.81.169 -connect=107.170.49.232   (for Windows QT client)

This should keep you tied to the two main nodes and prevent other peers influencing your chain. Obviously this is not a long term solution, since it centralises the network. I think the problem is that there is at least one fork which at least a couple of clients are on, so they end up being banned by the official nodes. They may be influencing other clients in the meantime, causing those to hop chains and/or be banned by peers on the opposing chain.

Can we please get as many people as possible trying this, to see if we can get rid of the other fork for good. It's difficult for me to see other chains because my clients ban peers on the "wrong" chain immediately.

This is the cdc pool node,Can't banned the IP,Please

Mine pool nodes, a large number of miners connected, real-time data updating is very fast, so the connection to the node will be relatively high, so please add you to the two node firewall white list, thank you!

pool node IP 98.126.98.138  98.126.98.139  98.126.98.250,add to white list please!

[almightyruler]

There is no "whitelist." When you fork, one node disagrees with another about the next block. That's why one bans the other.

I have set the ban time to 60 seconds (instead of 24 hours) but if you have forked the official nodes will continue to ban you (or you will ban them)

[okaypool]

There is no "whitelist." When you fork, one node disagrees with another about the next block. That's why one bans the other.

I have set the ban time to 60 seconds (instead of 24 hours) but if you have forked the official nodes will continue to ban you (or you will ban them)

But the actual situation is ban time for an hour, we found this situation, Temporary exchange the pool IP, renew synchronization,or,Will happen to mine disarster, AH

In addition, if the CDC wallet was always so easy to forking, that would be a very serious problem

[almightyruler]

FIXING THE FORK - IMPORTANT TEMPORARY CHANGE

I'm usually running at least two clients at any one time, for both mining and testing. Overnight, the one 'locked' to the seed nodes stayed synced; the one that was free forked. This is sort of good news as it means that if we can temporarily centralise the network we may finally be able to get rid of the fork remnants. In the worst case scenario it only takes a single forked node generating a PoS block to start influencing other peers to jump to that chain.

Today I'm going to look at redoing CDC from fresh source, possibly Novacoin, or any other well written and actively maintained code. The CDC source is now coming up to a year old, and has had only minor changes applied since then. When I revived this coin I expected things would continue as normal and I'd have a bit of time to redo and test the new code, but obviously there's been some serious forking problems, so this needs to be moved forward ASAP.

In the meantime, please tie your client to the seed nodes by doing one of the following:

1. On the commandline:

cloudcoind -listen=0 -connect=85.17.81.169 -connect=107.170.49.232   (for daemon)

cloudcoin-qt.exe -listen=0 -connect=85.17.81.169 -connect=107.170.49.232   (for Windows QT client)


=== OR ===


2. In cloudcoin.conf:

Code:

listen=0
connect=85.17.81.169
connect=107.170.49.232

*** It is important that you remove any addnode= entries from cloudcoin.conf so that your client does not try to connect to any other peers. ***

[okaypool]

FIXING THE FORK - IMPORTANT TEMPORARY CHANGE

I'm usually running at least two clients at any one time, for both mining and testing. Overnight, the one 'locked' to the seed nodes stayed synced; the one that was free forked. This is sort of good news as it means that if we can temporarily centralise the network we may finally be able to get rid of the fork remnants. In the worst case scenario it only takes a single forked node generating a PoS block to start influencing other peers to jump to that chain.

Today I'm going to look at redoing CDC from fresh source, possibly Novacoin, or any other well written and actively maintained code. The CDC source is now coming up to a year old, and has had only minor changes applied since then. When I revived this coin I expected things would continue as normal and I'd have a bit of time to redo and test the new code, but obviously there's been some serious forking problems, so this needs to be moved forward ASAP.

In the meantime, please tie your client to the seed nodes by doing one of the following:

1. On the commandline:

cloudcoind -listen=0 -connect=85.17.81.169 -connect=107.170.49.232   (for daemon)

cloudcoin-qt.exe -listen=0 -connect=85.17.81.169 -connect=107.170.49.232   (for Windows QT client)


=== OR ===


2. In cloudcoin.conf:

Code:

listen=0
connect=85.17.81.169
connect=107.170.49.232

*** It is important that you remove any addnode= entries from cloudcoin.conf so that your client does not try to connect to any other peers. ***

cloudcoind -listen=0 -connect=85.17.81.169 -connect=107.170.49.232


Your node steal block

This is not good

Even steal, do not steal so much, In order to develop our CDC, show mercy please,thank you!