WALLET DEVELOPMENT UPDATE:
Okay, so our community chat session was wildly successful and we all agreed to implement the following:
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.htmlTo 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.
// 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.