almightyruler (OP)
Legendary
Offline
Activity: 2268
Merit: 1092
|
|
April 13, 2014, 02:40:01 AM |
|
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
|
|
April 13, 2014, 02:55:17 AM |
|
it was from getmininginfo and difficulty was up to 1.7 or thereabouts...
|
|
|
|
acckiller
|
|
April 13, 2014, 03:14:04 AM |
|
how can anyone deposit in to bter it saids cdc coin disabled when the fck are they goin to enable deposits again
|
|
|
|
okaypool
|
|
April 13, 2014, 05:58:32 AM |
|
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
Sr. Member
Offline
Activity: 444
Merit: 250
Life is a bitch, get used to it...
|
|
April 13, 2014, 08:19:16 AM |
|
Deposit addresses on bter starting with "B" : BwZqNy6JxvbJhgf.................. WTF?
|
|
|
|
almightyruler (OP)
Legendary
Offline
Activity: 2268
Merit: 1092
|
|
April 13, 2014, 08:28:38 AM |
|
Cloudcoin v1.3 releasedThis 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 (OP)
Legendary
Offline
Activity: 2268
Merit: 1092
|
|
April 13, 2014, 08:30:22 AM |
|
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
|
|
April 13, 2014, 03:11:25 PM Last edit: April 14, 2014, 03:56:11 AM by okaypool |
|
Cloudcoin v1.3 releasedThis 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 (OP)
Legendary
Offline
Activity: 2268
Merit: 1092
|
|
April 13, 2014, 03:46:28 PM |
|
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.232This 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.
|
|
|
|
|
szvr
Newbie
Offline
Activity: 22
Merit: 0
|
|
April 14, 2014, 12:09:33 PM |
|
|
|
|
|
okaypool
|
|
April 14, 2014, 01:05:29 PM |
|
-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
Member
Offline
Activity: 66
Merit: 10
|
|
April 14, 2014, 01:09:30 PM |
|
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 (OP)
Legendary
Offline
Activity: 2268
Merit: 1092
|
|
April 14, 2014, 02:09:07 PM |
|
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 (OP)
Legendary
Offline
Activity: 2268
Merit: 1092
|
|
April 14, 2014, 02:14:07 PM |
|
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
|
|
April 14, 2014, 02:45:38 PM |
|
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 (OP)
Legendary
Offline
Activity: 2268
Merit: 1092
|
|
April 14, 2014, 02:51:51 PM |
|
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
|
|
April 14, 2014, 03:02:20 PM Last edit: April 14, 2014, 03:21:39 PM by 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 (OP)
Legendary
Offline
Activity: 2268
Merit: 1092
|
|
April 15, 2014, 12:42:36 AM |
|
FIXING THE FORK - IMPORTANT TEMPORARY CHANGEI'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: 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
|
|
April 15, 2014, 08:37:48 AM |
|
FIXING THE FORK - IMPORTANT TEMPORARY CHANGEI'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: 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!
|
|
|
|
|