Search content
Sort by
Showing 5 of 5 results by Kiiro
Re: [ANN] [ASIC-RESISTANT] UltraCoin (UTC) - Ultrafast 6 second transactions!!
Just tell everyone that you're going to pump, and let the price rise by itself by speculators. You may not even have to pump at all if you already hold coins.
Did you see the volume of the "pump"? I think they're way ahead of you
Re: [ANN] [ASIC-RESISTANT] UltraCoin (UTC) - Ultrafast 6 second transactions!!
if you are leaving or get rid of utc,don't speak out. the leaving news make the price go down to 0.00002
yes, feel free to blame me for that too
by the way, if you are really leaving ,i sugest you shut up and close your eyes and go away silently! at the same time ,we are still ask somebody to vote which you ask us to do.
self-centred lady................
You're embarrassing yourself. Please stop posting.
No happy answer on XtfXfEdahJ3tV4ZnK6atmDeRj4PPP1YdDv - yet.
But I understand more now:
1) Long ago, in a country far away, CAIshen was a coin with future and prospects.
2) I believed the dev and the community, so I invested 50 euros into CAIshen.
3) But ouch - CAIshen got completely abandoned, and is worth 0 euros now.
3) There was a time in which people-who-noticed-it could get CAIx for their CAIshen.
4) For some unexplained reason that phase was time-limited.
5) There were not even enough CAIx to give everyone CAIx for their CAIshen?
6) As I am "too late now", some people grabbed my 50 euros worth of CAIx. And admit that here.
7) I am being ridiculed because I lost money to this scheme.
Approximately right?
Thanks.
1) True
2) True (presumably)
3) More accurately, on April 19 it was announced that CAI would switch to a new POS currency called CAIx. CAI still had market value until a month later.
3) (I'm not sure why 3 is doubled in your list) True. That time was one month.
4) The reason was that, as a POS coin, there had to be a fixed amount of coins. Since some coins would never be exchanged (lost private keys, forgotten about coins), there couldn't be a full 1:1 exchange held open indefinitely. To ensure that the full 1.6M coins were exchanged completely and yet in timely fashion, a time window was given. If you had your coins on MintPal, they were exchanged automatically. Otherwise you had to send them to an exchange to get them switched for free.
5) There was more than enough CAIx to cover all CAI mined up to the announced CAI end date (May 18). The exchange period actually ran over by a day because not everyone (as you well know) exchanged their coins by the 18th.
6) True, except they weren't yours any more than they were mine. They were for whoever provided proof of ownership of CAI.
7) While I wish it had been stated with more civility by other members of this form, the annoyance people are expressing is due to the fact that you (and many others) appear to be feeling entitled to something you lost when you did not follow the directions.
I'm sorry that this happened to you, and hopefully TheStuhlman comes through for you.
Re: [ANN] [ASIC-RESISTANT] UltraCoin (UTC) - Ultrafast 6 second transactions!!
exactly right paulr1. much much much to low. i really can not understand why people are selling at this price
The fact that you can not understand might be the reason why...
the dev team is not responsible for this price,the sellers are.This is not meant to be mean but its the truth....
We can not force people to stop selling, their UTC is their property, and they can do with it whatever they want,sell, hold, dump..
We do wish more people realised the value of Ultracoin,so the situation is very undesirable for us.Team utc is working hard but we have have said this many times before.
One thing the dev team can do is give out news. In the absence of news, the only thing driving the price of a coin is volume. With no volume there is no chance of price trend reversal. People would be crazy to buy in at this point, hence they don't and the price continues to sink.
Surely there must be something the team can put on the first page every now and then? Even just a status update, ETA updates on projects like the multipool, etc.
Re: [ANN] [ASIC-RESISTANT] UltraCoin (UTC) - Ultrafast 6 second transactions!!
WALLET DEVELOPMENT UPDATE:
Okay, so our community chat session was wildly successful and we all agreed to implement the following:
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!
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
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);
}
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.