Bitcoin Forum
May 12, 2024, 07:15:02 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 [162] 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 ... 862 »
  Print  
Author Topic: [ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65%  (Read 1260288 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
pokeytex
Legendary
*
Offline Offline

Activity: 1504
Merit: 1002



View Profile
September 17, 2014, 12:21:45 PM
 #3221

The dashboard on danbi's pool shows we're hashing away.
Does this mean we lose whatever mining power we pointed to it for now?
yes

send ur miners towards
http://multipool.bit.diamonds/
there lot possible algos u can use

Thanks. The problem is that I'm at work without access to rigs. Will have to wait till I get home tonight.

Just an fyi - I use Teamviewer (google it) - it is free and allows me access to my rigs no matter where I am.

1715541302
Hero Member
*
Offline Offline

Posts: 1715541302

View Profile Personal Message (Offline)

Ignore
1715541302
Reply with quote  #2

1715541302
Report to moderator
The forum was founded in 2009 by Satoshi and Sirius. It replaced a SourceForge forum.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715541302
Hero Member
*
Offline Offline

Posts: 1715541302

View Profile Personal Message (Offline)

Ignore
1715541302
Reply with quote  #2

1715541302
Report to moderator
pallas
Legendary
*
Offline Offline

Activity: 2716
Merit: 1094


Black Belt Developer


View Profile
September 17, 2014, 12:40:33 PM
 #3222

The dashboard on danbi's pool shows we're hashing away.
Does this mean we lose whatever mining power we pointed to it for now?
yes

send ur miners towards
http://multipool.bit.diamonds/
there lot possible algos u can use

Thanks. The problem is that I'm at work without access to rigs. Will have to wait till I get home tonight.

Just an fyi - I use Teamviewer (google it) - it is free and allows me access to my rigs no matter where I am.

or simply "byobu_enable" on linux ;-)

cryptonit
Legendary
*
Offline Offline

Activity: 3038
Merit: 1053


bit.diamonds | uNiq.diamonds


View Profile WWW
September 17, 2014, 12:43:30 PM
 #3223

The dashboard on danbi's pool shows we're hashing away.
Does this mean we lose whatever mining power we pointed to it for now?
yes

send ur miners towards
http://multipool.bit.diamonds/
there lot possible algos u can use

Thanks. The problem is that I'm at work without access to rigs. Will have to wait till I get home tonight.

Just an fyi - I use Teamviewer (google it) - it is free and allows me access to my rigs no matter where I am.


or simply "byobu_enable" on linux ;-)
just connect to danbi pool and delete ur worker user so ur mining rig have a bad username and stop hashing

 
  Diamond [DMD]     uNiq.Diamonds  
Scarce✦✦✦✦ Valuable ✦✦✦✦ Secure ✦                     ▬ a collector experience ▬                
cryptonit
Legendary
*
Offline Offline

Activity: 3038
Merit: 1053


bit.diamonds | uNiq.diamonds


View Profile WWW
September 17, 2014, 01:00:25 PM
 #3224

new feature DMD Multipool
http://multipool.bit.diamonds/
u can now browser through all exchange rounds
(where u earned DMD payouts)
with forwards backwards buttons
this way not only the last round is visible in exchange stats

 
  Diamond [DMD]     uNiq.Diamonds  
Scarce✦✦✦✦ Valuable ✦✦✦✦ Secure ✦                     ▬ a collector experience ▬                
cryptonit
Legendary
*
Offline Offline

Activity: 3038
Merit: 1053


bit.diamonds | uNiq.diamonds


View Profile WWW
September 17, 2014, 02:55:52 PM
 #3225

new competition
in last open irc chat of noblecoin
how often u read DMD:


IRC Latest:

Quote
<Boreiv> good news all around
<kresut> good to hear
<Rofo> know weve also got a couple of projects in the works that will legitimatly burn a decent amount of NOBL also to reduce supply
<Rofo> legitimately
<Rofo> though not quite another fork of counterparty
<ruan> still reducing to 5 billion noble? so we'll have less than that
<Rofo> well with PoS its more of a soft cap
<Rofo> but the PoS will be a lower (but still attractive %) at this point since the high-PoS crowd arent really working with us any longer
<cryptobum> still think a comparatively high POS is the way forward!
<cryptobum> if possible
<Rofo> so do i, i still think it needs to be an attractively high number
<Rofo> but 175% was too much
<Rofo> and scares away people/doesnt help public perception
<Rofo> as we saw
<cryptobum> middle ground 2 be found
<Rofo> yes
<Rofo> it also looks like we'll stay PoW for security/backup reasons on a MM pool with groestl algo, but the mined amount in that regard will be a token amount and have little effect on inflation
<Rofo> keep in mind these are just the new talks, weve been back and forth with too many parties for too long
<Rofo> so finalizing DMD team to step in and help with the fork, in return we share marketplace with them at this point
<Rofo> finalizing points now though looks promising
<Rofo> then i can unload everything else which i think will have a far better effect on price than pos switch
<ruan> 50-100%?
<cryptobum> are we still on for getting things done this week?
<Rofo> 50-100% first yeah seems so atm yes
<Rofo> and yes cryptobum looks like it, active in talks today and yesterday so far with DMD team over skype
<Rofo> so fingers crossed this is the last leg of the wait
<cryptobum> small bug. when yr on https://marketplace.noblemovement.com , click on 'marketplace' at top right and it sends u 2 a blanck page with an @ in address bar
<Rofo> sorry fixed thanks
<cryptobum> all sounds promissing!! Smiley
<Rofo> if youre watching the marketplace youll be seeing the 200+ gift cards being added, mining and tech gear is next
<cryptobum> like the direction marketplace is heading
<Rofo> then the discounts will start being applied at higher rates to larger holders to entice buying/holding rather than flipping to get a discount only
<cryptobum> very good work
<Rofo> cheers, i just have a lot of different projects on my plate hence the speed of updates
<cryptobum> i can imagine
<Rofo> work/team/support shrinks with market cap and rises with the cap
<Rofo> back and forth lol
<kresut> just don't unload them all at once Smiley
<Rofo> i wont be lol
<kresut> Wink
<cryptobum> how is gold looking at the mo?
<Rofo> i need about 1btc for the final license i think, but i dont want to score that by dumping any reserves
<Rofo> so will be funding that after pos with the new projects or if we get a big pump
<Rofo> got all of amagi metals supplies ready to be rolled out
<Rofo> will be adding all of australian perth mint stuff too since i have an account with them
<Rofo> most of it is money-related, i regret a little not turning the reserves into BTC back in the day to make this smoother sailing
<Rofo> but the whole point was not to dump it lol
<cryptobum> cld do a fund raiser 4 licence, ill put.1 btcs?
<Rofo> well
<Rofo> lets sort out pos first then ill feel nicer asking for donations once the morale is back and looking forward Smiley
<cryptobum> yes
<Rofo> and i can list any donation requirements and the licensing
<cryptobum> POS no 1 priority 4 sure!!!!
<Rofo> yep
<Rofo> so were still also on mintpal for now
<Rofo> their market listing was BS
<Rofo> and we'll be on altmarket which has a lot of potential
<Rofo> though i think i just said that earlier sorry lol
<kresut> so how would you summarize the transition to PoS - ETA: 1/2 weeks? / code work: DMD dev team (?) / method: swap (on the exchange or just updating the client) ?
<Rofo> as you know timeframes working with external devs (and me having perhaps too high of a dream to hardfork rather than swap) mean timeframes bite me in the ass
<kresut> yep
<Rofo> but it looks like DMD will step in and publicly commit & fork our github ready at least this week with final specs public
<Rofo> they say a fork is good, if its not well swap so it doesnt affect timeline any more
<Rofo> 2-3 weeks
<Rofo> DMD dev team
<kresut> okay, thanks
<Rofo> we team up closer ill be working on realworld uses and NOBL projects
<Rofo> they get marketplace and we get fulltime PoS support
<Rofo> i can handle a lot of PoS stuff myself also, just initial specs, security and fork was beyond me
<Rofo> hardforks im more paranoid about getting right, the wallet and feature updates though is a different story
<Rofo> https://www.noblemovement.com/
<Rofo> services dropdown getting ready for post-pos
<Rofo> actually ill be adding to that also regarding marketplace listings/promos with fees paid in NOBL
<Rofo> yes DMD is just as confident that is possible, theyve been through hell & back experimenting & improving DMD through multiple forks over a year and their latest dev has spent months reverse-engineering PoS it seems so he is confident
<Rofo> the DMD team have a very similar crypto philosophy to many of us and being both smaller market cap coins we are often overlooked but this will give us lots of room and good synergy to grow

 
  Diamond [DMD]     uNiq.Diamonds  
Scarce✦✦✦✦ Valuable ✦✦✦✦ Secure ✦                     ▬ a collector experience ▬                
utahjohn
Hero Member
*****
Offline Offline

Activity: 630
Merit: 500


View Profile
September 17, 2014, 04:17:01 PM
 #3226

I think getting PoW working again MUST be our top priority.  Sure partnering with NOBL seems useful but our focus must remain on DMD stability.
I mine DMD directly and this is a big issue for me right now with PoW broken.  I minted 4+ DMD yesterday Date: 9/16/2014 11:21 and still only 98 confirmations at 9/17/2014 10:15, clearly PoS is having problem also.
I am afraid to attempt withdraw DMD from exchange atm and so am mining for BTC only right now ... not good ...
Reggie0
Member
**
Offline Offline

Activity: 107
Merit: 13


View Profile
September 17, 2014, 06:03:23 PM
Last edit: September 17, 2014, 07:32:04 PM by Reggie0
 #3227

cryptonit: Did you check what I wrote?

Here is the other side of the problem:
According to the difficulty description nbits[23:0] is the mantissa** and nbits[31:24] is the characteristic**. Mantissa is a signed field(because of bitcoin developers are idiots), therefore 0x7fffff is the maximal allowed value. Actually in DMD blockchain the latest nbits is 0x1C9CB359, were 0x1C is the characteristic and 0x9CB359 is the mantissa. This value is too big. In this case the official method is dividing mantissa by 256 and increment the characteristics during block generation. The proper nbits is 0x1D009CB3. You have to implement this dividing algo in the block generator.

If you apply the negative value correction what I suggested in my prev. comment then wallets will continue block generation without block index dependent correction.


** target=nbits[23:0]<< (nbits[31:24]*8 )
big_coins
Full Member
***
Offline Offline

Activity: 175
Merit: 100


View Profile
September 17, 2014, 07:32:28 PM
 #3228

cryptonit: Did you check what I wrote?

Here is the other side of the problem:
According to the difficulty description nbits[23:0] is the mantissa** and nbits[31:24] is the characteristic**. Mantissa is a signed field(because of bitcoin developers are idiots), therefore 0x7fffff is the maximal allowed value. Actually in DMD blockchain the latest nbits is 0x1C9CB359, were 0x1C is the characteristic and 0x9CB359 is the mantissa. This value is too big. In this case the official method is dividing mantissa by 256 and increment the characteristics during block generation. The proper nbits is 0x1D009CB3. You have to implement this dividing algo in the block generator.

If you apply the negative value correction what I suggested in my prev. comment then wallets will continue block generation without block index dependent correction.


** target=nbits[23:0]<< (nbits[31:24]*8 )

i was going to say that.
Reggie0
Member
**
Offline Offline

Activity: 107
Merit: 13


View Profile
September 17, 2014, 07:52:59 PM
 #3229

My friend(elbandi) found an anomaly in blockchain. The 576751 went back in time compared to prev block 576750

576750: 1410868131 (2014-09-16 11:48:51)
576751: 1410866296 (2014-09-16 11:18:16)

In the wallet there are a
int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();

In this case nActualSpacing went to negative and pushed bnNew to negative too.
rgm108
Sr. Member
****
Offline Offline

Activity: 274
Merit: 250



View Profile
September 17, 2014, 08:04:10 PM
 #3230

The dashboard on danbi's pool shows we're hashing away.
Does this mean we lose whatever mining power we pointed to it for now?
yes

send ur miners towards
http://multipool.bit.diamonds/
there lot possible algos u can use

Thanks. The problem is that I'm at work without access to rigs. Will have to wait till I get home tonight.

Just an fyi - I use Teamviewer (google it) - it is free and allows me access to my rigs no matter where I am.


or simply "byobu_enable" on linux ;-)
just connect to danbi pool and delete ur worker user so ur mining rig have a bad username and stop hashing


Thanks for all the advice...

Running linux rigs but still a linux nub and very paranoid regarding security.
Did switch my rigs to x11 on multipool so all is running fine now...

SPECTRE                ▄▄███▄▄
            ▄▄███▀▀▀▀▀███▄▄
▄▄      ▄▄███▀▀ ▄▄███▄▄ ▀▀███▄▄      ▄▄
████▄▄  ▀▀▀ ▄▄███████████▄▄ ▀▀▀  ▄▄████
  ▀▀████▄    ▀▀█████████▀▀    ▄████▀▀
 ██▄▄ ▀██ █▄▄    ▀▀▀▀▀    ▄▄█ ██▀ ▄▄██
 ▀▀███ ██ █████▄       ▄█████ ██ ███▀▀
     ██ ███████▄   ▄███████ ██
       ██ ████████   ████████ ██
       ██▄▄ ▀▀████   ████▀▀ ▄▄██
        ▀▀███▄▄ ▀▀   ▀▀ ▄▄███▀▀
            ▀▀███▄▄▄▄▄███▀▀
                ▀▀███▀▀
            │
     │      ███
     │      ███
    │    ███
███  │    ███
███ ███ ███ ███
███ ███ ███ ███
███ ███ ███ ███
███ ███ ███ ███
███ ███     │
███ ███     │
    │
 
▬▬     WHITEPAPER    ▬▬
FACEBOOK     TELEGRAM
TWITTER     SLACK     MEDIUM
.
PRE-SALE.
PUBLIC SALE.
Zebedee23
Legendary
*
Offline Offline

Activity: 2086
Merit: 1001


View Profile
September 17, 2014, 08:11:33 PM
 #3231

new competition
in last open irc chat of noblecoin
how often u read DMD:




7

▄▄▄███████▄▄▄
▄█████████████████▄
▄█████████████████████▄
█████████████████████████
██████████        ▀████████
█████████    ████▄  █████████
█████████▀▀  ▀▀▀▀   █████████
█████████▄▄  ▄▄   ▄██████████
▀██████████  ███▄  ▀████████▀
▀█████████▄▄█████▄▄███████▀
▀███████████████████████▀
▀███████████████████▀
▀▀█████████████▀▀
▀▀▀▀▀▀▀
.Reserve.
▄▄▄███████▄▄▄
▄█████████████████▄
▄█████████████████████▄
████████▀▀▀███▀▀▀████████
█████████   ███   █████████
███████               ███████
██████████   ███   ██████████
██████████   ███   ██████████
▀██████               ██████▀
▀████████   ███   ████████▀
▀███████▄▄▄███▄▄▄███████▀
▀███████████████████▀
▀▀█████████████▀▀
▀▀▀▀▀▀▀
▄▄████████▄▄
▄████████████████▄
▄████████████████████▄
███████████████▀▀  █████
████████████▀▀      ██████
▐████████▀▀   ▄▄     ██████▌
▐████▀▀    ▄█▀▀     ███████▌
▐████████ █▀        ███████▌
████████ █ ▄███▄   ███████
████████████████▄▄██████
▀████████████████████▀
▀████████████████▀
▀▀████████▀▀

.Reserve Your Rights.
danbi
Sr. Member
****
Offline Offline

Activity: 393
Merit: 250


View Profile
September 17, 2014, 08:42:30 PM
 #3232

My friend(elbandi) found an anomaly in blockchain. The 576751 went back in time compared to prev block 576750

576750: 1410868131 (2014-09-16 11:48:51)
576751: 1410866296 (2014-09-16 11:18:16)

In the wallet there are a
int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();

In this case nActualSpacing went to negative and pushed bnNew to negative too.

We know this.

This is what was not implemented for PoW in Diamond. We implemented it for PoS only. (long story)

Your suggested fix to make bnTarget 'unsigned' will work. We have other options too, such as letting it be < 0 for a while. Then the time pacing code will kick in and it won't become negative again.

Do you have code suggestion to fix the mantissa/characteristic in the block generator?

BTC: 15cJkRupKAkGr6sTxj1Uzb6uHbvuRyK1GL
DMD: dJZEqNcjiUiMMd8DKBFS9oMWtArAD2GCHr
Reggie0
Member
**
Offline Offline

Activity: 107
Merit: 13


View Profile
September 17, 2014, 09:26:36 PM
Last edit: September 17, 2014, 09:57:27 PM by Reggie0
 #3233

My friend(elbandi) found an anomaly in blockchain. The 576751 went back in time compared to prev block 576750

576750: 1410868131 (2014-09-16 11:48:51)
576751: 1410866296 (2014-09-16 11:18:16)

In the wallet there are a
int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();

In this case nActualSpacing went to negative and pushed bnNew to negative too.

We know this.

This is what was not implemented for PoW in Diamond. We implemented it for PoS only. (long story)

Your suggested fix to make bnTarget 'unsigned' will work. We have other options too, such as letting it be < 0 for a while. Then the time pacing code will kick in and it won't become negative again.

Do you have code suggestion to fix the mantissa/characteristic in the block generator?

In GetNextTargetRequired, replace the end with this:

...
    CBigNum bnNew;
    bnNew.SetCompact(pindexPrev->nBits);
    int64 nTargetSpacing = fProofOfStake? nStakeTargetSpacing : min(nTargetSpacingWorkMax, (int64) nWorkTargetSpacing * (1 + pindexLast->nH
eight - pindexPrev->nHeight));
    int64 nInterval = nTargetTimespan / nTargetSpacing;
    bnNew *= ((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing);
    bnNew /= ((nInterval + 1) * nTargetSpacing);

    if (bnNew > bnTargetLimit)
        bnNew = bnTargetLimit;
    
    uint32_t newnbits;

     newnbits=bnNew.GetCompact();
     //compact format:  (M=mantissa, K=characteric)
     //nbits= 0xKKMMMMMM,  bnNew=0xMMMMMM <<(8*0xKK-3)
     //0xMMMMMM max allowed value 0x7FFFFF, because of it is signed(OMG).

     if ( newnbits & 0x00800000 )
        newnbits=( ( newnbits & 0xFF000000 ) + 0x01000000 ) | ( ( newnbits&0x00FFFFFF )>>8 );

    return newnbits;
}


danbi
Sr. Member
****
Offline Offline

Activity: 393
Merit: 250


View Profile
September 17, 2014, 09:52:13 PM
 #3234

My friend(elbandi) found an anomaly in blockchain. The 576751 went back in time compared to prev block 576750

576750: 1410868131 (2014-09-16 11:48:51)
576751: 1410866296 (2014-09-16 11:18:16)

In the wallet there are a
int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();

In this case nActualSpacing went to negative and pushed bnNew to negative too.

We know this.

This is what was not implemented for PoW in Diamond. We implemented it for PoS only. (long story)

Your suggested fix to make bnTarget 'unsigned' will work. We have other options too, such as letting it be < 0 for a while. Then the time pacing code will kick in and it won't become negative again.

Do you have code suggestion to fix the mantissa/characteristic in the block generator?

In GetNextTargetRequired, replace the end with this:

...
    CBigNum bnNew;
    bnNew.SetCompact(pindexPrev->nBits);
    int64 nTargetSpacing = fProofOfStake? nStakeTargetSpacing : min(nTargetSpacingWorkMax, (int64) nWorkTargetSpacing * (1 + pindexLast->nH
eight - pindexPrev->nHeight));
    int64 nInterval = nTargetTimespan / nTargetSpacing;
    bnNew *= ((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing);
    bnNew /= ((nInterval + 1) * nTargetSpacing);

    if (bnNew > bnTargetLimit)
        bnNew = bnTargetLimit;
    
    uint32_t newnbits;

     newnbits=bnNew.GetCompact();
     //compact format:  (M=mantissa, K=characteric)
     //nbits= 0xKKMMMMMM,  bnNew=0xMMMMMM <<(8*0xKK-3)
     //0xMMMMMM max allowed value 0x7FFFFF, because of it is signed(OMG).

     if ( newnbits & 0x00800000 )
        newnbits=( ( newnbits & 0xFF000000 ) + 0x01000000 ) | ( ( newnbits&0x00FFFFFF )>>8 );

    return newnbits;
}


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).

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..

BTC: 15cJkRupKAkGr6sTxj1Uzb6uHbvuRyK1GL
DMD: dJZEqNcjiUiMMd8DKBFS9oMWtArAD2GCHr
cryptonit
Legendary
*
Offline Offline

Activity: 3038
Merit: 1053


bit.diamonds | uNiq.diamonds


View Profile WWW
September 17, 2014, 09:55:26 PM
 #3235

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


 
  Diamond [DMD]     uNiq.Diamonds  
Scarce✦✦✦✦ Valuable ✦✦✦✦ Secure ✦                     ▬ a collector experience ▬                
Reggie0
Member
**
Offline Offline

Activity: 107
Merit: 13


View Profile
September 17, 2014, 09:57:51 PM
 #3236

My friend(elbandi) found an anomaly in blockchain. The 576751 went back in time compared to prev block 576750

576750: 1410868131 (2014-09-16 11:48:51)
576751: 1410866296 (2014-09-16 11:18:16)

In the wallet there are a
int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();

In this case nActualSpacing went to negative and pushed bnNew to negative too.

We know this.

This is what was not implemented for PoW in Diamond. We implemented it for PoS only. (long story)

Your suggested fix to make bnTarget 'unsigned' will work. We have other options too, such as letting it be < 0 for a while. Then the time pacing code will kick in and it won't become negative again.

Do you have code suggestion to fix the mantissa/characteristic in the block generator?

In GetNextTargetRequired, replace the end with this:

...
    CBigNum bnNew;
    bnNew.SetCompact(pindexPrev->nBits);
    int64 nTargetSpacing = fProofOfStake? nStakeTargetSpacing : min(nTargetSpacingWorkMax, (int64) nWorkTargetSpacing * (1 + pindexLast->nH
eight - pindexPrev->nHeight));
    int64 nInterval = nTargetTimespan / nTargetSpacing;
    bnNew *= ((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing);
    bnNew /= ((nInterval + 1) * nTargetSpacing);

    if (bnNew > bnTargetLimit)
        bnNew = bnTargetLimit;
    
    uint32_t newnbits;

     newnbits=bnNew.GetCompact();
     //compact format:  (M=mantissa, K=characteric)
     //nbits= 0xKKMMMMMM,  bnNew=0xMMMMMM <<(8*0xKK-3)
     //0xMMMMMM max allowed value 0x7FFFFF, because of it is signed(OMG).

     if ( newnbits & 0x00800000 )
        newnbits=( ( newnbits & 0xFF000000 ) + 0x01000000 ) | ( ( newnbits&0x00FFFFFF )>>8 );

    return newnbits;
}


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).

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..


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.

Reggie0
Member
**
Offline Offline

Activity: 107
Merit: 13


View Profile
September 17, 2014, 10:06:22 PM
 #3237

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.
stoody
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
September 17, 2014, 11:00:40 PM
 #3238

have 2 minted blocks.. here is one transaction

Status: 37 confirmations, broadcast through 13 nodes
Date: 17/09/2014 13:39
Debit: 0.00 DMD
Net amount: -105.404543 DMD
Transaction ID: f4eb765ee338c4fcf958c9946d177856c1a543b412c87e57b0ce302633a63760

any idea if this is a true minted block??

thanks for ur time...
mugwarh

Proof of Stake: 4.867123 coins generated  Grin

http://diamond.danbo.bg:2750/block/63dcc0387d4d9bdafdef62da643069eb1b2dedb1390675d92218e590cdcbdaab
thanks cryptonit i now have 3 pending minted blocks... my wallet is always open and minting hope this helps
danbi
Sr. Member
****
Offline Offline

Activity: 393
Merit: 250


View Profile
September 17, 2014, 11:11:11 PM
 #3239

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

BTC: 15cJkRupKAkGr6sTxj1Uzb6uHbvuRyK1GL
DMD: dJZEqNcjiUiMMd8DKBFS9oMWtArAD2GCHr
Reggie0
Member
**
Offline Offline

Activity: 107
Merit: 13


View Profile
September 18, 2014, 12:02:32 AM
Last edit: September 18, 2014, 12:39:40 AM by Reggie0
 #3240

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


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.
Pages: « 1 ... 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 [162] 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 ... 862 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!