Author

Topic: ★★DigiByte|极特币★★[DGB]✔ Core v6.16.5.1 - DigiShield, DigiSpeed, Segwit - page 547. (Read 3058816 times)

legendary
Activity: 1722
Merit: 1051
Official DigiByte Account
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,

legendary
Activity: 1722
Merit: 1051
Official DigiByte Account
Here is the first weighting code (pre 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;
        }
    }

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;
        }
    }
legendary
Activity: 1722
Merit: 1051
Official DigiByte Account
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();
}
full member
Activity: 146
Merit: 100

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. 
newbie
Activity: 40
Merit: 0
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.
legendary
Activity: 1218
Merit: 1003
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
It's an interesting question but I don't understand what it has to do with distribution energy cost.
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?
hero member
Activity: 517
Merit: 500
aka alaniz
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
HR
legendary
Activity: 1176
Merit: 1011
Transparency & Integrity
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?
hero member
Activity: 517
Merit: 500
aka alaniz
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).
HR
legendary
Activity: 1176
Merit: 1011
Transparency & Integrity
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.



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?
HR
legendary
Activity: 1176
Merit: 1011
Transparency & Integrity
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?
You're one of the DigiSpeed update coders, you tell me. Don't you think that is the logical direction of information flow? Are they completely independent of one another? Total aggregate hashrate of the combined 5 algos means nothing in the dynamic adjustment of each individual algo's diff? Each algo's diff is completely independent of the others and is dependent exclusively and only on its own hashrate?

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.

newbie
Activity: 40
Merit: 0
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.
legendary
Activity: 1218
Merit: 1003

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  Wink

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.
Did you ever manage to contact the person that you bought the dgb from or the escrow service that you used again, did they reply to you?
no replay. I'll inform you when ever i get contact with either one of them.
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.
Well, I suspect I know why he isn't answering you and I wouldn't want any other member of our community using his services!

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.
what has happened could be unintentional on his part but now would be the time to step up and put things right.  Wink
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?
sent you a PM.
legendary
Activity: 1218
Merit: 1003
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.



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
Thanks Kayahoga for sharing your real world mining experience and tips with this community, it sounds like you have a great little DigiByte gaming setup there.
full member
Activity: 146
Merit: 100
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.



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
HR
legendary
Activity: 1176
Merit: 1011
Transparency & Integrity
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.



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.
member
Activity: 97
Merit: 10
Data Scientist

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  Wink

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.
Did you ever manage to contact the person that you bought the dgb from or the escrow service that you used again, did they reply to you?
no replay. I'll inform you when ever i get contact with either one of them.
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.
Well, I suspect I know why he isn't answering you and I wouldn't want any other member of our community using his services!

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.
what has happened could be unintentional on his part but now would be the time to step up and put things right.  Wink
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?
full member
Activity: 146
Merit: 100
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.



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. 
hero member
Activity: 687
Merit: 500
novag
Mb soon is going to big pump. Wink
hero member
Activity: 517
Merit: 500
aka alaniz
I was looking at the DGB trade history and saw this:

What does that bot do? Just create volume? Why would you sell and buy back, or are those 2 different accounts?

This is most probably an arbitrage bot. I can't imagine someone is buying and selling DGB at the same price!
Jump to: