HR as far as I understand it 20% of the blocks are ASIC, 20% are Scrypt, 60% are GPU (I do not know if these are equally distributed).
That's not the issue. The block find distribution is 20/20/20/20/20. About that there is no doubt.
The question is how does MultiShield adjust each algo's diff and as a function of exactly what? We know that before the most recent hardfork, global network hashrate (that is the combined total of the 5 algos) was key, and that all the algos diffs adjusted in response to changes in aggregate hashrate. The question is how much did that change? To what precise degree are the algos currently independent, and to what degree are they still inter-dependent?
I suggest reading the source code. ...with basic coding skills and the source code mentioned (that is freely available to the public), anyone can confirm it.
Forgive me mental, your post was just brought to my attention.
Read the code to find your answer? Are you off your rocker?
Could anyone imagine someone from Ubuntu saying something like that? From Redhat? SUSE? Any of the principal distros?
Could anyone imagine that such important, critical and key information isn't even documented in the first place?And then, when someone asks, the answers are
first to ignore,
second to be flippant,
third to seriously suggest it's not important,
fourth to disqualify and personally attack the person asking . . .
Does that sound normal to everyone?
We, the end users should read the code to answers central questions about how DigiByte works? Are you serious? (And don't play coy by saying I didn't quote your entire post - the rest was superfluous, and certainly didn't answer the questions.)
Again, is there anyone on the DigiByte team professional enough to start that basic documentation that everyone can understand by putting the following code in layman's terms instead of suggesting we all need to learn to code? (I make that a general question to all, not just to you, since Jared did the same thing, albeit more indirectly and with much more obfuscation.
//Global retarget
CBigNum bnNew;
bnNew.SetCompact(pindexPrevAlgo->nBits);
bnNew *= nActualTimespan;
bnNew /= nAveragingTargetTimespanV4;
//Per-algo retarget
int nAdjustments = pindexPrevAlgo->nHeight + NUM_ALGOS - 1 - pindexLast->nHeight;
if (nAdjustments > 0)
{
for (int i = 0; i < nAdjustments; i++)
{
bnNew *= 100;
bnNew /= (100 + nLocalTargetAdjustment);
}
}
else if (nAdjustments < 0)//make it easier
{
for (int i = 0; i < -nAdjustments; i++)
{
bnNew *= (100 + nLocalTargetAdjustment);
bnNew /= 100;
}
}
How many people are truly interested in something like this? My guess is there's not that many and our time is best spent elsewhere but if that proves to be wrong I'm sure we could sort something out.
I would just like to add that HR's tone and way of communicating isn't very inviting. Your not really motivating anyone by demanding answers (as none of us work for you etc.) with the way your asking your questions. Maybe if you had been nicer this would've all been answered and resolved ages ago.
P.S. I think in the 21st century everyone should no at least a tiny lil bit of code
Quite honestly, the lack of explanation about how the difficulty retargeting works, in a clear and understandable way that everyone can understand, doesn't give a very good impression, and I don't think anyone would say that repeatedly asking for a yet to be given answer is a reason for not giving it, much less for not being "nicer".
Of course, if someone had said that there still is no answer adequately formulated and that it's being worked on, or something of the sort, then impatient insistence might be a basis for criticism . . .
Thankfully the code is very nicely commented, but I still don't agree that we should insist on ordinary users having to read the code.
In any event, since the most effective way to promote activity on this thread when everything is quiet is to bring the subject up again, not all is lost.
BTW: what's the deal with Esotericizm?