[ANN] [ASIC-RESISTANT] UltraCoin (UTC) - Ultrafast 6 second transactions!!

[LHM]

WALLET DEVELOPMENT UPDATE:

Okay, so our community chat session was wildly successful and we all agreed to implement the following:

Code:

NFACTOR - 1 less from what it is now, effective for 12 months
POS - 7 day POS system at 5.2% per year, which equates to 0.1% per 7 days.  Max time = 30 days
No change to # of coins or ratio for now

The POS modifications are implemented and being tested. More news to follow on this. Expect an update shortly!

NFACTOR is actually far more complex than originally thought. Turns out dialing back could have severe, potentially crippling, repercussions. We are investigating how to work through this, if at all possible.

That being said: NFACTOR will change as scheduled this Saturday, May 24th, 2014 @ 03:15:12pm UTC. We cannot risk crippling the entire blockchain in an attempt to force this revision. When the NFACTOR changes, please use the config generator to update your miners!

http://ultracoin.net/configgen_raw.html

To summarize, the wallet update will, for now, include only the POS modifications, NFACTOR changes are being discussed, and NFACTOR will shift this Saturday. We will keep you all posted otherwise.

Thank you for your continued support!

I'm not sure why the N-factor change has to be so complicated.  I'm getting ready to go home for a long, long weekend but, if I remember correctly, there is just a convoluted function that has a bunch of arbitrary calculations that result in a block heights to change the N-factor at.  The point is, I thought it just returned nFactor and all the other things that used that value derived it from that function.

Why couldn't you just comment that all out and hardcode in the return value to be the N-factor you want it to be, aka 12?   

Obviously, this would be a mandatory wallet update.  No ones wallet would work on the old N-factor so you'd have to set it at a date in the near future. 

well there is the factor of changing the wallet software, a mandatory update, and a forced date for transition. However there is also mining software, scrypt-jane/scrypt-chacha mining software also uses the same formula to determine the n-factor when mining. Custom revisions of each of the mining programs used will need to be ready for this change as well. Coordinating all of this is a nightmare in the crypto world, some people don't listen some don't understand and things just get complicated.

That is what I said, I'll just copy it below and save myself the trouble of explaining it. 

Code:

// ultracoin: increasing Nfactor gradually
const unsigned char minNfactor = 4;
const unsigned char maxNfactor = 30;

unsigned char GetNfactor(int64 nTimestamp) {
    int l = 0;
    if (nTimestamp <= nChainStartTime || fTestNet)
        return 4;
    int64 s = nTimestamp - nChainStartTime;
    while ((s >> 1) > 3) {
      l += 1;
      s >>= 1;
    }
    s &= 3;
    int n = (l * 170 + s * 25 - 2320) / 100;
    if (n < 0) n = 0;
    if (n > 255)
        printf( "GetNfactor(%lld) - something wrong(n == %d)\n", nTimestamp, n );
    unsigned char N = (unsigned char) n;
    //printf("GetNfactor: %d -> %d %d : %d / %d\n", nTimestamp - nChainStartTime, l, s, n, min(max(N, minNfactor), maxNfactor));

    return min(max(N, minNfactor), maxNfactor);
}

The wallet passes the Timestamp to the function, subtracts the start time to get the total length of time the coin has been producing blocks, does some funky arbitrary math, then returns the N factor, assuming it's between 4 and 30.  If the value is outside that range ( 4> x >30), then it returns 4 or 30.  That's it.  Every call to get the N-factor in every other part of the wallet uses a call to GetNfactor.  For a short term fix, you just comment out the entire block of code, and write "return 12".  Then all the function calls remain the same and you are just forcing a set N factor until you decide on a proper schedule. 

I wouldn't imagine the mining software would care that it is hardcoded.  I'd need thirtybird to go over that though, as I really don't know a ton about that side of it.  I looked at his YACminer code and there are calls to getNFactor, but I got tired of tracking down where they were going to.  He's much better at this stuff than me anyway so he can probably tell me whether there is something wrong with what I said above as well. 

The mining software uses basically the same function, at a minimum you would have to set nfmax 12  so the nfactor change is overridden. That still leaves coordination, and the fact that there are people that don't listen, don't understand, and a social mess. Changing the code itself is not a huge hurdle, setting the transition time, the mandatory update, and mining changes so people don't go into riot mode is complicated and not to be taken lightly. If the transition window, the timing and communication are not carefully considered and clearly stated in the right way a change of this type could kill a coin, or at least severely damage it. (yes much more than you may think the current problems are)

Some simple changes are very complicated to actually implement. There is also the fact that some coins will have been mined at  a higher nfactor, how that affects the blockchain when lowering it I do not know, but may require much more work on the wallet software to make sure the transition does not invalidate any coins during the change.

[Kiiro]

WALLET DEVELOPMENT UPDATE:

Okay, so our community chat session was wildly successful and we all agreed to implement the following:

Code:

NFACTOR - 1 less from what it is now, effective for 12 months
POS - 7 day POS system at 5.2% per year, which equates to 0.1% per 7 days.  Max time = 30 days
No change to # of coins or ratio for now

The POS modifications are implemented and being tested. More news to follow on this. Expect an update shortly!

NFACTOR is actually far more complex than originally thought. Turns out dialing back could have severe, potentially crippling, repercussions. We are investigating how to work through this, if at all possible.

That being said: NFACTOR will change as scheduled this Saturday, May 24th, 2014 @ 03:15:12pm UTC. We cannot risk crippling the entire blockchain in an attempt to force this revision. When the NFACTOR changes, please use the config generator to update your miners!

http://ultracoin.net/configgen_raw.html

To summarize, the wallet update will, for now, include only the POS modifications, NFACTOR changes are being discussed, and NFACTOR will shift this Saturday. We will keep you all posted otherwise.

Thank you for your continued support!

I'm not sure why the N-factor change has to be so complicated.  I'm getting ready to go home for a long, long weekend but, if I remember correctly, there is just a convoluted function that has a bunch of arbitrary calculations that result in a block heights to change the N-factor at.  The point is, I thought it just returned nFactor and all the other things that used that value derived it from that function.

Why couldn't you just comment that all out and hardcode in the return value to be the N-factor you want it to be, aka 12?  

Obviously, this would be a mandatory wallet update.  No ones wallet would work on the old N-factor so you'd have to set it at a date in the near future.  

well there is the factor of changing the wallet software, a mandatory update, and a forced date for transition. However there is also mining software, scrypt-jane/scrypt-chacha mining software also uses the same formula to determine the n-factor when mining. Custom revisions of each of the mining programs used will need to be ready for this change as well. Coordinating all of this is a nightmare in the crypto world, some people don't listen some don't understand and things just get complicated.

That is what I said, I'll just copy it below and save myself the trouble of explaining it.  

Code:

// ultracoin: increasing Nfactor gradually
const unsigned char minNfactor = 4;
const unsigned char maxNfactor = 30;

unsigned char GetNfactor(int64 nTimestamp) {
    int l = 0;
    if (nTimestamp <= nChainStartTime || fTestNet)
        return 4;
    int64 s = nTimestamp - nChainStartTime;
    while ((s >> 1) > 3) {
      l += 1;
      s >>= 1;
    }
    s &= 3;
    int n = (l * 170 + s * 25 - 2320) / 100;
    if (n < 0) n = 0;
    if (n > 255)
        printf( "GetNfactor(%lld) - something wrong(n == %d)\n", nTimestamp, n );
    unsigned char N = (unsigned char) n;
    //printf("GetNfactor: %d -> %d %d : %d / %d\n", nTimestamp - nChainStartTime, l, s, n, min(max(N, minNfactor), maxNfactor));

    return min(max(N, minNfactor), maxNfactor);
}

The wallet passes the Timestamp to the function, subtracts the start time to get the total length of time the coin has been producing blocks, does some funky arbitrary math, then returns the N factor, assuming it's between 4 and 30.  If the value is outside that range ( 4> x >30), then it returns 4 or 30.  That's it.  Every call to get the N-factor in every other part of the wallet uses a call to GetNfactor.  For a short term fix, you just comment out the entire block of code, and write "return 12".  Then all the function calls remain the same and you are just forcing a set N factor until you decide on a proper schedule.  

I wouldn't imagine the mining software would care that it is hardcoded.  I'd need thirtybird to go over that though, as I really don't know a ton about that side of it.  I looked at his YACminer code and there are calls to getNFactor, but I got tired of tracking down where they were going to.  He's much better at this stuff than me anyway so he can probably tell me whether there is something wrong with what I said above as well.  

It might be more complex than simply replacing that code, as the n-factor is a function of time and that function needs to remain the same when loading/verifying the blockchain.

One thing I've learned about software development: unless you know the system, any estimate of difficulty is meaningless.

[rubenaco]

ups.. price is ridiculous... WHEN ULTRACOIN SHINE? scrypt asics are here...but ultracoin or vertcoin only downs and down. other altcoins can rise but ultracoin...

[longyenthanh]

when does nfactor change. My current time is 1:33AM

[primouno]

when does nfactor change. My current time is 1:33AM

At 3:15 pm UTC time, that is about 5 hours from now.

[PETAZETAS]

This is by far the wallet that takes most time opening and syncing, and I have over 50 crypto currencies....

You must address this problem, specially if you advertise as a 'ultrafast' coin

[bumface]

This is by far the wallet that takes most time opening and syncing, and I have over 50 crypto currencies....

You must address this problem, specially if you advertise as a 'ultrafast' coin

wallet opens in 8 seconds

[KingCole]

This is by far the wallet that takes most time opening and syncing, and I have over 50 crypto currencies....

You must address this problem, specially if you advertise as a 'ultrafast' coin

Have you updated your wallet recently? The original version and first update had problems which caused a long load time. The newest wallet, version 3, has addressed this issue.

Latest wallet available at http://ultracoin.net/wallet.html

KC

[KingCole]

Ultracoin is still number 1 on CoinPayments, but has only had one additional vote in the last 48 hours. The target for the prize fund was to reach 100 by the end of today. If you haven't voted then please do so, if you know someone who is into Crytpo then please encourage them to vote as well.

KC

[flobdeth]

If you look at other altcoins twitter feeds they have 300-800 followers and websites are mediocre. I have 1600 follows dcgirl have over 1000 and so does Michael on the official_utc. So am at a loss to see what these coins are doing that we are not. Take Unobtanium for example, they have 186 followers on twitter and a website with about 3 pages. They are ranked 36 on coinmarketcap and have a value of nearly $3 per coin!? It doesn't make sense. People need to be told about how good UTC is and how fast it is!

UTC doesn't have heavy hitters like Bryce Weiner and others promoting them, unlike UNO and some other coins.  Do not fear Mr Shadow, give it a month or two and crypto as a whole should start to see some serious ground being broken.  I mean Edmond Moy coming out saying "Bitcoin is the way" is a major thing.  Former director of the US mint saying banks are crooked....... don't be so down.  Yes the team seem kinda quiet on the promotion, but look at all the work they have put in recently. 

Arbitrage site, wallet updates, they haven't been playing tiddlywinks. UTC has been extremely lucky to have had DCgirl onboard, man/woman/alien lifeform, I do not care, great person to have on your coin team and the effort by all involved is much appreciated

I still own UTC, I am still mining (at a loss).  I wanted to get involved with the community more, but alas time has forsaken me.

My point is, don't give up on it yet, take a step back, look at all the work the team has done this past two months and remember that almost all coins are linked to BTC, it will bounce back bringing the altcoins with it.  When that happens......boom, promotion time.

Take a step back those holders that are shitting bricks at the current price, me, I took a week away from PC, price is shit when I came back, meh, I'm slowly buying keep dumping slackers

[utcminer]

WALLET DEVELOPMENT UPDATE:

Okay, so our community chat session was wildly successful and we all agreed to implement the following:

Code:

NFACTOR - 1 less from what it is now, effective for 12 months
POS - 7 day POS system at 5.2% per year, which equates to 0.1% per 7 days.  Max time = 30 days
No change to # of coins or ratio for now

The POS modifications are implemented and being tested. More news to follow on this. Expect an update shortly!

NFACTOR is actually far more complex than originally thought. Turns out dialing back could have severe, potentially crippling, repercussions. We are investigating how to work through this, if at all possible.

That being said: NFACTOR will change as scheduled this Saturday, May 24th, 2014 @ 03:15:12pm UTC. We cannot risk crippling the entire blockchain in an attempt to force this revision. When the NFACTOR changes, please use the config generator to update your miners!

http://ultracoin.net/configgen_raw.html

To summarize, the wallet update will, for now, include only the POS modifications, NFACTOR changes are being discussed, and NFACTOR will shift this Saturday. We will keep you all posted otherwise.

Thank you for your continued support!

I'm not sure why the N-factor change has to be so complicated.  I'm getting ready to go home for a long, long weekend but, if I remember correctly, there is just a convoluted function that has a bunch of arbitrary calculations that result in a block heights to change the N-factor at.  The point is, I thought it just returned nFactor and all the other things that used that value derived it from that function.

Why couldn't you just comment that all out and hardcode in the return value to be the N-factor you want it to be, aka 12?  

Obviously, this would be a mandatory wallet update.  No ones wallet would work on the old N-factor so you'd have to set it at a date in the near future.  

well there is the factor of changing the wallet software, a mandatory update, and a forced date for transition. However there is also mining software, scrypt-jane/scrypt-chacha mining software also uses the same formula to determine the n-factor when mining. Custom revisions of each of the mining programs used will need to be ready for this change as well. Coordinating all of this is a nightmare in the crypto world, some people don't listen some don't understand and things just get complicated.

That is what I said, I'll just copy it below and save myself the trouble of explaining it.  

Code:

// ultracoin: increasing Nfactor gradually
const unsigned char minNfactor = 4;
const unsigned char maxNfactor = 30;

unsigned char GetNfactor(int64 nTimestamp) {
    int l = 0;
    if (nTimestamp <= nChainStartTime || fTestNet)
        return 4;
    int64 s = nTimestamp - nChainStartTime;
    while ((s >> 1) > 3) {
      l += 1;
      s >>= 1;
    }
    s &= 3;
    int n = (l * 170 + s * 25 - 2320) / 100;
    if (n < 0) n = 0;
    if (n > 255)
        printf( "GetNfactor(%lld) - something wrong(n == %d)\n", nTimestamp, n );
    unsigned char N = (unsigned char) n;
    //printf("GetNfactor: %d -> %d %d : %d / %d\n", nTimestamp - nChainStartTime, l, s, n, min(max(N, minNfactor), maxNfactor));

    return min(max(N, minNfactor), maxNfactor);
}

The wallet passes the Timestamp to the function, subtracts the start time to get the total length of time the coin has been producing blocks, does some funky arbitrary math, then returns the N factor, assuming it's between 4 and 30.  If the value is outside that range ( 4> x >30), then it returns 4 or 30.  That's it.  Every call to get the N-factor in every other part of the wallet uses a call to GetNfactor.  For a short term fix, you just comment out the entire block of code, and write "return 12".  Then all the function calls remain the same and you are just forcing a set N factor until you decide on a proper schedule.  

I wouldn't imagine the mining software would care that it is hardcoded.  I'd need thirtybird to go over that though, as I really don't know a ton about that side of it.  I looked at his YACminer code and there are calls to getNFactor, but I got tired of tracking down where they were going to.  He's much better at this stuff than me anyway so he can probably tell me whether there is something wrong with what I said above as well.  

Ultracoin is still number 1 on CoinPayments, but has only had one additional vote in the last 48 hours. The target for the prize fund was to reach 100 by the end of today. If you haven't voted then please do so, if you know someone who is into Crytpo then please encourage them to vote as well.

[longyenthanh]

I will stay with UTC till my last breath 

[bumface]

I will stay with UTC till my last breath  

[primouno]

I will stay with UTC till my last breath 

We have no other choice

[funsponge]

we need to get new people into buying UTC rather than BC MAX or DRK. To do this we need marketing and discussing the benefits in troll boxes. Once the  price starts to go up people start to take interest as we have seen with other altcoins.
Also I wish Crypto-Trade will release version 2! With it will bring new traffic and new investors. Are they happy to watch their customers leave and their site to die?

I do feel that when bitcoin/altcoins become easily to buy (instant purchase like through paypal) then main investors will look at buying and holding and UTC will benefit from these buyers.

Currently all altcoin buyers are treating them as penny stocks and have no intention or interest in holding or spending their altcoins. They just want to day-trade. UTC needs to "stay-alive" whist this period is going on so more focus needs to be on marketing and spreading the word in my opinion. Facebook giveaways, the ultracoin lottery, add banner on coinmarketcap, UTC community on troll boxes.

[barbados-fs]

N-factor changed. Now 280x speed 29kH / s and at 270x - 19kH / s.

How much do you get?

[longyenthanh]

anyone help me config new factor? 

[KingCole]

So N-Factor 13 has now kicked in, time to update the miner configs. Based on my previous config and use of the config generator on http://ultracoin.net/configgen_raw.html I have the following config working before tweaking:


H.I.S Radeon 7970 on Windows 8.1 64 bit with 16GB RAM

yacminer.exe --scrypt-chacha -o stratum+tcp://stratum.ultracoinpool.info:3333 -u KingCole -p x -R 7552 --buffer-size 2590 -g 1 -w 128 --lookup-gap 5 --temp-cutoff 85 --nfmin 4 --nfmax 30 --starttime 1388361600

Getting about 19.5kHz per card

KC

[hanvude2424]

r9 270 config? , please !! 

[primouno]

What hashrate do you get comparing to before factor change? I have 1/3 of what I had before. Is it correct? I had 30 Kh/s now I get 9 Kh/s.

My R9 270 config (still tweaking):

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
del scrypt*.bin
timeout /t 60
cgminer -o stratum+tcp://stratum.ultracoinpool.info:3333 -u xxxxx -p xxxx --scrypt-jane --sj-nfmin 4 --sj-nfmax 30 --sj-time 1388361600 -w 128 -I 12 --thread-concurrency 70400 -g 1 --lookup-gap 6 --gpu-engine 1150 --gpu-memclock 1450 --gpu-powertune 20 --no-submit-stale --expiry 10 --scan-time 1 --queue 0 --temp-cutoff 90 --temp-overheat 85