Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 6600. (Read 9723680 times)

I could be wrong but I saw a thread in the regular altcoin forum started by BitcoinExpress about KGW having the ability to be manipulated. He was vague but I tend to believe him as he def knows his stuff. This leans me to believe it has nothing to do with the darksend but rather KGW. Maybe could contact bitcoinexpress?

As some of you know one of my interest is in testing the security of cryptocoins. Over the past 4 years I have "tested" so many I have lost count but one thing remains true. No matter what the so called improvement is, it always has an exploit.

Kimoto Gravity Well is one such improvement that solves a problem that AUR is having at the moment and that is moving at the speed of death as well purportedly protects against 51%. While KGW does protect somewhat against a 51% attack, it opens up a huge hole in the time warp exploit via the diff adjust first deployed against Geist Geld back in mid 2011 and a modded versions used last year on a few Scrypt coins and SHA coins with great success.

Long story short, KGW opens up a flank where a newly modded Time Warp Exploit can be deployed. I have sandbox tested it on AUR and it seems to do the trick in grand fashion but that is with a small amount of nethash in the sandbox. I need a live chain to test it on. So considering the vast amount of request I have received to take out this 50% premine scam, I thought it would be a good candidate to test on.

Why am I giving notice? Simply because in the past when I use alt coin chains as test subjects, people tend to lose coins. In particular, my ol' buddy Kelsey lost a ton last year in GME LOL. Block 5400 or when ever KGW kicks in will be the starting point. This will give all of you enough time to either cold store your AUR or dump them until the chain is fixed, if it can be after the test.

That's some fancy calculatin'

So, I wonder if something in the new darksend pool coding is twaeking the KGW... Is it possible that all the extra transactions are causing a difficulty twitch? I realize difficulty is based on blocks solved, not transactions sent, but perhaps something is getting crossed up somewhere?

Or is this an attack of some sort, injecting a bunch of crap hashes to try to bounce the difficulty?

Or maybe we should revisit hrt's claims ...

The actual equipment necessary is tremendous if it were to do this naturally. Boiling everything down to i7 processors and r9 290's . . in order to double the difficulty . . you need double the equipment. Looking at suchpool.pw . . the net hashes right now are 12g#. Taking this as normal with 306 difficulty . . then the hashes number would need to double to take it to 612 difficulty. Then double again to take it to 1224 difficulty. Then double again to take it to 2500 difficulty, again to 5k, and one last time to 10k difficulty. This ends up being 2^5.

So @ 12 g#, we'd need about 5517 R9 290's . . or about 33k i7 processors just to have it there now.

Doubling this . . 11304 290's, 66k i7's . . about $5.8 million in just GPU hardware ($21 million in processors)
Double again . . 22068 290's, 132k i7's
Double again . . 44136 290's, 264k i7's
Double yet again . . 88272 290's, 528k i7's
One last doubling . . 176544 290's, 1M i7's


Also, normalizing to Scrypt . . a 10k difficulty for this coin is a difficulty of 3872.

Last I checked no one person had pretty much the entire Litecoin network in hashing power . . so I really need to lean toward a bug or serious exploit in the difficulty retargeting algorithm.

Someone please let me know how far off I am.

hrt
Newbie
*
Online Online

Activity: 27



View Profile Personal Message (Online)
Trust: 0: -0 / +0(0)
   
Re: cpu hashrate
« Sent to: sippsnapp on: March 11, 2014, 06:44:56 PM »
« You have forwarded or responded to this message. »
   Reply with quoteQuote ReplyReply Remove this messageDelete
I run through mining proxy with a changed code. it denies automatic difficulty adjustment on pool stratum server, assign to each share variable hash raws [not unfeigned] thus stratum server is incapable to make up authenticity of this shares. i have always calculated at 0 diff and got all shares accepted, earnings respectively
Report To Admin
hrt
Newbie
*
Online Online

Activity: 27



View Profile Personal Message (Online)
Trust: 0: -0 / +0(0)
   
Re: cpu hashrate
« Sent to: sippsnapp on: March 11, 2014, 08:50:38 PM »
« You have forwarded or responded to this message. »
   Reply with quoteQuote ReplyReply Remove this messageDelete
added several extensions while compiled from 1.3 version in open source
i tried with different algos and at now proxy works on X11, groestl, qubit and sha256d.
saying clearly sha256d is not so useful as 500-1000GH guys play. on sha256d i have 80 iterations per second each pick up a low diff share at speed 48000KH. Running 30 CPU is equal to 115GH
if you are interested and there are other engaged people i can start a new topic with this on mind and share proxy for small donate although pulling out this in public would be risky as this is still cheating

Glad to hear that there's progress about fixing stratum exploits.

Any chance you could get Evan, or someone who has a clue what's going on, to comment about the difficulty? Some blocks its 150, some it's 300, then we get a spike and its around 800. Normally I'd let it slide, but the most recent spike was over 10k . . so what's going on?

I've seen plenty of KGW implementations but haven't seen crazy swings like I've seen with this coin. Has this already been talked about before in the tread?

Don't forget, people, that we have a wonderful forum where you can ask questions in an organized fashion.  Subjects can be kept under their own headers, and information can be easily searched, instead of like here where it could be anywhere in 420 + pages.  Please come join us on https://www.darkcointalk.org !

Ok, to summerise, without disclosing too much info for others to try on other pools:

that guy with the huge "mining speed" was using a weakness in the stratum code, i notised a weakness in the way the pool got the shares
and set defences up to prevent that kind of cheating, in reality he did not have that kind of mining power, and his shares wasnt worth anything to the pools overall progress. if you look at all the blocks discovered, why did hes miner not discover ANY blocks at all, we should have been getting loads of blocks with that kind of speed, so i investigated, together with evan we set up a fix, now, next time he tries, the system will automatically ban him for a week. he tried connection through a proxy but already he was unable to get that kind of speed that he had at first.
so that tells me it works as it should.. i also banned his ips from the server. and disabled automatic payout from his account.


regarding the orphants on the official pool, i think we got that sorted out as well...