Topic: ★★DigiByte|极特币★★[DGB]✔ Core v6.16.5.1 - DigiShield, DigiSpeed, Segwit - page 547. (Read 3059029 times)
February 22, 2016, 04:14:56 AM
Thanks for clearing this issue up Jared, much appreciated. I hope we can lay this issue to rest now and get on with more interesting developments/suggestions.
February 22, 2016, 04:10:02 AM
Okay, pretty much what I thought: those magic knights don't exist, and the level of understanding about the second most important aspect of DigiByte is, in general, close to zero.
Considering just how important it is to have a good understanding of this, would it be too much to ask for an explanation in layman's terms?
As a guide, not that you need it as you clearly answered both with your posting of the respective codes, but in order to help with the framing of that explanation for the average person, I'll remind of the framing of the last questions:
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?
Looks to me like the overall relationship is still very similar, in that all 5 algos have their difficulties to mine calculated from the same base input, but, not being an expert, I don't want to misrepresent the facts and prefer to hear your, expert, explanation for the masses.
More than anything because I could be wrong. As I said, I'm not an expert, and in this matter I consider myself to be a member of the masses.
Very much appreciated!
https://github.com/digibyte/digibyte/pull/36
Quote
First off, this will fix the safe mode warnings once and for all. But it does so much more than that. Currently, an attacker can 51% attack the network with roughly 60% of SHA256D and nothing else. After this change, an attacker with 90% of the SHA256D hashrate and 33% of each of the other 4 algorithms would have insufficient hashpower to mount a 51% attack.
The new formula was chosen as a function of the difficulties and based on these criteria:
1. It should be a symmetric funtion
2. It should be order 1 homogenous
3. It should be homogenous with respect to each variable
Or in plain English:
1. There should be nothing algorithm-specific (such as per-algorithm weights) nor should it depend on which algorithm actually solved the block.
2. If all difficulties double, the block work should double
3. If one difficulty doubles, the block work should change by some constant factor
There is only one function (save multiplication by a constant factor) satisfying all 3 conditions: the geometric mean. As an added bonus, because of how the difficulty algorithm works the geometric mean can change by at most 3% from block to block (which addresses the safe-mode warning issue).
In order to 51% attack the network, the product of the attacker's hashrates must exceed the product of the network's hashrates. In particular, the attacker must have some hashrate in all 5 algorithms.
The new formula was chosen as a function of the difficulties and based on these criteria:
1. It should be a symmetric funtion
2. It should be order 1 homogenous
3. It should be homogenous with respect to each variable
Or in plain English:
1. There should be nothing algorithm-specific (such as per-algorithm weights) nor should it depend on which algorithm actually solved the block.
2. If all difficulties double, the block work should double
3. If one difficulty doubles, the block work should change by some constant factor
There is only one function (save multiplication by a constant factor) satisfying all 3 conditions: the geometric mean. As an added bonus, because of how the difficulty algorithm works the geometric mean can change by at most 3% from block to block (which addresses the safe-mode warning issue).
In order to 51% attack the network, the product of the attacker's hashrates must exceed the product of the network's hashrates. In particular, the attacker must have some hashrate in all 5 algorithms.
So to summarise, there is no longer an individual algorithm weighting (workfactor) but a geometric mean (nthRoot) of all algos. This allows for five birds to be killed with one stone; preventing time warp attacks, eliminating safe mode error, improving difficulty adjustments, making sure each algo is only getting 20% of all the blocks and dramatically increasing the difficulty of a 51% attack. If you look back at the previous several thousand blocks and calculate the average % of each algo you will get the 20% average. Things are working as expected in that regard.
Now as to electrical efficiency of each mining setup. ASIC's are by their very nature designed to be highly efficient: https://en.wikipedia.org/wiki/Application-specific_integrated_circuit
The original idea was to allow for people with both used, obsolete ASIC's and GPU's as well as some CPU's to be able to mine. As time has gone on the mining scene has undoubtedly changed and we now have two algos (Sha256 and Scrypt) dominated by ASIC's. As time goes on these two algos miners will get more electrically efficient but still only account 40% of new DGB coming into circulation. The other 60% is up for grabs from GPU's.
As ASIC's get cheaper and more efficient it will be easier to distribute ASIC miners to people such as gamers. Remember the only thing a Sha256 or Scrypt ASIC can be used for is to mine a digital currency.
Does this answer everyones questions? This is a very complex topic so we understand the confusion. We are always open to new ideas and suggestions as technology is rapidly changing.
February 22, 2016, 02:58:37 AM
Here is the first weighting code (pre DigiSpeed):
https://github.com/digibyte/digibyte/blob/master/src/main.h#L866
New Adjusted Weighting Code (Post DigiSpeed):
https://github.com/digibyte/digibyte/blob/master/src/main.h#L866
Code:
int GetAlgoWorkFactor() const
{
if (!TestNet() && (nHeight < multiAlgoDiffChangeTarget))
{
return 1;
}
if (TestNet() && (nHeight < 100))
{
return 1;
}
switch (GetAlgo())
{
case ALGO_SHA256D:
return 1;
// work factor = absolute work ratio * optimisation factor
case ALGO_SCRYPT:
return 1024 * 4;
case ALGO_GROESTL:
return 64 * 8;
case ALGO_SKEIN:
return 4 * 6;
case ALGO_QUBIT:
return 128 * 8;
default:
return 1;
}
}
{
if (!TestNet() && (nHeight < multiAlgoDiffChangeTarget))
{
return 1;
}
if (TestNet() && (nHeight < 100))
{
return 1;
}
switch (GetAlgo())
{
case ALGO_SHA256D:
return 1;
// work factor = absolute work ratio * optimisation factor
case ALGO_SCRYPT:
return 1024 * 4;
case ALGO_GROESTL:
return 64 * 8;
case ALGO_SKEIN:
return 4 * 6;
case ALGO_QUBIT:
return 128 * 8;
default:
return 1;
}
}
New Adjusted Weighting Code (Post DigiSpeed):
Code:
CBigNum GetBlockWorkAdjusted() const
{
if (nHeight < workComputationChangeTarget)
{
CBigNum bnRes;
bnRes = GetBlockWork() * GetAlgoWorkFactor();
return bnRes;
}
else
{
CBigNum bnRes = 1;
CBlockHeader header = GetBlockHeader();
// multiply the difficulties of all algorithms
for (int i = 0; i < NUM_ALGOS; i++)
{
unsigned int nBits = GetNextWorkRequired(pprev, &header, i,false);
CBigNum bnTarget;
bnTarget.SetCompact(nBits);
if (bnTarget <= 0)
return 0;
bnRes *= (CBigNum(1)<<256) / (bnTarget+1);
}
// Compute the geometric mean
bnRes = bnRes.nthRoot(NUM_ALGOS);
// Scale to roughly match the old work calculation
bnRes <<= 7;
return bnRes;
}
}
{
if (nHeight < workComputationChangeTarget)
{
CBigNum bnRes;
bnRes = GetBlockWork() * GetAlgoWorkFactor();
return bnRes;
}
else
{
CBigNum bnRes = 1;
CBlockHeader header = GetBlockHeader();
// multiply the difficulties of all algorithms
for (int i = 0; i < NUM_ALGOS; i++)
{
unsigned int nBits = GetNextWorkRequired(pprev, &header, i,false);
CBigNum bnTarget;
bnTarget.SetCompact(nBits);
if (bnTarget <= 0)
return 0;
bnRes *= (CBigNum(1)<<256) / (bnTarget+1);
}
// Compute the geometric mean
bnRes = bnRes.nthRoot(NUM_ALGOS);
// Scale to roughly match the old work calculation
bnRes <<= 7;
return bnRes;
}
}
Okay, pretty much what I thought: those magic knights don't exist, and the level of understanding about the second most important aspect of DigiByte is, in general, close to zero.
Considering just how important it is to have a good understanding of this, would it be too much to ask for an explanation in layman's terms?
As a guide, not that you need it as you clearly answered both with your posting of the respective codes, but in order to help with the framing of that explanation for the average person, I'll remind of the framing of the last questions:
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?
Looks to me like the overall relationship is still very similar, in that all 5 algos have their difficulties to mine calculated from the same base input, but, not being an expert, I don't want to misrepresent the facts and prefer to hear your, expert, explanation for the masses.
More than anything because I could be wrong. As I said, I'm not an expert, and in this matter I consider myself to be a member of the masses.
Very much appreciated!
February 21, 2016, 11:03:42 PM
iOS Wallet update:
Our test wallet has been approved by the Apple iTunes store. If you have DigiBytes stuck in the old iOS wallet and would like to help us test the new wallet please email [email protected] your Apple ID email and we will add you to the Test Flight list.
Cheers,
Our test wallet has been approved by the Apple iTunes store. If you have DigiBytes stuck in the old iOS wallet and would like to help us test the new wallet please email [email protected] your Apple ID email and we will add you to the Test Flight list.
Cheers,
February 21, 2016, 10:58:51 PM
Here is the first weighting code (pre DigiSpeed):
https://github.com/digibyte/digibyte/blob/master/src/main.h#L866
New Adjusted Weighting Code (Post DigiSpeed):
https://github.com/digibyte/digibyte/blob/master/src/main.h#L866
Code:
int GetAlgoWorkFactor() const
{
if (!TestNet() && (nHeight < multiAlgoDiffChangeTarget))
{
return 1;
}
if (TestNet() && (nHeight < 100))
{
return 1;
}
switch (GetAlgo())
{
case ALGO_SHA256D:
return 1;
// work factor = absolute work ratio * optimisation factor
case ALGO_SCRYPT:
return 1024 * 4;
case ALGO_GROESTL:
return 64 * 8;
case ALGO_SKEIN:
return 4 * 6;
case ALGO_QUBIT:
return 128 * 8;
default:
return 1;
}
}
{
if (!TestNet() && (nHeight < multiAlgoDiffChangeTarget))
{
return 1;
}
if (TestNet() && (nHeight < 100))
{
return 1;
}
switch (GetAlgo())
{
case ALGO_SHA256D:
return 1;
// work factor = absolute work ratio * optimisation factor
case ALGO_SCRYPT:
return 1024 * 4;
case ALGO_GROESTL:
return 64 * 8;
case ALGO_SKEIN:
return 4 * 6;
case ALGO_QUBIT:
return 128 * 8;
default:
return 1;
}
}
New Adjusted Weighting Code (Post DigiSpeed):
Code:
CBigNum GetBlockWorkAdjusted() const
{
if (nHeight < workComputationChangeTarget)
{
CBigNum bnRes;
bnRes = GetBlockWork() * GetAlgoWorkFactor();
return bnRes;
}
else
{
CBigNum bnRes = 1;
CBlockHeader header = GetBlockHeader();
// multiply the difficulties of all algorithms
for (int i = 0; i < NUM_ALGOS; i++)
{
unsigned int nBits = GetNextWorkRequired(pprev, &header, i,false);
CBigNum bnTarget;
bnTarget.SetCompact(nBits);
if (bnTarget <= 0)
return 0;
bnRes *= (CBigNum(1)<<256) / (bnTarget+1);
}
// Compute the geometric mean
bnRes = bnRes.nthRoot(NUM_ALGOS);
// Scale to roughly match the old work calculation
bnRes <<= 7;
return bnRes;
}
}
{
if (nHeight < workComputationChangeTarget)
{
CBigNum bnRes;
bnRes = GetBlockWork() * GetAlgoWorkFactor();
return bnRes;
}
else
{
CBigNum bnRes = 1;
CBlockHeader header = GetBlockHeader();
// multiply the difficulties of all algorithms
for (int i = 0; i < NUM_ALGOS; i++)
{
unsigned int nBits = GetNextWorkRequired(pprev, &header, i,false);
CBigNum bnTarget;
bnTarget.SetCompact(nBits);
if (bnTarget <= 0)
return 0;
bnRes *= (CBigNum(1)<<256) / (bnTarget+1);
}
// Compute the geometric mean
bnRes = bnRes.nthRoot(NUM_ALGOS);
// Scale to roughly match the old work calculation
bnRes <<= 7;
return bnRes;
}
}
February 21, 2016, 10:50:49 PM
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?
Yes block distribution is 20/20/20/20/20. To compare the exact changes in the last hard fork compare GetNextWorkRequiredV3 to GetNextWorkRequiredV4.
Current difficulty adjustment code:
https://github.com/digibyte/digibyte/blob/master/src/main.cpp#L1670
Code:
static unsigned int GetNextWorkRequiredV4(const CBlockIndex* pindexLast, const CBlockHeader *pblock, int algo,bool log)
{
unsigned int nProofOfWorkLimit = Params().ProofOfWorkLimit(algo).GetCompact();
// Genesis block
if (pindexLast == NULL)
return nProofOfWorkLimit;
if (TestNet())
{
// Special difficulty rule for testnet:
// If the new block's timestamp is more than 2* 10 minutes
// then allow mining of a min-difficulty block.
if (pblock->nTime > pindexLast->nTime + nTargetSpacing*2)
return nProofOfWorkLimit;
else
{
// Return the last non-special-min-difficulty-rules-block
const CBlockIndex* pindex = pindexLast;
while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit)
pindex = pindex->pprev;
return pindex->nBits;
}
}
if(log)
{
LogPrintf("GetNextWorkRequired RETARGET\n");
LogPrintf("Algo: %s\n", GetAlgoName(algo));
LogPrintf("Height (Before): %s\n", pindexLast->nHeight);
}
// find first block in averaging interval
// Go back by what we want to be nAveragingInterval blocks per algo
const CBlockIndex* pindexFirst = pindexLast;
for (int i = 0; pindexFirst && i < NUM_ALGOS*nAveragingInterval; i++)
{
pindexFirst = pindexFirst->pprev;
}
const CBlockIndex* pindexPrevAlgo = GetLastBlockIndexForAlgo(pindexLast, algo);
if (pindexPrevAlgo == NULL || pindexFirst == NULL)
{
if(log)
LogPrintf("Use default POW Limit\n");
return nProofOfWorkLimit;
}
// Limit adjustment step
// Use medians to prevent time-warp attacks
int64_t nActualTimespan = pindexLast-> GetMedianTimePast() - pindexFirst->GetMedianTimePast();
nActualTimespan = nAveragingTargetTimespanV4 + (nActualTimespan - nAveragingTargetTimespanV4)/4;
if(log)
LogPrintf("nActualTimespan = %d before bounds\n", nActualTimespan);
if (nActualTimespan < nMinActualTimespanV4)
nActualTimespan = nMinActualTimespanV4;
if (nActualTimespan > nMaxActualTimespanV4)
nActualTimespan = nMaxActualTimespanV4;
//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;
}
}
if (bnNew > Params().ProofOfWorkLimit(algo))
{
if(log)
{
LogPrintf("bnNew > Params().ProofOfWorkLimit(algo)\n");
}
bnNew = Params().ProofOfWorkLimit(algo);
}
if(log)
{
LogPrintf("nAveragingTargetTimespanV4 = %d; nActualTimespan = %d\n", nAveragingTargetTimespanV4, nActualTimespan);
LogPrintf("Before: %08x %s\n", pindexPrevAlgo->nBits, CBigNum().SetCompact(pindexPrevAlgo->nBits).getuint256().ToString());
LogPrintf("After: %08x %s\n", bnNew.GetCompact(), bnNew.getuint256().ToString());
}
return bnNew.GetCompact();
}
{
unsigned int nProofOfWorkLimit = Params().ProofOfWorkLimit(algo).GetCompact();
// Genesis block
if (pindexLast == NULL)
return nProofOfWorkLimit;
if (TestNet())
{
// Special difficulty rule for testnet:
// If the new block's timestamp is more than 2* 10 minutes
// then allow mining of a min-difficulty block.
if (pblock->nTime > pindexLast->nTime + nTargetSpacing*2)
return nProofOfWorkLimit;
else
{
// Return the last non-special-min-difficulty-rules-block
const CBlockIndex* pindex = pindexLast;
while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit)
pindex = pindex->pprev;
return pindex->nBits;
}
}
if(log)
{
LogPrintf("GetNextWorkRequired RETARGET\n");
LogPrintf("Algo: %s\n", GetAlgoName(algo));
LogPrintf("Height (Before): %s\n", pindexLast->nHeight);
}
// find first block in averaging interval
// Go back by what we want to be nAveragingInterval blocks per algo
const CBlockIndex* pindexFirst = pindexLast;
for (int i = 0; pindexFirst && i < NUM_ALGOS*nAveragingInterval; i++)
{
pindexFirst = pindexFirst->pprev;
}
const CBlockIndex* pindexPrevAlgo = GetLastBlockIndexForAlgo(pindexLast, algo);
if (pindexPrevAlgo == NULL || pindexFirst == NULL)
{
if(log)
LogPrintf("Use default POW Limit\n");
return nProofOfWorkLimit;
}
// Limit adjustment step
// Use medians to prevent time-warp attacks
int64_t nActualTimespan = pindexLast-> GetMedianTimePast() - pindexFirst->GetMedianTimePast();
nActualTimespan = nAveragingTargetTimespanV4 + (nActualTimespan - nAveragingTargetTimespanV4)/4;
if(log)
LogPrintf("nActualTimespan = %d before bounds\n", nActualTimespan);
if (nActualTimespan < nMinActualTimespanV4)
nActualTimespan = nMinActualTimespanV4;
if (nActualTimespan > nMaxActualTimespanV4)
nActualTimespan = nMaxActualTimespanV4;
//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;
}
}
if (bnNew > Params().ProofOfWorkLimit(algo))
{
if(log)
{
LogPrintf("bnNew > Params().ProofOfWorkLimit(algo)\n");
}
bnNew = Params().ProofOfWorkLimit(algo);
}
if(log)
{
LogPrintf("nAveragingTargetTimespanV4 = %d; nActualTimespan = %d\n", nAveragingTargetTimespanV4, nActualTimespan);
LogPrintf("Before: %08x %s\n", pindexPrevAlgo->nBits, CBigNum().SetCompact(pindexPrevAlgo->nBits).getuint256().ToString());
LogPrintf("After: %08x %s\n", bnNew.GetCompact(), bnNew.getuint256().ToString());
}
return bnNew.GetCompact();
}
February 21, 2016, 08:08:24 PM
That's wild! Thanks for the tip. Someone else mentioned them again not too long ago on my forum and I appreciate you confirming that.
Cheers
Edit: btw, did you finally end up having any luck with Craptsy?
No I never did, Once I saw they weren't updating after the hard fork I then tried to get out with BTC but at that point everything was going south and things were shutdown a few weeks later. I should have gotten some out through another coin but I was stubborn and didn't want to lose half my DGB. In the end I lost all of it. I guess that the bright side is that I involuntarily took out several million out of the DGB ecosystem =). I had all my eggs in cold wallets but I had some on the exchange that needed to be traded to pay for bills / rig debt etc and that's what I lost so...live and learn I guess.
February 21, 2016, 07:11:43 PM
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. That's exactly right: you should do your own work, especially since you haven't already done it on your own and of your own initiative. Or do you think I'm here to work for you? I've done my job by alerting you to the fact that with basic coding skills and the source code mentioned (that is freely available to the public), anyone can confirm it. It's your problem, not mine, if you don't care, and judging by your attitude, I guess it's just that, correct? If you don't care, why should I?
Trolling aside, it turns out you don't even need that. Even if the only thing you know about MultiShield is that it keeps each algorithm's share at 20%, that is already sufficient to answer your question (with basic math skills, of course). You can multiply and divide can't you?
Okay, trolling truly off now. One thing you seem to be confused about is the latest hardfork. MultiShield was not changed at all in the DigiSpeed hardfork (other than changing a few constants so blocks would be faster). The formula that estimates work per block was changed, but this is unrelated to difficulty adjustments.
Edit: apparently HR didn't get it, so here's some context:
Your analysis may very well be rigorous, but I can't find your analysis - only your conclusions and a rough description of your sources. If you want a serious response, post your source data, the conclusions you derive from the source data, and any required logical steps that go beyond "basic math skills". I shouldn't have to re-do all your work just to have a conversation with you about the results.
That's exactly right: you should do your own work, especially since you haven't already done it on your own and of your own initiative. Or do you think I'm here to work for you? I've done my job by alerting you to the fact that with basic math skills and the data source mentioned (that is freely available to the public), anyone can confirm it. It's your problem, not mine, if you don't care, and judging by your attitude, I guess it's just that, correct? If you don't care, why should I?
The "multiply and divide" line was similarly copied from one of your posts which seems to no longer exist.
February 21, 2016, 06:57:25 PM
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'm not very good at C++ but I suspect the answer to your question lies here: https://github.com/digibyte/digibyte/blob/master/src/miner.cpp#L155
If we accept that each algorithm finds 20% of the blocks. If we were to double the mining on any one of them, wouldn’t it be reasonable to expect ‘the amount of energy that we used’ to also double, even though the same amount of blocks would be mined?
February 21, 2016, 06:36:46 PM
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'm not very good at C++ but I suspect the answer to your question lies here: https://github.com/digibyte/digibyte/blob/master/src/miner.cpp#L155
February 21, 2016, 05:15:57 PM
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?
February 21, 2016, 05:00:52 PM
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).
February 21, 2016, 04:58:30 PM
I’m going to use these figures, pulled out of a post a little way back by a well know member of our community. I’m going to consider that these figures are in the ball park of correctness but it does not particularly matter for the purpose of this exercise.
5000 DGB of mining
SHA-256 ASIC using 2.4KWh
Scrypt ASIC using 7.5KWh
GPU using 9.9KWh
Then using some special magic, I’m going to make SHA size of the network just over 4 times bigger and the Scrypt size about 1.3 times bigger. Abracadabra, they are all on an equal footing and the DigiByte network is considerably stronger than it was before I used the special magic. I’m going to need to use a bit more magic again when the latest ASIC technology hits mining.
I know I don’t really have any special magic to use, that’s why knights are so important!
We could follow the other suggestion that has been made to tackle this issue and do away with the ASIC part of the network and replace it with other algorithms but I will argue that this would require more hard forks and would actually leave our network weaker than it is already.
5000 DGB of mining
SHA-256 ASIC using 2.4KWh
Scrypt ASIC using 7.5KWh
GPU using 9.9KWh
Then using some special magic, I’m going to make SHA size of the network just over 4 times bigger and the Scrypt size about 1.3 times bigger. Abracadabra, they are all on an equal footing and the DigiByte network is considerably stronger than it was before I used the special magic. I’m going to need to use a bit more magic again when the latest ASIC technology hits mining.
I know I don’t really have any special magic to use, that’s why knights are so important!
We could follow the other suggestion that has been made to tackle this issue and do away with the ASIC part of the network and replace it with other algorithms but I will argue that this would require more hard forks and would actually leave our network weaker than it is already.
I don't want to get entangled in this too much but I just wanted to mention that I've been able to undervolt my 280x and mine qubit to get about 11 MH/s and that only runs at about 150 watts according to my Kill-a-watt. 11 Mh/s is roughly about 5k dgb per day which will put my 150 watts at about 3.6kw per day. Still not as efficient a sha256 asic but a lot less than the 9.9kwh mentioned above. I am guessing that's for either Skein or Scrypt on a GPU.
Great to see your presense Kayahoga, as always. Those are some very impressive results indeed! Let me guess, a dual card NVIDIA rig?
Phenomenal.
Actually its not NVIDIA, its a single AMD MSI 280x. My "gaming" rig. Undervolting is the key, you cant do it with every card which is why I went with the MSI 280x. Back when I had my rigs once I figured out how to properly undervolt I was saving about $50 a month in electricity with only sacrificing a small amount of hashing power.
Wow! That's more than double the hashrate I've ever seen published for a 280x ( http://asistec-ti.com/phpbb/viewtopic.php?f=25&t=38 ). Incredible. And you're still mining and those are current rewards?
EDIT: if you post your configuration, I'll add it to the list.
The magic isn't in the config, its the new optimized miner. Check out the miner's from nicehash. They keep up on all the latest builds and optimized kernels.
Either way...I use --intensity 18 --worksize 64 -g 2 A 280x is one of the few cards that should always have a -g 2, my engine stays at 1020 since I'm undervolting. I am pretty sure if I threw more juice at it I could go for 1100 and get close to 12 MH
Edit: Yes I'm still mining, just on my gaming rig with a single GPU, mining away today on my 280x
That's wild! Thanks for the tip. Someone else mentioned them again not too long ago on my forum and I appreciate you confirming that.
Cheers
Edit: btw, did you finally end up having any luck with Craptsy?
February 21, 2016, 04:51:37 PM
The idea that a huge increase in the hashrate of any one given algo only affects the diff of that particular algo and thus magically levels the playing field is also ludicrous, unless, that is, there was a major undocumented change in the DigiSpeed update.
Wait a minute...are you saying that the hashrate of one algorithm affects the diff of other algorithms or are you saying that the fact that it doesn't doesn't level the playing field?
Please don't take this as unfounded criticism. My numbers suggest something very different from what you suggest, and I think that my analysis is quite rigourous and merits serious response - I'm asking for clarification and/or documentation so I can better understand; I am not attacking.
Your analysis may very well be rigorous, but I can't find your analysis - only your conclusions and a rough description of your sources. If you want a serious response, post your source data, the conclusions you derive from the source data, and any required logical steps that go beyond "basic math skills". I shouldn't have to re-do all your work just to have a conversation with you about the results.
That's exactly right: you should do your own work, especially since you haven't already done it on your own and of your own initiative. Or do you think I'm here to work for you? I've done my job by alerting you to the fact that with basic math skills and the data source mentioned (that is freely available to the public), anyone can confirm it. It's your problem, not mine, if you don't care, and judging by your attitude, I guess it's just that, correct? If you don't care, why should I?
In any event, it's a moot issue until the first question above is answered.
Thanks in advance.
February 21, 2016, 03:31:43 PM
The idea that a huge increase in the hashrate of any one given algo only affects the diff of that particular algo and thus magically levels the playing field is also ludicrous, unless, that is, there was a major undocumented change in the DigiSpeed update.
Wait a minute...are you saying that the hashrate of one algorithm affects the diff of other algorithms or are you saying that the fact that it doesn't doesn't level the playing field?
Please don't take this as unfounded criticism. My numbers suggest something very different from what you suggest, and I think that my analysis is quite rigourous and merits serious response - I'm asking for clarification and/or documentation so I can better understand; I am not attacking.
Your analysis may very well be rigorous, but I can't find your analysis - only your conclusions and a rough description of your sources. If you want a serious response, post your source data, the conclusions you derive from the source data, and any required logical steps that go beyond "basic math skills". I shouldn't have to re-do all your work just to have a conversation with you about the results.
February 21, 2016, 02:28:17 PM
Have you tried to scroll down on the home? It worked for me somehow, i got a pending unconfirmed payment , it's 2 months old tho, so i scrolled down and there are this bla" just click on them and send/delete them
I think that works only for non-brodcasted transaction.
do you have the exact date of sending the Digibytes to exchange?
I remember that when the Digispeed hardfork kicked in poloniex did not update on time.
I don't remember
but I contacted jared Mon, Feb 1, 2016 at 1:22 AM
http://puu.sh/n3K0d/f3efd94a77.png
so I can tell that the sending happned before that day or in the same exact day.
most likely a day or 2 before.
as I remember he said something about not being able to connect to the internet for a quiet long time. that's why he sold me that amount, I guess.
but about the escrow, I don't know why he's not answering.
he's not a member of this community, well if he is I don't know his username.
he speaks our language and we both made deals with him before. and I know the city where he lives, I don't think it would be hard to find his exact address it's a small place. but thinking about it, it's just a small amount, not worth going this far. and one more thing I'm not 100% sure that he have the 60k.
Oh and I nearly forgot to say, we are in the process of finding out if he has your funds!
thank you, I have troubled you all with my problem, I am sincerely sorry.
any news?
February 21, 2016, 01:15:50 PM
I’m going to use these figures, pulled out of a post a little way back by a well know member of our community. I’m going to consider that these figures are in the ball park of correctness but it does not particularly matter for the purpose of this exercise.
5000 DGB of mining
SHA-256 ASIC using 2.4KWh
Scrypt ASIC using 7.5KWh
GPU using 9.9KWh
Then using some special magic, I’m going to make SHA size of the network just over 4 times bigger and the Scrypt size about 1.3 times bigger. Abracadabra, they are all on an equal footing and the DigiByte network is considerably stronger than it was before I used the special magic. I’m going to need to use a bit more magic again when the latest ASIC technology hits mining.
I know I don’t really have any special magic to use, that’s why knights are so important!
We could follow the other suggestion that has been made to tackle this issue and do away with the ASIC part of the network and replace it with other algorithms but I will argue that this would require more hard forks and would actually leave our network weaker than it is already.
5000 DGB of mining
SHA-256 ASIC using 2.4KWh
Scrypt ASIC using 7.5KWh
GPU using 9.9KWh
Then using some special magic, I’m going to make SHA size of the network just over 4 times bigger and the Scrypt size about 1.3 times bigger. Abracadabra, they are all on an equal footing and the DigiByte network is considerably stronger than it was before I used the special magic. I’m going to need to use a bit more magic again when the latest ASIC technology hits mining.
I know I don’t really have any special magic to use, that’s why knights are so important!
We could follow the other suggestion that has been made to tackle this issue and do away with the ASIC part of the network and replace it with other algorithms but I will argue that this would require more hard forks and would actually leave our network weaker than it is already.
I don't want to get entangled in this too much but I just wanted to mention that I've been able to undervolt my 280x and mine qubit to get about 11 MH/s and that only runs at about 150 watts according to my Kill-a-watt. 11 Mh/s is roughly about 5k dgb per day which will put my 150 watts at about 3.6kw per day. Still not as efficient a sha256 asic but a lot less than the 9.9kwh mentioned above. I am guessing that's for either Skein or Scrypt on a GPU.
Great to see your presense Kayahoga, as always. Those are some very impressive results indeed! Let me guess, a dual card NVIDIA rig?
Phenomenal.
Actually its not NVIDIA, its a single AMD MSI 280x. My "gaming" rig. Undervolting is the key, you cant do it with every card which is why I went with the MSI 280x. Back when I had my rigs once I figured out how to properly undervolt I was saving about $50 a month in electricity with only sacrificing a small amount of hashing power.
Wow! That's more than double the hashrate I've ever seen published for a 280x ( http://asistec-ti.com/phpbb/viewtopic.php?f=25&t=38 ). Incredible. And you're still mining and those are current rewards?
EDIT: if you post your configuration, I'll add it to the list.
The magic isn't in the config, its the new optimized miner. Check out the miner's from nicehash. They keep up on all the latest builds and optimized kernels.
Either way...I use --intensity 18 --worksize 64 -g 2 A 280x is one of the few cards that should always have a -g 2, my engine stays at 1020 since I'm undervolting. I am pretty sure if I threw more juice at it I could go for 1100 and get close to 12 MH
Edit: Yes I'm still mining, just on my gaming rig with a single GPU, mining away today on my 280x
February 21, 2016, 12:34:50 PM
I’m going to use these figures, pulled out of a post a little way back by a well know member of our community. I’m going to consider that these figures are in the ball park of correctness but it does not particularly matter for the purpose of this exercise.
5000 DGB of mining
SHA-256 ASIC using 2.4KWh
Scrypt ASIC using 7.5KWh
GPU using 9.9KWh
Then using some special magic, I’m going to make SHA size of the network just over 4 times bigger and the Scrypt size about 1.3 times bigger. Abracadabra, they are all on an equal footing and the DigiByte network is considerably stronger than it was before I used the special magic. I’m going to need to use a bit more magic again when the latest ASIC technology hits mining.
I know I don’t really have any special magic to use, that’s why knights are so important!
We could follow the other suggestion that has been made to tackle this issue and do away with the ASIC part of the network and replace it with other algorithms but I will argue that this would require more hard forks and would actually leave our network weaker than it is already.
5000 DGB of mining
SHA-256 ASIC using 2.4KWh
Scrypt ASIC using 7.5KWh
GPU using 9.9KWh
Then using some special magic, I’m going to make SHA size of the network just over 4 times bigger and the Scrypt size about 1.3 times bigger. Abracadabra, they are all on an equal footing and the DigiByte network is considerably stronger than it was before I used the special magic. I’m going to need to use a bit more magic again when the latest ASIC technology hits mining.
I know I don’t really have any special magic to use, that’s why knights are so important!
We could follow the other suggestion that has been made to tackle this issue and do away with the ASIC part of the network and replace it with other algorithms but I will argue that this would require more hard forks and would actually leave our network weaker than it is already.
I don't want to get entangled in this too much but I just wanted to mention that I've been able to undervolt my 280x and mine qubit to get about 11 MH/s and that only runs at about 150 watts according to my Kill-a-watt. 11 Mh/s is roughly about 5k dgb per day which will put my 150 watts at about 3.6kw per day. Still not as efficient a sha256 asic but a lot less than the 9.9kwh mentioned above. I am guessing that's for either Skein or Scrypt on a GPU.
Great to see your presense Kayahoga, as always. Those are some very impressive results indeed! Let me guess, a dual card NVIDIA rig?
Phenomenal.
Actually its not NVIDIA, its a single AMD MSI 280x. My "gaming" rig. Undervolting is the key, you cant do it with every card which is why I went with the MSI 280x. Back when I had my rigs once I figured out how to properly undervolt I was saving about $50 a month in electricity with only sacrificing a small amount of hashing power.
Wow! That's more than double the hashrate I've ever seen published for a 280x ( http://asistec-ti.com/phpbb/viewtopic.php?f=25&t=38 ). Incredible. And you're still mining and those are current rewards?
EDIT: if you post your configuration, I'll add it to the list.
The magic isn't in the config, its the new optimized miner. Check out the miner's from nicehash. They keep up on all the latest builds and optimized kernels.
Either way...I use --intensity 18 --worksize 64 -g 2 A 280x is one of the few cards that should always have a -g 2, my engine stays at 1020 since I'm undervolting. I am pretty sure if I threw more juice at it I could go for 1100 and get close to 12 MH
Edit: Yes I'm still mining, just on my gaming rig with a single GPU, mining away today on my 280x
February 21, 2016, 08:42:54 AM
I’m going to use these figures, pulled out of a post a little way back by a well know member of our community. I’m going to consider that these figures are in the ball park of correctness but it does not particularly matter for the purpose of this exercise.
5000 DGB of mining
SHA-256 ASIC using 2.4KWh
Scrypt ASIC using 7.5KWh
GPU using 9.9KWh
Then using some special magic, I’m going to make SHA size of the network just over 4 times bigger and the Scrypt size about 1.3 times bigger. Abracadabra, they are all on an equal footing and the DigiByte network is considerably stronger than it was before I used the special magic. I’m going to need to use a bit more magic again when the latest ASIC technology hits mining.
I know I don’t really have any special magic to use, that’s why knights are so important!
We could follow the other suggestion that has been made to tackle this issue and do away with the ASIC part of the network and replace it with other algorithms but I will argue that this would require more hard forks and would actually leave our network weaker than it is already.
5000 DGB of mining
SHA-256 ASIC using 2.4KWh
Scrypt ASIC using 7.5KWh
GPU using 9.9KWh
Then using some special magic, I’m going to make SHA size of the network just over 4 times bigger and the Scrypt size about 1.3 times bigger. Abracadabra, they are all on an equal footing and the DigiByte network is considerably stronger than it was before I used the special magic. I’m going to need to use a bit more magic again when the latest ASIC technology hits mining.
I know I don’t really have any special magic to use, that’s why knights are so important!
We could follow the other suggestion that has been made to tackle this issue and do away with the ASIC part of the network and replace it with other algorithms but I will argue that this would require more hard forks and would actually leave our network weaker than it is already.
I don't want to get entangled in this too much but I just wanted to mention that I've been able to undervolt my 280x and mine qubit to get about 11 MH/s and that only runs at about 150 watts according to my Kill-a-watt. 11 Mh/s is roughly about 5k dgb per day which will put my 150 watts at about 3.6kw per day. Still not as efficient a sha256 asic but a lot less than the 9.9kwh mentioned above. I am guessing that's for either Skein or Scrypt on a GPU.
Great to see your presense Kayahoga, as always. Those are some very impressive results indeed! Let me guess, a dual card NVIDIA rig?
Phenomenal.
Actually its not NVIDIA, its a single AMD MSI 280x. My "gaming" rig. Undervolting is the key, you cant do it with every card which is why I went with the MSI 280x. Back when I had my rigs once I figured out how to properly undervolt I was saving about $50 a month in electricity with only sacrificing a small amount of hashing power.
Wow! That's more than double the hashrate I've ever seen published for a 280x ( http://asistec-ti.com/phpbb/viewtopic.php?f=25&t=38 ). Incredible. And you're still mining and those are current rewards?
EDIT: if you post your configuration, I'll add it to the list.
February 21, 2016, 08:36:16 AM
Have you tried to scroll down on the home? It worked for me somehow, i got a pending unconfirmed payment , it's 2 months old tho, so i scrolled down and there are this bla" just click on them and send/delete them
I think that works only for non-brodcasted transaction.
do you have the exact date of sending the Digibytes to exchange?
I remember that when the Digispeed hardfork kicked in poloniex did not update on time.
I don't remember
but I contacted jared Mon, Feb 1, 2016 at 1:22 AM
http://puu.sh/n3K0d/f3efd94a77.png
so I can tell that the sending happned before that day or in the same exact day.
most likely a day or 2 before.
as I remember he said something about not being able to connect to the internet for a quiet long time. that's why he sold me that amount, I guess.
but about the escrow, I don't know why he's not answering.
he's not a member of this community, well if he is I don't know his username.
he speaks our language and we both made deals with him before. and I know the city where he lives, I don't think it would be hard to find his exact address it's a small place. but thinking about it, it's just a small amount, not worth going this far. and one more thing I'm not 100% sure that he have the 60k.
Oh and I nearly forgot to say, we are in the process of finding out if he has your funds!
thank you, I have troubled you all with my problem, I am sincerely sorry.
any news?
Jump to: