Topic: [ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65% - page 700. (Read 1260677 times)

I have some question for Cryptonit:
- Why my minted DMD (over 200 confirm, over 7 days) is not existed in Coin Control list?
- After DMD coin is minted, when is it ready for staking (7 days or never)?

send me your DMD wallet u won 7 DMD!

thx mate

https://bitcointalk.org/index.php?topic=580725.msg8133065;topicseen#msg8133065

trying to install the wallet : error loading blkindex.dat  . known problem?

Your analisys is good and indeed it seems the better way to address the problem. Is there no problem for nActualSpacing > nTargetTimespan?

Doing some more tests, it seems that once we let this "negative" number in, it keeps staying negative. I am experimenting now with adding the same "make positive" code for bnNew as well. Do you see any problems with this?

Also, while we are at this stage that requires forking, do you have any other code improvement suggestions?

It is a public forum. If you don't want comments then you have to send private messages.

I've already compiled the headless wallet on arm and it works on android. The interface is missing of course.
We discussed this recently (should it stake? full blockchain? fork bitcoin opensource android wallet? etc.).

Let's view PPC chart http://coinmarketcap.com/currencies/peercoin/
After they release new wallet in android.
I'm learning dev app in android, I'll free to join DMD wallet project .
We need to make something for DMD, to make it's more popular.

Yah some of us can speak English. unlike the DEV who cant spell

unfortunately there is a lot of people who need to take it out by badwording and offending on forums, because they can't in real life.

tell cryptsy they probably have largest wallet.

eta on mining fix ?

Yes.


    bnNew.SetCompact(pindexPrev->nBits);
    ....
    int64 nInterval = nTargetTimespan / nTargetSpacing;
    bnNew *= ((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing);
    bnNew /= ((nInterval + 1) * nTargetSpacing);

The bnNew is set to the last block's nbits. Then its value multiplied by
((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing)/((nInterval + 1) * nTargetSpacing)

If you set nActualSpacing to 1 then it will be multiplied by
((nInterval - 1) * nTargetSpacing + 2)/((nInterval + 1) * nTargetSpacing)=
(nInterval - 1)/(nInterval + 1) + 2/((nInterval + 1) * nTargetSpacing) =
((nTargetTimespan-nTargetSpacing) / (nTargetTimespan+nTargetSpacing)) + 2/((nTargetTimespan + nTargetSpacing) =
((nTargetTimespan-nTargetSpacing+2) / (nTargetTimespan+nTargetSpacing)) =
(1802-nTargetSpacing)/(1800+nTargetSpacing)
If nTargetSpacing>1 then it is smaller than 1 so you will decrease the target and increase the diff. It gives an exploitable bug: If you generates negative time hopping then you can artifically increase the diff and slow down the blockchain.
If it is a PoS block then nTargetSpacing=600 and the multiplier is (1802-600)/(1800+600)=0.5 approx. Now there are only PoS blocks, so every negative time hopping block will double the diff.

If you set nActualSpacing=nTargetSpacing, then:
((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing)/((nInterval + 1) * nTargetSpacing) =
((nInterval - 1) * nTargetSpacing + nTargetSpacing + nTargetSpacing )/((nInterval + 1) * nTargetSpacing) =
((nInterval + 1) * nTargetSpacing )/((nInterval + 1) * nTargetSpacing) = 1

So if there are a negative time hopping attack the target and diff will not change, so there will be no advantage of this kind of attack.

Our pacing code is

        if(nActualSpacing < 0)
        {
            printf(">> %s nActualSpacing = %"PRI64d" corrected to 1.\n", fProofOfStake ? "PoS" : "PoW", nActualSpacing);
            nActualSpacing = 1;
        }
        else if(nActualSpacing > nTargetTimespan)
        {
            printf(">> %s nActualSpacing = %"PRI64d" corrected to nTargetTimespan (%"PRI64d").\n", fProofOfStake ? "PoS" : "PoW", nActualSpacing, nTargetTimespan);
            nActualSpacing = nTargetTimespan;
        }


This works well for PoS.

Do you think it would be better to use

if (nActualSpacing<0) nActualSpacing=nTargetSpacing

thanks cryptonit i now have 3 pending minted blocks... my wallet is always open and minting hope this helps

The other solution is the blockcheck fixing to do not accept negative times. But in this case if somebody successfully submits a block with +30min blocktime, then the chain will be stopped for 30 minutes.
If you limit the time between two blocks to avoid forward hopping, then if you have enought hashrate you can deadlock the blockchain, by at first increasing diff then removing the rig from the network.

But if you don't let bnNew to be negative, then you don't need this fix. It would be better because this fix multiplies the target with -1, therefore it probably produces other bugs which could be exploited by negative times and fuck ups the diff(there are only one pros: the blockchain will not stop under time hopping attack). If you put a value check after nActualSpacing
if (nActualSpacing<0) nActualSpacing=nTargetSpacing
then diff will not change if time hop occoured.

IMPORTANT:
we need anyone have his DMD wallet in minting mode please
thx for ur support

I see Bitcoin has now different SetCompact/GetCompact code, but this might far too dangerous to change in haste. The 'always positive' code might be better -- although not sure it is very portable..