Topic: Star Trek Crypto Coin thread - Big changes are coming!! - page 36. (Read 40220 times)

I have the capacity to start another pool. 

Cubits?

Dollarpound?

Firefly?

Other?

Wow, to fix the problem with the tx messaging (Send a message with your transaction feature) that was causing the Boost thread handling errors, I had to fix a different issue with the back-end software that fixed the first issue. 

Anyway, I am testing the UFC stratum back end on port 4445, if anybody wants to try it.

This was the chain of events:

1. I started getting Boost threading exceptions on submit block.They would start up almost at random and nothing short of starting with a clean wallet/block chain would clear it up. These errors would have never led me to believe the issue was with the extra data in the TX (Message feature).

2.One of the active developers of stratum back-ends ,(amed_bodi) had recently published a commit solving this issue with the cloudcoin and other TX message coins.

3. That made my day when I saw it, not only was I not dealing with a core logic issue, but there was a fix.

4.Unfortunately, I started getting other errors with the back-end.I would have blocks get accepted by the coin daemon and put on the block chain, but the back-end would reject them and give out the infamous "500" errors.

5. At this point to keep the pool going I switched it to PushPool. This worked because with the LP protocol all the transaction handling and block building is done by the daemon, unlike stratum which gets instructions on how to construct a block (block template) and assembles then submits the completed block. PushPool only submits the header hash of a block while the daemon constructs it.

6. I found the issue and a quick fix for the problem unrelated to the first problem I was having with the back-end. It involves the way the Daemon accepts a get block command. One of the checks the back end of a pool does, is to check to see if a submitted block actuality made it into the block chain. Some scrypt daemons only accept the hexed scrypt hash with the get block command, UFC is one of them. So when the back end went to preform the test, it was passing the hexed block hash causing a 500 error. This lead to a condition where the block was actuality accepted to the block chain, but the back end would report it to the pool database as not accepted.

SO with the quick fix of passing the scrypt_hex_hash to the functions involved, i was able to get stratum working again for UFC. I want to test it for a few days to be sure, but you are welcome to use it on port 4445.

Well well well,

It looks like the UFC issues are because of the cloud coin base:

https://bitcointalksearch.org/topic/m.4110512

I am going to implement this fix and see if it works...

Until further notice, the UFC pool (http://ufccoin.com:4444) will be operating in Pushpool(LP) mode.

You will need to change the mining address to http://ufccoin.com:4444 . Some versions of mining software may not detect an LP port using (stratum+tcp://).

There appears to be a threading issue with block template block submits. There could be a number of factors with this, but it does not effect anything else.

Solo mining will still work fine. Long poll (LP) mining is perfectly acceptable at UFC Network hash rate, so the pool is good to go.

I am going to have to take a deeper look at the UFC code which I had planned on to fix the POS issues anyway. This issue (block template) will most likely be fixed in the next major release of UFC along with all the other fixes. I will produce a time table for release at a later date.

hi dream, unfocus,

how long does it take to get back KED from old wallet, just sent email yesterday.

thanks

thanks.

excellent work.

The GPL mine has been moved to a new server. DNS should have propagated by now, try a forced full refresh with F5.. I have discovered that many of the issues with the pools were related to the Linux version I was using on the servers.Once the original server is re-imaged, I will move the GPL pool back to the original server. The move back will be quicker as everything will be the same version, so a straight copy can be used.

I did not know about the superblocks. It does not appear to be mentioned anywhere, and I have not taken a deep look into the UFC code yet. A complete comb through and correcting of issues with UFC is the next major item on the list.

I do not see much reason to set a cut-off at this time. The database is static so nobody can "trick" the system by mining the old chain. If one is foolish enough to try and brute force a private key, the chances of a successful collision are just about zero.

GPL pool gplcoin.com is "Unable to load site configuration". Also, are there GPL CPU miner binaries for Windows? I only see the GPU miner.

The 4400 coinbase is intended - UFC has superblocks. See lines 969 to 972 in FederationCredits/src/main.cpp. I myself have received a block of 400 UFC before.

Finally what will happen to the portion of the KED premine which is not claimed? Perhaps you could set a deadline for collection, after which the coins will be destroyed?

Since late last night it appears the coin daemon for the UFC pool has been having some issues. Basically after the pool finds a few blocks and the daemon accepts them, further blocks submitted to the daemon cause a non-crashing exception and the block is not broadcast to the network.
The recent update only changed network ports, identifier and version, nothing in the core logic. I believe the issue has to do with the contaminated block chain and error handling.

For example block 164240 is malformed. A strange coinbase of 4400 UFC transaction where a coinbase of 50 should be.

http://ufc.cryptocoinexplorer.com/block/164240

To avoid issues with this block , I am going to add a check point past it on the checkpoint server and source. Not a mandatory update as the checkpoint server takes care of the issue. Windows will get the new checkpoints in the next release.

We also might be experiencing issues with the sudden inrush of POS block generation. It is going to take a bit of time for the block-chain to "heal".

I have run an extra test on the pool back-end and client by directly downloading the backend from the UFC pool locally. I have only changed the RPC login and databse login, and am running the back-end "as-is" on my local system/daemon. So far, no issues or exceptions.
This leads me to the conclusion that it might be an error handling difference between the server (Ubuntu 13.4) and my local systems (Ubuntu 12.4). I to plan to "downgrade" all my VPS to the 12.4 LTS version, but that takes a bit of time to back-up everything and wait for the hosting company to load 12.4 on the VPS.

The new KED pool server is 12.4 LTS, so I am going to move the UFC pool to that server and see if that alleviates the issue. This will be a straight move, so the database will remain intact and hopefully will just be a move and turn on type of deal.

Please give me a couple of days. I might do it tonight, it might be a couple of days. Withdrawal system on the pool will remain active until I sit down to do the move.

GPl is stable no plans for new client short term. There may be a cosmetic update later. there is some talk of optional displaying balance in slips, strips or bars as part of the cosmetic change.

Nice work guys! Excited to have a better performing UFC wallet. Any ETA on an updated GPL client?

I got my Keds from the old wallet.
Great work, Dreamwatcher
Thanks a lot.

Is there a date limit for the KED redemption?
Because I'm on vacations, and don't have my wallet here.

Thanks.

omg, a year! another word - "never" 

btw, what is KED maturity time? and % rate?

Just got my KED from old chain.
Thanx!

There is a cpu miner for scrypt-jane.

And the both KED and UFC are scrypt coins.

 I use cudaminer becuase it's a lot faster with Nvidia cards. Oh well, guess i'll just mine the scrypt coins

ATTENTION: UFC HARD FORK!!! UFC - version 1.5.5


If you have been mining UFC, you'd probably realize that there has been issues with transactions, performance, wallet forking and the health of the network in general. Dreamwatcher has discovered the issue, and he has created a fix.  A few of us have tested the wallet, and it seems to work well. He is in Central time, it's late for him, and he didn't have much rest since the KED relaunch, so I am posting this on his behalf.

PLEASE UPDATE YOUR WALLETS, AND PLEASE FOLLOW THE CORRECT STEPS

For windows users, the new wallet is downloadable from:
https://drive.google.com/folderview?id=0B0wumNRRq9LNbWo1cnF1YnhsR1U&usp=sharing

YOU HAVE TO CLEAN UP YOUR OLD DATA STORE: you need to re-download the whole block chain.
1. Click start -> type: %appdata% on the find/search bar, you'd get an explorer window.
2. Rename the federationcredit directory to to federationcredit_old
3. Copy the original wallet.dat and the federationcredit.conf (if you have it) to the new dir.
4. It's probably best if you add the official checkpoint server as a node in the conf file:
5. Start the new client, it's going to start syncing the blocks, and your balance should be intact.
6. If you get stuck, try again with completely empty federationcredit directory. After you are synced, replace the wallet file.


FOR LINUX USERS, the source code is available here: https://github.com/scificryptocoin/FederationCredits
Similarly, you need to start with an empty .federationcredit directory at your home dir.


The new ports are:
RPC Port: 7014
P2P port: 7013

The pool, http://www.ufccoin.com is up and running. You can resume mining over there. Your balance over there have been cleared out (0), as Dream had to start with a new wallet. But he will credit you back soon. He has a lot of book-keeping work to do in the next few days, including the KED exchange. Please be patient, and please acknowledge his hard work for the community.

You can check this guide also
http://www.scificryptocoin.org/index.php/general-information/how-to-mine/13-how-to-mine-gpl-at-pool

The hash rate is awfully high for 660 ti.  What miner are you using?
This is a scrypt-jane coin, not regular scrypt.